GoboLinux: Dosya sistemini paket veritabanı olarak kullanan deneysel Linux dağıtımı

 (gobolinux.org)
3 puan yazan GN⁺ 2024-03-01 | 1 yorum | WhatsApp'ta paylaş
  • Geleneksel Linux dağıtımlarındaki dizin alışkanlıklarını büyük ölçüde değiştirerek sistem yapısını program başına dizinler üzerinden anlamayı sağlayan deneysel bir dağıtımdır
  • Ayrı bir paket veritabanı yerine dosya sisteminin kendisini veritabanı olarak kullanır; programlar /Programs/Nano/8.3 gibi yollarda sürümlerine göre yerleştirilir
  • En yeni sürüm 017.01, önceki ISO sürümünden yaklaşık 5 yıl sonra gelen bir hata düzeltme güncellemesidir ve bu süre içinde ortaya çıkan bazı önemli sorunları ele alır
  • Kurucu Hisham Muhammad, 25 yıllık yönetimin ardından görevden ayrıldı; projeyi GitHub kullanıcısı @fyrak1s devraldı
  • Live ortam olarak doğrudan çalıştırılabilir veya sabit diske kurulabilir; böylece geleneksel dağıtımlardan farklı dosya sistemi yapısı pratikte denenebilir

Paketleri dosya sistemiyle düzenleme yaklaşımı

  • GoboLinux, tüm dosya sistemi hiyerarşisini yeniden tanımlayan deneysel bir Linux dağıtımıdır
  • Temel fikir, ayrı bir paket veritabanı tutmak yerine dosya sistemini veritabanı olarak kullanmaktır
    • Her program kendi dizinine yerleştirilir
    • Örnekler: /Programs/Nano/8.3, /Programs/GCC/14.2.0
  • Yapısı geleneksel Linux dağıtımlarından farklı olduğu için, ilk kez kullanacakların önce belgeleri okuması iyi olur

017.01 sürümü ve yönetimin devri

  • Güncel sürüm 017.01’dir
    • USB sürücülerden ve DVD’den çalıştırılabilen bir Live ortamdır
    • Sabit diske de kurulabilir
    • ISO, Downloads sayfasından indirilebilir
  • v017.01, yaklaşık 5 yıllık aradan sonra çıkan bir hata düzeltme güncellemesidir
    • Önceki ISO sürümünden sonra ortaya çıkan bazı önemli sorunları ele alır
    • Ayrıntılı değişiklikler release notes sayfasında görülebilir
  • Projenin yönetimi de değişti
    • Kurucu ve 25 yıl boyunca GoboLinux’a liderlik eden Hisham Muhammad resmen görevden ayrıldı
    • Proje, @fyrak1s yönetimi altında devam ediyor
    • Lucas Correia Villa Real, diğer adıyla paranoidd, Haziran 2021’e kadar Hisham ile birlikte GoboLinux’un bakımını yürütmüştü
  • Topluluk merkezleri sohbet, forum ve wiki olarak ayrılıyor

İlgili okumalar

1 yorum

 
GN⁺ 2024-03-01
Hacker News yorumları

  • GoboLinux tasarımına karşı güçlü bir ani reddetme hissi duyan biriyseniz, 20 yıllık “I am not clueless”¹ belgesinde arka plan ve mantığın epey fazlası var
    Reddetme hissim hâlâ tamamen kaybolmuş değil, ama eskisi kadar güçlü de değil ;)
    ¹ https://gobolinux.org/doc/articles/clueless.html

    • Yazının havası HTMX veya Tailwind belgelerine benziyor
      “Farklı olduğumuzu biliyoruz. Çok basit. Alışık olmayabilirsiniz ama anlaması ve yönetmesi kolay. Kullanmak zorunda değilsiniz. Biz bunu seviyoruz ve memnunuz” diye özetlenebilir
    • Bağlantı verilen yazıdaki make all programs relocatable bölümünde tüm uygulamaların libprefix kullanacak şekilde yeniden yazılması gerektiği söyleniyor; burada libprefix ile ne kastedildiğini merak ediyorum
      Web aramasında işe yarar bir sonuç çıkmıyor
    • Refleksif reddetme hissinin önemli bir kısmının işlevsel unsurlardan çok görsel tasarımdan kaynaklanıp kaynaklanmadığını merak ediyorum
      Örneğin ilk tepkinin önemli bir kısmı büyük harf kullanımından geliyor; büyük P’li Programs, Windows’taki Program Filesı çağrıştırdığı için duygusal olarak itici geliyor
      libx11 yerine LibX11 yazmak zorunda kalsam biraz sinir bozucu olurdu gibi de geliyor
      Linux dosya sistemi genelde büyük/küçük harf duyarlıdır, ama paket adları yalnızca büyük/küçük harfi farklı olan tekrarları muhtemelen önler; kullanıcı dostu bir katmanı hedefleyen bir dağıtımın kökte yalnızca büyük/küçük harfi farklı dizinler koyması da pek olası görünmüyor
      Yine de örnekler /packages/libx11/1.6.9, /packages/gcc/9.2.0 olsaydı ilk tepki çok daha hafif olurdu gibi geliyor; bu adlarla da avantajlar hiç azalmazdı

  • GoboLinux fikrinin ana akım Linux topluluğunda yer edinememiş olması gerçekten üzücü
    Linux’un dosya sistemi yapısı tam bir karmaşa

    • Katılıyorum, ama Nix, Guix ve en çok üzerinde çalıştığım Spack’in temelde aynı yönde ilerleyip giderek güç kazanmasını görmek sevindirici
      Bunu düzgün çalışır hâle getirmek her zaman önemsiz değil; verimli yapmak daha da zor
      Ancak son birkaç yılda, yazılımların çoğunun dağıtımı için bu modelin gerçekten sürdürülebilir bir düzeye yaklaştığını hissediyorum
    • Nix giderek popülerleşiyor
      GoboLinux modelinde /Programs/Xorg/7.0 gibi sürüm dizinlerini elle yönetmek gerekiyor; Nix ise paketin kurulum yolunu derleme tarifinin hash’ine göre belirleyerek bu sorunu ortadan kaldırıyor
    • Şu anda tutarlı biçimde anlamlı olanların ancak /home ve /tmp olduğunu düşünüyorum
      Geri kalanı, istediğini istediğin yere koyduğun bir ıvır zıvır yığınına yakın
    • O fikirler kesinlikle bana ilham verdi
      GoboLinux, Linux’ta gerçekten istediğin gibi yapabileceğini bana ilk gösteren projeydi
    • /opt ve /srv, zevke göre de /usr/local/opt, bileşenleri GoboLinux’taki gibi tek tek yönetmenin avantajlarını epey sunuyor
      Dağıtım açısından bakınca her şeyin kendince bir mantığı var
      dpkg -S this-file yazınca /usr içindeki bir dosyanın neden orada olduğunu hemen anlayabiliyorsunuz; dağıtım da büyük resmi çizme rolünü üstleniyor
      En çok hangi kısmı dağınık bulduğunuzu merak ediyorum

  • Geleneksel yolları GoboLinux’taki karşılıklarına eşleyerek Unix mirasıyla uyumluluğu şeffaf biçimde koruması ilginç
    Özel bir sihir yok; /bin, /System/Index/bin bağlantısı ve /usr/bin ile /usr/sbin de aynı şekilde tüm “binary” dizinlerinin aynı yere işaret etmesini sağlıyor
    Bu sayede hangi standart yoldan erişilirse erişilsin dosya çalışıyor; dolayısıyla gerçek dosyanın /usr/local/bin/foo altında olduğu ama betiğin /usr/bin/fooya başvurduğu için bozulduğu sıradan dağıtımlardan aslında daha uyumlu bile olabilir

  • Bilmediğim için soruyorum: macOS bir ölçüde böyle mi çalışıyor?
    Uygulamaların her zaman sürükle-bırakla yönetilen tek bir “dosya” gibi görünmesi gerçekten hoşuma gitmişti
    Ubuntu’da bir şeyin nerede olduğunu ve nereye kurulduğunu anlamaya çalışınca kendimi aptal gibi hissediyorum

    • Ubuntu’da neyin nerede olduğunu ve nereye gittiğini anlamanın zor olması, Linux dosya yöneticilerinin ana klasör veya bağlı sürücüler olmayan dosya sistemi kısımlarını gizlemeye çalışmasıyla daha da kötüleşiyor
      Neden yaptıklarını anlıyorum
      Ortalama bir Linux kurulumunun dizin yapısı teknik kişiler için bile kafa karıştırıcı bir labirent; büyük dağıtımların hedeflediği sıradan kullanıcılar için daha da öyle
      Ama sonuçta bu, nedeni değil semptomu ele alan bir yaklaşım; daha fazla Linux dağıtımının Gobo gibi dosya sistemi yapısını modernleştirmeyi ciddi biçimde düşünmesi gerektiğini düşünüyorum
      Kendim de denemek istiyorum
      Hedef, makul ölçüde kendi kendini açıklayan, acemileri tehlikeli alanlardan uzak yönlendiren ve dosya yöneticisinin neredeyse hiçbir şeyi gizlemese bile sorun çıkarmayan bir yapı oluşturmak
    • macOS’in bundle yaklaşımı iyi bir fikirdi ve hâlâ iyi, ama uygulamalar yine de genelde ~/Library gibi tuhaf konumlara bir şeyler saçıyor
      Minecraft başlatıcısı gibi her şeyin, dünyaların ve kayıt dosyalarının bile bundle içinde olduğu durumlar ilginçleşiyor
    • İlke olarak uygulamanın tek bir “dosya” gibi görünmesine katılıyorum, ama pratikte birçok uygulama ~/Library ve /Library içine çeşitli dosyalar koyuyor
      macOS’te bile bazı uygulamaları silmek için birden fazla manuel silme adımını izlemek gerekmesi nadir değil
      Özellikle giriş öğeleri ekleyen uygulamalarda bu daha önemli
      Windows’un Program Ekle/Kaldır aracı en azından kaldırmayı çalıştırmak için merkezi bir nokta sunuyor ve çoğu uygulama bu yönteme düzgün uyuyor
    • Fedora’da rpm veritabanını sorgulamak basit
      dpkg ile de aynı şey yapılamıyor mu?
    • Mac’te tam da bu noktadan gerçekten nefret ediyorum

  • İlk dizin adının büyük harfle başlaması pek iyi değil
    Yolda gezinirken ek bir iş gibi hissettiriyor; her seferinde harf ya da rakamla birlikte Shift’e basmak, günlük komut satırı kullanımında epey can sıkıcı

    • Yukarıda bağlantısı verilen yazıya göre, GoboLinux’un varsayılan kabuğu gibi doğru ayarlanmış bir kabukta /Programs yazmak, /usr ile tam olarak aynı sayıda tuş vuruşu gerektiriyormuş
      Slash, küçük p, Tab yeterli
    • PowerShell ya da cmd.exe’de gezinirken bunun neden hiç rahatsız etmediğine gelince: kabuk yardımcı oluyor
      Kullanılabilirlikten feragat edip PDP-11’in kıymetli tiklerini ve belleğini korumaya zorlamıyor
      “Büyük/küçük harf duyarlılığı en iyisi!” diyen hayranların, bunun aslında ilk sistemin kısıtlarından doğmuş bir sonuç olduğunu kaçırması hep komik geliyor
      Bu bir özellik değil
      Üstelik bu konu açıkça ele alınmış
      Sadece set completion-ignore-case On bile hayatı ciddi ölçüde kolaylaştırır
      Çünkü GoboLinux kullanmasanız bile büyük harfle başlayan her dosya adında Shift’e bir kez daha az basarsınız
      Ya da 1977’deki gibi yaşamaya devam edebilirsiniz
      Sizin VT100’ünüz, sizin kurallarınız
      Sonradan “neden normal gezinme için bash’i olduğu gibi kullanmayıp başka kabuk kuruyorsun” dendiğini gördüm; bu, kişinin kendi kabuğunu bile doğru dürüst bilmediği anlamına geliyor
    • İlk bakışta bunun bir dizin mi yoksa normal dosya mı olduğunu ayırt ettiren bir teamül olarak hoşuma gidiyor
      Ayrıca herhangi bir kabuk büyük/küçük harf duyarsız otomatik tamamlama sunabilir; Fish bunu varsayılan olarak yapıyor
    • Büyük harflerin amacı FSH/eski dizinlerle çakışmayı önlemek
    • Beğenmedim
      Windows hissi veriyor

  • Bu projenin bilişsel yükümüzü epey azaltma potansiyeli var
    Başarılı olmasını isterim
    Düzenleme: Şimdi fark ettim, 20 yıllık bir projeymiş

  • Öylesine mantıklı ki insanın gözleri doluyor
    Kütüphanelerin birden fazla kopyasını tekilleştirme işini, gerçekten gerekliyse dosya sistemi halledebilir
    Sonuçta dosya düzeyinde bir yineleme söz konusu; o yüzden o düzeyde çözülmeli

  • Çok kötü kapalı kaynak uygulamalar, kullanıcının sisteminden çok fazla şey bekliyor
    Steam istemcisi buna bir örnek: sh betiği değil bash betiği sağlıyor; Linux mount userspace konteyner gereksinimleri nedeniyle Debian/Ubuntu tarzı dosya yerleşimini güçlü biçimde varsayıyor ve çeşitli komutların GNU’ya özgü garip seçeneklerini de istiyor
    32 bit kütüphaneler de çok
    Yine de ABI’yi hâlâ kontrol altında tutuyor gibi görünüyorlar; muhtemelen binutils gas’in .symver yönergesini kullanıyorlar
    En azından mevcut karmaşa Steam tarafından boğazımıza itiliyor ve oyun oynatmayan bir dağıtım değilse bundan kaçınmak zor

    • Çoğu insan oyun oynamıyor; Linux kullanıcıları arasında da birçok kişinin baştan sahipli uygulama kullanmayacağını sanıyorum
      Oyuncu kitlesi içinde bile kayda değer bir kısmın ayrıca oyun için ayrılmış bir PC’si olması oldukça olası

  • Benden çok daha zeki biri, bunun neden snap/Flatpak ya da NixOS gibi dağıtımlardan daha iyi olduğunu, ya da gerçekten daha iyi olup olmadığını açıklasa iyi olur
    Derinlemesine anlamadan dışarıdan bakınca bu yaklaşım en basiti gibi görünüyor
    Elbette bunu kendi bilgi eksikliğimi varsayarak söylüyorum

    • Sadece her uygulamayı kendi klasörüne koymaktan söz ediyorsak, bu tek başına izolasyon için yeterli değil ve ne kadar ileri götürdüğünüze bağlı olarak inanılmaz derecede müsrif olabilir
      Flatpak ve NixOS’un daha karmaşık olmasının geçerli sebepleri var
      Örneğin diskte bağımlılıkların tam olarak aynı sürümünü tekrar tekrar saklamazlar
    • snap ve Flatpak daha çok dağıtıma odaklanıyor ve “sandbox” içinde çalışıyor
      Tırnak kullanmamın nedeni güvenlik sorunları olması
      NixOS mevcut programlarla uyumluluğu bozarken Gobo bunu yapmıyor
      Ancak NixOS’un paket deposu Gobo’ya kıyasla ezici biçimde daha iyi yönetiliyor; Gobo tarafı eksik ve yıllarca geriden geliyor
      Yine de burada anılanların hepsi, Android’in uygulamaları saklama biçiminin gerisinde kalıyor
      Android’de her uygulama dağıtımı kolay tek bir dosya olarak dağıtılabiliyor, düzgün biçimde sandbox’a alınıyor ve kendi dizinine sahip oluyor
      Diğer yaklaşımların kaçırdığı bir nokta da şu: Her uygulamanın kendi durumunu saklamak için uygulama dizini altında bir alt dizini var ve bu kullanıcı bazında da ayrılıyor

  • GoboLinux geliştiricileri, insanların anlayabileceği bir dosya sistemi yerleşimini gerçekten “akıllıca” oluşturmuştu
    Bugün kullandığımız eski UNIX teamüllerinin; 8.3 ad sınırı, depolama alanı yetersizliği, 1 GB üzeri dosya sorunları gibi kısıtların artık olmadığı bir çağda epey anlaşılmaz kaldığını düşünüyorum
    Eskiden sürüm kontrol yazılımlarını barındıran bir sunucuda GoboLinux 012~015’i birkaç yıl çalıştırdım ve genel olarak çok iyiydi
    Takıldığım nokta, gereken paket yoksa recipe yazmak zorunda kalmaktı
    GoboLinux’un recipe yazma dili başlı başına anlaşılması kolaydı; ancak bir paketin çoğu zaman on küsur ya da onlarca kütüphaneye bağımlı olması yüzünden bunları izlemek, sürümleri eşleştirmek, kütüphane ve paket URL’lerini bulmak, sonra yeniden recipe hazırlamak için çok zaman harcadım
    Sonunda Debian’a geçtim ama yapılandırma dosyalarının hâlâ /etc altında, ikili dosyaların da /usr/bin ya da /usr/local/bin içinde olduğunu görünce hâlâ irkiliyorum
    systemd’nin zahmetli ve ahtapot gibi olduğunu düşünen taraftayım
    İlgili .service dosyasını bulmak için sık sık find kullanmak gerekiyor; tek bir yerde olduğuna güvenemiyorsunuz ve komut satırı da sezgisel değil
    Buna karşılık Gobo’da servisleri yöneten betik seti çok basitti ve kullanması kolaydı
    Yine de gereken şeyi apt get ya da dpkg -i ile hemen kurabilme rahatlığı, GoboLinux’un çok daha makul olan akıllı tasarımına ağır basıyor
    Günümüzde desteklenen Linux dağıtımlarının sayısı, eskiden olduğu gibi sayısız seçenekten azaldı; neredeyse her zaman Debian veya Ubuntu varsayılan olarak dahil edildiği için depo dışında olsa bile bir paketi ya da programı kuramama ihtimali düşük
    macOS da kesinlikle GoboLinux’a benzer bir yaklaşımı bir ölçüde kullanıyor; bu yüzden son dönemdeki epey kullanıcı düşmanı sürümlerden önce macOS’u komut satırından yönetmek oldukça kolaydı
    Örneğin USB sürücüler /Volumes altında, program yapılandırma dosyaları ise ~/Library altında bulunur

    • Bu arada servis yüklenmişse, yalnızca systemctl status foo çalıştırmak bile ikinci satırdan itibaren hangi dosyaların işin içinde olduğunu tam olarak söyler
      Örneğin systemctl status getty@tty1.service çıktısında Loaded: loaded (/lib/systemd/system/getty@.service; enabled; preset: enabled) gibi göründüğü için /lib/systemd/system/getty@.service dosyasını doğrudan öğrenebilirsiniz