Új szolgáltatáskezelőt ír az Alpine linux csapata

Lecseréli a meglévő OpenRC -t az Alpine csapata, mivel egy éve nincs újabb commit.
Lényegében egy jól megcsinált SystemD alternatívát készítenek a közösségi visszajelzések és megbeszélések alapján.
Ugyanez bő lére eresztve: https://skamilinux.hu/uj-szolgaltataskezelot-ir-az-alpine-linux-csapata/
Az eredeti bejegyzés: https://ariadne.space/2021/03/25/lets-build-a-new-service-manager-for-a…

Hozzászólások

"jól megcsinált SystemD alternatívát készítenek "

Ouch...Ez fájt...

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

Szerkesztve: 2021. 05. 11., k – 20:05

Most nézem egyébként a blogpostot: benne lesz a buliban skarnet is, aki az s6-ot csinálta, szóval ebből akár még jó is kisülhet, bár kíváncsi leszek mennyire fog hasonlítani a systemd-re és mennyire az s6-ra. Meg arra is, ha ez systemd done right, azaz kihajigálják a systemd koncepciójából a marhaságokat, akkor mi marad? :D

Nem ül a poén; a systemd szinte semmit sem örökölt/tanult/emelt át a SysVInitből, tehát nem lehet addig gyalulni, amíg csak az marad. A systemd inkább az Apple féle launchd/launchctl ökoszisztémát próbálta meg majmolni (a parancsok/kifejezések/változók egy részével együtt), csak egyfelől tette ezt agyhalott módon (scope creep, tutti frutti PID1, bináris naplók, évtizedes működő konvenciók leszarása és felrúgása, WONTFIX-szindróma, stb.), másfelől meg az implementiáció minősége rengeteg kívánnivalót hagy maga után (instabil, sechole-os, bloated, évtizedes működő funkciók asszimilálása és újraírása szarul, WONTFIX-szindróma, etc.).
Vagy csak én nem értem, mire célzol?

A kérdés jó, de én nem tudom a választ. Nekem jó lenne. :)

Lehet, hogy azért, mert az s6 túlságosan eltér a systemd-től, itt pedig most nem egyszerűen alternatívát akarnak csinálni, hanem drop-in replacement-et, hogy legyen fedéspont az Alpine és a systemd-infected disztrók között és ne lehessen mondani, hogy az Alpine valami obsolete és/vagy untergrund izét használ, mert egy olyan SCS-ük van, ami kompatibilis a systemd vackaival és egy mozdulattal át lehet rá állítani egy systemd-s rendszert és ezt úgy is értheted, hogy a systemd-s rendszerben cseréled az SCS-t systemd-ről erre, de úgy is, hogy magát a rendszert cseréled Alpine-ra; azaz lehet a cél az, hogy így szerezzenek usereket, vagy piaci részesedést, de az is, hogy a systemd-nek bevigyenek egyet, lévén rengeteg disztró és user csak behódolt a systemd-nek a függőségek és a többi SCS/initrendszer szándékos marginalizálása miatt, de ha van valami, amivel egy mozdulat átállítani a rendszert bárminemű következmény (értsd: inkompatibilitás) nélkül, akkor lehet, hogy sokan átállítják a rendszerüket. (A két lehetőség távolról sem zárja ki egymást.)

Fentebb apal mondta a PulseAudio -> PipeWire analógiát, ami szintén egy drop-in replacement; itt sincs kizárva ez a felállás. De ez csak tipp. A legbiztosabb, ha őket kérdezed meg.

Erre a célra miért nem felel meg az elogind használata tetszőleges, már meglévő init rendszerrel, mint pl. az s6 vagy az openrc? Vagy ebben az esetben nincsenek reprodukálva a systemd háklijai?

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Arra, hogyha kidobod a systemd-bol az osszes agyhalalt, akor marad a sysvinit jellegu sartup-script halom es a kerek ujrafeltalalasa.

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

Van aki csak addig lát hogy jaj ez komplex jaj a pottering beszólt jaj sok a szekuriti issue, de azt nem nézzük meg hogy valamire amúgy jó is ez.

Amúgy az alpine linuxosok nem a minimál konténerek környékén mozognak sokat? Nem biztos, hogy general purpose szolgáltatáskezelőt akarnak irni (de nem olvastam el a mellékelt cikkeket még, szóval fixme)

Sure, csak a sysvinit és tsai esetében ha egy valamit elszúrtak, az jó esetben csak egy dolgot érintett, ha a keretrendszer jellegű a dolog, akkor ha az szarul van implementálva az mindent érinteni fog. Nagyon át kell az ilyent gondolni és tervezni. A túlságosan egy dologra építkező rendszerek könnyen managelhetőek, de kártyavárak. Kihúzol egy kritikus részt és dől össze az egész. Minél több komponenst teszel kritikussá, annál ingatabb lesz.
Nem, legyen egy fix szabályrendszer felállítva, legyenek könnyen beemelhető komponensek, de ne jöjjenek be függőségek.

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

Szerkesztve: 2021. 05. 12., sze – 14:59

Az alapértelmezett Alpine service manager az OpenRC. Ehhez nincs új commit egy éve. Ezt le kell váltani szerintük és nem foltozgatni meg karbantartani, mert  elavult.

Itt az idő egy modern, eseményvezérelt és unit -okon alapuló, dinamikus szolgáltatás vezérlő rendszernek, ami tudjuk hogy régóta beszédtéma a unix/linux közösségekben, de jelenleg mindössze egy nagyon komoly vallási háborúról beszélhetünk.

Az Alpine csapata máshogy döntött. Ebből jól jöhet ki az Alpine alapú mobilrendszer a PostmarketOS, de mi is, akik régi gépeken használjuk asztali rendszerként, ahol a hálózatkezelő beröffentése egy kis plusz munkát igényel jelenleg, illetve hatással lesz nyilván a többi aarch64, armhf, armv7, ppc64le, s390x, x86, x86_64 alapú kiadásokra is.

Puppy linux, mert megérdemlem. http://skamilinux.hu

Igen, ez a másik lehetséges ok, viszont az valószínűsíthető, hogy az Alpine jelenléte a mobiltelefonos és egyéb ARM alapú szegmensben és a konténertechnológiában, ahol egyre gyakrabban alkalmazzák, új igények jelentek meg, így feltehetőleg komoly igény lépett fel az elavult scriptes megoldások leváltására.

Egyszerűen arról van szó, hogy ennél sokkal dinamikusabb és testreszabhatóbb rendszerkezelést szeretnének megvalósítani az eszközkezeléstől a hálózatkezelésig mindenben.

Nem maga az OpenRC elavult,  egyszerűen kell egy jobb eszköz, egy modernebb és hatékonyabb az új megoldásokhoz és igényekhez igazítva.

Ebben elavult és lemarad folyamatosan az aktívan fejlesztett megoldásoktól.

Puppy linux, mert megérdemlem. http://skamilinux.hu

Itt az idő egy modern, eseményvezérelt és unit -okon alapuló, dinamikus szolgáltatás vezérlő rendszernek, ami tudjuk hogy régóta beszédtéma a unix/linux közösségekben, de jelenleg mindössze egy nagyon komoly vallási háborúról beszélhetünk.

Igazából volt belőlük bőven. Az egyik legjobb a már szóbakerült - és egyébként elméletileg bármilyen POSIX rendszeren működő - s6, a másik a BSD-s - de Linux-compliant - nosh. A vallásháborút az okozta, hogy a systemd-t kizárólag politikai okokból adoptálta a Linux disztrók többsége; gőzerővel folyik a Linux elwindózosítása és ezzel párhuzamosan a UNIX világ ellinuxosítása is. Ha már skarnet szóba került, erről ő is írt pár szavat.

erről ő is írt pár szavat

Ezzel még nagyrészt egyet is értenék, de a következő kijelentések borzasztóan irritálóak, és számomra ezért veszít az írás a hitelességéből.

(The other more or less viable development model for a project is to be company-driven: making up for the lack of technical excellence with manpower and procedures. Needless to say, companies usually do not produce either free or good software, and they are not efficient at doing so.)

Attól, hogy egy szoftvert fejlesztése céges környezetben történik, még nem biztos, hogy technikailag rosszabb, vagy kevésbé hatékony. Biztos vannak erre példák, de ennek ellenkezőjére is vannak példák. Ez inkább annak a kérdése, hogy a management hová helyezi a prioritásokat, adnak-e kellő időt és szabadságot a fejlesztőknek, hogy a lehető legjobb minőségű szoftvert készítsék el.

The distribution model of systemd, made of lobbying and bullying, is much more akin to the distribution model of Microsoft Windows than the one of GNU/Linux.

System software should stay the heck out of the way, which is exactly what systemd does not. In that respect, it is very similar to Microsoft Windows. Again.

Nem teljesen tudom, hogy ezekkel a hasonlatokkal mire utal akár a systemd, akár a Windows szempontjából. Így pedig ez az érvelés úgy hangzik, hogy ami olyan, mint a Microsoft Windows, az csak rossz lehet.

Ezzel még nagyrészt egyet is értenék, de a következő kijelentések borzasztóan irritálóak, és számomra ezért veszít az írás a hitelességéből.

Fordítás: a windows-t negatív példának használta az írásban, ezért felkaptad a vizet és zsigerből elutasítod amit mond és vagy nem tudod, vagy nem akarod megérteni, hogy mit és miért írt.

Attól, hogy egy szoftvert fejlesztése céges környezetben történik, még nem biztos, hogy technikailag rosszabb, vagy kevésbé hatékony.

Feltűnt az "usually" szó használata? Lássuk be: a cégek általában tényleg csapnivaló szoftvereket készítenek, illetve, amit sikerül is jól megcsinálni, azt is elkúrják, mert fontosabb a profit a minőségnél. Idevágó írás a "muszájfejlesztésről".

Biztos vannak erre példák, de ennek ellenkezőjére is vannak példák. Ez inkább annak a kérdése, hogy a management hová helyezi a prioritásokat, adnak-e kellő időt és szabadságot a fejlesztőknek, hogy a lehető legjobb minőségű szoftvert készítsék el.

És mivel a management a legtöbb esetben azt nézi, hogy hogy lehet a legnagyobb profitot kihozni a dologból, így nem fognak kellő időt és szabadságot biztosítani a fejlesztőknek a jó munkához, hanem leginkább minél olcsóbban és gyorsabban összekalapáltatják.

Nem teljesen tudom, hogy ezekkel a hasonlatokkal mire utal akár a systemd, akár a Windows szempontjából.

Az nagyon szomorú, mert ennél plain-ebb english-ben nem is mondhatta volna.

Az első mondat a terjesztési metodikáról szól, amit az ms lobbizással és fenyítéssel csinál. Azaz, az ms megy és megveszi kilóra az adott "terület" (legyen szó cégről, intézményről, alapítványról, vagy akár egy egész országról) illetékes döntéshozóját, a konkurenciát - meg úgy kb. mindenkit aki útban van - tőkével és jogászokkal eltapossa, vagy legalábbis megpróbálja. Eléggé meglepő, hogy nem emlékszel olyan dolgokra, mint pl. az SCO patent-trollkodásai, a PECSA-razzia, a Netscape megsemmisítése, a BSA által tönkretett cégek garmadája, a vesztegetési botrányok tömege, a MikeRoweSoft ügy, vagy amikor a GVH szét akart csapni a Fővárosi Bíróságon az illetékesek között és hirtelen megjelent Ballmer és nem lett belőle semmi, vagy épp az, amikor milliárdokat húztak ki az adófizetők zsebéből "Digitális Otthonra" (ahol majd a tévé nézi a nézőt).
És az RHEL ugyanígy működik, ugyanígy dolgozik, csak mivel nem ugyanakkora, mint az ms és nem ugyanaz a célpiac, ezért nem annyira feltűnő, meg esetleg a módszereik "finomabbak". De mindenesetre ez baromi távol áll az opensource világ opcionalitásától, ahol felteszi mindenki a cuccát a hálóra - az most mindegy, hogy amit írt az rulez vagy sux - és aztán használja aki akarja, neadjisten belefejleszt, vagy folytatja más irányban. A systemd ugyanúgy kvázi-kötelezővé vált a linuxos világban, mint ahogy annak idején a windows a valódi világban: letolták az emberek torkán erővel - választás nem volt.

A második pedig a szoftver viselkedéséről szól, ami a windows esetében az erőszakos tolakodás. Felzabálja az erőforrásokat, összedönti a gépet, lefrissíti a rendszert, ha kell erőszakkal, letörli a júzer fájljait, vagy épp felszinkronizálja őket egy - a júzert rommákorlátozó "biztonsági mechanizmusokon" simán átmászó - zsarolóvírus beszopása után a felhőbe, had vesszen el ott is és még sorolhatnám a windows "gyönyöreit". Ott szívatja le a júzert, ahol csak tudja.
A systemd ugyanez csak pepitában, de a végeredmény ekvivalens: a júzer szívatása. Minden fontos szolgáltatást és programot asszimilálni próbál, hogy ne lehessen megkerülni, de mindent beleönt a PID1-be, hogy még egy piszlicsáré funkció vakvágányra futása is a teljes rendszer teljes összeomlását eredményezze. Az asszimilált funkciókat teljesen agyhalott módon oldja meg, felrúgva az ismert konvenciókat, amik évtizedek óta működnek minden rendszeren, csak azért, hogy ne legyen kompatibilis és juszt is hozzá kelljen igazodni. (Ez a viselkedés is vajon honnan ismerős...?!) Ugyanúgy elveszi a kontrollt a júzertől, mint a windows és ugyanúgy nem működik.
(Tudom a windows és systemd believereknek sosem veszi el a kontrollt, de mindig működik, csak "érteni kell hozzá", aztán ha mégse, akkor arra másnap már nem emlékeznek. A masszív vallási fanatizmus szempontjából is simán párhuzamot lehet vonni a két rendszer között, ez is milyen érdekes...)

Csupán csak ennyit akart mondani az analógiáival, hogy mivel mind a kettőért egy erőszakos multi felel, ezért a terjesztési és a működési "megközelítéseik" is nagyon hasonlóak. Ezt és nem azt, amit te mondtál:

Így pedig ez az érvelés úgy hangzik, hogy ami olyan, mint a Microsoft Windows, az csak rossz lehet.

Nem, ez az érvelés nem így hangzik, csak te hallod így, vagy akarod hallattatni így. Ilyet egy szóval nem mondott, hogy ami olyan, mint a windows az csak rossz lehet, ezt te láttad, vagy magyaráztad bele.

Az openrc-t folyamatosan fejlesztik. 9 órája is volt commit. Az elmúlt egy évben több új verzióra emlékszem.

Nem értem az Alpine-t, hogy minek kell még egy init rendszer.

https://xkcd.com/927/

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."