Vlákno názorů k článku
V Ubuntu 25.10 bude Chrony místo systemd-timesync od 0x00 - nebylo by lepší do systemd implementovat ten nový...

nebylo by lepší do systemd implementovat ten nový protokol, než zpátečnicky systemd opouštět?

Ne.

Zlý jazyk by se mohl ale taky ptát, jestli by nebylo lepší tam, kde to není nezbytně nutné lepší opustit systemd :-D A jinak "nový"? RFC existuje 5 let a za tu dobu ho tam evidentně nikdo nenaimplementoval.

Ne nadarmo se RH drzi relativne stare verze systemd. Ja si myslim ze po vylifrovani lennarta drive ci pozdeji systemd bud hodne zestihli a zustanou tam jen nezbytne nutne veci souvisejici s jeho funkci vc interfaces a nebo se necim nahradi.
Spis myslim ze vylifruji nepotrebne systemd-varickafe veci ktere moc neohrozi kompatibilitu a nechaji veci tak jak jsou. A z puvodniho systemd zustanou jen rozhrani knihoven ,konfiguraky,cli tools.

A drzi stare verzie? RHEL 10 obsahuje systemd 257. RHEL 9.6 systemd 252, RHEL 9.0 mal systemd 250 (takze je tam nejaky rebase pocas zivotneho cyklu; aktualna verzia je 257).

Pokial chce niekto uptodate, tak Centos Hyperscale SIG obsahuje aktualne verzie.

Takisto Redhat nepodporuje vsetko len preto, ze existuje. Pokial to je funkcnost, ktoru v distribucii lepsie riesi iny balik, tak to ide prec. Preto je tam chrony a nie systemd-timesync. Preto je tam NetworkManager, nie systemd-network.

A neni treba duvod ten, ze to je zbytecny?

V čem přesně chronyd.service opouští systemd?

Nebylo by lepsi pouzivat veci na to k cemu jsou urcene a nesnazit se vymyslet zehlicku ktera taky umi varit kafe a prat trenky? Co oddelitelnost komponent? Proc mit ze systemu dalsi windows?
Takove to all in one monolit udelame protoze muzem not invented here? Typicka mentalita juniornich progrosu kteri to ani na konci nemusi udrzovat.

To mluvis o systemd? Tak jo, to sedi...

Ale ono systemd neni jedna binarka. Zrovna u podobnych veci se bavime o oddelenych binarkach/dae­monech. Takze ve vysledku je to o tom, jestli pustite daemon A a nebo B.

A nebylo by lepší ty projekty prostě nechat žít a uživatel ať si vybere? Komu stačí to, co je v systemd, používá to. Kdo chce něco jiného, nasadí si něco jiného. Distribuce pak jako výchozí vybere to, co považuje za nejlepší pro většinu svých uživatelů. Ve Fedoře je třeba výchozím správcem sítě NetworkManager, ale já mám na serveru systemd-networkd, protože pro moje použití to je plně dostačující a NM naopak overkill.

Kdyby bylo opravdu možné si vybrat, systemd / SysVinit / OpenRC / runit / ... , například při instalaci distribuce, tak by asi takové hejty nebyly.

Za mě jde Dčko proti Unixí filozofii malých nezávislých prográmků, které spolu kooperují. V komplikovaných řešeních se silnými vzájemnými závislostmi je také větší šance na chyby a jejich horší odhalování:

Nově tu máme např: https://blog.qualys.com/vulnerabilities-threat-research/2025/05/29/qualys-tru-discovers-two-local-information-disclosure-vulnerabilities-in-apport-and-systemd-coredump-cve-2025-5054-and-cve-2025-4598

Prý je to tam dlouho neřešený bug s tím protokolem. Tak proto, ne pro antisystemd.

To je typicky pristup ... kde ja jsem ho videl... aha. Foreman. Tam taky. Misto toho abychom to opravili vymenime cely podvozek (db system).

Nejlepsi by bylo, kdyby se systemd, kdyz uz nahrazuje init, necpal kam nema. Tim myslim nenahrazoval jine zakladni sluzby.

Kazda vec ma sve misto a ucel a tim, ze se systemd zbytecne cpe kam nema, se jen zvysuje jeho komplexita a tim i moznost selhani, a soucasne snizuje moznost pripadny problem jednoduse odhalit a vyresit. O neustale problemy v procesu s PID1 fakt nikdo nestoji. Uz ted je ta pitomost zbytecne komplikovana, user-friendly nebyla nikdy a asi uz ani nebude. Dokonce jednotlive casti jeji dokumentace si zhusta odporuji.

Chapu, ze by redhat jednou rad nahradil cely zakladni system timhle svym molochem, aby moh vytacet kontejnery a virtualy jak cvicky na krame, ale rozhodne s tim nesouhlasim.

Ovšem systemd není jedna binárka, která by řešila všechno od PID 1 (init) až po synchronizaci času. Celý systemd je velký projekt, který dělá desítky (dneska už možná přes stovku) různých utilit a je na uživatelích a tvůrcích distribucí, co si z toho vyberou. V Debianu je například 500 balíčků, které mají v názvu systemd.

Proč taky nikdo neříká, že se moloch GNU nemá do ničeho cpát, jednou udělali shell (Bash) a nějaké další funkce jako kompilátor (GCC), textový editor (nano) nebo dokonce grafický editor (gpaint) sem do takového molochu rozhodně nepatří. Stejně jako GNU není shell, tak systemd není init.

Tohle ale platí jen do chvíle, kdy si to vyžádá nějakou jinou systemd-* komponentu, přestože mám jinou, která to umí taky, ale protože nemá v názvu systemd-*, tak to s ní odmítá fungovat, že?

Jako napriklad co? :-) To jsou porad tyhle obecny teorie, ale v realu zadny konkretne popsany problem.

To je zajímavý postřeh. Zajímalo mě, jestli systemd umožňuje nějak volnější vazby. Trošku jsem zapátral, a mělo by to jít pomocí kombinace abstraktní unity bez service části a konkrétních implementací, které "implementují" požadované chování pomocí části PartOf nebo WantedBy.

Nemám s tím větších zkušeností.

Každopádně nezdá se, že by tomu systemd nějak aktivně bránil, spíše naopak.

Muzete prosim ty problemy v PID 1 konkretizovat... a nebo jde o nejaky nicim nepodlozeny FUD?

Komplikovane... ehm? V cem presne... v porovnani s klasickym SysV, kdy nejake zavislosti se resili tak nejak na kolene ruznymi bastly v shellu... stejne jako byly potreba ruzne ohaky okolo, pokud clovek treba zatouzil po automatickem restartu v pripade padu sluzby...

A ne, neni to jen o tech kontejnerech a virtualech. Je to i o "prkotinkach" typu oddelene privatni tmp, omezenich toho co spousteny daemon muze ci nikoliv atd. Coz krom jineho take posouva bezpecnost vysledneho reseni.

Jenže zrovna ve FreeBSD SystemV funguje perfektně. I v tom sh je to pěkně čitelné a modifikovatelné. Na Linuxu v tom býval takový nepořádek, že je lepší SystemD. SystemD je určitě špička. Někdy si budu muset projít všech těch 500 balíků, tak bude věcí! Všechny moje Linux servery jsou v podstatě jen jádro a SystemD.

FreeBSD pouziva BSD init. Ne System V.
Jinak nerikejte ze nevite o alternativach. Jako treba OpenRC.

To je kritika na pendrek, a po právu dostáváte sodu.

Obecně vzato se systemd vyčítalo a případně vyčítá:

1/ Lennart Poettering, páč je to debil.

2/ Že se systemd nasazuje ještě nedoladěné - podobné výtky, jako Qt5. Za to ale může RedHat, ne systemd

3/ Že zařezává alternativy - za což nemůže systemd, ale, třeba, GnomeTeam, který se neobtěžovalo vytvářet náhrady, a Gnome bez systemd nespustíte.

4/ Že systemd neprožívá zpětnou kompatabilitu

5/ Že občas nefunguje, například, že služba zbuchne, ale systémd tvrdí, že běží, že spustí strom závislostí, které popadají, protože systemd nerozlišuje (nerozlišoval) spouštěnou a spuštěnou...

Toto všechno by se dalo vytknout. Ale nemá to jednoduché řešení typu "kdyby to nedělal". Protože systemd objektivně nabízí lepší komfort jak to bylo dříve. Mnoho z toho jsou dětské nemoci, otázka peněz, nebo jen manažerská rozhodnutí.

Nejak si v tom vyctu zapomel to zdaleka nejpodstatnejsi, a to ze rozjebava veci ktery 100 let fungujou. logger, dns, ntp, ... atd atd atd.

Jasne, tradicni syslog, ntpd ci lokalni DNS resolver (napr. bind) se nikdy nerozjebal :-) A ted nam povezte jeste tu o cervene karkulce, at tu ty pohadky mame kompletni. Pravda je nicmene takova, ze tyhle dalsi (doplnkove) komponenty v systemd vam nikdo nenuti, muzete si je klidne vypnout a pouzivat alternativy dle sveho gusta. A pradlo take muzete doma prat na valse... :-)

No a zhodou okolnosti ako dns resolver je systemd-resolved asi jediny korektne sa spravajuci, ktory ma desktopovy user k dispozii.

Ziadny iny nevie link-specific a domain-specific upstream resolver. Napriklad pouzivatel si zapne vpn do firmy a cez resolver co mu nastavila vpn sa mu resolvuje iba interna zona fimy a vsetko ostatne ide cez globalny upstream resolver. Ale aj naopak, prihlasi sa k nejakej VPN sluzbe a resolvuje cez nu vsetko, okrem svojej lokalnej zony.

Takisto je jediny, z ktoreho vedia aplikacie ziskat DNSSEC status.