Door Anoniem: Door Anoniem:
Dat is geheel shell en een stuk robuuster en eleganter dan de ondertussen toch wel vrij achterhaalde softlink farm van sysv-init. Dat "linux" daar niet eerder wat aan gedaan heeft is de opening geweest waar systemd mee naarbinnen werd gewurmt, maar die "discussie" is heel zorvuldig geframed geworden als "sysv is achterhaald dus MOETEN we wel systemd invoeren"...
Er is niks mis met sysv-init zelf, het enige wat soms wel eens gewenst zou zijn is een monitoring- en recovery systeem
voor de opgestarte daemons. Als sysv-init een service start is deze daarna geheel aan zichzelf overgeleverd, als deze
crashed dan wordt daar verder niets mee gedaan. Het zou wel handig zijn als er een optie was voor een recovery, of
op zijn minst een gestandaardiseerde melding (weet ik veel, bijv je /etc/init.d/service script wordt gestart met de parameter
"exited" ofzo als de door dat script gestarte daemon exit of crashed. dan kan het script daar wat mee doen indien nodig)
Het licht is _bijna_ doorgebroken....
je noemt daar een beperkt aspect van wat er mis is met sysv-init . Maar je praat alleen over crashende daemons die op een verder statisch systeem misschien vanzelf herstart moeten worden.
In de tijd dat je CPU, memory, storage en interfaces constant waren gedurende de volledige uptime van je systeem kon je daar prima mee leven.
Wat er tegenwoordig anders is, is dat hotplugging, suspend/wake en dynamisch veranderende configuraties _normaal_ zijn.
(dankzij mn VMs, en cloud omgevingen - vooral voor servers.)
In de tijd dat je met een maintenace window en een schroevedraaier disken of NICs toevoegde was het ook wel te overzien dat een beheerder dan even zat te klooien met vi in ./etc/ files om _DE_ configuratie aan te passen.
En hopelijk niks vergat - (hallo daemon -i eth0,eth1,eth2 ) .
_Dat_ is waarom de klassieke decentrale startup systemen achterhaald zijn - ze kunnen niet omgaan met de dependencies die je hebt bij dynamische 'hardware' wijzigingen als hotplug devices en het herstarten van 'alle' services die ervan afhangen.
"De" configuratie bestaat niet meer - met een klik (of een API call) hangen er disken of nics, of CPUs bij. En het is eigenlijk helemaal niet normaal dat er dan een man-met-baard-en-bril moet gaan zitten inloggen , editen, en nog een keer rebooten voordat je die dingen kunt gebruiken.
Dan snap je ook waarom systemd van Redhat afkomstig is - met hun gebruik in Cloud en VM omgevingen hebben ze ervaren dat deze noodzaak er was . En de andere distro's die ook maar enigszins gebruikt worden in dergelijke omgevingen zijn direct meegegaan.
De tijd van Pöttering en de andere developers die ze betaald hebben, en de adoptie ervan in de distro waar heel Redhat van bestaat is echt niet voor z'n mooie ogen, maar omdat ze een oplossing willen waar de Redhat _klanten_ behoefte aan hebben.
[..]
En dat is vervelend, want de daemons die je wilt starten en/of de addons die gemaakt zijn voor de daemons die zijn
daar vaak nog niet op aangepast. Dus je zit ineens met een situatie van iets wat altijd prima werkte onder sysv-init,
en wat met systemd helemaal niet meer lukt of niet zo simpel of elegant meer is.
Ook oude honden moeten soms nieuwe kunstjes leren ...
Ik heb SunOS beheerders horen klagen over alles wat er zo erg mis was met Solaris .
En ja, je vaste patronen aanpassen _kost_ tijd en moeite en energie .
Prijs je maar gelukkig dat in Unix land dit soort veranderingen minder frequent zijn dan de WIndows beheerders die van NT4 naar W2K naar Vista naar W7/W10 gesleurd zijn.
En dat die systemd club daar alleen maar op reageert met "dat is allemaal deprecated" dat helpt niet om ze populair
te maken. Mensen die Linux gebruiken op systemen die willen dat hun oplossingen (blijven) werken, niet dat ze worden
gespannen voor karretjes van mensen als Poettering die Linux willen verWindowsiveren.
Als je in de niche van Unix beheerder met een paar dozijn vaste fysieke servers die je per stuk met het handje beheert blijft plakken heb je en leuke hobby, maar een doodlopende carriére.