FreeBSD geliştirmesi için bir yıllık sponsorluk
(daemonology.net)- FreeBSD/EC2 bakımı ile sürüm mühendisliği, tek bir kişinin gönüllü zamanı içinde çakışırken Amazon’un bir yıllık sponsorluğu sürüm operasyonları ile EC2 platform iyileştirmelerini aynı anda mümkün kıldı
- Sponsorluk, GitHub Sponsors üzerinden nominal olarak aylık 40 saat ölçeğindeydi ancak fiili çalışma ortalama ayda 50 saat oldu; bu süre kabaca EC2 sorunları, sürüm ilerletme ve diğer sürüm mühendisliği işleri arasında 20/20/10 saat olarak bölündü
- Bir yıl boyunca FreeBSD 13.4, 14.2, 13.5 ve 14.3 sürümlerini yönetirken AWS Graviton için güç kapatma sinyali işleme ve EC2 aygıt hot-plug gibi öncelikli işler de paralel yürütüldü
- Önyükleme performansı regresyonlarını yakalamak için 2018’den bu yana haftalık EC2 AMI derlemeleri benchmark edildi; kök disk boyutu, EFI entropy seeding, ZFS transaction group ve IMDSv2 IPv6 değişikliğindeki gecikme nedenleri bulunup düzeltildi
- Sponsorluk bittikten sonra da roller sürecek, ancak sürüm öncesi sorunları doğrudan düzeltmek veya EC2 özellik listesini sürekli ileri taşımak için ayrılabilecek zaman azalacak
Sponsorluk öncesi darboğazlar ve zaman dağılımı
- FreeBSD/EC2 bakımı, 2010’da Amazon EC2 üzerinde FreeBSD’yi ilk kez önyükledikten sonra devam etti ve Kasım 2023’te buna FreeBSD sürüm mühendisliği lideri rolü de eklendi
- Antithesis ve FreeBSD/EC2 Patreon’dan gelen küçük sponsorluklar, bu iki rolü taşımaya yetmiyordu
- Uygulanacak özellik listesi tıkanmıştı
- Anormallikler fark edilse bile inceleyecek zaman olmadığından erteleme giderek arttı
- 2024 başında FreeBSD/EC2 platformunun “iyi sahibi” olmanın zorlaştığı yönündeki kaygı büyüdü
- Nisan 2024’te Amazon’da bütçesi olan doğru kişiyi bulunca takvim, kapsam ve süreç üzerine görüşmeler yapıldı ve Amazon’un GitHub Sponsors üzerinden bir yıllık sponsorluk sağlamasına karar verildi
- Sponsorluk hedefi, FreeBSD sürüm mühendisliği ile FreeBSD/EC2 geliştirmesini birlikte kapsayan aylık 40 saatlik bir ölçekti
- İki işin birbirine bağımlı olduğu, bu yüzden yalnızca birini fonlamanın gerçekçi olmadığı iletildi
- Fiili harcanan süre ortalama ayda yaklaşık 50 saate çıktı
- Ortalama olarak ayda EC2’ye özgü sorunlara 20 saat, FreeBSD sürüm ilerletmeye 20 saat, diğer sürüm mühendisliğiyle ilgili işlere 10 saat ayrıldı; ancak aylık sapma yüksekti
Üç aylık sürüm operasyonu ve derleme iyileştirmeleri
- Temmuz 2024’te duyurulan FreeBSD üç aylık sürüm takvimi doğrultusunda bir yıl içinde 4 sürüm yönetildi
- FreeBSD 13.4: Eylül 2024
- FreeBSD 14.2: Aralık 2024
- FreeBSD 13.5: Mart 2025
- FreeBSD 14.3: 10 Haziran 2025’te yayımlanması planlanıyor
- Her sürüm; kod birleştirmelerini teşvik etmeyi, merge isteklerini onaylama/reddetmeyi, diğer ekiplerle koordinasyonu, imaj derleme ve testlerini, duyuru metni yazımını ve sürüm derleme sorunlarını düzeltmeyi içeriyordu
- Genellikle 3 Beta, 1 Release Candidate ve nihai Release derleniyordu
- İşlerin çoğu sürümden önceki ayda, yani her çeyreğin ikinci ayı olan “Beta Month” döneminde yoğunlaşıyordu
- FreeBSD 13.5, 33,5 saat; FreeBSD 14.2 ise 79 saat sürdü
- Stable branch ilerledikçe bozulan öğe sayısı azaldığından sürüm iş yükü de düşme eğilimindeydi
- FreeBSD 14.1 izlenmedi, ancak sürüm mühendisliği süresinin 100 saate yakın olduğu tahmin ediliyor; FreeBSD 15.0’ın ise bunun çok üstüne çıkması muhtemel
- Genel sürüm mühendisliğinde sürüm derlemelerini paralelleştirme de yapıldı
- EC2 AMI sayısı arttıkça, asıl derlemeden çok VM imajlarına FreeBSD kurma süresi baskın hale geldi
- Sürüm kodu paralelleştirildi ancak aralıklı derleme hataları ortaya çıktı ve tüm sürüm derlemesi yaklaşık 24 saat sürdüğü için kök nedeni ayırmak zordu
- Nihai neden, dosyaları kurmadan önce dizin oluşturan Makefile satırlarından birinin eksik olmasıydı
- Düzeltmeden sonra sürüm derleme süresi yaklaşık 22 saatten 13 saate indi ve derleme süresi yüzünden ertelenen EC2 AMI flavour genişletmesi de mümkün hale geldi
- Derleme yeniden üretilebilirliği sorunları, EC2 kullanılarak düzenli biçimde kontrol edilmeye başlandı
- Haftalık snapshot image test sürecinde EC2 instance’ları açılıp kendi AMI’lerini derlemeleri sağlandı
- diffoscope ile üretilen disk imajları kaynak imajlarla karşılaştırıldı
- Düzenli testler sayesinde çeşitli sorunlar bulundu; bazıları doğrudan düzeltildi, bazıları ise başka geliştiricilere aktarıldı
FreeBSD/EC2’de Graviton güç yönetimi ve hot-plug
- Amazon’un FreeBSD/EC2 için öncelikli istediği başlıca özellikler, AWS Graviton instance’ları için power driver ve aygıt hot-plug desteğiydi
- Graviton power driver’ı, EC2 API’nin işletim sistemine kapanma bilgisini ilettiği yolu işler
- Bu özellik olmadan FreeBSD kapanma sinyalini yok sayıyor, birkaç dakika sonra ise EC2 timeout sonrası sanal gücü kesiyordu
- Graviton sistemlerindeki “güç düğmesi” bir GPIO pinidir ve ayrıntılar ACPI
_AEInesnesinde yer alır - ACPI içinden bu bilgiyi bulup yapılandırma bilgisini PL061 GPIO controller driver’ına ileten kod eklendi
- GPIO pini assert edildiğinde controller interrupt üretir, ACPI “power button” olayı tetiklenir ve sistem kapanmaya gider
- EC2’nin sunduğu ACPI tabloları bu GPIO pininin “Pull Up” olarak ayarlanmasını ister, ancak PL061 controller’da pullup/pulldown direnci yoktur
- Linux, GPIO yapılandırma hatasını sessizce yok saydığı için sorun görünmüyordu
- FreeBSD ise yapılandırma hatasından sonra aygıtı devre dışı bırakıyordu
- EC2 bug’ının ileride Graviton sistemlerde düzelmesi bekleniyor, ancak şimdilik FreeBSD/EC2 AMI’lerine
_AEInesnesindeki GPIO PullUp bayrağını yok sayanACPI_Q_AEI_NOPULLquirk’i eklendi
- Hot-plug, özellikle de hot-unplug, çeşitli EC2 instance türlerinde farklı sorunların üst üste gelmesi nedeniyle daha fazla çalışma gerektirdi
- Bazı Graviton sistemleri, PCI attach sırasında sanal IRQ rezervasyonunu sızdırıyordu; 67 kez EBS volume attach/detach işleminden sonra IRQ’lar tükeniyor ve FreeBSD kernel panic oluşuyordu
- Neden, legacy PCI interrupt routing koduydu ve EC2’de bu kodu kapatan bir boot loader ayarı eklendi
- Bazı Graviton sistemleri, işletim sisteminin aygıt kullanımını bitirip eject için hazır olup olmadığını anlamak adına PCI aygıt güç durumunu kullanıyordu
- Bunun bir EC2 bug’ı olduğu düşünülüyor; şimdilik eject öncesinde PCI power management register’ındaki bazı bitleri değiştiren
ACPI_Q_CLEAR_PME_ON_DETACHquirk’i kullanılıyor
- Bunun bir EC2 bug’ı olduğu düşünülüyor; şimdilik eject öncesinde PCI power management register’ındaki bazı bitleri değiştiren
- Yeni nesil EC2 instance’larında hem x86 hem de Graviton tarafında PCIe unplug sonrası FreeBSD
nvmedriver’ı panic oluşturuyordu- Bu sorun
nvmedriver bakımcısına iletildi
- Bu sorun
- Bazı x86 ve Graviton EC2 instance’larında eject sonrasında PCI bus üzerinde “ghost” aygıtlar kalıyor ve yeni aygıt attach işlemini engelliyordu
- Nitro firmware, PCI bus yönetimi ile PCI aygıt yönetimini asenkron yürüttüğü için aygıt unplug edilmiş olsa da PCI bus’un birkaç ms boyunca hâlâ varmış gibi raporlandığı bir pencere vardı
- Linux bus’ı periyodik olarak taradığı için çoğu zaman bu yarışta geç kalıyordu, FreeBSD ise detach sonrası PCI bus’u hemen yeniden taradığından ghost aygıtları daha sık görüyordu
- Şimdilik
ACPI_Q_DELAY_BEFORE_EJECT_RESCANquirk’i ile eject sinyalinden sonra PCI bus yeniden taramasından önce 10 ms gecikme eklendi
- Bazı Graviton sistemleri, PCI attach sırasında sanal IRQ rezervasyonunu sızdırıyordu; 67 kez EBS volume attach/detach işleminden sonra IRQ’lar tükeniyor ve FreeBSD kernel panic oluşuyordu
- PCIe, aygıt eject isteği için “attention” düğmesine basıldıktan sonra 5 saniyelik bir gecikme zorunlu kılar; ikinci bir düğme girdisi gelirse eject isteği iptal edilir
- EC2’de fiziksel düğmeye basan bir insan yoktur ve sanal düğmeye yeniden basma mekanizması da bulunmadığından bu gecikme gereksizdir
- Bu yüzden EC2’de timeout’u 0 yapan bir boot loader tunable eklendi
- Hot-plug test script’i ile EC2 instance’ı açıldıktan sonra EC2 API üzerinden EBS volume tekrar tekrar plug/unplug edilip FreeBSD’nin art arda 300 kez attach/detach yapabildiği doğrulanabiliyor
- Gelecekte EC2 instance türlerine önceden erişim olursa hot-plug davranışını doğrulamak için kullanılabilir
Önyükleme performansı regresyonlarını izleme ve AMI genişletmesi
- Amazon’un en yüksek öncelikli iki işi dışında, EC2’ye ayrılan sürenin yaklaşık yarısı başka FreeBSD/EC2 sorunlarına gitti
- 2023 sonu ve 2024 başında FreeBSD/EC2 instance’ları bazen beklenenden uzun sürede önyükleniyor ve haftalık snapshot testlerinde instance başlatıldıktan sonra SSH denemesi öncesi bekleme süresini artırmak gerekiyordu
- Performans sorunlarını ele almak için 2018’den bu yana haftalık EC2 AMI derlemelerinin önyükleme süreleri benchmark edildi
- Bu süreçte 10 binden fazla EC2 instance başlatıldı
- FreeBSD boot performance plots üretilmeye başlandı
- Yeni veri toplama ve plot güncelleme, haftalık snapshot test sürecine dahil edildi
- Birden fazla önyükleme gecikmesi nedeni bulundu ve düzeltildi
- 2024’ün ilk haftasından itibaren FreeBSD önyüklemesi yaklaşık 3 kat yavaşladı; nedenin kök disk boyutunu 5 GB’tan 6 GB’a çıkaran commit olduğu bulundu
- Amazon tarafındaki doğrulama, kök disk boyutu 8 GB’a çıkarılınca önceki performans düzeyinin geri geldiğini gösterdi
- Graviton 2 ailesinde kernel entropy seeding sorunu nedeniyle önyükleme uzuyordu
- FreeBSD kernel’i, güvenli rastgele sayı üretimi için yeterli entropy yoksa daha fazla entropy toplayana kadar önyüklemeyi durdurur
- Nitro firmware’den güvenli seed almak için EFI boot loader üzerinden çalışan bir kod vardı, ancak EC2’de bu kod yürümüyor ve Graviton 2’de 2048 baytlık istek çok yavaş kalıyordu
- Boot menu Lua kodundaki istek, menü etkin olsun ya da olmasın çalışacak şekilde boot loader Lua içinde doğru konuma taşındı
- 64 bayt EFI entropy alınıp PBKDF2 ile 2048 baytlık API girdisine uygun biçimde genişletildi; bunun sonucunda FreeBSD
arm64/base/UFSönyükleme süresi yaklaşık 25 saniyeden 8 saniyeye düştü
- ZFS imajları, UFS’den daha geç önyükleniyordu ve gecikme miktarı disk boyutuna değil, diskteki veri miktarına bağlıydı
makefsher şeyi tek bir transaction group içine koyuyor, ZFS ise attach sırasında en son transaction group’u dolaşıp doğrularken diskteki tüm dosya metadata’sını okuyup işliyordu- Mark Johnston, filesystem’e daha yüksek bir transaction group yazarak bu tek transaction group’un “yakın tarihli” sayılmamasını sağladı ve sorunu çözdü
- ZFS imaj önyükleme süresi yaklaşık 22 saniyeden 11 saniyeye indi
- Aralık 2024’te
net/aws-ec2-imdsv2-getport’una IPv6 desteği eklendikten sonra önyükleme sorunu hızla yakalandı- Bu port, EC2 Instance MetaData Service için bir komut satırı arayüzü sunuyor
- Önce IPv6 deneniyordu, ancak varsayılan IMDS instance yapılandırması yalnızca IPv4’tü ve varsayılan TCP timeout’u olan 75 saniye de korunuyordu
- Düzeltmeden sonra önce IPv4 deneniyor ve timeout 100 ms’ye indiriliyor
- 2024’ün ilk haftasından itibaren FreeBSD önyüklemesi yaklaşık 3 kat yavaşladı; nedenin kök disk boyutunu 5 GB’tan 6 GB’a çıkaran commit olduğu bulundu
- FreeBSD AMI flavour’ları da genişletildi
- Daha önce yalnızca
basevecloud-initvardı smallAMI; debug symbol’leri, LLDB’yi, 32-bit kütüphaneleri, FreeBSD testlerini, Amazon SSM Agent’ı ve AWS CLI’ı kaldırarak disk kullanımını yaklaşık 5 GB’tan 1 GB’a düşürüyorbuilderAMI, kullanıcıların özel FreeBSD AMI’lerini kolayca oluşturabilmesi için FreeBSD AMI Builder AMIs sunuyor
- Daha önce yalnızca
- 4 AMI flavour, 2 filesystem, 2 architecture ve 3 FreeBSD sürümünün birleşimi haftalık snapshot derlemelerini artırınca eski imajlar ve ilgili EBS snapshot’ları temizlendi
- FreeBSD sürüm mühendisliği AWS hesabı Amazon sponsorluğu alıyor olsa da maliyet birilerinin üstüne yazılıyor
- Bir shell script yazılarak 336 TB EBS snapshot silinebildi
Sponsorluk sonrası kalan işler ve kısıtlar
- Büyük projelerin yanında birçok küçük iş de devam etti
- Haftalık snapshot derlemelerinde bulunan build breakage’ları düzeltmek
- ENA driver patch’lerini gözden geçirmek
- Dave Cottlehuber’ın OCI Container derleyip depoya yükleme özelliğini eklemesine destek olmak
bsdec2-image-uploadaracının dahili AWS hatalarını daha zarif işlemesini sağlamak- Tesadüfen fark edilen bir AWS güvenlik sorununu bildirmek
- Sponsorluk bittikten sonra da FreeBSD sürüm mühendisliği liderliği ve FreeBSD/EC2 platform bakımcılığı rolleri sürecek
- FreeBSD 15.0’ın Aralık ayında gelmesi bekleniyor
- 2026’da 14.4, 15.1, 14.5 ve 15.2 sırasıyla gelecek
- Ayrılabilecek süre azaldıkça, sürüm öncesi sorunları doğrudan düzeltme yaklaşımı zorlaşacak
- Geç gelen özelliklerin, sürüme yetişecek şekilde düzeltilmesinden çok sürümden çıkarılması daha olası hale gelecek
- FreeBSD 14.2’den itibaren OCI Containers’ın dahil edilebilmesi, sponsorlu zaman sayesinde gerekli parçaların eksiksiz girdiğinin doğrulanabilmiş olmasındandı
- EC2 tarafında önyükleme performansı regresyon testleri, ilgili sorunları yakalama olasılığını artırıyor; ancak ek zaman olmazsa özellik uygulama listesi durağanlaşabilir
- EBS volume genişletildiğinde filesystem’in otomatik büyümesi
- Çoklu network interface ve network interface hot-plug için otomatik yapılandırmanın iyileştirilmesi
- Rolling “pre-patched” AMI
- Package kurulumu ve daemon çalıştırma gibi işler için EC2 user-data dosyası üreten bir web sitesi
- FreeBSD/Firecracker çalışmalarının yeniden başlaması ve desteklenen platform haline gelmesi
- Amazon sponsorluğu, çoğu açık kaynak geliştiricisinin elde ettiğinden çok daha büyük bir fırsattı; sponsorluk biterken geriye, bundan duyulan üzüntüyle birlikte bu süreçte ortaya çıkan sonuçlar için duyulan minnettarlık kalıyor
1 yorum
Hacker News yorumları
Güzel. Bugünden itibaren ziglang.org indirme sayfasına FreeBSD eklendi; böylece FreeBSD kullanıcıları CI’da otomatik derlenen master dalı derlemelerini alabilecek.
Artık libc bağlantısı da dahil olmak üzere birinci sınıf bir çapraz derleme hedefi olarak desteklendiğinden
zig cc -o hello hello.c -target riscv64-freebsdgibi şeyler de mümkün.C/C++ bağımlılıkları varsa bunları Zig derleme sistemine alıp derleyebildiğiniz için, oldukça karmaşık projeleri bile FreeBSD için kolayca çapraz derlemek mümkün olacak gibi görünüyor. Daha fazla projenin FreeBSD desteği ve CI testleri eklemesine yardımcı olmasını umuyorum.
Resmen kabul görmüş bir C alternatifi olsa güzel olurdu.
Burada epey ilginç bir bölüm var.
“2024’ün ilk haftasından itibaren FreeBSD’nin önyükleme süreci birden yaklaşık 3 kat yavaşladı. Commit’leri ikili aramayla tarayınca nedenin kök disk boyutunu 5 GB’tan 6 GB’a çıkaran commit olduğu görüldü. Neden böyle olmuştu? Amazon’daki tanıdıklara sorunca yanıt ‘sihir’ ile ‘gerçekten bilmek istemezsin’ arasında bir yerdeydi; önemli olan ise kök diski 8 GB’a çıkarınca performansın eski seviyesine dönmesiydi.”
Bunun gözlemlenen performans uçurumuyla ilgisi olup olmadığını bilmiyorum.
Dizüstü tarafında da çok iş var; BSD Foundation’ın buna 750 bin dolar yatırdığını okumuştum.
S0ix uyku durumu gibi uygulamaları da içeriyor; proje burada görülebilir: https://github.com/FreeBSDFoundation/proj-laptop
cperciva’ya gerçekten saygı duyuyorum.
Bütün bunlarla Tarsnap’i aynı anda nasıl yürüttüğünü bilmiyorum.
Adil olmak gerekirse burada harcanan zamanın bir kısmı Tarsnap’ten çıktı, ama düşündüğünüzden çok daha azı.
Amazon’ın daha fazla harcama yapmasını ve katkıda bulunmasını beklerdim; temelde yalnızca asgari FreeBSD desteği için para ödemek istiyor gibi görünüyor.
Amazon, FreeBSD sponsorları listesinde bile yok [1]; Google geçen yıl yalnızca 9 bin dolar bağış yapmış, Apple da yok. Microsoft en azından listede, bunu teslim etmek gerekir. Meta/Facebook da yok.
Bu şirketler FreeBSD ve OpenBSD kullanıyor ve bunlardan yararlanmaya devam ediyor; bu yüzden temelde her yıl sponsor olmalarını beklerdim.
[1] https://freebsdfoundation.org/our-donors/donors/?donationYea...
Örneğin bana yapılan ödeme Foundation üzerinden geçmedi. Tahminimce kurumsal fonlarla yapılan FreeBSD geliştirmelerinin içinde Foundation destekli geliştirmeler belki %10 civarındadır.
Bu %10 özellikle “X şirketinin ihtiyaç duyduğu şeyler”e değil, “FreeBSD’nin ihtiyaç duyduğu şeyler”e odaklanabildiği için önemli; ama yine de küçük bir pay.
Birincisi, yalnızca belirli bir yıldaki Foundation bağışlarının anlık görüntüsünü gösteriyor; dolayısıyla bağış geçmişi doğal olarak görünmüyor.
İkincisi, geliştirme katkılarını da göstermiyor. Bu tür bilgiler genellikle her sürüm notunda özetlenmiş olarak görülebilir [1].
[1] https://www.freebsd.org/releases/
Bulutta olsun olmasın, Microsoft servislerinin *BSD üzerinde çalıştığı da aklıma gelmiyor.
Ev ağ geçidi/güvenlik duvarı/DNS/DHCP sunucusu olarak FreeBSD kullanmak istemiştim, ama 10GbE NIC’im için sürücü yok gibi göründüğünden sonunda Nix’i seçtim.
Uzun zaman önce FreeBSD’yi iş istasyonu olarak kullanmıştım ve oldukça akılda kalıcı bir deneyimdi. Hâlâ istikrarlı şekilde yoluna devam ettiğini görmek güzel.
Realtek ise sürücüyü bakımını yapan FreeBSD mühendisleri çok çaba gösterse de yük altına girince bozuluyor gibi. Şikâyet etmiyorum; emeklerine saygı duyuyorum.
Bu kadarı küçük bir bedel ve daha az kararlı bir işletim sistemi kurmak zorunda kalmamamı sağlıyor.
FreeBSD 7 ya da 8 zamanlarında, Atheros Wi‑Fi kartları gibi donanımlarda FreeBSD sürücülerinin Linux’tan daha iyi olduğu dönemleri hatırlıyorum
2021 civarına kadar FreeBSD’yi tercih ediyordum; ancak farklı CPU çekirdeklerinin bir arada bulunduğu bilgisayarlar yaygınlaşınca bu değişti. Önce 2 big çekirdek ve 4 little çekirdeği olan bir RockPro64 aldım, ardından Intel Alder Lake aldım
Anladığım kadarıyla FreeBSD zamanlayıcısı bu tür yapılandırmaları hâlâ düzgün ele alamıyor; sistemi yavaş çekirdekleri baz alan en düşük ortak paydaya çekiyor gibi görünüyor
Merak ediyorum, FreeBSD/EC2’nin başlıca kullanıcıları kimler acaba?
EC2 üzerinde FreeBSD’yi kimlerin kullandığını gerçekten bilmek isterdim
Şirketlerin açık kaynak sponsorluğunun nasıl işlediğini çok iyi gösteren bir yazı
FreeBSD kullanan biri, Unix alanında FreeBSD’nin doldurduğu nişin ne olduğunu açıklayabilir mi? Neden daha basit ve tutarlı OpenBSD ya da NetBSD değil de FreeBSD?
Cevap ZFS, Nvidia sürücüleri, ELF gibi desteklerse, neden Linux değil? GNU’nun sorunlarını iyi biliyorum ama Musl Void gibi şeylerde de sorun var mı?
Gerçekten merak ediyorum. FreeBSD benim için bir tür gölge alan gibi var; onu çalışır halde tutan temel kimliği tam olarak yakalayamadım ama bir yerlerde olduğunu biliyorum
Her servis izolasyon için kendi jail’i içinde çalışıyordu; çok güçlü olmayan tek bir sunucu tüm servisleri çalıştırabildiği için maliyet verimliliği olağanüstüydü
Bir noktada hibrit yapı için buluta geçiş yaptık; Linux (k8s) ile FreeBSD’yi karıştırınca maliyetler fırladı. Veri merkezinde diskleri kendiniz satın alıp değiştirmeniz, yangın gibi durumlara yanıt vermeniz gerekir ve yalnızca tek bir ülkede bulunmanın dezavantajı vardır; AWS ise çok bölgeli kullanım ve çeşitli güzel özellikler sunar, bunun da bir bedeli vardır
ZFS’den aşırı ölçüde yararlanmamıştık ama production DB’de bir tabloyu yanlışlıkla sildiğimizde, hemen önceki ZFS snapshot’ına anında geri dönerek bir kez bizi ciddi biçimde kurtardı. Biraz veri kaybı oldu ama o uygulamada uptime daha önemli olduğu için büyük bir sorun değildi. Yedekleme için de ZFS kullandığımızı hatırlıyorum
Production ortamı sorunlarını gidermek için dtrace’i birkaç kez kullandım; FreeBSD sunucu filosuna Linux’u dahil edince ekipler doğal olarak farklı dağıtımları seçti ve bir tür hayvanat bahçesine dönüştü. Sunucularda FreeBSD kullanınca yalnızca tek bir varyant var
İkisini de hâlâ kullanıyor ve seviyorum ama FreeBSD’nin çekirdek ile işletim sisteminin entegre bir formda olması gerçekten hoşuma gidiyor
Tarihsel olarak FreeBSD Intel CPU’lara öncelik verdi, NetBSD taşınabilirlikte daha güçlüydü; FreeBSD’nin güvenliği de sağlamdı ama OpenBSD güvenliğe daha fazla odaklandı
FreeBSD’nin ZFS desteği gerçekten oyunun kurallarını değiştirecek düzeyde. Bildiğim kadarıyla Nvidia ancak yakın zamanda yerel FreeBSD sürücüsü sağlamaya başladı; uzun süre FreeBSD’nin Linux çekirdeği uyumluluk özelliğine ihtiyaç vardı
Başka bir deyişle FreeBSD, diğer BSD’lerin sunduğu özellikleri iyi harmanlarken, benim ağırlıklı olarak kullandığım donanım platformunda da son derece kararlıydı
NetBSD taşınabilirlik üzerinden rekabet ediyor ve yüksek ağ throughput’unu korumaya çok fazla zaman harcamıyor gibi geliyor
Tüm BSD’ler genel olarak çok daha az değişiyor; bunun artıları ve eksileri var ama entegrasyon hedefi bir platform olarak daha iyi olduklarını düşünüyorum
Yazılım listesi de çok daha geniş ve modern bir masaüstü günlük kullanım işletim sistemi olarak da mümkün. Diğer ikisi için bunu söylemek zor
Neden Linux değil derseniz, ben Linux istemiyorum. Kurumsal çıkarların altında fazlasıyla ezilmiş durumda