Szegény systemd-t a mentaág is húzza [kattintásvadász]

Külön magyarázat (és szövegkörnyezet nélkül) a Linux Mint blog július 2-ai bejegyzésének vonatkozó részlete:

This is a lesson for us and it confirms that we should rely on frameworks such as systemd or debhelper as little as possible.

Ha így haladunk, öt--tíz év múlva talán lesz SystemD-mentes Linux Mint is. :) (Mondom: talán...)

Hozzászólások

Pedig nem érdemes a szövegkörnyezetet kihagyni.  Ha jól értem, akkor ez egy debhelper upgrade side effect (bug?) volt, ami ugyanúgy engedélyezhette volna az autoupdate service-t non-systemd környezetben is.

Csakhogy nem azt mondták, hogy ez a systemd hibája volt, nem arról van szó, hogy fujfuj systemd, mert egy random segédprogram egy bug miatt engedélyezte a systemd autoupdaterét, hanem arról, hogy nem dependálunk feleslegesen mindenféle környezetre. Non-systemd-sre se. Amiben igazuk van. Ha úgy csinálták volna elsőre, akkor a non-systemd környezetben se kapcsolta volna be az autoupdate-et.

A mai szoftverek egyik legnagyobb baja a dependency hell.

És az miben is különbözik, amikor egy-egy alkalmazás behúz feleslegesen n+1 csak általa sem használt shared libraryt? Épp tegnap szívtan egy ordasat Gwenview-val, mert berántott egy libet, ami rántott magával egy másik libet függőségként, aminek a csomagjában volt egy SVG, amit nem tudott bemásolni a helyére. Ennek hatására az első gwenview függőség nem települt. Az egész csomagmanagement agyhalál állapotába került. A legszebb, hogy mindezek ellenére a gwenview probléma nélkül futott. Igen sok olyan project van, amelyiknél bekerül egy-egy, "akkor még jó ötletnek tűnt" jellegű library, amiből jó ha egy-egy eldugott almenűnek az almenűjének a helpjében használnak egy függvényhívást.
A legszebb, mikor egy disztribúción belül ugyanannak a libnek, 2-3 verziója héderezik, mert egyes funkciók a szélirányváltozásoknak megfelelően változnak (Hello python, hello php). Aztán ott van a rendszeres, tegyünk bele scritnyelvet(!!!!4444) fantasztikus ötlet. Amit ugyan senki nem használ, mert a lángelmék brainfuckot választották, de legalább annak a libje is telepítésre kerül. Jah, de abból is csak valami ezoterikus verzió, mert amikor kimerült a support kedv, akkor senki nem updateli naprakészre.
Használok jónéhány statikusra  fordított alkalmazást (főleg célszoftvereket) és el nem lehet mondani, milyen jó érzés, mikor függetlenül a operációs rendszertől, mindig, minden ugyanott, ugyanúgy van, és ugyanúgy működik. Nem kell állandóan kitalálni, hogy épp hova tünt valamelyik gomb, vagy épp hogyan kell befengsuizni egy 1000 feletti számot egy textboxba, csak mert a UI fejlesztőknek gyereke épp tanulja a helyiértékeket.

Még egy aprósággal visszakanyarodva a nyitó poszthoz, az sem mindegy, mikor egy alkalmazás képes elcseszni egy rendszerbeállítást, pusztán csak a fejlesztőjének az autizmusa miatt. Ugyanis, ez a Linux egyik legnagyobb rákfenéje, hogy csodásan biztonságos, mindaddig míg valamelyik alkalmazásnak a fejlesztője azt jobban nem tudja.

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

"csodásan biztonságos, mindaddig míg valamelyik alkalmazásnak a fejlesztője azt jobban nem tudja" - Debian és az ssl esete? :-)

A statikusra linkelt binárisoknak is megvan a maguk helye/szerepe az ökoszisztémában, azonban arra oda kell figyelni, hogy az egyes beledrótozott komponensek sérülékenységei ott lesznek a rendszerben egészen addig, amíg új bináris nem érkezik. Ugyanes pepitában a dokcer vagy más konténerekkel...

Nekem az "tetszik", amikor egy szolgáltatást (pl. postfix) telepítés végén el is indít a drágalátos, miközben a konfiguráció a default paramétereket tartalmazza, ami nem minden esetben jó... Talán postfix volt, amivel így szívtam egy olyan gépen, ahol az IPv6 teljes egészében le volt tiltva. aptgetinstallpostfix, post install script fali led :) mert ugye indítaná, de a ::1/128-ra nem tud rácuppanni... 

Igen.

A dinamikus linkelés nem ad védelmet, a sérülékenységet csak egy másik szintre helyezi át és ráadásul nem egy hanem több alkalmazást is érintetté tesz vele. Szóval, egyik sem szent grál.
A postfixes sztori, klasszikus Linuxos tervezetlenség. Nem képesek izolált, definiálható állapotokkal rendelkező rendszerekben gondolkodni. Hiányoznak a fallbackek. Mint amikor Pistike (vagy jómagam) kódolni kezd a visszatérési értékek vizsgálata és azok mindenre kiterjedő kezelése nélkül.

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

"a sérülékenységet csak egy másik szintre helyezi át és ráadásul nem egy hanem több alkalmazást is érintetté tesz vele" - és a javítás nem egy, hanem az összes érintett alkalmazásra megtörténik - a dependency-k miatt ráadásul lehet tudni, hogy adott libficemfacom.1.2.3.so melyik alkalmazást érinti - ha statikusan bele van gyógyítva, akkor meg nem igazán...
Tökéletes megoldás nem igazán van - a _jól_ behatárolt, kordában tartott és dokumentált függőségek inkább segítenek, mint problémát okoznának. Az, hogy mindenhez _is_ hozzálinkelnek 1234 olyan kompnenst (és ezzel a függőségi hálót növelik), ami csak néhány corner-case kiszolgálásához szükséges, nos, az a fejlesztői/karbantartói lustaság. (foo-bar-baz-X, foo-bar-baz-noX foo-bar-baz-simple és hasonló csomagok buildelése és terjesztése helyett van egy foo-bar-baz, amihez minden _is_ kell... )