GNOME SystemD'ye bağımlı hâle geliyor

Bayram Tempest

Moderasyon Ekibi Sorumlusu
Süpervizör
Katılım
30 Nisan 2023
Mesajlar
6.111
Makaleler
39
Çözümler
271
Daha fazla  
Sistem Özellikleri
HP Victus 16 R7-7840HS RTX 3050 6 GB VRAM 16 GB DDR5 RAM
Cinsiyet
Erkek
GNOME'un son haftalık blog paylaşımında GNOME ve GDM'nin SystemD'ye daha bağımlı hâle getirileceği duyuruldu.

GNOME zaten SystemD'ye biraz bağımlılığı olan bir masaüstü ortamıydı ancak artık SystemD bulunmayan dağıtımlarda kullanılması çile olabilecek kadar bağımlılığın arttırılması düşünülüyor.

GNOME, SystemD bulunmayan sistemlerde kendi ek yazılımlarını çalıştırarak SystemD olmadan çalışmayı sağlıyordu ancak bu kodlar uzun süredir güncellenmiyordu. GNOME ekibi bu kodları kaldırarak SystemD'yi zorunluluk olarak sunacak. Ayrıca kullanıcı yönetimi gibi işlemler artık GNOME yazılımlarıyla değil SystemD ile çalışacak. GNOME masaüstünün tamamen SystemD ile entegre hâle getirilmesi planlanıyor.

GNOME'u SystemD bulunmayan dağıtımların kendi init sistemleri için forklayarak düzenlemeleri gerekebilir. GNOME bu konuda SystemD bulunmayan dağıtımlara yardımda bulunmayacak.

Ne düşünüyorsunuz? %99'umuz SystemD kullandığımız için umursamamız gerektiğini düşünmüyorum hatta bu SystemD entegrasyonunu destekleyebilirim.

Kaynak: #204 Sending Packets
 
GNOME'un son haftalık blog paylaşımında GNOME ve GDM'nin SystemD'ye daha bağımlı hâle getirileceği duyuruldu.

GNOME zaten SystemD'ye biraz bağımlılığı olan bir masaüstü ortamıydı ancak artık SystemD bulunmayan dağıtımlarda kullanılması çile olabilecek kadar bağımlılığın arttırılması düşünülüyor.

GNOME, SystemD bulunmayan sistemlerde kendi ek yazılımlarını çalıştırarak SystemD olmadan çalışmayı sağlıyordu ancak bu kodlar uzun süredir güncellenmiyordu. GNOME ekibi bu kodları kaldırarak SystemD'yi zorunluluk olarak sunacak. Ayrıca kullanıcı yönetimi gibi işlemler artık GNOME yazılımlarıyla değil SystemD ile çalışacak. GNOME masaüstünün tamamen SystemD ile entegre hâle getirilmesi planlanıyor.

GNOME'u SystemD bulunmayan dağıtımların kendi init sistemleri için forklayarak düzenlemeleri gerekebilir. GNOME bu konuda SystemD bulunmayan dağıtımlara yardımda bulunmayacak.

Ne düşünüyorsunuz? %99'umuz SystemD kullandığımız için umursamamız gerektiğini düşünmüyorum hatta bu SystemD entegrasyonunu destekleyebilirim.

Kaynak: #204 Sending Packets
Emeğinize sağlık, bu aralar canım çok sıkıyor aslında. Basit terminal komutlarından öteye geçmeyen video ve yazılardanda sıkıldım açıkcası derli toplu anlatıma sahip yazılı veya görsel ücretli veya ücretsiz bir kaynak öneriniz olur mu hocam ?
 
Sahsen sorumluluklar ayrimini gelistirme penceresinde destekliyorum. Kendileri wayland implementasyonu ve masaustu deneyimiyle ilgilenmeliler. Servis ve session yonetimi vb seyler systemd'ye birakilmali. Birden fazla init yontemi desteklemek icin bunlari init sisteminden offload edip kendileri init sistemine translation layer ve/veya API sunmak zorundalar. Bunun bakimi ise basli basina agir bir yuk. Tek basina hata sebebi.
Saçma. SystemD harici diğer init sistemleri işlerini SystemD'den daha iyi ve daha hızlı yapıyor.
Problem çoğu dagitimin ve de nin systemd kullanmasi değil systemd nin bunu zorla dayatmasıdır.
Mevzu iyi yada kotu yapmalari degil. Bakim cilesi. 1%'i bile kaplamayan bir grup icin devasa katmanlara bakim yapmak buyuk bir cile. Herkesin yiyecegi haltta degil. GNOME'a kimse systemd dayatmiyor. GNOME kendisi legacy kodu desteklemeyi birakiyor. Session managementi elle implemente edip diger init yontemlerine donusturmek yada init yontemlerini aradan cikartip tamamen kendin yapmak akil alir gibi bir yuk degil. Isi DE gelistirmek olan bir organizasyonun sorumluluklarini fazlasiyla asiyor.

Blog yazisini okuman lazim yorum yapmadan once.

Baska init sistemlerini desteklemek isteyen, kendisi GNOME projesini forklar, kendi translation layerlarini yazabilir. Ancak organizasyondan boyle bir sey beklemek mantikli degil. Ozellikle wayland gibi yarim bir sistemin implementasyonunu sifirdan yaptiklarini dusunursek. (Wayland referans disinda hic bir gerekli API'in implementasyonunu sunmaz. Tum compositorlar kendileri gerekli API'leri gelistirirler. Bu da display serverdan tutta, client managementina kadar her seyi sifirdan yazdiklari ve gelistirdikleri anlamina geliyor. Mutter'in gorevi bu.)
 
Son düzenleme:

Technopat Haberler

Yeni konular

Geri
Yukarı