Názory k článku
Jen 1 % uživatelů Debianu používá sysvinit

Uživatelé by možná chtěli, ale nemají na výběr. Na systemd je v Debianu závislé kde co. Buď používají ořezanou instalaci (to 1%), nebo se podřídili diktatuře systemd, nebo přešli na jinou distribuci.

Kdyby těch uživatelů bylo třeba 5-10 %, pak by se dalo vést tuto úvahu.
Zajímavé na tom čísle je, že je až tak moc malé.

Me to prijde az prekvapive velke na to, ze systemd je v debianu by default a prejit na jinej init je daleko zlozitejsi nez proste vymenit distribuci...

Kedysi som zachytil diskusiu o optimalizacii stranok jednej nemenovanej institucie, kde sa riesilo, ze stranky je potrebne kompletne prekopat lebo v nicom inom nez v IE prakticky nefunguju. Nacoz sa ozval jeden z prisediacich, ze je to zbytocne, lebo z inych browsrov na stranky prakticky nikto nechodi :D :D :D

Diktatuře... Přijde mi, že většina lidí, kteří žehrají nad tím, že distribuce neumožňují volbu init systému, si neuvědomuje, že jakákoliv možnost výběru má své náklady. Není to žádné lidské právo, naopak všechny softwarové projekty si pravidelně kladou otázky, jestli v tom či onom dát uživatelům na výběr i za cenu zvýšených nákladů na údržbu, které to má.

Převáží výhody volby initu v Debianu nad náklady, které to s sebou nese? Těžko říct. Debian se vždy vyžíval v tom podporovat, co se dá (jiné kernely, obskurní architektury), možná by to pro něj z tohoto pohledu dávalo smysl. Já jakožto správce několika balíčků ve Fedoře jsem rád, že my volbu initu nemáme. I kdyby byla, tak výchozí volbu bude používat stejně minimálně 90 % uživatelů, protože toto je pod jejich rozlišovací schopnosti, implementační detail. A popravdě raději budu ten vzácný volný čas, který můžu údržbě balíčků věnovat, trávit tím, že to budu vylepšovat pro těch 90+% než řešit problémy s něčím, co používají jednotky procent uživatelů.

Tu by som sa asi zamyslel nad tym, preco ludia zehraju. Sysvinit bol po dobre desatrocie (alebo aj dve) defakto monopolom v Linuxe. Ano, existovali rozne ine viac ci menej kompatibilne systemy, ale povacsinou mali nejaku vrstvu kompatibility so sysvinit, aby jeho init skripty slo do distra integrovat a maloktory balik riesil, ze ako si svoj init skript spusti trebars na Slacku, ktory sysvinit skripty nikdy neintegroval. A vsetci boli ticho. To sa ale bavime o dobe, ked ludi, co naozaj tusili, co to init system je a ze ho v pocitaci maju, bolo percentualne viac, nez dnes.

Preco to tak bolo? Pretoze ludia okolo sysvinit bohorovne netvrdili, ze niekoho workflow, ktory tak nejako fungoval je blbost a preto ho nebudu podporovat, nesnazili sa prevzat kontrolu nad systemom, neobmedzovali jeho flexibilitu, atd.

Systemd proste fungovat pre 100% ludi nebude, pretoze nepodporuje spravne napr. extremny embedded a extremny embedded len pre existenciu systemd nezmizne.

Dává vůbec smysl dneska používat pro "extreme embedded", ať už to znamená cokoliv, vanilkový Debian, místo minimalistických dister typu Alpine? Nejen kvůli systemd, ale třeba i kvůli glibc vs. musl?

[ventYI]

"A vsetci boli ticho."

Prave ze nebyli. Nadavalo se taky a zhusta. Dost takovych diskuzi (aspon tady v Cesku) se da najit treba na abicku. Jednem vadilo, ze Sysvinit sluzby startoval seriove, druhym vadily obtize pri startovani sluzeb a reseni zavislosti (co spustit driv), dalsim nevonelo pro kazdou sluzbvu psat skript, atd... Podobne vitky (ale nevim jestli v takove mire) zaznivaly vsak i jinde.

Jedine co me prijde rozdilne (ale mozna se pletu) ze se tehdy objevilo nekolik alespon pokusu bud opravit sysvinit samotny (napr zavedeni "konkurency modu", ktery umoznoval startovat sluzby paralelne), nebo i nejake konkurencni projekty, ktere se vsak moc neujaly. Az se nakonec objevil systemd. Ten rozdil spociva v tom (aspon me se to tak jevi) ze se JEN nadava. Bud na projekt samotny, nebo rovnou na autora...

13. 11. 2019, 02:00 editováno autorem komentáře

v *buntu byl upstart, startoval paralelne, resil zavisloti, sel zjistit stav sluzby, system startoval z ssd za 6s do plochy najete... a nedelal s0ze sebe druhej operacni syatem, nepohlcoval/ne­nahrazoval vse okolo, nekoncil boot v emergency kdyz nenasel datovej pro system nepotrebnej disk, atd...

myslim ze malo z tech co popisujes chteli misto init operacni system na ktetem bude zaviset pulka desktopu...

Ak by všetci boli rovnakí, neexistoval by multiplatformný (desktopový) SW - veď prečo by sa niekto patlal s podporou Linuxu / macOS a riešením problémov u jednotiek % namiesto vylepšovania SW pre tých 90+% (= Windows)

Vždycky k tomu vývojář SW musí mít nějakou motivaci a jen zřídkakdy je to altruismus, kdy se slituje nad uživateli nějakého minoritního systému a začne svůj SW na ten systém portovat a podporovat. U komerčního softwaru to může být čistě byznys. Linux má sice pár procent trhu, ale pořád to může být dostatečný příjem, aby to vývojáři stálo za podporu. U open-source projektu je pak často motivátorem aktivní komunita kolem Linuxu. Často dokáže vygenerovat víc lidí, kteří přispívají nebo aktivně hlásí chyby, než Windows. Často ta komunita ten port sama udělá.
U aplikací, které jsou primárně pro Linux, je pak motivací portovat na Windows uživatelská základna. Třeba přispěvatelé do LibreOffice jsou z drtivé většiny na Linuxu, ale u uživatelské základy a finančních příspěvků je to přesně naopak. Podobně to má GIMP. Vždy ale platí, že to nebude nikdo dělat "pro vaše krásné modré oči".

Lidé mají tendenci mezi diktaturou a možností volby hledat hranici. Ale ona tam vlastně žádná jasná hranice není. Volba jednoho člověka často znamená diktát člověku jinému.

Vezměme si to takhle: já porovnávám, zda výhody volby převáží nad náklady. Fajn, jenže jaké výhody, jaké náklady a pro koho? To, co jeden vnímá jako volbu a jiný jako diktát, je často jen úhel pohledu. Takže platí obě tyhle věty:

1. Výhody, které mi X přinese, převažují nad náklady, které mě to bude stát.
2. Výhody, které X přinese někomu jinému, jsou mnohem menší než náklady, které s tím bude ten někdo jiný mít.

Jedna a ta samá věc, jen pro jednoho je to volba, pro druhého diktát. A dáváte příklad: pro vás jako pro správce několika balíčků představuje "jen systemd a nic jiného" výhodu, aniž by vám to vlastně přinášelo jakékoliv náklady. Jenže ty náklady s tím možná bude mít někdo jiný, pro koho "jen systemd a nic jiného" nebude vůbec výhodné.

Co se systemd týká, tak dnes to ještě není katastrofa. Pořád je možné portovat projekty z Linuxu na BSD apod. Jenže se to každým rokem zhoršuje. Ne kvůli systemd jako takovému, ale kvůli jeho součástem, které řada projektů začíná používat. Multiplatformní vývoj se tak po letech zjednodušování začal naopak zase komplikovat. A to přesně podle vzorce "vývojář si díky přechodu na logind ušetřil nemalou část stresu a nákladů" + "člověk udržující daný balíček pro BSD se na to vybodl, protože tohle mu už vážně nestojí za to". Což je právě ten důvod, proč mnoha lidem leze systemd krkem - kvůli tomu, že toho dělá čím dál tím víc, prorůstá všude a vnucuje závislosti, se kterými si pak už člověk poradit nedokáže. A to se prosím nebavíme o systémových věcech, ale o userspace, o kterém jsme si před 15 lety mysleli, že touhle dobou už bude natolik jednotný, že bude jedno jaký OS kdo používá. Systemd "ekosystém" do toho hodil vidle.

Ano, žádná objektivní hranice neexistuje, proto jsem nabídl ten pohled někoho, kdo do linuxové distribuce přispívá. Ve výsledku jsou to tito lidi, kteří rozhodují, protože open-source projekty jsou v drtivé většině případů meritokracie ve stylu "kdo přispívá, rozhoduje".
Stejně tak, co vy vidíte jako komplikaci multiplatformního vývoje, to je pro hromadu vývojářů vysvobození, protože jestli jsme jako tvůrci distribuce něco pořád dokola poslouchali, tak to byly nářky vývojářů aplikací, že Linux je hrozně nejednotná platforma. A systemd jim v tomto hodně pomohl, protože userspace dost sjednotil napříč distribucemi.
Většina open-source projektů podporu pro BSD nebo ne-systemd distribuce nezavrhuje, ale obecně platí, že pokud se má něco podporovat, musí se najít někdo, kdo to udělá a bude udržovat. A takovou motivaci mají většinou ti, kteří to sami používají. Problém je v tom, že počet uživatelů těchto alternativ je tak malý, že je i malý počet lidí ochotných to dělat. Vidím to na GNOME, patche pro podporu BSD byly vždycky vítané, ale v open source obecně platí "každý si škrábe své vlastní záda". Dobrovolník, který používá jen Linux a zajímavá ho jen Linux, toto dlouhodobě dělat nebude.

Sami uživatelé tak vlastně ukazují, že o alternativní init systém zájem nemají.

To je ale nesmyslný závěr. Silou se jim natlačí systemd, udělají se jim nemalé překážky k jiným init systémům a pak se vyhodnotí, že o to nemají zájem, protože to používá jen 1% (těch nejzdatnějších, co to umí změnit a vědí proč to potřebují udělat, nezahrnuje ty zdatné, co zvolili ač neradi systemd, protože se s tím hodlají prát).

Tolik?

[pre] Init systém sysvinit prý používá jen 1 % nových instalací Debianu. Sami uživatelé tak vlastně ukazují, že o alternativní init systém zájem nemají.[/pre]

To je dost pochybná interpretace. On by zájem byl, ale když něco nefunguje... Snad ten návrh projde (a bude hlídáno dodržování). :)

Jsem jeden z 99% co pouziva systemd z donuceni. Uz od 1.hlasovani chci prejit na Deuvan, ale kdyz doslo na reinstall tak sem potreboval pocitac rychle zprovoznit a tak zase
zvitezil systemd, ktery Linux posouva bliz k Win. Dobry priklad je automount. S initem staci jedna radka v fstab a v systemd jsou potreba 2 soubory s x radky pro kazdej adresar. A tak je to se vsim. Jakakoliv jednoducha konfigurace initu se v systemd stava slozita se zapisem do nekolika souboru. Pokud uzivatel nic neladi tak systemd funguje krasne, ale pokud si ho chce uzivatel priohnout ke svym potrebam, tak je to velmi slozite.
Pristi reinstall uz snad provedu na Deuvan. (U Raspbianu systemd nechapu uz vubec).

chces rict ze Devuan nejde nainstalovat rychle?

btw: i se systemd pouzivam klasicnej zaznam v /etc/fstab, "pouze" pridavam volby:
nofail,x-systemd.device-timeout=1
aby systemd nestopnul start systemu do emergency rezimu jen proto ze nevidi datovej (= pro system nepotrebnej) disk a nenahodi ani SSH aby to slo poresit vzdalene...

Ano, nevím, co předřečník dělá (já si teda pod pojmem automount vždycky představoval připojení flashky aktuálnímu uživateli), záznamy ve fstabu vypadají furt stejně…

…až na to, že mount už není mount(2), ale něco, co spouští vygenerované mountovací unity a po změně fstabu se to musí reloadnout (!) a navíc nejde ručně mountnout jiné zařízení do adresáře co už ve fstabu je! (pozn. tohle se dělo na Debianu 9, v aktuální verzi jsem ještě neměl příležitost s tím zápasit, protože jsem nedávno změnil job z admina na vývojáře)

Pro mne byla naopak vyhoda, ze neslo ovlivnovat obsah toho adresare, do ktereho mel byt pripojen jiny svazek. Omezovalo to ztratu dat a havarii systemu - napr. kdyby neco zapsalo XX GB na maly systemovy disk, protoze nebyl pripojen velky disk pro to urceny.

> Pro mne byla naopak vyhoda, ze neslo ovlivnovat obsah toho adresare, do ktereho mel byt pripojen jiny svazek.

Jenže on ovlivňovat jde - můžeš do něj cokoli zapisovat, jen do něj nelze připojit nic jiného. A ještě hůř: pokud jsem měl třeba ve fstabu "/dev/md0 /mnt/foo" a zadal jsem "mount /dev/md1 /mnt/foo", tak to bez jakékoli hlášky o chybě připojilo md0! Takže jsem pak spustil "rsync --delete ..." na špatné pole!

Blbe jsem to specifikoval. Automount nfs svazku pri startupu. Teoreticky by melo fungovat do fstabu pridat parametr _netdev, ale me to nefungovalo. Nakonec jsem musel nadefinovat pro kazdej sitovej adresar systemd mount unit. To co v fstabu trvalo zadefinovat asi tak 5 minut v systemd trvalo hodinu (nekolik preklepu, ktery jsou kazdej v jinym souboru). Zrovna automount flashek funguje defaultne v systemd lip nez s initem.

Coz je zvlastni, nebot u me to funguje na prvni dobrou pridanim radku do fstab (ano, i ten nfs).

Dekuju, presne tohle sem resil o vikendu na Ubuntu a neprisel sem na to proc to furt pada do maintainance modu bez jakykoli chybovy hlasky (jak na konzoli tak v jurnalu). Pravdepodobne to byl presne ten pripad. Nakonec sem to vyresil smazanim Ubuntu a instalaci Void linuxu.

Jak tak ctu tu diskuzi, tak si rikam: "A ted cert se v tom vyznej..." Jen jestli to cele neni nahodou o tom, ze to 1% je proste moc slyset. Jsem taky hodne zvedavej na vysledky hlasovani. I kdyz se obavam, ze se urcite najdou zpusoby, jak ho zpochybnit at dopadne jak chce.

Nějakého klasického initu (OpenRC? Už nevím) jsem ve svém Gentoo držel docela dlouho. Každou chvíli mi při nějaké aktualizaci v GNOME a později v Xfce přestalo fungovat připojování externích disků, či optických mechanik, během bootu obligátní zelené [OK] zmizelo a já řešil, co se zase rozbilo. Jednou jsem to nevydržel při kompilaci GNOME, které na tom Systemd docela dost lpělo a zkusil jsem změnu. Vše fungovalo na první dobrou a od té doby si nevzpomínám na jediný problém.

Chybí mi ta jednoduchost a transparentnost init scriptů, taky Systemd spíš nemusím, ale funguje to, takže jsem si nějak zvykl na příkaz systemctl a dál to neřeším. Nectím potřebu provozovat nějaké sebemrskačství u klasického initu, který už požívá tak málo lidí, že to není pořádně odladěné. Mi to 1% připadá jako jasnější výsledek, než nějaké hlasování.

A nestačilo jen po té aktualizaci spustit etc-update?

OpenRC neni klasickej init. OpenRC totiz vubec neni init. Za to umi spoustu veci co systemd co se tyce spravy sluzeb...

Pro diskuzi o (ne)podpoře jiných init systémů mi přijde významnější spíš to, že v distribuci, kde je systemd protežovaný, automaticky zvolený při instalaci a existuje fork bez systemd, 11,5 % uživatelů nepoužívá systemd: https://qa.debian.org/popcon.php?package=systemd

Systemd stabilní na serveru? Možná na desktopu to něco vyřešilo, ale na serveru tomu ani trochu nevěřím, párkrát jsem jen koukal, jaké nesmyslné defaulty systemd má. Se skriptovaným initem jsem na serverech nikdy problémy neměl, prostě fungoval.