Názory k článku
Devuan Jessie: Debian bez systemd v první betaverzi

Nekrm trolla.. ;)

Hlášky na bootu jsou k ničemu (krom těch, kvůli kterým opravdu systém ani nenaběhne).

Ale hovno, prave barevne odlisene chybove hlasky pri bootu si clovek vsimne spis, nez neceho v logu. Zejmena pokud se cloveku ze systemu podari vykopat vselijake dementni Plymouthy, skryvani hlasek a kde co, co se snazi textovy boot nahradit nejakym nesmyslem. Krome toho ne vsechny hlasky z pbrazovky maji odpovidajici polozku v nejakem logu. I kdyz s Poetteringovym blobem by udajne mely byt odchyceny i hlasky, ktere vznikly pred namontovanim disku RW, tak je otazka, jestli se k nim clovek dostane. Je tu nekdo, kdo se uz poklousel cist Poetteringovy binarni logy? BTW, bootovaci obrazovku vidim pri kazdem bootu, existuje sance, ze si hlsky vsimnu. Ale do logu po kazdem bootu nelezu.

Promiň, prostě si myslím, že v moderním OS jako je i Debian, je volovina vypisovat uživateli něco čemu stejně nerozumí přes půl obrazovky, akorát ho to plaší, ale má se po naběhnutí systému zobrazit případný výčet a možnost logy normálně použít pro řešení.

Tak blby uzivatel si muze nainstalovat Plymouth, nastavit tak, ze se mu tam budou ukazovat akorat nejake nic nerikajici ikonky nebo progress bar nebo co to ted frci a ma hlasky skryte a i bez Poetteringa. Uzivatel, ktery si nezaklada na podobnych picovinach, si necha po obrazovce rolovat hlasky, aby se o systemu dozvedel vic, nez pri bootu Widli, ktere leda tak vytuhnou s hlaskou, ze se *neco* posralo.

> Jinak na obrazovku patří hlášky jenom pokud neběží logovací služba. To už je ale zřejmě moc na pochopení.

Nevím, kdo o tom rozhodl, že "nepatří". Nějaká komise? :)

Mně se třeba jednou stala taková prima věc: nabíhá Linux se systemd, splashscreen vypnutý, objevují se hlášky o startování jednotlivých služeb a v tom jedna z těch služeb nestartuje - motá se u ní takový to motadlo. Hláška samozřejmě žádná - je někde v tom slavném binárním logu. Nevím, co se děje. Mám počkat ještě pět minut? Půl hodiny? Hodinu? Není to nějaká chyba v systemd, takže to takhle sůstane viset na věky a na spuštění loginu vůbec nedojde? Zobrazí se mi po půl hodině hláška "Jejda! Něco se pokazilo"? Nebo "Došlo k chybě. Kód chyby: NO ERROR"? Objeví se okýnko "Zavolejte administrátora"?

> Vyskočí mi 10 řádků výpisu nějaké části co měla směřovat do logu - čas - nějaké hodnoty, věty .... a za 10 vteřin je to fuč. A co teď jako s tím?

Ale ty hlášky přece směřují do logu - ale zároveň se vypisují do konsole. Pokud je to za 10s pryč, tak je to dobře, protože to znamená, že systém naběhl a můžu si to v logu přečíst. Horší je opačný scénář - systém nenaběhne, čili z logu si to přečíst nemůžu a na obrazovce si to nepřečtu, protože to tam "nemá být".

> Nebo klasika "Waiting for network confi ..... 60 sec ...." a čeká ..... A co jako s tím? Jak mi to pomohlo?

No velice zásadně - vím, že to nenabíhá kvůli konektivitě. Čili buď tu konektivitu umím hned napravit (např. zastrčit vytažený kabel), anebo u nejklasičtějších initů umím využít i toho, že ten skript běží na popředí - čili stačí zmáčknout klasické CTRL+C a jede se dál bez čekání. Systemd (a ostatní systémy pro paralelní spouštění) už tohle neumožňují - procesy běží kdesi na pozadí a dostat se k nim dá jenom přes nějaké spešl API - úplně přesně jako na Windows, se všemi souvisejícími nepříjemnostmi.

> Prosím nedělejte z Nás obou blby, Kód chyby: NO ERROR je volovina, takové nicneříkající nic je k ničemu ale dají se dávat i normální error kódy

To byl samozřejmě nejapný vtip: je to typická hláška z Windows. Tak daleko snad zwindowsovatění Linuxu ještě nedošlo ;)

No, bud ad, ze to aspon probliklo. Aspon vis, ze mas lezt do logu. Na Widlich nic neproblikne a v logu se stejne obvykle nedoctes nic relevantniho a pokud doctes, tak k tomu v polovine pripadu nenajdes zadny rozumny vyklad.

...neobhajuji systemd, nevím jestli je lepší než init nebo něco jiného...

Systemd nemuze byt lepsi, nez jiny init a to uz proto, ze ho napal dement s tak arogantni drzkou a pristupem k uzivatelum.

To už jsme řešili nedávno pod jiným článkem/zprávičkou. V Debianu taky stačí "sudo apt-get purge plymouth plymouth-theme" a je vystraráno. U Ubuntu to sebou vezme tuším celý/většinu desktop(u) :). Vzhledem k té změně závislostí Debian vs Ubuntu to určitě není chyba, ale záměr :-). Výběr distribuce je každého jeho vlastní rozhodnutí a problém...

Ono je potřeba si k tomu přečíst i ten první sloupeček. To, že systemd pracuje se soubory ve formátu Unit File, a když mu předhodíte nějaký jiný formát, nebude s ním sám od sebe umět pracovat, je logické. To je jako byste vytýkali Perlu, že si neporadí se skriptem napsaným v Pythonu.

Chtěl jsem jenom upozornit na to, že kdyby to s tím API bylo tak růžové, tak by systemd nikoho nevzrušoval. Kromě sloupečku 1 je taky spolupeček 7, kde je vidět, že komponenty, které by snad měly být reimplementova­telné, nikdo neimplementoval. Asi z nějakého důvodu.

Existence API totiž sama o sobě nic neslibuje. Důležité je hlavně, jak je to API stabilní (to se snad poslední dobou zlepšilo a existuje i nějaký slib stability aspoň něčeho) a hlavně jestli je to API obecné nebo reflektuje designované volby implementátora (takže ho sice reimplementovat můžu, ale musel bych defacto napsat ten stejný kód, což by mi nijak nepomohlo). A tady u toho druhého bodu si nejsem moc jistý. Kdyby to totiž bylo tak růžové, neměli by vývojáři *BSD a Gentoo takové vrásky na čele...

-systemd code too co-dependent on other systemd libraries/com­ponents
-can't port/recreate any low-level functionality
-horrible idea anyway
http://darknedgy.net/files/systembsd.pdf

Chtěl jsem jenom upozornit na to, že kdyby to s tím API bylo tak růžové, tak by systemd nikoho nevzrušoval.
Tohle vůbec není pravda. To, co na tom nejvíce vadí, je to, že je to nové, poukazuje to na chyby v tom starém, je moderní na to nadávat, a stojí za tím kontroverzní autor. Až na ten poslední bod je to úplně stejné, jako nadávky třeba na IPv6 nebo btrfs. No a někde v koutku vedle těchhle hlasitých odmítačů jsou pak ti, kteří tiše věcně kritizují věci, které jsou na systemd (IPv6, btrfs) opravdu nešťastně řešené, nedotažené apod.

Stabilita a obecnost API je sice hezká věc, ale hrozí, že bude nějaká komise nejprve několik let navrhovat obecné stabilní API, aby se pak ukázalo, že to v praxi nevyhovuje. API podle potřeb konkrétního projektu má tu výhodu, že jsou hned vidět výsledky a to API se dá prakticky používat.

Ona je to s tím API totiž taková výmluva. Až tu bude nějaký projekt, který to API využívá, a kvůli změně v API systemd přestane ten projekt fungovat, pak bude možné tvrdit, že je chyba v nestabilitě API systemd.

Primární problém je totiž v tom, že původní správa služeb přes SysVinit a skripty byla tak zastaralá a zatuhlá, že udělat to dnes pořádně znamená implementovat spoustu nové funkcionality. Takže kdyby chtěl někdo reálně konkurovat systemd, musel by toho také sám spoustu implementovat – a do toho se nikomu nechce.

Po té nové funkcionalitě byla evidentně velká poptávka, proto najednou na systemd závisí tolik věcí. Což není důkaz rozpínavosti systemd, jak to někteří interpretují – protože systemd nemá žádné prostředky, jak donutit programátory nebo správce distribucí, aby na něm začali záviset.

Nikomu nic nebrání vytvořit svůj software, který bude nabízet lepší služby, než systemd. Nikomu nic nebrání vytvořit stabilní a obecné API, do kterého systemd zabalí. Celý problém systemd je v tom, že nikdo nevytvořil nic lepšího. Kdyby vytvořil, vývojáři i distribuce na to s radostí přejdou, a autorům systemd nezbyde, než implementovat to stabilní a obecné API toho lepšího systému.

> To, co na tom nejvíce vadí, je to, že je to nové, [...]

Asi jak kde. V *BSD světě na tom lidem vadí, že je to by-design Linux-only a že aplikace na tom začínají záviset. Čili *BSD se dostává do situace, kdy si může vybrat buď GNOME úplně zaříznout (nikdy už na BSD nebude) nebo reimplementovat systemd. Obojí je opruz. A nejhorší na tom je, že úplně zbytečný.

> ale hrozí, že bude nějaká komise nejprve několik let navrhovat [...]

Pokud je funcionalita jednoduchá, jasná a obecná, tak nevím, co by na tom komise řešila. Co je ta bájná funkcionalita? V principu jenom nastavit nějaké parametry systému (locale, hostname apod.), spustit a monitorovat služby apod. Není na tom nic světoborného, co by potřebovalo API o stovkách položek.

> Primární problém je totiž v tom, že původní správa služeb přes SysVinit a skripty byla tak zastaralá a zatuhlá

Opakuju: mnoho let existuje OpenRC, launchd, SMF, supervisord ... těch alternativ je spoustu. Není to "hnusné initskripty" nebo systemd. To je strawman.

> Po té nové funkcionalitě byla evidentně velká poptávka

Konkrétně prosím! Po jaké funkcionalitě? Nemám systemd kdovíjak nastudované, ale ještě jsem neslyšel o ničem, co by řešil a nedalo se to udělat jinak.

> protože systemd nemá žádné prostředky, jak donutit programátory nebo správce distribucí, aby na něm začali záviset. [...] Nikomu nic nebrání vytvořit svůj software, který bude nabízet lepší služby, než systemd

Jistě. To je stejně validní argument jako "nic nenutí lidi používat Windows". Pěkně silné "nic"...

> To je strawman.

Nebo spíš falešné dilema.

> bez Lennarta a podobných průkopníků bysme ještě lezle po stromech. :-P

Mně osobně je Lennart ukradenej, jeho chování a spory s některými developery jsou pro mě jenom takové vtipné historky z natáčení - Linux používám minimálně, kde můžu, mám FreeBSD. Rozlaďuje mě spíš to, že dokud byl linuxový svět malinký pidižvýček oproti drtivě majoritním Windows, mluvilo se o spolupráci, standardizaci, otevřenosti, přenositelnosti - a teď najednou, když se Linux rozšířil všudemožně (kromě desktopu), tak najednou vlastně standardy nejsou důležité, jde o vytvoření "moderní post-unixové platformy" a ostatní unixoidní systémy ať si trhnou nohou (nebo reimplementují řešení, která si vymyslíme my).

Prostě Linux jako celek (jo, vám, že to je nekorektní) se bohužel posunuje k chování, které bylo dřív typické pro Windows - systém kompatibilní jenom sám se sebou, totálně ignorující okolí. Navíc těch podobností je čímdál víc i v technické rovině (binární formáty, automagická řešení, do kterých nikdo nevidí, neproniknutelné závislosti,... už zbývá jenom řešení problémů reinstalací :( ).

Jak byste si to představoval jinak? Máme na Linuxu solidárně dál používat nevyhovující správce služeb z minulého století, protože v *BSD nejsou schopni naimplementovat funkcionalitu, kterou moderní správce služeb potřebuje? Není lepší to implementovat alespoň pro Linux, vyzkoušet a ověřit, a až bude existovat nějaké stabilní řešení, můžou si to lidé z *BSD portovat k sobě? Ano, nevýhoda je, že po něčem, co řeší systemd, byla evidentně velká poptávka, takže se masově nasazuje už v době, kdy ještě není stabilní a portace by byla komplikovanější. No jo, ale to je problém toho, že tu poptávku neuspokojil nikdo před systemd. Přitom tu možnost měl každý.

> Jak byste si to představoval jinak? Máme na Linuxu solidárně dál používat nevyhovující správce služeb z minulého století

Prosím o konkrétní vyjmenování, v čem jsou alternativy systemd nevyhovující. Se zřetelem k launchd, SMF a klidně i init skriptům FreeBSD.

> protože v *BSD nejsou schopni naimplementovat funkcionalitu, kterou moderní správce služeb potřebuje?

Jakou funkcionalitu? Třeba cgroups? Vývojáři BSD nejsou schopní BSD udělat tak, aby bylo přesně stejné jako Linux? Vývojáři BSD jsou pitomci, protože nechtějí mít systemd jenom kvůli tomu, aby fungovalo Gnome? WTF?! OSS už není o možnosti volby, ale o tom, že kdo nepřijde systemd, ten je pitomec?!

> Není lepší to implementovat alespoň pro Linux, vyzkoušet a ověřit, a až bude existovat nějaké stabilní řešení, můžou si to lidé z *BSD portovat k sobě?

Systemd nikdy portovat nepůjde, protože je neportovatelný by design. To je ta pointa.

> po něčem, co řeší systemd, byla evidentně velká poptávka

Pořád jsem ještě neslyšel konkrétně po čem. Je to fakt tak těžké vyjmenovat?

> No jo, ale to je problém toho, že tu poptávku neuspokojil nikdo před systemd. Přitom tu možnost měl každý.

Windows se asi taky rozšířily kvůli nějaké poptávce. Nikdo jiný ji neuspokojil. Přitom tu možnost měl každý. Tak jo no...

Vývojáři BSD nejsou schopní BSD udělat tak, aby bylo přesně stejné jako Linux?
Kde jsem psal, že se to má udělat „přesně stejně“? Ať si to vývojáři *BSD udělají, jak chtějí, klidně ať upraví systemd tak, aby fungoval i bez podobné služby. Kdo by to měl udělat jiný?

Vývojáři BSD jsou pitomci, protože nechtějí mít systemd jenom kvůli tomu, aby fungovalo Gnome?
Vývojáři BSD jsou pitomci, pokud nechápou, že když nechtějí mít systemd, musí Gnome opatchovat tak, aby fungovalo i bez systemd, nebo musí služby, které Gnome poskytuje systemd, implementovat sami. Ale já si myslím, že vývojáři BSD to chápou, že to nechápou jenom někteří diskutující.

Systemd nikdy portovat nepůjde, protože je neportovatelný by design.
To je zvláštní, že se běžně portují programy z Unixů do Windows a opačně, u kterých s portací původně nikdo nepočítal, a jde to. Co je na systemd tak specifického, že je neportovatelný by design?

Pořád jsem ještě neslyšel konkrétně po čem. Je to fakt tak těžké vyjmenovat?
Já netuším, po čem všem ta poptávka je. Ale jak už jsem psal, předpokládám, že když nějaký vývojář zatáhne do svého programu závislost na systemd, má k tomu dobrý důvod. Nebo vy si myslíte, že to vývojáři dělají jen tak z rozmaru, nebo aby něčím naštvali Mirka Prýmka?

Windows se asi taky rozšířily kvůli nějaké poptávce. Nikdo jiný ji neuspokojil. Přitom tu možnost měl každý. Tak jo no...
Před nástupem Windows měl tu možnost každý.

Pořád píšete, jakoby do Gnome tu závislost na systemd nepřidali vývojáři dobrovolně, jako by je k tomu někdo ze systemd donutil. Ale ani jednou jste nenapsal, jak je k tomu donutili, jaké mají vývojáři systemd páky na vývojáře Gnome.

> To je zvláštní, že se běžně portují programy z Unixů do Windows a opačně, u kterých s portací původně nikdo nepočítal, a jde to. Co je na systemd tak specifického, že je neportovatelný by design?

To je vtip? Budeme srovnávat portovatelnost init systému, úzce provázaného s kernelem, s nějakou aplikací, která interaguje jenom s knihovnami?!

> Já netuším, po čem všem ta poptávka je.

Ok. Tak s tím přestaň operovat.

> Ale jak už jsem psal, předpokládám, že když nějaký vývojář zatáhne do svého programu závislost na systemd, má k tomu dobrý důvod.

Jasně. A ten důvod může být třeba ten, že většina dister na systemd přešlo a cokoli jiného je mu u prdele.

> Nebo vy si myslíte, že to vývojáři dělají jen tak z rozmaru, nebo aby něčím naštvali Mirka Prýmka?

Mě tím rozhodně nenaštvou. Gnome nepoužívám a kdyby na BSD nebylo, je mi to úplně jedno. Ale je mi líto, že se z linuxové komunity - s jasným zaviněním konkrétních jedinců - stávají fanoušci jednoho konkrétního systému a na spolupráci kašlou.

> Pořád píšete, jakoby do Gnome tu závislost na systemd nepřidali vývojáři dobrovolně, jako by je k tomu někdo ze systemd donutil. Ale ani jednou jste nenapsal, jak je k tomu donutili, jaké mají vývojáři systemd páky na vývojáře Gnome.

A uživatele Windows někdo "donutil" používat Windows? Stál jim za zády s bouchačkou? Ne. Windows se prostě rozšířily a staly se monopolem, protože nebyly s ničím kompatibilní a způsobily lock in. Něco velmi podobného se může stát s linuxovým světem - stačí si představit, že podobně jako Gnome by se zachovali vývojáři různého jiného serverového sw. A juchů, Linux by byl monopolní serverový systém. Protože OSS je přece o svobodě volby...

Budeme srovnávat portovatelnost init systému, úzce provázaného s kernelem, s nějakou aplikací, která interaguje jenom s knihovnami?!
Systemd není úzce svázán s kernelem, pouze vyžaduje určité služby od jádra operačního systému. Což je úplně stejné, jako ty „nějaké aplikace, které interagují jenom s knihovnami“ – některé ty knihovny totiž tvoří pouze rozhraní k jádru operačního systému. Pokud dnes systemd používá některé služby, které jsou specifické pro Linux, není problém okolo těch služeb udělat obecnou knihovnu, systemd přepojit na tu knihovnu, a třeba na *BSD tu knihovnu implementovat jiným způsobem, s prostředky příslušného jádra. Nebo je možné nepoužívat příslušnou část systemd, která je na té službě linuxového jádra závislá. A nebo třetí možnost, fňukat, že my to chcem taky, ale nikdo to za nás neudělá, což je hrozně nespravedlivé.

Tak s tím přestaň operovat.
Myslíte, že když o té poptávce nebudeme psát, tak zmizí? Pokud k tomu takhle přistupujete, že když je někde nějaká poptávka, vy se tváříte, že ji nevidíte a že tím pádem neexistuje, nesmíte se pak divit, že přijde nějaké systemd, netváří se, že tu poptávku nevidí,a zareaguje na ní.

A ten důvod může být třeba ten, že většina dister na systemd přešlo a cokoli jiného je mu u prdele.
Jo, takže vývojář si tak se dí u počítače, a říká si: „Já systemd vůbec nepotřebuju. Ale většina distribucí na něj přešla, tak já schválně do aplikace tu závislost na systemd přidám. Sice mi to nic nepřinese, budu s tím mít akorát práci, ale naštvu tím Prýmka, a top je to hlavní!“

na spolupráci kašlou
Pěkně prosím, jak byste si takovou spolupráci představoval? To jako že linuxový komunita vyčlení pár dobrovolníků, kteří budou portovat věci z Linuxu do *BSD?

Windows se prostě rozšířily
Pokud vím, bylo to trochu jinak, než že se „prostě rozšířily“.

staly se monopolem, protože nebyly s ničím kompatibilní a způsobily lock in.
Jenže ta nekompatibilita a lock in byl záměr a Microsoft se alternativám aktivně bránil. Pamatujete války o souborové formáty kancelářských balíků? Nikdo tenkrát nechtěl, aby Microsoft naprogramoval Office pro Linux – chtěli jsme jenom znát specifikace souborových formátů, abychom si kompatibilní software mohli napsat sami. A i tomu se Microsoft bránil.

Brání snad někdo zveřejnění API systemd? Nebrání, jak také, když je systemd open source. No, ale psát alternativy k systemd opravdu není úlohou vývojářů systemd, stejně jako není úlohou linuxové komunity portovat software na *BSD. Stejně jako jsme nikdy nechtěli, aby Microsoft portoval Office na Linux.

stačí si představit, že podobně jako Gnome by se zachovali vývojáři různého jiného serverového sw. A juchů, Linux by byl monopolní serverový systém.
Ale nebyla by to chyba lidí od linuxu, ale těch, kteří nenapsali alternativy, přestože jim v tom nikdo nebránil.

Protože OSS je přece o svobodě volby...
No právě. OSS je o svobodě volby. Takže když se jako vývojář rozhodnu, že mi systemd přináší nějaké výhody a vyplatí se mi udělat na něm můj program závislým, je to moje svobodná volba. A někdo jiný má zase svobodnou volbu napsat alternativu k systemd se stejným rozhraním, nebo dokonce napsat něco lepšího než systemd, co povede k tomu, že opustím závislost na systemd a přejdu na to nové. A nebo tu mou aplikaci upraví tak, aby fungovala i bez systemd, jenom nebude poskytovat ty služby, ke kterým využívá systemd. To všechno je svoboda volby.

Vaše představa je asi taková, že by vývojáři systemd měli povinně naprogramovat minimálně dvě alternativy k systemd, a to navíc i pro všechny odnože BSD. V tom já ale žádnou svobodu volby nevidím.

> Systemd není úzce svázán s kernelem

Tak jo no...

> Myslíte, že když o té poptávce nebudeme psát, tak zmizí?

Ne. Myslím, že když něco neumíte konkrétně vyjmenovat, tak byste neměl šermovat s tím, že to na obecné rovině zcela určitě existuje protože a poněvadž pakliže proto.

> No, ale psát alternativy k systemd opravdu není úlohou vývojářů systemd, stejně jako není úlohou linuxové komunity portovat software na *BSD.

To jsem ani nechtěl. Nebudu to vysvětlovat znova, můžete si to přečíst znovu a pozorněji výš. Jestli něčemu na tom výš řečeném nerozumíte, zeptejte se, třeba jsem se vyjádřil nejasně. Ale opakovat se nebudu.

> A někdo jiný má zase svobodnou volbu napsat alternativu k systemd se stejným rozhraním

Problém je, že vy si to představujete jako hurvínek válku. Chápete to, že *BSD je prostě jiný kernel? Že má úplně jiné vlastnosti? Že nejde jenom tak snadno napsat nejakou mezivrstvu emulující chování Linuxu? A že je to úplně zbytečná práce, protože systemd nepřináší nic tak zásadního, aby to nešlo bez toho.

> Vaše představa je asi taková, že by vývojáři systemd měli povinně naprogramovat minimálně dvě alternativy k systemd, a to navíc i pro všechny odnože BSD.

Ne. Vývojáři systemd si můžou dělat co chtějí. Můžou si do systemd integrovat klidně i Xka (btw, provázání s Waylandem je určitě na spadnutí). Vy to můžete klidně obhajovat. Linus může klidně říct, že k tomu nemá žádný strong opinion. Dělejte si všichni co chcete, jste svobodní lidé.

Ale já si s dovolením vyhrazuji právo říct, že Linux windowsovatí a že je mi to líto. To je vše. A taky si dovolím vás poprosit, abyste mi nevkládal do úst svoje interpretace.

Ne. Myslím, že když něco neumíte konkrétně vyjmenovat, tak byste neměl šermovat s tím, že to na obecné rovině zcela určitě existuje protože a poněvadž pakliže proto.
Geniální. Tvrdíte, že existuje ČR? Dobře, tak vyjmenujte její obyvatele.

Chápete to, že *BSD je prostě jiný kernel? Že má úplně jiné vlastnosti? Že nejde jenom tak snadno napsat nejakou mezivrstvu emulující chování Linuxu?
Já to chápu. Ale nechápu, jaké vy navrhujete řešení. Linux má nějaké vlastnosti, které se hodí autorům určitého programu. Napadají mne jenom následující možnosti:

Autoři toho programu používají Linux, tak tu vlastnost použijí. Pokud bude někdo chtít použít daný program pod *BSD, bude muset příslušnou funkcionalitu implementovat s prostředky *BSD.

Nebo autoři Linuxu danou vlastnost vůbec neimplementují, protože ji nemá *BSD, a kdyby to někdo použil, byl by jeho program závislý na Linuxu.

Nebo autoři danou vlastnost implementují do Linuxu, ale zároveň ji povinně implementují i do *BSD, aby použití té vlastnosti neznamenalo závislost na Linuxu. Možná by to měli implementovat i do Windows?

Nebo autoři danou věc v Linuxu implementují, ale nikdo to nebude používat, aby nevznikla závislost na Linuxu.

Která varianta je podle vás správná?

Samozřejmě to platí i opačně, některé věci jsou implementované v některém z *BSD a nejsou v Linuxu, případně se jimi Linux dodatečně inspiruje. Nikdy jsem neslyšel, že by to *BSD někdo vytýkal.

A že je to úplně zbytečná práce, protože systemd nepřináší nic tak zásadního, aby to nešlo bez toho.
Vůbec nejlepší by bylo zůstat u děrných štítků. Terminály, klávesnice, dokonce grafická prostředí a myš nepřinášejí nic tak zásadního, aby to nešlo bez nich… Systemd evidentně něco přináší, když to lidé chtějí používat. Vaše neustálé fňukání, ať to vylepšení přestanou používat, protože když ho nemáte vy, nemá ho mít nikdo, je dětinské. Navíc, když to není tak zásadní, tak to přece půjde snadno obejít nebo implementovat jinak.

Ale já si s dovolením vyhrazuji právo říct, že Linux windowsovatí a že je mi to líto.
Takže přidání nové vlastnosti je windowsovatění. OK.

A taky si dovolím vás poprosit, abyste mi nevkládal do úst svoje interpretace.
Když ono je těžké vás pochopit, když pořád kroužíte kolem toho, že vám vadí, že Linux má nějakou vlastnost, kterou *BSD nemá, a považujete to za chybu linuxové komunity – ale přímo to napsat nechcete.

> Pokud vím, adekvátní ucelená náhrada k funkcím logind neexistuje.

Jaké konkrétně Gnome získal funkce tím, že začal systemd používat? Co přesně umí teď, co předtím neuměl? A to nešlo tu funkcionalitu udělat jako volitelnou?

Netvrdím, že takové věci neexistují, ale nebaví mě šermování něčím, co asi teda možná existuje, nevím, co to je, ale určitě něco jo a proto je potřeba systemd a žádná jiná alternativa není.

No a jsme u jádra pudla: přenositelný ConsoleKit (Linux, BSD, Solaris) byl nahrazen Linux-only systemd.

P.S. AFAIK to není "jejich [GNOME] vlastní" ConsoleKit. Je to prostě nezávislý projekt ConsoleKit.

No a jsme u jádra pudla: přenositelný ConsoleKit (Linux, BSD, Solaris) byl nahrazen Linux-only systemd.
No a jsme u jádra pudla. Já si myslím, že ta náhrada vyžadovala nějaké úsilí, a že ji tedy vývojáři provedli proto, že jim systemd oproti ConsoleKitu přinese nějaké výhody.

Od vás jsem se zatím nedozvěděl, jak měli ty samé výhody se stejným množstvím práce získat jinak.

> ale zase se můžou soustředit na vývoj jiných věcí, takže ve výsledku je to pro uživatele (smířené se systemd) výhra.

Jasně, však to je legitimní, můžou si dělat co chtějí.

Je to stejně legitimní jako proprietární autentizace ve Windows - pro lidi, kteří mají windows a jsou s nimi smíření, je to určitě úplně bezva. A vývojáři v Microsoftu se aspoň nemusí zabývat implementací něčeho přenositelného/kom­patibilního, takže pro uživatele je to jasná výhra.

Vůbec z Windows je ještě hodně čím se inspirovat. Vložit grafický subsystém do jádra, nebo aspoň do PID 1 by bylo určitě super, spoustu věcí by to zjednodušilo a zrychlilo, takže pro uživatele taky jednoznačně výhra.

Jo a taky myslím Lael říkal, že COM je daleko vyspělejší než DBUS. Možná by se na něj dalo přejít. Všichni správci linuxů se už těší na hlášky

Systém událostí modelu COM+ nemohl vytvořit instanci odběratele partition:{41E90F3E-56C1-4633-81C3-6E8BAC8BDD70}­!new:{6295DF2D-35EE-11D1-8707-00C04FD93327}. CoGetObject vrátil hodnotu HRESULT 8000401A.

:)

Je tu takový drobný rozdíl. Ve Windows si tu proprietární autentizaci nijak nezměníte. V případě Gnome a systemd vám nic nebrání napsat ještě lepší implementaci a portovat na ni Gnome. Dokonce pokud bude o tolik lepší, jako byl systemd oproti předchůdcům, portují na to Gnome jeho vývojáři sami, jak se ukázalo v případě systemd.

Však jo, já nic z toho nezpochybňuju. Linux se klidně může úplně vykašlat třeba i na POSIX a začít fungovat úplně jinak, post-unixově. Bude to úplně nový, jiný systém, který už nebude mít s unixem nic společného. Proč ne? Pokud takový systém bude chtít někdo vyvíjet a někdo používat, je všechno naprosto v pořádku.

Jenom nevím, proč by si lidi, kteří měli Linux rádi kvůli jeho unixovosti a kompatibilitě, nemohli postesknout po starých dobrých časech. Tak nám to dopřej, ne? :)

Poptávku už jsem dávno konkretizoval. Jsou to všechny ty kritizované přidané závislosti na systemd. Závislost na systemd přidají do své aplikace vývojáři právě proto, že systemd řeší něco, co vyřešit potřebují.

Dovolím si zpochybnit pravdivost tvého tvrzení. Zcela a úplně.

Ne. Myslím, že když něco neumíte konkrétně vyjmenovat, tak byste neměl šermovat s tím, že to na obecné rovině zcela určitě existuje protože a poněvadž pakliže proto.
Geniální. Tvrdíte, že existuje ČR? Dobře, tak vyjmenujte její obyvatele.

WTF?
Ty vole, ta tvoje "argumentace", to je k zblití.

A nejhorší na tom je, že úplně zbytečný.
Podle vás autoři třeba Gnome jen tak z rozmaru přepisují stávající kód, aby byl závislý na systemd? Nebude to spíš tak, že jim systemd poskytuje nějaké služby, které by jinak museli pracně implementovat, nebo na ně rezignovat – zatímco takhle jednoduše využijí systemd, a sami se mohou věnovat něčemu jinému?

Závislost na Linuxu je problém, ale asi to není problém, který by měli řešit primárně uživatelé systemd na Linuxu. A ta závislost není by-design – když bude *BSD implementovat služby, které systemd potřebuje, jistě nikdo nebude bránit portaci systemd na *BSD.

V principu jenom nastavit nějaké parametry systému (locale, hostname apod.), spustit a monitorovat služby apod.
To, co odlišuje systemd od správců služeb založených na SysVInitu a skriptech je mimo jiné schopnost průběžně reagovat na různé události. Takže nestačí jen služby spustit a monitorovat, ale také jim poskytnout prostředí, ve kterém mezi sebou mohou nějak komunikovat.

Opakuju: mnoho let existuje OpenRC, launchd, SMF, supervisord ... těch alternativ je spoustu. Není to "hnusné initskripty" nebo systemd.
Jenže ty alternativy nebyly dostatečné, pořád se snažily tvářit, že je to vlastně SysVinit + skripty (a třeba takové OpenRC pořád je SysVInit + skripty). Autoři systemd se rozhodli zahodit zpětnou kompatibilitu a udělat to znovu a tak, jak odpovídá roku 2016. Nikomu nic nebránilo udělat to před systemd, mohlo se dnes úplně stejně nadávat třeba na launchd.

ještě jsem neslyšel o ničem, co by řešil a nedalo se to udělat jinak
Systemd není žádný zázračný software s nadpozemskými schopnostmi. Vše, co dělá systemd, se samozřejmě dá udělat i jinak. Akorát to zatím nikdo jinak takhle komplexně neudělal. Samozřejmě je spousta projektů, které řeší část věcí z toho, co řeší projekt systemd. Ale zatím z nich nikdo tu alternativu systemd neposkládal.

To je stejně validní argument jako "nic nenutí lidi používat Windows". Pěkně silné "nic"...
To teda není stejně validní argument. K používání Windows nutí lidi to, že je všichni znají, je vydáván software nebo ovladače jen pro Windows. Když vám partner poskytuje data v proprietárním datovém formátu nějakého programu, který je jen pro Windows, můžete s ním buď přestat komunikovat, nebo používat Windows.

Systemd je něco úplně jiného. To, že nějaký jiný program používá systemd, vás jako programátora přece vůbec nenutí použít systemd ve svém programu. Když váš program nějak fungoval před příchodem systemd, bude úplně stejně fungovat i na systému, kde systemd běží, i když váš program bude systemd dál ignorovat. Takže autory programů opravdu vůbec nic nenutí vytvářet závislost na systemd. Když ale tu závislost dobrovolně vytvoří, musí pro ně systemd představovat nějakou výhodu. Zvlášť když každý programátor přidává nerad závislosti na cizích projektech a každý je v pokušení, že by si to napsal sám a určitě líp. A přesto programátoři tu závislost na systemd přidají.

Tvůrci distribucí jsou na tom o něco hůř. Pokud mají nějaký program, jehož autor přidal závislost na systemd, mohou tu část funkcionality odstranit, mohou začít používat systemd, nebo mohou to, co poskytuje systemd, poskytnout danému programu jinými prostředky.

Jenže odpůrci systemd na něj akorát nadávají, ale že by napsali něco lepšího, to ne. Přitom je to podle nich tak snadné. A autoři po tom rádi skočí, když sáhli o po tom „hrozném“ systemd. Takže jediné, co brání vytvoření lepší alternativy systemd, je to, že když se chtějí odpůrci systemd přepnout do programátorského editoru a začít kódovat, vždy jim to nějak ujede a najednou píšou nenávistný komentář do diskuse. A určitě za to může systemd.

> Závislost na Linuxu je problém, ale asi to není problém, který by měli řešit primárně uživatelé systemd na Linuxu. A ta závislost není by-design – když bude *BSD implementovat služby, které systemd potřebuje, jistě nikdo nebude bránit portaci systemd na *BSD.

Hm.

Závislost na Windows je problém, ale asi to není problém, který by měli řešit primárně uživatelé Windows. A ta závislost není by-design – když bude Linux implementovat služby, které Windows aplikace potřebují, jistě nikdo nebude bránit portaci aplikací na Linux.

Jinak zbytek už komentovat nebudu, jenom bych opakoval tohle: http://judecnelson.blogspot.cz/2014/09/systemd-biggest-fallacies.html

Ano, přesně takhle to při portaci Windows aplikací na Linux bylo. To opravdu neřešili uživatelé Windows, ale ti, kdo aplikaci chtěli používat na Linuxu. Museli nahradit to, co bylo specifické pro Windows, něčím, co poskytoval Linux, nebo danou část aplikace oželet, a nebo danou službu implementovat pro Linux.

A přesně proto se z Linuxu stalo to, čím byly Windows pro Linux - systém, který myslí jenom na sebe a ostatní je mu u prdele. Samozřejmě na to má kdokoli právo, ale neměl by se divit, že se to lidem, kteří pamatují když byl Linux ve stejné roli, nelíbí.

Jj. A z toho vlákna hlavně tohle (včetně těch citací shora):

https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00447.html

Kde se tam píše o tom, že tu závislost přidávají jen tak z rozmaru? Navíc pokud by byla přidána jen tak pro nic za nic, nebyl by žádný problém ji pro BSD zase odpárat. Jenže ona se ta závislost nepřidává jen tak z rozmaru, ale proto, že poskytuje nějaké služby, které Gnome skutečně využije. Takže to nejde jen tak odpárat. ale je potřeba ty služby něčím nahradit. Jenže to by tu náhradu někdo musel naprogramovat. A do toho se nikomu nechce, je snazší místo toho fňukat v diskusi, že když mi tyhle služby nemáme, neměl by je mít ani Linux, protože jinak je to od něj nekolegiální.

> Navíc pokud by byla přidána jen tak pro nic za nic, nebyl by žádný problém ji pro BSD zase odpárat.

Jistě. Protože lidi nemají nic jiného napráci než synchronizovat nekompatibilní codebase takového molochu jako je Gnome. Super nápad! :)

> A do toho se nikomu nechce, je snazší místo toho fňukat v diskusi, že když mi tyhle služby nemáme, neměl by je mít ani Linux, protože jinak je to od něj nekolegiální.

Jenže takhle to není. Věci jdou dělat se zřetelem na portabilitu a bez zřetelu na portabilitu. Někoho to prostě zajímá, někoho to nezajímá.

Podívejte se třeba na nosh - init systém, který z těch podstatných věcí dělá asi všechno co systemd. A s portabilitou nemá problém. Poettering jde ale záměrně cestou "všichni kdo nejste mainstream, polibte mi prdel."

No vidíte. Takže nad nosh triviálně uděláte API kompatibilní se systemd, a máte vystaráno.

Protože lidi nemají nic jiného napráci než synchronizovat nekompatibilní codebase takového molochu jako je Gnome
Takže podle vás mají raději plýtvat časem na tom, že budou znovu implementovat to, co už je implementováno v systemd?

"že budou znovu implementovat to, co už je implementováno v systemd?"
- a je?

Teda povim ti, ta tvá demagogie je vysloveně učebnicová.

systemd není hotové, řeší problémy, které mělo sysv, a má problémy, které sysv nemělo. Takže proč bychom jako měli kejvnout na tvůj dojem, že to, že je v systemd už něco implementováno má nějakou váhu?

Nejde o můj dojem. Jde o dojem všech těch vývojářů, kteří do svých aplikací závislost na systemd přidávají. Zatím nikdo zde v diskusi nepřišel s lepším vysvětlením, než je to pro ty vývojáře výhodné.

Ale v tom není sporu, že je to pro ně výhodné. Pro Microsoft je taky výhodné používat telnet s NTLM autentizací místo ssh.

Ne, můj software se v takovém případě nemusí stát závislým na systemd. Nanejvýš můžu přidat unit file, to je ale pouze přidání jednoho textového souboru do distribuce, žádná závislost tím nevzniká. A i kdybych ten unit file nepřidal, správce distribučního balíčku si ho snadno vyrobí sám, takže kdybych chtěl systemd jako autor toho software úplně ignorovat, klidně to můžu udělat, a můj software stejně v Debianu zůstane.

Takže tímhle způsobem závislost aplikace na systemd určitě nevzniká. Ale oceňuji, že jste se to alespoň pokusil nějak vysvětlit.

Asi ne, protože Gnome prý závisí na službách systemd. O tom se tady celou dobu bavíme, jestli existuje nějaké lepší vysvětlení, proč autoři do kódu Gnome přidali závislost na systemd, než to, že jim to přináší nějaké výhody.

Vytvoření unit souboru závislost na systemd nevytváří. To, že systemd používá nějaký jiný projekt, také závislost nevytváří, a není to důvod, proč přidávat tu závislost do svého projektu.

Myslíte, že když nechápete, co znamená v software „závislost“, že to lépe pochopíte, když budete psát tučně?

Protože chtěli být na systemd distrech
Systemd distribuce je předpokládám distribuce, která jako init systém používá ve výchozím nastavení systemd. V takové distribuci budou samozřejmě fungovat i aplikace, které na systemd žádnou závislost nemají. Třeba bash, vim, Firefox a tisíce dalších programů na systemd žádnou závislost nemají, přesto v „systemd distribucích“ fungují.

A nepodporovat systemd znamená asi jako na mobilech nepodporovat android
Ne, neznamená. Aplikace, která nepodporuje systemd, bude na systému se systemd fungovat úplně stejně, jako na systému, kde systemd není.

Ale aby jsme se netočili v kruhu a rozlouskli jsme to hned
Nejdřív musíte pochopit, že „podporovat systemd“ a „záviset na systemd“ jsou dvě různé věci, a to, že kdyžje v distribuci systemd, v žádném případě to neznamená, že v té distribuci může být jen software, který je na systemd závislý. Klidně v ní může být dál software, který o systemd vůbec nic netuší.

Ostatně ono stačí pochopit obecný význam slova „závislost“ – když budete mít v kuchyňce kafe („kafe kuchyňka“), neznamená to, že od té chvíle budou moci v kuchyňce vařit jenom ti, kteří jsou na kafi závislí. Klidně tam mohou být i lidé, kteří kafe vůbec nepijí.

Bylo to rozhodnutí podporovat pouze systemd z toho důvodu, že je systemd tak dobrý a nic jiného nemá smysl
Ne, z pohledu vývojáře je přidána závislost na systemd proto, že systemd poskytuje nějaké funkce, které může vývojář využít, a nemusí je sám programovat. To ale neznamená, že bude podporovat pouze systemd – když ty funkce nabídne někdo jiný, umožní použít i tu alternativu. Něco jiného samozřejmě smysl má, akorát to jaksi nikdo nenapsal, protože ti, kteří by k tomu teoreticky měli motivaci, mají plné ruce práce s hejtováním systemd.

nebo po přechodu na systemd by vývoj pro další init systémy znamenalo v podstatě udržovat paralelní forky
Dříve používané init systémy neposkytovaly aplikacím žádné služby. Takže aplikaci, která počítá se starými init systémy, je úplně jedno, jaký init sytém se použije, nijak ne tom nezávisí a její kód se nijak nemění. Prostě se vedle té aplikace připraví něco, co ji umí spustit – pro SysVinit shell skript, pro systemd unit file. Takže aplikace, která nechce být na systemd závislá, si může klidně dál nezměněná existovat, nepotřebuje žádné forky, prostě jenom její správce v systemd distribuci pro ni připraví unit file.

Prosím Vás, nemusíte psát takové dlouhé texty, jen opakujete obecné věci
Neopakuju. Význam slova „závislost“ jsem vám vysvětloval poprvé, předtím jsem si myslel, že to slovo znáte.

ldyž jsme chytli konkrétní, tak ta kompatibilita kterou proklamujete stejně jaksi neplatí
Ale platí.

Takže když vezmu staré Gnome tak ho spustím na distru se systemd?
Myslíte Gnome, které nebylo na systemd závislé? Samozřejmě, že ho v distribuci se systemd spustíte. Stejně jako tam spustíte kterýkoli jiný program, který o systemd nic neví. Jak by asi systemd mohl spuštění toho programu zabránit?

Alias proč tedy vývojáři nenapsali ten unit file
Protože vývojáři nechtěli jen ulehčit práci těm, kteří konfigurují správce služeb. Vývojáři chtěli použít služby, které programy z rodiny systemd nabízí. Tím vzniká ta závislost.

Co je teda taková výhoda, že se rozhodli být nekompatibilní s ne-systemd systémy?
Už jsem psal, že nevím, co konkrétně to bylo u Gnome. A také jsem psal, že neznám lepší vysvětlení, než že nějaké výhody existují. A zatím nikdo s lepším vysvětlením nepřišel.

Jak už jsem psal, to vysvětlení je nejlepší mně známé, nikdo tady zatím lepší nenapsal. To vaše vysvětlení je ve zjevném rozporu s realitou.

> to vysvětlení je nejlepší mně známé, nikdo tady zatím lepší nenapsal.

Tak úvodem bych chtěl říci, že nejdůležitější objevy jsem učinil já.

:-D :-D :-D

A co jsme se dozvěděli od tebe? Podal jsi nějaký argument, v čem je ta citovaná věta chybná? Ne. Vystačil sis s tím, že jsi ji 3x zopakoval. Tak jo no, doufejme, že budeš takto obohacovat diskusi i nadále :)

Zbytečně moc textu. Stačilo napsat "ne, nejsem schopný napsat konkrétní důvod. Raději ti budu nadávat, protože jsem anonymní king."

Hé-zký, to ty sám?
(doufám, že se ti ulevilo)

SMF? Jestli tím myslíte ten krám ze solarisu, tak to bych zrovna jako vzor neuváděl. Podle mého je to dokonalý příklad Enterprise humusu, u kterého není až tak jasné, co doopravdy přináší kromě toho, že se jim konečně podařilo do toho nějak narvat XML.

O launchd si něco přečtěte a zjistíte, že si je se systemd velmi podobný - přesněji řečeno, systemd se silně podobá launchd, který je starší. Rozdíly jsou hlavně v implementaci. V launchd procesy komunikují přes Mach porty, v systemd přes dbus. Kromě toho má systemd některé linuxové fičury navíc, jako je využití cgroups (což je velmi užitečné). Pokud vás ale uklidní, že systemd je až na pár drobností kopie launchd pro linux, tak mu tak klidně říkejte a žijte blaze :)

> není až tak jasné, co doopravdy přináší

??? Přináší v principu totéž jako systemd. XML není šťastná volba, ale taky není nijak nutné - viz např. https://github.com/mheily/jobd - reimplementace launchd, místo XML používá JSON. Stejně tak by tam mohl být třeba YAML, no problem.

> O launchd si něco přečtěte a zjistíte, že si je se systemd velmi podobný

No a co jsem asi napsal? Launchd je systemd velmi podobný, čili nebylo potřeba vymýšlet další nekompatibilní kolo, mohl se vzít launchd, poupravit, vylepšit a bylo by. Mohl vzniknout portabilní init systém, který by nezpůsobil takové vlny a nevytvářel z Linuxu nekompatibilního solitéra.

"Post-unixový" Linux je možná pro někoho příjemná myšlenka, nicméně https://plus.google.com/+MiroslavPrymek/posts/VYf2W8WXrj4

> mohl se vzít launchd, poupravit, vylepšit a bylo by.

Ne, nebylo by. Launchd má licenci Apache, ne GPL, což u tak klíčové součásti linuxového prostředí je dost zásadní problém. Možná se mýlím, ale pokud vím, ač je licence Apache dost permisivní, není to BSD a přelicencovat pro potřeby linuxu celý launchd pod GPL by nešlo - nehledě na to, že i kdyby to teoreticky šlo, neumím si představit ten řev. Některým lidem se prostě nikdy nezavděčíte.

> nevytvářel z Linuxu nekompatibilního solitéra.

To je dost diskutabilní. Nekompatibilní s čím? A z jakého pohledu? OSX je dodnes jediný systém s launchd, je to teda taky nekompatibilní solitér? Asi je, ale komu to vadí? Anebo dneska, kdy v podstatě všechny velká distra používají systemd, je takovým solitérem... Devuan, který je nekompatibilní s mainstreamem právě proto, že systemd nemá? Anebo FreeBSD, které nemá systemd ani launchd, ale svůj vlastní BSD init, který taky není kompatibilní se sysv, jak ho dříve používal linux?

Chci tím říct, že to je z mého pohledu čistě subjektivní argument a že v podstatě vůči jakémukoli software na světě se dá vznést námitka, že je špatný, protože vytváří nekompatibilitu s těmi, co ho nepoužívají.

> "Post-unixový" Linux je možná pro někoho příjemná myšlenka, nicméně https://plus.google.com/+MiroslavPrymek/posts/VYf2W8WXrj4

Přiznám se, že nevím, co tím chtěl básník říci. Každý má své důvody, já jsem kupříkladu už před neuvěřitelnými 23 lety neutekl od Windows proto, že to není unix, ale proto, že to je monopolistický proprietární systém a že záviset na něm znamená vydat se na milost a nemilost jisté notoricky hostilní a podraznické firmě. Linux byl, je a vždycky bude open source, ať už se systemd nebo bez něj, takže to mě tolik nepálí. Jestli ale systemd usnadní vývoj aplikací, užívání a nasazování linuxu pro uživatele, kterým jde možnost číst bezpečně maily, sledovat videa, prohlížet si fotky a psát články, a ani ne tak si hrát na pravoslavné unixové sysadminy, tak to bude záslužný počin.

To, že by správce služeb byl pod Apache licencí, by v linuxu neznamenalo vůbec žádný problém.

Proč to tedy s launchd neuděláte? Vemte, poupravte, přidejte API kompatibilní se systemd, a máte vystaráno. Nebo vemte, poupravte, udělejte lepší než systemd a systemd převálcujte.

Požadavek 1: mít API, aby šlo systém, služby, uživatelská sezení atd. ovládat a monitorovat programově. Pokud vím, minimálně na Linuxu má API jenom systemd.

Požadavek 2: integrace mezi různými typy událostí. Příklad: chci si nastavit (jako běžný uživatel, ne root), aby ve chvíli, kdy si připojím svůj záložní USB disk, se mi automaticky zálohoval adresář s dokumenty každou hodinu. Jak toho dosáhnu v klasickém unixu? V podstatě nijak. Jako běžný uživatel nemůžu ani instaloval službu, ani zachytit událost připojení konkrétního USB zařízení. Ale i kdybych mohl, bylo by to málo platné, protože neexistuje způsob, aby program nebo událost nastartovala nebo zastavila daný cronový úkol. Nemluvně teda o tom, že v zásadě neexistuje ani spolehlivý způsob, jak z pozice běžného uživatele zjistit, zdali je připojen jeden konkrétní USB disk. V systemd tohle jde, v sysvinit absolutně ne, v openrc se přiznám, že nevím, ale nejspíš taky ne.

Požadavek 3: Možnost JEDNODUŠE omezit CPU a pamět pro danou službu. V systemd to jde díky podpoře cgroups.

Stačí, nebo jich chcete patnáct dalších? ;-)

1) Nestaci. Navic to nefunguje.

3) systemd cgroups pouziva a diky tehle kombinaci je dost nastavovani omezeni celkem trivialni

Zapomnel jsi byt jeste sprosty ;)
Jenom jestli to neni nejaky falesny "j", ktery v tom jeste neumi chodit.

> Nestaci. Navic to nefunguje.

To, že spousta linuxových distribucí má prasácké init skripty, není argument pro nutnost systemd. Ve FreeBSD je většina funkcionality výborně vyřešená a daná do společných souborů. Takže typický init skript služby pak už připomíná spíš jenom tu deklaraci podobně jako ji má systemd - viz např. https://www.freebsd.org/doc/en/articles/rc-scripting/rcng-daemon.html - takhle málo stačí pro implementaci init scriptu, i s podporou dependencies.

Kromě toho samozřejmě existuje několik (!) init systémů, které fungují stejně jako systemd, ale nemají jeho nevýhody (např. ten zmíněný nosh).

> systemd cgroups pouziva

Na tom není nic špatného. Špatné je, pokud je nutně potřebuje a navíc ještě třeba probublají do API a následně do aplikací, které se tím stanou nejenom závislé na jednom init systému (úlet samo o sobě), ale i na jediném OS.

"To, že spousta linuxových distribucí má prasácké init skripty, není argument pro nutnost systemd."

Nevim, zda by init mel byt ve krehky ve smyslu ze nutne potrebuje bezchybne init scripty.

"Kromě toho samozřejmě existuje několik (!) init systémů, které fungují stejně jako systemd, ale nemají jeho nevýhody (např. ten zmíněný nosh)."

Ja netvrdim, ze systemd je jedine reseni (prestoze mne vyhovuje). Jenom to, ze sysv uz vazne ne. Ale samozrejme mas pravdu - tech reseni je vic.

"Špatné je, pokud je nutně potřebuje a navíc ještě třeba probublají do API a následně do aplikací, které se tím stanou nejenom závislé na jednom init systému (úlet samo o sobě), ale i na jediném OS."

Uprimne - nevim. Nikdy mne nenapadlo moc resit, ze Mail.app funguje jenom na Mac OS X, ale zase chapu, ze kdyz nekdo pouzival xBSD, tak asi bude rozcarovany, ze pro nej nekteri lide prestali delat soft.

> Nevim, zda by init mel byt ve krehky ve smyslu ze nutne potrebuje bezchybne init scripty.

Tomu nerozumím. Chyba v init skriptech způsobuje úplně stejné problémy jako chyba ve zdrojácích jakéhokoli init systému. Jaký je rozdíl?

> Nikdy mne nenapadlo moc resit, ze Mail.app funguje jenom na Mac OS X, ale zase chapu, ze kdyz nekdo pouzival xBSD, tak asi bude rozcarovany, ze pro nej nekteri lide prestali delat soft.

To je úplně jiný případ. Mail.app je proprietární aplikace a závisí na veliké proprietární knihovně.

Jde spíš o ten princip, proč ta aplikace nejde spustit jinde - jestliže je to jenom kvůli závislosti na pár funkcích init systému, které se daly udělat jinak, je to prostě škoda. Můžu jenom doufat, že většina vývojářů to za chybu bude považovat a takovou zbytečnou závislost s velkým dopadem si do softu nezavlečou - i když na to, jak říká Filip, mají právo, o tom není sporu.

Chyba v init skriptech způsobuje úplně stejné problémy jako chyba ve zdrojácích jakéhokoli init systému. Jaký je rozdíl?
Rozdíl je v tom, že administrátor neupravuje zdrojáky init systému, ale pouze jeho konfiguraci.

jestliže je to jenom kvůli závislosti na pár funkcích init systému, které se daly udělat jinak, je to prostě škoda
Co vám brání udělat to jinak?

> Rozdíl je v tom, že administrátor neupravuje zdrojáky init systému, ale pouze jeho konfiguraci.

A proč by měl admin upravovat init skripty? Když chci třeba spustit na FreeBSD nginx, tak dám do /etc/init.rc jeden řádek
nginx_enable="YES"
a pokud chci upravit nějaké parametry, tak třeba něco ve stylu
nginx_chroot="YES"
- je to principiálně úplně stejně deklarativní popis jako unitfile.

> Co vám brání udělat to jinak?

Proč bych to měl dělat jinak, když už jiná řešení existují? Už jste se podíval na to nosh?

1. Skripty nejsou API, to se na mě neráčej zlobit. Systemd API má, viz https://www.freedesktop.org/wiki/Software/systemd/dbus/. A pokud jsem si všiml, tak API pro zápis na disk náhodou máme.

2. Evidentně jsi to nepochopil. Že můžu na USB je irelevantní. Jak to udělám, abych věděl o tom, že právě byla připojena moje záložní flashka (a ne jiná)? A pokud na tohle řešení máš, jak to udělám, aby v tu chvíli začala jistá operace pravidelně probíhat každou hodinu? Doufám, že mi nechceš vážně navrhnout nějak fušovat crontab pomocí sed a awk...

3. Tak se informuj. Systemd funguje jako správce cgroups (ekvivalent cgmanager ve starších distrech) takže s ním nejen velmi úzce souvisí, ale taky takovou operaci triviálně umožňuje.

> Skripty nejsou API, to se na mě neráčej zlobit.

Api není problém vytvořit pro jakýkoliv init systém, pokud by to bylo potřeba. Viz např. API supervisord.

> Jak to udělám, abych věděl o tom, že právě byla připojena moje záložní flashka (a ne jiná)?

Matchováním tam, kam to patří - v hotplug subsystému. Root tam může dát skript, který může udělat cokoli, včetně spuštění uživatelského skriptu.

> Tak se informuj. Systemd funguje jako správce cgroups

Pointa je v tom, že cgroups se dají použít i bez systemd. Čili argument "chceme cgroups" je irelevantní pro otázku "potřebujeme systemd?"

> Api není problém vytvořit pro jakýkoliv init systém, pokud by to bylo potřeba. Viz např. API supervisord.

Takže neustále "není problém vytvořit, šlo by kdyby" atakdále. Vytvořené není, tudíž to momentálně nejde. Tečka.

> "Root tam může dát skript, který může udělat cokoli..."

Jestli Vaše odpověď na sice záměrně zvolený, ale jinak banální a legitimní scénář pro BFU je, že to sice normálně nejde, ale za to root někam může dát skript, tak jste mě rozesmál. Navíc neřešíte otázku, jak ten skript nahodí a zruší časovanou službu, když cron nemá API a init neumožňuje provozovat uživatelské služby.

> Vytvořené není, tudíž to momentálně nejde. Tečka.

Ne. Vytvořené to je, např. Upstart má dbus api. tudíž to momentálně jde už hezkých pár let. Akorát někteří lidi o tom neví.

> Jestli Vaše odpověď na sice záměrně zvolený, ale jinak banální a legitimní scénář pro BFU je, že to sice normálně nejde, ale za to root někam může dát skript,

Jak "normálně nejde"? Jde to. Tím skriptem. Na unixech se věci řeší skripty.

> Navíc neřešíte otázku, jak ten skript nahodí a zruší časovanou službu, když cron nemá API a init neumožňuje provozovat uživatelské služby.

Samozřejmě že to jde. Opět: vhodně napsaným skriptem.

Ale jinak námitku neexistence API ke cronu beru. Pokud je to problém, bylo by fajn ho řešit tím, že se API do cronu dopíše. Ne tím, že se cron včlení do initu.

> Ne. Vytvořené to je, např. Upstart má dbus api. tudíž to momentálně jde už hezkých pár let. Akorát někteří lidi o tom neví

Ano, upstart má (omezené) API, lépe řečeno měl, protože už se nepoužívá. Mimochodem všechny (pseudo)argumenty proti systemd se svého času stejně zuřivě používaly i proti upstartu, jak si možná pamatujete. Navíc hlavní hateři systemd nikdy neprosazují upstart, a vždycky sysvinit nebo openrc.

> Jak "normálně nejde"? Jde to. Tím skriptem.

Jak sám říkáte, nejde to bez zásahu roota a dost netriviálního bastlení (a to nechci ani pomyslet na race conditions a jiné možnosti katastrofy při tom skriptovém vrtání se v crontabu)

> Na unixech se věci řeší skripty.

Což je jeden z důvodů, proč si unix zasluhuje odpočinek (minimálně pokud jde o linux).

> Pokud je to problém, bylo by fajn ho řešit tím, že se API do cronu dopíše.

Tak jestli to někdy bude, tak se rád podívám. Do té doby na to máme systemd.

> Ano, nebudem to řešit skripty, to je přece fuj a zastaralé.

Když jde o to, pořád znovu vynalézat kolo a skriptovat věci, které jsou dneska holá samozřejmost a moderní OS je má umět out of the box, tak to je zastaralé. To vám klidně podepíšu.

Ale tady se nebavíme o něčem, co má systém umět out of the box. Bavíme se o tom, že uživatel chce po vložení nějakého zařízení udělat nějakou custom akci. Buď tu custom akci definuju pomocí skriptu, nebo nějakého jednoho řádku v uživatelově cronu, nebo pomocí vytvoření systemd služby. Každopádně musím něco vytvořit.

> Jak sám říkáte, nejde to bez zásahu roota a dost netriviálního bastlení (a to nechci ani pomyslet na race conditions a jiné možnosti katastrofy při tom skriptovém vrtání se v crontabu)

Zásah roota je nutně potřeba, to je správně. Jak jsem už řekl: bez něj by mohl uživatel komukoli nepozorovaně zkopírovat data.

O jakém "netriviálním bastlení" je řeč? Napadá mě několik způsobů, jak to udělat:

1. pod daným uživatelem je spuštěn skript, který provede zálohu a pak danou dobu čeká

2. flashka se mountuje do přesně daného umístění. V uživatelově cronu je úloha, která očekuje, jestli je přimountovaná a zálohuje. Když ne, končí.

3. konfigurace cronu je rozělena do více souborů (např. ~/.config/cron.d), při vložení flashky se konfigurační soubor přejmenuje z "bcp.conf.disabled" na "bcp.conf"

4. totéž jako 2, ale cesta k mountpointu flashky se zapíše někam do souboru

... a bambiliony jiných možností...

Nikde nevidím žádné "netriviální bastlení", všechno jsou to věci na jeden řádek.

Asi vám uniklo to hlavní: Frantu Uživatele zajímá, jestli se mu zálohují fotky. Jestli to je nebo není unixové je mu u onoho. Se systemd to jde triviálně a hned. Vaše "lepší" řešení bez toho "strašného" systemd spočívá v tom, že Franta nejdřív provede nebo nechá provést rootový zásah do OS, nastaví nový match pro udev a pak se pustí do vývoje vlastního démona, přičemž se předpokládá, že je dostatečně zkušený programátor, aby věděl, jak démona spolehlivě zabít nebo restartovat a jak se vyhnout race conditions. Případně milion jiných možností, které sice nefungují, protože unix potřebné funkce nemá, ale teoreticky by šlo je do něj implementovat.

To jako myslíte vážně?

(Na okraj: není pravda, že je na to potřeba root. USB se běžně automaticky mountuje s uid a gid namapovanými na toho, kdo je zrovna přihlášen na konzoli. Tak to bylo už před systemd a je tomu tak i teď. Vaše přístupy ostatně v tomto ohledu absolutně nic nemění)

Pokud Franta používá systém, který mu flashku automaticky namountuje, tak už vůbec systemd nepotřebuje. Prostě má cronjob, který zkontroluje, jestli je flashka přimountovaná a podle toho pak zálohuje nebo nezálohuje. To je jeden řádek. Jak to udělá pomocí systemd, že to je o tolik snadnější?

> To je přece úplně triviální. Třeba takhle (zřejmě zastaralé) nebo takhle s použitím timers - což je znovuvynalezený cron aneb Lennart a jeho NIH syndrom.

Znovuvynalezený cron, který na rozdíl od starého cronu jde ovládat skrz API, takže ho můžou používat aplikace, může záviset na jiných službách nebo událostech, služby nebo události můžou naopak záviset na něm atd. Taková drzost, co si to ten Lennart dovoluje!

Takže nakonec celé to drama kolem systemd je o tom, že když někdo chce použít novou funkci, která dřív nebyla, tak si ji musí najít v návodu?

To už se blíží čistému surrealismu :D

Ten cron jste se také musel naučit používat, v tom rozdíl není. Rozdíl je možná jenom v tom, že cron už umíte, ale nic nového se učit nechcete. A jinak zrovna cron také není vzorem intuitivnosti. Sice všechny crony používají zdánlivě stejný formát, ale ve skutečnosti se navzájem liší. A těch dotazů ve fórech „nefunguje mi cron“… Někde je potřeba odřádkování za poslední řádkou souboru, někdy dotyčný netrefí formát souboru, někdy má problémy s proměnnými prostředí, někdy neví, jak zacházet s výstupem…

Souhlas. Racionální řešení je vytvořit lepší cron s lepším API. To přeci není problém. Jak to souvisí se SystemD a s tím, že ho musím používat?

Nemusíte ho používat. Ale když se zamyslíte, jak by takový lepší cron měl vypadat, zjistíte, že není žádný důvod, proč by se služba „pokud dojde k události X, udělej Y“ měla chovat jinak, pokud událostí „X“ je uplynutí nějakého časového okamžiku, než když tou událostí je změna souboru, připojení média, spuštění služby… No a že když už máte univerzální systém, který dokáže reagovat na události, stačí do tohohle systému zapojit budík, který bude umět poslat událost v požadovaném čase. A že tak snadno získáte systém, který toho umí daleko víc, a jen tak mimochodem implementuje i celou funkcionalitu původního cronu. Navíc to „udělej Y“ je univerzální a může úplně stejně reagovat na různé události – takže může spouštět zálohu třeba každý den, a navíc pokaždé hned, jak připojíte zálohovací médium.

Ale nic vám nebrání používat ten původní cron, když chcete. Stejně jako vám nic nebrání napsat cron, který bude mít akorát lepší API.

Odbíháte.

Za a) SystemD musím používat.
Za b) Já chci lepší cron. Já nechci překopat půlku systému, který mi doteď fungoval.

Ad a): Kdo a jak vás k tomu nutí?

As b): Tak ten lepší cron napište. Nevím, proč by ho pro vás měl psát někdo jiný, kdo má o lepším cronu jinou představu, než vy.

ad a) Fedora? Debian?

ad b) Opět odbíháte. Problém není v tom, že bych mermomocí chtěl psát novej cron. Jen jsme vám kejvli na to, že nějakej lepší cron by se možná hodil. Jen stále nechápu, proč by náhradou tohoto cronu mělo být zboření všeho kolem.

Ad a) – Ne.

Ad b) – Neodbíhám, to jenom vy nevíte, co chcete. Chcete starý cron? Můžete ho mít. Chcete nový cron s API? Můžete ho mít, napište ho. Chcete správce služeb řízený událostmi (který tím pádem může plnit i to samé, co dělal cron)? Můžete ho mít. Výběr je jenom na vás. Když si vyberete starý cron, může vám být úplně jedno, že systemd dokáže plnit tutéž funkci.

Nikoli, nikdo vám nebrání mít vlastní názor – ale nemůžete po nikom chtít, aby se tím vaším názorem řídil. Systemd nikdo všem necpe – někdo ho napsal podle svých představ, a nabídl ho ostatním. Je teď na nich, aby se rozhodli, zda ho chtějí nebo nechtějí používat. Když vy máte jiný názor, napište svůj program a nabídněte ho ostatním – a opět bude na nich, zda ho budou používat či nebudou. To naopak vy chcete, aby se ostatní podřídili vašemu názoru, a když se vám systemd nelíbí, chtěl byste, aby vůbec nevzniklo nebo ho zakázat. To je totiž jediný způsob, jak zabránit tomu, aby ho lidé nezačali dobrovolně používat.

Přechod na systemd neznemožnil použití Gnome na zařízeních, kde se systemd nepoužívá. Odkazoval jsem třeba na návod na zprovoznění Gnome bez systemd na Gentoo.

To, že chcete používat Gnome bez systemd, je váš požadavek, takže se vy musíte postarat o jeho splnění. Není ničí povinností to pro vás zařizovat. Pohybujeme se ve světě opensource, takže je velmi pravděpodobné, že pokud bude o Gnome bez systemd zájem, vaše úpravy se integrují na hlavní větve Gnome.

„Systemd na věčné časy a nikdy jinak“ je pouze váš výmysl. Možnost výběru je tu pořád, nic nepadlo. Akorát pořád nechápete, že ty alternativy k systemd vám nezařídí autoři systemd, ale musí to udělat ti, kterým systemd vadí.

Jak může být záměr v nějaké nekompatibilitě nebo rozlezlosti ve světe opensource? Co vám brání napsat systém, který bude dotahovat a zlepšovat všechno, co dotahuje a zlepšuje systemd, a zároveň bude kompatibilní a nerozlezlý?

Bavíme se tu pořád dokola o tom, že někdo napsal systemd a dal ho k dispozici ostatním s tím, že pokud ho chtějí používat, tady je a používat ho můžete. A pár lidem se to nelíbí, a pořád dokola si stěžují, jak si může někdo dovolit napsat software, který neodpovídá jejich požadavkům, a dát ho k dispozici ostatním. Tak už se s tím smiřte, že žijete ve svobodném světě, každý si může napsat software jaký chce a může ho zveřejnit. Vy to můžete udělat také. V tom, abyste napsal software, který bude daleko lepší než systemd a převálcuje ho, vám nebrání vůbec nic z vašeho okolí – problém je čistě v tom, že to neumíte nebo nechcete. Stěžovat si na to klidně můžete, ale nečekejte, že lidé, kterým vyhovuje systemd, bude psát váš anti-systemd.

Je to neodpovídá požadavkům – bugs and compatibility jsou jenom požadavky. Na počtu lidí nezáleží – když píšete opensource software, nikdo vás nemůže nutit, abyste bral v úvahu, kolik lidí to bude používat. Já si můžu klidně napsat a zveřejnit program, který bude vyhovovat jenom mně a všichni ostatní budou tvrdit, jak je to špatný program – a přesto mi nikdo nedokáže zabránit v jeho zveřejnění. Navíc pokud je těch odpůrců systemd takové množství a systemd je špatné, tak už přece dávno někdo z nich musel napsat něco lepšího, než systemd, na co všichni uživatelé systemd rádi přešli.

Ano, je to něco jiného – rozdíl je v tom, zda se kvůli tomu poperou správci distribucí. Což je věc těch správců distribucí a já jako autor toho programu to řešit nemusím (ostatně oni se mohou klidně poprat z důvodu, který ani).

Ten princip není stejný. Autoři Debianu dělají distribuci pro sebe, a rozhodli se, že ji zpřístupní i ostatním. Vy jste se dobrovolně rozhodl, že tohle, co vám někdo zadarmo nabízí, budete využívat. Teď se autoři Debianu rozhodli k něčemu, co se vám nelíbí. Tím, že je to opensource, vy dokonce můžete tu distribuci jednoduše vzít, a udělat fork, který bude vyhovovat vašim potřebám – jako to udělali autoři Devuanu. Ale vy byste místo toho chtěl, aby se autoři Debianu vykašlali na to, jak to chtějí mít oni, a místo toho to udělali podle toho, jak chcete vy. Proč by to měli dělat?

Nezáleží na tom, jak se k tomu rozhodnutí dospělo, to výsledné rozhodnutí představuje to, co dnes Debian „chce“. Kdyby se rozhodli, že chtějí podporovat varianty se systemd i s ním, také by to znamenalo, že to Debian „chce“.

zdroj zde diskuze
Pokud se o tom, co nasadíte na server, rozhodujete podle zdejší diskuse, je to váš problém. Pokud zdejším diskutérům důvěřujete víc, než správcům Debianu, nenasazujte na servery Debian, ale distribuci zdejších diskutérů.

Takže to je takový můj výhled na účinek systemd v prostředí a panu Poetringovi […] můžu fakt poděkovat.
Za to, že se řídíte „radami“ zdejších diskutérů, opravdu pan Poetring nemůže.

Já vím, nemusím používat nic, ale tak proto to dělají? Aby to lidi mohli klidně nepoužívat?
Ne, dělají to proto, aby to lidé mohli používat – a dospěli k rozhodnutí, že se systemd to bude pro lidi použitelnější. Pokud vy si myslíte, že by to bylo použitelnější bez systemd, je na vás, abyste to prokázal. Ostatně autoři Devuanu jdou právě touhle cestou.

Nějak pořád nechápu, proč by autoři Debianu, kteří si myslí, že to bude lepší se systemd, měli prokazovat platnost vašeho názoru, že to bude lepší bez systemd.

> Za to, že se řídíte „radami“ zdejších diskutérů, opravdu pan Poetring nemůže.

Nejde o rady, ale o popis konkretnich problemu konkretnich lidi.

Z těch bugreportů a nepochval se ale nedozvíte, jestli je to jinde lepší nebo horší. Čekat s vydání softwaru „než se to pořádně vychytá“ je samozřejmě možné, ale při vývoji softwaru se obecně inklinuje spíš k častějšímu vydávání. Protože jinak hrozí, že si budete někde pod pokličkou psát svůj dokonalý kód, a až ho ukážete světu, ukáže se, že to takhle vlastně nikdo nechce. Navíc většina problémů „se systemd“ je způsobena tím, jak „netradičně“ se to v reálném světě používá – což nezjistíte, dokud se ten software nezačne reálně používat.

Ale přístup, když se ti něco nelíbí, tak "si naser", neboli slušně řečeno "používej si něco jiného nebo si to napiš sám" neberu jako správný, protože to nepodporuje volnou výměnu názorů.
To asi ale špatně vykládáte, co to znamená volná výměna názorů. Ta se týká skutečně jen těch názorů, ne toho, že se jimi někdo musí řídit. To, že je systemd špatný, je váš názor, a nikdo vám to nebere. Ale pokud se tím názorem chcete řídit, je to na vás – volná výměna názorů neznamená, že někoho jiného, kdo s tím názorem nesouhlasí, donutíte, aby se jím řídil.

To, že je ten balíček komplexní, je právě ta podstata sporu. Někdo si myslel, že ta původní halda různých částí, které spolu navzájem komunikují špatně a každá jinak, je špatně, a je potřeba místo toho přijít s něčím, co bude komunikovat jednotně a spolehlivě. Proto se to nedá řešit postupnými výměnami jednotlivých balíčků – protože primární problém není v těch balíčcích, ale ve vzájemných vazbách. Řešit to postupně tak, že by ty jednotlivé části uměly komunikovat postaru i ponovu, by bylo na dlouho, přičemž ten nový kód by se dlouho nevyužíval, a navíc by se s sebou pořád táhla ta zátěž chyb staré komunikace. Kdyby se s tím začalo před deseti lety, asi by to bylo přijatelné, ale dnes už není čas čekat na to, že možná za deset let budeme mít rozumný způsob správy a komunikace služeb.

Ano, někdo na to může mít jiný názor, ale pak je na něm, aby to implementoval. Jako to udělali autoři Devuanu. Třeba se časem ukáže, že měli pravdu oni, a Debian zanikne a bude pokračovat jenom Devuan, nebo se spolu zase sloučí a Debian z Devuanu převezme jako svou hlavní větev tu non-systemd.

> To, že je ten balíček komplexní, je právě ta podstata sporu. [...] a je potřeba místo toho přijít s něčím, co bude komunikovat jednotně a spolehlivě. Proto se to nedá řešit postupnými výměnami jednotlivých balíčků

Tak v tom teda vubec podstata sporu neni. Neni nic spatneho na tom, udelat novy init+svc management+cron+at­d, pekne to promyslet, provazat, udelat k tomu API. Spor je o tom, jestli zrovna ta implementace systemd je dobre promyslena, jestli bude v provozu dostatecne robustni, jestli toho nahodou vic nepokazi nez spravi.

Bud to nechapete nebo nechcete chapat, ale neustale tady cupujete strawmana. Kdybyste min mluvil a vic poslouchal, tak byste si to mozna uvedomil.

Čekalo to patnáct let. Kdyby autoři systemd čekali dalších patnáct let, přišel by mezi tím někdo jiný, kdo by udělal klidně ještě větší zásah do systému.

Testovací verze systemd samozřejmě existovaly, jenže když to testuje pár uživatelů, neodhalí se tím všechny možné kombinace prostředí. Mimochodem, to, že po světě existují miliony různých hacků správy služeb, které je problém naroubovat na systemd, je jenom dalším důkazem toho, že ten dřívější systém je špatný.

Můžu Vás ujistit, že čím větší systém složený z částí, které nejsou schopny fungovat samostatně (nemyslím jen systemd ale distro jako celek) - modulárně - tím dřív se nakonec sesype, protože taková struktura musí mít nějaký hlavní regulátor a ten nakonec jednou nebude schopen uřídit všechno.
A tohle je právě věc, kterou systemd řeší. Před systemd máte soustavu různých skriptů, udev pravidel, cronů a bůhvíčeho ještě, co je na sebe různě navázané a závislé. Systemd právě přináší tu modularizaci, protože ty komponenty si mezi sebou povídají stejným protokolem, takže můžete jednu komponentu snadno vzít a nahradit ji jinou komponentou, můžete snadno spouštěč události změnit z času na modifikaci souboru, start služby, přihlášení uživatele nebo cokoli jiného.

No super, takže důvod bychom měli. Ještě že tohle nefunguje třeba v letectví.
Taky doufám, že v letectví netrvá 15 let, než se začne řešit známý problém.

No to jste mě teda uklidnil, že si udělají z uživatelů a ostrých nasazení test plant.
Tak jako všichni ostatní, kteří píšou software, který se používá v milionech různých prostředí. Všechna ta různá prostředí totiž nejde nasimulovat.

Jinou komponentou, ale systemd komponentou.
Ne.

Oni se evidentně vy..li na interface a vše, na co narazí zahrnou do systemd.
Ne. Pouze píšou ty komponenty, které mohou z nového systému těžit a nenapíše je nikdo jiný.

Kam ta jejich modularita vede se hezky probublalo až ke Gnome že, a taky jsem narazil na to, že Xfce ja na tom stejně. To je přímo ukázka nezávislosti.
To, že nikdo jiný nenapsal implementaci logind, není chyba lidí od systemd. Pokud někdo che jinou implementaci, ať ji napíše. Nepsal už jsem to několikrát?

Jinými slovy, místo aby změnili/spravili článek mezi jádrem a desktopem, vedle cronu atd, tak vytvořili moloch, který nároky spojil všechno dohromady tak, že je systemd závislé i grafické prostředí
Ty nároky jsou mnohem menší, než byly u těch původních implementací. Vám pořád vadí, že nikdo nenapsal alternativní implementaci – ovšem vy patříte mezi ty, kteří ji nenapsali. Takže si stěžujete pouze na sebe.

ani neměli před nasazením možnost to otestovat
Mezi software, který takhle funguje, můžete zahrnout třeba také linuxové jádro.

No to je teda modularita.
Modularita znamená, že můžete komponenty přidávat a ubírat, aniž by o tom musely vědět ostatní komponenty. To, že třeba modul poskytující služby cronu nemůžete momentálně nahradit jiným modulem, protože neexistuje žádný jiný modul poskytující takové služby, není chyba modulárního systému. Je to chyba toho, kdo ten jiný modul potřebuje a nenapsal ho. To je jako kdybyste tvrdil, že linuxové jádro není modulární, protože když odstraníte modul ext4, nemáte žádný jiný modul, který by obsluhoval souborový systém ext4.

hromadu nezávislých komponent, který tvoří fungující a automaticky reagující celek.
Přesně takhle systemd funguje.

Mám na mysli postup, že když chcete např. v tabulce Users zrušit sloupec "whole-name" a nahradit ho sloupci "first-name" a "surname", tak přece hned v aktualizaci nezlikvidujete sloupec a nenahradíte ho těmi dvěma, ale pouze vytvoříte ty dva nové, přehrajete do nich data a začnete tam přidávat i nové, běží to paralelně a pak, až Vám to hezky běhá s novými sloupci a nikdo nezaznamenává problémy, tak třeba v další aktualizaci odstraníte sloupec "whole-name" + kód k tomu a máte jistotu, že to všechno běží a nikomu nic nerozbíjíte. Ano, je to těžší postup ale nikomu z razu nic neodstřihnete
Jenže pokud nemáte kontrolu nad všemi aplikacemi, které s tou databází pracují, zůstal byste na věky se třemi sloupci – protože některé aplikace by se prostě nepřizpůsobily, když by je k tomu nic nenutilo.

Navíc pokusy řešit ty problémy cestou mírného pokroku jsou staré minimálně patnáct let – a žádný z nich se neujal. Protože kvůli zachování zpětné kompatibility přinášely pouze malé výhody, přitom ale byly s předchozím řešením nekompatibilní. Takže se to ve výsledku moc nevyplatilo nasazovat. Takže se dál bastlily hacky na hacky, až se dospělo do bodu, kdy energie potřebná ke změně je menší, než energie nutná na udržování těch hacků.

Kdyby nebyl systemd tak problémový, měli bychom tu pořád ten starý systém postavený na nekompatibilních programech, které jsou různými hacky provázané tak, aby to připomínalo to, co bylo původně požadováno. Ty problémy jsou totiž převážně způsobeny tím, když se někdo ty hacky hacků pokouší naroubovat na systemd. Je to podobné jako s přechodem na IPv6, který je pro spoustu lidí také problémový, protože nevědí, jak v síti použít IPv6 adresy z privátního rozsahu a celou síť „schovat“ za NATem.

Takže je podle Vás v pořádku, že když si nainstaluji čistou Debian + systemd + Gnome a vyměním systemd tak už Gnome nespustím?
Když nějaká komponenta vyžaduje nějakou službu, a já poskytovatele té služby vyměním za něco jiného, co tu službu neposkytuje, je v pořádku a logické, že ta závislá služba přestane fungovat. Když nainstalujete X a Gnome, a pak X vyměníte za framebuffer, Gnome vám přestane fungovat – protože vyžaduje služby X, které framebuffer neposkytuje.

V pořádku není, pokud vám nějaká distribuce umožní udělat takovou „výměnu“, aniž by protestovala.

V pořádku by také nebylo, pokud byste implementaci té služby vyměnil za jinou implementaci té služby, a přestalo by to fungovat. Pak může být problém v některé z těch implementací, v nejasném rozhraní nebo v tom, že závislá aplikace závisí na specifickém chování konkrétní implementace, které není rozhraním zaručeno.

Není, protože jim nikdo nesebral možnost mít ipv4
Pokud vám ty možnosti někdo sebral, stěžujte si na něj – z toho, co píšete, předpokládám, že vám ji sebrali správci Debianu. Systemd pokud vím stále může běžet jako PID>1, ze systemd stále můžete spouštět jakékoli skripty, včetně původních init skriptů, stále můžete používat různé implementace cronu. Systemd tomu nijak nebrání, takže chybu hledejte jinde.

Ten váš příklad je úplně špatně. V původním řešení totiž neexistuje žádné jednotné rozhraní, každá komponenta s každou jinou komunikuje ad hoc rozhraním specifickým právě pro ty dvě komponenty. Správně by tedy ten příklad byl, kdyby ten původní dům žádný interface neměl. „Stoupačky“ by byly řešené tak, že by byla nějak přivedená voda do prvního patra, tam by se třeba před kohoutkem udělala odbočka, na ní nasadila hadice a tou voda vytáhla do druhého patra. Ve druhém patře by byla trvale zašpuntovaná vana, v ní ponorné čerpadlo a to by hnalo vodu do třetího patra – a kdyby ve vaně docházela voda, měli by z třetího patra dolů natažený provázek, kterým by zatáhli za pákový kohoutek ve druhém patře, aby se vana začala napouštět. Atd. atp.

Pak by přišli s tím, že je potřeba s tím něco udělat, udělat v celém baráku jednotný interface (normální stoupačky). Udělalo by se to, a nájemníci by si začali stěžovat. Ten ze třetího patra by si stěžoval, co je to za pitomý rozbitý interface, být napojený na stoupačky. On byl zvyklý na svůj interface – ponorné čerpadlo a provázkem ovládaný kohoutek o patro níž. A teď když se pokouší se na to připojit, musel si pořídit sud, do kterého napouští vodu z těch stoupaček, protože ponorné čerpadlo neumí čerpat vodu ze stoupaček. K ovládání kohoutku pro plnění sudu ze stoupaček musel přidat kladku pod strop, protože kohoutek má najednou u sebe a ne o patro níž, a když od něj vede provázek nahoru, už na něj nedosáhne. Nájemníci by tedy začali brblat, jak mají ty stoupačky špatný interface, že je potřeba, aby se to u nich v bytě napojilo na ten jejich původní – ale jinak v domě ať jsou samozřejmě ty stoupačky, protože si nájemníci od 4. patra výš rychle všimli, že ve stoupačkách je voda pořád, a ne podle toho, jak zrovna funguje čerpadlo ve 3. patře.

Co znamená „po výměně komponenty systemd“? Komponenta je podle mne něco, co přes nějaké rozhraní poskytuje nějaké služby. Takovou komponentou je třeba cron, který může být implementován třeba bcronem, dcronem, fcronem nebo cronie. Rozhraním té komponenty je správce systému, který pomocí textového editoru podle požadavků oedituje konfigurační soubor příslušného cronu.

Systémové proměnné a systémové funkce pro přístup ke zdrojům neposkytují rozhraní potřebné pro dnešní systémy. Jak byste pomocí systémových proměnných a systémových funkcí pro přístup ke zdrojům informoval všechny komponenty, které to zajímá, že se právě k systému přihlásil nějaký uživatel, a předal jim informaci o prostředí a o tom, který je to uživatel?