Vlákno názorů k článku Nebojte se systemd: další komponenty od TKL - Hmm. Takže tady máme Filipa Jirsáka coby autora...

odpůrce strany → ohledně odpůrců strany...

Tak jak si přejete, abych vás nazýval? Společným znakem všech vašich komentářů je, že se snažíte dát všemožně najevo, že nemáte rád systemd – i za cenu, že ze sebe uděláte úplného hlupáka. Pokud jediným projevem někoho je, že nemá rád systemd, jak jinak ho nazývat, než odpůrce systemd? Já vím, že systemd-hater je výstižnější a ironicky to odkazuje na způsob pojmenování binárek v systemd, ale já anglicismy nemám rád, takže to moc nepoužívám.

Kdybyste kritizoval systemd, psal byste věcné komentáře, argumentoval byste něčím, u čeho by se dalo věřit aspoň tomu, že si myslíte, že je to pravda, nenazýval bych vás odpůrcem systemd. Všimněte si, že takový komentář napsal na konci diskuse například Heron, a odpůrcem systemd jsem ho nenazval. Dokud v tom tématu reagoval věcně NULL, ani jeho jsem tak nenazýval. Ale když nekritizujete, jenom prezentujete svůj odpor, proč bych vás měl nazývat jinak?

Jj jak před '89... Kdo nesouhlasil, byl hned nepřítel lidu :D.

Vzhledem k tomu, že systemd nejen používám, ale řeším hromadu problémů, reportuji chyby, analyzuji kde chyba vzniká, zkouším najít opravy a taky je často nacházím si nemyslím, že jsem odpůrce nebo hater systemd, ale jak říkám, neznamená, že si z toho kusu softu budu dělat modlu, obzvlášť, když hromadu věcí dle mého názoru (na který mám po '89 nárok) dělá špatně.

Ještě jednou a naposledy, třeba to pochopíte: za odpůrce systemd neoznačuju ty, kteří nesouhlasí, ale ty, kteří neváhají psát nesmysly a vymýšlet si, jenom aby předvedli, že systemd nemají rádi.

Pokud to ani tentokrát nepochopíte, omlouvám se vám za označení „odpůrce systemd“ – v takovém případě to neděláte schválně, ale prostě jenom nechápete význam textu.

A nebo vy nechápete význam psaného textu a to, že když se s daným problémem nesetkáte vy, že neexistuje.

Tak si pojďme některé ty problémy rozebrat. Problém č. 1 - bez systemd nejde spustit linux (obecně). S tímto problémem jsem se nesetkal, ale myslím, že snadno prokážu, že neexistuje - mám totiž zařízení bez systemd, na kterém linux jde normálně spustit. Problém č. 2 - v budoucnosti nebude možné logovat jinak, než přes systemd. V současné době ten problém neexistuje (což lze opět snadno prokázat systémem, kde se loguje a není tam ani systemd ani journald). Teď je přítomnost, ne budoucnost, takže teď ten problém neexistuje. Problém č. 3 - uživatel Libcha chce ve své vlastní aplikaci logovat stejně, jako na daném systému loguje systemd. Uživatel ByCzech má problém s tím, že takové logování není multiplatformní a že vlastně vůbec neví, proč by měl logovat přes Journal API. Uživatel Libcha je někdo jiný, než uživatel ByCzech, takže uživatel ByCzech se laskavě přestane cpát do toho, co Libcha chce nebo nechce. Problém vyřešen.

Pokračovat můžete vy, protože byste mohl tvrdit, že schválně vybírám ty případy, kdy to dotyčným jenom ujelo a neexistující problém vytvořili omylem. Tam sem s nějakým reálným problémem, který já jsem označil za neexistující.

Aha, diskuze je fakt nepřehledná, pak se neví kdo na koho reaguje...

Aha, diskuze je fakt nepřehledná, pak se neví kdo na koho reaguje...

Jo, ale na to tu lidi upozornujou tepre asi jen pul roku. Nemuzes chtit, aby kazda chyba byla vyresena do druheho dne. Nejdriv se to musi responzivne promyslet.

Já už na to neupozorňuju, je to zbytečné. Vzhledem k těm chybám co tu jsou a nikdo s tím nejen nic nedělá, ale ani to nikoho nezajímá.

Každopádně jedna věc je nepřehlednost a druhá chování Jirsáka, který často místo věcné diskuze očerňuje nebo se staví do role samozvaného správce téhle diskuze, který má problém s chápáním toho co mu ostatní chtějí sdělovat. Slovíčkaří a trvá na svém chápání toho co kdo napíše, ačkoli se mu to snaží diskutující vysvětlit, že jim jde o něco jiného a uniká mu podstata příspěvku ap.

Ještě jste zapomněl na ty, kteří nechtějí implementovat API do všech svých aplikací
Nezapomněl. K tomu, aby aplikace mohla běhat v systému, který používá systemd, nemusí autor té aplikace implementovat žádné API, nemusí napsat ani čárku. Pokud někdo tvrdí opak, spadá do kategorie těch, kteří si prostě jen vymýšlí. Nikoho jsem neoznačil za odpůrce systemd proto, že by nevěděl, co je API.

Vite, ta "špinavá práce" nemusí být až tak špinavá.
Když se probíráte špínou, což je současný stav SysVinit+skripty, není to čistá práce.

Ta vaše metafora s mostem vůbec nesedí. My dneska nemáme několik starších mostů, které nevyhovují. My dneska máme děravou loď, holinky, bidlo, děravý záchranný kruh a spoustu leukoplasti, vytipované místo v řece, kde je mělčina a dá se tam postavit, když se člověk topí, a k tomu do detailu vypracovaný postup, jak se s pomocí těchhle propriet dostat na druhý břeh. A když někdo namítne, že děravá loď není úplně ideální dopravní prostředek, hned přijde někdo s tím, že proto je tam přece ten záchranný kruh a každý ví, kde má z loďky vyskočit a kde je ta mělčina, na které si může odpočinout – a nějaké novoty jako neděravou loď nikdo nepotřebuje.

V takové situaci neseženete prostředky na postavení drahého dálničního mostu někde vysoko nad údolím, lidé si takový most ani nebudou umět představit, a ani nebudete vědět, jak na to. Takže nejprve musíte postavit dřevěnou lávku nízko nad vodou, budou z ní schody k té mělčině, kde odpočívají topící se, bude u něj molo pro připoutání té děravé loďky, budou na něm zásobárny leukoplasti na ten záchranný kruh atd. A teprve až si lidé zvyknout, že nemusí jet děravou loďkou, topit se a teprve pak vylézat na most, ale že mohou přes most přejít z jednoho břehu na druhý, teprve pak jim můžete navrhnout pořádný most, který nebude omezený tím, že u něj musí být molo pro zakotvení děravé loďky a nemusí z něj vést schody do odpočívárny pro topící se.

Těch náhrad SysVinitu, které se snažily řešit jen malou část a postupně, bylo docela dost – a systemd vzniklo jenom proto, že žádná z nich neuspěla.

Protože odporoval, nařkl jste ho že neví co je API.
Ne. Nařkl jsem ho, že neví, co je API, protože v komentářích předváděl, že neví, co je API – například tvrdil, že API závisí na implementaci, nebo že aplikace využívající API musí vědět o tom, jaké všechny implementace API existují.

Dneska ohledně procesů si lidi dokážou představit co je potřeba. Jinak by to asi ani P-Team nemohl dělat, kdyby nevěděli co je vůbec potřeba.
Někteří lidé si to představit dokážou a jiní ne.

kdo che chodit po té vratké lávce, tak už nesmí měnit za loďku, případně mu stavitelé mostu zruší některé ty mělčiny nebo kotviště
Tak to ale není. Kdo se rozhodne používat most, klidně se zase může vrátit k loďce. Mělčiny nebo kotviště mu nikdo neruší. Ale je pravda, že když se někdo rozhodne, že tu loďku pro jistotu potáhne po mostě za sebou, že to nebude komfortní a bude to dokonce namáhavější, než s ní jet po vodě (než se potopí). Ale tahat za sebou loďku po mostě nebyl nápad tvůrců mostu.

Vratká lávka, po které přejde 99 suchou nohou a jeden se namočí (navíc vlastní nepozorností) mi připadá jako výrazný pokrok oproti stavu, kdy se jich namočí sto a je to vnímáno jako normální součást překonání řeky.

Já k té myšlence a snaze P-Teamu nic nemám, ale zdá se mi že to přehánějí a tak trošku prasí okolo. Bohužel . . .
Já vás chápu, přemýšlel jsem o tom několikrát, jestli to nepřehánějí. Ale vždy jsem dospěl k tomu, že se mi nechce riskovat, že by systemd byl další neúspěšný pokus, a za 3 roky se bude řešit to samé, jenom v ještě horší situaci a bude potřeba být ještě drsnější. Ty méně drsné metody už se zkoušely a neuspěly.

například tvrdil, že API závisí na implementaci, nebo že aplikace využívající API musí vědět o tom, jaké všechny implementace API existují.

Myslím, že by jste to měl dokázat nebo se omluvit.

Protoze vsichni vime, ze centos 7 == linux.

Konfiguracny subor /etc/grub2.cfg, riadky zacinajuce na linux, dopisat na koniec riadku init=/bin/bash. Prajem Vam vela zdaru a pevnych nervov pri praci s takto spustenym systemom.

Před lety, na centos 5, to vůbec nebylo složité. Mount disků, ip a / ip r nastavení sítě. service sshd start. Zbytek po síti.

Já jsem ale nikde nepsal, že rozběháte CentOS 7 bez systemd. Já jsem pouze vyvracel vaši lež, že bez systemd nespustíte linux. To, že CentOS 7 je linux na věci nic nemění, protože vy jste tvdil, že bez systemd nespustíte (žádný) linux, což rozhodně nelze dokázat jediným příkladem (ale jediným příkladem to lze vyvrátit).

A to je problém... Někomu systemd přidělá spoustu starostí a problémů a hned je to odpůrce!

Kde je fix laudon ta pověstná svobodná možnost volby, kterou jsem si na Linuxu tak oblíbil?

Že to nepomůže v jednom případě neznamená, že to nepomůže nikdy.

Ano, takže místo toho aby se psali programy správně a testovali se (Její pojetí asynchronního softwaru, plánování priorit, důkladného testování a ošetřování chyb způsobených chybným zadáním), tak se to bude zbůhdarma restartovat a třeba se to zrovna povede, pokud jsou hvězdy nakloněny. Ostatně, kdyby tam byl systemd, tak po restartu naběhnou všechny services jako před tím (protože konfigurace je přece jen jedna a je nesmysl to dělit na boot a aktuální, že).

Navíc zrovna v případě Mars Climate Orbiter to byl ten samý problém

To nebyla chyba vstupu, to byl vadný program. Nepředpokládám, že by tam někde byla tabulka fyzikálních konstant, kterou stačilo jen na dálku přeflashnout, tohle všechno bylo jistě zadrátováno do programu. Ostatně, kdyby tam byla, tak by si toho asi i někdo všiml.

PS: Jinak po včerejším kompletním výpadku DC Master Internet Praha nemám chuť dál flamovat. Mimochodem, půl dne nejelo ani Internet Info a nikde ani čárka. Počkáme do zítřka ;-). Každopádně toto ukazuje, s čím se musejí sysadmini potýkat. Vůbec to není problém padajících services. Za posledních několik let jsou to hlavně krajně nespolehliví dodavatelé, kteří LŽOU. Včera se provalila LEŽ o tom, že Master má zálohované redundantní napájení.

Ano, takže místo toho aby se psali programy správně a testovali se (Její pojetí asynchronního softwaru, plánování priorit, důkladného testování a ošetřování chyb způsobených chybným zadáním)
Ne místo. Správně napsaný a otestovaný program je takový, který se v neočekávané situaci přepne do bezpečného režimu, ve kterém nepáchá žádné škody a pomáhá při diagnostice problému.

zbůhdarma restartovat
To je vaše konstrukce.

To nebyla chyba vstupu, to byl vadný program.
Byla to chyba na vstupu. Nejdřív dostali od sondy údaje o aktuální rychlosti, které byly mimo očekávané hodnoty, sonda pak naopak dostala příkaz k manévru mimo očekávané hodnoty.

protože konfigurace je přece jen jedna a je nesmysl to dělit na boot a aktuální, že
po včerejším kompletním výpadku DC Master Internet Praha
Ano, je to nesmysl, protože jak ukazuje mimo jiné ten včerejší výpadek, můžete si klidně myslet, že máte zálohované redundantní napájení, ale stejně je potřeba počítat s tím, že server bude najednou z ničeho nic bootovat (protože to zálohované redundantní napájení už zase běží) a vy k němu navíc nemáte přístup (protože port na switchi není po tom neplánovaném výpadku tak zcela v kondici). Nebo-li pokud najednou z ničeho nic bootuje server, nebo najednou z ničeho nic startuje služba, měly by vždy skončit v nějakém bezpečném stavu. Pokud tedy administrátor pracuje způsobem "teď mám systém v jiném stavu, než do kterého by se dostal po bootu, ale správce služeb mi do toho hrabat nebude a dá-li Bůh, k restartu nedojde", docela hazarduje.

Někdo zkrátka počítá s tím, že správně napsaný program se nikdy neočekávaně neukončí, běží na serveru, který se nikdy neočekávaně nerestartuje, a je umístěn v datacentru, kde nikdy nedojde k výpadku napájení. A pak jsou lidé, kteří na tohle nespoléhají, a řeší, aby i v případě toho neočekávaného výpadku systém skončil v bezpečném stavu. Takže třeba aplikace, která se spouští v okamžiku, kdy nebyla řádně ukončena, naběhne v režimu pouze pro čtení, aby bylo možné zkontrolovat, že nedošlo k nějakému skrytému poškození dat. A nebo ještě lépe, aplikace v takovém okamžiku naběhne v režimu jen pro čtení a sama spustí diagnostiku. Takže až se k ní správce přes ten nefunkční switch probojuje, budou už na něj čekat výsledky, že je vše v pořádku a jestli je možné se přepnout do plného provozu.

stejně je potřeba počítat s tím, že server bude najednou z ničeho nic bootovat

S tím se kupodivu počítat dá a vždy se s tím počítalo i v minulosti s oddělenou konfigurací pro boot. Mimochodem, tohle tady (se slovníkem sobě vlastním) komentovat j. A velmi trefně.

To se stalo zrovna našemu ex-konkurentovi (nebo jak to nazvat) minulý týden, který si k nám do racku dal svůj hw. Po prvotním nastavení na místě si to chtěl donastavit z kanclu a ejhle, co čert nechtěl (nebo možná chtěl), uklepl se v iptables pravidlu a odřízl si síť kompletně.

Stačilo přes monitorovací rozhraní poslat impuls reboot, počkat až to najede, a bylo to OK (načetla se původní konfigurace). Kdyby to nastavoval přes hypotetický sd-firewalld stylem "je jen jedna konfigurace", tak aby ani reboot nepomohl, protože po bootu by se mu tam opět načetlo to špatné pravidlo (a ne každý HW má na mgmt grafickou konzoli, takže by tam musel někdo dokráčet).

Pokud tedy administrátor pracuje způsobem "teď mám systém v jiném stavu, než do kterého by se dostal po bootu, ale správce služeb mi do toho hrabat nebude a dá-li Bůh, k restartu nedojde", docela hazarduje.

Viz. Výše. Nikdo nepsal o tom, že k výpadku nikdy nedojde. Jen jsem psal o tom, že se těžko jedná s dodavateli, kteří lžou. Ten včerejšek byl jen vhodným příkladem takových lhářů.

S tím se kupodivu počítat dá a vždy se s tím počítalo i v minulosti s oddělenou konfigurací pro boot.
V tom případě nechápu ty nářky na to, že systemd připojil souborový systém nebo spustil službu - protože přesně to by se stalo po bootu.

Stačilo přes monitorovací rozhraní poslat impuls reboot, počkat až to najede, a bylo to OK (načetla se původní konfigurace).
To musí být děsně prima. Upravím konfiguraci firewallu, za několik týdnů někdo jiný aktualizuje jádro, musí provést restart serveru, a načte se mu jiná konfigurace firewallu. A ještě lepší to bude v případě výpadku napájení - server naběhne, něco v síťování nebude fungovat (kvůli chybně nastavenému firewallu), všichni budou řešit, co se tím výpadkem napájení pokazilo, a ona je to akorát chybná nikdy nepoužitá konfigurace firewallu.

Řešit chybnou konfiguraci služby restartem celého systému je oblíbený způsob ve Windows. V unixovém světě se to řeší tak, že se připraví nová konfigurace, ta se aplikuje dočasně, a pokud hrozí, že by si mohl správce odříznout přístup, nastaví si časový limit, po kterém se vrátí předchozí konfigurace automaticky.

Mimochodem, tohle tady (se slovníkem sobě vlastním) komentovat j. A velmi trefně.
Pokud se mi někdy přihodí, že souhlasím s tím, co napsal j, zamyslím se nad tím ještě jednou a hledám, kde je v mých úvahách chyba.

V tom případě nechápu ty nářky na to, že systemd připojil souborový systém nebo spustil službu - protože přesně to by se stalo po bootu.

To už jsme probrali. Může na ten server spadnout meteorit. Ano, může. Příčetný admin si nebude rebootovat stroj, u kterého vyměňuje disk. Elektřina zpravidla nevypadává (pokud omylem nemáte server v DC Master Praha). Pokud by vypadla, tak by to příčetný admin nechal najet do nějakého rescue režimu. Nebo by se zařídil jinak. Fakt nevím, co je to za argument: stejně by se to stalo po bootu.

To musí být děsně prima. Upravím konfiguraci firewallu, za několik týdnů někdo jiný aktualizuje jádro, musí provést restart serveru, a načte se mu jiná konfigurace firewallu.

Velmi se omlouvám, že jsem to pro vás nenapsal jasně, pohybuji se mezi adminy, takže jsem předpokládal (moje chyba), že všichni vědí, že se ta konfigurace při bootu dá změnit. Takže: ve chvíli, kdy si dotyčný nastaví ten fw tak, že je s ním spokojen, může toto nastavení uložit i pro příští boot.

Takže s tím, že server bude najednou z ničeho nic bootovat, se samozřejmě počítá, až na výjimky, kdy se s tím nepočítá.

Jistě, dá se tak pracovat, ostatně dělali jsme to tak spoustu let. Akorát v tom nevidím jedinou výhodu, zato tam je dost příležitostí pro chyby. Připadá mi lepší mít jednu nebo více konfigurací (třeba pro běžný běh a záchrannou konfiguraci), mezi kterými se přepíná podle definovaných pravidel nebo na pokyn administrátora, ne rebootem.