( gyu | 2018. 03. 01., cs – 14:46 )

Ezt kicsit nem értem. Kijelölöd a RH-et mint követendő irányt, miközben meg te magad is látod, hogy a systemd mekkora egy rakás sz..r.

Erről a klasszikus vicc jut eszembe, minél a csattanú ugye úgy kezdődik, hogy: Vadász, vadász, ...

Miközben ha megnézed a teljes szoftver-szolgáltatás-* ökoszisztémát, akkor látszik, hogy a RH/bármelyik disztrókészítők szintén csak követik a fejlődést. Na jó, van némi minimális kontribúciójük is. Az ilyen abominációk/blaszfémiák mint a systemd.
A kernelhez talán csak értelmes embert hagynak hozzányúlni. Pillanatra most el is gondolkodtam rajta, hogy nem-e a linux védelmében hagyják Pöteringet systemdz-ni: Addig se nyúl a linux kernelhez, aztán mikor már elég gáz a cucc, akkor kihajítják az egészet és csinálnak egy gpl-es smf-szerű rendszert.

Az irányt nem ők írják. Az olyan cégek írják, mint a Google, Amazon, ... esetleg még Facebook.
Ahol ahhoz, hogy piacvezetők tudjanak maradni, folyamatosan kell újdonságokkal, valódi új szolgáltatásokkal kijönni.
A google-nek ott egy Google I/O, Az Amazonnak pl. az Innovate, stb.
Vagy nézz meg egy Lisát, Fosdemet, stb. hogy honnan jönnek nagyon sokan előadni, részt venni, stb.

Meg nézd meg aztán ezeknek a szofterfejlesztési módszertanait, hogyan tudnak jó minőségű szoftvert, sokat, gyorsan önteni ki a nagyvilágba, illetve szolgáltatásokat, meg azokhoz a szoftvereket fejleszteni!

Már kb. a RedHat is belátta, hogy képtelen a disztrót értelmes sebességgel frissen tartani. (Debiantól meg soha nem is vártunk ilyet.)
Igény meg lenne rá, hogy modern eszközök legyenek! Mert ha folyamatosan a backward compatibilityn kell embernek törpölnie, akkor nem halad a fejlesztés! Lásd a múltkori linkem a semver.org-ra, verziószámozást illetően.
Ma már a klasszikus "sysadmin"ság kihaló szakma. Automatizálod a telepítést is. Mindegy, hogy kayak-kal, kickstarttal, seedfile-al, vagy mivel. A lényeg, hogy ahogy új node-okat tolsz be a rendszerbe, a gép használatbaállításáig ne kelljen embernek hozzányúlnia, max pár configot átütsz egy file-on, aztán git commit.
Ha gyorsan, fenntarthatóan akarsz platformot építeni, akkor nem telepítgetsz ma már linuxokat, unixokat, stb.
Fogsz pl. egy openshiftet, és használsz more ore less minőségbiztosított image-ket. Vagy megcsinálod a saját pipelinejaid.
Írsz teszteket, hogy mit vársz a rendszertől. Ha nem megy valami, akkor nem deployolod productionbe. De még ezt a döntést se kell embernek meghoznia. A fejlesztő max egy zöld vagy piros visszajelzést lát a Jenkinsében, aztán majd oknyomoz, hogy miért nem deployolódott a micsoda.

Egy ekkora ökoszisztémában most egy systemd... Jah. Gáz. Egy erős technical debt. Az openshift node managelésére úgyis kb mindegy, mert max az LB oda nem küld terhelést ahol a systemd miatt elborult a node, a scaling érdekében meg majd másik node-okon spinupol néhány új pod-ot, és mehet minden tovább.

Megnézed, mire épül az egész?
Kubernetes.
Google.

A redhat már csak annyit tesz, hogy csomagolja neked azokat a technikákat, amiket a google, meg a többi nagy ont magából.

hwgyártó + support kérdés is ma már egyszerű: eldöntöd milyen szolgáltatást szeretnél: valamit, ami skálázódik, és akkor Amazon, Microsoft meg talán még a Google felhő, amik nagypályások.
Vagy szenvedsz magadnak avval, hogy az alapoktól felépíts mindent, amihez a nagyok már rég kínálnak neked profin összerakott szolgáltatást és akkor csak VM-eket bérelsz az 2jegyű Óceánból, vagy a *Rack*-től, ...
<szerk>és újra feltalálod a spanyolviaszt, amit a Google, meg Amazon már megcsinált és kb. a szolgáltatás része</szerk>

Egyébként, meg ha init rendszerben kell a személyes kedvencet említeni: Ennyire mélyen az AIX-ot nem ismerem, úgyhogy a saját személyes kedvencem az SMF. CDDL. Mélyen nem kell gyökerezzen a kernellel, vagy mással legjobb tudásom szerint. Szóval, még a licenc nácik se találnának rajta kifogást, mint a ZFS esetén. Szóval, a legtöbb kifogást, amit az SMF-el kapcsolatban hallottam: xml-ben kell neki a manifest fájlokat megírni.
De alternatívát eddig még nem hallottam, hogy mit javasolna bárki, az xml kiváltására. Lehet jönni json, meg yaml és hasonló agymenésekkel. De ez egy kötött fogású birkózás! Az xml-t lehet validálni, van rá szabványos megoldás. A többinél a validáció kb. kimerül annyiban, hogy be tudod-e tölteni parserrel.