Vlákno názorů k článku
Debian bez systemd je za dveřmi: Devuan 1.0 RC2
od thedf413 - To zní jako skvělá šance, abych se konečně...
-
thedf413 (neregistrovaný)
To zní jako skvělá šance, abych se konečně zeptal - co je tak špatného na systemd?
Používam ten Linux 7 let, začal jsem na Ubuntu, pak pár let Debian a poslední 3 roky Arch. Migrací na systemd jsem tedy asi nějak projít musel. A jediné, čeho jsem si všiml je to, že se jiným příkazem spouští služby a při vypínání systému občas otravuje "a stop job is running for xyz", čehož jsem se zbavil instalací balíku watchdog.Co lidi vede k tomu, aby svůj volný čas věnovali zrovna vývoji něčeho tak zbytečného jako Devuan a k tomu tříštili síly, které mohli věnovat rovnou Debianu? Je to něco hlubšího? Nebo je to nějaká náboženská víra stoupenců Stallmana v podobném stylu jako "tohle neni Linux, ale GNU/Linux..." ? Jde o funkčnost, ideologii nebo něco jiného?
-
Pro konkrétní odpověď se musíte zeptat některého z nepřátel systemd. Jako jeho příznivce vám můžu nabídnout jenom pohled z druhé strany.
Záměrně se nezmíním o technických argumentech - ne, že by v určitých případech nebyly nutně oprávněné, ale proto, že nikdo zásadně nikdy nepřichází s nějakou smysluplnou alternativou. Většinou je to jenom o tom, jak "by to šlo" i bez systemd kdyby to existovalo.
Zakopaný pes je dle mého názoru v tom, že systemd skutečně znamená jistý přerod Linuxu, od v zásadě unixového OS pro adminy, ovládaného primárně pomocí skriptů a konfiguračních souborů, k programátorskému a uživatelskému OS, ovládaného primárně přes abstraktní API. Většině lidí je to jedno, někdo z toho má radost, ale někdo třeba kdysi začal používat Linux specificky proto, že chtěl Un*x a teď má pocit, že "tohle jsme si nedomluvili". Někomu se to prostě nelíbí a cítí nostalgii po éře klasických unixových systému a adminů a někdo to vidí tak, že si do teďka fušoval na svém karburátoru a najednou všichni chtějí jezdit s Teslou a on si s ní neví rady. Jistou roli hraje princip svobodného software, různí lidé ho interpretují různě, ale pro někoho to znamená, že v systému nic nesmí mít závislosti natvrdo. A pak je pár jedinců, kteří to berou skutečně jako jakousi zradu nebo svatokrádež. Nesmíme zapomínat, že stará Unixová komunita nikdy neměla k náboženskému fanatismu daleko: jsou to lidé schopní vidět boj dobra se zlem v tom, jaký kdo používá textový editor ;)
-
Knihu jsem si přečetl a stačilo mi to k vysvětlení, proč je Eric Razmond úplně vedle.
Na Unixu a jeho takzvané "filozofii" je mnoho dobrého ale současně taky mnoho katastrofálně špatného. Odmítat se poučit z chyb a trvat na tom, že se se všechno musí dělat tak, jak se to dělalo před čtyřiceti lety z žádného jiného důvodu, než toho, že doteďka se to vždycky dělalo takhle, není zrovna rozumný přístup.
-
Trupik (neregistrovaný)
Lol, "magic potty" ...
... To mi pripomína ako som sa snažil vysrať na Bratislavskom letisku a vždy keď som zatlačil a nahol sa dopredu tak automatický splachovač usúdil, že som odišiel a môj holý zadok "ovlažili" striekance od splachovača. Najhoršie sranie za dlhú dobu, 1 z 10, neodporúčam. A podobné to je aj so systemd. -
j (neregistrovaný)
Debilove jako ty tu vzdycky potesej, narozdil od zvanilu admini potrebujou aby veci fugovaly a enexistujici logy nebo root prava pro uzivatele to sou veci, bez ktery se s radosti obejdou.
A s nostalgii to nema nic spolecnyho, systemd proste nefunguje a nidky nebude, protoze z principu nemuze. Duvody sou exaktne stejny jako proc nefungujou widle. Taky nemuzou, protoze je to jeden gigantickej bastl kde spoulu souvisej naprosto ensouvisejici veci ...
Zarnej priklad, chces ve widlich vypnout logovani? No tak to ti nebude fungovat widlocron. Proc? Protoc ...
-
Ondra Satai NekolaZlatý podporovatel@j Neblábol a čas věnuj studiu dokumentace, ať o tom systemd víš alespoň alespoň základy.
-
NULL (neregistrovaný)
Aha, no to asi bude muset vysvětlit autor, ale já to pobral tak, že tím "správnou" myslí tu "opravdovou" ideologii svobody. Těch ideologií svobody máme totiž více. Třeba ta ideologie svobody okolo systemd mi nepřipadne taková ta úplně opravdová svoboda, protože se sice můžeš svobodně rozhodnout, ale s tím, že pokud nebudeš chválit, tak nebudeš svobodomyslný člověk který tomu rozumí, ale budeš hloupý trollí neumětel, který by chtěl zpátky jednoúlohové OS, otrokářství a malé děti k večeři.
-
Ještě že se open source komunita dostala k Unixům až s Linuxem, když už bylo všechno zásadní vymyšleno, a Linus to jen opsal podle dokumentace. Jinak by Linux měl pět nekompatibilních typů kernelu s deseti různými sadami sycalls, dvacet implementací libc s minimálním překryvem funkcí, třicet nekompatibilních zobrazovacích serverů (logicky pojmenovaných ISS, Mir, Beowulf, Wayland a X11 až X96), čtyřicet formátů balíčků, padesát toolkitů pro každý zobrazovací server, sto formátů konfiguráků atd. Po nocích by se v ulicích řezaly a občas střílely skupinky příznivců Beowulfu a X23, initq a systemz, MachoKernelu a PureCore, Cairo a Tripoli, wcurses a mcurses, gpm a dec...
Upřímně mi jako nezúčastněnému pozorovateli tyhle žabomyší války s tříštěním sil, kydáním špíny a dokonce výhrůžkami smrtí připadají tragikomické.
-
Jenda (neregistrovaný)
Za mě: samozřejmě, že jde o funkčnost. Podle mě potřebuje ještě několik let k tomu, aby dozrál. Udělat z toho jeden z nejkritičtějších kusů SW ve všech distribucí už teď byl podle mě velký nerozum.
Spousta nedořešených problémů v nečekaných situacích (selhání fsck, nesestavení RAIDu, nepřerušitelný n*90 sekund timeout při nedostupné síti/disku (tj. čeká se 3 minuty navíc a až potom se admin může přihlásit na konzoli a problém opravit), nereportování chyb)
Nedostatek návodů a howto na zvládání novinek jako journald a spousty dalších démonů (resolve, timesync, ...).
S každou verzí očekávání co dalšího co v unixech fungovalo posledních 30 let se zase rozbije (zabíjení screen/nohup sessions po odhlášení uživatele, zrušení rc.local, „opravení“ aby halt dělal halt a poweroff dělal poweroff, převzetí ACPI eventů loginctl, který ale neumí spustit arbitrary skript, takže se musí vypnout a stejně pustit předchozí acpid).
Unit files rozprsklé všude možně po VFS včetně generovaných za běhu s ne-obvious možností jak je overridnout.
Blbě napsané unit files které službu nespustí a nic neřeknou a na rozdíl od init skriptů nejde triviálně udělat bash -x /etc/init.d/služba start a podívat se, na čem se to vysekalo.
Nesmyslné enforcování ideologie i když to rozbije distribuční mechanismy (/etc/mtab musí být symlink do /proc/mounts, jenže update-initramfs čte z /etc/mtab informace o tom, kde je /. Když jsem generoval initramfs pro chrootnutý systém, tak jsem mu /etc/mtab prostě přepsal. Teď to nejde.)
Komplikovanější dohackování funkcionality než „tady do init skriptu připíšu jeden řádek“.
Desítky megabajtů paměti použitých novými démony (systemd --system/user, logind, journald). To fakt nikdo nečeká, že v roce 2017 existují linuxové embedded systémy, kde je tohle nezanedbatelný podíl dostupné RAM?
Veliká enterprise architektura a obrovské množství konfiguračních XML souborů na mnoha místech po systému do které není snadné proniknout a blbě se to ladí na rozdíl od pár skriptů a symlinků v /etc/rc*.
Vývoj veden nepříjemným vývojářem, který má mezery ve znalostech, jak funguje UNIX (1, 2)
-
muf (neregistrovaný)
Díky za dobré shrnutí. Podařilo se vám shrnout skoro vše, čím ta obluda otravuje i mě.
Argumenty zastánců bývají někdy komické. Kupříkladu je prý teď krásně jednoduché vytvořit novou službu pomocí pár řádek v příslušném .service, protože nemusíte psát složité shell scripty. Všimněte si, že často je praxe taková, že zde najdete cestu právě k takovému scriptu, čímž se vtipně obchází omezení a chybovost toho nejúžasnějšího init systému všech dob.Jestli chcete vidět, jak náramně to funguje, mrkněte, jak jsou v RHEL7(CentOS) nahazována síťová rozhraní...Joo, generators, to je věc...
Já vím, až bude vše sluníčkové a daemony a vůbec vše budeme dělat podle Poetteringa... Ten chlapec by se rád zapsal do dějin, ale prostě na to nemá. Produkuje tuny kódu, ale bez koncepce, invence, elegance. Celé jeho působení je upachtěné a proto agresivní. Vedle tvůrců Unixu zůstane navždy jen trpaslíkem.
Celé to hnutí "za pokrok" mně připomíná levicové "liberály", kterými je v západním světě promořené humanitní vzdělávání. Je to podobné jak metodikou tak vnějšími projevy: dehonestace, urážky, nálepkování oponentů, hysterie, snaha vsugerovat, "že jinak to nejde...my jsme ti dokonalí a vyvolení..."Já kupříkladu nikdy netvrdil, že starý init ze systemu 5 je dokonalý a nepotřebuje náhradu. Byly tady. Například upstart jí mohl být, nebýt politiky. Ničeho jiného než politiky...
Devuan je obdivuhodný počin.
-
tnr (neregistrovaný)
Nic neukazuje vic emocialnost rozhodovani nekterych lidi proti systemd jako propagovani upstartu, projektu, o kterem jeho autori sami rekli,ze je broken by design.
Viz komentare od Scott James Remnant,ktery rikal,ze by se to muselo cele prepsat...
Kdyz uz chcete sd kritizovat a rikat co by se mohlo pouzivat misto nej,tak to aspon nedelejte tak hloupe a doporucujte aspon OpenRC))
-
Filip JirsákStříbrný podporovatelBlbě napsané unit files které službu nespustí a nic neřeknou a na rozdíl od init skriptů nejde triviálně udělat bash -x /etc/init.d/služba start a podívat se, na čem se to vysekalo.
Mně teda připadá mnohem jednodušší zkopírovat ten jeden příkaz z unit souboru a spustit jej ručně, než debugovat bash skript. A obvykle to ani není potřeba, protože výstup toho příkazu najdu v logu. -
Mně teda připadá mnohem jednodušší zkopírovat ten jeden příkaz z unit souboru a spustit jej ručně, než debugovat bash skript. A obvykle to ani není potřeba, protože výstup toho příkazu najdu v logu.
Teorie krásná, blbé je, že běžně se příkaz ručně spustit dá a funguje, ale při startu přes systemd se nespustí a v logu je houbeles. To je zase praxe.
-
Filip JirsákStříbrný podporovatel
Úplně jiné? Mohou tam být nastavené nějaké limity nebo capability, ale ty obvykle pro základní odladění nepotřebujete – a pokud ano, vidíte jejich nastavení v unit souboru. Mohou tam být jinak nastavené proměnné prostředí, ale ty opět vidíte v unit souboru.
Moje zkušenost je taková, že když připravuju nějakou službu, nejprve si ji spouštím z shellu, služba mi běží na popředí, vidím její výstup. Když mám všechny parametry nastavené tak, jak potřebuju, jenom ten příkaz zkopíruju do unit souboru – a všechno funguje stejně, jako když jsem to pouštěl z shellu, standardní výstup vidím v logu. Když jsem to samé řešil se SysVInitem, narazil jsem typicky hned na začátku na dva problémy – za prvé, proces se typicky sám odforkováním daemonizoval, takže když jsem ho chtěl spustit z shellu, musel jsem daemonizaci zakázat – a služba se hned začala chovat jinak. Druhý problém byl, že standardní výstup byl v init skriptu typicky přesměrován do /dev/null, takže když jsem se chtěl dozvědět, co vlastně aplikace při startu vypisuje za chybu, musel jsem upravovat produkční init skript, přidávat do něj ladicí výpisy a doufat, že ho pak zase vrátím do původního stavu.
Už před lety jsem právě kvůli tomuhle začal používat daemontools – protože už tenkrát mi připadalo šílené, že proces sám dělá něco jiného, když ho spustím ručně a když ho spustím pod správcem procesů. Mimochodem, řekl bych, že to, že spousta serverů implementuje daemonizaci, vypovídá o „kvalitě“ běžně používaného správce služeb – když serverový proces první, co udělá, je to, že se forkne, aby se dostal z dosahu správce služeb…
-
Povedal by som, že ak netušíte, prečo démonizácia začína forkom, bude technologická diskusia s Vami zážitkom ktorému by som sa radšej vyhol.
Rovnak tak odporúčam premýšľať prelúskať si manuál k systemd.service, zistíte tak, ako veľmi sa môže líšiť spustenie pod SystemD od normálneho. Len tie premenné prostredia vie ovplyvniť asi 20 nastavení. Vedľa nich existujú i vlastné premenné SystemD, nastavenia plátne i pre iné typy jednotiek a premenné popisujúce predávané file desktriptory.
Zreprodukovať to všetko pri ladení v shelly je, myslím, ešte stále nemožné.
-
Filip JirsákStříbrný podporovatel
Povedal by som, že ak netušíte, prečo démonizácia začína forkom, bude technologická diskusia s Vami zážitkom ktorému by som sa radšej vyhol.
Já jsem ale nepsal, že netuším, proč démonizace začíná forkem – naopak po pořádném přečtení mého komentáře zjistíte, že to dobře vím. Psal jsem o tom, že je špatně, že se proces démonizuje, aby se dostal z dosahu svého rodiče, a běží pak způsobem, při kterém se velmi těžko ladí a vůbec zjišťuje jeho stav. Považuju za normální, že proces spustím, proces vypisuje informace na standardní výstup a chyby na standardní chybový výstup, já se na ně kdykoli můžu podívat, rodičovský proces může ten spuštěný proces ovládat tak, že mu pošle signál, a také se rodičovský proces dozví o ukončení procesu. Takhle to funguje, když službu spustím z shellu, a považuju za správné, že to úplně stejně funguje i tehdy, když proces spustím přes správce služeb.Rovnak tak odporúčam premýšľať prelúskať si manuál k systemd.service, zistíte tak, ako veľmi sa môže líšiť spustenie pod SystemD od normálneho. Len tie premenné prostredia vie ovplyvniť asi 20 nastavení. Vedľa nich existujú i vlastné premenné SystemD, nastavenia plátne i pre iné typy jednotiek a premenné popisujúce predávané file desktriptory.
Abych pravdu řekl, nikdy jsem neřešil problém, že by služba používala nějaké proměnné prostředí, které defaultně nastavuje systemd. Naopak už jsem řešil spoustu chyb v init skriptech pro SysVinit, kdy při spuštění z shellu skript fungoval, ale pak při spuštění při startu nefungoval, protože byla jinak nastavená proměnná PATH nebo HOME.Předávané deskriptory jsou věc navíc, SysVinit nic takového neuměl.
Zkuste si třeba ladit nějaké chyby při startu Apache. Když spustíte v shellu ten příkaz, který najdete v init skriptu, Apache se vám odforkuje a nevíte nic. Když ho chcete spustit v shellu, musíte použít parametr
-x, a to najednou Apache dělá úplně něco jiného, než když běží z init skriptu. Ono je vůbec úžasné celéapachectl. Proč to programují autoři webového serveru? Neměl by se o tohle náhodou starat správce služeb? -
> Abych pravdu řekl, nikdy jsem neřešil problém, že by služba používala nějaké proměnné prostředí, které defaultně nastavuje systemd.
Je to poznat :) Zial, to, ze ste sa Vy s takym problemom nestretol je ako riesenie dost nedostatocne.
> Předávané deskriptory jsou věc navíc, SysVinit nic takového neuměl.
SysVinit je init, neexistuje ziadny dodvod, preco by nieco take vediet mal. Ostatne, to neexistuje ani pre SystemD. Pre pouzitie, s ktorym ta funkcia bola povodne uvedena sa pouziva inetd.
> Proč to programují autoři webového serveru? Neměl by se o tohle náhodou starat správce služeb?
Spravca sluzieb kludne. Ved napokon, moje apache sa spusta z normalneho skriptu, avsak volanim na spravcu -
start-stop-daemon -S -b -m -p /run/httpd.pid -x /usr/bin/httpd -- -k start -DFOREGROUNDNie kazdy ale potrebuje k blbej LAMPe pustat spravcu sluzieb a uz vobec by sa o to nemal starat init.
-
Filip JirsákStříbrný podporovatel
Zial, to, ze ste sa Vy s takym problemom nestretol je ako riesenie dost nedostatocne.
Která proměnná prostředí, kterou vám systemd zákeřně nastavuje, dělá vaší aplikaci problémy? PATH nebo LANG?Spravca sluzieb kludne. Ved napokon, moje apache sa spusta z normalneho skriptu, avsak volanim na spravcu -
start-stop-daemon -S -b -m -p /run/httpd.pid -x /usr/bin/httpd -- -k start -DFOREGROUND
SysVinit na všechno stačí, je to jen obyčejný shell skript – a pak tam najednou navíc potřebujetestart-stop-daemons 5 parametrama.Normální server, který dělá jen svou práci a nemusí suplovat správce služeb, se spouští příkazem
/usr/bin/serverz shellu, a ze správce služeb se překvapivě spouští tím samým příkazem/usr/bin/server. Není žádný rozumný důvod, proč by to mělo být jinak. Nerozumným důvodem je rozbitý správce služeb.Nie kazdy ale potrebuje k blbej LAMPe pustat spravcu sluzieb
Pokud to nechce spouštět ručně z terminálu, ale automaticky jako službu, pak správce služeb potřebuje.uz vobec by sa o to nemal starat init
V případě systemd se o to také init nestará. Systemd init toho dělá méně, než SysVinit init. -
> V případě systemd se o to také init nestará. Systemd init toho dělá méně, než SysVinit init.
SystemD je monolit. Ak Vam niekto niekedy povedal nieco ine, znamena to len, ze sa z neho nikdy nepokusil vysekat jeden komponent.
> SysVinit na všechno stačí, je to jen obyčejný shell skript – a pak tam najednou navíc potřebujete start-stop-daemon s 5 parametrama.
Nepotrebujem, chcem :) Ale pravdupovediac, toto vzniklo skriptom, co prevadza SystemD unity na normalne skripty. Dalo by sa to prepisat aj na cisty bash, ale v podstate na to nikdy nebol dovod...
> Není žádný rozumný důvod, proč by to mělo být jinak. Nerozumným důvodem je rozbitý správce služeb.
Normalny server hlavne nema ocakavat pritomnost dakeho spravcu sluzieb. Pokial podporuje beh ako demon, je to samozrejme plus.
> Pokud to nechce spouštět ručně z terminálu, ale automaticky jako službu, pak správce služeb potřebuje.
Neviem, ci sa da skript, co pri inicializacii systemu nahadzuje apaca nazvat spravcom sluzieb, ale nieco na tom bude :D
Kazdopadne, citajuc toto vlakno zacinam premyslat, ako sme to tych 30 rokov pred vynalezom SystemD vobec dokazali fungovat. Tolko problemov, co priniesol^H^H vyriesil, tolko use cases, co sme ani nevedeli, ze potrebujeme...
Skutocne je zazrak, ze na svete existuje tolko masin schopnych bez SystemD normalne fungovat.
-
tnr (neregistrovaný)
No,ze jsme to prezili bez neceho jako systemd je sice pravda, ale podil linuxu na desktopu taky o necem mluvi )) to neni vubec jen o sd, ale o pouzitelnosti novych technologii v kombinaci sd,wayland a jejich pro desktop moc neni potreba mluvit.. Sysvinit a treba podpora dynamicky pridavaneho hw, skoda mluvit.
A i ta sprava serveru je dneska dost jina,davno jsou pryc doby,kdy jeden admin spravoval par uber serveru, kuchtil si shell skripty a customizoval. Dnesni velke firmy chteji mnoho virtualizovanych standardnich serveru, kontejnery, automaticke deploymenty serveru a centralizovanou spravu.
A na takove veci je marna slava ten systemd lepsi, protoze je unifikovany, ma api, funguje stejne na vsech distribucich...
-
> ale podil linuxu na desktopu taky o necem mluvi ))
O niecom konkretnom, alebo sa len snazis naznacit, ze BFU tusi nieco o inite? :)
> Sysvinit a treba podpora dynamicky pridavaneho hw, skoda mluvit.
To rozhodne. Rovnako ako je skoda hovorit o sysvinite a podpore prevodu reci na text.
> A na takove veci je marna slava ten systemd lepsi, protoze je unifikovany, ma api, funguje stejne na vsech distribucich...
Jediny problem je, ze systemd nieje unifikovany a nefunguje rovnako na vsetkych distribuciach. SystemD unit pre rhel nemusi bezat korektne na Archu a Archovske unity celkom urcite nebezia OK na Debiane.
A to je len jeden z prikladov problemov, ktore SystemD vynasiel, vyhlasil za nutne riesit a nevyriesil :D
-
tnr (neregistrovaný)
> O niecom konkretnom, alebo sa len snazis naznacit, ze BFU tusi nieco o inite? :)
Ne, ale o tom ze veci nefunguji, dokaze vedet docela hodne :-) Viz vsemozne, neresitelne problemy napr. bez logind.
>Jediny problem je, ze systemd nieje unifikovany a nefunguje rovnako na vsetkych distribuciach. SystemD unit pre rhel nemusi bezat korektne na Archu a Archovske unity celkom urcite nebezia OK na Debiane. A to je len jeden z prikladov problemov, ktore SystemD vynasiel, vyhlasil za nutne riesit a nevyriesil :D
Me to funguje docela dobre :) Dej priklad unity, ktera je nekompatibilni. Samozrejme muze byt problem verze systemd, ale to se 99.9% unit vubec netyka. A proc teda vubec treba vyvojar Archlinuxu rika, ze jim systemd vyrazne ulehcil praci pri sprave unit?:)
-
Filip JirsákStříbrný podporovatel
Dej priklad unity, ktera je nekompatibilni.
Předpokládám, že největší problém bude v názvech – když si jedna distribuce pojmenuje službu httpd a druhá apache, nebudou závislé unity v jedné nebo druhé distribuci fungovat. (Což samozřejmě není problém jen systemd, nebude to fungovat nikde, kde se v závislostech používají arbitrární jména.) -
> Viz vsemozne, neresitelne problemy napr. bez logind.
Vychadzajuc z toho, ze logind nemam na ziadnom zariadeni, ake neriesitelne problemy sa ma tykaju?
> Me to funguje docela dobre :)
To je mimoriadne relevantne :)
> A proc teda vubec treba vyvojar Archlinuxu rika, ze jim systemd vyrazne ulehcil praci pri sprave unit?:)
Pretoze pred prechodom na SystemD podporoval Arch niekolko init systemov. Pri prechode sice vyhlasili, ze pouzivaniu inych initov nebudu nijak branit, subory pre ostatne inity ale odstranili z balickov.
> Dej priklad unity, ktera je nekompatibilni
Len prva vec co vyplul vyhladavac :)
-
tnr (neregistrovaný)
> Vychadzajuc z toho, ze logind nemam na ziadnom zariadeni, ake neriesitelne problemy sa ma tykaju?
To je mimoriadne relevantne :) Napr. stabilni ukonceni sezeni jednoho, vicenasobne prihlaseneho uzivatele, se vsemi procesy z tohoto sezeni (vcetne forknutych), cely multiseat management atd. Ono ne ze by se to nedalo pouzivat i bez toho, ale je to podobne jako s jinymi vecmi ze systemd - jde to nabastlit i bez nich, ale robustni reseni to neni.
A priklady neresenych problemu v tradicnim initu je mnohem vic - napr. aktivace sluzeb pridanim zarizeni (+ sprava zavislosti sluzeb v tomto pripade), korektni paralelismus startu atd atd atd.
> Len prva vec co vyplul vyhladavac :)
Gratuluji k skvelemu proti prikladu. Tzn. konfiguracni zmena cesty v unite je duvod, proc jsou ty jednotky nekompatibilni, to je rozhodne srovnatelne s nutnosti bastleni vlastnich init.d skriptu :)
> Pretoze pred prechodom na SystemD podporoval Arch niekolko init systemov. Pri prechode sice vyhlasili, ze pouzivaniu inych initov nebudu nijak branit, subory pre ostatne inity ale odstranili z balickov.
False.
Cituji 2brainz (vyvojar zodpovedny za init v Archu v te dobe):
> Burden of maintenance: In addition to the aforementioned design problems, initscripts also had a large number of bugs. Fixing those bugs was always complicated and took time, which we often did not have. Delegating this task to a larger community (in this case, the systemd community) made things much easier for us.Tzn. jasne pise, ze pouziti systemd a moznost sdileni teto spolecne funkcionality s vetsi komunitou znamenalo zjednoduseni jejich prace (oproti bastleni init skriptu na kolene).
-
> To je mimoriadne relevantne :)
Co take?
> Napr. stabilni ukonceni sezeni jednoho, vicenasobne prihlaseneho uzivatele, se vsemi procesy z tohoto sezeni (vcetne forknutych)
Inak povedane, slavny SystemD bug vrazdiaci procesy screenu a tmuxu. Na jednej strane chapem, ze naskriptovat toto by zabralo mozno i 5 riadkov, pritom ale nemam pocit, ze by zrovna toto bola ziadana featura :D
> A priklady neresenych problemu v tradicnim initu je mnohem vic - napr. aktivace sluzeb pridanim zarizeni (+ sprava zavislosti sluzeb v tomto pripade)
ATTRS{vendor}=="nieco" ATTRS{model}=="nieco-ine" RUN+="service start nejaka-sluzba"To hadam ani nebolo myslene vazne :)
> Tzn. konfiguracni zmena cesty v unite je duvod, proc jsou ty jednotky nekompatibilni, to je rozhodne srovnatelne s nutnosti bastleni vlastnich init.d skriptu :)
Nie. Nutnost bastlenia si vlastnych jednotiek je zrovnatelne s nutnosti bastleni vlastnich init.d skriptu. Jednotka nekompatibilna kvoli ceste je zrovnatelna s init skriptom nekompatibilnym kvoli ceste. Skratka, vobec nic sa nezmenilo.
> Cituji 2brainz (vyvojar zodpovedny za init v Archu v te dobe):
To bol samozrejme krasny predpoklad a je smutne, ze mu nevysiel. Neprijemne je, ze si kvoli nemu "ulahcil" pracu i zrusenim podpory ostatnych initov.
-
tnr (neregistrovaný)
> Inak povedane, slavny SystemD bug vrazdiaci procesy screenu a tmuxu. Na jednej strane chapem, ze naskriptovat toto by zabralo mozno i 5 riadkov, pritom ale nemam pocit, ze by zrovna toto bola ziadana featura :D
Ano? A jak ten tvuj skript o 5 radcich pozna u forknuteho procesu X pri 2 sezenich stejneho uzivatele, zda ho killnout ci nikoliv :)
A jinak zadana featura to docela byla, na desktopech byl mizerny multiseat a leftover procesy zdrojem docela beznych problemu...
> ATTRS{vendor}=="nieco" ATTRS{model}=="nieco-ine" RUN+="service start nejaka-sluzba"
> To hadam ani nebolo myslene vazne :)Tak a ted se zamysli, jak to resi napr. zavislosti te sluzby, jak to osetruje paralelni spusteni v pripade, ze se takovato sluzba (ci jeji zavilosti) spusti z vice hw eventu atd.No, nijak, obet v minulosti bezny zdroj problemu :)
> Nie. Nutnost bastlenia si vlastnych jednotiek je zrovnatelne s nutnosti bastleni vlastnich init.d skriptu. Jednotka nekompatibilna kvoli ceste je zrovnatelna s init skriptom nekompatibilnym kvoli ceste. Skratka, vobec nic sa nezmenilo.
Jiste, protoze init.d skripty se mezi distribucemi typicky lisily prave jenom zmenenyma cestama a nikoliv treba pouzitymi knihovnami a vubec nebyly uplne odlisne v distribucich :) A nemluve o tom, ze zmena konfiguracnicho souboru (unit) je mnohem jednodussi nez zmena provadeneho skriptu (ktery muze byt vice ci mene zprasen a typicky bude mnohem delsi - staci se podivat na init.d skripty pred systemd treba v redhatu ci debianu - obcas i stovky radku provadeneho kodu).
> To bol samozrejme krasny predpoklad a je smutne, ze mu nevysiel. Neprijemne je, ze si kvoli nemu "ulahcil" pracu i zrusenim podpory ostatnych initov.
Opet cituji:
>So, for me personally, when systemd came along, it solved all the problems I ever had with system initialization. What most systemd critics consider "bloat", I consider necessary complexity to solve a complex problem generically. You can say what you want about Poettering, but he actually realized what the problems with system initialization were and provided a working solution.
Prispevek je z roku 2016, nikde nepise, ze mu predpoklad nevysel :)
> Co take?
Nepochopil, nevadi :))
-
Filip JirsákStříbrný podporovatel
SystemD je monolit. Ak Vam niekto niekedy povedal nieco ine, znamena to len, ze sa z neho nikdy nepokusil vysekat jeden komponent.
Mícháte hrušky a jabka. Jedna věc je unixová filozofie, že jeden proces dělá jen jednu věc – jak to dělají třeba jednotlivé komponenty qmailu, Postfixu nebo právě systemd. systemd PID 1 se pokud vím stará jen o spuštění správce procesů a o zombie procesy. Míň už toho PID 1 dělat nemůže.Druhá věc je, že máte nějaký softwarový balík, který se skládá z většího množství komponent, které navzájem spolupracují. Vysekat jednu náhodně vybranou komponentu z qmailu nebo Postfixu také nebude snadné. Ale tak je to v pořádku – ty komponenty si navzájem poskytují nějaké služby, a pokud někdo chce nějakou komponentu nahradit, musí nahradit ty funkce, které ostatním poskytuje. Nemá smysl omezovat funkcionalitu jenom proto, aby nevznikla závislost na nějaké další komponentě. Většina lidí chce software používat kvůli jeho funkcím, ne pro to, aby měl co nejméně závislostí.
Normalny server hlavne nema ocakavat pritomnost dakeho spravcu sluzieb.
Který server očekává konkrétního správce služeb? Tedy pokud vynecháme třeba Apache, který očekává nemožného správce služeb, takže si radši implementuje vlastní správu, nebo Postfix, který rovněž očekává nemožného správce služeb, takže si raději implementuje vlastního správce, nebo qmail, který toho vlastního správce rovnou zveřejnil jako samostatnou aplikaci.Pokial podporuje beh ako demon, je to samozrejme plus.
Já v tom žádné plus nevidím, pro mne je to akorát komplikace a možný zdroj chyb.Kazdopadne, citajuc toto vlakno zacinam premyslat, ako sme to tych 30 rokov pred vynalezom SystemD vobec dokazali fungovat.
To, že jsme nějak dokázali fungovat, neznamená, že to nejde lépe. Taky jsme dokázali fungovat bez internetu, bez elektřiny, bez vodovodu, bez domů.tolko use cases, co sme ani nevedeli, ze potrebujeme...
To je podobné jako s IPv4. Taky si mnozí nedokážou představit, k čemu je dobré mít všude veřejné IPv6 adresy, a neustále pláčou nad tím, že jim přestanou fungovat jejich rovnáky na vohejbáky na obcházení NATu. Pravda je, že u veřejných IP adres je to ještě pikantnější, protože internet tak dlouhá léta fungoval, takže tam to ani není posun vpřed, ale jenom návrat k lepšímu stavu, který už jsme dříve měli. -
> Jedna věc je unixová filozofie, že jeden proces dělá jen jednu věc
... mountuje filesystémy, spravuje konzole, vypočítava machine_id (nech je to čokoľvek), parsuje stringy v kernel commandline, prehadzuje procesy medzi jadrami cpu, číta konfiguračné súbory, reštartuje procesy, zapisuje container_id a vypisuje help. A to som prosímpekne prešiel v tom zdrojáku len do polovice, než ma to prestalo baviť.
Pre porovnanie si pozrite init skript runit-u, ktorý ma, keď zrátam všetky 3 stages, 200 riadkov shellu.
> <i>Normalny server hlavne nema ocakavat pritomnost dakeho spravcu sluzieb. </i>
> Který server očekává konkrétního správce služeb?Kde sa zrazu vzalo to "konkrétního" ? :)
> To, že jsme nějak dokázali fungovat, neznamená, že to nejde lépe.
S tým náhodou súhlasím. Čo mne osobne vadí je, že sme miesto "lépe" prešli na "komplikovanejšie". SystemD ako správca služieb docela obstojí, ale už v dobe, keď ešte len crashoval inštalácie nás, odvážlivcov s Archom, existovali oveľa zaujímavejšie riešenia. Ruinit Voidu, OpenRC riešiaci všetky problémy, ktoré SystemD pôvodne riešiť mal na ~100 riadkov shellu, InitNG ktorý neriešil nič, ale dokázal nabootovať Arch pod 5 sekúnd a pár ďalších čo im neviem prísť na meno.
Každý z nich je schopný nahradiť klasický init jedným príkazom na správcu balíčkov a zvyšok systému o tom ani netuší. Preto sa radšej prešlo na obludnosť, čo pokladá za vhodné kompletne redefinovať ako sa operačný systém správa :)
-
Filip JirsákStříbrný podporovatel
... mountuje filesystémy, spravuje konzole, vypočítava machine_id (nech je to čokoľvek), parsuje stringy v kernel commandline, prehadzuje procesy medzi jadrami cpu, číta konfiguračné súbory, reštartuje procesy, zapisuje container_id a vypisuje help. A to som prosímpekne prešiel v tom zdrojáku len do polovice, než ma to prestalo baviť.
Aha, tak vy jenom nevíte, co je to proces.Kde sa zrazu vzalo to "konkrétního" ? :)
Předpokládal jsem, že to tam patří, aby to tvrzení vůbec dávalo nějaký smysl. Co by podle vás znamenalo, že server očekává nějaký libovolný správce služeb? Že by bez nějakého libovolného správce služeb ani nešel nastartovat? A jak by ten server potom nastartoval nějaký libovolný správce služeb?Čo mne osobne vadí je, že sme miesto "lépe" prešli na "komplikovanejšie".
To už tak většinou je, že „lépe“ znamená „komplikovaněji“. Kdyby „lépe“ znamenalo jednodušeji, tak už to tak děláme dávno, protože by nebyla potřeba ta doba nutná ke zvládnutí toho komplikovanější. Auto je komplikovanější než žebřiňák, a žebřiňákem a ne autem jsme začli proto, že je to jednodušší a bylo potřeba nějaký čas, než jsme zvládli udělat něco tak komplikovaného, jako je auto. Stejně tak postavit dům je komplikovanější, než najít jeskyni, ale opět trvalo nějakou dobu, než jsme se to naučili.OpenRC riešiaci všetky problémy, ktoré SystemD pôvodne riešiť mal na ~100 riadkov shellu
Jak OpenRC řeší socketovou aktivaci, jak řeší logování standardního výstupu, jak řeší zpětné informování od služby, že nastartovala a poskytuje své služby? Jak zajistíte s OpenRC to, aby webserver měl spojení k databázi, když ho potřebuje? Hluboce se zamyslíte, řeknete, že do dvou minut by mohla databáze nastartovat, a přidáte na začátek startu webového serveru dvouminutové čekání?Každý z nich je schopný nahradiť klasický init
Jenže většina uživatelů nechce nahrazovat klasický init něčím, co se bude chovat úplně stejně. Chtějí správce služeb, který bude službám poskytovat podporu v tom, co služby obvykle potřebují (aby si to každý nemusel implementovat znova sám, jako se to děje se SysVinitem) a který dokáže zajistit spolupráci služeb. To, že takový správce služeb, aby mohl rozumně fungovat, bude mít jako jednu ze svých komponent i PID 1, je jenom jedna taková nepodstatná maličkost. -
> Aha, tak vy jenom nevíte, co je to proces.
Nie, ja na rozdiel od Vas len tusim o com hovorim. Mal som to potesenie kod SystemD skumat pri svojom pokuse reimplementovat parser na unit files. Je mimochodom dostupny na githube, proces o ktorom hovorime najdete v "main.c" :)
> A jak by ten server potom nastartoval nějaký libovolný správce služeb?
Serveru by malo byt jedno, ci je pusteny z bashu, initu alebo cez spravcu sluzieb. A pokial mi je zname, vacsina serverov takto funguje. Pristup apache a spol nieje pravidlom, ide o vynimku danu asi hlavne tym, ze sa snazi fungovat na obrovskom mnozstve systemov.
SystemD ale takyto princip neuznava, respektive ho poklada za "legacy". Spravna Linuxova sluzba by po novom mala predpokladat spustenie pod spravcom, ktory jej preda konfiguraciu, sockety, pipy, nastavi limity, komunikuje s nou cez dbus a zabezpeci zotavenie... Spravca samozreje moze byt lubovolny, za predpokladu, ze je to SystemD :)
Je to v podstate lepsie navrhnuta verzia toho, co so sluzbami robi Windows.
> (...) žebřiňákem a ne autem jsme začli proto, že je to jednodušší (...)
Hovadina. Auta vytlacili rebrinaky rychlostou, nie jednoduchostou. "Lepsie" a "jednoduchsie" su dve celkom rozdielne metriky.
> To, že takový správce služeb, aby mohl rozumně fungovat, bude mít jako jednu ze svých komponent i PID 1, je jenom jedna taková nepodstatná maličkost.
Podstatnost tejto malickosti uz bola demonstrovana tak silne, ze do SystemD pridali kod restarujuci system pri pade :) Ono totiz na nic z toho, co ste menoval PID 1 nepotrebujete, ale ked uz Vas posadne komplex a rozhodnete sa ho predsalen obsadit, zistite, ze kazdy pad toho bazmeku zrazu znamena kernel panic.
> Jak OpenRC řeší (...)
Inetd, start-stop-daemon -1, start-stop-daemon, symlinkom vo /var/run/openrc/started/, nastavim "needs mysql". V poradi ako ste sa pytal.
Ale skratene, rovnako ako vsetky ostatne inity napisane po 1995. Fakt by sme nemali prepadat iluzii, ze SystemD prisiel s niecim novym :D
-
Filip JirsákStříbrný podporovatel
proces o ktorom hovorime najdete v "main.c"
Ne, proces opravdu nenajdete v souborumain.c. Proces je spuštěný kód v paměti počítače, který má nějaký identifikátor přiřazený jádrem.Serveru by malo byt jedno, ci je pusteny z bashu, initu alebo cez spravcu sluzieb.
Souhlasím.A pokial mi je zname, vacsina serverov takto funguje.
To je vám známo špatně. Spousta serverů má speciální mód pro hloupé správce služeb, kdy se server sám daemonizuje, aby se dostal z dosahu správce služeb.SystemD ale takyto princip neuznava, respektive ho poklada za "legacy". Spravna Linuxova sluzba by po novom mala predpokladat spustenie pod spravcom, ktory jej preda konfiguraciu, sockety, pipy, nastavi limity, komunikuje s nou cez dbus a zabezpeci zotavenie...
Nesmysl. Servery, které se prostě spustí na popředí, provádějí svou činnost a zapisují na standardní výstup, servery, které prostě spustíte z shellu a chovají se úplně stejně, jako když je spustíte ze správce služeb, fungují se systemd perfektně. Mnohem lépe než se SysVinitem.Je to v podstate lepsie navrhnuta verzia toho, co so sluzbami robi Windows.
Ani náhodou. Služba ve Windows má speciální vstupní bod, jiný, než když aplikaci spustíte ručně. Další speciální funkci má pro ukončení služby. Nic takového systemd nevyžaduje. Když si vytvoříte „server“ tím, že spustítenetcataby naslouchal na nějakém portu a zrcadlil přijatá data třeba na standardní výstup, můžete ten spouštěcí příkaz zkopírovat do unit souboru a poběží vám to jako služba pod systemd, včetně správného ukončení.Hovadina. Auta vytlacili rebrinaky rychlostou, nie jednoduchostou. "Lepsie" a "jednoduchsie" su dve celkom rozdielne metriky.
Přečtěte si ještě jednou, co jsem doopravdy napsal.Auta byla lepší – a aby mohla být lepší, nedalo se toho dosáhnout jinak, než že byla komplikovanější než žebřiňák. Stejně tak je Linux komplikovanější než DOS, aby mohl být lepší, btrfs je komplikovanější než ext3 nebo FAT, aby mohl být lepší než tyto souborové systémy. To, že dokážeme udělat něco lepšího, je v drtivé většině případů dané tím, že zvládneme komplikovanější věc, na kterou bychom dříve neměli.
Ono totiz na nic z toho, co ste menoval PID 1 nepotrebujete, ale ked uz Vas posadne komplex a rozhodnete sa ho predsalen obsadit, zistite, ze kazdy pad toho bazmeku zrazu znamena kernel panic.
Ale pořád na PID 1 potřebujete proces, který spustí správce služeb a který bude řešit zombie procesy. No a co teď s tím dělat, když takovou aplikaci nemáte – SysVinit toho dělá zbytečně moc, ale spolupracovat rozumně se správcem služeb neumí. Tak asi nezbývá, než ten kód pro PID 1 napsat.nastavim "needs mysql"
Jak se OpenRC dozví, že MySQL je schopna obsluhovat požadavky? Ten aplikační server totiž nepotřebuje, aby začal start procesu MySQL, ale aby databáze byla schopná přijímat požadavky. A pokud byste k takové signalizaci chtěl použít to, že se spuštěný proces ukončí – jak potom zjistíte, že se ukončil ten skutečně výkonný proces?Ale skratene, rovnako ako vsetky ostatne inity napisane po 1995.
Ano, sleep s bulharskou konstantou ve startovacích skriptech. To je skutečně profi řešení. -
> Ne, proces opravdu nenajdete v souboru main.c. Proces je spuštěný kód v paměti počítače, který má nějaký identifikátor přiřazený jádrem.
Nie, proces je systematicka seria operacii smerujuca k urcitemu cielu :)
> Spousta serverů má speciální mód pro hloupé správce služeb, kdy se server sám daemonizuje, aby se dostal z dosahu správce služeb.
Povedal by som, ze si zamienate init so spravcom sluzieb. Systemy, ktore pouzivaju to druhe vacsinou pustaju servery s flagmi, ktore demonizaciu vypinaju.
> a aby mohla být lepší, nedalo se toho dosáhnout jinak, než že byla komplikovanější než žebřiňák.
To je skutocne zaujimava teoria. Suhlasil by ste s nazorom, ze je elektromobil z mnohych pohladov lepsi, nez klasicke auto?
Pretoze technicky su elektromobily 2 magnety s baterkou, riesenie ovela, ovela, OVELA jednoduchsie nez riadena explozia chemicky upravovanej zmesi plynov v presne tvarovanych piestoch klasickeho motora.
> Jak se OpenRC dozví, že MySQL je schopna obsluhovat požadavky? Ten aplikační server totiž nepotřebuje, aby začal start procesu MySQL
Pocka na vytvorenie socketu. Pomerne jednoduche.
> Ano, sleep s bulharskou konstantou ve startovacích skriptech. To je skutečně profi řešení.
Bulharske konstanty su najdolezitejsim stavebnym prvkom kazdeho systemu :) Ale inotify funguje tiez vcelku dobre.
-
Filip JirsákStříbrný podporovatel
Nie, proces je systematicka seria operacii smerujuca k urcitemu cielu :)
Bavíme se tu o linuxových procesech…Povedal by som, ze si zamienate init so spravcom sluzieb.
Já bych řekl, že nevíte, co je to init. Ani v linuxových instalacích, kde se používal nebo používá SysVinit, nespouští služby init, ale až nějaká nadstavba (obvykle shellových skriptů), která je z toho initu spuštěná. Takže i tyhle instalace mají nějaký správce služeb, i když je co do funkčnosti velmi primitivní a často nemá ani jméno.To je skutocne zaujimava teoria. Suhlasil by ste s nazorom, ze je elektromobil z mnohych pohladov lepsi, nez klasicke auto?
Elektrický motor je podstatně jednodušší, než spalovací motor. Proto také po žebřiňáku nenásledovala auta se spalovacím motorem, ale nejprve elektromobily. Ke zvládnutí komplikovanosti spalovacích motorů bylo potřeba se nejprve dostat. Pak se podařilo zvládnout i tuto komplikovanost a rozšířily se automobily se spalovacími motory, protože byly lepší, než tehdejší elektromobily, u kterých byl problém s dojezdovou vzdáleností. Dnes už zase zvládáme komplikovanější věci (efektivnější baterie, rychlejší dobíjení, efektivnější asynchronní motory), takže nám to umožňuje dělat elektromobily, které jsou v mnohém lepší, než automobily se spalovacími motory. Je to pořád tak, jak jsem napsal na začátku – nejprve musíme zvládnout komplikovanější technologii, a pak díky té komplikovanější technologii můžeme něco zlepšit.Pocka na vytvorenie socketu. Pomerne jednoduche.
To je fajn. V době, kdy jsem OpenRC nepoužíval, to nic takového neumělo. Pořád je to ale předpokládám jen pozorování nějakých vedlejších efektů (ukončení procesu, vytvoření souboru). Nebo už OpenRC umí i to, že mu proces v okamžiku plné inicializace pošle nějakou zprávu?Ale inotify funguje tiez vcelku dobre.
I na inet sockety? -
tnr (neregistrovaný)
> SystemD ale takyto princip neuznava, respektive ho poklada za "legacy". Spravna Linuxova sluzba by po novom mala predpokladat spustenie pod spravcom, ktory jej preda konfiguraciu, sockety, pipy, nastavi limity, komunikuje s nou cez dbus a zabezpeci zotavenie... Spravca samozreje moze byt lubovolny, za predpokladu, ze je to SystemD :)
Delat je to nikdo (a rozhodne ne systemd) nenuti. Na druhou stranu je to prijemne zlepseni, ze pokud tohle vse nechci po 151. resit v serveru, co pisu, tak ze nemusim - muzu pouzit funkcionalitu spravce sluzeb a spoustu dalsich veci z nej.
> Je to v podstate lepsie navrhnuta verzia toho, co so sluzbami robi Windows.
Souhlasim, konecne v Linuxu je neco, co dokaze podobne uzitecne funkcionalite z Windows konkurovat a neni to nutne resit v kazdem serveru zvlast (a povetsinou vic ci mene blbe)> Hovadina. Auta vytlacili rebrinaky rychlostou, nie jednoduchostou. "Lepsie" a "jednoduchsie" su dve celkom rozdielne metriky.
Hezky priklad. A systemd vytlacil ostatni init systemy rychlosti, komplexnim resenim beznych situaci a jednoduchosti pro autory distribuci a uzivatele. Ale samozrejme se vzdy najde nejaky pomatenec, co v tom hleda konspiraci RedHatu / Microsoftu / Zednarske loze / .... Ale uz nikdo nedokaze vysvetlit, co by z toho treba ten RH mel - mohli si klidne nechat systemd jako proprietni reseni, stejne tak ho zadna distribuce nemusela pouzivat, RedHat nikomu nuz na krku nedrzel (a ano, pokud duvodem je snaha usetrit vlastni zdroje, abych mohl pouzivat co nejvice prace od RH bez nutnosti zmen a vlastni invencne, tak v takovem pripade proste smula - bud to musi akceptovat, nebo si platit vlastni vyvojare).> Podstatnost tejto malickosti uz bola demonstrovana tak silne, ze do SystemD pridali kod restarujuci system pri pade :)
A? Normalni soucast zakladniho core systemu skoro vsude.> Ono totiz na nic z toho, co ste menoval PID 1 nepotrebujete, ale ked uz Vas posadne komplex a rozhodnete sa ho predsalen obsadit, zistite, ze kazdy pad toho bazmeku zrazu znamena kernel panic.
Init nepotrebuje, moderni zaklad systemu ano. Je proste holt potreba se smirit s tim, ze system postaveny na bastleni shell skriptu a neposkytujici komplexni funkcionalitu pro sluzby vc. API pro automatizaci (kam presne takove veci, ktere SD resi, patri), dnes nikdo z velkych Linuxovych hracu (a jejich zakazniku) proste nechce...
-
> Na druhou stranu je to prijemne zlepseni, ze pokud tohle vse nechci po 151. resit v serveru, co pisu, tak ze nemusim - muzu pouzit funkcionalitu spravce sluzeb a spoustu dalsich veci z nej.
Lenze ty to samozrejme riesit musis, nakolko SystemD funguje len na par specifickych konfiguraciach Linuxu. Takze poriesis jeho i vsetkych 15 konkurencnych standardov a potichu budes dufat, ze ten 16-ty uz bude dostatocne pouzitelny na to, aby sa uchytil.
> A? Normalni soucast zakladniho core systemu skoro vsude.
Vlastne si takuto hovadinu pred SystemD dovolil spravit iba Windows :)
> Hezky priklad. A systemd vytlacil ostatni init systemy rychlosti, komplexnim resenim beznych situaci a jednoduchosti pro autory distribuci a uzivatele.
... rovnako ako v 90-tych rokoch vytlacil Unixy technicky vyspelejsi OS od Microsoftu. To bol sarkazmus, mimochodom.
> Je proste holt potreba se smirit s tim (...)
Vlastne som doposial realne nasadenie SystemD u nikoho vacsieho nevidel. Pisu sa sice kvanta clankov o tom, ako je stvoreny pre kontainery, AWS, embeded zariadenia, LHC... ale vsetko je to len krasna teoria, od ktorej sa realne nasadenie drzi setsakramentsky daleko. Nechapem preco...
-
Podotýkám že to nejsou jen Windows, kde je správa služeb řešená rozumně. Solaris má Service Management Facility, který používá deklarativní definici servisu, závislosti a API pro správu. Apple má launchd, který má ty podobné vlastnosti. Pro mě je velmi těžké pochopit, jak někdo může považovat za výhodu klubko skriptů, ke kterému ani neexistuje API. Argument "dělá se to tak od roku 1979, takže to musí být správně" nějak neberu. Spíš to vidím tak, že "klasiku" obhajují admini, které dost často pohled uživatele nebo vývojáře jaksi nezajímá; hlavně aby se to neměnilo a nemuseli se učit nějaké novinky.
-
NULL (neregistrovaný)
@Ophir
To je stejná pitomost, jako kdyby jsi napsal, že každý kdo nechce poviné kvóty na počty žen v jednotlivých zaměstnáních, tak tvrdí, že ženy patří jenom do kuchyně.
Stejně je to trošku laciné rovnítko, když je init špatný, tak je prostě systemd dobrý i kdyby . . . . To promiň, ale to je kritérium jak ...... -
KateStříbrný podporovatel
Ale on nepsal nic o systemd. Jen obhajoval tenhle styl správy služeb nezávisle na implementaci oproti původním init skriptům.
-
NULL (neregistrovaný)
@Kate
A jak pak se v tomto případě "tenhle styl správy služeb", o kterém je tu řeč150+ příspěvků, jmenuje?
Ale to se systemd nebyla přímo reakce na @Laela, ale tak celkem povzdychnutí k tomu stylu 'Argument " dělá se to tak od roku 1979, takže to musí být správně" nějak neberu', protože z toho okamžitě čiší argument "To že je to staré neznamená automaticky že je to špatné" a ani to že "je to nové, neznamená automaticky že je to dobré". A to, že je to staré řešení špatné ještě neznamená, že kdejaký bastl nový je automaticky lepší. Může a nemusí, ale hodnotit to podle stáří . . . ach jo.
-
tnr (neregistrovaný)
> Lenze ty to samozrejme riesit musis, nakolko SystemD funguje len na par specifickych konfiguraciach Linuxu. Takze poriesis jeho i vsetkych 15 konkurencnych standardov a potichu budes dufat, ze ten 16-ty uz bude dostatocne pouzitelny na to, aby sa uchytil.
Jenze systemd nefunguje na par specifickych konfiguracich Linuxu, ale na vsech majoritnich distribucich :) Takze pokud nemam v planu multiplatformnost, muzu klidne pouzit systemd API primo a neresit milion veci, ktere uz resi systemd.
> Vlastne si takuto hovadinu pred SystemD dovolil spravit iba Windows :)
Nebo to treba dela Mac OS X - takze vlastne 3 majoritni systemy (Windows, Mac OS X, majorita Linuxovych distribuci).Ale jinak podpora watchdogu je uplne v kazdem systemu, i treba v FreeBSD (watchdogd), je to normalni soucasti systemu uz dekady.
> ... rovnako ako v 90-tych rokoch vytlacil Unixy technicky vyspelejsi OS od Microsoftu. To bol sarkazmus, mimochodom.
Tvuj sarkasmus je mimo, vytlacil spoustu existujicich reseni, protoze byl technicky lepsi a univerzalnejsi (napr. NetWare), lepe se integroval s klienty (NT domain, pozdeji ActiveDirectory) ci byl pro spoustu firem proste jednodussi na spravu (SMB).
Naopak nevytlacil tam, kde technicky nezaril - prave specializovane servery, webove (ale casto i aplikacni) servery, firewally, routery atd. Tam vsude zustaly bud specializovane operacni systemy nebo zustaly dominantni UNIXy a MS mel smulu. -
SystemD je neuveriteľný galimatiáš kódu a komponentov, ktoré sú síce teoreticky samostatné, ale v praxi prepojené a neoddeliteľné jeden od druhého. Vytvára tak single point of failure bežiaci na privilegovanej vrstve, masívny, prakticky neauditovatelný a spoločný pre viaceré distrá.
Jeho hlavnou devízou nikdy nebola technická vyspelosť, ale fakt, že sa ho podarilo politicky presadiť do dvoch hlavných distribúcií. Za jednou z nich stojí firma čo riadi jeho vývoj.
SystemD je prakticky antitézou k Unixu. Namiesto "do one thing and do it well" máme systém, ktorý zvláda mnoho, ale väčšinu na hovno. Mnoho komponentov bolo čiastočne nahradených funkciami SystemD a následne odstránených, takže k dispozícii ostala len čiastočná funkčnosť. Akékoľvek ladenie je zážitok, nakoľko chyby sa zásadne prejavujú v komponentoch ktoré ich nespôsobili. Pokiaľ Vám napríklad po nabootovaní občas nefunguje sieť, nemusí to byť nutne problém v NetworkManageri. Môže to spôsobovať SystemD reimplementácia mountovania a fakt, že sa niektoré súbory vo VFS zjavia až po tom, ako sa ich dhcpcd pokúsi prečítať.
Stále viac a viac komponentov má na SystemD nevysvetliteľné závislosti, takže sa dostávame do podobného vendor-lock-inu ako s Windows. Pokiaľ si zvolíte distro s technicky lepším init systémom, môže sa Vám stať, že nebude fungovať zvuk, pretože ovládací panel pulseaudia závisí na SystemD. Alebo vtipnejší príklad, Snap, nový balíčkovaní systém Ubuntu, stavia na architektúre kde kľúčový démon spustený inak, než so SystemD, bez chybovej hlášky spadne.
Tím za SystemD trpí šialeným prípadom "NIH syndrómu" a neustále sa snažia vynachádzať koleso, necápajúc pri tom prečo by malo byť guľaté. Pekným príkladom je napríklad ich verzia "rm", ktorá donedávna pri rekurzívnom mazaní pokladala ".." za podadresár a snažila sa rekurzívne zmazať celý disk.
A toto všetko je vystupňované na n-tú nepochopiteľnou aroganciou vývojárov, ktorá si nezadá ani s prístupom ľudí za prostredím Gnome. Diskusia nieje prípustná, za problémy môže zásadne niekto iný. Proste sranda, aspoň kým to človek môže pozorovať z ďaleka :)
