Se zájmem sleduji tuhle diskuzi...
Osobně si myslím, že v raných verzích byl systemd skvělý. Uměl startovat jednoduše daemony, umožňoval výrazně rychlejší start, nejen díky paralelnímu startu (to uměl i klasický init, např. v Debianu už dávno před tím), ale také díky tomu, že nemusel čekat na start některých daemonů, na kterých záviselo něco jiného, protože např. poskytoval jeho rouru sám a tu mu pak po jeho startu předal, takže věci závislé na něm na jeho start čekat nemusely (typicky dbus). Umělo to zrychlit start 2x i 3x v závislosti na HW. Malý, jednoduchý, dělal co dělat měl. Dal se jednoduše vyměnit za kterýkoli jiný boot init, což je ve světě Linuxu tak běžná a předpokládaná věc.
Pak se to začalo zvrhávat v to, že nabaloval na sebe další věci, které nejsou nutné, binární logy, ke kterým může být problém se dostat, když něco selže (a selhávání není výjimka). Nahrazování systémových částí svými, které nejsou "kompatibilní" a proto už nejde příslušná část vyměnit, pokud se původní zavedená alternativa nepřizpůsobí. Zažírání do částí desktopových software, které pak umějí běžet jen s ním ap. A úplně blbé je, když se vám jedna a ta samá instalace chovala na jiných PC různě - na některých start selhal na druhých ne. Nebo po vypnutí jader CPU a start na jednom se situace "opravila" a systém, který nenastartoval už naběhl. Sám jsem zažil, že po instalaci či upgrade systému příští start už neproběhl. Ať jsem se jako dekádami znalý odborník snažil, nebylo možné přijít na to, kde je chyba. Když jsem se to snažil řešit s maintainery balíčků a vývojáři, selhalo i toto. Museli konstatovat, že neví kde je problém. Nakonec jsem ten konkrétní problém vyřešil, protože jsem přišel na to, že se tam tluče paralelní start systemd a jeho vlastní služba readahead - vypnutím readahead a smazáním jeho cache souborů (vypnout nestačilo!!!) se to umravnilo (a to i přesto, že jsem si pak readahead zase zapnul). Ale bylo to pokus omyl a tenhle způsob mi byl na Windowsech vždy protivný, protože to znamená, že nemám OS pod kontrolou, jak bych jako admin mít měl a z toho slevovat nehodlám. Bohužel takových případů, kdy se to vyřešit nedá je mraky. Třeba na konkrétním HW při použití prelink prostě systém se systemd nenaběhne. Možné kdykoli předvést. Chyba je zjevně v systemd, protože normálně chcípne. Na jiném HW to nevadí, na jiném pro změnu ano. Jediným východiskem byla reinstalace OS, protože ani vrácení binárek prelinkem do původního stavu nepomohlo a tohle nedeterministické chování je prostě fail. I těmto způsobům jsem na Linuxu po předchozím používání pouze Windows odvykl a opravdu si nehodlám na tohle zvykat, to spíš udělám vlastní boot system, který bude schopen systemd nahradit. Takže základní myšlenka se mi líbí, ale její naplňování je od jistých verzí hodně špatně. Předpokládám, že si nikdo si nepřeje systém, který není schopen naběhnout, bez možnosti to řešit, protože init systém má spoustu vad.
Takže tohle vadí mi osobně, přestože ho používám, hlavně proto, že se mu moc vyhnout nedá a potřebuju prostě s ním umět. Učit se nové věci mi nevadí, naopak, děsně mě to baví. Ale co mě nebaví je, když se v principu deterministický stroj chová díky jedné SW komponentě nedeterministicky. Třeba to je to co vadí i jiným, jen to neumějí správně popsat.
145 Odpovědí
49093 Zhlédnutí