Techolay Sosyal

.service Linux'un degil, systemd'nin cunku.
Ben runit kullaniyorum diye bende niye bozuk olsun?

Runit'te bu nasıl oluyor bilmiyorum ama bence doğrusu bu olmalı; en azından systemd için... Çünkü bu sayede süreçleri çok daha düzgün bir şekilde yönetmek mümkün oluyor ve bence Unix felsefesine de daha uygun.
Ama haklı olduğun bir nokta var: Her dağıtımda farklı farklı init sistemleri mevcut. Yazılımların her dağıtımda çalışması gerektiğini referans alırsak ve çoğu masaüstü ortamı (DE) ile pencere yöneticisi (WM) son kullanıcıyı hedeflediği için süreci kolaylaştırmak adına böyle bir yola başvuruyorlar. Yani aslında bir nebze benim WM seçimim de hatalı.

Benim yaşadığım sorun buydu mesela ve hyprland Wiki tarafında adam akıllı böyle olmalı bilgisi yoktu.

Systemd mi POSIX felsefesine uygun, pardon?

Sistem servisleri sistemi adi ustunde sistem servisidir. User process'ler (pipewire, wireplumber mesela) autostart yoluyla user process'ten baslamali. Dogru olan yol bu.

SDDM bir sistem servisidir. /var/service/ altina linklerim. PipeWire bir sistem servisi degildir, exec'lerim.

@WebSmith yasadigin sey sorun degil, unutmussun. Desktop portal bir daemon'dir. KDE, GNOME falan otomatik baslatiyor onu zaten.
Dbus ve portal'i exec'lediginde sorun cozulur. Window Manager SADECE PENCERE YONETIR. Fark bu.

XDG ise WM'den bagimsiz. Kimsenin wikisine eklemeye geregi yok. DE degil, WM bu.

Bu tür basit yazılımlar elbette exec-once ile çalıştırılabilir, onda bir sorun yok. Ama XDG Desktop Portal gibi kritik bileşenlerin bu şekilde başlatılmasını doğru bulmuyorum; Hyprland dokümantasyonunda öyle önerilse bile...
Benim asıl odaklandığım nokta, Systemd'nin servis yönetimini son derece başarılı yapıyor oluşu. Süreç takibi, çökme durumunda otomatik yeniden başlatma ve bağımlılık sırası yönetimi konusunda Systemd'ye güvenerek ilerlemek bana pratik ve kararlı geliyor.
Unix felsefesi konusundaki tanımım hatalı olabilir, kabul ediyorum; ancak kendi sistemimde servis yönetimini bu iş için tasarlanmış güçlü bir araca bırakmak stabilite açısından bence hâlâ en doğru yaklaşım.

Tamam lakin XDG desktop portal bir servis degil. XDG ortaminda DE/WM tarafindan baslatilan bir daemon.

WM'in amaci tamamen penceredir. Fvwm'den kendi basina default olarak desktop portal baslatmasini beklemeyecegin gibi Sway'den de beklememelisin, veya hyprland her neyse. Ama onun otomatik desktop portal baslatmasini saglayabilirsin.

Zaten WM kullaniyorum diyenler WM kullanmiyor, bu da bir fark. Ustune shell, notification daemon, desktop portal, ses sunucusu ve daha cogu elementi ekleyerek kendi custom DE'lerini yapiyorlar.

Beklentin ve aradigin sey yanlis, dediklerin WM'in isi degil. XDG gibi user yapilandirmasina bagli ve user process'leri ile calisan bir sey init'in de isi degil.

Tamam ama doğru ve düzgün bir xdg desktop portal yönetimi nasıl olacak o zaman systemd servisi için aşağıdaki dosya süreci güzel yönetir ama bu işlem bunun dışında nasıl olacak

Yine kacirdigin nokta bu hocam. Bu bir user process.

Desktop Portal zaten bir kere daemon olarak exec edildigine onu dbus activate eder. Bir program gibi desktop-portal deyip baslatamazsin, dbus uzerinden ona sinyal yollar baslatirsin. Ki dbus activation ile bazi durumlarda buna bile gerek kalmiyor.
Verdigin ornek de yine sacma. GNOME, RedHat'indir ve RedHat ekosistemine gore tasarlanir tamam. OpenBSD kullanan adam, OpenSolaris kullanan adam, Alpine Linux kullanan adam, Slackware kullanan adam veya benim gibi Void Linux kullanan adam napacak? Eger process takibi seylerin systemd ozelinde oldugunu saniyorsan yaniliyorsun hocam, her init sisteminin yapabildigi asiri basit numaralar bunlar.

Ve dedigin seyin imkansiz olma sebebine gelelim:
Desktop Portal; kullanici tarafindan baslatilmasi gereken, kullanici UID'sine bagli, dbus uzerinden calisan bir daemon'dir. Init sistemi ile alakasi olamaz, init sistemi kullaniciyla ilgilenmez. Ismindeki gibi kernel'i kullanima initialize (hazir) eder. Init senin kullanici olup olmadigina, agetty'den veya PAM'den veya bsdauth'dan login olup olmadigina bakmaz. Umurunda olmaz. Sistem calisiyor mu, calisiyor tamam.

WM (aslında bir karışıklık olmaması adına bunların ana adı Wayland compositor) içerisinde de iki tip var: Birisi Hyprland, MangoWM vb. gibi son kullanıcı odaklı olanlar; diğeri ise River gibi olanlar. Hyprland veya MangoWM elbette doğrudan genel son kullanıcıya hitap etmiyor; ancak WM tarafındaki 'son kullanıcı' için birer tercih. River ise öyle değil.
Bir diğer nokta ise exec-once karşılığı olarak Linux'ta hâlihazırda XDG Autostart ve shell script'lerin bulunması. Benim Unix konusundaki ana eleştiri noktam; pencere yöneticilerinin bu tür kendi çözümlerini getirmelerinin son kullanıcı açısından pratiklik sağlamasına rağmen, asıl yapmaları gereken işleri daha iyi yapmak yerine zaten var olan güçlü alternatiflere kendi çözümlerini getirmeleri. Bu durumun Linux'un gelişimini bir nebze olumsuz etkilediğini düşünüyorum.

Autostart da XDG Autostart ve bir freedesktop standardi.
WM tek basina calistigi icin baska bir bagimliligi olmamali. Portability ve POSIX felsefesi icim uygun olan da bu.

Dedigim gibi, DE ile WM arasindaki fark zaten bu.

Ayrica yine bir hataya dusmussun hocam: Linux ile alakasi yok. Tribblix'de oturur Sway derler pasa pasa kullanirim, freedesktop beni alakadar etmez. PipeWire bile kullanmam, OSS kullanirim.
Kim bilir? Belki de Linux 2.3.x kullaniyorumdur. OpenRC, ALSA ve i3wm ile mutluyumdur.

WM dedigin her yapi bir twm klonudur, islevini yapar. Plasmashell veya Gnomeshell olmadigi takdirde kwin ve mutter da aynidir; Desktop Portal'i gecin XDG Autostart bile baslatmazlar.

Ha unutmusum, compositor de bambaska bir sey. Wlroots bir compositor'dur ama WM degildir.
Labwc de Sway de Hyprland de WM'dir ama compositor degildir. Ayni compositor'u (wlroots) kullanirlar ama bambaska seylerdir.

Sanirim KWin ve Mutter tek basina hem kendi compositor'une hem de kendi WM'ine sahip diye karistirmissin hocam.

Hocam, tamam ama X11'de evet, window manager ile compositor ayrı olarak bulunabiliyor. Ama Wayland tarafında zaten compositor, display server rolünü üstleniyor. Bu sebeple de window manager da compositor içerisinde gerçekleşmiyor mu?
Ve çoğu pencere yöneticisinin GitHub ana sayfasında Wayland compositor yazıyor.

Evet zaten oyle ama ikisi farkli parcalar.
Compositor projenin tercihi (wlroots, Weston veya Weston uyumlu herhangi bir compositor), WM ise WM. Wayland tarafinda degisen tek sey display server mimarisi.

Sway compositor degildir, Labwc compositor degildir, Hyprland de degildir. Ucu de wlroots (ki Sway'in alt projesidir) compositor'unu kullanan WM'lerdir.

WM ≠ Compositor, tam tersi de gecerli. Beraber calisiyorlar, evet.

Hocam, hangi konuda beni eleştirdiğinizi anlamadım ben. compositor mu, WM mi konusu uzayıp gider; asıl olarak hangi konuda bana katılmıyorsunuz?

Ben tercih edecek olursam, pencere yöneticisi/kompozitörün sadece gerekli işleri kendisinin yapmasını, diğer işleri Linux'un kendi içerisindeki güçlü alternatiflere bırakmasını savunuyorum. Bu durumda ise bu tür şeyler hem daha hızlı gelişir hem de her pencere yöneticisinde belirli bir standart oluşur. Ama tabii ki sadece bu seçenek olsun, diğerleri ölsün, yok olsun, gitsin demiyorum; bunlar da olsun.

Belli başlı kavramları yanlış ele aldığımı ve bunların bir hata olduğunu kabul ediyorum.

WM'in tek basina WM oldugu gercegini reddetmenize katilmiyorum hocam. Tasinabilir yazilim hep olmalidir.

Systemd, POSIX'in parcasi degildir ve POSIX'e de uymaz zaten. Alakasi yoktur POSIX felsefesi ile. Linux'un parcasi da degildir; Linux POSIX uyumlu bir kernel'dir ve klasik bir POSIX kernel'i ile ayni calisir.

Sizin kast ettiginiz sey RedHat ekosistemi. Evet, RedHat ekosisteminde mantikli olabilir ama dedigim user process olayi yine gecerli. Dediginiz sey imkansiz.

Mesela Sway'i alalim. Sway, Wayland icin yapilmis bir window manager'dir. Ben Wayland'i OpenBSD'de de acarim, Tribblix'de de acarim; Yeter ki Gallium veya esdegeri bir DRI olsun.

Exec dedigimiz sey dumduz exec() veya fork() syscall'lari ile process olusturmaktan ibaret. Olmasi gereken yok bu. Ne demis POSIX felsefesi? Birbiri ile konusan ve calisan yazilimlar yaz. Pipe muhabbeti de ayni felsefenin urunu.

Kisaca olmasi gereken bu. Her isi kendi icinde kapatmak gerekiyor. Her sistemi ust bir otoriteye baglamak mantikli olabilir ama bu tasinabilirligi oldurur. Ayrica bahsettigimiz parcalar user process oldugu icin zaten imkansiz, unutmamak gerek.

---

Jzun lafin kisasi eglenceli sohbetti hocam. Arada konusalim yine.

olmasi gereken yol* olacak yanlis yazmisim... ayrica uzun* olacak...
Imla hatalarindan kusuruma bakmayin bir taraftan baska isle ugrasiyorum.