Vlákno názorů k článku Nebojte se systemd: jednotky od higgsuv boson - Článek jsem ještě nečetl, ale ten titulek mě...
-
higgsuv boson (neregistrovaný)
Článek jsem ještě nečetl, ale ten titulek mě zaujal:
„Nebojte se systemd“
Ale on je tu důvod.
systemd ukončuje procesy uživatelů po jejich odhlášení
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394)
↓↓↓↓
vývojář systemd navrhuje jako řešení do tmuxu implementovat dbus a přes něj volat nějakou metodu
(https://github.com/tmux/tmux/issues/428)*When one facepalm is not enough*
-
No, bez legrace ... skoncil jsem u debianu, protoze si clovek mohl byt jist, ze se po dobu jeho sluzby nic zvlastniho nestane, vyjma pozaru v HW. Skousnul jsem grub2 (dobre, nemusim se v tom tedy hrabat, ale at to funguje), systemd (ok, nerozumim co delas, ale hlavne startuj).
A jestli jsme ted prekrocili rubikon tim, ze jedna aktualizace zlikviduje moje legie bezicich screenu a ukonci funkci nekolika mych stroju ... predvidali to, kdyz prijimali systemd? ... Ne, tomu nemohu uverit. -
Sten (neregistrovaný)
Nebojte se, v Debianu tahle nová vlasnost nebude zapnutá, dokud nebude fungovat se screenem a tmuxem. Viz bug 825394.
-
dustin (neregistrovaný)
Těch dotčených aplikací je mnohem víc, přímo v tom bug reportu jsou zmiňované další. Je nesmysl je všechny měnit, navíc lidi třeba používají i své vlastní. Tenhle přístup je prostě hovadina, není o čem diskutovat.
Sleduji mailinglist alsy (nerovná se pulstaudio :) ) a tam platí zásadní pravidlo - neměníme legacy funkcionalitu, jen opravujeme chyby a přidáváme další API, jak vzniká potřeba u nových zařízení. Hlavní správce si to sakra hlídá a neakceptuje patche, které by mohly rozhodit stávající správně napsané user-space aplikace.
-
dustin (neregistrovaný)
=====
ALSA je část jádra. Tam platí jiná pravidla.
=====Naopak, v tomto případě se jedná o user-space API knihoven kolem alsa-lib. User-space programy nevolají služby alsích modulů napřímo.
Tato pravidla vycházejí ze zdravého rozumu a měla by platit v mezích možností vždy a všude. Pokud ke změně rozbíjející legacy kód není opravdu zásadní důvod, pak by se dělat neměla.
Protože to má spoustu dopadů. Provozujeme několik serverů na netu. Sami i klienti kontrolujeme jejich zabezpečení. Takže musíme samozřejmě upgradovat v případě bezp. problémů. Co myslíš, chce se nám upgradovat servery z wheezy na jessie? Dosud to bylo vždy docela bez problémů (upgradů už proběhla celá řada). Nyní budeme wheezy držet, co to půjde, protože můžeme čekat mraky problémů se systemd v jessie. I když si to vyzkoušíme bokem, stejně lze očekávat nějakou neotestovanou situaci. Máme tam některé klíčové systémy v legacy chrootu (bez LXC), spouštěné Jak se to podepíše na bezpečnosti těch serverů? A takhle se bude chovat mraky správců. Tyhle zbytečné změny povedou akorát ke snížení bezpečnosti internetu jako celku.
Donedávna jsem byl optimistou a věřil, že správci debianu udrží systemd v jessie pod kontrolou. K systemd jsem se nevyjadřoval, protože se mě defacto nijak netýkal. Poslední dobou (po pár setkáních s jessie na serverech) začínám mít obavy, co dál.
-
Sten (neregistrovaný)
A když ten legacy kód používá nedokumentované chování?
Několik serverů jsem aktualizoval. Problém jsem se systemd měl jen ten, že jsem se musel naučit s ním pracovat.
Pokud se přesto obáváte, tak Debian nikoho nenutí používat systemd. Bylo o tom i hlasování. Klidně můžete zůstat u sysvinitu, upstartu nebo něčeho jiného, co jste používal dřív, v Jessie, Stretchi, Sidu i Experimental pořád jsou.
-
dustin (neregistrovaný)
====
A když ten legacy kód používá nedokumentované chování?
====Nevím, zda např. nohup používá nedokumentované chování, ale používá se takto desítky let, je popisován ve všech knížkách o správě linuxu. To je pro mě dokumentované chování.
====
Několik serverů jsem aktualizoval. Problém jsem se systemd měl jen ten, že jsem se musel naučit s ním pracovat.
====Asi to byly jen jednoduché věci. Hned při první příležitosti jsem narazil na velice nepříjemnou a zcela nelogickou změnu chování http://www.root.cz/clanky/nebojte-se-systemd-jednotky/nazory/876735/
Všechny aktualizace debianů na serverech jsme vždy dělali vzdáleně, přes ssh. Sice v noci, ale za provozu. Na tohle si v případě upgradu na jessie se systemd ani náhodou netroufnu.
-
Nevím, zda např. nohup používá nedokumentované chování, ale používá se takto desítky let, je popisován ve všech knížkách o správě linuxu. To je pro mě dokumentované chování.
Kdyby jen Linuxu, ale nejspis i v kazde knizce o libovolnem *NIXu. Nohup je definovan v POSIXu. Ale POSIX patrne dnes znamena Poettering's Operating System Interface, takze je vse v poradku.
-
Sten (neregistrovaný)
POSIX nikde neuvádí, že by nohup měl přežít konec sezení. Pouze že přežije poslání SIGHUP. Což nemusí a často ani není totéž, třeba pokud po přihlášení spustíte MC, pak všechny další příkazy jsou spuštěné v novém shellu a ukončením MC by je to postřílelo SIGHUP. Sezení ale neskončí, dokud neskončí ten původní shell.
-
ebik (neregistrovaný)
No to neni uplne pravda. Grub2 se jen prestal spolehat na to, ze mu filesystem nepresune bloky kde je ulozen. Takze mu muzete vytvorit specialni partisnu s par jednotkama mega, nebo pouzit filesystem, ktery ma na zacatku partitiony dostatecne rezervovaneho mista (bohuzel z hlavy zadny takovy neznam). Kazdopadne to asi ale bude chtit priohnout jeho install skripty (to uz je peknejch par let co jsem to delal). A obavam se, ze bude grub vytlacen nahravanim jadra do EFI, nebo tak neco.
