- macOS’e yerleşik dosya senkronizasyon aracı 2006 tabanında kalmışken, Apple rsync 2.6.9 yerine openrsync kullanmaya başladı
- Mevcut macOS rsync’i güvenlik ve diğer sorunlar için gerekli düzeltmeleri almış olsa da, 2.6.9 sonrasındaki rsync 3.x özelliklerini içermiyordu
- Geçişin temel nedeni lisans farkı: rsync 2.x GPLv2, rsync 3.x ise GPLv3 altında dağıtılıyor
- openrsync, rsync ile uyumlu olsa da komut satırı argümanlarının yalnızca bir kısmını destekliyor; bu nedenle mevcut betikler Sequoia’da olduğu gibi çalışmayabilir
- macOS 15.4 itibarıyla
/usr/bin/rsync, openrsync’e işaret ediyor; bu yüzden Mac yöneticilerinin desteklenen seçenekleri ve mevcut otomasyonlarının uyumluluğunu kontrol etmesi gerekiyor
macOS’te uzun süre kalan rsync 2.6.9
- rsync, Unix benzeri işletim sistemlerinde dosya aktarmak ve senkronize etmek için kullanılan bir komut satırı aracıdır
- Aynı bilgisayara doğrudan bağlı depolama aygıtları arasında kullanılabilir
- Ağ üzerindeki başka bilgisayarlarla dosya senkronizasyonu için de kullanılabilir
- macOS uzun süredir rsync içeriyordu, ancak Apple’ın sunduğu sürüm rsync 2.x’in son sürümü olan rsync 2.6.9’du
- rsync 2.6.9 Kasım 2006’da yayımlandı ve Apple, rsync 3.x çıktıktan sonra bile macOS’teki rsync’i daha yeni bir sürüme yükseltmedi
- Apple, macOS’e dahil edilen rsync 2.6.9 için güvenlik sorunları ve diğer problemler adına gerekli güncellemeleri yaptı
- Ancak macOS Sequoia’ya kadar Apple’ın rsync’i neredeyse 20 yıllık bir temel üzerinde kalmıştı ve 2.6.9’dan sonra rsync sürümlerine eklenen yeni özellikleri içermiyordu
GPLv2 ve GPLv3’ün yarattığı sürüm tıkanması
- rsync 2.x ve 3.x, farklı GPL lisans sürümleri altında dağıtılıyor
- Apple, rsync 2.x’in GPLv2 koşullarına uyabileceğini, ancak rsync 3.x’in GPLv3 koşullarına uyamayacağını değerlendirdi
- Bu nedenle macOS’te rsync 3.x sunulmadı
macOS Sequoia’da openrsync’e geçiş
- Apple, macOS Sequoia ile rsync 2.6.9’u openrsync ile değiştirdi
- openrsync, GPL lisansı kullanmayan bir rsync uygulamasıdır
- openrsync, BSD ailesi lisanslardan biri olan ISC license altında dağıtılır
- ISC license, izin verici bir lisanstır (permissive license) ve bu lisansla sunulan yazılımın kullanımı, değiştirilmesi ve dağıtımı üzerinde asgari düzeyde kısıtlama getirir
- Apple, rsync 3.x’in GPLv3 koşullarının aksine openrsync’in lisans koşullarına uyabileceğini değerlendirdi
Mac yöneticileri için önemli uyumluluk farkı
- Apple bundan sonra rsync’in GPL uyumluluğu sorunları konusunda endişe duymadan openrsync’in güncel sürümlerini sunabilir
- Daha büyük pratik değişim ise, openrsync rsync ile uyumlu olsa da rsync komut satırı argümanlarının yalnızca bir kısmını desteklemesi
- Mevcut macOS’te çalışan rsync işlevleri macOS Sequoia’da başarısız olabilir
- Çünkü ilgili işlev, Sequoia ile gelen openrsync komut satırı aracında bulunmayabilir
- macOS Sequoia’daki openrsync’in desteklediği özellikler openrsync kılavuz sayfasında görülebilir
macOS 15.4’te nasıl kontrol edilir
- macOS 15.4 itibarıyla openrsync aracı
/usr/bin/rsync yoluna bağlanmış durumda
- Kullanıcılar, daha önce rsync komut satırı aracını çalıştırır gibi openrsync’i çalıştırabilir
- openrsync sürüm bilgisi şu komutla kontrol edilebilir
/usr/bin/rsync --version
username@computername ~ % /usr/bin/rsync --version
openrsync: protocol version 29
rsync version 2.6.9 compatible
username@computername ~ %
- Çıktıda protocol version 29 ve rsync version 2.6.9 compatible bilgileri gösterilir
1 yorum
Hacker News yorumları
openrsync’in dokümantasyonu o kadar yetersiz ki, rsync’in yerini alabileceğine dair güven vermiyor
Bir dosya kopyalama programı, kaynağın verilerini ve metadata’sını tek bir bit bile kaybetmeden eksiksiz bir kopya oluşturabilmeli; bunu yapamıyorsa kullanılamaz seviyede olduğunu düşünüyorum
Unix türevi birçok kopyalama/arşivleme aracı varsayılan seçeneklerle eksiksiz kopya oluşturamıyor; bazı araçlarda ise hangi seçenek kullanılırsa kullanılsın bu mümkün değil
scp de en azından birkaç yıl öncesine kadar işletim sistemi veya dosya sistemi farklı olduğunda eksiksiz kopyalama konusunda zorlandığı için onu kullanmadım; yalnızca ssh üzerinden rsync kullandım
rsync, uygun seçenekler verildiğinde FreeBSD UFS ile Linux XFS arasında olduğu gibi farklı işletim sistemi/dosya sistemi kombinasyonlarında bile extended attributes, ACL’ler ve yüksek hassasiyetli timestamp’leri koruyabilen nadir araçlardan biri
openrsync dokümantasyonu bu tür eksiksiz kopyalamayı garanti etmediği için, şimdilik bunu yapamadığını varsayıyor ve işe yaramaz buluyorum
Arşiv tarafında, Linux’ta bsdtar pax formatını kullandığında neredeyse eksiksiz bir dosya kopyasını saklayabiliyor; eski tar/cpio formatları ise modern metadata’yı barındıramıyor
Normalde rsync’i
/usr/bin/rsync --archive --xattrs --acls --hard-links --progress --rsh="ssh -p XXX -l YYYYYYY"şeklinde alias olarak kullanıyorumcoreutils’in
cpkomutu da doğru CLI seçenekleri ve derleme seçenekleriyle eksiksiz kopya oluşturabiliyor; ancak bazı dağıtımlar extended attribute desteği olmadan derlediği için uyarı veya hata vermeden yalnızca kısmi kopya yapıyorBiz her şeyi çok dikkatli biçimde geri yüklüyoruz, ama bazen bunu sadece biz önemsiyormuşuz gibi geliyor
Temelde openrsync’i lisans kısıtları daha az olan rsync olarak düşünürüm; farklı davrandığını varsaymam
openrsync README’sinde rsync ile uyumlu olduğu ve rsync dokümantasyonuna bakılması gerektiği yazıyor
Extended attributes, ACL’ler ve yüksek çözünürlüklü timestamp’ler protokol seviyesinde isteğe bağlı özellikler değilse, uyumluluk iddiası için modern rsync’in desteklediği her şeyi desteklemesi gerekmez mi diye düşünüyorum
Yoksa tüm protokolü kabul edip ACL gibi şeyleri basitçe çöpe atmak anlamına mı geliyor, merak ediyorum
Ancak resmi web sitesinde de “We are still working on it... so please wait.” yazıyor
Böyle kullanıcılar zaten rsync’i kurabilir
Alias’ta kullandığım
--xattrs,--acls,--hard-linksseçeneklerinin hepsi eksik[0]https://github.com/kristapsdz/openrsync/blob/a257c0f495af2b5...
Nispeten yeni bir Linux kullanıcısı olarak, birlikte gelen sistem yardımcı araçlarının sürüm yönetimi bana epey dağınık görünüyor
Tipik bir örnek
unzip: Debian sunucusu ve eski Ubuntu sunucusuyla birlikte gelenunzip, AES-256 ile şifrelenmiş ZIP dosyalarını işleyemiyordu; Stack Overflow’a bakınca bazı dağıtımların bunu destekleyecek şekilde güncellediği anlaşılıyorSorun şu ki güncellenmiş
unzipi bulmak kolay değil; hepsi “version 6.00” olduğunu iddia ediyor ama gerçek davranışları farklı, bulsam bile sistemle gelen sürümü değiştirmek güvenli mi bilmiyorumSonuçta birisi yaygın kullanılan bir yardımcı araca iyi bir özellik eklemiş olsa bile hâlâ kullanamıyorum; çekirdek sistem aracı olduğu için üçüncü taraf araçlara göre güncellemesi daha da zorlaşmış gibi hissettiriyor
Windows veya macOS de sistem yardımcı araçları açısından benzer, hatta daha kötü olabilir; ama Linux’un bu işi daha iyi yöneteceğini sanmıştım
unzipyerine 7z kullanmak daha iyiLinux’ta ZIP ya da genel olarak arşiv dosyalarıyla uğraşırken
unzipkullandığımı pek hatırlamıyorumUnix felsefesine göre tar ile paketleyip gzip ile sıkıştırıp pgp ile şifrelemek gibi, tek işi iyi yapan basit araçları pipe’larla birbirine bağlamak da doğal bir akış
Sürüm tarafında Debian/Ubuntu’nun ikisinin de neden 6.00 dediğinden emin değilim ama bu genel bir durum değil
Kişisel cihazda Arch veya Manjaro gibi rolling release dağıtımlar upstream sürümleri daha düzenli takip eder, fakat bakım yükü ve bizzat yönetmeniz gereken beklenti artar
Linux/açık kaynak sürüm yönetiminde daha rahatsız edici nokta, kütüphanelerin v1.00 ilanını aşırı geciktirmesi
Ekosisteme yaygın biçimde yerleşmiş, stabil ve işlevleri de neredeyse tamamlanmış olsalar bile yıllarca v0.2 ya da v0.68 durumunda kalıp yeni başlayanların kafasını karıştırıyorlar
Debian’ın yayın döngüsü uzun ama çok stabil; stable’da her şey birbiriyle uyumlu çalışır
Ubuntu temelde Debian’a “daha sık yayınlansa nasıl olur?” fikrinin eklenmiş hali gibi
En yeni araçları istiyorsanız Nix veya Arch gibi daha az stabil olabilecek seçenekleri göze almanız gerekir; ikisi de çok kullanıcı dostu sayılmaz
Hem stabilite hem güncel araçlar istiyorsanız Gentoo bir yol, ama Arch’tan bile daha zahmetli
Stabilite ve basitlik istiyorsanız disk alanından feragat ederek Docker/podman, flatpak, appcontainers, snap gibi yöntemleri kullanabilirsiniz
Windows ve Mac’te de aynı sorun var; Windows bunu eski kütüphaneleri birlikte taşıyıp çalışan uygulamaya göre dinamik linkleme yaparak çözegeldi
unzipözel bir vakaUpstream geliştirme fiilen durmuş durumda ve son sürüm 2009’daki 6.0
Sonrasında çeşitli sorunlar bulunup özellikler yetersiz kalınca her dağıtım bu sürümün üzerine bir sürü patch ekledi; sonuçta aynı sürüm numarasına sahip, birbirinden çok farklı çalıştırılabilir dosyalar ortaya çıktı
[0]: https://infozip.sourceforge.net/UnZip.html
[1]: Arch derleme tarifine bakarsanız uygulanan patch sayısını görebilirsiniz: https://gitlab.archlinux.org/archlinux/packaging/packages/un...
Bir ölçüde birlikte çalışabilirlik iyidir, ama farklı seçeneklerin olması da avantaj
Çoğu dağıtım deposunda bsdtar var; onun yerine onu denemeye değer, dağıtıma göre paket adı libarchive olabilir
bsdtar xf path/to/fileile neredeyse her formatı açabilirsiniz ve ZIP’te AES’i de desteklermacOS’te varsayılan olarak var, Windows’ta da muhtemelen bulunuyordur
Yaptığım her iş için bir git deposu ve
flake.nixoluşturuyorum; direnv de o dizine girildiğinde flake’te tanımlanan ortamı etkinleştiriyorgrepkullanan bir script yazarsam script’i depoya koyuppkgs.gnugrepi deflake.nixe ekliyorumBöylece sistem sürümü değil, tanımlanmış sürüm kullanılıyor; macOS’ten Linux’a veya WSL’ye geçsem de aynı grep sürümü çağrılıyor
Nix’in yeni başlayanlara pek dostça olmadığı sık söyleniyor, bu yüzden doğrudan önermekte temkinliyim; ama esas nokta bağımlılıkları bir şekilde beyan etmek ve yalnızca beyan edilen bağımlılıkları kullanmak
Docker da olabilir; Python/Node.js/Go/Rust gibi dil ekosistemleri de bağımlılıkları paketleyip çağırmanın yollarını sunuyor
Böylece bağımlılık güncellemeleri commit olarak kalır; bir şey bozulduğunda önceki commit’e dönebilirsiniz
Böyle bir deponun illa bir yazılım projesi olması gerekmez; “XYZ yaparken gereken araçlar seti” de olabilir
openrsync’in rsync’in bazı özelliklerini desteklememesi biraz can sıkıcı
Yine de artık rsync’in bağımsız uygulamalarının birden fazla olması iyi bir şey
Çünkü bu, rsync’in basit bir yazılım değil, fiilen bir protokol gibi ele alındığı anlamına geliyor
Protokole yaklaştıkça rsync algoritması tabanlı bir ikili fark API’si noktası da ortaya çıkabilir gibi görünüyor
İlginç bir bilgi olarak, Dropbox geçmişte büyük dosyalardaki küçük değişiklikleri hızlıca yüklemek için içeride rsync ikili farklarını kullanıyordu
Hâlâ böyle yaptığını düşünüyorum, ancak herkese açık API endpoint’inde bu özellik olmadığı için büyük bir dosyada yalnızca küçük bir değişiklik olsa bile tüm dosyayı yeniden yüklemek gerekiyor
Kurumsal ortamlarda SSH+rsync engellenmişken gRPC servisi kurmaya izin verildiğinde oldukça işe yarıyor
rsync’in çok fazla özelliği olduğundan bu işin epey zaman alması kaçınılmaz
Ana hat rsync yamasına macOS metadata desteği için genişletilmiş öznitelik desteği eklenmişti
Bombich’in “Carbon Copy Cloner”ı bunun etrafına sarılmış bir GUI uygulaması
https://support.bombich.com/hc/en-us/articles/20686446501143...
Mike Bombich’i macOS Server sistem yöneticileri panosundaki yazılardan öğrenmiştim; ilgili materyaller de var
https://web.archive.org/web/20140707182312/http://static.afp...
Nathaniel Gray, çoklu stream, genişletilmiş öznitelikler, ACL’ler vb. dahil yedeklemenin doğruluğunu doğrulayan Backup Bouncer’ı geliştirmişti
https://github.com/n8gray/Backup-Bouncer
rsync’i sarmalayan SwiftUI uygulaması RsyncX de var
https://github.com/rsyncOSX/RsyncOSX
Yeni UNIX sistemi üzerinde “Classic” macOS yazılımlarının çalıştırıldığı dönemlerde bunlara gerçekten çok önem verilirdi
https://web.archive.org/web/20161022012615/http://blog.plast...
IFileOperation(Windows) ve FileManager(macOS), alttaki dosya sisteminin desteklediği en yüksek performanslı kopyalamayı gerçekleştirir
SMB ve ReFS’te CRC denetimi bir onay kutusu düzeyindedir; modern Windows Server’daki modern SMB paylaşımlarında rsync’in içerik eşleştirme aşaması mükerrer iştir
Windows’tan Windows’a IFileOperation, rsync’ten 1,5 ila 8 kat daha yüksek aktarım hızı sağlar ve CPU kullanımı daha düşüktür; sıradan Go dosya kopyalamasından da 1,2 ila 3 kat daha hızlı olabilir
Karmaşık dosya sistemi metadatasını gerçekten kullanan işletim sistemlerini önemsemeyip yalnızca Linux’a bakarsanız openrsync ya da daha basit bir program yeterlidir
Apple’ın GPLv3’ten neden bu kadar korktuğunu iyi açıklayan bir kaynak var mı merak ediyorum
Çalıştırılabilir dosyayı statik olarak derlemek sorun olmamalıymış gibi geliyor
O dönemde TiVo bunu yaptığı için buna tivoizasyon deniyordu
iOS’ta GPLv3 kullanılmamasının nedeni açık: koşullar ihlal edilmiş olurdu
macOS’a GPLv3 kodu koymak mümkün olabilir, ancak Apple iOS/macOS/watchOS/tvOS/visionOS arasında çok fazla kod paylaştığından yalnızca bir işletim sisteminde GPLv3 tabanına dayanıp diğerlerinde kullanmamak pek anlamlı değil
Hiç kullanmamak daha basit
Ayrıca gelecekte macOS’ta kullanıcı kodu çalıştırmayı daha da kilitlese bile, o zaman GPLv3 kodunu söküp çıkarma derdi olmaz
Tamamen güvenli sandığım şeyler bile avukatlar açısından o kadar kesin değildi
Apple’ın gerekçesini bilmiyorum, ancak başka şirketlerdeki şirket avukatları mümkün olduğunca GPL dışı lisansları seçme prensibini veriyordu
GPLv2 ile ilgili içtihat geçmişine bakınca harcanan emeğe kıyasla elde edilen şey az görünüyor
Apple açısından “sorun” gibi görünen kısmı basitçe değiştirirse, sorun kategorisinin tamamından kaçınabilir
Ayrıntılı teknik meseleler ilginç olabilir ama bence işin özü onlar değil
Apple’ın niyetlerine dair başkalarının açıklamalarına inanmamak daha iyi
Go ile doğrudan https://github.com/gokrazy/rsync uygulamasını yazarken openrsync’e bakmıştım; kodu iyiydi
Ancak openrsync’in rsync ile %100 uyumlu olmaması üzücü
macOS 15’te testlerim bozulunca Apple’ın openrsync’e geçmeye başladığını fark ettim
openrsync’in OpenBSD için bir RPKI doğrulayıcısı olan rpki-client(1) projesinin parçası olarak yazıldığı ve NetNod, IIS.SE, SUNET, 6connect tarafından finanse edildiği söyleniyor; bu kuruluşların bu geliştirmeyi neden finanse ettiğini merak ediyorum
https://github.com/kristapsdz/openrsync?tab=readme-ov-file#p...
https://news.ycombinator.com/item?id=43605846
Şirketler faydalı ya da gerekli olan şeyleri finanse eder
Listedeki bazı şirketler BSD kullanıyor olabilir ve GPLv3 olmayan bir rsync uygulaması istemiş ya da buna ihtiyaç duymuş olabilir
Ya da sadece açık kaynak projeleri ve geliştirmeyi desteklemeye ilgi duymuş olabilirler
Bir süre Sequoia 15.3’e kadar
/var/select/rsyncveyaCHOSEN_RSYNCortam değişkeni üzerinden hem rsync_samba hem de rsync_openrsync kullanılabiliyorduopenrsync’in özellikle can sıkıcı yanı,
--relativeiçin/./sihirli yol bileşenini desteklediğini iddia etmesiydiBu sorun için yaklaşık bir ay önce Apple’a hata raporu gönderdim
Sequoia 15.4’ten itibaren rsync_samba ortadan kalktı; ben de rsync’i Homebrew ile kurulu tutuyorum
Yakın zamanda bu sorunla karşılaştım: komut satırında
xcodebuildile iOS.ipaoluşturduğunuzda, içeride rsync’i çağırıp yerel dizinler arasında dosya kopyalıyor gibi görünüyorAncak
$PATHiçinde Homebrew rsync önde olduğu için onu çalıştırdı vexcodebuild, openrsync’e özgü bir argüman olan--extended-attributes’ı geçtiHomebrew rsync bu argümanı anlamadığı için başarısız olup çıktı
Apple’ın osx’i iOS gibi yapmaya çalışarak POSIX tarafını yavaş yavaş ortadan kaldırmaması, bunun yerine geliştirmeye ve benimsemeye devam etmesi hâlâ sevindirici