Názory k článku
V Ubuntu 25.10 bude Chrony místo systemd-timesync

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.

Jednou jsem si potreboval hrat s casem a delat pro testovani falesny casovy server, a nakonec jsem taky skoncil u chrony, mnohem lepsi na praci.

Zkusil jsem na Xubuntu 25.04. Nepodařilo se to, systém hlásí po prvním řádku, že nelze najít žádné baliky. Po druhém řádku chrony nainstaluje, ale první příkaz neproveden, po řádku s instalací chrony je třeba provést znovu Sudo apt-mark auto chrony.

24. 5. 2025, 11:42 editováno autorem komentáře

Nejde jen o tu bezpečnost, ale ověřuje se zároveň na více serverech správný čas a pakliže jeden server má čas jinak, tak se nebere v potaz.
Tohle NTP v systemd neumí.

Co kdyz ma vic serveru cas jinak a ten co jinak neni je ten spravny?

To má nižší pravděpodobnost.

Zjisti si, jak funguje ntp ... ono tech serveru kupodivu nejsou dva ... a ono si to prubezne checkuje dalsi a dalsi. Pricemz cas se syncuje s tim, ktery ma predevsim minimalni rozptyl latence. Jedna z tech veci ktery proste fungujou ... kdyz se nepouziva ta lennartova jebka.

To je jak v dávných dobách ruský počítač. Udělají se tři a když to dvoum vyjde stejně, považuje se to za správný výsledek:-)

Sa z toho smejete, ale pri projektoch letu do vesmiru to bolo bezne, na oboch stranach ciary. Minimalne tri funkcne pocitace alebo ine komponenty, dva musia vytvorit kvorum.

Netřeba chodit tak daleko, úplně stejně pracují běžné kritické systémy, např. řízení airbagů, kde se dosahuje kvóra nejen mezi počítači (dnes typicky mezi jádry jednoho čipu), ale i hardwarově: pyrotechniku neodpálí jeden GPIO pin, ale musí jich sepnout několik ve správné sekvenci, čímž se spustí příslušná analogová elektronika, která teprve práskne do palníčků proud. Když se to nestane ve správném pořadí (např. kvůli selhání pinu, napájení, poškození atd.), tak se náboj vybije a airbag nevystřelí.

Vidíš, a kdyby aspoň tohle udělali američtí soudruzi od Boeingu, tak nemusely spadnout dva MAXy.

indičtí*

Tam by to mohlo dopadnout jak u jedne rakety ariane. Soft zalozniho navigacniho systemu delal ten samy tym takze tam byla pouzita ta stejna unsafe praktika - pretypovani a dlouhy floating point.

Ta trojitá redundance (nebo větší) se dělá kvůli radiační odolnosti. Bug v software je úplně jiný problém. Na ten měli přijít už na zemi.

Ne, nemohlo. O žádné přetypování se nejednalo, ten MCAS z MAX krámu prostě vzal za směrodatný údaj z jediného (vadného) senzoru, přičemž navrženy byly naprosto zcestně pouze dva místo aspoň tří, kde by se dalo smysluplně něco vyhodnocovat ohledně poruchového stavu. :-(

Systemd-timesync nie je ntp klient. Je to sntp klient zo všetkými nevýhodami a problémami ktoré to prináša.

Které veřejné servery podporují NTS?

První odkaz na google
https://gist.github.com/jauderho/2ad0d441760fc5ed69d8d4e2d6b35f8d

Mate tam chybu systemd-tymesinc nie je NTP ale SNTP klient.

Čo je dobre tak na domáci počítač.

To ale lennartovi nebrani ti to dat na server a posunovat ti hodiny tam a zpet.

Chovam blahovou nadeji ze lennart vi co je prestupna sekunda a nebo ze do implementace prestupne minuty um... ehm bude se venovat jine cinnosti.

Cenu optimista storočia vyhráva ...... TRIDENT!!!! Gratulujeme!