rsync di macOS Sequoia diganti dengan openrsync

 (derflounder.wordpress.com)
2 poin oleh GN⁺ 2025-04-07 | 1 komentar | Bagikan ke WhatsApp
  • Di tengah situasi ketika alat sinkronisasi file bawaan macOS masih bertahan pada basis dari 2006, Apple mengganti rsync 2.6.9 dengan openrsync
  • rsync macOS yang lama memang menerima perbaikan yang diperlukan untuk keamanan dan masalah lainnya, tetapi tidak menyertakan fitur rsync 3.x setelah 2.6.9
  • Latar belakang utama peralihan ini adalah perbedaan lisensi: rsync 2.x didistribusikan di bawah GPLv2, sedangkan rsync 3.x di bawah GPLv3
  • openrsync kompatibel dengan rsync, tetapi hanya mendukung sebagian argumen command line, sehingga skrip yang ada mungkin tidak berjalan apa adanya di Sequoia
  • Pada macOS 15.4, /usr/bin/rsync terhubung ke openrsync, jadi administrator Mac perlu memeriksa opsi yang didukung dan kompatibilitas otomatisasi yang sudah ada

rsync 2.6.9 yang lama bertahan di macOS

  • rsync adalah alat command line untuk mentransfer dan menyinkronkan file di sistem operasi keluarga Unix
    • Dapat digunakan antarperangkat penyimpanan yang terhubung langsung ke komputer yang sama
    • Juga dapat digunakan untuk menyinkronkan file dengan komputer lain di jaringan
  • macOS sudah lama menyertakan rsync, tetapi versi yang disediakan Apple adalah rsync 2.6.9, yaitu versi terakhir rsync 2.x
  • rsync 2.6.9 dirilis pada November 2006, dan Apple tidak menaikkan rsync di macOS ke versi setelah itu meskipun rsync 3.x sudah hadir
  • Apple tetap memberikan pembaruan yang diperlukan untuk masalah keamanan dan masalah lain pada rsync 2.6.9 yang disertakan di macOS
  • Namun, hingga sebelum macOS Sequoia, rsync dari Apple masih berbasis fondasi yang hampir 20 tahun usianya, dan tidak menyertakan fitur baru yang ditambahkan pada versi rsync setelah 2.6.9

Stagnasi versi akibat GPLv2 dan GPLv3

  • rsync 2.x dan 3.x didistribusikan di bawah versi lisensi GPL yang berbeda
  • Apple menilai dapat mematuhi ketentuan GPLv2 pada rsync 2.x, tetapi tidak dapat mematuhi ketentuan GPLv3 pada rsync 3.x
  • Karena itu, rsync 3.x tidak disediakan di macOS

Peralihan ke openrsync di macOS Sequoia

  • Di macOS Sequoia, Apple mengganti rsync 2.6.9 dengan openrsync
  • openrsync adalah implementasi rsync yang tidak menggunakan lisensi GPL
  • openrsync didistribusikan dengan ISC license, salah satu lisensi keluarga BSD
  • ISC license adalah lisensi permisif (permissive license) yang memberikan pembatasan minimal terhadap penggunaan, modifikasi, dan distribusi perangkat lunak yang menerapkannya
  • Berbeda dengan ketentuan GPLv3 pada rsync 3.x, Apple menilai dapat mematuhi ketentuan lisensi openrsync

Perbedaan kompatibilitas yang penting bagi administrator Mac

  • Ke depannya, Apple dapat menyediakan versi pembaruan openrsync tanpa mengkhawatirkan masalah kepatuhan GPL pada rsync
  • Perubahan praktis yang lebih besar adalah meski openrsync kompatibel dengan rsync, ia hanya menerima sebagian argumen command line rsync
  • Fitur rsync yang sebelumnya berjalan di macOS lama bisa gagal di macOS Sequoia
    • Sebab fitur tersebut mungkin tidak ada di alat command line openrsync yang disertakan di Sequoia
  • Fitur yang didukung oleh openrsync di macOS Sequoia dapat diperiksa di halaman manual openrsync

Cara memeriksanya di macOS 15.4

  • Pada macOS 15.4, alat openrsync terhubung ke /usr/bin/rsync
  • Pengguna dapat menjalankan openrsync seperti menjalankan alat command line rsync seperti sebelumnya
  • Informasi versi openrsync dapat diperiksa dengan perintah berikut
/usr/bin/rsync --version
  • Outputnya mirip seperti berikut
username@computername ~ % /usr/bin/rsync --version
openrsync: protocol version 29
rsync version 2.6.9 compatible
username@computername ~ %
  • Output tersebut menampilkan protocol version 29 dan rsync version 2.6.9 compatible

Bacaan terkait

1 komentar

 
GN⁺ 2025-04-07
Komentar Hacker News

  • Dokumentasi openrsync terlalu minim, sehingga belum menimbulkan kepercayaan bahwa ia bisa menggantikan rsync
    Untuk program penyalin berkas, seharusnya ia mampu melakukan salinan lengkap tanpa kehilangan satu bit pun data dan metadata dari sumber; jika tidak, saya menganggapnya tidak layak dipakai
    Banyak alat penyalinan/pengarsipan di keluarga Unix tidak melakukan salinan lengkap dengan opsi bawaan, dan sebagian alat bahkan tidak bisa melakukannya dengan opsi apa pun
    scp juga, setidaknya sampai beberapa tahun lalu, sulit melakukan salinan lengkap ketika sistem operasi atau filesystem berbeda, jadi saya tidak memakainya dan hanya menggunakan rsync di atas ssh
    rsync adalah salah satu alat langka yang, jika diberi opsi yang tepat, dapat mempertahankan extended attributes, ACL, hingga timestamp presisi tinggi bahkan di antara sistem operasi/filesystem yang berbeda, seperti antara FreeBSD UFS dan Linux XFS
    Dokumentasi openrsync tidak menjamin salinan lengkap seperti ini, jadi untuk saat ini saya mengasumsikan ia belum bisa melakukannya dan menilainya tidak berguna
    Di sisi pengarsipan, di Linux, bsdtar saat memakai format pax dapat menyimpan salinan berkas yang hampir lengkap, sedangkan format tar/cpio lama tidak dapat memuat metadata modern
    Biasanya saya membuat alias rsync sebagai /usr/bin/rsync --archive --xattrs --acls --hard-links --progress --rsh="ssh -p XXX -l YYYYYYY"
    cp dari coreutils juga bisa melakukan salinan lengkap jika opsi CLI dan opsi kompilasinya benar, tetapi beberapa distro membangunnya tanpa dukungan extended attributes sehingga hanya melakukan salinan parsial tanpa peringatan atau error

    • Setelah bekerja di perusahaan backup, saya melihat sebagian besar pelanggan perusahaan besar tidak terlalu peduli apakah 99% metadata kembali dengan tepat saat pemulihan; selama datanya pulih, mereka merasa cukup
      Kami memulihkan semuanya dengan sangat hati-hati, tetapi kadang terasa hanya kami yang memedulikannya
    • Ini mungkin sekadar perbedaan gaya dokumentasi
      Pada dasarnya, saya akan menganggap openrsync sebagai rsync dengan batasan lisensi yang lebih longgar, bukan sebagai sesuatu yang berperilaku berbeda
      README openrsync mengatakan ia kompatibel dengan rsync dan meminta pembaca melihat dokumentasi rsync
      Jika extended attributes, ACL, dan timestamp resolusi tinggi bukan fitur opsional di level protokol, bukankah untuk mengklaim kompatibilitas ia harus mendukung semua yang didukung rsync modern?
      Atau saya penasaran apakah maksudnya ia menerima seluruh protokol tetapi begitu saja membuang hal-hal seperti ACL
    • OpenRsync berasal dari proyek OpenBSD, sehingga biasanya membuat orang berharap pada kualitas dan fokus keamanan
      Namun di situs web resminya juga tertulis “We are still working on it... so please wait.”
    • Dari sudut pandang Apple, ini adalah masalah lisensi, dan pengguna yang peduli pada perbedaan ini kemungkinan sedikit
      Pengguna seperti itu tinggal memasang rsync sendiri
    • Saya bisa menemukan daftar argumen yang diterima openrsync di kode sumbernya
      --xattrs, --acls, --hard-links yang dipakai di alias semuanya tidak ada
      [0]https://github.com/kristapsdz/openrsync/blob/a257c0f495af2b5...

  • Sebagai pengguna Linux yang relatif baru, manajemen versi utilitas sistem bawaan terasa cukup berantakan
    Contoh utamanya adalah unzip: unzip bawaan di server Debian dan server Ubuntu lama tidak bisa menangani ZIP yang dienkripsi dengan AES-256, tetapi dari Stack Overflow tampaknya beberapa distro sudah memperbaruinya agar mendukung hal itu
    Masalahnya, unzip yang sudah diperbarui sulit ditemukan dengan mudah, semuanya mengaku sebagai “version 6.00” tetapi perilaku nyatanya berbeda, dan meskipun menemukannya pun saya tidak tahu apakah aman mengganti paket bawaan sistem
    Pada akhirnya, meski seseorang menambahkan fitur bagus ke utilitas yang banyak dipakai, kita tetap tidak bisa memakainya; karena itu utilitas sistem inti, rasanya malah lebih sulit diperbarui dibanding alat pihak ketiga
    Windows atau macOS mungkin serupa atau bahkan lebih buruk dalam hal utilitas sistem, tetapi saya mengira Linux akan menangani hal semacam ini dengan lebih baik

    • Dalam kasus ini, sebaiknya gunakan 7z alih-alih unzip
      Di Linux, saya hampir tidak ingat pernah memakai unzip saat menangani ZIP atau berkas arsip secara umum
      Mengikuti filosofi Unix, alur seperti menggabungkan dengan tar, mengompresi dengan gzip, lalu mengenkripsi dengan pgp—menghubungkan alat-alat sederhana yang melakukan satu pekerjaan dengan baik lewat pipe—juga terasa alami
      Untuk soal versi, saya tidak yakin mengapa Debian/Ubuntu sama-sama menyebutnya 6.00, tetapi itu bukan hal yang umum
      Untuk mesin pribadi, distro rolling release seperti Arch atau Manjaro mengikuti versi upstream dengan lebih konsisten, tetapi beban pemeliharaan dan ekspektasi untuk mengelolanya sendiri menjadi lebih besar
      Hal yang lebih merepotkan dalam manajemen versi Linux/open source adalah pustaka-pustaka yang terlalu lama menunda deklarasi v1.00
      Meski sudah banyak tertanam di ekosistem, stabil, dan fiturnya hampir lengkap, mereka tetap bertahun-tahun berada di v0.2 atau v0.68 sehingga membingungkan pemula
    • Debian dan Ubuntu cenderung mengikat versi alat sistem pada versi rilis sistem operasi
      Debian memiliki siklus rilis yang panjang tetapi sangat stabil, dan di stable semuanya berjalan serasi
      Ubuntu pada dasarnya terasa seperti Debian ditambah “bagaimana kalau rilis lebih sering?”
      Jika menginginkan alat terbaru, harus menerima pilihan yang mungkin kurang stabil seperti Nix atau Arch, dan keduanya tidak terlalu ramah
      Jika ingin stabilitas sekaligus alat terbaru, Gentoo bisa menjadi cara, tetapi bebannya bahkan lebih besar daripada Arch
      Jika menginginkan stabilitas dan kesederhanaan, Anda bisa mengorbankan ruang disk dengan pendekatan seperti Docker/podman, flatpak, appcontainers, atau snap
      Windows dan Mac juga punya masalah yang sama, dan Windows selama ini menanganinya dengan menyertakan pustaka-pustaka lama lalu melakukan dynamic linking sesuai aplikasi yang sedang berjalan
    • unzip adalah kasus khusus
      Pengembangan upstream pada dasarnya terhenti, dan rilis terakhirnya adalah 6.0 pada 2009
      Setelah itu, berbagai masalah ditemukan dan fiturnya makin kurang memadai, sehingga tiap distro menumpuk banyak patch di atas rilis tersebut; hasilnya, muncul executable yang sangat berbeda meski memiliki nomor versi yang sama
      [0]: https://infozip.sourceforge.net/UnZip.html
      [1]: Dari resep build Arch, Anda bisa melihat jumlah patch yang diterapkan: https://gitlab.archlinux.org/archlinux/packaging/packages/un...
    • Distro adalah proyek independen, jadi perbedaan seperti itu wajar diperkirakan
      Interoperabilitas sampai tingkat tertentu memang bagus, tetapi banyaknya pilihan juga merupakan kelebihan
      Sebagian besar repositori distro memiliki bsdtar, jadi layak dicoba sebagai pengganti; tergantung distronya, nama paketnya bisa saja libarchive
      Dengan bsdtar xf path/to/file saja, hampir semua format bisa diekstrak, dan AES pada ZIP juga didukung
      Di macOS ini disertakan secara default, dan kemungkinan juga disertakan di Windows
    • Memang berantakan, dan sebaiknya kurangi ketergantungan pada alat bawaan sebisa mungkin
      Untuk setiap pekerjaan, buat repositori git dan flake.nix, lalu biarkan direnv mengaktifkan lingkungan yang dideklarasikan dalam flake saat masuk ke direktori tersebut
      Jika menulis skrip yang memakai grep, masukkan skrip itu ke repositori dan tambahkan juga pkgs.gnugrep ke flake.nix
      Dengan begitu, yang digunakan adalah versi yang dideklarasikan, bukan versi sistem; saat berpindah dari macOS ke Linux atau WSL pun, versi grep yang dipanggil tetap sama
      Nix sering dinilai tidak ramah bagi pemula, jadi saya berhati-hati untuk merekomendasikannya begitu saja, tetapi intinya adalah mendeklarasikan dependensi dengan cara apa pun dan hanya memakai dependensi yang sudah dideklarasikan
      Docker juga bisa, dan ekosistem bahasa seperti Python/Node.js/Go/Rust juga menyediakan cara untuk membundel dan memanggil dependensi
      Dengan cara ini, pembaruan dependensi tercatat sebagai commit, sehingga ketika ada sesuatu yang rusak, Anda bisa kembali ke commit sebelumnya
      Repositori seperti ini tidak harus berupa proyek perangkat lunak; bisa saja berupa “kumpulan alat yang diperlukan saat melakukan XYZ”

  • Agak merepotkan bahwa openrsync tidak mendukung sebagian fitur rsync
    Namun tetap bagus bahwa sekarang ada beberapa implementasi independen rsync
    Karena itu berarti rsync diperlakukan bukan sebagai perangkat lunak sederhana, melainkan seperti protokol sungguhan

    • Poin ini membuat saya antusias
      Jika makin mendekati protokol, rasanya bisa muncul titik API diff biner berbasis algoritma rsync
      Fakta menariknya, Dropbox secara internal memakai diff biner rsync untuk mengunggah perubahan kecil pada file besar dengan cepat
      Saya kira sampai sekarang pun begitu, tetapi endpoint API publiknya tidak punya fitur ini, jadi meski hanya ada perubahan kecil pada file besar, seluruh file harus diunggah ulang
    • Jika melihat http://github.com/stapelberg/rsync-over-grpc/, ada contoh penggunaan protokol rsync, tepatnya implementasi https://github.com/gokrazy/rsync, di atas gRPC
      Ini cukup berguna di lingkungan perusahaan ketika SSH+rsync diblokir, tetapi pembuatan layanan gRPC diizinkan
    • Di situs webnya tertulis “We are still working on it... so please wait.”
      rsync punya banyak fitur, jadi memang pasti butuh waktu cukup lama
    • Ada juga librsync
    • Saya penasaran mengapa ini berarti rsync adalah protokol

  • Pada patch rsync mainline, dukungan extended attributes ditambahkan untuk mendukung metadata macOS
    “Carbon Copy Cloner” dari Bombich adalah aplikasi GUI yang membungkusnya
    https://support.bombich.com/hc/en-us/articles/20686446501143...
    Mike Bombich dikenal lewat tulisan di papan administrator sistem macOS Server, dan ada juga materi terkait
    https://web.archive.org/web/20140707182312/http://static.afp...
    Nathaniel Gray membuat Backup Bouncer, yang memverifikasi fidelitas backup termasuk multi-stream, extended attributes, ACL, dan sebagainya
    https://github.com/n8gray/Backup-Bouncer
    Ada juga RsyncX, aplikasi SwiftUI yang membungkus rsync
    https://github.com/rsyncOSX/RsyncOSX
    Pada masa ketika perangkat lunak macOS “Classic” dijalankan di atas sistem UNIX baru, hal-hal seperti ini benar-benar dianggap penting
    https://web.archive.org/web/20161022012615/http://blog.plast...

    • Masalah rsync adalah sangat tidak masuk akal lambatnya
      IFileOperation (Windows) dan FileManager (macOS) melakukan penyalinan dengan performa terbaik yang didukung filesystem underlying
      Pada SMB dan ReFS, pemeriksaan CRC setara fitur checkbox, dan pada share SMB modern di Windows Server modern, tahap pencocokan konten rsync menjadi pekerjaan duplikatif
      Antara sesama Windows, throughput IFileOperation 1,5–8 kali lebih cepat daripada rsync dan penggunaan CPU-nya juga lebih rendah; bahkan bisa 1,2–3 kali lebih cepat daripada penyalinan file Go biasa
      Jika hanya melihat Linux tanpa memedulikan sistem operasi yang benar-benar memakai metadata filesystem kompleks, openrsync atau program yang lebih sederhana sudah cukup

  • Saya penasaran apakah ada materi yang menjelaskan dengan baik mengapa Apple begitu takut pada GPLv3
    Rasanya kalau executable dikompilasi secara statis, seharusnya tidak menjadi masalah

    • GPLv3 menutup celah ketika sebuah produk turunan dari kode GPL merilis source-nya, tetapi membuat pengguna tidak bisa benar-benar membangun dan menjalankan source tersebut di perangkatnya
      Saat itu TiVo melakukan hal seperti itu, sehingga disebut tivoization
      Di iOS, alasan tidak memakai GPLv3 jelas, karena akan melanggar ketentuannya
      macOS mungkin bisa memuat kode GPLv3, tetapi Apple banyak berbagi kode antara iOS/macOS/watchOS/tvOS/visionOS, jadi tidak banyak artinya jika hanya satu sistem operasi berbasis GPLv3 sementara yang lain tidak
      Lebih sederhana untuk sama sekali tidak memakainya
      Selain itu, jika di masa depan macOS makin mengunci eksekusi kode pengguna, mereka tidak perlu khawatir harus mencabut kode GPLv3 saat itu
    • Pandangan saya tentang GPL dan lisensi terkait banyak berubah setelah bekerja dengan para pengacara
      Hal-hal yang saya kira sepenuhnya aman pun, dari sudut pandang pengacara, ternyata tidak bisa dinyatakan setegas itu
      Saya tidak tahu alasan Apple, tetapi para pengacara korporat di perusahaan lain memberi prinsip untuk memilih lisensi non-GPL jika memungkinkan
    • Kemungkinan besar mereka hanya ingin menghindari situasi harus memperdebatkan GPLv3 di pengadilan, dan mungkin kalah
      Jika melihat riwayat putusan terkait GPLv2, hasil yang didapat tampak kecil dibanding upaya yang diperlukan
      Dari sudut pandang Apple, jika bagian yang terlihat sebagai “masalah” cukup diganti, mereka bisa menghindari seluruh kategori masalah itu
    • Apple jelas menentang hak pengguna, dan GPL adalah lisensi yang justru berusaha melindungi hak tersebut
      Isu teknis detailnya mungkin menarik, tetapi menurut saya bukan intinya
    • Apple tidak menyampaikan alasannya
      Sebaiknya jangan terlalu percaya pada penjelasan orang lain tentang niat Apple

  • Saat menulis sendiri implementasi https://github.com/gokrazy/rsync dalam Go, saya melihat openrsync, dan kodenya bagus
    Namun sayangnya openrsync tidak 100% kompatibel dengan rsync
    Saya baru tahu Apple mulai beralih ke openrsync ketika pengujian saya rusak di macOS 15

  • Tertulis bahwa openrsync ditulis sebagai bagian dari proyek rpki-client(1), validator RPKI untuk OpenBSD, dan didanai oleh NetNod, IIS.SE, SUNET, serta 6connect; saya penasaran mengapa organisasi-organisasi ini mendanai pengembangan tersebut
    https://github.com/kristapsdz/openrsync?tab=readme-ov-file#p...

    • Alasan keberadaannya dijelaskan cukup baik oleh komentar ini
      https://news.ycombinator.com/item?id=43605846
      Perusahaan mendanai hal-hal yang berguna atau mereka butuhkan
      Sebagian perusahaan dalam daftar itu mungkin menggunakan BSD, dan kemungkinan menginginkan atau membutuhkan implementasi rsync yang bukan GPLv3
      Atau bisa saja mereka sekadar tertarik mensponsori proyek dan pengembangan open source

  • Untuk sementara hingga Sequoia 15.3, rsync_samba dan rsync_openrsync sama-sama bisa digunakan melalui /var/select/rsync atau variabel lingkungan CHOSEN_RSYNC
    Hal yang sangat menjengkelkan dari openrsync adalah klaimnya mendukung elemen path ajaib /./ untuk --relative
    Karena masalah ini, sekitar sebulan lalu saya mengirim laporan bug ke Apple
    Sejak Sequoia 15.4, rsync_samba sudah hilang, dan saya memasang rsync lewat Homebrew

  • Baru-baru ini saya mengalami masalah ini: saat membuat .ipa iOS dengan xcodebuild dari command line, tampaknya secara internal ia memanggil rsync untuk menyalin file antar direktori lokal
    Namun karena Homebrew rsync berada lebih dulu di $PATH, itulah yang dijalankan, sementara xcodebuild meneruskan argumen khusus openrsync, --extended-attributes
    Homebrew rsync tidak memahami argumen itu, sehingga gagal dan keluar

  • Saya tetap senang Apple tidak secara bertahap menyingkirkan sisi POSIX untuk membuat osx menjadi seperti iOS, melainkan terus memperbaiki dan menerimanya