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í...