Flatpak systemd'ye bağımlı hale gelebilir

 (osnews.com)
1 puan yazan GN⁺ 2 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Flatpak, uzun süredir “tüm dağıtımlar için uygulama derleme” avantajını öne çıkarıyordu; ancak bir sonraki büyük sürümde systemd bağımlılığı kazanma ihtimali giderek artıyor
  • Flatpak Next veya Flatpak 2.0, mevcut 1.x sürümünün on yıllara dayanan tasarım sınırlarını aşmak için neredeyse bir yeniden yazım niteliğinde ve hâlâ planlama aşamasında
  • Yeni hizmet systemd-appd, uygulama kimliklerini ve izinlerini saklayıp diğer bileşenlerin bunları sorgulamasını sağlayacak; ayrıca alt sandboxing'i mümkün kılan temel rolü üstlenecek
  • systemd kullanmayan dağıtımlar için elogind benzeri bağımsız bir daemon uygulaması ihtimali vardı; ancak tartışmalar büyüdükten sonra geliştiricilerin bu konuda hassasiyet gösterme isteğinin azaldığı görülüyor
  • systemd bağımlılığı katılaşırsa Void, Guix ve Alpine gibi dağıtımlarda Flatpak kullanımı zorlaşabilir ve dağıtımdan bağımsızlık da zayıflayabilir

Flatpak'in dağıtımdan bağımsızlığında olası değişim

  • Flatpak web sitesi, ilk avantaj olarak “Build for every distro: create one app and distribute it to the entire Linux desktop market.” ifadesini öne çıkarıyor ve desteklenen dağıtımlar listesinde Void Linux, Guix, Alpine gibi systemd dışı init sistemleri kullanan dağıtımlar da yer alıyor
  • Şu anda Flatpak, kullanıcının hangi init sistemini kullandığıyla ilgilenmiyor; ancak bir sonraki büyük sürümde systemd bağımlılığı ortaya çıkma ihtimali yüksek
  • Bu değişiklik gerçekten uygulanırsa, systemd kullanmayan dağıtımlarda Flatpak'in sunulmaya devam edip edemeyeceği temel tartışma konusu olacak

Flatpak Next ve yeniden tasarım yönü

  • Arian Vovk ve Sebastian Wick, Linux App Summit'te Flatpak'in geleceğini ele alan bir sunum yaptı
  • Mevcut Flatpak sürümü geliştirilmeye devam edecek olsa da, on yıllara dayanan tasarımın sınırlarını dolanmak giderek zorlaşıyor
  • Flatpak Next veya Flatpak 2.0 olarak anılan çalışma, Flatpak 1.x sonrasında biriken deneyimleri yansıtan fiilî bir yeniden yazıma yakın
  • Yeni tasarım, Flatpak'in ilk tasarımından sonra yerleşen modern teknolojiler ve fikirlerden yararlanacak şekilde planlanıyor
  • Sunumda anlatılanlar henüz plan aşamasında; tek satır kod bile yazılmadığı için önümüzdeki birkaç yıl içinde çalışma ilerledikçe sonuçlar önemli ölçüde değişebilir

systemd-appd ve izin yönetiminin taşınması

  • Flatpak'in geliştirme yönündeki temel değişiklik, izin yönetimini Flatpak'in içinden çıkarıp hizmet katmanına taşımak
  • Yeni hizmet systemd-appd, uygulamalara kimlik verecek, izinleri saklayacak ve sistemin diğer bileşenlerinin bu verileri sorgulamasına imkân tanıyacak
  • Bu yapı birçok özelliği mümkün kılıyor; özellikle alt sandboxing (subsandboxing) önemli bir yetenek olarak öne çıkıyor
  • Mevcut plan, bu özelliği bugünkü Flatpak sürümüne eklemek; bunun sonucu olarak Flatpak systemd'ye bağımlı hâle gelecek

systemd kullanmayan dağıtımlar için alan

  • Vovk'un açıklamasına göre, systemd kullanmayan dağıtım ve kullanıcılara karşı “çok hassas” olma niyeti vardı
  • Öngörülebilir model, systemd-logind'in ayrı bir daemon olan elogind olarak ayrılması ve böylece farklı init sistemleri kullanan dağıtımların da systemd-logind'e bağımlı masaüstü ortamlarını kullanabilmesine benziyordu
  • Flatpak geliştiricilerinin de systemd-appd için benzer bir bağımsız daemon uygulamasını mümkün kılacak gerçekçi alanı olabildiğince bırakmaya çalıştığı anlaşılıyor
  • Bu yaklaşım korunmuş olsaydı, Flatpak'in systemd kullanmayan dağıtımlarda da sunulmaya devam etme ihtimali vardı

Tartışmanın büyümesi ve geliştirici tutumundaki değişim

  • Void veya Alpine gibi dağıtımların kullanıcıları, Flatpak systemd'ye güçlü biçimde bağımlı hâle gelirse kendi sistemlerinde artık çalışmayabileceği yönünde kaygı dile getirdi
  • Sorular, Flatpak geliştirmesine teknik olarak dâhil olmayan bir kişiye yöneldi ve verdiği yanıtlar kimi zaman yararlı olmadı, kimi zaman aşağılayıcı ve kışkırtıcı bulundu
  • Onun Flatpak geliştirmesine dâhil olduğu yönündeki yanlış kanaat yayılınca, ciddi ve dostane sorular ile systemd karşıtı sert tepkiler birbirine karıştı ve durum kötüleşti
  • Bunun sonucunda Flatpak geliştiricileri, systemd kullanmayan dağıtım ve kullanıcıları gözetmek için zaman harcamak istemediklerini belirten bir tepki göstermeye başladı
  • Bu eğilim sürerse systemd bağımlılığı daha da katılaşabilir ve systemd-appd işlevlerini kopyalayacak bağımsız bir daemon uygulaması geliştirmek, başlangıçta öngörülenden çok daha zor hâle gelebilir

Beklenen sonuçlar ve anlamı

  • Mevcut tabloda, önümüzdeki birkaç yıl içinde Flatpak'in systemd bağımlılığı kazanma ihtimali yüksek görünüyor
  • systemd kullanmayan dağıtımların systemd-appd işlevlerini ikame edecek bağımsız bir daemon geliştirebilmesi için bırakılan alanın da ortadan kalkma ihtimali var
  • Böyle olursa Flatpak, artık tek bir uygulamayı tüm dağıtımlara ulaştırabilen dağıtımdan bağımsız çözüm olduğunu savunmakta zorlanabilir
  • Flatpak, kullanıcı hangi init sistemini kullanırsa kullansın gerçek talebi olan bir araç olduğu için, bu değişim Linux masaüstü uygulama dağıtımının kapsamını doğrudan etkileyecek

İlgili okumalar

1 yorum

 
GN⁺ 2 시간 전
Lobste.rs görüşleri

  • systemd'den neden bu kadar nefret edildiğini anlamıyorum. Bana göre kullanımı kolay bir API ve makul bağımlılık/çakışma yönetimi ile faydalı işlevler sunuyor.
    systemd'den hoşlanmayanlar çoğu zaman yalnızca “Unix felsefesine uygun değil”, “merkeziyetçi”, “systemd-journald dosya formatı düz metin değil” gibi muğlak gerekçeler öne sürüyor.
    Karşı çıkılıyorsa somut nedenler ve çözümlerle birlikte, diğer init sistemlerinin neden daha iyi olduğunun da söylenmesini isterim. O zaman rc betiklerinin neden korkunç derecede dağınık hack'ler olduğunu anlatabilirim.

    • Bağlantısı verilen Mastodon tartışmasının büyük kısmı özünde systemd karşıtlığından çok merkeziyet karşıtlığı gibi görünüyor. Flatpak systemd'ye bağımlı hale gelirse, başka init sistemleri kullanan Linux türevleri flatpak erişimini kaybedecek.
      En azından benim için Linux felsefesi temelde seçimle ilgiliydi ve Flatpak'in belirli bir init sistemi gerektirmesi, kullanıcıların istedikleri sonucu elde etmek için sistemlerini yapılandırırken seçeneklerini azaltıyor.
    • systemd'yi gayet iyi kullanıyorum ama Flatpak örneğinde gelen tepkiyi anlıyorum. Flatpak özünde “herhangi bir Linux dağıtımında çalışabilmek” ile ilgili ve systemd bağımlılığı bunun faydasını bir miktar azaltıyor.
    • systemd'ye dair benim filtrelenmemiş şikayetlerim şunlar: journald uygulaması pek iyi değil ama fikrin kendisi fena değil ve systemd'nin birimleri yönettiği gerçek soyutlama olan iş kuyruğunda belgelenmemiş ya da bulunması zor garip sınır durumları var.
      Container image'lara koymayı daha kolay hale getirmeli ve kullanıcı systemd'si, sistem örneğine en azından After, Requires gibi şeylerle birim zamanlayabilmek için okuma API erişimine sahip olmalı.
      Yine de HAL'in kaldırılmasından beri Linux'ta olan en iyi şey olduğunu düşünüyorum ve hatta bir keresinde Lennart'la tokalaşıp proje için teşekkür etmiştim.
    • Chimera gibi gerçekten güvenilir bir alternatif yığın oluşturmaya çalışan taraflar FUD yaymıyor; nazik ve alçakgönüllüler. Buna karşılık çevrimiçi öfke kalabalığının açık bir çözümü yok ve muhtemelen hiçbir zaman da olmayacak.
      Bu “karşıtların” fiilen savunduğu şey, çözüm diye bir şeyin hiç olmamasına daha yakın. Linux'un HOA'sı gibi davranıyorlar; pratikte sağlam, kullanılabilir ve rekabetçi bir sistemin tekel işletim sistemlerini geride bırakabilecek ilerlemelerini engelleyen gerici bir siyaset gibi görüyorum.
    • Web sayfası sunan ya da GUI tarayıcıyla web sayfası gösteren sistemlerde kullanılacaksa systemd'den nefret etmiyorum. VPS'ye dağıtım yaparken systemd unit'lerini doğrudan kullanmak da sorun değil; SysV init ya da upstart olsa da büyük ihtimalle pek şikayet etmezdim.
      Ama dizüstünde istediğim şey farklı. Kişisel ortamımın nasıl çalışmasını istediğime dair fikirlerim var; sıradan Linux kullanıcısının istemeyeceği bazı kolaylıkları istiyorum ve açıkça istemediğim şeylerin olmasını istemiyorum. “Bir şeyi çalıştırmak için uğraşmak”tan çok “bir şeyi çalışmaz hale getirmek için uğraşmak”tan nefret ediyorum.
      NixOS'tan systemd yüzünden ayrılmama yol açan temel unsur, durmadan genişleyen kapsamı ve güçlü varsayılan tercihleri oldu. Güç yönetimi ve oturum açma süreçleri entegre edildikçe kapağı kapatınca her seferinde otomatik uykuya geçmesi gibi davranışları tekrar tekrar düzeltmek zorunda kaldım; linger kapsamındaki değişiklikler POSIX'in gerektirdiği nohup ve screeni bozdu; daha katı VT yönetimi ise “bir kez giriş yapıp birden fazla Xorg örneği çalıştırma” ya da “VT ele geçirme” gibi şeyleri systemd usulü yeniden tasarlamayı gerektirdi.
      Sonunda en az düzeyde init olan sinitin ve servis gözetimi olmamasının daha iyi olduğuna karar verdim; kabuk önyükleme betiklerimi kendim yazıp bazı sistem işlevlerini shell, bazılarını da Common Lisp ile gerçekleştirdim. Dizüstünde PostgreSQL gibi şeyler bir kez açılınca çalışmaya devam ediyor; durursa fark edebilirim ve yeniden başlatmak yeterliyse zaten basit, yetmiyorsa servis gözetleyicisi de yardımcı olamaz.
      Güvenimi kıran örnekler arasında, HDD üzerinde journald'nin soğuk önbellek durumunda log göstermesini dakikalarca bekleyip hiçbir çıktı alamamam, https://github.com/systemd/systemd/issues/2913 sorununu bizzat yaşamam ve nohupu bozmaktan çekinmemeleri var.
      Geliştirme sürecinde de https://github.com/systemd/systemd/issues/437 içindeki “iyi varsayılanlar sağlıyoruz ama varsayılanlar kötüyse dağıtım düzeltir” hissi veren tavır ve kararlı API sözü vermeye isteksiz görünen http://lists.freedesktop.org/archives/systemd-devel/… gibi yaklaşımlar güvenimi azalttı.
      Yine de bunlar eski şikayetler. systemd'nin bazı sorunları çözerken başka sorunlar yarattığını ve bunların ikisinin de aslında benim başlangıçtaki sorunlarım olmadığını gördükten sonra dizüstünde önyükleme için shell betiklerine geçtim; şimdi de mevcut düzeni korumanın maliyeti o kadar düşük ki systemd'yi yeniden denemem için bir neden yok. VPS'te ise Debian'ın alışıldık çerçevesi içinde systemd kullanıyorum.

  • Bu işin Flatpak geliştiricisi olmayan biri tarafından yanlış bilgiyle başlatılmış olması, sonra duygusal tepkileri tetiklemesi ve ilk başlık ilerledikçe daha sert ifadelerin eklenmesiyle insanların Flatpak projesine ve geliştiricilerin itibarına yüklenmesi sinir bozucu.
    Bunun sonucunda gerçek Flatpak geliştiricilerinin duygusal olarak etkilenip öfkeli kalabalıktan uzak durmak istemesi de şaşırtıcı değil.
    Herkesin sakinleşip meseleyi daha fazla büyütmemesini isterim. Şüphe ya da kaygı varsa gerçek bakımcılarla konuşulmalı, orta bir yol bulma isteğine destek gösterilmeli ve bunun tüm topluluğu temsil etmeyen belirli kişilerin yalıtık bir olayı olduğu gösterilmeli.
    systemd'ye bağımlı olma fikri kesinleşmiş bir karar değil de yalnızca bir fikir olduğu gibi, bakımcıların daha çeşitli projeleri desteklemeyi yeniden değerlendirme ihtimalinin de hâlâ kapanmadığını düşünüyorum.

  • systemd'de çalışmayan sistemlerin de desteklenmeye devam edebilmesi için insanların iyi geçinmesini isterim. Flatpak ve diğer container tabanlı yaklaşımlar, kullanıcıların hedef platformda kolayca derlenemeyen paketleri çalıştırmasına yardımcı oluyor; belirli bir yazılıma ihtiyaç duyulduğunda böyle sistemler üzerinde Flatpak çalıştırabilmek güzel olurdu.
    Container'lar da benzer bir rol oynuyor ama yeterince sıra dışı kurulumlarda x11docker gibi şeyleri düzgün çalıştırmak insanı bezdirecek kadar zahmetli olabiliyor.

    • 10 yılı aşkın süredir Void'i memnuniyetle kullanıyorum. En son ne zaman init sistemi ya da systemd entegrasyonu hakkında endişelendiğimi bile hatırlamıyorum. Void için harcanan tüm emeğe minnettarım.

  • Dizüstü bilgisayarımda Void kullanıyorum; çalışmak için verimli ve dokümantasyonu da oldukça iyi. Geliştiricilerin bugüne kadar yaptığı tüm işler için minnettarım ve umarım Flatpak’taki değişiklik çok büyük bir yük olmaz.

  • “Modern Linux bu; sadece systemd var.”
    Bu, Linux topluluğunun bir topluluktan çok WeWork’e daha yakın olduğunu çarpıcı biçimde hatırlatıyor. Etraftaki herkes Red Hat’in varlığına bağımlı maaşlar alırken, birileri de GNU readline üzerinde bedavaya hack’liyor.

    • Yazının şu noktada haksız olduğunu söylemek zor: “fanatik anti-systemd Red Hat komplo teorisyenlerini (ve daha kötülerini) kendine çekiyor” kısmı.

  • Bu aşamada kesin bir dille “bağımlı olacak” demek için çok erken; bu bana oldukça spekülatif görünüyor.

  • Başlığın, yazının gövdesinden çok daha kesin konuşması ilginç. Pek çok yorum açıkça sadece başlığa tepki veriyor; neyse ki hepsi değil ama bu internette yeni bir şey değil.
    Son zamanlarda lobste.rs’de de insanların sadece başlığa ya da uzun bir yorumun içindeki tek bir cümleye tepki verdiğini sık sık görüyorum; bu kaygı verici. Genelde akıllarına ilk gelen, çoğu zaman saldırgan yorumu, başka olasılıklara neredeyse hiç yer bırakmadan benimsiyorlar.
    Yazıyı okuyunca, Flatpak 2.0 söyleminde de benzer bir şey olmuş gibi görünüyor. Başka init sistemleri için alan açmaya çalışmışlar gibi, ama etrafındaki söylem hızla düşmanca bir hale gelince fiilen vazgeçilmiş.

  • Alternatif init sistemleri kullanan biri olarak bu gerçekten sinir bozucu. Bir dizüstü bilgisayarımı Alpine Linux ile çalıştırıyorum ve yalnızca glibc üzerinde çalışan yazılımları çalıştırmak için Flatpak kullanıyordum. Bu değişiklik beni o ortamı terk etmeye zorlayacak.
    systemd’den nefret etmiyorum. Gentoo sistemlerimin hepsi systemd tabanlı. Ama systemd’nin özgür ve açık kaynak yazılımları GNU/Linux’a giderek daha bağımlı hale getirme biçimini sevmiyorum.

  • Bu kesinlikle iyi bir şey.
    systemd, kararlı ve iyi tanımlanmış API’lere sahip daemon’lardan oluşuyor; dolayısıyla Flatpak’in bağımlı olacağı systemd parçası her neyse, birisi emek verirse bunu baştan temiz bir şekilde yeniden uygulayabilir diye düşünüyorum.
    Bu mümkün olan en iyi sonuç. Parçalanma azalır ve sıra dışı gereksinimleri olan insanlar için yeniden uygulama adına kararlı bir hedef ortaya çıkar.

    • İlk başta bunu ironi sanarak okumaya başladım ama değilmiş.
      systemd API’leri çoğu zaman man sayfalarında muğlak biçimde tanımlanıyor ve systemd tarafı başka implementasyonlar beklemediği için iki yönlü olarak kararlı ya da sürümlendirilmiş de değiller.
      notify socket API’si söz konusu olduğunda durum hatta sadece ters yönde kararlı. vsock desteğinin eklenmesi, libsystemd’ye bağımlı olmadan implementasyon yapan daemon’ları fiilen bozdu. Bu kırılmanın çok bilinmemesinin nedeni, vsock’un esasen sanallaştırma sınırları arasında systemd’den systemd’ye iletişim için kullanılmasıydı. Doğru tasarlansaydı, yalnızca o sınırda kullanılan bir genişletme olarak yapılırdı.
      “Daemon’lar” deniyor ama pratikte çoğu logind ve systemd; API yüzeyinin tamamını bu ikisi açığa çıkarıyor, bu yüzden birleştirip karıştırma imkânı sınırlı. Bunu birkaç DBus arayüzüyle, artık varlink ile ve tek bir kütüphane üzerinden yapıyorlar.
      systemd’yi değiştirmek istiyorsanız ya tamamını değiştirip iç modelini systemd tarzı API’ler sunacak şekilde zorla uydurmanız gerekir ya da önce systemd’nin API tasarım tercihlerini çözerek takılabilir backend’ler sunan bir ara katman oluşturmanız gerekir.
      Bu sorunla yıllardır uğraşıyorum. systemd’nin birçok tasarım ilkesinin makul olduğunu düşünüyorum ama mevcut tasarım, çoğu insanın ihtiyaç duymadığı karmaşıklığı ön tarafa yığıyor. Daha modüler ve değiştirilebilir bir tasarım mümkün; ayrıştırılabilir basit arayüzler tasarlamak ya da mevcut olanları yeniden kullanmak da nispeten kolay.
      Ama sorun, systemd API’sine bağımlı olmayı seçen yazılımlarda. Bunu başka şeylerle çalıştırmak için ya libsystemd’nin tamamına bağlı özellik desteğini ayıran yamaları upstream’e sokmanız ya da yeni münferit API desteği eklemeniz gerekiyor; ilki hiç başarılı olmadı, ikincisinin de yayın öncesi ve az kullanılan API’lerin bakım yükü nedeniyle kabul edilmesi zor.
      Bir başka yol da, yazılımın kullandığı API’leri tek tek implement etmek. Mesela API’lerin çoğunu implement etmeyen bir login1 DBus servisi kullanmak gibi. Ama bu durumda API’nin diğer kısımlarını değiştirmeye çalışan başka implementasyonlarla çakışıyorsunuz ve bir anda üç varyantı implement etmeniz gerekiyor: asıl temiz API, logind/systemd DBus API’si ve varlink için olan API.
      Uzun vadede, tüm systemd ya da logind API’sini implement edip arka tarafta ayrılmış API’lere bağlayan bir router çözüm olabilir. Ama mevcut tasarımda aşırı tekrar ve systemd’ye özgü bağımlılık o kadar gömülü ki bunu düzgün yapmak son derece karmaşık.
      Bunun amaçlanıp amaçlanmadığını bilmiyorum ama systemd geliştiricilerinin söylediklerine bakılırsa, en azından bilinçli olarak önemsenmeyen bir meseleydi. Karmaşık bir ara katman kurmadan ya da systemd’yi baştan yazmadan bir systemd alternatifi yapmak çok zor ve uygulamalar yalnızca izole parçalar halinde sunulabilecek API’lerin bir kısmına bağlı olsa bile systemd’nin tek bir parçasını temiz biçimde değiştirmek pratikte çok zor.
    • systemd’nin bazı kısımlarını baştan temiz bir şekilde yeniden implement etmenin bugün pratikte de doğru olduğu söylenebilir mi? Yazı elogind’i örnek veriyor.

  • Red Hat’in Linux ekosistemi üzerinde bu kadar fazla denetim sahibi olma biçimini sevmiyorum.

    • Ben de sevmiyorum ama bugünlerde Red Hat’in systemd üzerinde ne kadar denetimi olduğunu gerçekten bilmiyorum.
    • Gerçekten iki ucu keskin bir durum. Denetimin merkezileşmesi kötü ama insanlara para verip özgür ve açık kaynak yazılım geliştirmelerini sağlamak iyi. Ve elde ettikleri denetimin önemli bir kısmı da tam olarak bunu yaptıkları için ortaya çıkıyor.
      Yine de Red Hat’in özgür yazılımı benimsemiş olması, onun etkisine dair kaygıları bir ölçüde hafifletiyor. Yıllar içinde satın aldıkları teknolojilere bakınca, daha önce upstream’i olmayan şeyler için bile kendilerinin özgür ve açık kaynak bir upstream oluşturduğu durumlar var. Özellikle Dogtag PKI ve 389 Directory Server aklıma geliyor.
      Genel olarak ekosistem için çoğunlukla kötü olmadığını ve zarar verdiğinden çok daha fazla geliştirdiğini düşünüyorum.

  • Bu tartışmadan doğrudan etkilenmiyorum ama burada, Linux sistemlerinde sürekli artan gereksiz karmaşıklık ve soyutlama konusundaki kaygıyı azaltacak hiçbir şey yok.
    Linux hızla işletim sistemlerinin Java’sı haline geliyor. Gerçekten üzücü.