Portál AbcLinuxu, 12. května 2025 04:31
Lennart Poettering se v příspěvku The Biggest Myths na svém blogu rozhodl vyvrátit 30 největších mýtů o systemd. Mýtus 1: systemd je monolitický. Mýtus 2: systemd je o rychlosti. Mýtus 3: rychlý start pomocí systemd je nepodstatný pro servery. Mýtus 4: systemd je nekompatibilní se shellovskými skripty. Mýtus 5: systemd je složitý. Mýtus ... (LWN.net).
Tiskni
Sdílej:
Nejspis tim, ze provozuje nejaky voodoo, ze?Jo, třeba odložený start – navenek se to bude tvářit, že DB nastartovala hned, ale až přijde první zákazník, bude čekat pět minut než se DB opravdu spustí. Nebo spíš nebude čekat a půjde jinam.
ze "ta barva je cerna", tak vyvraceni tohoto tvrzeni bude hlaska "to neni pravda, ta barva je bila".nikoli, to není vyvrácením tohoto tvrzení, to je pouze protitvrzení vyvrácením by bylo něco ve smyslu "za ideály bílé barvy považujeme síran barnatý nebo oxid hořečnatý (viz literatura); laboratoř ta a ta provedla měření našeho vzorku, při kterém vyšlo, že dosahuje 96% bělosti BaSO4, pročež jej můžeme považovat za bílý"
jsou to jenom plky typu "to neni pravda", bez jakehokoli argumentu.Argumenty tam jsou, nektere mohou byt sporne, ale jsou. Problem je v tom, ze fakticka argumentace odpurcu systemd nedosahuje zdaleka anit teto jeho urovne, tahle diskuze je toho ostatne ukazkou.
Lennart Poettering 4086 Kay Sievers 3177 Greg KH 679 Michal Schmidt 232 Zbigniew Jędrzejewski-Szmek 222 Martin Pitt 181 Harald Hoyer 86 Marco d'Itri 65 Dave Reisner 63 Tom Gundersen 58Toto jsou aktuální čísla, ovšem silně zkreslená faktem, že byla importována kompletní historie
udev
u, proto je tam Greg a Kay tolik neudev commitů afaik mít nebude. Každopádně faktem je, že systemd == Lennart, potažmo RedHat a až potom zbytek.
bash-4.2# ls /usr/lib/systemd/ ls: nelze přistoupit k /usr/lib/systemd/: Adresář nebo soubor neexistujeYES!
Ve skutečnosti mezi initem a spouštěným programem ubyl shell (ve většině případů), což je jedna vrstvaOn taky shell (nebo třeba bash) není ani nijak hezká vrstva - jako programovací jazyk stojí za houby a pro ovládání běžících procesů je docela nepraktický, když prakticky jediné, co umí, je pustit nový proces.
prakticky jediné, co umí, je pustit nový procesale umi to udelat poradne
ale umi to udelat poradneV porovnání s čím? Shell tak akorát abstrahuje od pár volání jako pipe, fork/exec a getenv/setenv a přidává celé to harampádí ohledně úloh běžící na popředí a pozadí (což je pro init systém stejně irelevantní). Cokoli, co umí zavolat příslušná volání spouští procesy stejně dobře, jako shell.
Bohužel tohle jsou body, které snad všichni označí za "nesmysly" a doloží spousty případů, kde shell skripty neměly/nemají výhody oproti systemd-based konfiguraci.
Ale ani já bych nedokázal přijít na žádný "systemd killer", jen tak nějak cítím, že je to špatně. Kdyby to byl jednoduchý C process s jasně definovanou množinou souborů, do kterých zasahuje, kdyby se nesnažil pohltit snad vše kolem, kdyby ..., tak by možná dle mé osobní definice "jeden program dělá jednu věc a dělá ji dobře" uspěl spíše. A nikdo netvrdí, že by nemohl mít (třeba v další verzi) featuru trackování procesů přes cgroups.
Takhle mi (osobně) připadne jak zaváděcí proces Windowsu - ne že by se jej nešlo z dokumentace naučit, ale je na můj vkus málo intuitivní a dokud se do něj člověk vyloženě neponoří celým tělem, zůstává systemd takovým blackboxem. Třeba evoluce BSD initu mi přijde docela přirozená - od "rc", přes zavedení "rc.local" až k "rc.d" s integrovanými závislostmi.
Poznám "geniálně elegantní" řešení, když jej vidím, ale taky poznám opak. Neřeší systemd náhodou problémy jen proto, aby se řešily problémy? Připomíná mi tu iniciativu přepsání kernelu do C++ s objekty, protože "C je přece staré a pro dnešní dobu nevhodné". Vždy u každého systému budou chybějící featury, pointa je ta, zda nám stojí za to systém zesložiťovat jen pro implementaci těch, které v současnosti považujeme za klíčové.
Připomíná mi tu iniciativu přepsání kernelu do C++ s objekty, protože "C je přece staré a pro dnešní dobu nevhodné".Vetsinou maji tyto iniciativy prepisovani sve opodstatneni (sam jednu v zavorce zminujes). Ono se to zvenci muze zdat byt jako malicherne a zbytecne rypani se ve fungujici veci, ale ono je obcas zkratka vyhodnejsi vec prepsat nez se pokouset spravovat stavajici reseni postavene nad technologii, ktera nanabizi vse, co chces a je navic napsana tak, ze se v tom prakticky nikdo nevyzna.
Je spousta věcí, který v céčku nejdou napsat tak, aby se z toho člověk nepomátl.Napadá mě třeba překladač C++
Bootovaci system ma bejt prostej jak bulharska stripterka a admini by meli resit jiny veci nez je bootovani.Podľa toho čo som videl, práve snaha zrýchliť proces bootu to skomplikovala, pritom ako vidím z diskusie, tak je to pre každého neprínosné a stráca sa jednoduchosť konfiguráku, one line.
systemd je jednodussi nez initscripty kvuli unifikaci rozhrani ?Tady, ac s nim nesouhlasim, bych se ho zastal. Existuji dva pohledy na jednoduchost, ktere jdou casto proti sobe - 'jednoduchost uziti', kdy vnejsi chovani je prizpusobene obvyklym use cases, a proto se jich da snadno dosahnout i za cenu komplikovaneho chovani software, a 'jednoduchost chovani', kdy je jednoduche (ci rekneme transparentni) to, co dany software dela, i kdyz to muze znamenat, ze obvykle use cases vyzaduji netrivialni zachazeni. Oba tyhle pohledy jsou svym zpusobem regulerni, takze Poetteringa nelze oznacovat v tomto bode za demagoga. Ale slusi se zminit, ze 'jednoduchost chovani' je dalko vic v souladu s 'the unix way'.
se sys-v si musí napsat vlastní skript a nastavit úlohu v cronu.Nebo použít nástroj k tomu určený, jako například Monit.
systemd
, kterým odstaníme těch předchozích tisíc řádků shellu a nutnost startovat extra proces na něco, co lepší init systémy umí sami o sobě.
protoze to ze sluzba zbuchne tak, ze to pozna systemd je spis vyjimka.To zalezi treba na tom, zdali sluzba podporuje treba sd_notify a sluzby to ted zacinaji podporovat, od apache po mysql.
# Run gettys in standard runlevels 1:2345:respawn:/sbin/mingetty tty1Tohle prece umi klasicky BSD init uz minimalne 30 let. Dokonce je tak inteligentni, ze po nekolika selhanich pocka 5 minut nez, to zkusi znovu. Takhle to dopada, kdyz kazdyho bavi programovat, ale nikdo nechce cist dokumentaci.
inittab
nehodí), jim zase tak ohromující nepřijde. Systemd umí udělat respawn čehokoli, můžete si nastavit, při kterých exit hodnotách se to udělat nemá, nebo kolik času se má mezi restarty počkat.
Takže co to ten BSD init vlastně už 30 let umí?
systemd mi zabírá 20MB/16MB VIRT/RES
$ ps -p 1 -o comm,rss,vsz,size COMMAND RSS VSZ SIZE systemd 2100 43880 3032Pokud máte zapnutý SELinux, tak většina toho bude právě on.
Ale proč to potřebuje natáhnout tam zmiňováno není.+1, taky jsem to z toho nepochopil ...?
ale samotný fakt, že se integruje selinux, bych jim odpustil.Proti integraci ve smyslu, ze systemd spousti a aktivuje veci pro selinux vubec nic nemam, o tom jsem vedel. Ale fakt, ze systemd naloaduje cosi z selinuxu do sveho pametoveho prostoru a pak jeho proces zabira v pameti 20M, jak se pise nahore, je silene, to by fakticky znamenalo primou integraci selinuxu do systemd. Nevim, casem se na to kouknu, ted varim z vody, ale prijde mi to divne.
Nevim, casem se na to kouknu, ted varim z vody, ale prijde mi to divne.Taky vařím z vody, četl jsem o tom někde před delší dobou… Jenže pokud chceš v nějaké službě dělat policy decisions, tak potřebuješ buď natáhnout politiku do paměti, nebo dělat policy decisions dotazem na službu, která tu politiku nataženou má (třeba kernel).
nebo dělat policy decisions dotazem na službu, která tu politiku nataženou máTohle se cesta, ne narvat selinux do systemd.
8. Myth: systemd was created as result of the NIH syndrome.Zajímavé, že si vždy ke srovnávání úmyslně vybírá jen některé z dlouho existujících alternativ :).
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.