il faudrait dire quelle probleme le nouveau système d'init
resout et en quoi cette solution est une amelioration
Ok, alors systemd résoud plusieurs soucis.
Tout d'abord, ça permet d'arreter un démon de manière sur. Sur dans le sens ou on est sur qu'il le fait. Plus de trucs qui trainent aprés un crash d'un process lancé par apache qui lance un cgi qui lance un truc à la con qui plante en faisant un pipe.
Plus de race condition comme dans le script bind de Debian.
Ensuite, ça permet de résoudre le souci des interfaces haut niveau de pas avoir d'API à utiliser. Par exemple, un projet comme cockpit (http://cockpit-project.org/) utilise les API, au lieu de lancer le script d'init avec un code de retour non assuré. Ou ça permet de changer de maniére fiable le nom de domaine de la machine (hostnamectl), l'arrangement du clavier et de la console (localectl), l'heure et l'usage ou pas de ntp. Gnome devait avoir un code relativement compliqué pour s'adapter à la façon de faire de chaque distro pour un taf globalement la même partout, à savoir lancer ntpd.
Enfin, il permet de lancer les services dans un environnement propre. Cad sans groupe supplémentaire (genre, si le programmeur se plante et change d'abord l'uid avant le gid, si il change le gid sans mettre à zero la liste des groupes supplémentaires), sans variable d’environnement parasites (genre, si quelqu'un avec un shell en allemand relance apache, alors les pages en php vont utiliser les locales allemandes pour le tri alphabétique).
( et ça, c'est juste dans mon historique firefox )
Et pour finir, ça réduit aussi la maintenance des distros car tu peux mettre en commun les unités de services, c'est plus facile pour les mainteneurs débutants, donc ça réduit la courbe d'apprentissage pour eux.
[^] # Re: meme sa façon d'argumenter est nulle
Posté par Misc (site web personnel) . En réponse au journal Dépèche de ouf en préparation !!!!. Évalué à 10.
Ok, alors systemd résoud plusieurs soucis.
Tout d'abord, ça permet d'arreter un démon de manière sur. Sur dans le sens ou on est sur qu'il le fait. Plus de trucs qui trainent aprés un crash d'un process lancé par apache qui lance un cgi qui lance un truc à la con qui plante en faisant un pipe.
Plus de race condition comme dans le script bind de Debian.
Ensuite, ça permet de résoudre le souci des interfaces haut niveau de pas avoir d'API à utiliser. Par exemple, un projet comme cockpit (http://cockpit-project.org/) utilise les API, au lieu de lancer le script d'init avec un code de retour non assuré. Ou ça permet de changer de maniére fiable le nom de domaine de la machine (hostnamectl), l'arrangement du clavier et de la console (localectl), l'heure et l'usage ou pas de ntp. Gnome devait avoir un code relativement compliqué pour s'adapter à la façon de faire de chaque distro pour un taf globalement la même partout, à savoir lancer ntpd.
Enfin, il permet de lancer les services dans un environnement propre. Cad sans groupe supplémentaire (genre, si le programmeur se plante et change d'abord l'uid avant le gid, si il change le gid sans mettre à zero la liste des groupes supplémentaires), sans variable d’environnement parasites (genre, si quelqu'un avec un shell en allemand relance apache, alors les pages en php vont utiliser les locales allemandes pour le tri alphabétique).
Normalement, tu es censé utilisé service pour régler le 2nd souci, mais d'expérience, tout le monde ne le fait pas. Et pour le premier, ma fois, j'ai du trouvé 3 bugs comme ça, genre https://bugzilla.redhat.com/show_bug.cgi?id=1000722 , https://bugzilla.redhat.com/show_bug.cgi?id=894626
Et ça arrive aussi à d'autres programmes :
https://bugzilla.redhat.com/show_bug.cgi?id=130112
https://bugzilla.redhat.com/show_bug.cgi?id=828436
( et ça, c'est juste dans mon historique firefox )
Et pour finir, ça réduit aussi la maintenance des distros car tu peux mettre en commun les unités de services, c'est plus facile pour les mainteneurs débutants, donc ça réduit la courbe d'apprentissage pour eux.
J'ose croire que ça réponds à la question.