( TCH | 2020. 10. 10., szo – 00:01 )

> 0 kör, ha már fent láthatólag kezdtél befeszülni, akkor most szólok, hogy itt az ilyeneket simán el fogom engedni, azokkal együtt, amikor azzal jössz, hogy de hát ezt más is tudja. Igen, tudom, hogy van, amit más is csinál. Teljesen hibás prekoncepció, hogy a systemd csak akkor lehet indokolt, ha olyat csinál, amit más nem.

Azt kértük, olyat mutass, amit csak a systemd tud.

> Annyit mondtam, hogy ha nem kell, el lehet tekinteni tőle, attól még lehet értelme.

Nincs értelme, a metaadatok tárolása lenne az egyetlen értelme, de azt is lehetne épeszűen.

> Torvalds bácsi véleménye érdekes, de üzemeltetési kérdésekben finoman szólva sem gondolnám perdöntőnek.

> Ha a bináris logolás agyrém lenne, akkor nem lenne tele a világ olyan projektekkel, amik nem text fileokba, hanem mindenféle adatbázisokba (azok biza binárisok ám) pakolják be a logokat. Éppen azért, mert a text fileok egy csomó mindenre kevésbe optimálisak, elég fos mondjuk bennük keresni, korelálni, ilyesmi. Hogy mást ne mondjak, mondjuk a syslog-ng, meg a rá épülő scb egészen jól megél abból, hogy van neki egy bináris logstore formátuma, hozzá jó indexelés, meg jó patterndb support. Szóval nem, önmagában a bináris logolás nem agyrém.

Oké, akkor pontosítok, hogy mire gondoltam: a systemd bináris loggolása agyrém. System-service-ek kimenetét loggolja binárisan, mert csak.

> a bazi méret pl (ami miatt naponta berotáljuk őket egy bináris gzipbe :P) meg hátrány

Text. Jól tömöríthető, ha annyira sok helyet foglal.

> Köszi a linket, igen jól mutatja, hogy milyen jól csúsztatsz, vagy legalábbis mennyire furcsán értelmezed, amit látsz. Most tekintsünk el attól, hogy az egy darab bugreport szeretnek korrumpálódni labellel jön (ne strapáld magad, biztos lehet találni még egy másik rakás esetet is, elhiszem, hogy szar)

Tehát, ha csak egy példát hozok, hogy szar, akkor csúsztatok, de ne hozzak több példát, mert inkább elhiszed, hogy van? Izé... Hogy is van ez?

> kéne valami igazi érv erre a legkisebb sérüléstől is teljesen olvashatatlan lesz. Lehet, hogy így van, de ha már érvelőset játszunk, akkor bizonyíts, mert ebből az ellenkezője jön le.

Bakker, épp most pirítottál rám, hogy ne hozzak több példát a korrumpálódásra, mert elhiszed, hogy van még... Most akkor hozzak, ne hozzak, bizonyítsak, vagy inkább mégse? Döntsd már el.
De tessék: volt rá példa, hogy reprodukálhatóan egy reboot elég volt ahhoz, hogy kinyírja. Valakinek az oldotta meg a korrumpálódást, hogy kikapcsolta a logok tömörítését. De a fő, hogy Pötyi korrekt összefoglalást adott és rotálnak, ha kell, helyén van a damage control... Ne fárassz már. :)

> Ami nem túl vidám, de beleírva egy gzben kb pont ugyanez történik a zcattal. Az ugyan olvas, de csak garbage out van utána.

Ebben igazad van, de ki mondta, hogy feltétlenül gzippel tömörítsd a szöveges logokat? FS szintű tömörítés is van, hibakezeléssel. Persze atomtámadás ellen az sem véd, dehát semmi sem tökéletes.

És akkor itthagynék egy linket, amiben leírják, hogy a metaadatok loggolását a systemd nem konzisztensen csinálja, mert nem bírja cérnával a rendszer:

Logging reliable metadata? Only works "most of the time", recently watered down because of the performance hit of metadata retrieval.

> Már most azon lovagulunk, hogy az execline nem shell script? Kérlek, a deklaratív vs script vonalon maradjuk. A systemdben effektív iniket kell írni.

Itt meg envdirek vannak, envfile-okkal. Mi a baj vele?

> Ami szabad fordításban azt jelenti, hogy nem kaptál megoldást. Amiket ajánlanak, azok jellemzően scriptek.

Az ajánlás nem szentírás. Megírhatod Lua-ban is, vagy bármi másban.

> (Néztem egyébként, szerintem az se jó)

Szerinted. Én értem, hogy te utálod, de attól még nem lesz automatice szar.

> Amikor egy ilyen helyen shell scripttekkel kell játszani, az annak a beismerése, hogy rossz az absztrakciós réteg.

Fenéket. A shellscripttel ugyanúgy részegységeket lehet összekötögetni, mint bármelyik másik scriptnyelvvel. Ettől csak flexibilisebb lesz a rendszer. A systemd-sek kikiáltották a shellscriptet a sátán művének, az a patásscript. :P

> Ezt elengedem, mint rant.

Ne fölényeskedj, hanem nyisd ki a systemd bugtrackerét.

> Van az s6-svwait meg az s6-svlisten, ami megmondja, hogy valami elindult, vagy megállt, a többit pedig találd ki magad. Ehhez képest a systemdben egészen sok féle előre kigondolt és letesztelt függőség megoldás van.

A nagy túrót. Olvasd el, mi minden van még benne. (Pl. s6-supervise, s6-notifyoncheck)

> Hát, ezek szerint te nagyon felületesen nézted meg a systemdt. Wants - WantedBy, Requires - RequiredBy, stb. Van, amit nem így neveznek teljesen, de azt, hogy a függőségeket oda vissza lehet definiálni.

Mint te az s6-ot. De ezt a részt valóban nem néztem még, majd lecsekkolom.

> Nahát, mennyire genya vagyok, hogy a saját véleményem mondom. Csak én nem gondolom, hogy szentírás. FYI, a te szubjektív megítélésed sem az.

Én nem is mondtam. Te mondtad, hogy "normális". Neked normális max.

> Az előbbiek sokkal alaposabban megírt, több funkcionalitással rendelkező toolok, az s6 cuccai meg egy vékony minimum, nekem az előbbi sokkal jobban kézreáll.

Vékony minimum a francokat, olvasd el rendesen.

> A kettő összefügg. Ettől lesznek rendes resource limitek. Tudod, cpu, memória, ilyesmi.

Erre gondolsz?

> Egyrészt gyakorlatilag pont ezt mondtam, hogy patásördög lett, mert le akarták tolni a mindenkinek is a torkán, vagy legalábbis ez volt az interpretáció. Másrészt tmux sztorira ilyenre nem emlékszem, olyanra igen, hogy egy másik feature (a nem hagyhat a user random szarokat futni csak úgy maga után, másik nagy utált cucc, mert mit képzelnek) miatt kérték, hogy tök jó lenne, ha a tmux szólna automatán, hogy ne a usernek kelljen, megtartva a megszokást, de aztán volt valami fujjdbus.

Olvasd el a tmux fejlesztőjének az indoklását.

> No shit sherlok, nem mondod, hogy a fosul tervezett init és processzing miatt ezt faszott tangót kellett leimplementálni minden egyes daemonban, hogy aztán lehessen pid fileokkal raceconditionözni.

Nem kell "raceconditionözni" Watson, rendesen kell megírni. Nekem valahogy sikerült. És ez is elfedi az "agyrém gányolást" és nincs race condition. És működik minden UNIX alatt. (És egyébként itt szólok, hogy az általad említett double fork egyáltalán nem szükséges, a cikkemben erre is kitértem.)

> Nyilván a systemd is ad ehhez támogatást (mert különben ugye nem lenne rajta sapka), de el is mondják, hogy szerintük ez nem jó, oldja ezt meg az okosabb supervisor, semmint az összes deamon. Azok fussanak csak forground, és ne foglalkozzanak ilyenekkel, az apukájuk meg majd vigyáz rájuk. És ezzel a véleménnyel egyáltalán nincs egyedül, az s6 is pont ezt mondja, és csinálja tök elegánsan (emlékszel, mondtam, hogy cuki, nem vicceltem, az az exec chain egy elegáns megoldás)

De könyörgöm, ez a normális megközelítés.

> Ez egy rakás dns kliens. Vagy rendkívül fos a doksija, vagy nem értetted, mire gondoltam.

Egyik sincs kizárva. Fejtsd ki bővebben, hátha érteni fogom és akkor kiderül.

> Hát, ezt másképp látjuk.

Másképp. Eddig mindennek, amit felhoztál, volt megfelelője az s6-ban. Max. neked nem tetszett. Nekem meg a systemd nem tetszik.
Itt viszont tőlem okosabb ember írt egy nagyon részletes összehasonlítást az s6 vs. systemd témában, ahol kitér a leglényegesebb dolgokra, meg a végén a mítoszokra is, amivel a systemd evangelisták szoktak ködösíteni.

> Szóval tulajdonképp, ha alátolnék mondjuk egy tinit, és ettől a systemd a pid2 lenne, akkor már nem lenne baj? Vagy miért olyan rettenetes tragédia, hogy amit a rendszer felügyeletére akarok használni, az a pid1?

Kezded kapisgálni. Igen, ha át lenne zúzva egy csomó dolog a PID1-ből más processzekbe, akkor mindjárt negyedennyire lenne szar a systemd, mert nem tenné sokkal sebezhetőbbé (nem (csak) biztonságról van szó: stabilitásról, hibalehetőségekről) a rendszert; ha a PID1 összedől, vége a rendszernek. Ismét tőlem okosabb ember véleménye a kérdésben.

> Egyrészt a systemd messze nem pötyi egyszemélyes projectje. Másrészt pötyi hozza szokásos markáns véleményű doert, ami sok sok sikeres opensource project sikerességének egyik oka. Linus, DeKok, Theo, meg még egy csomóan nem egyszerű emberek. De szeretnél te csak fele olyan okos lenni, mint az a srác.

Nem szeretnék. Nagyon sokat kéne hülyülnöm ahhoz és nem azért, mert én akkora zseni lennék, hanem mert Poettering akkora majom. A megoldásaiból, a kódjából, a viselkedéséből mind-mind ez jön le. Csak egyetlen érv ez mellett: én elismerem, ha elbaszok valamit és nem kezdek kereszteshadjáratba, hogy megideologizáljam, hogy az úgy van jól. (BTW, miből gondolod, hogy én nem raktam le a saját területemen semmi számottevőt az asztalra? Nem tetszik a pofám, tehát automatice hülye vagyok?)

> És egy csomó mindent nem tud, amit a systemd igen. (VIgyázz, ha mégis, akkor hirtelen nem lesz érv, hogy miért ilyen bloat a systemd).

És de, tudja. Csak nem olvastad el rendesen a manualt. (Miért ne lenne? A systemd annak ellenére sokkal elhízottabb, hogy nem tud többet, legalábbis eddig nem derült ki, hogy többet tudna: máshogy tud dolgokat, esetleg (neked) kényelmesebben, de nem többet. Azonfelül a s6 100% moduláris. Annyit használsz fel belőle amennyit akarsz. A systemd-nél minden bele van borítva a PID1-be. De jó helyen van ott, már mondtad. Kettő bekezdéssel feljebb a link, hogy miért nincs.)

> A systemd is sok részből áll, rengeteg helyen hozzá lehetne nyúlni, ott a dbus, lehetne vele beszélni. Ja, nem a szokásos unixos IPCt használja, shell felől nagyobb szívás jönni.

Nem csak shellből. A "szokásos" UNIX IPC-re megvannak a kiforrott megoldások minden nyelvben/környezetben. Ez ilyen direkt máshogy csináljuk, mert csak. Ami nem lenne baj, ha jó lenne, de nem az.

> De a gyakorlatban az s6ból sem nagyon szokás larpurlart más használni mondjuk az s6-rc helyett, mert minek?

De lehet. Ez a lényeg. Lehet. Nincs drótozva.

> Egyrészt mind mondtam, ez a nem cserélheted le egyetlen részét sem ez erős csúsztatás

Tudom, nyílt forrás, át lehet írni, ki lehet dobni...

> másrészt nem erre gondoltam, hanem arra, hogy ezek az összecsiszolt részek sokkal részletesebb szabályok mentén tudnak együttműködni alapból. Ergo konfigolni flexibilisebben lehet, hogy mit szeretnél. Lehet, hogy nem ez a legjobb szó

Hát lehet, hogy nem a legjobb. Mert egy olyan laza szerkezetnél, mint az s6, ezerszer flexibiliseben kötheted össze a részeket és ennek a legnyilvánvalóbb bizonyítéka, hogy semmilyen s6 komponenst nem kötelező használni a setupban. Az s6-ot pedig ugyanúgy be lehet konfigolni bármire; fentebb az összehasonlító link.

> Egyrészt nyilvánvalóan poénból, másrészt azért, mert szokott menni a nyekergés, hogy pl a geci gnomeosok logindt (? asszem ezen szokott menni) használnak, és jajj szegény bsdk.

Pedig direkt kiraktam a smiley-t; ééééérted, szóvicc, busszal jön ide, débusszal, lehet; hogy szar volt, de érteni azért lehetett...