Kvůli tomuto jsem po víc jak 10 letech odešel od Debianu a přešel na všech strojích (kromě starého serveru, kde nemám dost času a náladu) na Funtoo. Od té doby jsem bez systemd a bez komplikací s tím spojených. A i když mě Gentoo based disto trochu děsilo, zjistil jsem, že je tu spousta problému se závislostmi paradoxně jednodušejších na řešení.
Podobny problem som riesil vcera na XFCE, len s trocha menej zjavnymi priznakmi.
xfce4-power-manager v Manjare vyzaduje upower, ovsem nie lubovolnu verziu, ale 0.99 a viac. Upower 0.99 vyzaduje systemd. Instalacia s upower 0.9.23 je naviac mozna, power-manager ale nebude fungovat... Nakoniec som si musel power-manager kompilovat sam.
systemd je mor :(
Po přečtení bugreportu jsem přesvědčen, že celá záležitost má se systemd pramálo společného. Maintaineři Devuanu distribuují rozbitou kombinaci balíčků, kvůli které v KDE nefunguje uspávání. systemd, KDE upower ani ConsoleKit2 za nic nemohou. Že se tím vývojáří KDE odmítají zabývat je podle mě zcela v pořádku a Mathieu Roy v komentářích jen tupě trolluje proti systemd, protože maintaineři jeho anti-systemd distra si neumí zkontrolovat závislosti PowerDevilu.
Je to super, ze konecne sa veci zacali zjednocovat, a ze to ci mi funguje uspavanie a podobne banality(ktore BFU povazuju za beznu vec) uz nebude zavisiet od pouziteho grafickeho frameworku. To ze nejake pokrocilejsie prostredie potrebuje k behu systemd je potom logicke. Proste GUI je dalsia aplikacna vrstva, ktora je nad nizsou vrstvou. SystemD Rulezzz!
Mno takže protože už nějakých 30 let používáme klasické filesystémy, ať se nikdo ani neodváží pomyslet na BTRFS nebo ZFS. A co ty multijádrové procesory? Unix přece taky neměl SMP a jak to krásně fungovalo... Nejhorší je ale wayland a mir, co pořád melou o nějakém uživatelském rozhraní, to je jako windows, linux nesmí být nic jiného než unix a to znamená vi a maximálně latex. Multimedia, hry, web, kancelář, to přece na unixu 20 let nebylo, tak co s tím furt mají. Jo a taky ten python, na unixu se přece 20 let programovalo v C, a teďka mi najednou vnucují pythoní interpret když chci používat nějakou apku... Fakt hrůza, ještě že NetBSD 1.0 se pořád ještě dá stáhnout.
;-)
Systemd je dneska normální součást základního systému a je to tak dobře. Posedlost představou, že desktop má fungovat bez něj, je asi tak na stejné úrovni jako trvat na tom, že to má fungovat bez kernelu (a proklínat Linuse za to, že mi "vnucuje" ten svůj linux). Někdo se holt ještě nedokázal vyrovnat s tím, že od dob SVR4 se vývoj o notný kus posunul a od operačního systému se toho dneska čeká víc, než od klasického unixu.
Není to normální součástí, ale je to jednou z nejkontroverznějších věcí v Linuxu. Je to zcela proti základní filozofii a přibližuje to Linux k Windowsu. Chování se mění častěji, než si Poettering mění ponožky a i když se zrovna nemění záměrně, je stejně nepředvídatelný - aneb dělá to přesnej opak toho, na co to mělo původně být. Nápady typu "raději haltnout celej systém, než přeskočit triviální chybu", to prostě nezkousnu.
Ziadna taka otazka nepadla. Ja som reagoval na tvrdenie, ze ovladanie sluzieb bez initu pojde dost tazko :)
Mimochodom, pri tom kopirovani z Wikipedie si vynechal zvysok vety. "... that works with the system-provided init program, normally /sbin/init; however, it is not a replacement for /sbin/init."
Nefunguje to u zadny sluzby, co nechapes na tom, ze to, ze neco je v pameti a ma to status "bezi" neznamena vubec nic? Co ti bude platnej bezici apache, kdyz nebude odpovidat na requesty?
Kdyz potrebuju aby neco bezelo a pripadne se to restartlo, tak potrebuju neco dalsiho, co to bude at uz lokalne nebo vzdalene kontrolovat. A systemd to rozhodne neni.
"je asi tak na stejné úrovni jako trvat na tom, že to má fungovat bez kernelu"
Bez kernelu by to nešlo, ale je možnost ten kernel nahradit jinou implementací. Zrovna Debian umožňuje instalaci s kfreebsd. Takže požadavek je to zcela přirozený a opodstatněný. Je definováno nějaké rozhraní, které, pokud jej všechny komponenty dodržují, vede k tomu, že je možné libovolnou komponentu nahradit jinou implementací. Toto v userspace děláme neustále. Nelíbí se mi implementace něčeho od A, tak tam dám implementaci téhož od B. Ostatně, na BSD běží v podstatě totéž do na Linuxu. Včetně grafických prostředí. Takže neexistuje důvod to vázat na komponentu, která funguje jen jedné implementaci kernelu (zrovna linux) a ztížit si tak přenositelnost (která tu je od počátku těch projektů).
Nikolive, ale tu tupec jirsak nemuze chapat. Systemd totiz nema zadne (natoz stabilni) api. A chovani jednotlivych komponent se zcela zasadne meni v zavislosti na tom, jak se zrovna ten kreten vyspi.
Nadto, kdo by si do systemu, od ktereho ocekava, ze bude proste fungovat, daval srackomet, kterej by design predpoklada, ze veci fungovat nebudou a jeste to vykazuje jako ficuru, kdyz opravdu nefugujou.
Nevsim sem si, ze bych v pripade pouziti openrc/sysvinit/ ... musel pouzivat nejakej konkretni logovac, kupodivu si muzu vybrat z hromady kterej se mi libi, divny co? Stejne tak muzu pouzit libovolnej cron, dhcp klienta, ntp, ... a sestavit si vse dle vlastnich prani a predevsim potreb. Aha ... ono to ma deklarovany API a tudiz je to zamenitelny ... ZAZRAK.
Vsetky dve myslis? Systemd je vyvyjany pod Redhatom, takze Fedora je jaksi samozrejmostou a do debianu ho pretlacili asi v niekoho slabej chvili... Ostatne "velke" distra sa pridali jednoducho preto, ze udrzovanie rozdielneho init systemu ako ma parent distro je docela problem i v pripade, ze ten init system _nieje_ zrovna systemd.
Linuxových distribucí je poněkud více než dvě. Kupříkladu Arch Linux žádné "parent" distro nemá, OpenSUSE, Mageia či Gentoo také ne. Naopak Canonical určitě prostředky pro udržování Upstartu v Ubuntu má a stejně jej opustili ve prospěch systemd. Trochu přemýšlení při konstruování vašich argumentů by neškodilo.
systemd úspěšně řeší věci, na které se v Linuxu roky zoufale kašlalo. Je to vždycky stejné, ať už jde systemd, PulseAudio, Wayland nebo libovolný jiný projekt, který se snaží řešit problémy předchozích řešení tím, že přijdou s výrazně jinou koncepcí. Pokaždé se zvedne vlna odpůrců, jenž budou tvrdit, že současný systém je vlasně naprosto v pořádku, byť se na něj až do příchodu nové alternativy nadávalo zleva zprava.
(Ještě vtipnější je psát tento příspěvek pod článek, který se systemd souvisí jen marginálně.)
systemd úspěšně řeší věci
Můžu se zeptat, kolik strojů spravujete? Kolik jich je se systemd? V praxi se o tom "úspěšně řeší" dá totiž silně pochybovat (včetně konkrétních příkladů).
PulseAudio
Aha, tak jestli PA považujete za úspěšné řešení čehosi, tak potom chápu, že i systemd. Já mám poněkud jiné nároky, mezi které patří i to, že chci plně využít HW za $1, který je na všech základních deskách a který je považován za low end. S Alsou bez problémů. S PA ani omylem.
Pokud se vám chce trávit čas tím, že zprovozňujete zabugovaný HW za 1 $…
:-D
Řeč je o zvukových čipech z rodiny Realtek ALC. Všechny umí 192kHz/24b. Zkuste si to nastavit v PA.
Jestli ALC nevoní, tak můžu nabídnout profesionální karty v ceně několika tisíc (ne dolarů, ale korun). Standard 96kHz / 24b. Zkuste si to nastavit na PA.
Nebo poněkud méně rozšířený standard 88.2kHz. Zkuste si to nastavit na PA.
Jediné, co na PA reálně funguje je default 44.1(48)kHz/16b. Nic víc.
Proč?
Zcela vážně, proč? Tohle alsa někdy uměla? A měla by to vůbec umět? Je toto správná vrstva k řešení těchto věcí?
Jako je hezké, že PA přišel s novými featurami. To je fajn. Pokud implementace těchto vlastností vyžadovala ustoupit od dejme tomu výkonnostních parametrů, tak jako ok (věci jako BT stejně moc hifi zatím nejsou). Jen to nikde není deklarováno. Naopak se všude deklaruje, že PA vyřešil problém se zvukem.
Ostatně mohu běžet jen na alse... počkat, mohu? No mohu, ale dnešní grafická prostředí mají silné závislosti na PA. Mohu si také zvolit jiné prostředí (prostě utéct). Takže ano, mohu nastavit PA tak, aby se nevšímal nějaké zvukárny ... no ale proč tam to PA teda je? A proč se ho nemůžu snadno zbavit? Ostatně zvukových serverů je víc, nevšiml jsem si, že by mi někdo nutil třeba jackd (který je v mnoha ohledech lepší). To, jestli si ho vyberu nebo ne, je pouze na mém uvážení.
Úplně stejné odpovědi jsou i o systemd. Nemusíš to používat. Jasně, nemusím, ale musím to tam mít. A je čím dál těžší to tam nemít.
Ale to je naprosto v pořádku. Pokud někdo PA využije, ať si jej nainstaluje. Já jsem rád, že je k disposici, stejně jako jsem rád, že v repu je dalších 35tisíc balíčků, protože je mohu kdykoliv použít, pokud je budu potřebovat pro řešení nějaké situace. Já nikomu PA neberu.
Ale proč má být nainstalovaný na systému, kde se nevyužívá? Proč se jej nemůžu snadno zbavit? Obrazně řečeno, proč mi jej někdo nutí(ve smyslu je stále těžší se toho zbavit)? Stejně drtivá většina věcí jede s PA přes alsa interface (default pcm device).
Ehm ... viz vejs, mam pripojeny 3 zvukovky, kazda disponuje nekolika vstupy/vystupy a prepinat si je (nad alsou) muzu jak chci, staci kdyz to umi aplikace a lecktera to umi.
A BT headset === USB headset, zprovozneni lusknutim prstu. Dokonce to funguje podle ocekavani i kdyz se to odpoji.
Pokud to aplikace umí. A leckterá to neumí. Proč by to vůbec měla řešit aplikace? Řeší snad aplikace také to, jestli zapisuje na SSD nebo magnetický disk?
BT headset není USB headset s bezdrátovými sluchátky. Navíc třeba přepínání mezi A2DP a headset profily se v ALSA dělá změnou konfiguráku (ke kterému má samozřejmě přístup jen root) a restartem.
Řeší snad aplikace také to, jestli zapisuje na SSD nebo magnetický disk?
V některých případech ano. Aplikaci lze říct, jak drahý je náhodný přístup oproti sekvenčnímu a aplikace se podle toho zařídí. U SSD jsou poněkud jiné parametry iopsů než u hdd. Aplikace se potom může lépe chovat k danému typu zařízení a třeba přečíst raději data sekvenčně, i když z nich potřebuje jen část. Přístup přímo na jednotlivé bloky by byl pomalejší.
Některé rozmazlenější dokonce mají více druhů dat a pro některá je lepší použít ssd a pro jiná hdd.
Takže ano, některé aplikace to řeší.
Stejně jako některé řeší rozdílné zvukovky.
Výjimka, výjimka... Já si tak jen říkám, jestli náhodou celý linuxový ekosystém není právě na výjimkách postavený. Jestli náhodou neřeší některé věci mnohem lépe právě proto, že je umožňuje řešit jiným způsobem. Protože neexistuje univerzální způsob, jak ty věci řešit. A že je velkou chybou se snažit to svázat do nějakého jednoho způsobu. Protože ten bude fungovat někde, ale totálně selhávat jinde. Dosud si admin na každý případ mohl ten systém přizpůsobit, jak potřeboval.
Vy mě fakt dneska bavíte :-D
Schválně si to vyzkoušejte a dejte nám vědět výsledek. ;-) To, že jsou někde na webu vytažené 3 řádky z confu, které jsou asi tak to první, co nastavíte když to chcete nastavit, opravdu neznamená, že to funguje. Prostě to nefunguje. Nepomůže ani realtime. Ani nastavení bufferů. Co s alsou a dmixem funguje out of box, na PA prostě nefunguje.
Mohl by jste mě prosím taky pobavit? Jsem majitelem ALC chipu a v návod dle Google mi funguje v PA na první šup. A to nejsem 2x příznivcem PA, některé věci se mi tam dost nelíbí, ale není daleko doba, kde si pamatuju daleko nepříjemnější problémy s alsa only desktopem, třeba ohledně mikrofonního vstupu. Takže asi tak.
Co znamená (ne)funguje? Jako nastavit to tam jde, restartovat pa jde, pustit jeden stream jde. Pustit druhej stream už skoro nejde (dochází k výpadkům). Pustit si jeden stream (třeba jen hudbu, ideálně video třeba s koncertem) a třeba hru (kde už vás interní hudba omrzela) prakticky nejde. Pochopitelně se bavíme o stavu, kde jednotlivé streamy mají jiný samplerate (typicky menší), než je zvolený 96/24 a je potřeba je upsamplovat.
Na rozdíl od alsy, kde všechno toto funguje i se src-best, u pa toto nefunguje ani vyšší speex ani default speex.
Arch sice oficialne parent distro nema, kopiruju ale kazdy nezmysel, s ktorym redhat pride. Systemd v Archu bol nasadeny prave s tymto argumentom.
Systemd, PulseAudio a Wayland maju skutocne spolocne riesenie problemov, ktore nikto nepocitoval :) PulseAudio je z nich, myslim, najstarsie a poriadne nefunguje dodnes.
Nikdy jste nechtěl k Linuxu připojit TV přes HDMI? Bezdrátová sluchátka jste v životě nepoužil? Skutečně funkční vertikální sychronizaci nepotřebujete? Že pod X11 může by design fungovat každá aplikace jako keylogger je podle vás také v pořádku? V tomto duchu by se dalo pokrařovat dále...
Pokud vám zmíněné nedostatky nevadí, samozřejmě můžete používat to, co už existuje. Netvrďte ale, že systemd, Wayland a PA řeší problémy, které nikoho nezajímají, protože to je absolutní pitomost.
Jenže ono to neznamená jen napsat dva .desktop soubory, to je jen závěr. Znamená to taky nastavit Xka a Kodi, jelikož jaksi netuší, co mají kam posílat, dokud jim to někdo (PulseAudio a Xrandr u té automatické konfigurace, j u té manuální) neřekne. A taková sranda klidně zabere i víkend, pokud to neděláte podesáté.
Ne to jen ty netusis jako funguje kodi, zmenit vystup si muzu klidne jedinym tlacitkem primo v nem, zadny PA na to nepotrebuju a restartovat ho uz vubec ne. V XML je nastavena vychozi konfigurace a mimo jiny diky tomu se da "ikone" rict, kam se to ma poslat.
Ve tvym zcela retardovanym schematu budu porad neco nekde pepinat a jako bonus, kdyz tu appku pustim 2x, coz bez PA naprosto vpohode funguje, tak to s PA fungovat nebude nejspis vubec. Pochopitelne ze kazda spustena varianta pousti vystupy jinam ... to ubertechnika co? A nemusim nikde nic prepinat, proste staci kliknout ...
TV cez HDMI pripojene mam. Hram cez neho hry - to je jeden z problemov, ktory by Wayland vyriesil :D
Kvoli BT sluchatkam som pulseaudio kedysi davno instaloval. Po 2 hodinach konfigurovania som sa vratil k alse, kde ich stacilo pridat do aconf. Nakoniec som u PA skoncil nie pre to, ze by riesilo nejaky problem, ktory by som pocitoval ale jednoducho pre to, ze ho zacalo tvrdo vyzadovat 90% aplikacii.
Pokial nemozem na keylogovanie pouzit XSelectInput, napichnem sa rovno na /dev/input/keyboard.
Nieco dalsie?
HDMI není jen obrazový, ale i zvukový výstup, který se často tváří jako zvláštní audiozařízení. Ve většině aplikací se musí přehazovat zvukový výstup tam a zpět, s PA se jen prohodí zvukový profil.
S ALSA BT audiozařízení už nezprovozníte. BlueZ 5 ALSA interface nemá vůbec a to nemluvím o případech, kdy má BT zařízení více profilů. S ALSA a BlueZ 4 se to muselo ručně nastavovat a přehazovat v konfigurácích.
Na /dev/input/keyboard se bez roota napíchnete asi těžko, pokud nemáte hodně volně nastavená práva.
Teď ještě ten VSync, žádné zběsilé problikávání obrazovky při přechodu do fullscreenu a zpět, i skutečně funkční screenlock se v Xkách nedá udělat.
Je Vam dufam zname, ze pulseaudio riesi HDMI zvuk cez alsu? :)
Pokial Bluez 5 vynucuje zavislost na PA, pouzije sa Bluez 4. Je to len dalsi problem, ktory sa "vyriesil"
Citanie z /dev/input/keyboard ma dovolene kazdy v skupine "input", co je zaroven kazdy, pod kym chcete spustit Wayland.
Problemy s vsync, blikanim a screenlockom bude treba trochu rozviest, zatial si nie som vedomi toho, ze by som sa s nimi stretol.
Ten rozdíl je v tom, že s PulseAudio se vám to přehodí pro všechny aplikace najednou (klidně automaticky jako reakce na připojení TV a zpět po odpojení TV), s ALSA to musíte přehazovat pro každou aplikaci zvlášť.
BlueZ 4 neumí změny profilů, je potřeba jej vždy restartovat. Nastavení je také potřeba udělat v systémovém konfiguráku, nejde jen vzít Bluetooth headset, dát ho na počítači vyhledat a připojit.
Problém se screenlockem je ten, že když spadne aplikace screenlocku, tak se desktop odemkne.
Řeší se to, že v současnosti je screensaver a screenlock to samé. Každá implementace screensaveru tak kromě stability musí řešit i zamykání (kradení eventů ap.). Co když váš screensaver zapomene ošetřit nejnovější rozšíření Xek?
IMO je takové řešení o dost lepší, protože se neodemkne přístup (po pádu to vykopne na přihlašovací obrazovku). Ale jestli máte raději stabilní prostředí pro útočníka…
Nie, prostredie, ktore v pripade problemu zahodi vsetku moju pracu v ziadnom pripade nieje lepsie. V ziadnom. Prave uvazovanie takehoto typu nas dostalo do tych problemov, v ktorych je Linux teraz.
Ak musi byt sucastou wayland compositora naviac i screensaver, z foru sa stava pruser. Nespadnutelny screenlock si este dokazem predstavit, screenlock je vyslovene trivialna vec. Pad v screensavery je ovela pravdepodobnejsi. V tom pripade je obycajne XGrabPointer, XGrabKeyboard a pustenie screensavera v samostatnom procese ovela bezpecnejsi postup.
Jenže ono nejde o jen tak ledajaký problém. Jde o problém, který má dvě možná řešení: zahodit práci či nechat útočníkovi plný přístup. Já si tedy vždy vyberu 1).
Nemusí, tak je to u X11, kde screensaver a screenlock je totéž, protože X11 žádný screenlock nemá.
A to je zrovna implementace, která rozhodně nestačí, protože Alt+Tab (přepnout na jiné okno) pořád funguje a pomocí Ctrl+Alt+Esc (či jak máte nastavený kill window) takový screenlock snadno sestřelíte.
Tj samozrejme nezmysel. Pad lockeru sa da uplne dementne vyriesit automatickym restartom lockeru. Alebo pisanim poriadneho sw, nie riesenia situacie, az sa bazmeg zruti.
XGrabKeyboard samozrejme zabere zamkne aj alt+tab. Kludne si to vyskusaj, otvor akekolvek kontextove menu gtk aplikacii a stlac alt+tab. Rovnako tak Ctrl+Alt+Esc.
Řešení s XGrabKeyboard a spol. je tak geniální, že stačí mít otevřené kontextové menu a screenlock na X11 se neaktivuje. Ideální pro případy, kdy máte nastavený nějaký timeout, odejdete od počítače a necháte někde něco rozkliknutého. XGrabKeyboard je pro implementaci čehokoliv bezpečného z principu nepoužitelný, protože jej nelze ukrást.
"XGrabKeyboard je pre screenlock priamo napisany"
A na tohle jste přišel jak? XGrabKeyboard může selhat spoustou způsobů, kterými screenlock selhat prostě nesmí. XGrabKeyboard není a nikdy nebyla určená pro účely zabezpečení. Kromě GTK jí používa Qt, SDL a čert ví, co ještě.
"Rovnako dobre moze volat wl_postpone_screensaver, az raz taku moznost vo Waylande implementuju"
Na Xkách tento problém existuje taky a vyhrazování si práva na klávesnici a deaktivace screensaveru má úplně odlišné use-cases.
man XGrabKeyboard :)
Inak XGrabKeyboard moze zlyhat presne dvoma sposobmi. Programatorska chyba (volanie nad skrytim oknom) alebo zamknutim klavesnice inym klientom. Ale to, ze niektory klient robi bordel sa ma riesit s tym klientom, nie prepisanim okenneho systemu... V SDL je, pokial viem, problem uz opraveny, vyvojari GTK sa klasicky vyjadrili cca v zmysle "s***me na vas, prechadzame na wayland"...
XGrabKeyboard pouziva i Firexox pro implementaci svoji geniani featury "drag and never drop". Kdy zacnete drag-and-drop operaci, ale pak nastane nejaka chyba v aplikaci a FF uz nikdy nevrati rizeni ostatnim aplikacim. Drive slo aleson Xka sestrelit pomoci CRTL+ALT+BACKSPACE, dneska uz zbyva jen rebootovat pocitac anebo spolehat na to, ze window manager takovou situaci dokace rozpoznat a po nejaky dobe to vrati do normalu. V dobe Windows 3.11 jsme se smali kooperativnimu multitaskingu, ale Xka ho vlastne maji dodnes.
Pokud sis nestacil vsimnout, ta gentoo systemd nepouziva. Jen ho umoznuje.
Systemd pravda resi spoustu veci, admin nemusi resit ze neco spadlo, protoze logy nema, nemusi resit znicena data, protoze ma jistotu, ze znicena budou, cele dny muze travit zabavnym hledanim stanic v siti, na kterych bezi dhcp servery ...
Podľa mňa nieje. Ide o to že tak ako funguje sistemd ako ho vedie programátor (teraz neviem jeho meno) vytvára problém do budúcnosti. A niektorý ľudia (ktorým nebolo zalepené oči peniazmi od korporácií) vidia kde to všetko vedie tak brblú. Keby nebrblali tak tá najhoršia predikcia sa môže naplniť.
Ono všimol som si že občas niekto niečo otestuje na programátoroch a správcoch počítačov a potom to tak nechá. Dosť sa to rozmaže po sieti. Napríklad jedným takým testom bolo pulse audio. Možno myšlienka pekná ale tá aplikácia.... Podľa mňa pulse audio sa začalo stabilizovať a zlepšovať vlastnosti až po odchode hore spomínaného programátora.
Podobný test prebehol aj v DELL notebookoch s Win10 a selfsignet certifikátmi.
To je jednoduché. O použití systemd rozhodují package maintaneři a pro ty je systemd dobrý, protože jim umožňuje relativně rychle vyřešit init skripty. Oni si odškrtnou "init vyřešený" a jsou spokojeni. To, že je to ve skutečnosti "vyřešené" velmi mizerně je netrápí, protože oni ty servery neadministrují...
Předně, existuje více linuxových distribucí, které nejsou sestaveny "systemd only" (navzdory oficiální preferenci) a umožňují náhradu initu jiným a totéž u systémových služeb. Bez ohledu na to, čím obeplácají vývojáři, baliči a údržbáři jádro ve své distribuci, vždy je k dispozici nějký funkční hack bez potřeby systemd. Nicméně upozorňuji, že jistá standardizace startu systému a jeho služeb je v podobě systemd řešena nejen logicky, ale i na daný objem úloh i cekem efektivně. proto rozhodně nepatřím mezi systemd haters a snahy neschopných posílat LP k psychiatrovi považuji za trapné pro jejich autory...
Jak jsem ty crapwary vykopal z testing debianu tak mi notas vydrží na baterií o třetinu víc. Přestal bezeť ten debilní DNS bazmek atd. Sice jsem se někde musel zatím vrátit k příkazové ale nelituju.
http://without-systemd.org/wiki/index.php/Main_Page
Uvidíme co vyleze že Suckless.
Systemd udělal jen jednu dobrou věc. Nastal spoustu lidí.