( TCH | 2020. 10. 09., p – 12:11 )

> Eh, legyen, szó ne érje a ház elejét, hogy csak TCHt trollkodom :) Kezdjük a végével:

Hát, ha neked ez trollkodás volt...mert nekem erőlködésnek tűnt.

> Van egy csomó előnye, bár a defaulttá tétele kérdéses. Szerencsére ha nem tetszik, egy mozdulat használni mást.

Tehát baromi jó, de ha mégsem, akkor legalább forwardolni lehet, hogy ugyanazt kapjam, mint nélküle, tehát semmi értelme az egésznek.

A bináris loggolás egy agyrém, ami még Torvaldsnál is kiverte a biztosítékot, pedig ő direkt nem szállt bele a systemd vitákba. A logoknak pont az a lényege, hogy az ember is el tudja őket olvasni. Arról nem is beszélve, hogy a systemd logfájljai szeretnek korruptálódni, ami után teljesen olvashatatlan lesz az egész, a legkisebb sérüléstől is, míg a szöveges logoknál azért elég durva sérülés kell, hogy az egész olvashatatlan legyen.

A meta-adatokat meg szöveges fájlokban is meg lehet jeleníteni.

> van neki egész használható deklaratív interfésze, ami kb. senkinek nincs, mert mindenki shell scripteket gányol, ami szerintem totális zsákutca, és ez önmagában egy tök nagy feature.

Hát nem. Ezek szerint te nagyon felületesen nézted meg s6-ot.

> mindenki shell scripteket gányol, ami szerintem totális zsákutca, és ez önmagában egy tök nagy feature. Shellben programozni szar, meg egyébként is

Aszongya, hogy:
1. Először is, nem kötelező shellscripteket használni. Azt használsz, amit akarsz.
2. Az, hogy a SysVInit scriptekkel minden nyűg van, az nem jelenti, hogy mag a shellscripting szükségszerűen szar. Ez egy téveszme a részedről. Nézd meg a BSD.rc-t.
3. Tekintve, hogy a systemd-ben gombamód szaporodnak a javítatlan bugok, a shellscriptek okozta bugok száma ahhoz képest elhanyagolható.

> Az s6 is tök cuki ahogy az exec()-es chain loadingot csinálja, de írni nagyon szar.

Why?

> Nagyjából az összes disztró által annó összerakott shell script halom, ami ezt az űrt tölti be, rettenetes. Ezzel együtt nagyobb tételben mernék fogadni, hogy szerinted ez nem feature.

Feature-nek feature, de nem systemd specifikus.

> Aztán tud pl elég jó dependencia kezelést. De általában az szokott lenni, hogy ez nem hasznos, meg nem dolga, szóval bug.

s6-ban is van (Ctrl+F "Readiness notification and dependency management").

> a többi nettó vicc, párat már próbáltam

Ez így kevés: fejtsd ki, hogy mitől vicc az s6 függőségkezelése.

> Bár szűkebbnek tűnik a paletta, illetve pl a Verb - VerbedBy párosok azért igen hiányoznának, amikor az ember bővítene vagy overrideolna. Oh, wait :) Még egy jó feature, ami máshol nem nagyon van.

Bevallom, ezt nem értettem és hiába is kerestem rá, hogy systemd Verb VerbedBy, nem találtam semmit.

> Vannak benne normálisan kezelhető user unitok.

s6-ban is, csak nem files, hanem envfile-based dirs, ahol a változó a file. Ez mitől nem normális? Így aztán lehet bele konvertálni sysv-rc szkripteket, OpenRC szkripteket és systemd unitokat is.

> Van neki normális command line interface

s6-nak is. Mitől nem normális az szerinted? Ez már a sokadik, hogy a normalitásra hivatkozol. Nekem nagyon úgy tűnik, hogy te a szubjektív "normális" jelentését a saját szemszögeddel akarod megerőszakolni, te ex-katedra kijelented, hogy X a normális way és olyan nincs másban. Hát ez nem így működik.

> Van neki resource managementje.

Clarify pls.

> Van neki cgroup / namespace supportja.

Isoraz, mit támogat a cgroupson?

> Van neki notify mechanizmusa a deamonok számára, hogy el tudják dönteni és jelezni tudják, mikor üzemkészek, ami baromi hasznos tud lenni.

http://skarnet.org/software/s6/ftrig.html#notification

> De ez pl tipikus patásördög, mert mit képzel magáról pötyi, hogy majd miatta megpeccselik a világ összes deamonját.

Te keversz valamit. Nem az baszta ki a biztosítékot, hogy van daemon-notify benne, hanem az, hogy azt akarták, hogy a világ összes daemonja a systemd daemonizerét használja. Ld. a tmux esetét, na ott megkapták a magukét.

> Van neki socket activation supportja, amit megint csak egész faszán fel lehet használni mondjuk forgalom kiesés nélküli service upgradehez / rekonfighoz / restarthoz / lbhez.

http://skarnet.org/software/s6/socket-activation.html

> Alapjáraton eltünteti a pidfileos, double forkolásos teljes agyrém gányolást. Igen, tudom, ezt más is csinálja, de megint csak mondjuk a "miért nem ez lett a strandard" openrc pl nem tesz ellene semmit.

Agyrém gányolás? Jó reggelt, az UNIX így működik. Szerinted a systemd daemonizere mit csinál belül? BTW: http://jdebp.eu/FGA/systemd-house-of-horror/daemonize.html

> A resolved pl szintén pfujj pfujj, világbezabálás, cserébe két mozdulat megoldani vele pl, hogy menjen a split dns, ha épp fent van egy openvpn tunnel. (Igaz, mást meg időnként elbasz a lelkem)

http://skarnet.org/software/s6-dns/

> Van interface, hogy daemonok tudjanak érdemben kommunikálni a tűzfal fele.

Hogy mi?

> Van benne olyan cron, ami össze tud nőni a servicekkel, dependency managementtel, ami azért elég faszogányos.

Ezt aláírom. A systemd timerek tényleg jók. Csak épp cron alternatívából dunát lehet rekeszteni. Még jobbakkal is. (Mesos + Chronos) Ettől persze a systemd timerek még nem lesznek szarok.

> És igazából egyébként ez a legnagyobb feature, hogy ezeket a -- többnyire viszonylag normális, néha kicsit büdös, ritkán nagyon szarul csinált -- featuröket szép szoros integrációban adja, és együtt lehet őket használni. De éppen ez az, ami általában legjobban kiveri a biztit azoknál, akik szerint a systemd szar.

Nem. Egyrészt ezt más SCS-ek is tudják, nem csak a systemd. Másrészt meg nem konkrétan az integráció a baj, hanem az, hogy ez mind a PID1-be van beleöntve. Ez szokta kiverni a "biztit".

> akkor összességében jobb, ha okos emberek egységesen próbálják meg rendszerbe szervezni főműsoridőben, mint ha egyszeri random fejlesztő / distribes csomagolóember / rendszergazda próbálja megoldani mindenhol, mert az még sokkal szarabb lesz.

Ez igaz. De Poettering nem okos ember. Amit ő művel néha, az már-már az elmeháborodottságot súrolja.

> Mert persze mindezt nyilván össze lehet rakni a one thing and one thing well tradicionális unixos szemléletű eszközökből, csak ott már az egész rendszerre mérve jó eséllyel nem lesz sokkal jobb mondjuk a bug látkép.

Miért is lenne? Az s6 úgy van összerakva, hogy egymással kommunikáló, de független részegységekből áll. Ez UNIX-os szemléletű és mégsincs tele bugokkal.

> Cserébe az integráció flexibilitása szinte biztos, hogy vackabb lesz.

Hogy mi? :D Ha mindent egybeöntünk, ahelyett, hogy részekre lenne szedve, akkor az szerinted flexibilisebb? Bakker, az pont, hogy merevebb, hiszen szükségszerűen egybe van öntve az egész, aminek nem cserélheted le egyetlen részelemét sem...

> a KDEsek azon gondolkodnak, hogy ez már a kde4-e, a gnomeosok, meg hogy a fejlődés jegyében ma melyik beállítást tüntessék el. :D

Ez igaz, de hogy jön ide? DBus-szal? :]