Değişmez Linux Sistemlerine Giriş

 (dataswamp.org)
3 puan yazan GN⁺ 2023-09-19 | 1 yorum | WhatsApp'ta paylaş
  • Değişmez Linux dağıtımları, yükseltmeleri çalışan sistemin dışında hazırlayıp bir sonraki açılışta uygulayarak, hata durumunda geri dönebilen bir işletim modeli sunar
  • “Değişmez” adına rağmen sistemin birçok alanı hâlâ değişebilir; gerçek ortak nokta daha çok işlemsel güncellemeler ve geri alma yeteneğidir
  • NixOS ve Guix bildirimsel yapılandırmayı ve salt okunur depoyu merkeze alırken, OSTree ailesi, MicroOS ve Vanilla OS sırasıyla /usr, btrfs anlık görüntüleri ve A/B kök bölümleriyle yaklaşır
  • Avantajı, paket değişiklikleri sırasında bile sistemi kararlı tutmak ve sorunları geri alabilmektir; ancak yeniden başlatma gereksinimi, yapılandırma yönetimi araçlarıyla çakışmalar ve değişiklikleri izleme zorluğu devam eder
  • Yenilik, anlık görüntünün kendisinden çok değişiklikleri canlı olmayan bir ortama uygulamak ve bunu bootloader ile kullanıcı araçlarına entegre ederek daha kolay yönetilebilir hâle getirmektir

“Değişmez” adının gerçek kapsamı

  • Değişmezlik aslında değişmeyen nesne anlamına gelir; ancak işletim sistemlerine uygulandığında tanımı hemen belirsizleşir
  • Linux LIVE-CD, her seferinde aynı programlarla açılması ve disk ortamının salt okunur olması nedeniyle değişmez gibi görünür; ancak çalışırken dosya ve dizin oluşturmak ya da paket kurmak mümkündür
  • Günümüzde bir Linux dağıtımını değişmez olarak adlandırmak için genellikle üç koşul gerekir
    • Sistem yükseltmeleri doğrudan canlı sistem üzerinde yapılmaz
    • Paket değişiklikleri bir sonraki açılışta uygulanır
    • Önceki duruma geri dönülebilir
  • Uygulamaya göre ek özellikler farklılık gösterir; ancak bu üçü günümüzde “değişmez” dağıtımların asgari koşullarına yakındır

Uygulamalara göre farklar

  • NixOS / Guix

    • NixOS ve Guix aynı aileden uygulamalara dayanır; Nix ilk kez 2003’te ortaya çıktı, Guix paket yöneticisi ise 2010’ların başında Nix’ten çatallanarak %100 özgür yazılımı hedefledi
    • İki sistem geleneksel Unix benzeri sistemlerden oldukça farklıdır ve değişmezliği temel ilke olarak benimser
    • Tüm paketler ve derlenmiş dosyalar, yalnızca paket yöneticisinin yazabildiği özel salt okunur dizinlerde benzersiz girdiler olarak saklanır
    • İşletim sisteminin kendisi paket yöneticisinin çıktısıdır; kullanıcı, istediği sistem durumunu bildirimsel yapılandırma olarak yazar
    • Yapılandırma; kullanıcıları, kabukları, kurulu paketleri, çalışan servisleri ve ayarlarını, bağlanacak bölümleri ve seçenekleri içerir
    • Modüller varsayılan değerler sağladığından, kullanıcı oluştururken UID, GID, kabuk ve ev dizinini tek tek belirtmek gerekmez
    • /etc/fstab veya /bin/sh gibi dosyalar da salt okunurdur; değiştirmek için paket yöneticisinden geçmek gerekir
    • Yapılandırma geçişi, sembolik bağlantı değiştirmeye yakın olduğu için anında yapılabilir; açılışta önceki yapılandırma seçilerek geri dönülebilir
    • Özel depo dizini dışındaki /home, /etc, /var gibi alanlar değiştirilebilir; sistem sembolik bağlantıları başka şeylerle değiştirilebilse de asıl kaynaklar düzenlenemez
    • NixOS iyi bir uygulama olarak görülür; ancak mevcut sistemlerden çok farklı olduğu için, avantajlarına rağmen benimsenme oranı düşüktür

  • Endless OS

    • Endless OS son kullanıcıları hedefleyerek yayımlanan ilk değişmez işletim sistemlerinden biridir; internet veya elektrik şebekesi kapsamasının düşük olduğu ülkelerde de kullanılabilecek sağlam bir sistem olmayı amaçlar
    • Debian tabanlıdır ancak değişmezliği OSTree ile uygular
    • OSTree, çekirdek sistem imajını yönetir, bunun üzerine paket benzeri katmanlar ekler ve bir sonraki açılış için yeni sistem imajı hazırlayabilir
    • Paket değişiklikleri, bir sonraki açılışta kullanılacak yeni sistem sürümüne uygulanır; açılışta önceki sürüme geri dönülebilir
    • Bölümler genellikle yazılabilir durumdadır; ancak OSTree’nin yönettiği paket alanı olan /usr salt okunur bağlanır
    • /etc için geri alma yoktur
    • Kullanıcı uygulamaları Flatpak ile kurulur; böylece her yeni paket kurulumunda yeniden başlatma ihtiyacı azalır
    • Değiştirilmiş GNOME masaüstü, akıllı telefon menüsüne benzer görünür ve teknik olmayan kullanıcılar için tanıdık bir biçim hedefler
    • DevOps araçları kurmak pratik değildir, ancak imkânsız da değildir

  • Fedora Silverblue

    • Fedora Silverblue Fedora / CentOS / RHEL’i değişmez hâle getirmeyi amaçlayan Project Atomic akımının devamındadır
    • OSTree üzerinde RPM paket değişiklikleri uygulayan rpm-OSTree kullanır
    • Sistem, sürüm başına tek bir çekirdek imajdan ve bunun üzerine eklenen paket katmanlarından oluşur
    • Kurulu paket katmanları listelenebilir; bir paket kaldırıldığında tüm yığın yeniden oluşturulur ve kaldırma sonrası artık dosya kalmaz
    • Bu yeniden oluşturma süreci çok yavaştır
    • Paket kurulduğunda mevcut açılmış sisteme uygulanmadığından varsayılan olarak yeniden başlatma gerekir; açılışta önceki sistem sürümü seçilebilir
    • rpm-OSTree, bir sonraki açılış değişikliklerini tmpfs overlay ile canlı sisteme geçici olarak birleştirme özelliği sunar
    • Bağlama politikası /etc, /root, /var dışında salt okunurdur; ev dizinleri varsayılan olarak /var/home altında olduğundan beklentilerle çelişebilir
    • /etc rpm-OSTree tarafından yönetilmediği için geri alınmaz
    • /usr/local, /var içindeki bir dizine işaret eden sembolik bağlantıdır; bu nedenle RPM dosyası olmadan kullanıcı değişiklikleri enjekte etmek kolaydır
    • Paket kurulumu yavaş olduğu ve yeniden başlatma gerektirdiği için Flatpak veya toolbox kullanımı önerilir
    • toolbox, geliştirme kütüphanelerini veya araçlarını terminalde kullanabilmek için root yetkisi gerektirmeyen Fedora konteynerleri oluşturur

  • OpenSUSE MicroOS / Aeon

    • OpenSUSE MicroOS rolling-release olan OpenSUSE Tumbleweed’in değişmez bir spin’idir ve kendi uygulamasını kullanır
    • /home, /var gibi bazı dizinler dışında tüm sistem btrfs anlık görüntüleri üzerindedir
    • Sistem değişikliği gerektiğinde mevcut anlık görüntü yeni bir anlık görüntüye kopyalanır; değişiklik yeni anlık görüntüye uygulanır ve bir sonraki açılışta kullanılır
    • OSTree tabanlı sistemlerden farklı olarak /etc de anlık görüntünün parçası olduğundan geri alınabilir
    • Yeni anlık görüntü içinde bir kabuk kullanarak dosya sistemindeki herhangi bir dosyayı değiştirmek mümkündür; bu, sürücü sorunlarını gidermek için dosya enjekte etme gibi işlerde kullanışlıdır
    • Ancak bu tür değişiklikler izlenmediğinden sistemin “saf” durumda olduğunu garanti etmek zordur
    • Değişiklikler transactional-update komutuyla yapılır; paket ekleyip kaldırabilir veya yeni anlık görüntü içinde kabuk açarak istediğiniz değişiklikleri yapabilirsiniz
    • /etc anlık görüntüye dahil olsa da her zaman okunabilir olduğundan, canlı durumda /etc değiştirilip ardından yeni anlık görüntü oluşturulursa bu değişiklik hemen devralınır
    • Varsayılan yaklaşım, güncellemelerden sonra günlük yeniden başlatma planlamaktır; rolling-release olduğu için günlük güncelleme vardır ve yeniden başlatmadan önce yeni paketlerin avantajlarından yararlanılamaz
    • Otomatik yeniden başlatma devre dışı bırakılabilir
    • Silverblue’daki gibi canlı sisteme değişiklik uygulama özelliği şu anda deneyseldir ve henüz kullanılamaz
    • Bunun yerine, kullanıcı araçlarını kurmak için distrobox ile farklı dağıtımların root yetkisi gerektirmeyen konteynerlerini kullanma yöntemi önerilir

  • Vanilla OS

    • Vanilla OS Ubuntu tabanlıdır ve yakında Debian tabanına geçmesi planlanan yeni bir değişmez sistem ailesidir
    • Değişmezlik ABroot ile uygulanır
    • ABroot; kök bölümü A, kök bölümü B ve /home ya da /var gibi kalıcı veriler için bölümler bulundurur
    • Açılış ve değişiklik akışı şöyledir
      • İlk açılış A’dan yapılır ve A salt okunur bağlanır
      • Yeni paketler veya /etc dosyası değişiklikleri gibi sistem değişiklikleri B’ye uygulanır; tmpfs overlay ile canlı uygulama da mümkündür
      • Yeniden başlatma sonrasında B’den açılır; başarılı olursa ABroot, A ile B arasındaki farkı tarar ve B’deki değişiklikleri A’ya uygular
      • Yeni değişiklik olmadığında A ve B her zaman aynıdır
    • Dezavantajı, yalnızca yeni sürüme önyükleme yapılana kadar geri dönüş yapılabilmesidir
    • Yeni sürümle açılış yapıldığında değişiklikler önceki açılış bölümüne de uygulanır ve artık geri dönülemez
    • Bu yöntem esas olarak başarısız yükseltmeleri veya canlı olarak denenen değişiklikleri geri almak için etkilidir
    • Vanilla OS, apx paket yöneticisini sağlar
    • apx, distrobox’ın yazarı tarafından geliştirilen bir araçtır; root olmayan kullanıcıların Arch Linux, Fedora, Ubuntu, Nix gibi çeşitli dağıtımların paketlerini kurup yerel kurulum gibi entegre edebilmesini sağlar
    • Vanilla OS, ABroot ve apx hâlâ gençtir ve pürüzlü yanları vardır

  • LBU ile Alpine Linux

    • Alpine Linux, lbu komutuyla değişmezliğe yakın bir yapılandırma oluşturabilir
    • Alpine kurulum programını temel açılış sistemi olarak kullanır ve açılışta otomatik uygulanan bir “kaydedilmiş ayarlar” tarball’ı oluşturur
    • Her açılışta dizinler yeniden açılır ve paketler yeniden kurulur; her şey canlı bellekte tamamen yazılabilir durumdadır
    • Her zaman temiz bir durumdan başlar ve değişiklikleri bunun üzerine uygular; değişiklikleri geri alıp yeniden başlayabilir
    • Yukarıda tanımlanan değişmezliği tam olarak karşılamaz; çünkü değişiklikler temel sistemin üzerine uygulanır
    • Sistem tamamen bellektedir ve neyin kaydedilip geri yükleneceğini bizzat yönetmek gerektiğinden yüksek düzeyde kavrayış gerektirir; arşiv büyüyebilir
    • Dokümantasyonu da yetersizdir

Avantajlar ve operasyonel kısıtlar

  • Avantajlar

    • Sorun çıkarsa değişiklikler geri alınabilir
    • İşlemsel güncellemeler, paket değişiklikleri sırasında bile sistemin doğru şekilde çalışmasına yardımcı olur

  • Dezavantajlar

    • Ansible, Salt, Puppet gibi yapılandırma yönetimi araçlarıyla entegrasyonu çok kötüdür
    • Paket değişikliklerini uygulama biçimini anlayacak şekilde güncellenmiş olsalar bile, bunları normal bir sistem gibi yönetmeye çalışınca çoğunlukla duvara toslanır
    • Değişikliklerden sonra yeniden başlatma zorunluluğu can sıkıcıdır; ancak NixOS ve Guix her değişiklik için yeniden başlatma gerektirmez
    • OSTree tabanlı sistemler esnek değildir
      • Örneğin ses için ALSA dizinine ek dosyalar gerektiren bir netbook’ta, bu dosyaları dağıtan bir paket oluşturmadan ekleme yapılamaz
    • Geri alma daha çok kör geri alma gibidir; her sistem sürümünde hangi değişikliklerin olduğunu anlamak zordur
    • Kök dosya sisteminde dizin gerektiren Nix/Guix gibi programlar veya paketlenmemiş yazılımların sistem geneline kurulumu zor olabilir

Değişmez sistemler hakkında gerçekler ve yanlış anlamalar

  • Değişmezlik, katı anlamıyla neredeyse yanlıştır; sistemin birçok bölümü hâlâ değiştirilebilir
  • Değişmezlik durumsuz (stateless) anlamına gelmez
  • NixOS ve Guix, kararlı paket yöneticileriyle tüm sistemi izler; kaynaklarda sürüm kontrol sistemi kullanılabildiği için baştan doğru felsefeye sahip uygulamalar olarak değerlendirilir
  • Değişmezlik sık sık güvenlik avantajlarıyla ilişkilendirilir; ancak root yetkisi elde eden bir saldırgan canlı sistemi manipüle edebilir ve /boot bölümüne de müdahale edebilir
  • Bir sonraki açılışta kullanılacak arka kapının kurulmasını engelleyen bir şey yoktur
  • Değişmezlik disiplin ve bakım gerektirir
    • Sürüm kontrolüne dikkat etmek gerekir
    • apx, distrobox, devbox gibi ek programların sistemden ayrı güncellenmesi gerekir
    • NixOS ve Guix’te bu kısım entegredir

Gerçekte yeni olan ne

  • Değişmez işletim sistemleri açık kaynak sistem topluluğunda ilgi görüyor; ancak aynı kelimenin altında farklı uygulamalar ve kullanım senaryoları bir araya geliyor
  • “Değişmez” adı kullanıcıda belirli beklentiler oluşturur; fakat gerçekte işletim sistemleri için işlemsel güncellemelere daha yakındır
  • İşlemsel güncellemenin kendisi yeni bir kavram değildir
    • Solaris ve ZFS, açılışta sistem anlık görüntüsü seçebiliyordu
    • FreeBSD de yaklaşık 10 yıl önce benzer bir özelliği uygulamış gibi görünüyor
    • Genel Linux dağıtımları da btrfs anlık görüntüleri kullanıldığında açılışta anlık görüntü seçebilir
  • Asıl yeni olan, işlemsel değişiklikleri canlı olmayan bir ortama uygulamak, bunu bootloader’a entegre etmek ve kullanıcıların kolayca yönetebileceği araçlar sunmaktır
  • Daha fazla okumak için Colin Walters’ın “Immutable” → reprovisionable, anti-hysteresis yazısı önerilir

İlgili okumalar

1 yorum

 
GN⁺ 2023-09-19
Hacker News yorumları

  • Silverblue’nun listeye girmesi sevindirici, ama Fedora CoreOS’un eksik olması üzücü
    FCOS, üretimde kullanıma uygun bir işletim sistemi; CoreOS satın alındıktan sonra çok gelişti ve Nix’e kıyasla öğrenmesi ve kullanması daha kolayken değişmezliği koruyan iyi bir orta yol gibi görünüyor
    FCOS geliştiricilerinin eklediği CoreOS Layering, sistem durumunu Dockerfile ile tanımladığınızda FCOS’un o duruma rebase etmesini sağlayan, sunucu yapılandırması için yalnızca yeniden başlatmanın yeterli olduğu güçlü bir özellik
    Bir sonraki projenizde VM gerekiyorsa denemeye değer. Linux iş istasyonunda yerel olarak Butane dosyaları oluşturmayı kolaylaştıran Python tabanlı CLI aracı Bupy’yi de yaptım; ayrıca CoreOS Layering ile Paperless NGX çalıştıran bir örnek de var
    https://github.com/quickvm/bupy
    https://github.com/quickvm/fcos-layer-paperless-ngx
    https://coreos.github.io/rpm-ostree/container/
    https://github.com/coreos/enhancements/blob/main/os/coreos-l...
    https://github.com/coreos/layering-examples

    • CoreOS ailesindeki başka bir proje olan Flatcar hakkındaki düşüncelerini de merak ediyorum
      Böyle projeleri bare metal ortamda nasıl kullanmak gerektiği benim için en zor kısımdı. VM imajı oluşturmak güzel, ama pratikte çoğu zaman mevcut bir sürücüye kurmak ya da altında bir ZFS pool olacak şekilde kurulum yapmak istiyorsunuz
    • CoreOS Layering gerçekten kullanışlı görünüyor. Şu anda birkaç Raspberry Pi ve x86_64 sunucuda openSUSE MicroOS kullanıyorum; MicroOS’u seçmemin nedenlerinden biri Raspberry Pi kurulumunun oldukça basit olmasıydı
      CoreOS’u Raspberry Pi’ye kurmanın ne kadar zor olduğunu merak ediyorum. İnternetteki bazı kurulum rehberleri epey karmaşık görünüyor

  • Bu tür değişmez sistem tanıtımlarında hep eksik kalan başka bir eksen de imaj tabanlı yaklaşım
    https://universal-blue.org/ üzerinde benden çok daha yetkin insanlarla birlikte çalışıyorum; Fedora Silverblue temel sürümü ve çeşitli masaüstü edisyonları üzerine OCI konteyner imajları derliyoruz
    Bu imajlar rpm-ostree ile boot edilebiliyor, daha doğrusu bunlara rebase edilebiliyor; bu, sistemi katmanlamadan daha sağlam biçimde genişletmenin bir yolu ve aynı değişiklikleri herkesin kolayca devralmasını ya da kullanmasını sağlıyor. Kendi imajınızı oluşturmak da çok kolay
    VanillaOS ve SUSE de benzer bir şey yapıyor gibi, ama biz bir OS projesi değil, yalnızca Fedora’nın downstream’iyiz. Fedora’nın resmi desteği de yolda; hâlihazırda çalışan kapsamıyla bile Nvidia sürücüleri sunmak gibi işler için, deneyimlerime göre en sağlam ve en kolay yöntemlerden biri

    • Biraz farklı bir konu ama, 2009 civarında Windows uzak masaüstü host’ları çalıştıran büyük bir hipervizör görüp şaşırmıştım. Sanırım Citrix’ti
      VM’ler bir imajdan boot ediyordu ve imaj ile değişiklik diski tamamen RAM’deydi. Kullanıcı profilleri sabit diskteydi, ama 25 kişilik masaüstü host’u uzaktan oturum almaya hazır duruma yaklaşık 4 saniyede boot ediyordu
      Yama yapması en az acı veren Windows sistemiydi
    • Fedora Silverblue da imaj tabanlı değil mi diye kafam karışıyor
      Varsayılan kurulumun katmanlama kullanmadığını, katmanlamanın yalnızca ek RPM paketleri kurmak istediğinizde devreye girdiğini sanıyordum
    • UBlue, paket güncellemelerini yansıtmak için imajları GitHub Actions ile düzenli olarak yeniden derliyor gibi görünüyor. Maliyeti kimin ödediğini merak ediyorum
      İmajların da GitHub’dan sunulup sunulmadığını, GitHub’ın dış trafik için ücret alıp almadığını ve çok sayıda kullanıcı aynı imajı indirmeye çalışırsa ne olacağını da merak ediyorum

  • Değişmez sistemlerden çok önceden yapılandırılmış sistemlerle ilgileniyorum
    Bu konuda NixOS ve Home Manager öne çıkıyor, ama yapılandırma biçimi gerçekten berbat. Tüm yapılandırmayı kaynak kontrolüne koymak, mevcut sistem durumunun o yapılandırmayla aynı olduğunu bilmek ve bunun dışındaki değişikliklerin yeniden başlatmada silinmesini istiyorum. Yeniden başlatmadan önce değişenlerin vurgulanması da iyi olurdu
    Silverblue gibi şeylerle sınırlı deneyimime göre temel sistemi yapılandırabiliyorsunuz, ama Firefox gibi uygulamalar eklemeye başladığınızda Flatpak kullanıyorsunuz ve istediğim tüm Flatpak kurulumunu ve bunların ayarlarını birlikte bildirimsel olarak nasıl tanımlayacağımı pek bilmiyorum
    Flatpak’leri topluca kurup geri kalanını dotfile’larla halletmenin bir yolu muhtemelen vardır
    https://universal-blue.org/tinker/mindset/#resist-the-urge-t...

  • Flatpak ve genel olarak değişmez yaklaşımda yaşadığım sorun, geliştiricinin desteklemediği bir şekilde değişiklik yapamamanız
    Örneğin takvimimi decsync ile eşitliyorum; bildiğim kadarıyla Evolution Flatpak’e decsync eklentisi eklemek mümkün değil
    Bu tür değişmez sistemler, geliştiricinin destekleyemediği ya da desteklemediği kullanım senaryoları için kullanıcı tanımlı overlay dosya sistemlerini katmanlamayı birinci sınıf bir özellik olarak destekleyene kadar insanlar değiştirilebilir sistemleri kullanmaya devam edecek

    • NixOS tam da bu türden kontrolü çeşitli şekillerde sağlıyor
      nixpkgs’teki bazı paketler ile NixOS ve Home Manager modüllerinin çoğu, eklentileri, ek paketleri vb. yapılandırmaya yarayan pek çok seçenek sunuyor
      Nix ayrıca özel paketler veya mevcut paketlerin varyantlarını eklemek için overlay ve override mekanizmaları da sunuyor; paketlerin bazı kısımlarını değiştirmek de mümkün. Bu da yetmezse koda doğrudan yama ekleyebilir veya upstream deposunun bir fork’undan derleme yapabilirsiniz
      Aslında bu, Nix’te en sevdiğim şeylerden biri. “Bu paketi derlerken şu bağımlılığı benim sürümümle değiştir” demek kolay olduğu için açık kaynağa daha sık katkı yapar oldum
    • “Evolution Flatpak’e decsync eklentisi eklemek” gibi işler Linux GUI yazılımlarında çok yaygın
      Bu alanın dışında çoğu yazılım, ihtiyaç duyulan özellikleri içinde barındırarak gelir. Örneğin Solidworks bana hiç isteğe bağlı bağımlılık indirmemi söylemedi; ama FreeCAD, CAD/CAM/simülasyon/render akışında bir sonraki adıma her geçtiğimde, kelimenin tam anlamıyla her 15 dakikada bir benden bir şey istiyordu
      https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv... de bakmaya değer
      Asıl mesele şu: “herkesin kullandığı %20” hiçbir zaman aynı %20 değil. Son 10 yılda özelliklerin yalnızca %20’sini uygulayan “hafif” bir kelime işlemci çıkarmaya çalışan onlarca şirket duydum; bir gazetecinin inceleme yazarken kelime sayma özelliğini arayıp bunun “kimsenin kullanmadığı %80” içinde olduğunu görmesi ve sonunda “hafif program iyi, şişkinlik kötü ama şu lanet şey kelime sayamadığı için kullanılamaz” diye yazması hikâyesi neredeyse PC kadar eski
    • Kullanıcı tanımlı overlay dosya sistemlerini birinci sınıf özellik olacak kadar katmanlayacaksanız, bence doğrudan değiştirilebilir sistem kullanmak daha mantıklı değil mi
      10 yıl önce herkesin NoSQL’e koşup hemen ardından her projenin içinde şemayı yeniden icat etmesini hatırlatıyor
    • Flatpak uygulamalarına da eklenti eklenebilir; bu eklentileri genişletme paketi olarak yapmak yeterli
      OBS bunun bir örneği. Flathub’da com.obsproject.Studio.Plugin.* biçiminde birkaç OBS eklentisi var

  • Tanımı şöyle yapmak iyi olur: İstediğiniz kadar paket kurduktan sonra gelecekte herhangi bir zamanda, herhangi bir sırayla kaldırdığınızda, en başta hiç kurulmamış olmalarıyla eşdeğer bir duruma dönülmeli
    Bu tanım bazı dağıtımları dışarıda bırakır, ama bence bu kavramın önemli kısmı tam da bu özellik

    • Kullanıcıya yönelik sistemlerde bu niteliğin fiilen imkânsız olması asıl nokta gibi görünüyor
      Bir kelime işlemciyi veya metin düzenleyiciyi sildiğinizde, onunla yazdığınız tüm dosyaların da birlikte yok olmasını ister misiniz? Tarayıcıyı silerseniz indirdiğiniz tüm dosyalar da silinmeli mi? Değilse hangi dosyanın program tarafından otomatik oluşturulduğunu, hangisinin kullanıcının o programla oluşturduğu dosya olduğunu güvenilir biçimde ayırmanın yolu yok
      Kurulum sırasında oluşturulanlar kolayca kaldırılabilir, ama sonrasındaki tüm değişiklikler için bu mümkün değil
      DNS uygulamasını değiştirip daha sonra varsayılan DNS sunucusunu değiştirdiğiniz bir durumu da düşünebiliriz. Provider’ı kaldırıp önceki uygulamaya dönerken eski sunucuya da geri mi dönüleceği, yoksa yeni sunucu ayarının korunup korunmayacağı seçilmeli. Kişisel olarak yalnızca provider’ın değişmesini, yeni sunucunun korunmasını isterim
      Birden fazla makinenin paylaştığı dizinler de işi zorlaştırır. /home/${USER} NFS veya Samba mount’u olarak duruyor ve birden çok iş istasyonunda aynı dosyalar kullanılıyorsa, bir program XDG yapılandırma dizinine dosya oluşturduğunda ve o program bir iş istasyonundan kaldırıldığında tüm makinelerdeki dosyalar da silinmeli mi? Tüm aygıtların aynı mı olması gerektiğini, yoksa yalnızca home dizininin aynı olmasının yeterli mi olduğunu tek bir sistemin paket yöneticisinin bilmesine imkân yok
    • Mesele, bu özelliği ne kadar derine uygulamak istediğiniz
      Benzersiz gösterimli veri yapıları ve geçmişten bağımsız veri yapılarına bakmaya değer
      Blok aygıtlarının, örneğin SSD’lerin, blokları geçmişten bağımsız biçimde tahsis etmesi için özel olarak dikkat etmek gerekecektir
    • Buna yeniden üretilebilirlik denilen özellik denir; aynı yapılandırmanın her zaman aynı sistem durumunu üretmesi anlamına gelir
    • Bu tanımı sevdim
      Paket kümesinin bir kafes oluşturduğunu ve paketlerin herhangi bir alt kümesine hangi yoldan ulaşılmış olursa olsun durumun tek olduğunu da söyleyebiliriz

  • Fedora Silverblue’u çıktığı günden beri kullanıyorum ve bu kesinlikle gelecek
    Bence herkes ostree kullanmalı

    • Silverblue’un kişisel bilgisayarlar için yeterince esnek olmadığını hissettim
      Belki Linux’u biraz doğaçlama kullanıyorumdur ama /usr ya da /bin gibi klasörlere yazma yetkimin olmaması iki haftada bir beni çıldırttı
      Örneğin Ubuntu kullanıcısının yazdığı bir betik, kütüphaneyi Ubuntu’daki adı ve konumuyla arıyordu; Fedora ise o kütüphane için farklı bir ad kullanıyor. Böyle bir durumda içgüdüm, Ubuntu adında bir sembolik bağlantı oluşturup Fedora RPM’in yönettiği kütüphaneye işaret ettirmek oluyor
      Ama pratikte çalıştırmak için betiği fork’lamam, yerelde derlenecek hale getirmem, iki kütüphane adını da arayacak şekilde düzeltmem, yerel testleri çalıştırmam, upstream’e PR göndermem vb. gerekti. Normalde tek satırlık shell komutuyla bitecek iş 90 dakikalık bir işe dönüştü
    • 1 yıldır kullanıyorum ve gerçekten çok iyi. Red Hat’in elinde ne olduğunun farkında olup olmadığını merak ediyorum. Sadece Silverblue değil, Fedora’nın kendisi de öyle
      Quora’daki bir yanıtta Windows OS geliştirme bütçesinin maaşlar bazında yaklaşık 18 milyar dolar olarak tahmin edildiğini okumuştum. Red Hat’in Fedora’ya 2 milyar dolar yatırıp onu masaüstü OS dünyasının Firefox’u yaptığını hayal edin; Microsoft’a karşı yalnızca %10 pay almak bile çok büyük olurdu
      Binlerce açık kaynak paketinin üzerinde, bu kadar az kaynakla buraya kadar gelmiş durumda. O para, bu tür projeleri yaşatmaya ve geliştirme sırasında desteklemeye harcanabilir. Red Hat çalışanları zaten bu projelerin birçoğunda yer alıyor
    • ostree fikrini seviyorum ama kabaca göz attığım kadarıyla sıradan ya da orta seviye kullanıcı için Docker kadar dostane görünmedi. Docker’ı bireysel bir kullanıcı bir öğleden sonra öğrenebilir
      “Debian dağıtımını ostree snapshot’ı olarak dağıtma” noktasına nasıl gelindiği net değildi
      Bunun yalnızca profesyonel sistem yöneticileri ya da sistem oluşturucular için mi tasarlandığını merak ediyorum
    • Nix kullandıysanız karşılaştırmanın nasıl olduğunu merak ediyorum
      Silverblue kullanmadım ama Nix de gelecek gibi hissettiriyor
    • Şu anda sunucumda Ubuntu kullanıyorum ve depoda ostree olduğunu gördüm ama henüz deneme fırsatım olmadı
      Mümkünse mevcut sistemimi olduğu gibi sürüm kontrolüne almaya başlamak isterim. Bu çok zorsa ya da imkânsızsa bir gün sunucuyu Silverblue’ya taşımayı düşünüyorum. ostree fikrini gerçekten çok seviyorum

  • Bu yaz Tinycore’a sardım
    Birkaç gün önce burada konuştuğumuz Qubes, Tails ve Whonix’in temelindeki “bir OS’ye bir işlev” güvenlik felsefesini iyi tamamlıyor
    O kadar hafif ki posta sunucusu için bir VM, veritabanı için bir VM, güvenlik duvarı/yönlendirici için bir VM’i birkaç saniye içinde ayrı ayrı ayağa kaldırabiliyorsunuz
    Tinycore’un kendisi immutable olduğu için vdisk’e “paketleri” ve yapılandırmayı koyup salt okunur olarak işaretlemek yeterli. Bir Virsh betiği “servis”in başlatılıp durdurulmasını yönetiyor ve her servis bir Tinycore instance’ı oluyor
    Eğlenceli ve şimdiye kadar sağlam, ama henüz birinin prodüksiyonuna koyup koymayacağımdan emin değilim

    • TinyCore bu tür immutable Linux tanıtımlarında hep atlanıyor. Uzun zamandır var ve tasarımı da harika
      Uygulamasında eksik taraflar var ve insanların neden pek bilmediğini açıklayacak kurumsal bir sponsorluğu da muhtemelen yok
      Diğer immutable Linux dağıtımlarından farklı olarak sağlam ve basit

  • Fedora Sericea çıktığından beri sürekli kullanıyorum. Temelde Fedora Silverblue, ama Gnome-wm yerine Sway-wm kullanıyor
    Gerçekten gayet kullanılabilir ve her rpm-ostree install komutundan sonra yeniden başlatmanız da gerekmiyor. rpm-ostree live-apply bunu systemd tabanlı overlay ile hallediyor

    • Son 2 haftadır Fedora Workstation kullanıyorum ve Linux’u 20 yıl sonra yeniden deneyen biri olarak deneyimin muazzam biçimde iyileştiğini söyleyebilirim
      Henüz Windows’a yeniden boot etmem gerekmedi. Önümüzdeki 6 ay boyunca da bu durum sürerse tamamen Linux’a geçip Windows bölümünü sileceğim
    • Yine de yeni çekirdeği gerçekten uygulamak için yeniden başlatma gerekmez mi? Yoksa çekirdeğin kexec gibi bir şeyle değişip değişmediğini merak ediyorum

  • “Immutable’lık bir yalan; sistemin büyük kısmı değiştirilebilir. Yalnız bu aileyi başka nasıl tarif etmek gerekir bilmiyorum, transaction bir şeyler mi?” sözüne gelirsek, Nix söz konusu olduğunda odak daha çok yeniden üretilebilirlik üzerinde gibi geliyor
    Nix yapılandırma dosyasını başka bir bilgisayara koyarsanız /home civarı hariç aynı sistemi elde etmeniz gerekir anlamına geliyor gibi görünüyor
    Diğerleri ise mevcut araçların sunduğu snapshot ve rollback işlevlerini farklı bir uygulamayla sunmaya daha yakın görünüyor

    • “Immutable” sözcüğü buraya yapıştırmak için garip
      Canlı sistemde sistem yükseltmesi yapmamak, paket değişikliklerinin bir sonraki açılışta uygulanması ve değişikliklerin geri alınabilmesi anlamına geliyorsa bu, veritabanlarındaki atomik transaction’lara daha yakın. Yalnız commit etmek için sistemi kapatmak zorunda olmak biraz fazla
      Microsoft birkaç yıl önce dosya sistemine atomik transaction eklemişti, ancak dosya sistemi transaction’ları pek kullanılmadı
      Kurulum sisteminin tüm değişiklikleri tek seferde commit etmesi ve kurulum sırasında sorun çıkarsa hiçbir şeyi commit etmeden önceki duruma rollback yapabilmesi iyi olurdu. Teoride transaction dosya sistemiyle mümkün olurdu, ama pratikte dosya sistemi dışındaki çok fazla durumun işin içine gireceğini düşünüyorum

  • Sunucu tarafında Amazon’un Bottlerocket OS’i var
    Fikir, yükseltmeler için A/B partition kullanmak ve temel sistem olmayan her şeyi container olarak çalıştırmak
    Açılışta kullanıcıya özel yapılandırmalar için boot container kullanılıyor; uzun süre çalışan servisler için host-container ya da Kubernetes’te DaemonSet kullanılıyor
    https://github.com/bottlerocket-os/bottlerocket