( TCH | 2020. 10. 10., szo – 22:41 )

> Mutattam is.

Nem. Eddig még nem sikerült. Csak olyat mutattál, amit máshogy tudott az s6. Lehet, hogy kényelmetlenebbül, vagy neked nem tetsző módon, de tudta.

> Pl, hogy a systemctl status kiementében gyorsan meg tudjon jelenni a unit naplójának a vége, vagy hogy lehessen értelmesen unitra, vagy időpontra szűrni anélkül, hogy mindjuk ki kelljen találnom, hogy hogyan lehet lefedni a timestampeket regexel, amik tegnap délelőtt 9 és 11 között készültek.

Ez oké, meg fasza, de erre adhatna olyan toolt is, ami ezt szöveges fájlban tudja és akkor ugyanúgy nem kell regexet szülnöd. A probléma nem a filterrel van, hanem a storage-dzsel.

> Értem én, hogy szerinted fontosabb, hogy text file legyen, mert hatalmas tragédia találni valahol egy journaltclt, és odadni --fileal, mint simán csak catoln, és edge casekben (file corruption) jobban viselkedjen.

Nem, nem az a baj, hogy ad egy szerszámosládát a naplófájlokhoz, hanem az, ahogy a naplófájljait kezeli.

> Csak ettől még nem lesz a bináris logolás agyrém.

Már pontosítottam: a systemd féle bináris loggolás agyrém.

> Akkor most próbáld meg még egyszer értelmezni, hogy mit mondtam.

Én értelmeztem, neked nem sikerült: pontosan arra válaszoltam, hogy beforgatjátok gzipbe, ha sokat foglal, arra írtam, hogy mivel text ezért jól fog tömörödni, szóval a helyfoglalás azért nem akkora probléma, mint ahogy felsoroltad.

> Azt az állításodat kellene bizonyítani, hogy a legkisebb sérüléstől teljesen olvashatatlan lesz.

Könyörgöm...bináris. Ott a legkisebb sérülés is szétbaszhatja az adatintegritást, ha rossz részt érint. Nyilván, ha az időbélyeg sérült valamelyik bejegyzésben, akkor nem feltétlenül lesz teljesen olvashatatlan, csak épp bullshit lesz benne.

> Én még tettem rá egy hevenyészett teszet is, amiből az látszik, hogy ez az állításod nem igaz.

Egy hevenyészett teszt => az állítás nem igaz. Kimertél egy vödörrel a tengerből, cápát keresvén... Robi, hova lett a másik lábad is?! Lerágta egy rája?! Jó ég...

> Pötyi leírása szerint jó eséllyel az állításod nem igaz.

Audio vox Dei. (Nem tudom, jól írtam-e.)

> Ez a két link erről semmit nem mond. Fogalmunk sincs, mennyire olvashatatlanok azok fileok.

Azt írták corrupted. Ami azt jelenti, hogy nem tudták olvasni, vagy legalábbis annyira sérült, hogy használni nem tudták a kapott eredményt.

> A második meg a benne levő információkból csak annyi derül ki, hogy valami compression issue volt, nem sok köze van neki a minimális korrumpálódáshoz.

Dehogynem, a compression issue miatt egy szekció hibás lett kicsomagolás után és elkorrumpálta a journalt.

> Ráadásul ez mindkettő sima bug, amiről magad mondtad, hogy nem para. Ami bugreport, az egészen úgy tűnik, hogy javult, ráadásul függetlenül.

Nem az a baj, hogy bug van benne, hanem a koncepció.

> Ne haragudj, hogy azzal hasonlítottam, ami jellemzően van egy standard setupban.

7z is van egy standard setupban, vagy mittudomén, más olyan formátum, aminek vannak hibajavításhoz eszközei. Egyébként tök jó, hogy ha én hivatkozok systemd bugokra, amiket az upstreamben már javítottak, akkor nem valid, hogy a "vadonban" még azok nagyon is élő bugok, de te hivatkozhatsz arra, hogy csak a disztró alapeszközeit hasonlítsuk a systemd cuccaival.

> Hagyd, de ne haragudj, ennyire nem érdekelnek a random iderángatott bugok, amiket találtál a bináris loggolással kapcsolatban, mert biztosan bármeddig tudod citálni. Biztosan az egész egy rakás szar, kész csoda, hogy van, akinek néha még van valami logja.

Ez nem bug. Minek adok én neked bármi forrást, ha nem olvasod el? Ez nem bug, hanem koncepciós probléma: annyira megterhelő a metaadatok folyamatos pakolása és tárolása, hogy leterheli és letérdelteti a rendszert.

> Miről akarsz még megygyőzni?

Arról, hogy a systemd minden további nélkül kiváltható az s6-tal.

> Az, hogy nem is érted, mit akarok mondani, Az s6-envdir simán csak a child futtatási környeztét állítgatja. Az összes többit neked kell lescriptelned. A unit fileok meg az egész rendszer működését így csinálják, nem kell neked semmit megírni, mert meg van csinálva. A nem kaptál megoldást, pontosan ezt jelenti: hogy nincs kész, neked kell megcsinálni.

Most vagy tényleg én nem értem amit te mondasz, vagy te nem érted amit én mondok. Az s6 is támogat egy unit-szerű környezetet, csak nem ini fájl van benne, mint a systemd-ben, hanem "ini dir". Adott az s6-rc-compile, aminek átadod azt a directoryt amit "fordítani" akarsz (egy raklap példa itt) és ugyanúgy összeállítja magának a service-t, mint a systemd, csak a systemd ezt belül csinálja magának minden alkalommal az unit fájlból, ez meg egyszer legenerálja belőle a service dirt, amit az s6-rc-db-vel beéleszthetsz. (És egyébként lehet systemd unitot s6 unitra konvertálni.) Az igaz, hogy ebben is van lehetőség scriptet írni (run file), de ez a systemd-re is igaz. És nem véletlenül. Ezek a unitok limitáltak, mind a s6-é, mind a systemd-é: ha túlléped igényben a tudásukat, akkor ugyanúgy scriptet kell írnod mindkettőben. systemd-ben is.

> Pontosan ezt magyarázom, hogy tök mindegy, hogy melyik másik program nyelven kell csinálni, az azt jelenti, hogy neked kell implementálni, mert programnyelv. Ehhez képest, a systemd -- jót, rosszat, sokat, keveset -- de kész megoldásokat ad a kezedbe, amiket csak fel kell konfolni.

Az a baj, hogy te a scriptekre - akár shell, akár más - rosszként tekintesz. Az előző bekezdésben leírtam, hogy akármit használsz, a unitjai nem mindentudóak. A scripteket pedig pont azért találták ki, hogy a különféle eszközöknek a ki és bemeneteit összekötögesd vele. Ez tehát nem valami ördögtől való rossz, mint azt a systemd-sek hiszik, hanem éppenhogy kurwa jó, hogy van, mert ettől lesz a rendszer végtelenül flexibilis, ettől tudhat tkp. akármit.

> Publikus projektek bugtrackerének nézegetésével maximum a dolog elterjedtségére lehet következtetni.

A Gentoo fórumon író fickó erre az érvelésre is kitért, mármint a popularitással való takarózásra:

"Few bugs have been reported in s6/s6-rc because they have few users."

As far as I know, systemd is one among the very few well-known open source projects that cannot control the growth of unresolved bugs, even with nearly two orders of magnitude more active developers than s6/s6-rc have. I also note that qmail has an extremely small total number of reported bugs, more than 20 years after its first release; I believe similar situations can be expected of s6/s6-rc, which closely follow the style of qmail.

Hogy ez mennyire így van; tekintsd meg ezt a listát: 20 még mindig nyitvalévő sérülékenység a systemd-ben, aminek a negyede súlyos.

> Abban igazad van, hogy elfelejtettem, hogy bele lehet írni a dependencyket egy fileba is, de sajnos az, hogy itt lényegében csak egy oda vissza transitive gráf van, nem változtat.

Értem és mi van még függőségkezelésként bedrótozva a systemd-be, amit nem lehet megoldani egy pársoros s6 scripttel?

> Egyrészt azt nézd meg, hogy hány féle típusú dependencia típus van

Tudtommal kettő, a want, meg a require és ezeknek lehet megadni, hogy after vagy before, de nem értem, hogy mit akarsz velük.

> egy saját unitból is meg tudom mondani, hogy egyébként baszki mostantól az sshd dependál rám anélkül, hogy hozzá kellene nyúlnom az sshd distró által szállított konfigjához. Ugyan mivel a systemd lehetővé tesz overrideolt paramétereket (amiket szintén azért tud, mert deklaratív), ez tulajdonképp menne másképp is, de pl az s6ban ez már szívás.

Elismerem, az override tényleg hasznos feature, de ezt s6-ból is meg lehet oldani, csak megint neked nem tetsző módon. :P
(Amúgy, szerintem ezt a feature-et be fogják emelni az s6-ba is előbb-utóbb.)

> Dehát pontosan ez az, hogy a fasznak feltalálni a spanyol viaszt minden egyes daemonban.

Azért, mert a systemd Linux-only. Pont.

> Nyilván te is azért nem csináltál double forkot, mert direkt ki akartál cseszni magaddal, hiszen az egy jó dolog.

Azért nem csináltam, mert nem kell. Leírtam, hogy akik double forkot csinálnak, azok miért tévednek: zombiprocessz nem lehet egy daemonból, mert az azt jelentené, hogy a PID1 szállt ki anélkül, hogy kiolvasta volna a visszatérési kódját, ami ugye az egész rendszer halálával járna, tehát egy daemon semmiképpen sem válhat zombivá; terminált meg nem nyitogat magától semmilyen program, ha meg kell egy terminál valamiért, akkor O_NOCTTY.

> Most non-supervision systems use a hack known as .pid files, i.e. the script that starts the daemon stores its PID into a file, and other scripts read that file.

És itt a bibi. Nem olvastad el a cikkemet. Nem a script olvassa ki és tárolja le a PID-et a .pid fájlban, hanem maga a daemon és a másik - vezérlés céljából indított - instance olvassa be, hogy ki kell-e szállni, vagy lehet futni.

> This is a bad mechanism for several reasons, and the case against .pid files would also justify its own page; the most important drawback of .pid files is that they create race conditions and management scripts may kill the wrong process.

Bibi #2: Ha elolvastad volna a cikkemet, akkor tudnád, hogy én az egész scriptelés dolgot kikerültem azzal, hogy a start/stop-ot is a daemon intézi. A signalt is a daemon küldi. Amikor elindítod magát a binárist, akkor először ellenőrzi, hogy van-e pid fájl és ha van, akkor kiolvassa, küld neki egy nullás signalt, ha létezik a processz, kiszáll, ha nem, akkor daemonizálódik. Leálláskor ugyaez, csak ott az van, hogy ha létezik a másik process, akkor SIGTERM-et küld neki, hogy álljon le és ha nem áll le timeout idő alatt, akkor meg SIGKILL-t. Script nincs.

> remélem sknak elhiszed.

Amit leírt, abban igaza van, de ő a scriptek által kezelt pid-ek miatti race conditionról beszélt. Még egyszer, itt maga a daemon kezeli a saját pidjét, nincs management script, a daemon ökoszisztéma, amihez a kitet adtam az self-managed. Race condition nem lehetséges, nincs minek mivel összeakadnia. Legalábbis én nem tudok olyan felállást elképzelni, hogy legyen, kivéve, ha direkt többször indítod el egymás mellett ugyanazt a daemont (aminek ugye nincs értelme), de akkor is annyi történik, hogy a legelső daemonizálódik, a többi meg érzékeli, hogy fut az első és kiszáll.

> Akkor mit szerettél volna mondani?

Félreértetted, az a normális megközelítés, amit lehúztál, hogy a daemonok maguk kezelik magukat. Úgy hordozható marad.

> Az s6 cli interface vs a mindenfélectlek interface. Ez utóbbi lényegesen több kényelmi segítséget ad. (És persze, ez megint szubjektív)

A kényelmi rész lehet, de az tényleg szubjektív. Tudásra megvan minden az s6 oldalon, csak mivel sok toolból áll, nem három darab xyctl-ből (mennyi alrendszer kezelése is van beleöntve a systemctl-be?), ezért elsőre úgy tűnik, mintha primitív lenne: nem az. Nagyon is szofisztikált. És - ismét a patásördög - scriptekkel nagyon faszán kaszkádolható.

> Hogy segít nekem ez megoldani azt, hogy ha konnektálok a céges openvpnre, ami split tunnel, és csak a 10.akármit viszi be csak az .encegem domainbe tartozó dns query menjenek be a céges dns szerverhez, a pornhub pl továbba se.

Ezt sajnos nem tudom. De jelen pillanatban ezt systemd-vel sem tudnám megoldani, mert ilyet még nem csináltam. Szóval ez nem azt jelenti, hogy az s6 nem tudja, hanem azt, hogy én nem tudom.

> Erre gondolnék, ha használná a cgroupsot, de sajnos nem teszi még, amennyire én tudom, az meg sajnos azért egy fokkal jobb mechanizmus.. (És még mielőtt nekiugranál, biztos, hogy lehet valami wrapperrel indítani az s6ból, ez biztos benne is van valamelyik összefoglalóban, és biztos igaz is)

Isoraz, szerintem maradjunk is ebben, hogy biztos megoldható, csak nem tudjuk, hogy hogyan.

> Természetesen lehet azon agonizálni, hogy ez az egész egyáltalán minek.

A minek még érthető lenne, de inkább az a kérdés, hogy miért így?

> btw, a distrok nagy része mégsem teszi, szóval szerintük se olyan rossz ötlet ez.

Ebbe inkább ne menjünk bele, hogy a disztrókészítők miért mennek ész nélkül a systemd után...

> Ők meg közölték, hogy ők be nem emelnek semmifélre új platform specifikus kódot.

Csontvázra vetkőztetve tényleg ezt mondták, csak így épp a lényeget sikerült kihagynod belőle: hogy van egy darab működő crossplatform függvény, ami 30 éve pontosan azt csinálja, amire itt szükség van és ehelyett kellene beemelni többtíz kbyte-nyi Linux-only kódot és még egy library függést is. Függést egy olyan librarytól, aminek az API-ját eddig már többször megváltoztatták az elmúlt néhány évben. És nem véletlenül emeltem ki a működőt az elején, lehet forgatni a szemedet, hogy már megint, de a daemon függvényben nem nagyon vannak bugok, a systemd-ben meg igen. És nem, ez itt ebben az esetben nem gizike-gőzeke, mert a daemon meghívást szerették volna lecseréltetni a systemd függőséggel és az egészet kapják vele, amire itt nincs is szükség.

> Nem én vagyok az, aki szerint ha a systemd nem tud uniq dolgokat felmutatni, akkor szar.

Nem is én, már bocs. Már megint szalmabábot ütsz. Én olyat sosem mondtam, hogy azért lenne szar, mert nem tud uniqe dolgokat. Sem itt, sem más topicban. Sőt, ebben a topicban még csak nem is nagyon csesztettem a systemd-t (a bináris loggolását leszámítva), csak annyit kértem, hogy hasonlítsuk már össze az s6-tal, hogy mit tud a systemd, amit az s6 nem. És félreértés ne essék, itt nem arról papolok, hogy ne lenne-e esetleg benne valami natív egyedi megoldás (a timerjei is egyediek), hanem arról, hogy mit tud, amit az s6 nem. És az a baj, hogy nem akarod elfogadni, hogy egy olyan komplex SCS, mint az s6, vagy a systemd esetén a független részek közti összehangolás (nem-csak-shell)scriptekkel való megoldása nagyon is valid. Pont a flexibilitás miatt. De a systemd ehelyütt mindent egybeönt. Ez a legnagyob baj vele.

> Gondoltam, hogy fogod majd linkelni, mert olvastam már, és mert egy húron vagy vele.

Egy hullámhosszon vagy vele, vagy egy húron pendülsz vele. Bocs a GN beszúrásért, de ezt muszáj volt. :P

> Kérlek vedd észre, hogy a táblázat nagy része erősen szubjektív, mind a konkrétumokat tekintve, mind azt az, hogy egyáltalán mit tart fontosnak.

Miért, a te véleményed nem szubjektív? Attól még lehetnek benne tények. Amit ez a fickó felsorolt, azok is tények voltak. Semmit nem tagadott le, amit a systemd tudott és semmit nem hazudott hozzá az s6 tudásához.

> Hogy nem akarod megérteni, hogy attól még, hogy mindkettő tud egy bizonyos featuret, attól még bizonyos szempontból lehet az egyik jobb, mint a másik.

Nem, én ezt értem. Csak az a bajom, hogy a systemd hiába tud adott területen hasznos dolgokat, amíg olyan dolgokat önt össze feleslegesen, amiket nem kéne és ebből egy csomó összeakadás keletkezhet. Tudod mi az overkill? Na, a tmux-ban a daemon függvényt lecserélni a systemd-re, az overkill. És nem szedheted szét. A KISS elvet nem véletlenül találták ki. Ami mindenre jó, az nem jó semmire. Ha Poettering feldarabolná a systemd-t független részegységekre és hallgatna a jó szóra, ahelyett, hogy abszurd válaszokat ad, amikor az abszurd ötletei abszurd hibákba torkollanak, akkor kb. az egyetlen komoly gond a systemd-vel a Linux-onlyság lenne. (Illetve az önmagában még nem feltétlen lenne gond, ha a készítők deklaráltan Linuxra akarnak fejleszteni, csak akkor ne akarják kierőszakolni, hogy az addig crossplatform eszközök az ő cuccaiktól függjenek.)

> Hidd el, értem én, hogy ha a pid1 megáll, akkor minden megáll, nem véletlen mondtam, hogy szerintem ennek lényegesen kisebb jelenleg a valódi jelentőssége, mint ahogy szeretjük előadni.

De, hát végülis csak a rendszer dőlt össze, ugyan kit érdekel az. :P

> In practice, ha a service manager megáll, akkor az esetek nagy részében annak a gépnek már úgy is mindegy.

De felcseréled az okot az okozattal: ha maga a service manager áll meg, csak úgy magától, akkor lehet (de nem biztos), hogy adott pillanatban annak a gépnek már mindegy, de az nagyon nem mindegy, hogy a service manager szeret csak úgy összedőlni. És minél több minden van beleöntve, annál könnyebben dől össze.

> És ha a systemd-t úgy ahogy most van betennénk mint egyetlen plusz processzt egy egyszerű init fölé, attól ugyanúgy nagyon szar lenne, ha megállna. És ez egyébként igaz lesz egy s6 supervisorra, egy daemon toolsra,meg egyéb másokra is.

És kapaszkodj meg: nem, korántsem lenne annyira szar, mert itt életbeléphetne a systemd-nek valami mitigációs rendszere, mert nem a rendszer dőlt össze, hanem csak egy processz! És ha a helyreállítások sikeresek voltak, akkor utána a PID1 újrahúzza a systemd-t és nem kell restartolni az egész rohadt gépet... (Nyilván, ha fail, akkor cumi, de az már nem a systemd sara.)

> Aha, jól látszik ez abból, hogy mennyire vagy képes fekete fehéren nézni a systemdt.

Mert te ugye nem fekete-fehéren nézed a systemd-ellenzők véleményét. Csak egy raklap hatert látsz, az érveiket nem, mert nem is akarod: ld. feljebb saját magad a bináris loggolás kapcsán a "ne hozzál ide még több linket" megközelítéssel.

> Pont abból, ami alapján te megítéled pötyit. Abból, amekkora blődségek itt kiesnek [szerk: néha ] a szádon szakmai szempontból, meg abból, hogy mennyire vagy képes megpróbálni felfogni mások nézőpontját.

Ebből vontad le azt, hogy nem raktam le semmit az asztalra, abból, hogy nem szeretem Pötyi bácsit...? Hát ez...priceless... Mutassak egy két cuccot amit csináltam? Kiváncsi vagyok, hogy értenéd-e, amit látsz, vagy te is csak legyintenél rá, hogy kit érdekel ez már manapság.
Szakmai blődség lehet, hogy esik ki [sz*rk: néha nem] a számon, de kién nem? Arról nem is beszélve, hogy jó eséllyel a blődségeim egy - nem definiált méretű - része nem is volt blődség, csak teneked nem tetszett a véleményem.

> Ráadásul már megint duzzogsz, ahelyett hogy értelmeznéd, mit mondtam..

Nem duzzogtam, értettem én, csak nem értettem egyet. Az nem ugyanaz.

> Nem hülyéztelek le. Akkor hülyéztelek volna le, ha a Pötyi szerintem is hülye lenne, mint szerinted. De ez nem így van, én egy kifejezetten értelmes srácnak tartom.

Én viszont nem. Azért, ahogyan kezeli a helyzeteket, amikor kidől egy csontváz a systemd szekrényéből. Itt van például amikor nem csekkoltak le egy pointert NULL-ra, ami ugyan emberi hiba, de utána közölték, hogy ők ezt a) nem tesztelik, b) nem javítják, mert nem foglalkoznak cgroups nélküli kernelekkel, bár hackeket raktak bele, hogy menjen. A bibi (ezen kívül) csak annyi, hogy a fickó, aki belefutott, az nem cgroups nélküli kernelt használt, hanem csak nem mountolta fel a cgroupsot a dockeren belül. Ja, ez user error is, de systemd error is. És nem ez a baj, hogy lemaradt egy rohadt nullcheck, (ki nem kúrta el ezt még sose), hanem az a reakció, amit adtak. (És megint, ha ez nem a PID1-en belül lett volna, akkor nem dőlt volna össze az egész rohadt rendszer.) A "megoldás" az lett, hogy kiszedték a dirty hackeket, ha nincs cgroups, akkor hibát dob és nem indul el. Ami oké, de a nullchecket csak azért sem rakták bele... Ez is korrekt szakmai magyarázat? Vagy damage control? Bocs, de értelmes ember így nem áll hozzá a dolgokhoz. És ez csak egy példa volt az abszurd válaszokra. (Tudom, ne hozzak többet, mert elhiszed, hogy van még...)

> vagy továbbra sem érted, hogy a máshogy is fontos, mert még mindig nem érted, hogy a systemd fő erőssége éppen ez a máshogy.

Mármint, hogy mi fontos azon, hogy "máshogy"? Máshogy a máshogy kedvéért? (Egyébként igen, a systemd-fejlesztők ebben nagymesterek.) A máshogy egy dolog, de a máshogy, csak azért, hogy máshogy legyen az rossz ómen.

> Szakmabeli vagy, ugye nem kell elmagyaráznom, hogy a nodeok ki/be menetének egymásra dugásához képest egy busnak milyen előnyei vannak egy komplex, sok elemes rendszerben, ahol gyakran szeretnénk új elemeket kivenni, betenni, illetve új kommunikációs párokat bevezetni.

Ez a "buszrendszer" létezik a kezdetek óta: úgy hívják operációs rendszer; rajta keresztül közlekednek a processzek között az üzenetek és alapból lehetővé teszi, hogy egy bemenetet/kimenetet többen írjanak/olvassnak, van sorbafűzés, van kaszkád, van logging, van bridge, van block, van minden, minden megvalósítható ezekkel az "elavult" módszerekkel már évtizedek óta.

> Arról nem beszélve, hogy azért nem akkora tragédia ám dbus üzeneteket küldeni shellből (mármint meg kell hívni egy parancsot)

Nem az a baj, hogy tragédia lenne shellből dbus üzenetet küldeni, hanem egyfelől az, hogy megint sokévtizedes működő platformfüggetlen konvenciókat rúgunk fel, for teh lulz, másfelől meg megint az, hogy egybe van ömlesztve és kapod, ha akarod, ha nem; a D-Bus alias Desktop-Bus elsősorban desktopok alá lett kitervelve; szerveren vagy beágyazott környezetben talán nem feltétlen van rá szükség...

> Neked ez a lényeg. Más meg esetleg leszarja, hogy nem tud valamit kicserélni, amit nem is akar, cserébe örül egy szorosabban összecsiszolt rendszernek.

Megint más meg megint nem szarja le. Folyton úgy állítod be, mintha egyedül lennék a véleményemmel. Biztos azért van egyre több deklaráltan systemd-mentes disztró, mert ez csak a trécéhá rigolyája. (És ugyanezen okokból van a distrowatchon direkt olyan lehetőség az initrendszerekre való szűrésnél, hogy "not systemd". Biztos én raktam bele, vagy csak nekem rakták bele.)

> Ehhez képest a systemd ezekből egy csomóra ad konzerv megoldásokat, amiken belül a szorosabb kapcsolat miatt egyszerűbb rendszerösszefüggéseket szabatosan megfogalmazni, ha jó a konzerv, akkor kevesebb dolgod van, és jó eséllyel kevesebb bugi lesz a megoldásban, mint ha on the fly kellett volna lefejleszteni (pl sokkal kisebb esélyed van rá, hogy egy hülye, primitív shell script syntax hiba miatt szopjál az ügyfélnél) Igen, ennek az az ára, hogy nagyobb, bizonyos tekintetben kötöttebb, és van benne olyan, ami akkor épp nem kell.

Ez idáig még rendben lenne, de mi van, ha nem jó a "konzerv"? Akkor viszont kerülgetheted a kupit, amit a systemd kötöttségei és integráltsága miatt baromi nehéz kivitelezni. Vagy taknyolhatsz itt is scriptet hozzá. Az úgy menni fog systemd-vel is, de nem arról volt szó, hogy azt itt nem kell?

> Azt kellene megérteni, hogy ez a két nézőpont nem jobb vagy rosszabb mint a másik, hanem más.

Én ezt értem. Leírtam, hogy mi a baj a systemd-vel és a fejlesztőinek hozáállásával, nem egyszer. Vagy nem érted, vagy nem akarod érteni.

> És a disztibútorok azért szeretik valószínűleg a systemdt, mert az ö szempontjaikból a good enough integrált konzerv jobb, mint egy "csak" szép tiszta alapokat adó új megoldás, mert nincs elég kezük.

Ebbe ne menjünk bele, mert ez aztán tuti parttalan vita lenne, mert ez ilyen "tabu", hogy az idealista nyíltforrású világon és lakóin kívül ott vannak a nagy profitorientált cégek, akiknek bizony erősen érdekükben áll, hogy a szoftverpiac arra menjen, amerre ők akarják...