Názory k článku Debian se musí znovu vážně zabývat přístupem k init systémům

Díky svému pevnému a rozhodnému "možná" dopadá Debian zhruba tak, jako Lidovci v Parlamentu. Pro mě osobně je to velká ztráta, protože před lety jsem Debian považoval za favorita mezi svobodnými distribucemi. Jen díky jejich neschopnosti určit vlastní směr jsem přešel na FreeBSD a nakonec vůbec nelituju. Debian pro mě zůstává, hned po FreeBSD alternativou č. 2. Není to špatné, ale škoda ztráty pozice favorita.

Ač bych do toho politiku netahal, tak to mám stejně. FreeBSD je dneska už pro mě na prvním místě, Debian na druhém. Systemd nezatracuju, ale nelíbí se mi cesta, kterou se dostal na světlo.

Co se týče Debianu, tak myslím, že by bylo správnější udělat fork distribuce, kde část bude jen na systemd a to poctivě a druhá (třetí, čtvrtá) bude poctivě podporovat jiný init. Aktuální kočkopes, kdy fakticky není zcela podporován žádný z init systémů a balíčky nejsou připraveny na daný init, nepovažuji za šťastnou situaci.

V posledních letech jsem narážel na to, že ruzné debian helpery pro konverzi mezi init.d skripty a unitami napáchaly více škody než užitku. Některé unity jsem si napsal sám, protože buď neexistovali (jen přes generátor) nebo byly špatně napsané. To už je lepší používat čistě systemd distribuci.

Patřím k těm co by uvítali "...a druhá (třetí, čtvrtá) bude poctivě podporovat jiný init..." Sám se v tom potácím někde na konci uživatelského řetězce a ještě míň vím o freeBSD. Ten kdo by měl vyhlásit root.cz odklon správným unix směrem jste Vy GURUové pod vedením zvoleného předsedy, navrhuji p.Krčmáře:) Chápu ale jak je to náročný:(

Osobně nemám jasno zda lze napsat tohle: "Ano, můžeš v tom turingovsky úplném shellu například implementovat funkcionalitu systemd".
A-politicky systemd vidím jako něco připomínající diktát EU a nátlak velkých korporací ke škodě svobodného SW, který může mít jedinec plně pod vlastní kontrolou.

správným unix směrem

Otázkou je, co to je. Jedna ze základních myšlenek unixu je vytvářet jednoduché programy, které budou dělat jednu věc a budou ji dělat dobře a budou se umět propojit s ostatními programy. V "klasickém" pojetí se mělo na mysli např. propojení více programů pomocí roury. Jenže to se nestalo samo od sebe a k tomu byl potřeba shell. Takže v interaktivním skriptovacím jazyku (který rozhodně není jednoduchý) se něco lepilo.

Systemd tomuto vůbec nijak nebrání. Je to jiný druh lepidla. Naopak, the systemd way je dělat malé unity (service), spouštějící se podle událostí a reagujících na ně. A můžou být vzájemně propojeny pomocí socketů.

To skutečně není nic proti unixu. Ano, systemd je moloch a možná časem se rozpadne na víc částí, které by mohly transparentně komunikovat třeba pomocí nějaké sběrnice. Co já vím.

A mě osobně toto pojetí (v tom co já dělám) příliš nevyhovuje. Mám rád staticky nastartované služby a jednoduché a rozumně udržované rc skripty. Tak jednoduché, že implementace jailů ve freebsd byla procházka růžovým sadem. A toto mám rád. Místo radikálních změn to dělat dobře (možná pomaleji, ale dobře) a následující změny budou jednoduché. U FreeBSD mám pocit, že u návrhu base systému někdo skutečně přemýšlel. Což se o některých distribucích linuxu říci nedá.

Osobně nemám jasno zda lze napsat tohle: "Ano, můžeš v tom turingovsky úplném shellu například implementovat funkcionalitu systemd".

V každém turingovsky úplném jazyku lze napsat totéž, co ve kterémkoliv jiném turingovsky úplném. Jen je otázkou, zda je to vhodné. Každý jazyk má jiné vyjadřovací prostředky a ne každý se hodí na každý úkol.

připomínající diktát

A politiku bych do toho fakt vůbec netahal. systemd představuje zcela legitimní koncept jak věci dělat a jen by jim slušelo více a lépe vysvětlovat, kam to chtějí směřovat (např. dynamické spouštění služeb na základě událostí místo statického při bootu), možnost ovládání služeb i z jiných zdrojů (dbus, socket activation) apod. Systemd není žádná černá skříňka na magii a rozhodně jej má jedinec plně pod kontrolou. A bugy v implementaci jsou a najdou se u každého programu.

To je pochopitelne, pretoze FreeBSD je stale UNIXom. Linux ale unixom nikdy nebol, iba tak vyzera a snazi sa o POSIX. Inak si ide svojou vlastnou cestou. https://en.wikipedia.org/wiki/Unix_wars#/media/File:Unix_timeline.en.svg

pak je tu třetí možnost: opustit systemd a pořádně máknout na kompatibilitě alternativních initů

To je jistě možnost. Teoretická.

Obávám se, že na to už je pozdě ... ale mohli by využít service.unit ke generování init scriptů pro ostatní initd.

... ale ani to asi nepůjde, systemd se hrabe do příliš mnoha věcí a často se systemdmagií ...

Popravde za celou dobu co distribuce pouzivaji systemd jsem s tim nemel zadny problem (s vyjimkou nutnosti nastudovat si, jak se to konfiguruje).

"systemdmagie" znamena, ze to funguje, ale nenastudoval jsem si proc a jak. zatim co klasicky init moc nefunguje, ale aspon se verejne vi proc a jak. nahradit takovym ne-uplne-funkcnim init systemem funkcni systemd je pak nemozny, pokud clovek nenapise vlastni init, kterej bude komplexni jako systemd.

To ze systemd integruje spoustu veci je trochu blby z hlediska politiky, protoze hromadi zodpovednost. Nicmene mi to vyresilo spoustu problemu s kompatibilitou a podporou. napriklad demon na ntp synchronizaci funguje v systemd lip nez jakykoliv standalone, ktery jsem pouzival predtim.

"zatim co klasicky init moc nefunguje"
V skutocnom Unixe, konkretne AIXe, ktory ma klasicky init a pouziva sa na mnozstvo kritickych 24/7 servroch napriklad v bankovom prostredi, s initom ziadny problem nie je. Tak neviem, kde "soudruzi udelali chybu".

Je skupina lidí, kteří si pořád stěžují na problémy se systemd, a pak je skupina těch, kteří na žádný takový problém nenarazili. Nemám na to žádná data ale připadá mi dost možné, že k těm problémům dochází, když se člověk snaží i po zavedení systemd dál používat systém v unixovém stylu, tj. spravovat služby pomocí skriptů, nastavovat síť pomocí ifconfig nebo ip atd. To celkem pochopitelně koliduje s tím, co "pod povrchem" dělá systemd. Jako takový mi systemd připadá dobrý, ale je jisté, že predstavuje skutečně určitý zlom a přerod od Unixu k něčemu jinému. Osobně mi tento zlom připadá velmi žádoucí.

Je to proto, ze AIXovy init vsechnu praci hodil ne nekoho jineho. Napr:

• AIX device manager pro spravu HW
• AIX ma dve faze bootovani a vzdy bootuje s initrd
• Autor ovladace rozhoduje ve ktere fazi bootovani se ovladac nacte
• Konfiguracni nastroje pro ovladac jsou soucasti baliku ovladace
• "udev" pravidla (anebo neco podobneho) pro detekci HW jsou soucasti baliku ovladace

Diky tomu, ze si AIX udelal poradek nekde jinde, nemusi resit problemy jako soucast init-u.

Jasně, nefunkční sysvinit a vždy funkční systemd. Zrovna dneska na Twitteru:

https://twitter.com/JirkaChadima/status/1174634408231473152

A takových věcí je plný Internet.

To víme, že je takových věcí plný internet, ale nikdo jim nebude věnovat pozornost, protože to je jen výkřik do tmy. Není tam ani napsané co se vlastně stalo, takže není možné říct, zda to je chyba systemd a nebo toho člověka, který si v každém postu na Twitteru na něco stěžuje dost svérázným způsobem.

> "systemdmagie" znamena, ze to funguje, ale nenastudoval jsem si proc a jak.

Ne, systemdmagie znamená, že mi došel kinedryl a další paletu kupovat nehodlám.

> To ze systemd integruje spoustu veci je trochu blby z hlediska politiky, protoze hromadi zodpovednost.

Není to trochu blbý, je to hodně blbý. Korunu tomu nasazuje arogance vývojářů.

> "systemdmagie" znamena, ze to funguje, ale nenastudoval jsem si proc a jak
dobrá ... a teď do reality

init se má starat o nahazování a shazování služeb

Proč se ale proboha stará o DNS a NTP? To má nechat systému nebo příslušnému démonu.
SSH v systemd je úplná hovadina a už.loginy přes init démona ... škoda slov.

To co je předváděno v systemd je vlastně to samé co je velká slabina Windows - monolitická struktura na které vše stojí a padá.

Asi je na čase se trochu vzdělat, než psát blbosti: https://www.youtube.com/watch?v=o_AIw9bGogo

Já systemd na většině strojů používám a o DNS ani NTP se mi nestará. O dané věci se starají programy z daného balíku, které jsou ale oddělené a můžeš je nepoužívat (na Debianu je dokonce jejich nepoužití default, alespoň v minimální instalaci). DNS mám jako veřejný resolver odkázaný v ručně napsaném /etc/resolv.conf a na NTP mám někde openntpd, někde ručně spouštěné ntpdate; systemd-resolvněco ani systemd-timesyncd mi nikde neběží. (pozn. tohle není obhajoba systemd, osobně mi přijde z různých důvodů špatný (naštěstí se většina z nich postupně zlepšuje), ale když chceš kritizovat, bylo by dobré dělat to podle skutečnosti)

"systemdmagie" znamená, že to funguje, což je fajn, ale jakmile se to rozbije (a věci se prostě rozbíjejí, a to klidně chybou admina, ale ten musí mít možnost na svou chybu přijít), tak je kvůli architektuře tohoto software značně komplikované zjistit, čím to přesně je, a jak to opravit.

Pokud by existoval init, který umí řešit závislosti jako systemd tak proč ně, ale já třeba příchod systemd vítal, v základu řeší spoustu věcí co se v init.d dělali špatně nebo nešli vůbec dořešit.

> v základu řeší spoustu věcí co se v init.d dělali špatně nebo nešli vůbec dořešit.

Tak moment, v init.d (sysvinit) měl člověk shell, a ten je - pokud se nepletu - Turingovsky úplný. Co za problémy nešly dořešit v sysvinit? Neumím si to představit...

Na druhou stranu je systemd překomplikovaný systém, který mění léta zaběhlé defaulty, živí se na parametrech jádra, používá přinejmenším zavádějící pojmy v konfiguraci...

@ravise

Ano, můžeš v tom turingovsky úplném shellu například implementovat funkcionalitu systemd

Aha, děkuji za konstruktivní příspěvek. Pokud by to ale někdo přehlédl, otázka zněla "Co za problémy nešly dořešit v sysvinit?"

Problém systemd je, že odpůrci se snaží argumentovat, ale ve výsledku předkládají nesmysly.

překomplikovaný systém - Vždyť to je jen nějaké hloupé video.
zaběhlé defaulty - Neexistuje něco jako zaběhlý default a v tomto případě se podle mě systemd chová lépe než jiné inity
živí se na parametrech jádra - Nakonec to bylo vyřešeno.
používá přinejmenším zavádějící pojmy v konfiguraci - Tohle asi není úplně přesně popsaný, protože ten uživatel použil nevalidní username. xinted mu to sežral a systemd ne.

> překomplikovaný systém - Vždyť to je jen nějaké hloupé video.
Ano, a s touhle logikou je systemd jen hromada hloupého zdrojového kódu. Tady už snad ani nemá smysl se dál bavit. Ale pro případ že bych si to vyložil stoprocentně blbě - to video hezky ilustruje, co všechno systemd nabaluje na init.

> zaběhlé defaulty - Neexistuje něco jako zaběhlý default a v tomto případě se podle mě systemd chová lépe než jiné inity
Něco jako zaběhlý default zcela jasně existuje. Například roky nepřítomnost nějakého "fail" parametru v fstab znamenala, že když daný disk nejde připojit, jede se dál (tedy "výchozí" nofail). Systemd to překopal, z podlahy vyrobil strop a všechny disky jsou ve "fail" režimu. Tadá, fakjů.

> živí se na parametrech jádra - Nakonec to bylo vyřešeno.
Ano, nakonec. Nakonec jsme se zbavili i komunismu. To nic nemění na tom, že příčetný vývojář by takový kód neměl napsat a příčetný správce změnu začlenit.

> používá přinejmenším zavádějící pojmy v konfiguraci - Tohle asi není úplně přesně popsaný, protože ten uživatel použil nevalidní username. xinted mu to sežral a systemd ne.
Když do konfigurace napíšu "user = někdo", očekávám, že ta služba poběží pod uživatelem "někdo" a pokud to z jakéhokoliv důvodu nepůjde, tak se nic nespustí a já dostanu vynadáno chybovým hlášením.
Rozhodně neočekávám, že "když to nepůjde, tak se username zkusí převést na user ID a služba se nakonec spustí pod tím".
Nehledě na to, že podle POSIXu (cituji):
3.437 User Name
A string that is used to identify a user; see also User Database. To be portable across systems conforming to POSIX.1-2017, the value is composed of characters from the portable filename character set. The <hyphen-minus> character should not be used as the first character of a portable user name.
A to je právě hezký příklad překomplikovanosti systemd: proč ten kolos musí určovat, jestli je username validní - pokud takový uživatel existuje, je validní, pokud neexistuje, není to chyba validního username, ale chyba neexistujícího uživatele.

I když Linux není Unix a není POSIXem vázaný, základní linuxové nástroje (useradd, adduser) dovolí takového uživatele vytvořit. Ale existující ve světě systemd neznamená validní...?
Navíc viz vyjádření vrchního diktátora systemd, ve kterém zcela jasně nerozumí základům množin... Pokud má být unitfile přenositelný mezi liberálními a konzervativními distribucemi, neměl by systemd uvalovat žádná další pravidla nad rámec té nejliberálnější distribuce. Protože jinak přijde chvíle, kdy unita zařve (a ještě zařve takhle nesmyslně hloupě).

Ještě stále mojí snahu o argumentaci považuješ za nesmysl?

“Slysitelne prskani” tak nejak vystihuje miru respektu kterou ma autor k vyvojarum Debianu. Stavet odpurce systemd do jakesi sebemrskaccke role minority s potrebnou inkluzi je usmevne. Je treba mit na pameti ze jakkoli organy rozhodnou, nic to nemusi zmenit protoze jen velmi malo prace podleha review. Tim nerikam ze to nezafunguje ale proste nemusi. Balikovani je drina a kazda uleva je vitana.

na Gentoo stale fici OpenRC. pouzival som to viac ako 10 rokov a nemal som s tym ani raz problem. SystemD je dost precenovane.

A OpenRC nefičí jen na Gentoo, ale i na jiných *nixech (na rozdíl od systemd, které je pouze linux only)

Toto je zajímavá informace k zamyšlení: Ponechání init.d udrží Debian flexibilnější „platformou operačních systémů“ .
Je pravda, že Debian se dá používat v podstatě všude.

Mám na to dva pohledy.

První je pohled člověka, který potřebuje počítač k práci a zábavě. Tam mi je jedno jestli skripty spouští systemd nebo malí skřítci. Chci aby počítač fungoval a umožnil mi dokončit práci.

Druhý pohled je ze strany admina/iťáka kdy chci mít plnou kontrolu nad tím, co v systému mám a co se tam děje, na úkor všeho ostatního. To je třeba proč jsem měl dlouhá léta gentoo a vyhýbal se systemd jako čert kříži.

V dnešní době je trend dělat vše pro první případ. Je to vidět na systemd, nebo i windows 10, androidu a třeba apple to razí téměř od začátku.

Abych neutekl od tématu, co je nejlepší pro debian...těžko říct, mám debian už všude se systemd a přes pár problémů co jsem s tím měl to holt funguje.
Možná by se mohli vydat cestou forku na debian-systemd a debian-openrc, ale nevím jak by se pak daly udržovat balíčky mezi jednotlivými odnozemi. Jedině mít mezivrstvu s nějakým init-generic api, do kterého by se zapojil init jaký chceme? Ale jak by to pak fungovalo...?

SystemD, narozdil od cehokoliv jineho, nasadil predevsim v plnem rozsahu cgroups spolu se spravnou inicializaci MAC. Ty jsou nutne pro containery a chteji je velci hraci, takze se z toho neuhne. Bohuzel si s nimi chteji hrat i male deti, ktere nevidi bezpecnostni rizika a spoustu dalsich dusledku. Takze na Linuxu proste systemd bude a prevalcuje vse ostatni - to je (budouci) realita. Jak to zdegeneruje/zah­lti/otravi zacatecniky, kteri s Unix-like systemy teprve prijdou do styku si nedovolim odhadovat.

Sam se primlouvam za to, aby na svete zustal aspon jeden Unix-like system, ktery se tomuhle kontejnerovemu silenstvi vyhne, anebo ho zrealizuje jinym, lepsim zpusobem. Linux to ale uz nebude.

V AIXe su implementovane nativne kontainery (nazyvaju sa workload partitions), ktore umoznuju limitovat spotrebu resources podobne ako cgroups a to vsetko funguje v ramci systemu, kde sa pouziva klasicky init.

Bohuzel si s nimi chteji hrat i male deti, ktere nevidi bezpecnostni rizika a spoustu dalsich dusledku. Takze na Linuxu proste systemd bude a prevalcuje vse ostatni - to je (budouci) realita. Jak to zdegeneruje/zah­lti/otravi zacatecniky, kteri s Unix-like systemy teprve prijdou do styku si nedovolim odhadovat.

To jste popsal velmi přesně. Linux byl dlouhoju dobu atraktivní pro jednu sortu adminů / uživatelů, kteří neměli trpělivost se naučit správně spravovat Windows. Se systemd přišla podobná komplikovanost do linuxu a je tedy logické, že tomuto segmentu uživatelů se ten posun nelíbí. S trochou nadsázky, pro tyto "ortodoxní" unix(-like) adminy je systemd podobné zlo, jako je nutit učit se Active Directory, NTLM, GPO a další komplikované (pokročilé) technologie.

Spravovat správně a bezpečně holý systém není úplně jednoduché. Mnoho lidí si pod pojmem "bezpečnost" představuje to, že mají zapnutý firewall, mnohdy ještě "bezpečnostně posílený" NATEM na routeru. (Mimochodem, na IPv6 spousta adminů používá znovu NAT, ačkoliv IPv6 vzniklo od toho se NATU vyhnout - ale nikdo si netroufne do zoufale nezabezpečených koncových uzlů pouštět ostrý internet). Bezpečnost ale taky znamená celky segmentovat, segregovat uživatele a oprávnění (ne, že všechny servicy běží pod rootem nebo je vše nivelizováno sudem). Software je potřeba aktualizovat (dávno neplatí, že co funguje, na to se nesahá). ..., ..., ... Dobře zabezpečený systém aby člověk pohledal.

Kontejnery jsou v tomto ohledu opravdu šílenství. Dnes si kontejnery instalují programátoři a skoro-ne-admini podle kuchařek na internetu. Vzniká tu obrovská bezpečnostní díra. Co základní operační systémy roky pilují - aby bezpečnost byla výchozím stavem, aby aktualizace bylo možné provádět bez osypek, že se vše rozpadne, ..., to vše nám kontejnery znovu vzaly. A my tomu ještě tleskáme. Děsím se doby, až do nějakého populárního image někdo vpašuje backdoor - víme z praxe, že i velké bezpečnostní chyby zůstávají léta nepovšimnuty. Kdo by pitval image až do posledního atomu?

Takže za mě, kontejnery do produkce nepatří, nebo jsou tak drahé na údržbu, že to většinou setře tu původní motivaci je používat (v praxi se setkávám s kontejnery vnímanými jakožto rychlé, levné cesty). Většinou dokážu najít nekontejnerové řešení téhož problému levněji (při zachování stejné bezpečnosti).

Na druhou stranu, kontejnery jsou super pro vývojáře. Rychlý deploy určité verze a prostědí se hodí při práci na různých projektech. Tam je jejich přínos opravdu velký.

Boj admina je pak uvnitř firmy. Umět vysvětlit, že opravdu nelze jen vzít kontejner od programátora, někam ho nahrát a do hodiny běžet v produkci. Vždyť ten programátor tvrdí, že to takhle dělá a funguje mu to, tak proč nějaký admin říká, že takto to nejde?

Jak jste psal, kontejnery jsou super pro velké hráče, kteří dokáží bezpečnost zajistit hromadně, hromadně nasazovat a udržovat. Tam mohou přicházet zajímavé úspory z rozsahu, aniž by byla bezpečnost narušena. Ale kolika promilím z nás se podaří do takového prostředí dostat?

21. 9. 2019, 08:07 editováno autorem komentáře

Jsou kontejnery a kontejnery. To, co popisujete, se týká hype kolem dockeru a ano, máte pravdu. Ale i docker se dá dělat dobře a automatizovaně, včetně bezpečnostních update.

Osobně doporučuju používat kontejnery (lxc, systemd-nspawn, freebsd jaily) jak jen je to možné. Tedy mít na HW jen nezbytné minimum a všechny služby provozovat v kontejnerech výše uvedeného typu.

Proč. Už jen z důvodu oddělení konfigurace. MX server přece jen vyžaduje jiné nastavení než webserver a moloch typu gitlab sice lze nainstalovat po balíčcích a umístit společně s dalšími 50 službami na stejný server, ale pravděpodobně z toho admin zešílí.

Kontejnery umožňují jednoduché oddělení konfigurace pro to které nasazení. Navíc takto velmi snadno a elegantně můžete oddělit skupiny služeb a IP, na kterých budou poslouchat (tj webserver z MX serveru bude na jiné IP než webserver pro obecné weby - ano, lze v každé jednotlivé službě nastavit listen a bind apod. ale uzavření do kontejneru je jednodušší a zřejmé).

Další věcí je oddělené zálohování. Stačí udělat snapshot toho kterého kontejneru a dumpnout jej na zálohovací server. Každý kontejner lze zálohovat jinak často. Obnova jednoho kontejneru nijak nezasáhne ostatní služby v jiných kontejnerech.

Velmi snadno se to přenáší na jiný server. V případě systemd-nspawn stačí udělat btrfs send na jiný stroj (případně použít příslušný machinectl příkaz), překopírovat jeho konfigurák a spustit. (jaily totéž v bledě modrém, zfs send, jail.conf a je to). Opět, zkuste si zmigrovat jednu službu ze serveru, kde jich máte 50. Musíte udělat dump konkrétní db, konfig pro vhosta, bind na ip apod. Když je to v kontejneru, tak jej prostě pustíte jinde a je to.

Takto by se dalo pokračovat dál. Ano, je to víc práce z hlediska třeba update. Místo jednoho stroje jich updatujete 20 a to už chce třeba nějakou automatizaci. Na druhou stranu, pokud se update jednoho kontejneru nepovede a je nutné jeho služby nastavit pro novou verzi, tak se lze opět zaměřit jen na jeden kontejner a dalších 19 je v klidu.

Každý admin musí zvážit výhody a nevýhody. Pro mě výhody převažují.

Jsou kontejnery a kontejnery. To, co popisujete, se týká hype kolem dockeru (...)
Každý admin musí zvážit výhody a nevýhody. Pro mě výhody převažují.

Naprostý souhlas, dělám to tak stejně. Mě se třeba týká to ZFS a jail, to používám.

Moje kritika směřovala k tomu, že (jak jste správně poznamenal) docker zažívá hype a lidé si to ztotožňují s tím, že něco-kliknu-ejhle-ono-to-jede.

Nastavit např. FreeBSD jail taky není jen tak, minimálně než si na to zavedete pravidla. Docela zajímavé je na base system zavést deduplikaci, protože base files jsou opravdu totožné napříč všemi jaily. Musíte se rozhodnout, jak bude fungovat síťový stack, jestli bude v jailu společný s hostem, nebo jestli bude nezávislý. Podle toho se musí správně nakonfigurovat pf, které se konfiguruje NAD jailem, ne v něm.

...a to všechno, a mnohé další, už je práce admina a ne nějakého klikoše, který si stáhne docker a pak vám vykládá, že admin už není potřeba...

Osobne bych doporucoval nasazovat kontejnery (na Linuxu) jen po zrale uvaze a za prihodnych podminek, nikoliv jak jen to je mozne. Mnozstvi brutalnich bezpecnostnich der v poctu az desitek rocne, minimalne na urovni der Intelskych procesoru, fakticka eliminace SELinuxovych ohradek pro bezici sluzby a pridani dalsi vrstvy do sitove trasy by mi za to v produkci nikde nestalo. Zisk v podobe swarm modu je pro mne bagatelni, protoze zaklad (veskere diskove overlay i snapshoty) zvladnu se SAN a HW virtualizaci, pricemz swarm mod vlastne vubec nikde nepotrebuji. Prinos kontejneru vidim tedy minimalne v mem prostredi jako zanedbatelny, radsi mam HW virtualizaci.

Kiežby bol systemd len init či service manager.

https://systemd-free.artixlinux.org/img/systemd-devours-all.gif

podle me je resenim, nechat Debian ciste s systemd a cast maintaineru co by se jinak staralo o non-systemd kompatibilitu by mohla pomahat oficialne s Devuanem...

Vidim to stejne. Uz tu ten fork je; a systemd je stejne v Debianu vychozi moznost, takze by to bylo zbytecne predelavani distra.