Vlákno názorů k článku
Dělá systemd Linux více složitým, náchylným k chybám a nestabilním?
od Ladislav Jech - uz je to tady fakt dlouho, to musi...
-
uz je to tady fakt dlouho, to musi byt nemocne by design, ikdyz myslenky systemd se mi libi. ja se porad lamu, jestli svoje gentoo servery preklopim na systemd, mam 15 experimentalnich masin, jsem primarne vyvojar... co to tu ctu tak fakt nevim.
mate nekdo zkusenost s mesos, nebo jeho extenzi dcos nad systemd?
-
Ladislav Michl (neregistrovaný)
Dlouho sme měli koňa. Nebyly s nim starostě, až pak jednou zdechnul, tatik už druhého nechtěl, že žere aj v zimě. Včil máme traktor, ale těch problémů! Třeba sem se musel naučit měnit olej a jednou jsem dokonce měnil vstřikovací trysky! Ten traktor je nemocné už od návrhu, tohle kůň neměl...
Ale jinak mě to nepřestává fascinovat. Primárně vývojář s 15 experimentálníma mašinama prostě experimentovat nebude, protože se na jakémsi fóru dočte, že má někdo s nějakým kusem software problém.
-
no sorry frajirku, ale oba dedove meli kone a dnes mame traktory a je to vic bezudrzbova zalezitost. mas hezkej sloh, ale uplne mimo realitu , ackoli ja jsem se nejak vydal jinou inkarnacni cestou...
asi ses o kone nikdy nestaral. ja mluvim o tom, ze kdyz kdyz prevadim myslenky do navrhu, tak to delam durable, pokid je moznost nejakeho stucku, tak navrhnu protistuckove funkce, kdyz heozi, ze nedochazi k auto restartu, tak dam do systemu bud doublu check, nebo to navrhnu tak, ze k tomu nemuze dojit....
dalsi vec, proc si myslim, ze jakejkoli monolith je spatne (napsal jsem monolithy pro generovani a zpracovani faktur, kde nikdo nikdy nenasel chybu, ale urcite tam byla). zacinal jsem na plc systemech ve skodovce, programovali jsme montaz fabie back in 2000. chyba kazdych 10-20 minut, reseni zabralo 1-5 minut, po pul roce chyba za 3 dny, reseni 1-3 hodiny. tenhle stav ma samozrejme matematicky zaklad ve slozitosti. nechci uplne rikat ze systemd navrhli blbe, ale rozhodnuti monolithu je spatne, schovavas do nej radove vice chyb nez do mikroservices. traktor je spis jako microservice, upadnou mu kola, ale motor porad facha, koni upadnou nohy, a umre. chapes? to jsou fundamentalni veci v designu, ackoli jsou funkce vicemene stejny, jedna nebo jina cesta te vede do ruzne velkeho pekla... make your choice.. nevim, jestli si studoval navrh softwaru, ale jestli ne, tak bys nejdriv mel, nez cist blogy...
v praci jsem se samozrejme se systemd uz taky setkal, potvrzuji, ze ty error logy jsou nekdy uplne k hovnu nebo zadny.'. nejsem admin ale mam omezeny nekdy plny sudo a serveru mame asi 100, ale tam se vyhybam delat admina
ps: delam architekta mikroservices a ai
-
Ladislav Michl (neregistrovaný)
Odpověděl jste si sám, ačkoliv ty příměry jsou mimo, jak je obvyklé, když se softwarový architekt pustí do "automotive" porovnávání. Mě je traktor bez kol k ničemu i kdyby stále běžící motor plnil Euro 6 a myslím si, že se na tom shodnu s většinou sedláků.
Systemd není monolit, samotný init je velmi malý. Zbytek argumentace taky nechápu, tento init umožňuje restartovat službu za podmínek daných autorem služby, nikde není dané, že se služba musí restartovat. Máte volbu. Stejně tak máte možnost spustit služby po sobě v pevně daném pořadí. Běžně to nikdo nedělá, ale jde to.
Kupodivu existují lidé, kteří dokáží opravit chyby systemd (a abych použil Váš vychloubačný přístup, systemd mám nasazený na desetitisících zařízení, které mají společné snad jen to, že musí běžet bez dozoru a problémy samočinně hlásit) v řádu hodin, ale to není věcí systemd nebo software Vaší montážní linky, ale znalosti návrhu a implementace opravovaného kódu.
Výše jsem narážel na to, že dostanete traktor místo koně a divíte se, že nefungují postupy pro chov koní běžné. U vývojářů, architektů, ap. mě takový přístup překvapuje, nic víc. A neberte si to osobně, lidí, kteří trpí předsudky na základě toho, co si přečetli na kdejakém blogu je i mimo IT víc než dost.
A nakonec, journald je velmi dobrý systém logování, ale spolehlivě ho dokáže rozhodit nesmyslně nastavený čas v okamžiku startu. Možná jako architekt oceníte možnost napsat si vlastní log storage, třeba někam do NVRAM, takže uvidíte i předsmrtné logy, které by jinak zmizely v cache.
-
Ja se fakt nevychloubam, nebo jsem tak zaslepen sam sebou, ze jsem si toho nevsiml :-) Taky jsem se nedivil, ze by byl rozdil mezi konem a traktorem... Sam jsem si rozhodne neodpovedel, resp. nedostal jsem se k odpovedi.....to jsou nejake tvoje vnitrni preludy(asi bezis na systemd :-) )....
Ad: softwarový architekt pustí do "automotive", ja jsem odrostl na automotive asi uz jako dite (ale jinak gefanuc a simatiky) a az pak jsem se zapletl s jinym balastem a skoncil primarne na Jave, okrajove C a Pythonu.. a samozrejme Gentoo, ostatni distribuce krome Debianu povazuju za zbytecne (mozna moje zaslepenost).... ale zpet k systemd
On na nizke urovni take nasleduje mikroarchitekturu, jde o nejakych cirka 70 knihoven jestli se nepletu v plne show, ale me to prijde derave jak reseto, protoze veci, ktere hlasa resit jsou nestabilni, a tech nestabilit je tam na muj vkus hodne na to, abych to mel na produkci (tohle je mozna predsudek, muze byt). Spousta uz je jich opravenych, ale tim, ze je to komplexni system, tak ty opravene jen umoznuji nekterym skrytym byt nalezeny (analogie na slozitosti viz predchozi prispevek). Me to trochu prijde jak kdyz navrhuju tank, ktery projede zdi, ale kdyz najede na klacek, tak se rozlomi vejpul, jsou tam nektere veci (z github issues), ktere me k tomuto vedou, aktualne:
707 open a 2341 closed
z toho
70 bugs open a 437 bugs closed, ale oni pouzivaji skoro 100 labelu, takze nevim, co vlastne je a neni chyba systemd jestli jen bug label, nebo i dalsi....Takze takhle se ten system ma aktualne. Ja uz vim na co si narazel, ze jsem byl vychloubacny(ted mi to doslo, protoze jsem to chtel zase zminit :-)). No ano, to se mi podarilo ale uz nekolikrat, ze jsem napsal netrivialni software, ve kterem urcite byly chyby (i ja jsem o nekterych vedel, ale vzdy se samozrejme hrozim tech, o kterych nevim), ale fungoval a uzivatel zadne chyby nezaznamenal. Proto proboha pisu unit/integracni a automatizuju i user acceptance testy (simuluju scenare, ktere bude uzivatel provadet) a jen potom to vypustim do sveta. Sorry jako, ale at uz to je velkym soustem, nebo nekvalitnim testovanim, ja opravdu neznam systemd management a historii taky nic moc. Ale ty cisla ukazujou, ze to neni koser a je jedno jestli na tom REDHAT maka a fixuje. Zvlaste pokud na tom REDHAT tak pracuje, tak bych prave cekal, ze se spousta tech chyb odchyti, taj mi to prijde, ze to proste namastej, vypada to dobre, tak to vysmazime ven a uvidime. Mozna jsem trochu pokriveny (v dobrem slova smyslu) prave z automotive. Pokud bych tam neco podobneho vypustil na svetlo bozi, tak se mi urve karoserie z transferu, nebo nedej boze vytlacim celou karu i se skidem z vytahu ve druhym patre a necham ji jumpnout na podlahu.... IT IS NOT ACCEPTABLE - a proto je neakceptovatelny pro me i systemd, tak jak je ted a uz je tak pekne dlouho... end of story
Realny problem: chci na svoje GPU masiny ted stejne instalovat DCOS(protoze uz chci instalovat cpu/gpu aplikace pouze ve forme docker imagi) a lepsi nastroj jsem nenasel (krome mozna kubernetes, ale dcos je generictejsi), na laptop zase miraclecast abych mohl delat prezentace pres wifi na projektoru/televizi, oboje systemd dependant.. Druhy zmineny se pokousime zmigrovat na openrc v ramci Gentoo komunity.
Takze ja se systemd nevyhybam, a diky nekterym vecem, na kterych delam je to jedina moznost, jestli nechci pracovat na portovani (coz nechci), ale nepovazuju to krome krasnych myslenek za kvalitni produkt, no way, sorry jako. A jestli ty jo, tak nevim ty vole, cim se zivis.
-
Ladislav Michl (neregistrovaný)
Je to furt dokola. Počty chyb z bugzilly bych jako argument... Nebylo by lepší podívat se, co se za těmi chybami skrývá? Systemd používá integrační testy ap. Možná byste mohl vysvětlit, co Vás vede k závěru, že tomu tak není, když sám přiznáváte, že neznáte způsob vývoje systemd. Čísla neukazují nic, naprostá většina bugreportů je typu "tady jsem něco udělal a ono to dělá něco jiného než jsem si myslel, že to bude dělat", týkají se kontejnerů, seats, zkrátka to, co System V vůbec neřeší. Chyb, kdy to dělá něco jiného, než je dokumentované, je minimum (sám jsem zatím na žádnou nenarazil, takže pro mě (a zákazníky) je to software bez chyb).
Já Vám, ani nikomu dalšímu systemd necpu, jen se ptám, co Vás vede k tomu, prohlásit cizí práci za zmetek na základě informací z blogů a fór.
K reálnému problému: oboje je systemd dependant protože, seats, device management, atd. Tohle neřeší init jako takový, ale další moduly systemd. Nakonec sám píšete, že se pokoušíte o migraci, takže musíte vědět, co za Vás systemd dělá. Přeju Vám, aby ve Vaší reimplementaci bylo co nejméně chyb ;-)
-
Proste vyprodukovat neco, co ma v sobe minimalne 500 veci oznacenych za bugy a cpat to do produkce (je to managovane lidmi ze systemd, oni delaj labely, to normalni github users nemuzou). Jako Oracle, Postgres databaze ma v sobe taky tunu bugu v produkce, tj. je to battle tested poradne az kdyz se to dostane do ruky, ale ty vole to je taky komplexni system jak krava.
Nepochybuju, ze na tom delaj dobry mozky, ale cetl jsem detailni clanky ukazujici proc je systemd superior, a take proc neni(at uz systemd fanatiku, nezazaujatych, nebo hateru :-) ). Ten impact je enormni zejmena i na outof Linux world -> Unix a BSD arena. Aplikace sou uz nove napsany na systemd a ....
Ale uz toho nechme, vse dobre...
No tesim, az zavitam na nejakej systemd festival, hlavni host vecera Lada Michl :-)))
Ale k zakladni otazce celeho threadu: Dělá systemd Linux více složitým, náchylným k chybám a nestabilním
Odpoved: Ano dela, ikdyz to nemusi byt zpusobeno primo systemd :-)) -
Ladislav Michl (neregistrovaný)
Jak se ta komplexnost měří? Na počet řádků asi ne, PostgeSQL, teda Postgres, vyvíjený od roku 1986 jako nástupce Ingresu, který má za sebou čtyři dekády a furt sou v tom chyby... No nic, 3x tolik řádků kódu v C souborech a to akorát ukládá data a hledá v nich (teď sem to přehnal a jistě to schytám :-))
Úplně po lopatě: na detailní články matlat a podívat se do kódu :-)
A k základní otázce: Ano, systemd dělá GNU/Linux více složitým, protože je psaný za účelem řešení problémů složitějších než prosté spuštění procesu. Za mě naprosto stačí 2 inity, systemd a busybox/init/init.c
-
Aha, argumentace počtem bugů. To už docela smrdí statistikou. Pamatuju se, jak přednášející ve statistice na první přednášce začal: "Teď si vystupňujeme slovo LEŽ. Lež, odsouzeníhodná lež, statistika".
Čísla jsou o ničem, pokud nevíš, čeho se týkají. A to z jednoho čísla nevíš nikdy. Víš, že třeba
- můžou používat CI a pokud někdo přidá soubor se zdrojákem, ale nepřihodí ho do commitu, sám se mu přidělí tiket na opravu bugu hned, jak to odešle? git add, git comit, fixnuto. Ale v té tvojí statistice to zůstane.
- můžou používat unit testy. A něco se rozbije ve vývojoví verzi, která ještě ani není v RC. Vyskočí bug report, ještě ten den je fixnut a nedostane se dál, než k tesťákovi. Ale tobě straší ve statistice chyb na produkci.
- Jde o bug, ale ve spolupracujícím modulu, kde tvůj soft funguje třeba jako wrapper. Vytvoříš tiket pro ten modul, dáš odkaz do svýho (protože chybu je potřeba opravit, ne zamaskovat) a zavřeš to, protože ve tvým softu chyba není. Bum, Jech má další argument, i když tam ta chyba není.
- Uživatel něco nepochopí podle dokumentace. v SW je to korektně, žádný bug. Upřesní se dokumentace, aby byla jednoznačná a do SW se nesahá. A tiket se zavře, jenomže pro Jeca i tohle znamená, že je ten soft děravý.A takhle bych klidně vycucal z prstu 50 dalších důvodů, proč tam může být tolik tiketů bez toho, že by v SW bylo cokoliv zásadního blbě. Takže - racionální argument místo statistiky, které sám nerozumíš, by tam nebyl?
-
Ty si pletes issue vs bug, takze proti me argumentujes jeste vetsim blur efektem, nez ja(a ja jsem tu chtel pouzit pouze hruba cisla viz nize). Issue je obecnej record a bug je label, a ja jsem jen vytahnul bugy(tj. problem tam je). jinak tam maj 134 issue labels, priznam se, ze nevim k cemu vsechny jsou...
Github systemd pouziva exkluzivne pouze pro bug reporting a novy ficury a to pouze pro 2 posledni verze. Pouzivaj travis CI, ale nemaji tam auto issue generation, tj. muzou to mit vedle, ale ok, uznavam, ze nevim co delaj, kdyz CI zarve, ale zda se mi, ze to perou pres Fedoru (jak jinak)
Primarne 3000 issues je na fedore a 200 na debianu(nerozlisuju, jestli je problem v systemd, nebo jinde, nerozlisuju jestli jsou to vsechno bugy).
Ty se me snazis argumentovat na zaklade toho, co pisu, ale ja se tam kouknul a prohlidnul jsem si i jejich testy, a projel jsem si reporty. Ale ty ses tam evidentne vubec nekoukl(preludovy predpoklad pouze), protoze si nic neuvedl na pravou miru... jen tupa reakce na me, kdo si to cele prolezl a kouknul se na nektery bugy v detailu skrz celej arzenal projektu systemd vcetne test casu....chapes, jak ses povrchni vole? :--)))
Zaver: Ano, pouzivam hruba cisla, abych tim hrube ukazal, ze systemd je tlusta krava a ackoli je tu tak uz 7 let, tak ji bude jeste trvat nejaky cas, nez se napase na moji louce :-) beres to? :-))
