( kroozo | 2020. 10. 08., cs – 22:48 )

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

> Netan te egyetertesz a binaris logolassal?

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.

> Es azzal, ahogy a dhcpcd es a dhclient csereje mukodik?

Fogalmam sincs.

> Szerinted nem volt ciki, hogy maskepp kovette a symlinkeket a sajat torles feature-uk par verzion at, mint az evtizedek ota megszokott rm?

De. És még egyébként volt még gáz bug is, Pötyering gyakran hozza az (open source project vezetőkre gyakran jellemző) nagy arcot és arroganciát, és tényleg elég nagy, és tényleg vannak részei, amiknél van adott esetben legalább néhány szempontból jobb célmegoldás.

Cserébe -- hogy eredeti kérdésedtől induljuk -- pl 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. Shellben programozni szar, meg egyébként is, ahogy pl itt is mondtam (ha tényleg érdekel, egyébként érdemes átfutni az egész szálat), az, hogy a szegény mellőzött openrc wiki bejegyzésében a példa service script hatvan sor, nem triviális hányásokkal (megannyi hibalehetőség) tele, az finoman szólva se túl biztató.  Az s6 is tök cuki  ahogy az exec()-es chain loadingot csinálja, de írni nagyon szar. 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.

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. Ebben egyébként az openrc, ahogy nézem nem annyira rossz (a többi nettó vicc, párat már próbáltam). 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.

Vannak benne normálisan kezelhető user unitok.

Van neki normális command line interface (és igen, voltak benne vicces bugok, és igen, időnként kevésbé jól működik a standard cli eszközökkel, mert eldilettánskodták a terminal handlinget) ami után egy ilyen sv és környéke a nettó fájdalom. (De ez is bug szokott lenni)

Van neki resource managementje. 

Van neki cgroup / namespace supportja.

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. 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. (Pedig érdemes elsétálni pl docker földére, ahol meg lehet szemlélni, hogy mi van, amikor ezen nem gondolkodtak előre, ezért aztán mindenki maga próbálja valahogy megoldani, hogy mikor kell indulni a mindenféle dependenciákhoz képest. Tanulságos kirándulás a cirkusz, elmegyógyintézet, siralomház bermuda háromszögben)

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.

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.

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)

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

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

É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.

És igen, ennek az integráltságnak ára van. Egyrészt viszonylag nehéz bele feszegetni mást -- bár ahogy én felületesen néztem, ahhoz képest, hogy mennyire komplex a problématér, elég tisztességesen szét van ez szeletelve, de kétségtelen, hogy lesz olyan pont, ahol sokat kell dolgozni annak, aki értelmesen akar valamit cserélni benne. Másrészt persze több a bug, mint mondjuk csak egy initben, és az integráltság miatt ez könnyebben (de legalábbis biztosan látványosabban) tova tud gyűrűzni a rendszerben. Meg persze abstactions leak, és egyébként is milyen szép is volt, amikor még kézzel kellett mknodolni, nem kell ezt túlbonyolítani. De az igazság az, hogy ma lényegesen komplexebb dolgokat csinálunk, és velem a hosszú évek szakami tapasztalata azt mondogatja, hogy ha van egy komplex probléma, 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.

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. Cserébe az integráció flexibilitása szinte biztos, hogy vackabb lesz. Meg hát, komoly kirándulás (idő, tudás) azt mind összerakni, kitesztelni, karbanstb stb, sokat tud segíteni egy handy eszköz. Nem olyan nagy baj ám, ha mondjuk a mindenféle DEk fejlesztői nem ezeken a dolgokon találják fel a spanyolviaszt, hanem valami hasznossal töltik az idejüket, amihez értenek. 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