Jak odrovnat systemd jedním tweetem

Andrew Ayer v příspěvku How to Crash Systemd in One Tweet na svém blogu minulý týden ukázal, jak lze příkazem, jenž se i s popisem vejde do jediného tweetu, zcela odrovnat systemd a tím odrovnat celý systém využívající jako init právě systemd. Bezpečnostní chyba CVE-2016-7795 (systemd #4234) se dostala do systemd před více než dvěma roky. Při její opravě byla nalezena další bezpečnostní chyba CVE-2016-7796. Samotný příspěvek rozpoutal bouřlivou diskusi.

3.10.2016 23:23 | Ladislav Hagara | Bezpečnostní upozornění

Komentáře

[R]

To je bomba :D Skoda, ze to nemam kde vyskusat.

[Bedňa]

Tiež používam systemd FREE distribúcie (antiX, Devuan), ale rád by som to odskúšal, je to prdel :)

PS: Ten výraz systemd FREE som nevymslel ja, ale bol by som rád keby na to niekto napísal RFC alebo tak niečo :)

[kralyk z abclinuxu]

Uhh, zas nějakej systemd-cholerik. Takovýhle bugy se objevují prakticky v jakýmkoli software, ale on z toho udělá velkou svatou válku proti systemd. Pak si stěžuje, že systemd není napsán v memory-safe jazyce, přitom se ale nejedná o problém memory managementu. S Twitterem nebo tweety to taky nijak nesouvisí. Ten člověk vypadá, že je dost mimo.

Náš administrátor shledal tento komentář závadným.

ad hominem

Zobrazit komentář

[kralyk z abclinuxu]

Jistě, že jsem to četl. Naprostá většina těch řečí 1) v zásadě nesouvisí s tím bugem a 2) by se dala úplně stejně říct o spoustě dalšího software, včetně třeba Apache o kterém tam debatují s tím druhým typkem. Nebo o kernelu. Prostě ten člověk akorát rantuje, stejně jako ty...

[j]

Nevsim sem si ze by apache bezel pod rootem a mel pod palcem vse ostatni. Na neco takovyho sou ponekud naprosto diametralne odlisny naroky, a jednoduchost, cimz padem prehlednost a bezpecnost, jsou prave tim, co se od toho ceka.

[kralyk z abclinuxu]

Nevsim sem si ze by apache bezel pod rootem a mel pod palcem vse ostatni.

Nevidím, jakým způsobem z toho plynou nějak diametrálně větší bezpečností nároky. Init je v podstatě pouze glorifikovaný spouštěč programů. Apache oproti tomu v produkčním prostředí typicky neustále zpracovává nebezpečná data zvenku a pracuje s kriticky citlivými informacemi jako různé klíče, hesla atd. Viz další komentáře v diskusi.

[j]

Nevsim sem si, ze by systemd byl "jen" spoustec programu, zato sem si vsim, ze se sere uplne do vseho, a neda se to vypnout.

Apache ma typicky striktne omezeny pristup k datum a s jeho napadenim zvenku se tak nejak v kazdym normalnim produkcnim nasazeni pocita.

[kralyk z abclinuxu]

Nevsim sem si, ze by systemd byl "jen" spoustec programu

Mluvil jsi o initu, ie. PID 1 - to je 'jen' spoštěč programů i v případě systemd.

Apache ma typicky striktne omezeny pristup k datum a s jeho napadenim zvenku se tak nejak v kazdym normalnim produkcnim nasazeni pocita.

Ano, odtud ty vysoké nároky na bezpečnost...

[Prohnutá nudle]

ja si vsim, ze kernel bezi v ring 0. Chyby jsou v nem take.

[mirec]

Možnosť zložiť systemd zápisom do socketu, ktorý môže vykonať neprivilegovaný proces je dosť veľky prúser, rozhodne nie "minor security issue" ako to zľahčujú ľudia zo systemd. Áno chyby sa stávajú, preto by tak dôležité komponenty mali byť čo najmenšie a najjednoduchšie, aby bol priestor na chyby minimálny.

[Sid]

Podla toho cloveka zo systemd ta chyba ma hodnotenie 3.5, takze by som zase az tak moc to nehrotil. Podla tvojej teorie by vlastne aj linux mal by napisany ako microkernel. A vlastne hocico ine. Myslim, ze ten clovek zo systemd popisal ten syndrom co tam je celkom presne, stret medzi init teoretikmi (tj. v zivote som nenapisal nic na podobnej urovni, ani nic pododne) a ludmi co tomu co vsetko sa musi riesit rozumeju. Cest vynimkam. Tym nechcem tu zase zacat flame o systemd ano alebo nie, len to beriem z pohladu programovania. Pride mi to podobne ako ked si kazdy povie, ze implementovat nejaky security algoritmus je predsa easy kym sa nezrazi s realitou. Alebo vlastne hocico co musi byt nalezite univerzalne a vysporiadat sa s milionom moznosti pouzitia.

[mirec]

Ok, takže v podstate ktorýkoľvek klient môže na serveri spôsobiť DOS je v podstate nič moc chyba, správne?

Mám rád architektúru mikrokernelu. Nie som si istý, či má na bežne dostupnom hardvéri zmysel kvôli chybám priamo v HW, ale koncept je to určite zaujímavý.

A ehm mimochodom kedysi som malý init programoval.

[Sid]

Asi by bolo fajn rozlisovat medzi lokalne zneuzitelnou chybou a niecim co mozes mozes urobit vzdialene bez pristupu. Predsa tie skore sa nerobia len tak ako koho napadne. A netvrdim,ze je to banalita akurat, ze to nie je koniec sveta ako sa anti systemd ludia snazia to podat. To, ze si naprogramoval nejaky maly init je fajn, ale na predstavu by bolo treba vidiet tvoj kod, lebo to moze by podobne ako ked urobim simple subor kde ukladam data a pridam nejaky lock a nazvem do DB. Alebo tiez nie, mozno si to mal dobre vymyslene a sikovne a potom samozrejme mozes do systemd busit z pohladu cloveka co vie ako to urobit inac a lepsie.

[kralyk z abclinuxu]

Možnosť zložiť systemd zápisom do socketu, ktorý môže vykonať neprivilegovaný proces je dosť veľky prúser, rozhodne nie "minor security issue" ako to zľahčujú ľudia zo systemd.

Nevšim jsem si toho, že by to zlehčovali. Nevidím, v čem se to liší od CVE v jakémkoli jiném software, na poměry CVE to ani není nijak hrozné. Závažnější chyby se našly v rozšířenějším software (třeba dekódery typu libpng, libtiff atd. atd.).

Standardní proces je oznámit chybu, nejlépe s tím, že se člověk zamyslí, jestli by nebylo na místě utajení, dokud nebudou k dispozici rychlé opravy, zaregistrovat CVE a nastartovat celý ten proces bezpečnostních záplat.

Někteří lidé jsou ale zjevně na takový postup moc histeričtí a to vezmou to jako příležitost k sáhodlouhému a s chybou nesouvisejícímu postěžování si na to, jak jim systemd zavraždil babičku.

[mirec]

Nevšim jsem si toho, že by to zlehčovali

It’s a tantrum when you use a minor security issue as justification to rant about everything remotely related to systemd

Závažnější chyby se našly v rozšířenějším software (třeba dekódery typu libpng, libtiff atd. atd.).

Bežia pod PID 1 (tj. najdôležitejším procesom)? Je správne, že sa chyby PID 1 berú vážnejšie než v ľubvoľnom softvéri.

[kralyk z abclinuxu]

1) Kdyby ten člověk tu chybu bral vážně, tak by ji ohlásil autorům standardním procesem. Ten blogpost, kde akorát rantuje o Twitteru, Go, Rustu a X dalších zcela nesouvisejících věceh, mě moc nepřesvědčuje, že to bere vážněji než lidé od systemd. Spíš naopak.

2) Je to DoS chyba, ne např. RCE chyba nebo něco podobného závažnějšího, na její zneužití potřebuješ přístup na daný stroj, navíc si nejsem jist, jak moc to je skutečně využitelné pro DoS - jestli jsem to správně pochopil, tak např. na webovém serveru by tohle neudělalo nic, dokud bys nepotřeboval šachovat se službama, což se typicky neděje.

Bežia pod PID 1 (tj. najdôležitejším procesom)? Je správne, že sa chyby PID 1 berú vážnejšie než v ľubvoľnom softvéri.

V čem je PID 1 v kontextu této chyby specielní? Stejná chyba např. ve webovém serveru nebo kdekoli ve stacku by způsobila pravděpodobně stejné nebo větší škody.

[mirec]

V čem je PID 1 v kontextu této chyby specielní?

V tom, že odstaví systém. Pád apacha môže automaticky vyriešiť supervizor, stratí sa pár requestov a server beží ďalej. Pád PID 1 sa rieši podstatne ťažšie.

[kralyk z abclinuxu]

Co myslíš tím "odstaví systém"? Zkusil jsem to na svém systému, systemd zhučel, ale httpd normálně dál obsluhuje requesty, databáze též funguje, "odstavený systém" si asi představuju jinak. Kdybych takhle shodit httpd, a to třeba opakovaně, tak bych to viděl jako horší dopad.

Disclaimer: Neříkám, že to je úplná prkotina. Je to bezpečnostní problém, oprávněně bylo vytvořeno CVE, atd. Ale ta histerie mi opravdu nepřijde na místě.

[mirec]

Neskúšal, čítal som len popis. Na produkčných strojoch nebudem riskovať a všetky ostatné stroje mám bez systemd (menovite OpenRC 3 stroje, upstart 1 stroj, busybox mimo krabičiek 1 stroj).

[Sid]

to je sakra problem urobit VM a vyskusat to tam? :)

[pavlix]

Asi není dostatečná motivace. :)

[Bedňa]

Ale ta histerie mi opravdu nepřijde na místě.

Súhlasím, so systemd sú ďaleko horšie problémy :)

[Heron]

Co myslíš tím "odstaví systém"? Zkusil jsem to na svém systému, systemd zhučel, ale httpd normálně dál obsluhuje requesty, databáze též funguje, "odstavený systém" si asi představuju jinak. Kdybych takhle shodit httpd, a to třeba opakovaně, tak bych to viděl jako horší dopad.

Ta chyba způsobila, že se zastavily všechny systemd operace. Takže kdyby ten supervizor (jak píše mirec) byl systemd (restart on failure), což systemd prosazuje jako správné řešení, tak v případě zhučení toho httpd by už to nenaběhlo.

Nehledě na to, že systemd současně i doporučuje socket activation a to třeba i na ssh, takže je vůbec otázkou, zda by se admin na ten stroj vůbec dostal.

[Heron]

Nehledě na to, že systemd současně i doporučuje socket activation a to třeba i na ssh, takže je vůbec otázkou, zda by se admin na ten stroj vůbec dostal.

Tak jsem to otestoval (Debian Testing SD 231) a odpověď je: nedostal.

[kralyk z abclinuxu]

Se socket activation, nebo bez?

[Heron]

Se socket activation ssh.

Dokonce i login (na konzoli) je o něco pomalejší (asi se čeká na nějaký timeout), nakonec se ale přihlásí.

[pavlix]

Na to už jsem někde odpovídal.

Ne, vážně, problém služeb jako je SSH v kombinaci se systemd není v tom, že by systemd technicky nabízel horší možnosti než sysvinit s /etc/init.d, ale v tom, že vývojáři a příznivci systemd často doporučují řešení, která mají zásadní nevyřešené problémy. Přístup „po náš potopa“ je v téhle komunitě naprosto všudypřítomný. Už hodněkrát jsem si říkal, že jsem debil, že to nedělám stejně, protože kdybych začal před pár lety, tak mi můžete touhle dobou všichni leda vlézt na záda stejně jako mistrovi.

[Xerces]

Kód init je klíčová část OS, nelze to srovnávat s knihovnami, které ani nemusím mít nainstalované. Proto jsou chyby vnímány mnohem citlivěji, proto by ten kus kódu měl být co nejmenší, aby se to potenciální množství chyb eliminovalo (jak už tu někdo poznamenal) a proto je celý systemd takový fail (jak tu spousta lidí neustále dokola křičí).

[Xerces]

A než to tu někdo napíše. Ano vím, že tvůrci alibisticky tvrdí, že systemd není init.

[kralyk z abclinuxu]

1) Chci tě vidět, jak nemáš nainstalovanou libpng.

2) Nejcennejší na mém stroji není root ani ring 0, ale $HOME. Na libpng mám tudíž v podstatě mnohem přísnější bezpečnostní nároky než na systemd, protože libng má přístup do $HOME a neustále zpracovává nedůvěryhodná data z venku. systemd zdaleká není tak exponovaný.

3) Proč systemd-hateři nemají stejný nárok na minimalizaci kódu na kernel a důležité démony (zmiňoval jsem Apache) jako na systemd? Proč mohou být kernel a všichni démoni, které beží pod rootem a/nebo obsluhují kriticky důležitá data, napsáný monoliticky v C a systemd nesmí?

[kralyk z abclinuxu]

Ještě přidám relevantní xkcd.

[nic]

Ach jo... ale přesto by ten člověk, co to kreslil, nedal dobrovolně svoje admin heslo nikomu, že?? Proč asi.

[Václav "Darm" Novák]

Trochu jsi minul pointu. Trochu hodně.

[pavlix]

Proč asi? Třeba protože se nic takového v tom komixu neříká? :D

[Heron]

To je relevantní jak noha. Pokud ten člověk chce všechny ty věci používat pod jedním účtem, tak může. Stejně tak dobře ale může na každou z těch činností vyhradit vlastní uživatelský účet nebo dokonce virtuálku. Jako vtip dobrý, ale jinak úplně mimo.

[kralyk z abclinuxu]

Stejně tak dobře ale může na každou z těch činností vyhradit vlastní uživatelský účet nebo dokonce virtuálku.

... což v praxi udělá 0.001% lidí, protože to je pohodlné jak utírat se šmirglpapírem...

[Heron]

Tohle se dá napasovat na kde co. Také je jednodušší, aby všechny služby běžely pod rootem a měly přístupy k všem datům na disku, ale přes to v praxi admini (nebo teda alespoň já) se snaží všechny služby provozovat pod svými vyhrazenými uživateli, kteří mají přístup pouze k nutnému minimu dat. Ano, je to práce, ale osobně toto považuji za integrální součást práce admina.

[little.owl]

ale přes to v praxi admini (nebo teda alespoň já) se snaží všechny služby provozovat pod svými vyhrazenými uživateli

Stastni clovek, Portable Services v systemd vam podobny pristup umozni .

[Heron]

Asi nerozumím, tohle šlo provozovat vždy, to nemá se systemd nic společného.

[little.owl]

Mel jsem napsat 'usnadni', kdy sluzbu budu moci sandboxovat za dvacet sekund na par radcich konfiguraku bez pleveleni systemu novym uzivatelem a vsim s tim spojenym.

[kralyk z abclinuxu]

Tohle se dá napasovat na kde co. Také je jednodušší, aby všechny služby běžely pod rootem a měly přístupy k všem datům na disku, ale přes to v praxi admini (nebo teda alespoň já) se snaží všechny služby provozovat pod svými vyhrazenými uživateli, kteří mají přístup pouze k nutnému minimu dat.

Myslím, že je zjevné, že ten komix je o deskoptu. Ne serverech je situace typicky mnohem složitější, takže tam to záleží na architektuře konkrétního řešení. Může tam záležet na zabezpečení roota víc, ale někdy třeba i míň, pokud např. na nějakém stroji běží služba, ale root toho stroje nemá přístup k datům té služby.

Obecně bych ale rozhodně nesázel na nějaké černobílé pravidlo typu "je potřeba hlavně zabezpečit roota, ostatní tolik nevadí, to nejsou root účty...".

[Heron]

Myslím, že je zjevné, že ten komix je o deskoptu.

Ano vím, ale když jsem se naposledy díval, tak i na desktopu šlo vytvořit více uživatelských účtů.

Obecně bych ale rozhodně nesázel na nějaké černobílé pravidlo typu "je potřeba hlavně zabezpečit roota, ostatní tolik nevadí, to nejsou root účty...".

Tak on na to asi nikdo nespoléhá, podstatné je však to, že pokud už se někdo proboří nějakou službu na daném stroji, tak se nedostane ke všem datům, ale jen k datům té aplikace. Což, pravda, v době, kdy je zvykem dávat jednu službu na jeden server a žádná další data tam už prakticky nejsou není tak zajímavé.

[mirec]

Proč systemd-hateři nemají stejný nárok na minimalizaci kódu na kernel

Kto sú tí systemd-hateri? Akože ja? Ja som pravidelne kritizoval monolitický kernel a dúfal, že Linux prevalcuje Hurd. Nestalo sa. Ja rozhodne nie som nadšený z monolitu.

[Sid]

otazka je ci taka komplexnost sa da vobec dobre modularizovat (v zmysle ze samotna modularizacia nebude neprehladnejsia ako monolit) a ak ano aky bude vykonostny dopad. Proste nie kazdy model musi byt vhodny pre kazdy system napriek tomu ako krasne na prvy pohlad vyzera.

[mirec]

V prípade mikrokernelov sa benchmarky dajú nájsť. Nie je tam až taký problém s výkonom, skôr je problém, že rôzne kusy hardvéru aj tak môžu pomocou DMA robiť problémy a nad všetkým Intel AMT (alebo niečo podobné od AMD), dokonca ani samotné CPU nie sú bez chýb (kto by to čakal? ), takže nakoniec stroj s mikrokernelom môže havarovať aj keď softvér nebude mať žiadne bugy.

Čo sa týka PID 1 .. no viem si predstaviť variant kde PID 1 sa bude starať prakticky len o spustenie daemona, ktorý už môže byť ovládaný socketom a ak niekto tohto daemona zostrelí alebo havaruje tak ho naštartuje znovu.

[kralyk z abclinuxu]

Když bude démon obsahovat DoS chybu, bude restart k ničemu - prostě útočník vyvolá chybu znova, případně v rychlém sledu, takže init odmítne službu znova startovat. Nehledě k tomu, že u některých služeb může démon startovat dlouho, způsobuje to problémy se ztrátou dat, atd...

[sid]

Myslim benchmark pri porovnatelnej komplexnosti OS. Ten zvysok je snad vtip? Aky je rozdiel v hw chybach pri mono a micro jadre? Dost pochybujem ze vies o com pises.

[mirec]

Ako ma mikrokernel zachráni ak DMA zapíše blok pamäte tam kam nemá, alebo pri chybe v implementácii UEFI spustí kód nad OS ...?

[Sid]

Pointa je snad v tom, ze toto nemozes ovplyvnit takze to absolutne nema vplyv na porovnanie microkernel vs monokernel.

[mirec]

Však píšem, že napriek mikrokernelu sa mi systém môže tak či tak zosypať. Nie som si preto istý, či sa oplatí vzdať sa časti výkonu za väčšiu robustnosť v istých situáciách, alebo ísť ďalej cestou monolitu. Pekne sa to rozoberalo v diskusii Tanenbaumom - Linus.

[R]

Lenze Linux bezi hlavne na serveroch. Tam v $HOME nie je nic a k libpng sa malokedy nieco dostane.

[kralyk z abclinuxu]

Ano, ale platí tam stále to samé: Na veškerém kódu těch serverových služeb záleží minimálně stejně, ne-li víc, jako na kódu PID 1. Od céčkového základu démonů přes veškeré použité knihovny až po poslední obslužný skript, chyba v čemkoli z toho může napáchat škody minimálně stejné, příp. větší.

[Filip Jirsák]

Ano, k libpng se na serveru dostávají akorát taková nepodstatná data, jako data poslaná vzdálenými uživateli. Takže chybu libpng na serveru může zneužít vzdálený uživatel, což je zcela nepodstatný problém, zejména ve srovnání s tak katastrofální chybou, jakou je to, že místní uživatel může způsobit, že všechny služby systému poběží dál, akorát s nimi administrátor nemůže manipulovat.

Jak píše Kralyk nebo MadCatX, je to hloupá chyba, zrovna u PID 1 bych měl zvýšené nároky, aby k takovýmhle chybám nedocházelo, ale ta chyba se normálně opraví a není to nic zvláštního. Ale těch nesmyslných keců okolo, třeba že by PID 1 měl být napsán v nějakém jazyce s memory managementem… Proč to dotyčný vytýká jenom systemd? Kolik je těch PID 1 napsaných v nějakém jazyku s memory managementem? Ostatně, kdyby to byl případ systemd, tak budou systemd-hateři zase nadávat, jak je možné, že něco tak důležitého jako PID 1 je závislé na nějakém složitém runtime a není to napsané v jednoduchém C.

Mám takový návrh. Vzhledem k tomu, že u podobných zpráviček nejde vůbec o obsah, podstatný je pouze výskyt slova systemd v nadpisu zprávičky, který spustí lavinu nesmyslných komentářů – co takhle jednou týdně uveřejňovat pouze zprávičku s nadpisem „systemd“, pod ní se mohou systemd-hateři vyřádit? Ostatní budou vědět, že je zbytečné do takové diskuse lézt, protože nehrozí, že by se tam něco dozvěděli.

[bhy]

Mám takový návrh. Vzhledem k tomu, že u podobných zpráviček nejde vůbec o obsah, podstatný je pouze výskyt slova systemd v nadpisu zprávičky, který spustí lavinu nesmyslných komentářů – co takhle jednou týdně uveřejňovat pouze zprávičku s nadpisem „systemd“, pod ní se mohou systemd-hateři vyřádit? Ostatní budou vědět, že je zbytečné do takové diskuse lézt, protože nehrozí, že by se tam něco dozvěděli.

však to už tak de facto je, ne?

[Filip Jirsák]

Úrovní debaty ano. Akorát z titulku zprávičky se dá nabýt dojmu, že to je myšleno vážně. Proto jsem navrhoval ten jednoslovný název „systemd“ – spouštěč tam je, takže tenhle účel to splní, ale zároveň ostatní budou vědět, že to není nic pro ně.

[Xerces]

... akorát s nimi administrátor nemůže manipulovat Tím jste ten jinak pěknej pokus o nezaujatou obhajobu problému zabil. Nechci, aby to vypadalo, že se navážím do systemd ze strachu, že mi jednou jako administratorovi sebere práci (možná to tak je). Ale fakt mám neodbytný pocit, že si tady pod sebou řežeme větev(ve) za potlesku několika proaktivních blbů, ale možná jsem ten blbej jen já. To ukáže až čas.

[kralyk z abclinuxu]

Jen pro pořádek, já nejsem nijak extra nadšený proponent systemd. Vyhovuje mi ta initová část, tím to ale dost končí, journald nemám rád (IMHO s**čka) a ostatní části mi jsou dost někde.

Snažil jsem se pouze ukázat tu nesmyslnost té argumentace v souvislosti s touhle chybou.

[Xerces]

1) Mám nainstalovaný libpng a spoustu dalších potenciálně nebezpečných knihoven. 2) U mě je $HOME pochopitelně taky TOP. Ať si zpracovává, hlavně že pracuje 3) Třeba mají. K httpd například existuje dost použitelných/jednoduše zaměnitelných alternativ

[pc2005]

Proč systemd-hateři nemají stejný nárok na minimalizaci kódu na kernel

Ale mají .

napsáný monoliticky v C a systemd nesmí?

No já jsem proto, aby bylo všechno napsaný v C .

[nyan]

Na libpng mám tudíž v podstatě mnohem přísnější bezpečnostní nároky než na systemd, protože libng má přístup do $HOME

To plati mozna pro tebe, doma. Kdyz mas server s vicero sluzbami, a (hypoteticky) nekdo ti shodi PID 1 a nejak to poskodi i vsechny dalsi sluzby na tom serveru, asi moc nadsenej nebudes. Takze jo, na desktopu je HOME > PID 1; na serveru to muze byt naopak.

[JoHnY3]

Blbost. Na serveru je v prvni rade podstatne jestli jde o local nebo remote exploit. Pokud bude bug v libpng, tak muze byt zranitelny kazdy druhy web na kterem bezi diskuzni forum s moznosti vkladat obrazky. Staci buffer overflow pri parsovani metadat a o zabavu je postarano. Google by mohl s Androidem vypravet. Chyby v knihovnach jsou jedny z nejnebezpecnejsich, protoze roznaseji zranitelnost na sirokou paletu dalsiho SW. Prikladem budiz OpenSSL, kvuli kteremu musela asi tak pulka planety menit SSL certifikaty na daemonech s verejnou dostupnosti z netu.

Pro PID 1 jde vymyslet rada katastrofalnich bugu, ale CVE-2016-7795 mezi ne nepatri. Neni to malickost, ale nikdo mi tim nekompromituje server z pohodli sveho domova.

[Heron]

1) Chci tě vidět, jak nemáš nainstalovanou libpng.

Ze 12 strojů mám libpng nainstalováno přesně na 6 strojích. Na rozdíl od systemd.

Proč systemd-hateři nemají stejný nárok na minimalizaci kódu na kernel a důležité démony (zmiňoval jsem Apache) jako na systemd? Proč mohou být kernel a všichni démoni, které beží pod rootem a/nebo obsluhují kriticky důležitá data, napsáný monoliticky v C a systemd nesmí?

Podle čeho soudíš, že nemají? Sám používám apache pouze tam, kde není vyhnutí (aplikace je na tom nějak závislá) případně tam, kde jsem si ještě nenašel čas přepsat rewrite pravidla do nginxu. Jinými slovy si každý vybírá software podle toho, jak mu vyhovuje a pokud mu vyhovuje minimalistický tak si jej nainstaluje a používá.

[pavlix]

Podle čeho soudíš, že nemají?

To je velice jednoduchá logika.

1) Kdo není nadšený ze systemd nebo se ho neznaží za každou cenu omlouvat, je systemd hater.

2) Je zjevné, že systemd hater je blbec, jinak by nebyl hater.

3) Blbec se určitě nechá lehce nachytat na tom, že je nekonzistentní.

4) Nekonzistentní je zcela jistě úplně ve všem.

5) Z toho vyplývá, že miluje balast.

6) Kromě systemd.

7) Z toho vyplývá, že jsi nekonzistentní systemd hater, který miluje libovoný balast, ale nesnáší systemd. Q.E.D.

Elementární logika, ne? :D

[kralyk z abclinuxu]

Ze 12 strojů mám libpng nainstalováno přesně na 6 strojích. Na rozdíl od systemd.

Záleží hlavně na tom, jestli pracuje s nedůvěryhodnými daty (což může těch 6 potenciálně redukovat na 0, anebo taky ne, že, podle toho, k čemu ty stroje jsou). Každopádně doufám, že pomocí pid 1 ty stroje žádná data z venku nezpracovávají

Podle čeho soudíš, že nemají? Sám používám apache pouze tam, kde není vyhnutí (aplikace je na tom nějak závislá) případně tam, kde jsem si ještě nenašel čas přepsat rewrite pravidla do nginxu. Jinými slovy si každý vybírá software podle toho, jak mu vyhovuje a pokud mu vyhovuje minimalistický tak si jej nainstaluje a používá.

Tak jestli nginx je minimaslistické řešení a je z tvého hlediska v pořádku, pak úplně nevidím, v čem je problém se systemd, příp. s jeho init částí...

[Heron]

Tak jestli nginx je minimaslistické řešení a je z tvého hlediska v pořádku

Rozhodně je menší jak apache. Jestli je to minimální systém splňující dané požadavky nevím.

[MadCatX]

^^^ Přesně tak.

Autor využil tohoto hloupě působícího bugu k nastartování inkvizice proti systemd. Velmi rychle pak utekl po tangentě k více či méně nesouvisejícím problémům. Kdyby se podobný lokální DoS našel kdekoliv jinde, vyjde o tom maximálně zprávička a patch. Protože jde ale o systemd, je nutné okolo toho vyburcovat haló blogpostů, tweetů a flejmů.

Kdybych si chtěl zahrát na konspirátora, myslel bych si, ze Lennart vymyslel systemd proto, aby demonstroval, že i Linuxí a FOSS komunita žere bulvár. My akorát místo Kardashianů a Štikové řešíme skrze PA a systemd Poetteringa se Sieversem...

[pavlix]

Co je na tom špatně?

[aubi]

...a vubec, vysel uz ten patch?

[pavlix]

Jaký?

[Bedňa]

postěžování si na to, jak jim systemd zavraždil babičku

Teba fakt nevadí ako sa okolo kernelu vytvára monolit ktorý všetko požiera? Popravde je toto pre mňa hlavný dôvod nepoužívania systemd.

Nový fajnovejší init by sa hodil, ale aby sa dal skompilovať bez tých všetkých závislostí okolo.

Tak o kernel sa tiež hovorí ako o monolite, len to nie je úplne tak, žeby zožral všetko okolo seba, nieje len napísaný ako microkernel a servery, zato môžeš určiť čo v ňom bude a čo nie. Napr. pre rokmi som mal problémovú TV kartu, tak som si ovládač skompiloval ako modul a keď ju seklo, tak som ovládač unloadol a potom loadol späť.

V systemd sa proste nedá žiť, že chcem len init a ostatné nie, systémd je dnes celý Linux enviroment a buď ho príjmeš ako monolit, alebo neuvižiješ žiadnu z jeho komponent.

[kralyk z abclinuxu]

Teba fakt nevadí ako sa okolo kernelu vytvára monolit ktorý všetko požiera?

Na systemd mi vyhovuje ta init část. Dále mi vyhovuje udev a asi mě ani nijak zvlášť netankuje, že je součástí systemd. Koneckonců, krom Linuxu používám také OS, které mají kernel a userspace v jednom repo a taky to přežiju Co mě vysírá je journald, se kterým mývám problémy a který se AFAIK ani nedá ze systemd vyhodit - tady bych uvítal změnu. Jinak ty ostatní věci se AFAIK povyhazovat dají, neměl jsem ale s nimi problémy.

[Bedňa]

Vďaka Gentoistom používam "systemd udev" aj ja bez systemd, čiže eudev, len sa pýtam prečo to tak nespravili sami autori aby človek mohol používať komponenty ktoré chce bez ďalších zbytočných závislostí.

To že sa journald nedá vypnúť pokladám za úplne nezmyselné a dalo by sa o tom popísať aj viac.

Nemôžem proste používaním podporovať projekt ktorý hľadí len na seba rozbíja komunitu a všetky princípy pre ktoré som si Linux vybral.

[pavlix]

Protože autorům záleží v první řadě na úspěchu a vytvářejí si něco jako sektu. Pamatuju si oznámení projektu eudev, kdy sám veliký osobně přišel narušovat přednášku na FOSDEM, aby projekt co nejdříve poškodil.

[little.owl]

narušovat přednášku na FOSDEM, aby projekt co nejdříve poškodil.

Ale to je jen tvoje interpretace, ze? Viz.

[pavlix]

Ano, to je moje interpretace, nebudu přece psát cizí interpretaci, ne? :)

[Bedňa]

Protože autorům záleží v první řadě na úspěchu a vytvářejí si něco jako sektu.

Najlepšie na tom je, že takto označujú nás ktorí sme prosili, upzorňovali a neskôr už len bezmocne nadávali na smerovanie projektu.

Pamatuju si oznámení projektu eudev, kdy sám veliký osobně přišel narušovat přednášku na FOSDEM, aby projekt co nejdříve poškodil.

To je smutné a čo sa mu musí uznať, tak ako jediný dokázal rozhádať celú komunitu okolo Linuxu. Možno je to tým, teda aspoň ja mám taký pocit, že prv by sa to stať nemohlo, komunita by ho neprijala. Dnes už priateľstvo asi toľko neznamená, mám pocit že devalvuje.

[Sten]

udev nezávisí na systemd. eudev přidává pravidla specifická pro OpenRC a Upstart.

journald se nedá vypnout, protože sbírá logy třeba ze stderr či změn stavů služeb. Ale klidně ho lze nastavit, aby všechno posílal jen do syslogu.

[j]

A hele, ty uz zvanis i tady zejo ... udev bez systemd nefunguje, Gentoo dela jednak eudev a druhak udrzuje patch, kterej z udevu zavislosti na systemd odpare ... ZATIM.

[Filip Jirsák]

Systemd používá k logování otevřené Journal API, takže by mělo být možné nepoužívat journald a místo něj použít jinou implementaci Journal API, až jí někdo napíše.

[kralyk z abclinuxu]

A je to API nějak rozumně stabilní?

[Filip Jirsák]

Nezměnilo se pokud vím od roku 2013.

[kralyk z abclinuxu]

Ok, tak to zní slibně, díky.

[little.owl]

Stabilita techto interfacu nema ani garanci Lenartova cestneho slova, ted nic na cem by se dal stavet i logger. Prave situaci s nestabilnimi vnitrnimi interfacy povazuji za nejvetsi problem systemd.

[Filip Jirsák]

Journal API není žádný nestabilní vnitřní interface, je to stabilní veřejné API.

[little.owl]

Mate pravdu, beru zpet, vypada to, ze toto API je pokryto Interface Stability Promise.

[biolog]

Ta chyba vede na spuštění útočníkova kódu s většími právy? Ne. Získá útočník nějaká tajná data? Ne. Poškodí nebo změní útočník nějaká data? Ne. Je zneužitelná vzdáleně? Ne. Takže si neumím představit neškodnější chybu, která by ještě byla bezpečnostní chybou.

[Jendа]

FYI neprivilegovaný uživatel může Linux složit už několik let a nikoho to netrápí.

[pc2005]

Takovýhle bugy se objevují prakticky v jakýmkoli software, ale on z toho udělá velkou svatou válku proti systemd.

V jakýmkoliv jiné softwaru ti prostě jen nenajede ten software, v systemd ti nenajede systém .

[fukfukfuk]

Zrejme jedinej systemd-cholerik tu jses ty, kdyz nevidis, jaka je to sracka

Ale co, s fanatikem nema cenu se hadat...

[kralyk z abclinuxu]

1) Polij hlavu studenou vodou, 2) klikni tady.

[fukfukfuk]

Ja ti hlavu studenou vodou rad poleju, skutecne to potrebujes, jen mi rekni, kde te najdu

[kralyk z abclinuxu]

Takže k tomu kliknutí ses nedostal, že?

[little.owl]

Podstatne je, ze chyba byla opravena do dvou hodin, coz je velmi slusny response time. David Timothy Strauss dobre zhodnotil Ayeruv prispevek, pojem tantrum sedi.

Flamy o systemd upadaji, kde jsou ty doby kdy odpurci hrozili migraci [svych tisicu serveru] na BSD ... .

[a1bert]

no jestli to nebude tim, ze uz je zmigrovano ;)

[little.owl]

Mozna, ale podil BSD systemu dale klesa. Navic, byt jako FreeBSD user, nemam pocit ze ten system je v soucasne dobe schopen nahradit Linux.

[Heron]

Asi tak.

Osobně jsem jeden květnový víkend vyhradil instalaci FreeBSD, s tím, že si s tím budu hrát potom a jaké bylo mé překvapení, kdy jsem během jednoho odpoledne po práci měl hotové vše včetně služeb a to i těch, které jsem původně migrovat ani nechtěl. Pro linux admina je to jednoduché a ty služby od té doby jedou a kromě updatů (které dělám ručně) o tom serveru nevím. Vše jede jak má.

Zatímco na systemd jsem teď 3 dny řešil chybu v systemd-journald, o které se v systemd komunitě ví už 4 roky (a zřejmě to nikoho z nich vůbec netankuje).

https://github.com/systemd/systemd/issues/2913

https://bugs.freedesktop.org/show_bug.cgi?id=50184

[little.owl]

Zatímco na systemd jsem teď 3 dny řešil chybu v systemd-journald, o které se v systemd komunitě ví už 4 roky (a zřejmě to nikoho z nich vůbec netankuje).

To vypada na race condition, kterou je nutne resit v kernelu a jeho API, kdy na urovni systemd a systemd-journald to nelze vyloucit, jen limitovat a podle logu to Lennart roky sleduje. Podobny problem budou mit z principu i jine loggery, pokud do podobne situace vlitnout.

[Heron]

Ano, já jsem ten bugreport četl a trochu jsem nevěřil vlastním očím. Ta funkce nefungovala spolehlivě nikdy. A já nevím jak kdo, ale pro mě je nespolehlivá funkce horší, než kdyby tam vůbec nebyla. A co víc, o tom se ví už 4 roky ale v manu o tom není ani čárka (třeba v sekci bugs, která tam taky není).

[little.owl]

A já nevím jak kdo, ale pro mě je nespolehlivá funkce horší, než kdyby tam vůbec nebyla.

Teoreticky ano, prakticky nikoliv. Nestava se to az tak casto a staci kdyz se zaloguje, ze zprava neni uplna a informace v _CMDLINE, _COMM, _EXE, _SYSTEMD_CGROUP, _SYSTEMD_UNIT chyby.

A co víc, o tom se ví už 4 roky ale v manu o tom není ani čárka (třeba v sekci bugs, která tam taky není).

O tom bez debaty ano, i kdyz zalezi s jakym kernelem to pouzivate a jak je opatchovany - a to je otazka pro maintainery distribuce.

[Heron]

Na tohle mám jiný názor.

Teoreticky ano, prakticky nikoliv. Nestava se to az tak casto a staci kdyz se zaloguje

Říkají ti něco Murphyho zákony? Tenhle přístup se ti vymstí v nejhorší možné chvíli, kdy to budeš nejméně potřebovat (a ano, v praxi se opravdu všechno tohle stává naprosto běžně). Takhle se spolehlivé systémy nenavrhují. Ty největší katastrofy (v průmyslu apod.) vždy vznikají jako celá série selhání a stačí, aby libovolný z těch systémů fungoval a ta událost by nenastala.

[little.owl]

Zas tolik se nelisime a ja jsem jen klasifikoval pripadne dopady v konkretnim pripade jinak.

Obcas v praci predstiram, ze skutecne pracuji na navrhu a vyvoji safety critical systems, prevazne podle specifikace ISO_26262, tedy nejakou praktickou zkusenost mam. Pri navrhu se podilim na FMEA, prevazne jeji SW casti, ktera musi spolu s designem projit nezavislym prezkoumanim. System bez chyb neexistuje, a vzdy se vyhodnocuje pravdepodobnost selhani, jeho zavaznost a dopady, a scenar pro recovery ci bezpecne selhani. System na bazi Linuxu bych na cokoliv jineho nez QM nedal a i tak bych vyzadoval minimalne externi monitoring nebo duplicitu.

[Bill Gates]

Na flamy kolem systemd vam kazdy kasle, ale je fakt, ze ti co chteji systemd prosadit a stoji si z ruznorodych duvodu za nim ho budou vychvalovat do nebes i kdyby co bylo, to nezmeni nikdo.

U nas na firme (uz 1500+ zakazniku) nema OS se systemd jakoukoliv sanci, protoze vetsi hnuj u nas nikdo nevidel a to netvrdim jen ja, ale ukazala to az sama praxe. Jinde to muze byt jinak, treba to jinde sedlo, u nas urcite ne. V praxi jsme zjistili ze je to opravdu lepsi volba se mu vyhnout protoze zanasi prilis mnoho problemu, mnohem vice nez prinosu.

Odpurci tedy ne ze hrozi migraci, ti uz davno migrovali :) A zakaznici jsou s provozem nasich zarizeni spokojeni a to je hlavni. Zbytek kolem systemd mam u paty :)

[Sid]

Ak mi niekto povie,ze systemd (bavme sa teraz cisto o inite) je vacsi hnoj ako to co bolo doteraz tak neviem co mysliet.

[j]

Je to radove horsi hnuj ... protoze ac ty scripty obcas vypadaly hruzostrasne, tak nic nebranilo adminovi si proste vedle ubastlit vlastni, a to klidne s jedinym radkem kterej bez jakyhokoli srani proste spusti to, co se spustit ma. A klidne to ani nemusi umet vypnout.

Kdyz se ti neco podela v systemd, jako ze je tam neco podelany furt (a s kazdou verzi jinak) coz je ostatne definice widlows ... tak stim neudelas zhola nic, navic se jeste ne prave ridce dozvis, ze to je tak spravne.

Neni to tak dlouho, co sem se kralovsky pobavil, kdyz si dodavatel vybral distro se systemd, tak ho dostal ... a vyjebalo s nim prave systemd ... protoze misto toho, co chtel startovat dodavatel, si tvrdohlave startoval neco uplne jinyho, co startovat vubec nemelo ... a obsadil samo port, kterej byl potreba pro tu appku ...

[kralyk z abclinuxu]

Je to radove horsi hnuj ... protoze ac ty scripty obcas vypadaly hruzostrasne, tak nic nebranilo adminovi si proste vedle ubastlit vlastni, a to klidne s jedinym radkem kterej bez jakyhokoli srani proste spusti to, co se spustit ma. A klidne to ani nemusi umet vypnout.

Zaprvé mi úplně nepřijde, že by systemd bránilo vytvořit si skript.

Zadruhé doufám, že veškerý ostatní software také brzo přepíšeme do bashe, aby byll možné chyby snadno opravovat, aniž by člověk musel kompilovat...

[j]

Co je ti platnej vlastni script, kdyz nefunguje systemd? Nevsim sem si, ze by ostatni sw ovlivnoval stabilitu a bezpecnost startu celyho systemu. Nemluve o tom, ze kdyz se mi nebude libit logovani s normalnim initem, tak si muzu vybrat z asi tak bambiliardy jinych logeru, kdezto v systemd musim vzdy mit ten jejich nefunkcni bastl.

[kralyk z abclinuxu]

Co je ti platnej vlastni script, kdyz nefunguje systemd?

Nevím, jak u tebe, ale u mě jsou skripty schopné startovat démony a dělat všechno možné nezávisle na systemd. Nějak úplně nevidim ten rozdíl oproti třeba OpenRC, ten když nenastartuje, tak je to to samé, a o sysvinitu to platí v podstatě taky - celý ho stejně nepřepíšeš.

Nemluve o tom, ze kdyz se mi nebude libit logovani s normalnim initem, tak si muzu vybrat z asi tak bambiliardy jinych logeru, kdezto v systemd musim vzdy mit ten jejich nefunkcni bastl.

Moc nevím, proč mi tohle píšeš, na tom se shodujeme...

[Jooky (inactive)]

Skus si pozriet OpenRC. Ten sa umyselne vynechava v porovnani a systemd porovnavaju len s cistym sysvinit. Sysvinit neni ziadna slava, ale fungoval spolahlivo. OpenRC ako prvy zaviedol zavyslosti medzi sluzbami (startovanie v spravom poradi) a svoju robotu robi dobre. Daemony startuje a vypina spolahlivo + cez par prikazov vies bez problemov ovladat masinu.

Naproti tomu sa systemd vybral cestou, ze integruje a ovlada aj kavovar v hale pred serverovnou a nic z toho nerobi poriadne. Na laptope mam teraz distro so systemd a je to cele zle ... okrem toho, ze nie vzdy nastartuje vsetko ako ma, tak ma vyslovene dostala jedna vec. Potreboval som docasne uvolnit disk, tak som dal btrfs device add / remove, aby sa presunili data na iny disk. Po dokonceni presunu mi systemd odmontoval vsetky subvolume a uzavrel luks sifrovanie ... kto ho k tomu prosil ?! to iste z casu na cas robi aj so daemonmy ... takze ano. Systemd je hnoj a na seriozne riesenie nepatri ...

[Jooky (inactive)]

dalsie srandy su zakilovanie fsck ak ma pocit, ze bezi dlho a podobne ...

[j]

Tak nejak, openrc dela presne to, co delat ma. A nijak se ti nesere do vyberu jednotlivych casti systemu.

[Ota]

my bychom ve firme take radi pokracovalii bez systemd, ALE.

Pouzivame centos a 30.11.2020 je konec s centos6 a co potom? Rada software jako MariaDB, Kerio a dalsi jsou vpodstate k dispozici jen pod RH. Pro FreeBSD je to treba prekladat a nebo hledat po vsech certech. To je dost nejiste. Ja se obavam, ze jsem se v tom free zase dostali do peknych zavislosti, sice je to hezke pro tech 500 vyvojaru v Brne, ale takhle jsem si to vlastne nepredstavoval.

[R]

Akoze MariaDB v inych distribuciach nie je? :D

[Ota]

je, ale mariadb.org pro freebsd pakety nedela.

[daemon]

A co Ti brání si ty věci pro FreeBSD přeložit resp. z čeho máš obavu? Proč si myslíš, že balíčky které sis přeložil sám, by měly být "horší" než ty, které přeložil někdo jiný?

[R]

U nas je tiez pocet strojov beziacich so systemd rovny nule. Bol jeden na skusku, neobstal...nastastie v Debiane nie je problem init system vymenit (na serveri; zatial).

[Bill Gates]

To se me zatim ne zcela povedlo. Proto prevlada Devuan. Jak servery, tak zarizeni kde je graficke prostredi.

[little.owl]

Vida, jeden se nasel!

nema OS se systemd jakoukoliv sanci

To si povime za par let.

protoze vetsi hnuj u nas nikdo nevidel

Tak to jste asi videli ztracene malo, i kdyz to zuzime na init.

a to netvrdim jen ja, ale ukazala to az sama praxe.

V praxi naopak doslo k vyrazne adopci systemd, a to budete velmi tezko popirat.

V cem jste videli prakticke problemy branici jeho nasazeni?

Odpurci tedy ne ze hrozi migraci, ti uz davno migrovali :)

Pak to bylo takove mysi rvani, zadna vetsi migrace se podle vsech dostupnych cisel nekona.

[a1bert]

o jakych cislech tady porad mluvis? muzes se o ne s nami podelit ?

[little.owl]

Porad?

muzes se o ne s nami podelit ?

Jiste. Napriklad statistiky verejne pristupnych serveru na Internetu. Viz. zde, zde ci zde. Statistika TOP500 (jeden propadajici se BSD stroj). V embedded svete se vyrobci SoC prestali vubec bavic o moznosti podporovat BSD, viz treba podil na ARM - a pritom systemd si tam uz nasel misto. Chapu, ze nekdo muze povazovat tato cisla za nepresna, nicmene pokud by doslo k nejake vyraznejsi migraci k BSD, bylo by to asi nekde patrne.

[Matlák]

Z těch grafů jen vyplývá že je na sestupu BSD a že je na vzestupu Debian. To jestli mají ty systémy v sobě systemd je irelevantní. To, že Debian adoptoval systemd spousta uživatelů-administrátorů špatně nese a tuny mašin jedou pořád na sysvinit, to vám garantuju.

Jinak nepopírám že distributoři mají systemd rádi (míň konfigurace a hlavně unifikovaná konfigurace) o to víc ale brečí lidi co s tím mají pracovat dlouhodobě. Ale je to relativně mladý projekt na takové škále - to se (snad) časem vyřeší, kde jsou ty flamy o pulseaudio? PA třeba na svém stroji nepoužívám, ale neznám moc lidí kdo by si na PA stěžoval, a na většině desktopů co znám to jede parádně...

[little.owl]

Z těch grafů jen vyplývá že je na sestupu BSD a že je na vzestupu Debian.

Ilustruje je to o co tu slo: nastup BSD, jako oaza bez systemd, se asi nekona. To jestli se jedna o Linux se systemd ci bez jsem neresil, a Debian podle zminenych zdroju spise ztraci.

o to víc ale brečí lidi co s tím mají pracovat dlouhodobě.

A to mate podlozeno jak? A jaky podil? Me prijde ze RHEL7 byl prijat pomerne pozitivne.

[trekker.dk]

V cem jste videli prakticke problemy branici jeho nasazeni?

Jenom ze zvědavosti, počítalo by se "je to sračka" jako praktický problém?

[cezz]

Nie.

[j]

Ma ty prostoto .. jaka adopce, v provoznich systemech jeste peknych par patku nebude zadny distro, ktery tuhle hruzu ma. A az admini na svych lab strojich zjistej (jako ze uz zjistili) jak se to chova, tak dospejou k naprosto jednoznacnymu zaveru, ze tohle na provozni system nikdy nikdo davat nebude - teda s vyjimkou, ze chce firmu privist na buben.

Zatim vsichni s klidem a pohodou pouzivaji distra s LTS podporou do 2k20+.

[little.owl]

No ovsem. A Red Hat je v cervenych cislech, obrat jde dolu jak kamen a az zkonci placena podpora RHEL6 a predchozich produktu, vyhlasi bankrot.

[Bill Gates]

typicky systemdbijec urovne "hlava nehlava". Ja mu rikam ze nam se jede dobre bez systemd a vse nam slape u 1500 platicich zakazniku, on rika ze nemame pravdu a ze systemd je proste in.

A v cem jsme videli problemy? No proste neslapalo to stabilne. Treba shutdown zamrzl nekde tesne pred vypnutim a zarizeni se nevyplo. Spousta zbytnych administrativnich nastavovatek, ktere nepotrebujeme. Je toho vicero, jestli ocekavate seznam problemu ktere mi nasledne vyvratite ze problemy nejsou a ze si mame nastudovat tamto a ono ohledne systemd, tak na to dlabanec, o to nestojim :) Nevysvetlujte mi v cem je to dobre, me to uz ted po zkusenostech velmi nezajima. Je to zbytny sw bez ktereho se obejdeme a stabilne fungujici alternativa existuje, coz je velmi dobre.

Ze doslo k adopci o tom neni sporu. To nikdo nenamita. Udelalo to z tech distribuci ale pekne nepouzitelne a nestabilni hybridy.

Mysi rvani? Jak to myslite? Prece se nebudu vztekat s nejakym nefunkcnim a nestabilnim kusem software a zbavim se ho hned. Mysi rvani tedy podle vas znamena chybu jako ze jsme se dokazali rychle oprostit zbytneho a problemy zavadejiciho software... no tak to pokladam spis za prinos. Porad lepsi nez se zacyklit v nefakturovatelnych zasazich a ve volajicich klientech, ze tam a onde neco neustale vypadava a nejede stabilne. To se ted vubec nedeje bez systemd. Se systemd bezna vec ze se neco podela kde to clovek neceka. Proto to zavcasu letelo do softwarovych lovist a systemd je u nas sproste slovo.

[sid]

Ked tak citam vsetky tieto nareky vzdy ma napadne ci vsetci distributori a programatori su tak dementny ze nasadzuju systemd a vsetci admini tak genialny... Som hlavne zvedavy ked o par rokov uz nebude napr debian podporovat nejake sucasne veci co urobia. Ci pislusne sklopia usi a presedlaju na aktualnu verziu alebo budu sami sa starat o support.

[nyan]

ci vsetci distributori a programatori su tak dementny

Tak vetsina distro je zamerena na desktop uzivatele, ti budou max rvat na netu; ti co maji servery si bud zaplati podporu (a pak to neni jejich problem) nebo to proste vyhodi a maji klid... hadam. Takze distributorum to muze byt jedno. Zvlast kdyz neni temer zadna konkurence.

[j]

Programatori se narozdil od adminu u ty nefungujici srackomety nemuseji starat.

[Xerces]

Ámen bratře.

[little.owl]

... on rika ze nemame pravdu a ...

A to ze rikam presne kde?

Treba shutdown zamrzl nekde tesne pred vypnutim a zarizeni se nevyplo.

To mate tedy pech. Moznost rychle nabootovat a ukoncit, se vsim souvisejicim, mi prave prijde jako silny bod systemd, jak ukazuji veci jako CoreOS, a to vcetne debugovani, ladeni a monitoringu.

Spousta zbytnych administrativnich nastavovatek, ktere nepotrebujeme.

Kdyz je nepotrebujete, tak je nepouzijte. Prusvih je, kdyz je potrebujete a oni nejsou.

Mysi rvani? Jak to myslite?

Koukne sem. Desive, ze? Skoro jako tohle!

Jinak rceni pochazi ze satiry The Mouse That Roared:

The tiny (three miles by five miles) European Duchy of Grand Fenwick, supposedly located in the Alps between Switzerland and France, proudly retains a pre-industrial economy, dependent almost entirely on making Pinot Grand Fenwick wine. However, an American winery makes a knockoff version, "Pinot Grand Enwick", putting the country on the verge of bankruptcy. The prime minister decides that their only course of action is to declare war on the United States. Expecting a quick and total defeat (since their standing army is tiny and equipped with bows and arrows), the country confidently expects to rebuild itself through the largesse that the United States bestows on all its vanquished enemies (as it did for Germany through the Marshall Plan at the end of World War II). Instead, the Duchy defeats the mighty superpower, purely by accident ...

[Bill Gates]

To mate tedy pech. Moznost rychle nabootovat a ukoncit, se vsim souvisejicim, mi prave prijde jako silny bod systemd, jak ukazuji veci jako CoreOS, a to vcetne debugovani, ladeni a monitoringu.

Pech nemame my, ale systemd. Bez nej neni se shutdownem problem, volba je tedy jasna. Za silny bod systemd moznost rychle nabootovat a ukoncit se vsim souvisejicim tedy rozhodne nepovazuji protoze nefunguje jak ma v okamziku kdy bez systemd jede. Debugovat systemd-like shutdown neni relevantni. To by meli spise tvurci systemd, aby to bylo pouzitelne.

Kdyz je nepotrebujete, tak je nepouzijte. Prusvih je, kdyz je potrebujete a oni nejsou.

Takove, ktere bychom nezbytne potrebovali a byly jen v systemd, tedy stali bychom se na systemd zavisli, takove nastavovatka skutecne nepotrebujeme a jsem presvedcen ze je potrebovat nebudeme a kdyz ano, jiste najdeme alternativu bez systemd, tedy najdeme reseni na konkretni problem, ktere nam s sebou neprinese tisice dalsich neoddelitelnych a zbytnych problemu.

[little.owl]

Pech nemame my, ale systemd.

Tezko. Lidem okolo systemd je evidetne naprosto u zadele co si mysli minorita mimo (IMHO, to je problem) a nejsou ti co breci, jak se jejich svet v zadel obraci.

Bez nej neni se shutdownem problem, volba je tedy jasna.

Jasna volba v tomto pripade je zjistit, proc to selhava - jsme engineeri, ne hunanitni mluvky a tohle neni bezny problem. Systemd dava k dispozici dostatecne mnoztvi nastroju, a odezva vyvojaru na pripadne provozni bugy tohoto typu je pomerne dobra. Pokud reportujete bugy zpusobem jakym je tady popisujete, bude to nejspise tezke, tam se nema vyvojar skutecne ceho chytnou.

[Bill Gates]

Tezko. Lidem okolo systemd je evidetne naprosto u zadele co si mysli minorita mimo (IMHO, to je problem) a nejsou ti co breci, jak se jejich svet v zadel obraci.

Lide okolo systemd jsou u zadele nam, protoze ti nam penize negeneruji.

Jasna volba v tomto pripade je zjistit, proc to selhava - jsme engineeri, ne hunanitni mluvky a tohle neni bezny problem. Systemd dava k dispozici dostatecne mnoztvi nastroju, a odezva vyvojaru na pripadne provozni bugy tohoto typu je pomerne dobra. Pokud reportujete bugy zpusobem jakym je tady popisujete, bude to nejspise tezke, tam se nema vyvojar skutecne ceho chytnou.

Zjisteno. SystemD zamrznul v urcite fazi tesne pred vypnutim. Presneji to zkoumal kolega ale rozbor a logy odeme necekejte, jestli chcete, tak kdyby jste na problemy se shutdownem narazil, muzete zkoumat treba do aleluja jak vam bude libo. Pokud na problemy nenarazite tim lepe :) Nicmene neni velice duvod zkoumat proc nefunguje pochybne fungujici kus software, kdyz bez nej funkcnost neni nijak zasazena. V tomto pripade nevidim duvod ve vyuziti dodatecnych nastroju ktere systemd dava pro umozneni leceni jeho neduhu k dispozici. Odezva vyvojaru systemd je pro nas take nezajimava at je jaka chce, protoze systemd je pro nas (a pro nase zakazniky totalne) v tuto chvili zbytny kus software.

[pavlix]

Tezko. Lidem okolo systemd je evidetne naprosto u zadele co si mysli minorita mimo (IMHO, to je problem) a nejsou ti co breci, jak se jejich svet v zadel obraci.

S výjimkou jejího nejznámějšího člena, který naopak brečí velice rád.

[Jendа]

Jasna volba v tomto pripade je zjistit, proc to selhava

Nikoli. Pokud máš s nějakým software už několikátý takový problém, přičemž vedle existuje alternativa se kterou jsi takové problémy neměl a přitom umí všechny funkce, které potřebuješ, je jasná volba nainstalovat tuto alternativu.

[Jendа]

(já mám problém v tom, že používám Debian, jehož předchozí init systém také nefungoval -- takže dilema je, jestli je víc problémů se systemd, nebo s alternativním initem. Kdyby alternativní init fungoval, tak systemd nikde nemám.)

[Heron]

+1

[AsciiWolf]

Jaká je rozumná alternativa k systemd? Napadá mne jen OpenRC. Možná ještě Upstart, ale to je z bláta do louže.

[Jendа]

V Debianu mají jako alternativu ten jejich původní init (říkají mu sysv), který má „jediný“ problém v tom, že neumí zakázat start nějaké služby, jinak je docela rozumný.

[little.owl]

Na diskuzi o initu v Debianu byla zrejma jedna vec, na ktere se shodli proponenti systemd, upstart a openrc - tedy naprosta vetsina zucastnenych - puvodni init neni cesta a je nutne ho nahradit.

[Jendа]

Treba shutdown zamrzl nekde tesne pred vypnutim a zarizeni se nevyplo.

V systemd halt jenom zastaví systém, vypne ho poweroff. Jsem rád, že nejsem sám, kdo na to nepřišel…

Je to zbytny sw bez ktereho se obejdeme a stabilne fungujici alternativa existuje, coz je velmi dobre.

Opravdu? Já měl za to, že třeba Debian to bere jako přechodnou alternativu a časem to přestane podporovat. Nebo máte nějaké jiné distro?

[Jendа]

V cem jste videli prakticke problemy branici jeho nasazeni?

Spousta nedořešených problémů v nečekaných situacích (selhání fsck, 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)).

Nedostatek návodů a howto na zvládání novinek jako journald.

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, rc.local, 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ě 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 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“.

Veliká enterprise architektura, do které není snadné proniknout a blbě se to ladí na rozdíl od pár skriptů a symlinků v /etc/rc*.

[Jendа]

S každou verzí očekávání co dalšího co v unixech fungovalo posledních 30 let se zase rozbije

„Opravení“ aby halt dělal halt a poweroff dělal poweroff. Určitě je to logičtější. Ale několikrát jsem ten stroj musel navštívit nadávaje na ACPI a až když se mi to stalo i jinde mě napadlo zagooglit.

[little.owl]

Naprostou vetsinu veci, co jste popsal nemusite pouzivat a cast veci ma jine reseni a cast problemu co popisujete je dusledek integrace v Debianu.

[Jendа]

Naprostou vetsinu veci, co jste popsal nemusite pouzivat

„Naprostá většina“ z 8 je journald (přičemž ten musím používat alespoň do té míry, že musím nastavit logování do systlogu), nebo i něco dalšího?

a cast veci ma jine reseni

Ano, já vím. Všechno má řešení. Ale mě netěší řešit několik hodin věci, které posledních 30 let fungovaly, a pokud je to práce placená za hodinu, tak zákazníky to netěší platit.

[little.owl]

Chapu, ze pokud prejdete na systemd, musite zahodit cast najednou zastaralych vedomosti a zkusenosti, nove chyby a je toho najednou hodne. Na stranu druhou, systemd je tu let od Fedora 14, skoro sest let, trend byl viditelny, takze jako vylozenou novinku bych to neoznacoval.

[pavlix]

Otázka je, zda lze tak úplně brát Fedora 14 jako seriózní systém.

[AsciiWolf]

Co je tedy podle tebe seriózní systém? Ptám se, protože uvažuji, že na Fedoru přejdu na mých PC.

[pavlix]

Od této otázky se distancuju. Jen jsem chtěl zdůraznit, že Fedora 14 pocházela z dost experimentálního období.

[AsciiWolf]

Aha, ok.

[little.owl]

Fedora 14 jako seriózní systém.

To ale celkem irelevantni otazka. Pointa je v tom, ze systemd je tu skoro sest let, jeho pozice je zrejma jiz nezpozdeji od rozhodnuti uziti v RHEL a SLES, a pro cloveka ktery se zivi treba profesionalne spravou Linuxu by to nemela byt az takova novinka. Nevim jak ty, ale sleduji vyvoj v mem oboru a takove zmeny vetsinou neprichazi ze dne na den a cast novinek me s**e.

Ve Fedore 14 byl systemd "technology preview" se vsemi dopady, pouzivat se to dalo az od Fedora 15.

[Heron]

selhání fsck

Wau. Tak tohle je ještě masakróznější, než co jsem objevil já:

mdadm se nesestaví, protože je fakt vadné. systemd.device unita toho pole označena jako failed. n*90s čekání na mount fs (na zařízení, které tam není a jehož unita je failed - tolik k těm závislostem), heslo, rescue režim. Nastartoval jsem ručně mdadm pole s assembly force. Opuštění rescue režimu. Fs se najednou připojil ve write režimu a pochopitelně něco zapsal na to pole. Hodně štěstí s případným obnovováním dat.

sd je evidentně jedno, že nějaké block device je failed, stejně jako mu je asi jedno, že fs check neprošel. To je dost síla.

[Bedňa]

A už vie systemd nabootovať ak je pripojený Ubuntu Phone, alebo stále vysí v nekonečnej sľučke? To sú samé bonusy. Pre bežného užívateľa to môžu byť signály, že ten Linux stojí za hovno, popravde aj mne chvíľu trvalo kým som príšiel na to čo sa deje.

[cezz]

JJ, keby rovnaka chyba bola kdekolvek inde, asi by sme o nej nepoculi.

Pamatam si, ako som svojho casu zhodil logstash proste tym, ze som sa pripojil cez TCP a v zapati odpojil. Take chyby sa proste stavaju.

[pc2005]

Flamy o systemd upadaji, kde jsou ty doby kdy odpurci hrozili migraci [svych tisicu serveru] na BSD ... .

Na mě se nekoukej, já mám slackware a buildroot .

[pc2005]

Jo a ubuntoid v parallelle, který umřelo při dist-upgrade na systemd .

[TM]

Takže něco, k čemu zákonitě dojít muselo. Bylo to jen otázkou času. A banda mlamojů bude mít, pochopitelně, omluvy a zdůvodnění
Smutné, co se z Linuxu stalo...

[pavlix]

Linux není systemd. A kdo chce mít Linux bez systemd, ten se stará o to, aby tomu tak bylo. Třeba tady uživatel Bedňa mě pravidelně bombarduje ohledně čehokoli, co bych mohl vědět, jak provozovat bez systemd a kupodivu s tím nebývá zase až takový problém. Tohle je velká výhoda open source, že nemusíme všichni zobat z ruky jednomu šéfíkovi a žít s výsledkem toho, jak se zrovna vyspal.

[Bedňa]

Třeba tady uživatel Bedňa mě pravidelně bombarduje ohledně čehokoli, co bych mohl vědět, jak provozovat bez systemd a kupodivu s tím nebývá zase až takový problém.

Za čo ti je večná sláva a somozrejme informácie posúvam do upstreamu aby som si to nemusel udržovať sám. Slobodný svet softvéru je super.

So long.

[TM]

Omlouvám se, ale toto je neuvěřitelný žvást.
To, že neoficiálně nebo pomocí bezvýznamné distribuce, dospěju k Linuxu bez systemd, je sice pravda a je to hezké. Jenže Linux dnes není jen na domácí hraní. Nasazujeme jej na kritická místa a pochopitelně v takovém případě bývá vyžadována komerční distribuce se zajištěnou podporou. Všechny takové jsou již nakaženy a to se okecat nedá.
Mimochodem i na doma dnes dám na server raději FreeBSD. Ušetří to čas ztracený řešením neustále narůstajícího bordelu.

[Bedňa]

Keď ich používaš profesionálne, tak je veľká šanca, že je to práve Debian. Tie systemd FREE spiny sú vlastne Debian bez systemd, takže funguješ na Debiane ako hocikedy pred tým, nič sa nemení. Čo sa mení, je že nenainštaluješ balíček ktorý je závislý na systemd.

Testovanie samozrejme robím cez --dry-run a potom obťažujem autorov aby s tým niečo spravili, momentálne som sa dostal do štádia, že som si si takto vymodlikal všetky programy ktoré na systemd záviseli a používam ich. Prakticky ostalo na mne baliť len dva balíčky a to beriem ako prínos komunite, niečo za niečo.

[Ondrej Santiago Zajicek]

Ono u Debianu neni treba ani pouzivat ty spiny, staci proste odinstalovat baliky systemd, systemd-sysv a nainstalovat balik sysvinit-core a zavislosti.

[pavlix]

Mám pocit, že si tím zrovna u Debianu zbytečně odkopeš věci, které tam jsou závislé na systemd a nemusí být.

[R]

Ano, napriklad network-manager zavisi na libpam-systemd a ten zavisi na systemd. Akurat ten systemd nemusi bezat, staci, ze je nainstalovany... Takze staci nainstalovat sysvinit-core.

[pavlix]

Já to osobně do detailů nesleduju, pouze odpovídám na dotazy a požadavky u projektů, u kterých to umím, bez ohledu na to, z čeho ty požadavky vycházejí. Jsem fanda diverzity a tudíž jakoukoli snahu nabídnout alternativu vítám.

Někdo požaduje, aby daná věc fungovala, když systemd neběží, jiný požaduje, aby nebylo třeba instalovat samostné systemd, někdo aby nebylo potřeba instalovat žádné komponenty toho projektu. Já osobně moc neřeším, jestli mi ty požadavky dávají smysl, spíše se snažím dát odpověď.

A mimojiné můžu nabídnout zkušenosti z Gentoo, kde je velmi silná komunita non-systemd uživatelů, a tudíž se třeba networkmanager bez systemd stále ještě považuje za samozřejmost.

[pavlix]

Omlouvám se, ale toto je neuvěřitelný žvást.

Přesně tak. Většina lidí bere open source jen jako levnou možnost, jak se dostat k software, a když se jim řekne, že to open source není jenom o braní, tak to označí za žvást. A toto je přesně ten případ, protože jediní, co jsem napsal bylo, že pokud někomu na něčem takovém záleží, tak proto něco udělá. Jenže na takové lidi já seru, mě zajímají aktivní lidi, kteří mají, co nabídnout. :)

To, že neoficiálně nebo pomocí bezvýznamné distribuce

O žádné distribuci jsem se nezmiňoval, natož bezvýznamné.

Jenže Linux dnes není jen na domácí hraní.

Už jsem psal, že mě lidi a firmy, co vidí v open source jen levný způsob, jak se dostat k software nezajímají, pokud nepřijdou za mnou, že mě chtějí z těch ušetřených peněz štědře vyplácet? :)

Nasazujeme jej na kritická místa a pochopitelně v takovém případě bývá vyžadována komerční distribuce se zajištěnou podporou.

Je snad můj problém, na co si dokážete zajistit komerční distribuci se zajištěnou podporou?

Všechny takové jsou již nakaženy a to se okecat nedá.

Protože to absolutně nikoho v komerční sféře nezajímá nebo systemd vítají. A na trhu dostanou přesně to, za co jsou ochotni solit. Jestli jsou všechny komerční distribuce na systemd, tak jsou buď ochotni solit za systemd, nebo je obrovská díra na trhu a příležitost pro vás všechny ukázat svůj potenciál. Žijete stále ještě v době startupů, takže jistě seženete investory a s nimi i potřebnou pracovní sílu.

Mimochodem i na doma dnes dám na server raději FreeBSD.

Nevidím na tom nic špatného, naopak spolu s dalšími zajišťuješ potřebnou diverzitu.

[Mirek]

takze zase takovy typicky 'pavlix' komentar. Rekl bych, ze ty nejses tisnova linka, ne , mnohy by potreboval tisnovou linku, kdyz cte ty tvoje vyplody.

Jinak, kdyby te to nahodou zajimalo, v cem je tvuj komentar tak debilni :

A na trhu dostanou přesně to, za co jsou ochotni solit

V tomto se hosanku mylis, na trhu dostanou to, co je jim monopolista ochoten dat!

[biolog]

Monopolista ochoten dát?

Alternativní distribuce existují, můžete si je stáhnout dokonce zdarma. Dokonce můžete upravit stávající mainstreamovou distribuci, která používá systemd, a systemd z ní odstranit. Ale nemůžete po distributorech chtít, aby kvůli vám pouhým tisícům neplatících ajťáků byť jen hnuli prstem.

Mainstreamové distribuce nemají monopol, mají jen velikánský podíl na trhu. Proto se o nich říká, že jsou mainstreamové.

[pavlix]

Ano, je to typický můj komentář a stojím si za ním. Zatím nepadl ani náznak protiargumentu, takže se nemáme o čem bavit. Kdo chce, hledá důvody, kdo nechce, hledá způsoby. Nechci si ani představovat, kde bych dneska byl, kdybych veškerou energii věnoval hloupým výmluvám.

[TM]

Tak já píšu o komerčních distrech, za která se normálně platí a jsem obviněn, že chci vše zadarmo.
Bravo, mistře!

[Jendа]

A toto je přesně ten případ, protože jediní, co jsem napsal bylo, že pokud někomu na něčem takovém záleží, tak proto něco udělá.

Jenže tady nejde nic udělat, protože cena vývoje a nasazení vlastního init systému je prostě moc velká a způsobí to nekompatibilitu se zbytkem světa „až po mně přijde jiný admin“.

[kralyk z abclinuxu]

Takže něco, k čemu zákonitě dojít muselo. Bylo to jen otázkou času. A banda mlamojů bude mít, pochopitelně, omluvy a zdůvodnění
Smutné, co se z Linuxu stalo...

Už by to asi opravdu chtělo nějakou tísňovou linku pro oběti systemd. Podle diskusí to vypadá opravdu vážně.

[pavlix]

Já už pro pár lidí jako tísňová linka funguju.

[Filip Jirsák]

Takže něco, k čemu zákonitě dojít muselo. Bylo to jen otázkou času.

Nechci vám brát iluze, ale toto není první chyba v software, která byla objevena. Chyby v software jsou objevovány každý den, už od okamžiku, kdy první software vznikl, takže dávno před tím, než vzniklo systemd.

[TM]

Teď jste na to kápnul. Váš příspěvek do diskuse považuji za objev roku.

[pavlix]

+1

[Václav "Darm" Novák]

Jestli jsi stejně nejančil při každé CVE kernelu, ssl apod., jsi pokrytec. Protože třeba heartbleed nebo shellshock byly průšvihy na úplně jiné úrovni, proti kterým je tohle naprostá (a prakticky okamžitě opravená) ptákovina.

[Bedňa]

Ale v tejto diskusií už ani nejde tak o danú chybu, ale to že kdo chce má stále šancu na alternatívu a robiť to ako zstara, jeden program robí jednu vec a robí ju dobre. Teda aspoň mne to tak príde, aj ja som tu písal názory ktoré priamo s CVE nemajú súvislosť.

[Václav "Darm" Novák]

Bedňo, moje reakce byla na část threadu která se vyloženě týkala CVE.

[pavlix]

On ten zápisek není ani tak o té chybě, že? Spíš to byla jen taková příležitost se vyjádřít.

[Heron]

Tohle je argument stylu: a vy zase bijete černochy.

Jistěže existují jiné a mnohem závažnější chyby. Pravděpodobně u nich i lidi jančili mnohem víc. Ale v čem má být jako pointa? U chyb v ostatním software jsem nezažil, že by někdo oznámil chybu a někdo mu tam do diskuse napsal, že by měl také zmínit výhody. Tak, jak se stalo v diskusi pod tím tweet blogem. Takové chování z mnou sledovaného software jsem zažil jen u systemd. Všude jinde prostě chybu akceptují a opraví. Tady ne, tady je potřeba relativizovat její závažnost a psát oslavné ódy na jiné vlastnosti systemd (které nepochybně má). Ať se na mě nikdo nezlobí, ale toto mi připomíná chování sekty.

[kralyk z abclinuxu]

Tady ne, tady je potřeba relativizovat její závažnost a psát oslavné ódy na jiné vlastnosti systemd (které nepochybně má).

Hm, asi tě nějak úplně minulo to, že tyhle "ódy" a relativizace jsou pouze reakcí na ty hemzy, který se okolo té chyby okamžitě vynořily (už hned v tom úvodním blogpostu), kde se lidi snaží co nejvíc očernit systemd dosti nesmyslným způsobem. Vem v úvahu už jen titulek zprávičky - dává ti smysl? Mně teda ne.

[Heron]

Vem v úvahu už jen titulek zprávičky - dává ti smysl? Mně teda ne.

Dává. Příkaz se vleze do limitu na twitteru. Chápu to tak, že tím chtěl autor blogu zdůraznit, že se jedná o velmi krátký příkaz. Stejně jako svého času byla populární smajlíkoidní bash fork bomba :(){ :|:& };: což je ještě kratší (ale tehdy zase nebyl twitter).

[Filip Jirsák]

Tohle je argument stylu: a vy zase bijete černochy.

Ne, to je reakce na komentáře, které z té chyby dělají katastrofu, která málem vyhladila lidstvo.

U chyb v ostatním software jsem nezažil, že by někdo oznámil chybu a někdo mu tam do diskuse napsal, že by měl také zmínit výhody. Tak, jak se stalo v diskusi pod tím tweet blogem.

Ten tweet blog není oznámení chyby. To je špatně skrývaný hate na systemd, ve kterém je jen tak mimochodem zmíněna chyba.

Všude jinde prostě chybu akceptují a opraví.

Tady také chybu akceptovali a opravili.

Tady ne, tady je potřeba relativizovat její závažnost

Relativizaci závažnosti jsem nezaznamenal, zato jsem zaznamenal spoustu případů, kdy byla závažnost chyby neúměrně nadsazována – je logické, že se objeví reakce, které závažnost chyby zasazují do správných měřítek.

Ať se na mě nikdo nezlobí, ale toto mi připomíná chování sekty.

Sekta bývá organizovaná. Systemd-haters jsou chaotické útoky – spíš to připomíná řádění fotbalových chuligánů nebo nějakých výtržníků při různých antisystémových demonstracích. Začne to pár ultras, pak se přidají ti, kteří mají taky chuť si bouchnout, normálně by se neodvážili ale teď vidí, že se to může, a pak se přidá i spousta „slušných lidí“, když to dělají všichni okolo – a dodatečně se diví, jak se něčeho takového mohli zúčastnit. A vedle toho pak stojí nešťastně ti, kteří chtěli opravdu slušně demonstrovat proti globalizaci a nechtěli rozbíjet výlohy.

[Filip Jirsák]

Děkuji. Ale nic to není proti vašemu objevu tisíciletí, že zákonitě muselo dojít k tomu, že se v softwaru najde chyba.

Takže něco, k čemu zákonitě dojít muselo. Bylo to jen otázkou času.

Nebo jste tím „něco“ myslel něco jiného, než že v softwaru byla nalezena běžná chyba? Myslel jste snad, že je tahle chyba něčím zvláštní, že je snad dokonce první svého druhu? Povídejte, přehánějte, jsem zvědavý, co se za tím vaším „něco“ skrývá.

[TM]

Tak raději polopaticky pro Aspergy, kteří chápou vše doslova:
Zákonitě došlo k tomu, že se objevila vážná chyba ve zbytečně komplexním bastlu, který běží v unixovém OS s PID 1(případně je s tím úzce propojený). Jak známo, v takovém OS má tento proces speciální význam.
Měl by být, logicky, co nejjednodušší, jak tomu bývalo v minulosti. Pravděpodobnost takového trapného problému(v duchu tradic Microsoftu, Pejska a Kočičky a dalších...) by pak dramaticky poklesla.
Ale nedělám si iluze, že moje snaha padne na úrodnou půdu.

[Václav "Darm" Novák]

Pokud takovou prkotinu bereš jako vážnou chybu, pak tvoje šílení u opravdových vážných chyb musí být něco úžasného.

[kralyk z abclinuxu]

Jak známo, v takovém OS má tento proces speciální význam.

Je to v zásadě úplně normální user-space proces. Jediná specialita je, že když padne na hubu, tak kernel zpanikuje, což se ale ani v případě této chyby neděje, afaik systemd má proti tomu opatření. Takže úplně nevidim, v čem má ta speciálnost tohoto procesu význam, zejména v kontextu téhle chyby.

Měl by být, logicky, co nejjednodušší, jak tomu bývalo v minulosti.

Zřejmě mluvíš o sysvinitu. Ten byl skoro celý napsaný v bashi. Viděl jsi někdy zdrojáky bashe? Opravdu ti to připadá jednoduché? V bashi se našly mnohem závažnější bezpečnostní chyby.

[TM]

Odpovím na oba najednou:
Pokud jako prostý uživatel z konsole(mohu si ale přístup k CLI za dobrých podmínek vynutit i jinak) jednoduchým způsobem naruším chod celého systému a je to považováno za "prkotinu", pak tady něco sakra smrdí.Ale je to přesně v duchu bastlířského přístupu propagátorů Čapkova pejska s kočičkou, nejsem překvapen...
Existují i jiné systémy než překonaný Sys5 init, ale i ten s bashem dohromady je z pohledu toho problému proti Poeteringovu mentálnímu zvratku zlatý.

[Václav "Darm" Novák]

Pokud je možné na systému vynutit přístup k CLI útočníkem jinak, mám potenciálně průšvih tak jako tak. Ta chyba nevede k žádnému úniku dat, bezpečnostnímu problému, nic. Je to jen velmi silně teoretický DOS, nebezpečností naprosto nesrovnatelný s jinými CVE poslední doby. To už mohu pomalu považovat za kritickou DOS chybu fakt, že když si někdo stoupne k mému serveru, může ho vypnout.

[kralyk z abclinuxu]

Pokud jako prostý uživatel z konsole(mohu si ale přístup k CLI za dobrých podmínek vynutit i jinak) jednoduchým způsobem naruším chod celého systému a je to považováno za "prkotinu"

To je jak do dubu. Jsaně, že to je chyba a jasně, že to je i bezpečnostní chyba - CVE záznam tomu právem náleží. Prkotina to je ve srovnání s mnoha jinými CVE, které se v poslední době našly v mnoha jiných programech/knihovnách, protože to není nijak moc zneužitelné. Nezaslouží si to tohle haló.

Existují i jiné systémy než překonaný Sys5 init, ale i ten s bashem dohromady je z pohledu toho problému proti Poeteringovu mentálnímu zvratku zlatý.

Ano, to je velice technický argument.

Ostatní inity, sice existují, ale neprošly by ostrou kritikou systemd-haterů, protože nejsou v bashi, takže se nedají ad-hoc opravovat.

Jinak třeba upstart má taky nějaké to CVE. Ale to asi nemá smysl zmiňovat, protože prostě systemd zřejmě může za všechno zlo na planetě...

[mirec]

Sysvinit je napísaný v C. Jeho úlohou je starať sa o pár blbostí ako inittab, runlevely, procesy, shutdown a to je asi tak všetko. Že pod nim niektoré distribúcie majú zvyčajne tonu bashovských skriptov ešte nerobí zo sysvinitu bash skript.

[kralyk z abclinuxu]

Přesně takový alibismus jsem čekal, to samozřejmě vím, že sysvinit je tehcnicky vzato jen malý C program. Že pod tím máš navěšeno v praxi tunu skriptů je snad samozřejmé.

[pavlix]

Můžeš na to úplně stejně navěsit programy v C nebo co si vymyslíš, takže to, co nazýváš alibismem je pouhá náprava neznalosti.

[Ondrej Santiago Zajicek]

To neni alibismus, ja treba na svych routerech mam vlastni boot skripty pod sysvinitem. Distribucni skripty jsou proste ekvivalent defaultniho konfiguraku, ktery uzivatel muze ale nemusi menit.

[kralyk z abclinuxu]

Odpověď i pro pavlixe: Ano, technicky vzato máte pravdu, můžeš si na to navěsit co chceš, ale pointa v kontextu diskuse byla úplně jinde. TM si stěžoval, že PID 1 musí být naprosto minimální, protože bezpečnost a stabilita. Ten alibismus je v tom, že si na něj stejně vždykcy něco navěsíš. Je mi celkem jedno, jestli si na něj navěsíš distribuční nebo vlastní skripty, nebo kombinaci obojího, podstatné je, pokud je to v bashi, tak je pod tím celá komplexnost bashe i s bezpečnostními riziky. O vlastním kódu v C nemluvě.

[pavlix]

Ano, technicky vzato máte pravdu, můžeš si na to navěsit co chceš

Ano a na tom stály vedle klasického rc.d i projekty jako upstart, openrc a mnoho dalších.

TM si stěžoval, že PID 1 musí být naprosto minimální, protože bezpečnost a stabilita.

Na což je sysvinit docela dobrou odpovědí.

Ten alibismus je v tom, že si na něj stejně vždykcy něco navěsíš.

To není alibismus, ale standardní metoda, jak držet minimální stabilní init, který se nemusí starat o nic jiného než své základní úkoly. Navíc je naprosto super, že můžeš nezávisle měnit ty vrstvy nad tím, nebo naopak měnit samotný init, pokud poskytne stejné rozhraní. Kdysi dávno byl tohle jeden z hlavních technických argumentů pro přechod na Linux.

[kralyk z abclinuxu]

To není alibismus, ale standardní metoda, jak držet minimální stabilní init, který se nemusí starat o nic jiného než své základní úkoly.

Vůbec nevidim, kde má tohle nějaký pozitivní efekt. Chápal bych to, pokud by cílem bylo zabránit panicu, tohle ale zjevně systemd už nějak řeší, protože k panicu nedojde ani při crashi v pid 1.

K čemu je minimalistický /sbin/init, když pak pod něj navěsíš X tisíc řádek nějakýho kódu, kterej běží pod stejným oprávněním a může způsobit ty samý problémy?

Přijde mi, že ten rozdíl je čistě sémantický...

[pavlix]

Mimojiné k tomu, abys na něj právě mohl navěsit libovolně malou či velkou hierarchii služeb. Ty služby můžou a nemusí mít stejná oprávnění. A můžou být jednotlivě nahraditelné což je pro další vývoj open source podle mého názoru obrovsky výhodné.

Ty v tom výhodu nevidíš a dáváš přednost megaprojektu se silným vlivem. Já ti to neberu, ale nevidím důvod, proč bych měl jásat taky.

[kralyk z abclinuxu]

Mimojiné k tomu, abys na něj právě mohl navěsit libovolně malou či velkou hierarchii služeb.

Já neměl na mysli služby, ale vlastní kód init systému. Silně pochybuju, že /sbin/init bude v obecném případě stačit.

Ty v tom výhodu nevidíš a dáváš přednost megaprojektu se silným vlivem.

Nedávám. Poetteringa nemusim, veškerý jeho SW mimo jádro systemd IMHO není dobrý. Fandil jsem iniciativě uselessd, ale bohužel to odumřelo.

V diskusi argumentuju pro systemd proto, že IMHO ta základní část není problém, na svých strojích vidím určitě v oblasti initu po přechodu na systemd posun k lepšímu. Dále mi přijde, že kritika systemd má v 80% hodně daleko do čehokoli alespoň trochu konstruktivního, pokud to rovnou nejsou emocionální výlevy. Když se podíváš na názory systemd-haterů, zjistíš, že jsou dost nekoznistentní, tenhle chce tradiční init z distra/OS X, tenhle z distra/OS Y, tenhle by všade nasadil OpenRC, tomuhle je to úplně jedno, hlavně když v CREDITS nebude Poettering, atd.

Nebejt systemd, nevěřim, že by někdo z nich vyvinul nějakou iniciativu pro lepší init, akorát by nechali maintainery každé distribuce oddřít práci s vyřešením initu po svém.

[Heron]

Když se podíváš na názory systemd-haterů, zjistíš, že jsou dost nekoznistentní, tenhle chce tradiční init z distra/OS X, tenhle z distra/OS Y, tenhle by všade nasadil OpenRC, tomuhle je to úplně jedno, hlavně když v CREDITS nebude Poettering, atd.

Tohle byl "argument" už za komoušů (a možná ještě dřív) kdy jedna skupina (obvykle vládnoucí) uměle označila protistranu více skupin či dokonce nezávislé jednotlivce jako jednu skupinu vnitřně rozhádanou a nejednotnou s tím, že až se teda oni dohodnou, tak je budou poslouchat. Vše pochopitelně s cílem vládnout dál aniž by do toho někdo jiný kecal.

Nevím přesně, kdo je systemd-hater, ale to, že různí lidé chtějí různé věci a admini různých systémů mají různé preference a požadavky na chování a správu systému mi přijde úplně normální a rozhodně bych to neoznačoval slovem nekonzistentní. Naopak vždy jsem považoval za velké plus linuxu to, že si to každý může nastavit a provozovat jak chce a že systém mu neháže příliš klacků pod nohy. Minimalistický init, který dělá co má (tj starat se o zombíky a o spawnování zvolených procesů) hází klacky pod nohy zcela minimálně.

[Filip Jirsák]

Rozdíl je v tom, jestli různí lidé chtějí různé věci, nebo jestli různí lidé chtějí různé věci a společně při tom nadávají na systemd, podporují se navzájem – ovšem používají protichůdné argumenty, a kdyby se jim společnými silami podařilo systemd opravdu odstranit, budou na tom v souhrnu ještě mnohem hůř, než se systemd.

každý může nastavit a provozovat jak chce a že systém mu neháže příliš klacků pod nohy. Minimalistický init, který dělá co má (tj starat se o zombíky a o spawnování zvolených procesů) hází klacky pod nohy zcela minimálně.

Někdo zase od systému vyžaduje, aby mu pomáhal – neházení klacků pod nohy ho ani zdaleka neuspokojí. Výhoda linuxu je ale v tom, že si to každý může nastavit a provozovat jak chce, bez ohledu na to, co vy považujete nebo nepovažujete za „dělá co má“.

[kralyk z abclinuxu]

Tohle byl "argument" už za komoušů (a možná ještě dřív) kdy jedna skupina (obvykle vládnoucí) uměle označila protistranu více skupin či dokonce nezávislé jednotlivce jako jednu skupinu vnitřně rozhádanou a nejednotnou s tím, že až se teda oni dohodnou, tak je budou poslouchat. Vše pochopitelně s cílem vládnout dál aniž by do toho někdo jiný kecal.

Nechápu, proč je tohle vyčítáno systemd nebo lidem, kterým systemd vyhovuje. Proč je za to "zlo" označován systemd nebo někdo, kdo ho spokojeně používá, když přitom za tu "nadvládu" jsou zodpovědní tvůrci distribucí?

Můžeš mě přirovnávat ke komunistům jak chceš, ale mě nějaké vládnutí absolutně nezajímá. Mně zajímá mít možnost nainstalovat si efektivně fungující init, který je víc než pouze tak-nějak fungující klubko init skriptů vyprodukované přetíženým maintainerem. A je mi úplně jedno, jestli ten init bude na každém distru, jde mi o to, aby byl k dispozici v tom mém.

Před tím než přišlo systemd jsem se dokonce vážně zabýval nápadem init napsat, myslímže už jsem i měl nějakou kostru projektu. Nicméně pak mé distro nasadilo systemd a tím byl problém vyřešen.

Minimalistický init, který dělá co má (tj starat se o zombíky a o spawnování zvolených procesů) hází klacky pod nohy zcela minimálně.

No ano. Je to takový styl "kdo nic nedělá, nic nezkazí". Sice to v podstatě nic neumí, ale alespoň s tím nejsou problémy. A když s tím jsou problémy, tak se řekne, že jsou někde jinde (máte špatně napsaný init skript).

[Heron]

Můžeš mě přirovnávat ke komunistům jak chceš

Já jsem tě v žádném případě nepřirovnával ke komunistům. Jen jsi použil ten argument, který jsem popsal (uměle definovat nějakou skupinu lidí, kteří jednu ucelenou skupinu ani netvoří, a potom vynášet soudy o tom, jak se ta skupina chová nekonzistentně). Ten příměr ke komunistům byl proto, že jsem tento způsob manipulace slyšel od několika disidentů. Pravděpodobně se tato manipulace používala hodně dlouho před tím.

[kralyk z abclinuxu]

To není manipulace, ze dvou důvodů:

Zaprvé, já jsem tu skupinu uměle nevytvořil, ta skupina se vytvoří víceméně sama pod jakoukoli zprávičkou obsahující string "systemd".

Zadruhé, IMHO ten požadavek na to, aby se lidé dohodli, je skutečný a nevychází od nějaké "zlé vlády", ale je to praktický důsledek a byl tu už dávno před systemd. Mít možnost spolehnout se na nějaké jednotné rozhraní k základním prvkům systému je obrovská výhoda pro tvůrce software, ať už ke všeobecnému použití nebo nějakých vlastních řešení, zjednodušuje to deploy, atd. Koneckonců, projekt freedesktop.org AFAIK vznikl přesně kvůli tomu a kvůli tomu také vznikaly projekty jako DCOP → D-Bus, HAL → udev a podobně. Systemd je toho v podsatě pouze důsledek.

Samozřejmě můžeme debatovat o tom, jestli systemd je/není správná odpověď. I já bych byl pro, aby v systemd bylo mnoho věcí bylo jinak (větší modulárnost, veřejná API, méně NIH syndromu). Ale ta myšlenka, že si každý druhý admin vytvoří vlastní init systém mi nepřijde úplně reálná.

Přijde mi, že mnozí odpůrci systemd tohle zcela ignorují, být po jejich, tak bychom stále ještě byli v dobách, kdy desktop environment musel v podstatě hádat, jakým magickým příkazem se na té či oné distribuci vypíná počítač.

[Borec]

kdy desktop environment

ja si myslím, že to je to správné slovíčko - desktop

Linux není desktopový systém a já dodnes nevím jestli to neví jen LP nebo celý RH

[AsciiWolf]

Linux je mimo jiné i desktopový systém.

[Heron]

ta skupina se vytvoří víceméně sama pod jakoukoli zprávičkou obsahující string "systemd"

Nevšiml jsem si. Když budu mít 3 lidi odmítající stavbu nějaké silnice, tak to není skupina. Protože jeden ji bude odmítat z důvodů narušení krajiny, druhů z důvodů že mu vede pod okny a vadí mu hluk a třetí to považuje za zbytečné, protože preferuje železnici před silniční dopravou. Jediné, co ti lidé mají společného je, že nechtějí tu silnici ale tím to končí.

Mít možnost spolehnout se na nějaké jednotné rozhraní k základním prvkům systému je obrovská výhoda pro tvůrce software, ať už ke všeobecnému použití nebo nějakých vlastních řešení, zjednodušuje to deploy, atd.

Otázkou k diskusi je to, co je tou základní skupinou prvků. Já jsem za to vždy považoval POSIX + VFS (vlastnosti fs nejsou nikde standardizovány, ale ten standard de facto tvoří VFS).

Koneckonců, projekt freedesktop.org AFAIK vznikl přesně kvůli tomu a kvůli tomu také vznikaly projekty jako DCOP → D-Bus, HAL → udev a podobně.

No právě (chápat jako: ani jeden z těch projektů nepovažuji za bůh ví co dobrého).

[kralyk z abclinuxu]

Jediné, co ti lidé mají společného je, že nechtějí tu silnici ale tím to končí.

Tomu nevim, jestli rozumim, ty tedy opravdu chceš pouze /sbin/init z SysV a cokoli nad tím si dopíšeš sám? Nebo chceš i nějaké skripty nad tím? Pokud ano, kdo by měl být tím, kdo je bude psát a spravovat?

[Heron]

Já zase asi úplně nerozumím tobě. Tohle už je druhý ilustrativní příklad, který bereš v podstatě doslova (nechtějí silnici -> nechtějí init). Ten příklad se stále týkal argumentace ohledně skupiny jedinců, které nic nespojuje.

Jinak otázka, jaký init systém bych chtěl se asi nedá odpovědět v jednom komentáři. Vycházím z praxe admina stovek serverů (zejména web+db, já se hlavně hrabu v datech, takže db+fs, raidy apod.).

Mimochodem nedávno jsem narazil na krásnou chuťovku. Aneb změníme způsob sestavování raidu, přece se nic nemůže stát, že.

O tom, jak krásně funguje systemd a mountování fs jsem už referoval v diskusi na rootu.

Mno ale zpět k diskusi.

Z mojí praxe plyne, že zdravé služby nepadají (Filip Jirsák to určitě opět rád okomentuje). Jsem zvyklý na to, že pokud má stroj uptime 700dnů*, tak služby na něm běžící mají též uptime 700dnů. Z tohoto titulu fakticky rc systém nepotřebuju, protože spouštění těch služeb by se dalo naházet do nějakého skriptu typu rc.d, který se spustí jen jednou při startu stroje.

Z tohoto pohledu nemám nic proti původním sysvinit+rcv skriptům v bashi, protože se při bootu ta mašinerie bash skriptů spustí jen jednou a potom to měsíce běží. Navíc, jak psal Jenda, debugování je triviální a vzhledem k tomu, že v bash admin stejně pracuje, tak pro něj obsah těch skriptů nepředstavuje žádnou supernovinku (nebo by nemělo představovat) a když bude potřeba, tak tam něco opraví a jede se dál.

Stejně tak nepotřebuju nic jako systemctl status service, protože to stejně vůbec nic o stavu té služby neřekne. Je potřeba mít řádný monitoring, který konktroluje to, co ta služba má dělat. Už jsem tady zmínil restart on failure, zažil jsem služby, které sice jely (proces běžel), ale neplnily svou funkci. Systemd restart on failure pochopitelně nezafungoval, protože z jeho pohledu vše jelo ok.

A takto by se dalo pokračovat dále. Prostě mě přijde, že vývojáři systemd nemají základ v praxi. Protože spousta nápadů jsou sice na první pohled zajímavé a zdánlivě užitečné, ale ve skutečnosti neuvěřitelně naivní. Ten restart on failure je dobrý příklad, aby toto fungovalo, tak by systemd musel umět monitorovat (nebo se umět napojit na existující monitoring) to, co ta služba má skutečně dělat. Protože kupodivu httpd neběží proto, aby tam byl ten proces v nějaké cgroupě. Ale běží především proto, že když se na něj připojí nějaký klient tak dostane obsah daného webu. A to je mnohem silnější požadavek, než jen běžící proces.

Takže ve výsledku si to stejně každý admin musí zařídit podle sebe (a tím nutně neříkám napsat od nuly), protože nikdo jiný jeho systém nezná, neví jak je navržen a neví, co ten systém má dělat.

A jak psal Jenda (dneska mi bere slova z úst), tak jestli si mám vybrat, mezi systémem, se kterým mám neustále potíže** a systémem, který sice papírově toho umí méně, ale funguje bez problémů, tak hádej, který si vyberu.

*) Odhlédněme od toho, že ten stroj by se měl pravidelně updatovat a rebootovat do nového jádra.

**) A to nepíšu proto, že bych byl systemd hater. Mám pocit, že na cokoliv sáhnu, tam najdu chybu. A to je ani aktivně nehledám, naposledy jsem jen převáděl úlohu z cronu na oneshot.service a .timer a během 10 minut jsem narazil na chybu, že systemd nezaznamenává unitu do journalu. A teďka budu na systemd mimořádně hodný: fajn, ok, akceptujme, že tam ta chyba je a prostě trvá dlouho ji vyřešit. Ale sakra, proč se ve všech tutoriálech pro práci s journalctl uvádí --unit? Když se 4 roky ví, že to nefunguje? To si ty hatery chce SD sám vyrábět? Jak asi zareaguje neutrální admin, když si vyzkouší nový úžasný opěvovaný init systém a během 10 minut narazí na chybu?

[Heron]

Oprava: rc.d má být rc.local

[kralyk z abclinuxu]

Já zase asi úplně nerozumím tobě. Tohle už je druhý ilustrativní příklad, který bereš v podstatě doslova (nechtějí silnici -> nechtějí init). Ten příklad se stále týkal argumentace ohledně skupiny jedinců, které nic nespojuje.

Hm tož já nevim, jak jsem to měl brát, možná spíš tak, že chtějí nějakou silnici (cestu?), ale jinou? Možná nechme přirovnání přirovnáníma...

Z mojí praxe plyne, že zdravé služby nepadají (Filip Jirsák to určitě opět rád okomentuje). Jsem zvyklý na to, že pokud má stroj uptime 700dnů*, tak služby na něm běžící mají též uptime 700dnů. Z tohoto titulu fakticky rc systém nepotřebuju, protože spouštění těch služeb by se dalo naházet do nějakého skriptu typu rc.d, který se spustí jen jednou při startu stroje.

Ok, pro takový use case chápu minimalistický init. Je pravda, že spousta vlastností systemd dává smysl spíše na deskoptu. Respektive na pracovní stanici - což je pozice, ze které to vidím já. Jako vývojář potřebuju dost často testovat různé věci, což zahrnuje spouštět/vypínat/měnit různé služby. I ten on-demand může být užitečný, ačkoli bych to narozdíl od Poetteringa nedával jako default a rozhodně ne třeba na ssh.

Na druhou stranu mě napadá - ty služby nemají mezi sebou závislosti?

Ten restart on failure je dobrý příklad, aby toto fungovalo, tak by systemd musel umět monitorovat (nebo se umět napojit na existující monitoring) to, co ta služba má skutečně dělat.

Takhle to AFAIK nikdy nebylo myšleno, je to prostě jen kvůli tomu, když proces služby padne na hubu. V tomhle není systemd nijak specielní, to dělá AFIAK většina ostatních systémů včetně tradičních init skriptů...

**) A to nepíšu proto, že bych byl systemd hater. Mám pocit, že na cokoliv sáhnu, tam najdu chybu. A to je ani aktivně nehledám, naposledy jsem jen převáděl úlohu z cronu na oneshot.service a .timer a během 10 minut jsem narazil na chybu, že systemd nezaznamenává unitu do journalu.

Tak já jsem journald-hater, takže tomuhle rozumim...

[Heron]

Na druhou stranu mě napadá - ty služby nemají mezi sebou závislosti?

Nic, co by se nedalo vyřešit vhodným pořadím, přičemž i to je dost volné.

Systemd zavedlo jako závislost všechno, včetně třeba fs. Já si prostě myslím, že fs je nutná podmínka pro jakoukoliv práci, o tom se nemá smysl bavit (s tím souvisejí bloková nařízení nesoucí ty fs apod.). Takže někde na začátku rc skriptu je prostě mountování fs dle fstab.

Další závislost je na síti, ale tam stačí aby byl up lo. Další interfaces mohou naběhnout kdykoliv později. Přidávání ip za běhu je běžná záležitost, ani jsem nikdy nezaznamenal problém s ip l set down dev iface za běhu. Všechny (námi) používané síťové služby prostě v pohodě běžely dál i po zhození nahození iface, změně jména atd. Pokud je služba nastavená na bind na konkrétní iface, tak je jistě potřeba toto řešit (systemd to též nijak neřeší, nekontroluje konfig každého programu).

Závislost typu služba na službě. Kromě lokálního cachujícího dns resolveru (i tady to záleží program od programu, třeba nginx má při startu problém, pokud nelze přeložit host uvedený v proxy pass), mě nic dalšího nenapadá.

A to je vlastně vše.

Pokud se bavíme o aplikacích typu LAMP (včetně libovolné kombinace webserveru, databáze a jazyka (a OS ), tak ta musí být samozřejmě připravená na to, že nebude dostupná db a další síťové zdroje dat. Ale to beru jako samozřejmost.

Jako vývojář potřebuju dost často testovat různé věci, což zahrnuje spouštět/vypínat/měnit různé služby.

Chápu. Je z tohoto pohledu nějaký významný rozdíl mezi změnou unity a změnou třeba su -c "program -d" user? A spouštění pomocí ./sluzba.sh a vypnutí přes kill?

V tomhle není systemd nijak specielní, to dělá AFIAK většina ostatních systémů včetně tradičních init skriptů...

Tradiční sysv skripty (třeba v CentOS5) toto rozhodně nedělají.

[Jendа]

Já si prostě myslím, že fs je nutná podmínka pro jakoukoliv práci, o tom se nemá smysl bavit (s tím souvisejí bloková nařízení nesoucí ty fs apod.). Takže někde na začátku rc skriptu je prostě mountování fs dle fstab.

No to právě ne, někdy je třeba zase síť podmínka pro fstab, že.

Další závislost je na síti, ale tam stačí aby byl up lo.

Nestačí, například pokud máš v konfiguráku služby, že má udělat bind na IP f00::b47, tak v okamžik startu musí interface s touto IP existovat, jinak se bind nepovede.

Ale souhlasím, že paralelní dependency systém je overkill. Osobně by mi fakt stačilo to pořadí a sériové spouštění. Nevím, jak často bootujete vy, ale já desktop když vytuhne (cca 1 za měsíc) a servery tak jednou za rok nebo když je vážný bezpečnostní problém v jádře.

[Heron]

No to právě ne, někdy je třeba zase síť podmínka pro fstab, že.

Ano, tohle se řeší (v klasických sysv skriptech) tak, že se fstab projde ještě jednou po nahození sítě a nahodí se síťové fs.

Nestačí, například pokud máš v konfiguráku služby, že má udělat bind na IP f00::b47, tak v okamžik startu musí interface s touto IP existovat, jinak se bind nepovede.

Jistě, problematiku bind na inface apod. jsem zmiňoval.

Nevím, jak často bootujete vy, ale já desktop když vytuhne (cca 1 za měsíc) a servery tak jednou za rok nebo když je vážný bezpečnostní problém v jádře.

Desktop každý den. Mám jej v místnosti, kde spím, takže jej nemohu mít zapnutý nonstop (zas tak tichý není).

[Jendа]

Já uspávám do paměti.

[little.owl]

Ano, tohle se řeší (v klasických sysv skriptech) tak, že se fstab projde ještě jednou po nahození sítě a nahodí se síťové fs.

A race conditions v podobnych skriptech vyresime sleepy a ruznymi pochybnymi locky.

[Heron]

Tohle by bylo vtipné kdyby na tom nebyl sd mnohem hůř co do funkčnosti. Aneb, nejdřív je dobré si zamést před vlastním prahem.

Ano, v rc.d skriptech bylo k vidění mnoho věcí, které by tam člověk nejraději neviděl. Ale v praxi to fungovalo. A tohle je spíš vizitka těch programů takto spouštěných.

[little.owl]

Ale v praxi to fungovalo. A tohle je spíš vizitka těch programů takto spouštěných.

Ne vzdy. Jako priklad treba lvm2 + crypto na laptopu, a vetsinu takovych veci resi systemd celkem spolehlive a deterministicky.

[Ota]

ale Heron prece nahore pise, ze on nikdy takovou situaci nezaznamenal. Ja mimochodem take ne.

[little.owl]

Pokud si vystacite jen s timto, tak chapu, ze systemd pro vas neni prinos, ale na stranu druhou nemam pocit, ze by vas limitoval. Sprava a provoz serveru se bude komoditizovat, plno veci automatizovat, pak veci jak deklaritivni unity generovane on-fly, systemd generatory, sandboxing ci monitoring maji smysl, uz jen protoze standardizuji prostredi. Tim nerikam, ze nebudou potreba specializovana reseni, stejne jako lide co vidi i za systemd a kterych bude casem mene a mene.

[Heron]

ale na stranu druhou nemam pocit, ze by vas limitoval

Limituje mě pouze svými chybami. Z produkčního světa prostě nejsem zvyklý na to, že je v něčem 4 roky chyba (třeba korupce journald logů) a nikdo to neřeší.

Od začátku používání linuxu (15-17 let nazpět) jsem zvyklý na to, že programy prostě fungují ve své funkci, už jen proto, že tu funkci typicky potřeboval autor toho programu (a kdyby to nefungovalo, tak by mu to bylo k ničemu). Nemusí mít super doladěné uživatelské rozhraní, nemusí být naleštěné jako komerční soft (což vyloženě nesnáším), ale zkrátka musí fungovat a typicky fungují.

Chování vývojářů systemd je mi zcela cizí (mírně řečeno). Arogantně se rozbíjí něco, co fungovalo (a ne, není to jen o tom, že se někdo nechce učit něco nového - tato urážka se rychle vžila a je nadužívána), myslím, že u linuxáků je chuť učit se nové věci nadprůměrná. Vývojáři sd by se měli zamyslet, proč ta věc funguje tak jak funguje a jestli je opravdu nutné to měnit. Nemám nic proti změnám, pokud jsou přínosné. Ale ta změna musí být řádně vysvětlena a musí být uveden postup, jak nahradit staré řešení novým. Příkladem může být třeba KillUserProcess=yes. Nevím, zda jsem to diskutoval s tebou. Mě se to zrovna hodilo do krámu, protože jsem řešil, jak elegantně spouštět tmux a nechat běžet na pozadí. Bohužel, SD přišel s KillUP, ale nedokumentoval, jak nahradit starý způsob, o kterém prostě věděli, že jej rozbijí. Ano, přišel jsem na linger + systemctl --user, napsal jsem si tmux.service. Ale na takovéto chování takto důležitého projektu prostě nejsem zvyklý. Mnohem méně významné projekty považují za nutné svým uživatelům vysvětlit proč, jak a co.

Tohle je můj největší problém vůči sd.

Systemd používám (logicky, jinak bych v něm nenacházel chyby), nspawn používám denně. Nejsem hater (jestli jím tedy jsem) z přesvědčení, ale ze zkušeností.

[kralyk z abclinuxu]

Chápu. Je z tohoto pohledu nějaký významný rozdíl mezi změnou unity a změnou třeba su -c "program -d" user? A spouštění pomocí ./sluzba.sh a vypnutí přes kill?

Já občas i takový skripty používám na nějakej třeba dočasnej hack a podobně, ale ve chvíli, kdy to je trvalejší věc, vždy se na to snažim použít init (ie. systemd v mém případě), protože konfigurace je v systému, ne někde ve skriptu, který další den zapomenu, kde mám, nemusím řešit PIDy, nohup, logy a podobně...

[Jendа]

Z tohoto titulu fakticky rc systém nepotřebuju, protože spouštění těch služeb by se dalo naházet do nějakého skriptu typu rc.d, který se spustí jen jednou při startu stroje.

Upřímně řečeno sám doteď nechápu, proč init systém není nikde udělaný takto. Mně by to vlastně stačilo i na desktopu - nebo co ostatní s počítači dělají, že potřebují něco víc?

Mimochodem nedávno jsem narazil na krásnou chuťovku. Aneb změníme způsob sestavování raidu, přece se nic nemůže stát, že.

Když je to / pole, tak by ho určitě sestavit měl, abych se na ten stroj dostal. Ale na druhou stranu bych byl rád, kdyby nesestavoval (resp. sestavil, ale nemountoval rw, aby to zůstalo v auto-read-only) degradované datové - disk může být v pořádku a může se nenajít z nějakého jiného důvodu a když ho sestaví a zapíše na něj, tak po opravě tohoto důvodu budu muset přežít celý rebuild (nevím jestli tohle odchytí bitmapa, pokud tam je), během kterého typicky pole už nemůže tolerovat další výpadky (je-li to RAID5, 1 nebo 10).

[pavlix]

Upřímně řečeno sám doteď nechápu, proč init systém není nikde udělaný takto.

FreeBSD? Když jsem ho viděl naposledy, tak se v jednom konfiguráku řeklo, které služby poběží a které ne a tak přesně FreeBSD nabootovalo.

[Bedňa]

Z tohoto titulu fakticky rc systém nepotřebuju, protože spouštění těch služeb by se dalo naházet do nějakého skriptu typu rc.d, který se spustí jen jednou při startu stroje.

Upřímně řečeno sám doteď nechápu, proč init systém není nikde udělaný takto. Mně by to vlastně stačilo i na desktopu - nebo co ostatní s počítači dělají, že potřebují něco víc?

Kedysi som narazil na distro Linuxu ktoré používa ScriptInit, alebo tak nejak sa to volá, ak by som záujem môžem ho pohľadať.

[AsciiWolf]

+1

[pavlix]

+1

Ale mýtus o sysvinitu a bashi je kupodivu docela rozšířený.

[Filip Jirsák]

Porovnejte si to s tím, co je úlohou systemd (toho jednoho procesu s PID 1, ne všech komponent projektu).

[little.owl]

Staci se podivat na stav init systemu pred systemd. Sice muzete argumentovat, ze to slo udelat lepe, ale to byla jen teorie. Souhlasim s Kralykem.

[Václav "Darm" Novák]

Editace init skriptů byla vždycky žůžo :)

Napsat si několik systemd units pro můj server mi na stranu druhou zabralo pár minut.

[kralyk z abclinuxu]

Asi tak. Potřeboval jsem nedávno nasadit démona (vlastní kód) na krabičku s Raspberry Pi uvnitř. Staičlo napsat systemd unitu na několika málo řádcích a funguje to zcela bez problémů. Ta věc je ready za několika málo sekund po zapnutí napájení. Chtěl bych to vidět se sysvinit.

[mirec]

cat /etc/init.d/dhcpcd
#!/sbin/runscript
# Copyright 2007-2008 Roy Marples <roy@marples.name>
# All rights reserved. Released under the 2-clause BSD license.

command=/sbin/dhcpcd
pidfile=/var/run/dhcpcd.pid
command_args=-q
name="DHCP Client Daemon"

depend()
{
	provide net
	need localmount
	use logger network
	after bootmisc modules
	before dns
}

[little.owl]

Aaaa, OpenRC. Tak jsem se schvalne podival, jestli teto pet let stary bug byl konecne uzavren, a ono stale ne!

[Hans1024]

kdyz uz se tady ukajime nad jednoduchosti

$ cat /etc/rc.d/ntpd 
#!/bin/sh
#
# $OpenBSD: ntpd,v 1.3 2016/02/02 17:51:11 sthen Exp $

daemon="/usr/sbin/ntpd"

. /etc/rc.d/rc.subr

rc_reload=NO

rc_cmd $1

[TM]

Pššt, o tom tady musíte jen šeptat. To je Unix.

[Václav "Darm" Novák]

Nějak jsem si nevšiml že Solaris, z jehož SMF systemd vychází, není Unix :)

[TM]

Ale no tak. Srovnávat to se systemd, to je velmi neslušné.

[kralyk z abclinuxu]

No, mně teda SMF rozhodně nepřipadá jednodušší než systemd...

[kralyk z abclinuxu]

No je to velice jednoduché, s tím, že v tom rc.subr je 2k řádek shellového humusu :-/

[pavlix]

A proto je lepší místo toho použít 200k řádek céčkového humusu. :D

[kralyk z abclinuxu]

...protože za tím bash scriptem vůbec nejsou kvatna céčkového humusu, že. Achjo.

[Hans1024]

Nemyslim si, ze ten script nekdo spousti bashem.

[pavlix]

Aspoň sám vidíš, jak je ten argument od začátku mimo mísu. Pro každou stranu můžeme vymyslet dalších sto pseudoargumentů. Já osobně vím proč se mi open source líbí a jaký open source se mi líbí a jak to má fungovat. Je naprosto zjevné, že to systemd nesplňuje.

Před pěti lety jsme řešili stejné téma a hromada lidí tvrdila, že to jsou jenom počáteční mouchy, které se vychytají. Nevychytaly, naopak se situace drasticky zhoršila, komunita systemd se drasticky zhoršila a konflikt se přenesl daleko víc do osobní roviny, kdy největší celebrita systemd mediálně útočí na největší celebritu linuxu a na to se nabalují další pseudoproblémy dalších lidí. Celé se to zvrhlo do takové míry, že je výsledek špatný jak po technické, tak po lidské stránce.

[kralyk z abclinuxu]

Aspoň sám vidíš, jak je ten argument od začátku mimo mísu.

U wot m8? Nic takového z toho vidět není. Šlo mi o to, že nechci mít init napsaný v bashi, protože bash je, narozdíl od C, mizerná volba pro psaní spolehlivého a efektivního systémového software. Jasně, v C se dá psát hnusně, ale je to osvědčená věc pro realizaci věcí jako je kernel, různí démoni, servery, atd., ie. je to velmi dobrá volba pro systémové programování.

Přijde mi více než smysluplné stejným způsobem přistupovat i k realizaci initu.

Celé se to zvrhlo do takové míry, že je výsledek špatný jak po technické, tak po lidské stránce.

Když se podívám do jakékoli diskuse ohledně initu, vůbec mi nepřipadá, že by na tom zbytek komunity mimo systemd byl lépe. Podívej se třeba už jen do téhle diskuse, jediný odpůrce systemd, který nějak rozumně diskutuje, je Heron (a samozřejmě Jenda, ale ten vypadá, že mu nevyhovuje žádný init (čemuž se moc nedivím)). Ditto takhle buga - když se podívám na ten naprosto nesmyslný a zbtečně útočný rant toho člověka, co na ten bug přišel...

[pavlix]

Tak jako mě je docela jedno, co si o tom myslíš, jen k tomu píšu svůj vlastní pohled jako kdokoli jiný v diskuzi.

[Hans1024]

Šlo mi o to, že nechci mít init napsaný v bashi, protože bash je, narozdíl od C, mizerná volba pro psaní spolehlivého a efektivního systémového software.

Uprimne, to, co jsi napsal "...protože za tím bash scriptem vůbec nejsou kvatna céčkového humusu, že." mi pripada jako uplne jiny argument, nez to co pises ted.

Když se podívám do jakékoli diskuse ohledně initu, vůbec mi nepřipadá, že by na tom zbytek komunity mimo systemd byl lépe. Podívej se třeba už jen do téhle diskuse, jediný odpůrce systemd, který nějak rozumně diskutuje, je Heron (a samozřejmě Jenda, ale ten vypadá, že mu nevyhovuje žádný init (čemuž se moc nedivím)).

Lidi, kteri systemd nepouzivaji, o nem treba nemaji tak velkou potrebu diskutovat. Ja jsem v dobe prosazovani systemd velice rychle pochopil, ze to, co chteji Lennart a spol (a taky to, jakym zpusobem si to prosazuji) neni kompatibilni s tim, co chci ja, a proste jsem se podle toho zaridil, pouzivanim projektu, ktere mym ucelum vyhovuji mnohem vice.

Ditto takhle buga - když se podívám na ten naprosto nesmyslný a zbtečně útočný rant toho člověka, co na ten bug přišel...

Ja mam zase docela pochopeni pro ventilaci frustrace. Prestoze na zadnem svem stroji systemd nemam, uz me dva pribuzni nezavisle na sobe otravovali s tim, ze se jim system zasekne pri bootu, (ne)prekvapive pote, co jejich distribuce presla na systemd. To jednomu proste skazi den.

Kdyz nekdo resi problem, ktery vetsina uzivatelu nema, a to resenim, ktere zpusobuje problemy, ktere predchozi reseni nemelo, a navic odmita jakkoli spolupracovat s alternativnim resenim a utoci na lidi, kteri preferuji jiny pristup, tak neni nic prekvapiveho na tom, ze reakce na systemd jsou takove, jake jsou.

[kralyk z abclinuxu]

Uprimne, to, co jsi napsal "...protože za tím bash scriptem vůbec nejsou kvatna céčkového humusu, že." mi pripada jako uplne jiny argument, nez to co pises ted.

No protože mezitím přišel pavlix s tím, že systemd má místo bashe tuny céčka, jako kdyby CPU vykonávalo přímo bash a céčko pod tím nebylo i v případě sysvinitu... Akorát poměrně nešikovně skrz bash.

Ja mam zase docela pochopeni pro ventilaci frustrace.

No pro mě za mě, ať si ten člověk klidně frustraci ventiluje, ale dojem profesionality tím teda úplně nevzbudí. Bude teď znám jako někdo, kdo neví, jak se zachází s bezpečnostními chybami a dostane histerický záchvat, když na nějakou narazí. Místo zprávy maintainerům píše veřejnou reportáž ve stylu TV Nova. Být ta chyba trochu závažnější, mohl způsobit poměrně rozsáhlé problémy.

Kdyz nekdo resi problem, ktery vetsina uzivatelu nema, a to resenim, ktere zpusobuje problemy, ktere predchozi reseni nemelo, a navic odmita jakkoli spolupracovat s alternativnim resenim a utoci na lidi, kteri preferuji jiny pristup, tak neni nic prekvapiveho na tom, ze reakce na systemd jsou takove, jake jsou.

Mně to překvapivé připadá, protože systemd nebo Lennart "Voldemort" Poettering není tím, kdo za to primárně může, můžou za to distribuce, nesnad?

[pavlix]

No protože mezitím přišel pavlix s tím, že systemd má místo bashe tuny céčka

Uvědomuješ si, že jsem jenom nastavoval zrcadlo nesmyslnému argumentu ohledně bashovského driveru initskriptů? A že hlavní součástí argumentu byl ten řádově odlišný počet řádků, který po celou dobu ignoruješ? Když už se odkazuješ na mě, nemusel byses uchylovat k takové manipulaci.

Být ta chyba trochu závažnější, mohl způsobit poměrně rozsáhlé problémy.

Přesně tak. Budeme nadávat na člověka, který zveřejnil chybu, protože by mohl býval zveřejnit závažnější chybu... To jsme to dopracovali. :)

Mně to překvapivé připadá, protože systemd nebo Lennart "Voldemort" Poettering není tím, kdo za to primárně může, můžou za to distribuce, nesnad?

Ano, můžou za to primárně distribuce. Ten člověk ovšem umí velmi dobře vyvolávat negativní emoce a starat se o své nehynoucí blaho, takže se holt v reakcích objeví i jeho jméno.

[kralyk z abclinuxu]

A že hlavní součástí argumentu byl ten řádově odlišný počet řádků, který po celou dobu ignoruješ?

Tak to jsem z toho nepochopil, sorry, nechtěl jsem manipulovat.

Pokud to bylo porovnání počtu řádek mezi bashem a C, tak to mi přijde trochu jako jabka s hruškama, to se přece úplně nedá porovnávat. Pokud jde o bash versus sytemd:

$ ll /usr/bin/bash /usr/lib/systemd/systemd
-rwxr-xr-x 1 root root 769K 30. čen 20.59 /usr/bin/bash
-rwxr-xr-x 1 root root 995K  7. říj 19.38 /usr/lib/systemd/systemd

Nicméně určitě souhlasím, že by systemd mohl být štíhlejší...

Budeme nadávat na člověka, který zveřejnil chybu, protože by mohl býval zveřejnit závažnější chybu... To jsme to dopracovali.

Nemám žádnej problém s tím, že ji zvěřejnil. Pouze ten způsob, kterým to udělal, mi přijde mírně mimo, ale vzhledem k tomu, že tím asi v zásadě nezpůsobil žádnou strašlivou škodu, tak je to spíš jeho mínus...

Ano, můžou za to primárně distribuce. Ten člověk ovšem umí velmi dobře vyvolávat negativní emoce a starat se o své nehynoucí blaho, takže se holt v reakcích objeví i jeho jméno.

Mně přijde, že se objevuje primárně jeho jméno a podíl distribucí se dost ignoruje, včetně toho, že když si distribuce (Debian) napíše rozšíření do systemd, které způsobí ten problém s fsck timeout, tak se to automaticky hodí na systemd.

[pavlix]

Tak to jsem z toho nepochopil, sorry, nechtěl jsem manipulovat.

Sorry za chybný předpoklad.

Pokud to bylo porovnání počtu řádek mezi bashem a C, tak to mi přijde trochu jako jabka s hruškama, to se přece úplně nedá porovnávat. Pokud jde o bash versus sytemd:

Je to argument proti tvé stížnosti na 2K shellskript, který jednak není ani řádově srovnatelný se systemd, ani nemusí být nutně interpretován bashem, jednak se používá na systémech, kde v, ani tam vůbec nemusí nutně být, jenžto je to jen jedno z možných řešení. Nehledě na to, že se používá na systémech, kde vždy nějaký shell je.

Mimochodem o podpůrných shellovských skriptech nikdo do vzniku potřeby omlouvat systemd nemluvil, tudíž mi nezbývá než to považovat za čistě účelovou argumentaci bez jakékoli vypovídací hodnoty. Nemá smysl brečet nad tím, že je to systemd vs zbytek světa, když zbytek světa není tím, kdo se vymezil.

[little.owl]

... , když zbytek světa není tím, kdo se vymezil.

Temer kazdy projekt se vymezuje, s tim neni zadny problem.

[pavlix]

Nemyslím si.

[pavlix]

Sorry za ten zmatečný odstavec, opravím.

1) Že je něco realizováno shellovským skriptem nikdy do rétoriky systemd nebylo apriori považováno za problém.

2) Že má shellovský skript 2K řádků není v kontextu 200K řádků systemd argument.

3) Shell se používá na všech systémech se systemd a vcelku běžně se volá ze systemd unit files.

4) Shellovský skript vůbec nemusí vyžadovat bash.

5) Argumentuješ vůči jednomu konkrétnímu řešení, ačkoliv nepoužití systemd dává obrovské množství alternativ, které ani všechny v shellu být nemusí.

Jestli tedy nemáme žádný jiný argument než že je módní bránit systemd, nemusí se protistrana nijak namáhat a stačí jako protipól položit, že je úplně stejně módní ho hanět. :)

[kralyk z abclinuxu]

Že je něco realizováno shellovským skriptem nikdy do rétoriky systemd nebylo apriori považováno za problém.

Já jsem s tím teda problém měl už předtím. A další lidé AFAIK také (v této diskusi Jenda?).

Že má shellovský skript 2K řádků není v kontextu 200K řádků systemd argument.

Zcela mi uniká, co mají řádky shellu společného s tím kontextem těch 200k řádků C kódu (který navíc afaik zahrnuje celý projekt systemd, ne pouze init). Ty máš nějaký koeficient, kterým porovnáváš řádky shellu a C kódu?

Shellovský skript vůbec nemusí vyžadovat bash.

To je pravda. Ne, že by jiné shelly byly menší

Argumentuješ vůči jednomu konkrétnímu řešení, ačkoliv nepoužití systemd dává obrovské množství alternativ, které ani všechny v shellu být nemusí.

Pak si ale špatně vykládáš moji pozici, moje pozice není bránit nutně systemd, ale nahradit nečím právě tohle konkrétní řešení - sysvinit+skripty, protože to je řešení, které moje distro (Arch) používalo předtím a měl jsem s tím problémy, IMHO to bylo naprosto mizerné řešení. No a bylo to nahrazeno systemd, s čímž jsem spokojen, alespoň co se initu týče. (Že mě vysírá journald je další věc.)

Co se týče těch "mraků ostatních řešení", tak až takové mraky teda nevidím, a už vůbec co se týče dostupnosti v distribucích...

[kralyk z abclinuxu]

Ačkoli je pravda, že třeba dash asi o dost menší bude...

[Hans1024]

Defaultni shelly v BSDckach jsou taky mensi.

[Hans1024]

Zcela mi uniká, co mají řádky shellu společného s tím kontextem těch 200k řádků C kódu (který navíc afaik zahrnuje celý projekt systemd, ne pouze init). Ty máš nějaký koeficient, kterým porovnáváš řádky shellu a C kódu?

Ja myslim, ze zadny koeficient tak diametralni rozdil nezachrani. Pokud se podivam na ty rc skripty v OpenBSD, a pak na systemd, ten rozdil v komplexite je tak kolosalni, ze snad nema cenu ho nejak zpochybnovat.

To doklada i hromada bugu, nad kterou vyvojari systemd velice snadno mavnou rukou s tvrzenim "kazdy software ma bugy", pricemz bud ignoruji, nebo je jim jedno, ze se jedna o dusledek komplexity zpusobene jejich zpusobem vyvoje a rozsahem projektu. Tahle mentalita je casto pritomna i u jinych projektu, ale ty se obvykle netvari, jako ze ostatni jsou zpatecnici co brzdi jejich skvelou vizi.

[kralyk z abclinuxu]

Ja myslim, ze zadny koeficient tak diametralni rozdil nezachrani. Pokud se podivam na ty rc skripty v OpenBSD, a pak na systemd, ten rozdil v komplexite je tak kolosalni, ze snad nema cenu ho nejak zpochybnovat.

Bavíme se pouze o initu, nebo o celém systemd? To je totiž dost rozdíl.

V každém případě nechci zpochybňovat, že ten skript je mnohonásobně jednodušší než systemd. To bezpochyby je. Starý init systém třeba v Archu už ale až tak extrémně malý nebyl, o některých jiných distrech nemluvě.

Nicméně u programu v C mi nepřijde nutně na závadu, když jsou velké, narozdíl od bashe. Třeba takový git byl na začátku taky ze značné části skripty, dnes ho tvoří ~100k řádků céčka. Proč už si nikdo dávno nestěžuje na kolosálnost?

[Hans1024]

Nicméně u programu v C mi nepřijde nutně na závadu, když jsou velké, narozdíl od bashe. Třeba takový git byl na začátku taky ze značné části skripty, dnes ho tvoří ~100k řádků céčka. Proč už si nikdo dávno nestěžuje na kolosálnost?

Tak treba u OpenBSD je to myslim jeden z duvodu, proc nechteji git pouzivat. Me pripada git tak nekde na pul cesty mezi minimalismem OpenBSD a silenosti systemd, takze pro vetsinu lidi asi idealni. A samozrejme, ze ta komplexita nesouvisi jenom s velikosti. Shell na velky projekt smysl moc nedava, ale pouziti Cecka neznamena, ze prilis velka komplexita prestane vadit. Taky ma git velkou vyhodu v tom, ze je to proste program, ktery clovek spusti, aby udelal konkretni, celkem dobre definovanou vec a pak se ukonci a se zbytkem systemu temer neinteraguje.

[kralyk z abclinuxu]

Tak treba u OpenBSD je to myslim jeden z duvodu, proc nechteji git pouzivat.

ROFL...

[pavlix]

Mám za to, že bývá Git posuzován především z hlediska uživatelského rozhraní, architektury a dostupnosti návazných náštrojů a služeb. A popravdě si myslím, že ani u toho initu to není reálný argument.

[Hans1024]

Ja myslim, ze uzivatele sice komplexitu a zpusob vyvoje obvykle neresi, ale rozhodne jim vadi pripadne dusledky v podobe bugu a regresi.

[kralyk z abclinuxu]

Přijde mi, že tohle je diskuse analogická známému XY problem. V systemd jsou bugy → systemd je komplexní → komplexní software má bugy.

Přitom problém je prostě v tom, že systemd má bugy. Celou tu debatu o komplexnosti software vedeme dost zbytečně.

[pavlix]

Nejde o to, že má bugy, ale že je po mnoha stránkách zcela nevhodně navržený od vnitřnosti až po user interface.

[Heron]

Jenže ta komplexnost komplikuje řešení těch bugů.

Vem si, co všechno v systému můžeš zaměnit. Já se třeba zabývám av obsahem, zejména obrázky. Máš imagemagick, potom máš graphicsmagick. Stále mají dostatečně kompatibilní rozhraní, takže pokud nefunguje jeden, nasadím druhý. A program / skript, prostě funguje dál, beze změny (protože v systému stále existuje příkaz convert a to, že se mu změnila implementace ten skript vůbec nezajímá).

Nebo ffmpeg, mencoder, avconv apod. Všechny dělají stejnou věc, pokud je v jednom z nich buga, tak se tam dá jiný. Na zbytek programu se nemusí sáhnout.

Pokud někomu nevyhovuje bash, může použít asi 30 dalších shellů. Ta tak dále.

Spousta programů umí požívat víc nástrojů (php-gd, imagemagick zaměnitelný s graphicmagickem, + třeba i jednotlivé utilitky jednotlivých grafických formátů. Pokud nefunguje jedna, přepnu v nastavení programu na jiný toolkit a jede se dál.)

Takže já preferuji skládání větších celků z malých a zaměnitelných kostiček. Každá kostička dělá jednu věc a dělá ji pořádně . Pokud je bug v jedné kostičce pro optimalizaci png, tak to nahradím za jinou (případně optimalizaci png odstraním z pipeline, protože to není nic kritického) a jede se dál. Kostičky jsou spojené jednoduchým lepidlem, ve kterém sice může být také chyba, ale buď jde nahradit jinou implementací (jiný shell), nebo je to tak jednoduché, že se snadno opraví.

Hrabu se v datech, fs si vybírám podle povahy ukládaných dat a taky podle funkcí. Na něco xfs, tam, kde se mi s výhodou hodí snapshoty, tak btrfs. Nemám jeden fs na všechno, protože takový neexistuje. Pokud bude v nějakém fs buga a já mu přestanu důvěřovat, nahradím ho jiným (nahradil jsem ext4 právě xfs). A program si toho ani nevšimne. Možná se změní výkon různých operací, ale to ten program stejně nesleduje a neřídí se tím. To není jeho práce.

Takže já jsem zvyklý na to, že lze vyměnit jednotlivé komponenty a celek funguje stále stejně dobře. Po této stránce by byla bomba, kdyby šel vyměnit i kernel (debian má projekt kfreebsd), ale tam není možné ráno nabootovat linux a večer kfreebsd, takto to zatím bohužel nefunguje (už jen třeba proto, že neexistuje jeden fs, který by uměl jak bsd tak linux používat jako root fs).

[kralyk z abclinuxu]

Jenže ta komplexnost komplikuje řešení těch bugů.

To si nemyslim, chyby se opravují i v komplexnějším software. Podle mě to je spíš prostě neochota.

Jinak ke zbytku komentáře je těžko něco říct, protože to je řečeno hodně obecně.

Osobně ten přístup, kdy si člověk věci poskládá, mám taky rád, ale

U nějakého hraní s A/V médii je to opravdu jednoduché. A tohle v podstatě platí o většině zejména uživatelských záležitostí na desktopu. Nadruhou stranu, třeba init nebo filesystémy by se mi nechtělo měnit moc často.

Problém je když člověk začne třeba psát programy nebo realizovat služby, které na těch věcech závisí. Ano, v některých programech je možné měnit backendy, ale ten program na to musí mít buď explicitní podporu, nebo musí existovat nějaká abstrakční vrstva, kterou někdo někde definoval, udržuje ji, projekty ji používají, atd.

Co se týče těch shellů, ano, uživatel si může vybrat z 30 shellů, ale musí počítat, že mu třeba taky přestanou fungovat jeho skripty, které doposud používal. Nebo, pokud bude mít opravdu smůlu, začnou dokonce dělat něco jiného.

Vyměňování jádra systému pod zadkem mi přijde už dost mimo.

Calkově: Myšlenka je to hezká, ale takhle utopisticky, jak to popisuješ, to nikdy prakticky fungovat nemůže. Ta analogie s kostičkama je v tomhle docela dobrá: Můžeš si stavebnici sestavit z různých kostek, jenže všechny ty kostky vyrobila jedna firma, která přísně dohlíží na veškeré rozměry/parametry všech kostek a vyrobila je s tím, aby šly k sobě a dávaly dohromady nějaký smysl.

Co se týče systemd, vůbec nevím, jakým způsobem vidíš systemd v kontextu tohohle argumentu, to jsem z komentáře nevyčet. Initová část mi příliš monolitická rozhodně nepřipadá. Pokud to ale vztahuješ na ten projekt celkově, tak s tím celkem souhlasím, že to není dobře, tak jak to je. Ale nepřijde mi, že by to bylo o komplexnosti, spíš je to o rozraních a standardizaci.

[Heron]

U nějakého hraní s A/V médii je to opravdu jednoduché.

Jenže úplně stejně je to jednoduché i u původních sysv rc skriptů. Jsou to jen shellové skripty, používající pár základních "kostiček" (sed, grep, find, pipe apod.). Pokud se tam nepoužívají bashismy (nebo jiné shellismy), tak můžeš i relativně svobodně měnit i interpret těch skriptů (musí být dostatečně kompatibilní s sh, přičemž to dostatečně není jinak silné - viděl jsem daleko extrémnější příklady, co vše lze v bashi dělat, v tomto se sysv rc skripty držely hodně při zemi (a je to dobře)). Některé shelly mají výše uvedené základní příkazy jako built-in, jiné používají samostatné programy. Implementace se mění, funkce zůstává.

nebo filesystémy by se mi nechtělo měnit moc často

Tak krom zkopírování dat s tím žádné další nepohodlí není. Programy si toho ani nevšimnou. A pokud ano (hint: ext4, změna módu jourálování, a ztráta dat u blbě napsaných programů), tak je to chyba a tu je potřeba opravit.

všechny ty kostky vyrobila jedna firma, která přísně dohlíží na veškeré rozměry/parametry všech kostek

No, říká se tomu standardizace. Nemám pocit, že bych si musel kupovat například všechny audio komponenty (pokud by opět vadil příměr s AV - i když tentokrát fyzickým, tak si tam doplň cokoliv jiného: šrouby, matice, mosfety, motory, lana, kladky, cepíny, závory) od jedné firmy. Bohatě stačí, že všechny používají stejné konektory a stejné linkové úrovně. Tak jak je to definované v nějaké normě. Standardizací ve světě linux je posix (+ osobně doplňuji vfs).

Vyměňování jádra systému pod zadkem mi přijde už dost mimo.

Dobře, možná že "každý boot jiné jádro" je asi už přehnané, ale nemám pocit, že by bylo nějak extra náročné programovat pro bsd a pro linux. Mám-li říct pravdu, tak z uživatelského hlediska nevidím mezi těmito systémy žádný rozdíl, na obou mám stejné programy a kdyby součástí hostname nebyly písmenka bsd, tak bych si rozdílu vůbec nevšiml. Nejsem vývojář, tak nevím, jak velký problém je vyvíjet program pro linux a bsd ale soudím, že to příliš náročné nebude (nehledě na to, že programy v perl, python, sh apod. by měly fungovat všude stejně - moje bastl programy fungují a třeba u youtube-dl jsem též nezaznamenal problém).

Co se týče systemd, vůbec nevím, jakým způsobem vidíš systemd v kontextu tohohle argumentu, to jsem z komentáře nevyčet.

To už se dostáváme k těm koncepčním věcem. Už třeba jen snadnost údržby. Když se pokazí něco v sh init skriptu, tak se na tom podívám, opravím a jede se dál. Když se něco pokazí v systemd, tak jsem skončil, přestože jsem na škole programoval v C a někteří mi dodnes od té doby říkají Céčko (jazyk C + i první písmenko mého příjmení), tak už jsem nějaký ten pátek C neviděl (to raději spíše python), a navíc si nedovedu představit, jak ve 3 ráno na pohotovosti startuju debuger, opravuju a kompiluju systemd. Fakt ne.

[pavlix]

Nejsem vývojář, tak nevím, jak velký problém je vyvíjet program pro linux a bsd ale soudím, že to příliš náročné nebude

Skutečně to není problém. Buď se napíšou vybrané low-level věci ve dvou variantách, nebo se použije hotová mezivrstva, pokud je dostačůjící. Fakt to není nic divokého, navíc jsou ty rozdíly docela obstojně zdokumentované.

[kralyk z abclinuxu]

Jenže úplně stejně je to jednoduché i u původních sysv rc skriptů.

Ty si možná chceš denně hrát se střevama initu jako s A/V, já teda rozhodně ne. U initu chci, aby fungoval dlouhodobě a efektivně, což se s shell skripty IMHO víceméně vylučuje (mluvím o initu jako takovém, nemluvím nutně o definicích nebo spouštěčích služeb). Nevylučuje se to úplně, určitě to nějak jde, ale přijde mi to jako web v PHP ve stylu rok 2000.

Jestli má být init napsaný v nekompilovaném jazyce, tak bych prosil alespoň Python.

Standardizací ve světě linux je posix (+ osobně doplňuji vfs).

Spoustu věcí, které řeší systemd, POSIX vůbec neřeší. (Předpokládám, že bude následovat "argument", že co neřeší POSIX, není potřeba řešit...)

Nejsem vývojář, tak nevím, jak velký problém je vyvíjet program pro linux a bsd ale soudím, že to příliš náročné nebude

Kdekoli, kde se interaguje s jádrem to problém být může celkem snadno. Což se nezdá, ale probublá to všade možně. Třeba emulátor terminálu potřebuje ifdefy pro bsd, to jen namátkou vzpomínám...

To už se dostáváme k těm koncepčním věcem. Už třeba jen snadnost údržby. Když se pokazí něco v sh init skriptu, tak se na tom podívám, opravím a jede se dál. Když se něco pokazí v systemd, tak jsem skončil, přestože jsem na škole programoval v C ...

Ježimarjma už zase tohle. Jasný. Na Linuxu, který bootuje asm/céčkovým bootloaderem do asm/céčkového jádra, k inicializi používá hromadu céčkových komponent, včetně třeba fsck a tak dále, následně startuje céčkové démony, které musí být vysoce spolehlivé. Ale kdyby byl init v céčku, to by byl najednou problém, protože co bychom dělali, kdyby se pokazil?

Když se pokazí bootloader, nahradíme jiným, není problém. Když se pokazí jádro, ta samé. Když se pokazí fsck, nahrádíme filesystém, to nemůže být žádný problém a nemůže to trvat dlouho, pohoda. Když se pokazí PostgreSQL démon, což se děje tak tříkrát do týdne, protože je hodně komplexní, nevadí to, nastartujeme místo něho MySQL a všechno bude zcela jistě hned zase fungovat. Když se pokazí Apache, nahradíme nginx, lighttpd neo čímkoli jiným, opět nevidim absolutně žádný prostor pro problémy. Když se pokazí sshd, přihlásíme se telnetem a jedeme dál. Cajk.

Ale jak je problém v systemd, to jsme v prdeli, s tím se bez debuggeru a znalosti céčka nedá dělat absolutně vůbec nic. To můžem rovnou zahodit celou tu mašinu a pro jistotu několik dalších okolo rovnou taky.

FFS.

[pavlix]

U initu chci, aby fungoval dlouhodobě a efektivně, což se s shell skripty IMHO víceméně vylučuje

Nesmysl. Tento hon na shell vznikl až jako dodatečné ospravedlnění systemd. Do té doby byl shell prostě jednou z mnoha možností, jak potřebné akce zavolat.

Ale kdyby byl init v céčku, to by byl najednou problém, protože co bychom dělali, kdyby se pokazil?

Init byl pokud vím v céčku odjakživa.

[kralyk z abclinuxu]

Nesmysl. Tento hon na shell vznikl až jako dodatečné ospravedlnění systemd. Do té doby byl shell prostě jednou z mnoha možností, jak potřebné akce zavolat.

Už asi potřetí píšu, že já měl s init skripty problémy ještě předtím, než jsem cokoli slyšel o nějakém systemd, snažil jsem se jich zbavit a uvažoval jsem o přizpůsobení nějaké existující náhrady nebo napsání vlastní.

[pavlix]

To docela značně ustupuješ. Ještě před chvílí se shell skripty se spolehlivou funkcí inicializace systému zcela vylučovaly.

[kralyk z abclinuxu]

? Cože? Ta náhrada neměly být zase shell skripty... Nebo nevim, jak to myslíš...

[little.owl]

Nesmysl. Tento hon na shell vznikl až jako dodatečné ospravedlnění systemd.

Nesmysl . To uz bylo zduvodneni davno predtim uz treba u Solaris SMF, tady LP neprisel s nicim novym.

[pavlix]

Osobně jak shell, tak céčko, tak python, tak jiné považuju prostě za nástroje. Dobře, některé nástroje preferuju, některé míň, ale stavět cargo cult kolem toho, jestli je kus kódu v C nebo v shellu mi přijde padlé na hlavu. Kralyk nemá absolutně žádné argumenty. Možná, když mu přijdeš na pomoc, bude diskuze vypadat jinak. :)

[kralyk z abclinuxu]

Zamysli se, jetsli bys chtěl mít v bashi napsaný třeba ssh démon nebo něco takového. Pokud ne, stejné důvody mám já proč nechci mít init v shellskriptech. Pokud ano, pak nechi pokračovat ve vlákně

[pavlix]

Pokud ne, stejné důvody mám já proč nechci mít init v shellskriptech.

V tom případě doporučuju sysvinit, ten je napsaný v céčku. :D

[Heron]

Ty si možná chceš denně hrát se střevama initu

Nechci. Ale pokud je potřeba, tak si vyberu tu snadnější možnost.

U initu chci, aby fungoval dlouhodobě a efektivně, což se s shell skripty IMHO víceméně vylučuje (mluvím o initu jako takovém, nemluvím nutně o definicích nebo spouštěčích služeb).

Otázka je, co zde konkrétně myslíš tím efektivně. Jako že je to pomalejší než kompilované jazyky? To jistě ano, ale mašinerie rc skriptů se při bootu spustí jen jednou a těch (i kdyby) pár sekund navíc sežraných neefektivitou interpretru, tak (podle mě) je zcela nezajímavých a ztratí se v těch měsících následujícího provozu.

Jestli má být init napsaný v nekompilovaném jazyce, tak bych prosil alespoň Python.

Nemám nic proti.

(Předpokládám, že bude následovat "argument", že co neřeší POSIX, není potřeba řešit...)

Původní argument byl, že o výrobu "kostiček" se musí starat jedna firma. Nemusí. I ve fyzickém světě se běžně desítky let let používají součástky různých výrobců a není s tím problém. Stačí dodržovat normy.

Kdekoli, kde se interaguje s jádrem to problém být může celkem snadno. Což se nezdá, ale probublá to všade možně. Třeba emulátor terminálu potřebuje ifdefy pro bsd, to jen namátkou vzpomínám...

Fakt se nebudu pouštět na tenký led, tady už jsem hodně let mimo mísu. Programoval jsem v ANSI C, stejný kód jsem přeložil jak na linuxu, tak na Windows. Používají se knihovny, které příslušné změny odstíní. Moje "největší dílo" byl CGI program, na kterém běžela tehdejší verze mého webu. Tím bych tento směr diskuse asi ukončil, protože nejsem prog.

Ježimarjma už zase tohle.

Škoda, do teď to byla klidná zajímavá diskuse.

Ale kdyby byl init v céčku, to by byl najednou problém, protože co bychom dělali, kdyby se pokazil?

Já bych jenom chtěl říct, že ne všechny programy jsou kompilované. Opravoval jsem programy v Perlu, Pythonu, v Sh, php apod. Tento bod není o tom, že "zrovna u systemd je problém, pokud je v C, ale u jiných to nevadí". Tento bod je o tom, že preferuju možnost to snadno vlastními silami opravit. Buď drop in náhradou za jinou implementaci, nebo klidně opravit řádek 512 v nějakém perlovém programu (vzpomínám si třeba na backuppc). Nehledě na to, že když mám možnost se do toho programu podívat, tak snadněji dokážu zjistit, co se mu nelíbí (když tam zrovna není jasná chybová hláška). Tohle se mi třeba s strace nikdy tak snadno nedařilo (možná je to jen rukama).

Když se pokazí PostgreSQL démon

To by zrovna problém byl, protože ač se člověk snaží používat SQL standard, tak rozšíření typu hstore nebo json jsou natolik lákavá, že se tomu často nelze ubránit. Ale pochopitelně kdyby se chtělo, tak se dá vedle PG ještě Mongo a je to.

Jinak PostgreSQL máme nasazen na desítkách serverů, za 10 let jsou to zkušenosti rovnající se stovkám "postgres-years", velikost dat na produkci přerůstá 3TB a zatím nejmenší problém. Takto si prostě představuji program, která dělá svou práci a dělá ji dobře. Kdyby toto byl standard systemd, tak ani nepípnu.

[kralyk z abclinuxu]

Původní argument byl, že o výrobu "kostiček" se musí starat jedna firma. Nemusí. I ve fyzickém světě se běžně desítky let let používají součástky různých výrobců a není s tím problém. Stačí dodržovat normy.

To bylo jen v rámci té analogie s tou stavebnicí, co se týče Linuxu, jedna firma to samozřejmě být nemusí. Nicméně aby bylo možné dodržovat nějaké standardy a normy, musí ty standardy a normy prvně existovat, že.

Dejme tomu, že napíšu démona a budu chtít, aby byl k mání pro různá Linuxová distra, rovnou out-of-the-box s možností nainstalovat a spustit službu. Ve světě před systemd se musím buď postarat o každé distro zvlášť, nebo o jedno/pár vybraných a doufat, že zbytek si to nějak přebere. Ve světě se systemd mi víceméně stačí napsat unitu a tím mám pokrytou většinu dister. Ideální by samozřejmě bylo, kdyby pro to existoval standard, ale zatím o ničem takovém nevím.

Jinak PostgreSQL máme nasazen na desítkách serverů, za 10 let jsou to zkušenosti rovnající se stovkám "postgres-years", velikost dat na produkci přerůstá 3TB a zatím nejmenší problém. Takto si prostě představuji program, která dělá svou práci a dělá ji dobře. Kdyby toto byl standard systemd, tak ani nepípnu.

Tomu věřím, tak by to třeba mohl být příklad software, který je v C a je komplexní (AFAIK několikrát větší než systemd, jestli mám správná čísla), ale je spolehlivý/dobrý. Tj. ten problém u systemd bude v něčem jiným...

[Heron]

Nicméně aby bylo možné dodržovat nějaké standardy a normy, musí ty standardy a normy prvně existovat, že.

No tak ony i existují, ale zkus v nějaké diskusi říct, že to či ono nedodržuje RFC. V lepším případě se ti jen vysmějou.

Dejme tomu, že napíšu démona a budu chtít, aby byl k mání pro různá Linuxová distra, rovnou out-of-the-box s možností nainstalovat a spustit službu.

Proč bys ho měl psát ty? O to se mohou postarat balíčkáři v distrech (nebo pokud budeš pro ta distra dodávat i balíčky, tak s tím je ještě víc práce, než s jedním skriptem). Ti svá distra znají a pokud ten démon nedělá psí kusy tak je to stejně jen o doplnění do nějaké šablony rc skriptu.

Jinak tohle je skutečně fascinující. Toto se opakuje stále dokolečka. Někdo napíše svůj skvělý program, ale potom jaksi není schopen upravit pár řádků v nějakých init skriptech.

Stejně je to typicky jen to tom někam strčit "mujuzasnyprogram -d".

Tj. ten problém u systemd bude v něčem jiným...

Já PostgreSQL považuju za jeden z nejlepších příkladů návrhu unixového software vůbec. Možná je to u mě už známka postgresofilie, nevím. Totiž ten program nedělá nic co nemusí. Na rozdíl od jiných DB systémů, které přímo používají blokové zařízení, tak postgresql používá fs. FS musí být dostatečně příčetný, další nároky na to nejsou (klidně si to provozujte na NFS, pokud si ho nastavíte). Používá IO cache OS, nesnaží se o vlastní implementaci téhož. Má na kdeco subprocesy, jedno spojení s klientem, jeden subproces. Triviální. Na komunikaci subprocesů (IPC) používá shared memory. Díky tomu, že neřeší kdejakou kravinu NIH stylem, se může soustředit na svou práci. Tedy jednak je to úložný engine, který spolehlivě ukládá data. V podstatě jen dvou datových typů (pevných a varlena), vše ostatní se na to transformuje. Veškerá energie je věnována tomu, aby to byla dobrá SQL databáze, takže parser, exekutor apod si prostě napsat vlastní musejí. Ale ten zbytek ne, ten už je v systému a stačí ho jen použít.

Na druhé straně je systemd, který se snaží si dělat vše po svém. Jednak je to strašná hora práce, ve které nevyhnutelně budou chyby, ale také to "po svém" nemusí být koncepčně dobře. Tak, jak znám (alespoň blokově) architekturu PG, tak vůbec neznám architekturu SD. Na blogu jeho blahorodí jsem žádný diagram nenašel. Z toho, jak se mi sd jeví zvenku, tak mi to nepřipadá jako nejlepší návrh.

[kralyk z abclinuxu]

Proč bys ho měl psát ty? O to se mohou postarat balíčkáři v distrech (nebo pokud budeš pro ta distra dodávat i balíčky, tak s tím je ještě víc práce, než s jedním skriptem). Ti svá distra znají a pokud ten démon nedělá psí kusy tak je to stejně jen o doplnění do nějaké šablony rc skriptu.

Tohle se mi právě nelíbí, na baličkáře v distrech takhle všechno hodit, protože vím jak to pak dopadá, zejména když je distro komunitní, ie. má omezené zdroje (Arch). V podstatě mi to přijde jako požadavek, aby v každém distru seděl nějaký člověk a dělal víceméně zbytečnou práci.

Na druhé straně je systemd, který se snaží si dělat vše po svém. Jednak je to strašná hora práce, ve které nevyhnutelně budou chyby, ale také to "po svém" nemusí být koncepčně dobře. Tak, jak znám (alespoň blokově) architekturu PG, tak vůbec neznám architekturu SD. Na blogu jeho blahorodí jsem žádný diagram nenašel. Z toho, jak se mi sd jeví zvenku, tak mi to nepřipadá jako nejlepší návrh.

S tím celkem souhlasím.

[pc2005]

Jestli má být init napsaný v nekompilovaném jazyce, tak bych prosil alespoň Python.

Python ne. Init skripty by měly mít uzavřené závislosti v co nejmenším interpreteru. Prakticky každý druhý projekt v pythonu po mě chce instalaci nějakýho modulu. V případě nutnosti tenhle skript nainstalovat pak lehko dojde k deadlocku.

[Bedňa]

Podívej se třeba už jen do téhle diskuse, jediný odpůrce systemd, který nějak rozumně diskutuje, je Heron

Nemám pocit, že by sme sa spolu s tebou nejak nezhodli na tom čo mi vadí na systemd.

Sorry, ale ten systém smerovaním a samotnou komunitou je určený na smerovanie niekde do MS. Nechcú spoluprácu s projektami ktoré sú tu už roky, neexistuje žiadne napojenie na to čo tu už funguje roky, neexistuje tu žiadna priateľská atmosféra v zmysle spolupráce.

Niesom tak starý, ako si veľa pamätám, ale takéto projekty majú len dva konce, buď to samo umrie, čo je ten lepší prípad, alebo tu máme MS Windows číslo dva.

[Heron]

jediný odpůrce systemd, který nějak rozumně diskutuje, je Heron

Celkem by mě zajímalo, čím jsem si vysloužil nálepku odpůrce systemd.

Resp ta otázka by mohla znít i jinak: dle jakých kritérií si (vy ostatní) vybíráte programy?

Protože systemd ode mě dostalo nadmíru luxusní a opakované šance, jiné programy by už byly dáááávno na blacklistu a prostě by pro mě přestaly existovat.

A možná právě proto, že systemd používám, nacházím další a další chyby a potom o nich diskutuju, může za tu nálepku odpůrce. Systemd se asi nemá používat, to se má jen obdivovat (lehké rýpnutí).

[little.owl]

Celkem by mě zajímalo, čím jsem si vysloužil nálepku odpůrce systemd.

Asi stejne jako ja jeho fanaticky zastance .

[trekker.dk]

Systemd se asi nemá používat, to se má jen obdivovat

Včera jsem tu věc poprvé nainstaloval na Debianu. Musím uznat, že to, že out-of-the box funguje init skript, který po sobě nenechá žádný program spuštěný, mě příjemně překvapilo. To, že mi po zadání reboot okamžitě vytuhne SSH spojení, už ne.

Tak jsem hledal a našel jsem, že je potřeba nainstalovat nějaký další kus systemd a dbus, aby systemd vědělo, že je na tom serveru někdo přihlášený a neshodilo síť okamžitě (protože shodit ji okamžitě je skvělé pro to, aby se ten server vypnul co nejrychleji.) Tohle myslí vážně? Čert vem SSH, od té doby, co jsem objevil enter ~ . , mi vytuhlé spojení moc nevadí. Ale na tom serveru přece můžou běžet (a běží) další věci, které se potřebují čistě odpojit, než se ukončí. A se shozenou sítí to, hádám, asi moc nepůjde.

Se mi zdá, aby si člověk se systemd vyhradil pár měsíců na to najít/vyrobit workaroundy na jejich skvělé nápady.

[pavlix]

Hlavně existuje určitá třída chyb, které se v systemd roky neřeší s odkazem na to, že se vyřeší až s kdbus. Mezi ně patří i neschopnost spolehlivě zastavovat dbus-aktivované služby. Osobně bych systemd neoznačil za production-ready, dokud se všechny tyhle problémy nevyřeší a i potom budu mít k návrhu spoustu výhrad.

[kralyk z abclinuxu]

Celkem by mě zajímalo, čím jsem si vysloužil nálepku odpůrce systemd.

Neměla to ani být nějaká nálepka, měl jsem prostě pocit, že preferuješ minimalistické řešení...

[Heron]

No to preferuju, ale někdy si člověk prostě nevybere. Kdyby systemd dělal to co má, tak bych to neřešil. Resp jak píše Pavlix, potom by přišla řada na koncepční otázky. Ale o tom se můžeme hádat donekonečna a v praxi je to tak, že neexistuje jeden přístup, který by se hodil na všechny situace.

[Hans1024]

V rc.subr je 300 radku snadno citelneho shellu.

[Bedňa]

Staičlo napsat systemd unitu na několika málo řádcích

To verím a proti tomu hádam väčšina ani nič nemá, ale načo ten balast okolo?

[Václav "Darm" Novák]

Velkou část z toho balastu využívám. I ten journald je šikovný, i když bych preferoval trochu jiný formát ukládaných dat. Ale jak tu někdo odkázal, má to už stabilní API, takže se alternativ snad brzy dočkáme.

[kralyk z abclinuxu]

To verím a proti tomu hádam väčšina ani nič nemá, ale načo ten balast okolo?

Vim já? Z balastu okolo nejsem kdovíjak nadšený, nadruhou stranu jsem s ním ale zároveň neměl zatím problémy...

[little.owl]

Vetsina defaultni konfigurace je opt-in, nastavite jen kdyz potrebujete, a to plati i o modulech sdilejich systemd repository. Ted se pripravuje strict mode, pro "Portable Services", a kde bude pouzit opt-out pristup, a veci budou zakazany/omezeny pokud to neni explicitne povoleno.

[Filip Jirsák]

Hádám, že ten balast okolo je tam proto, že někdo někdy něco zaslechl o balastu kolem systemd, tak to dál opakuje, a vůbec neřeší, co by ten balast tedy mělo být. Pokud opravdu chcete odpověď na otázku „co ten balast okolo“, napište nejprve, co myslíte tím balastem.

[Bedňa]

Nejak som sa stratil v diskusií, takže dodatočne pre všetkých vyššie.

[AsciiWolf]

+1

[Filip Jirsák]

Já jsem se snažil váš komentář vyložit tím pro vás nejpříznivějším možným způsobem. Děkuji, že jste se férově přiznal sám, že je to daleko horší a komentujete něco, o čem vůbec nic nevíte.

vážná chyba

No, v PID 1 by mohly být mnohem horší chyby.

zbytečně komplexním bastlu, který běží v unixovém OS s PID 1

Co je /usr/lib/systemd/systemd na komplexního?

Měl by být, logicky, co nejjednodušší, jak tomu bývalo v minulosti. Pravděpodobnost takového trapného problému(v duchu tradic Microsoftu, Pejska a Kočičky a dalších...) by pak dramaticky poklesla.

Co přesně je na systemd PID 1 podle vás komplikované nebo zbytečné? Jak by mohla poklesnout pravděpodobnost takového problému, když by tam ten kód, ve kterém je problém, stejně byl?

[TM]

Tak, určitě.

[mirec]

Linuxu ako kernelu sa to zatiaľ moc netýka. Ani kdbus sa zatiaľ nepretlačil do kernelu (už som o ňom dlho nepočul, nakoniec sa ten koncept zahodil, alebo ho nahradil bus1?)

[AsciiWolf]

Nahradil ho BUS1, viz Phoronix.

[MilanK]

"Jak odrovnat systemd jedním tweetem"

To je tak, když dovolíte systemd číst tweety. Než se to snažit napravit na miliónech zařízení, to snad raději doufat v blízký krach Twitteru a modilit se, aby systemd neobjevil facebook nebo google+.