Il faut quand même dire que beaucoup de choses sont possibles sans systemd, cependant, ce dernier les facilitent. Le point principale, je pense, est de pouvoir modifier le démarrage d'un service sans qu'il se fasse écraser (ou que la question soit posée) à la prochaine mise à jour de la distribution. Par exemple, avec sysv, si tu modifie /etc/init.d/myservice, Debian va te proposer de l'écraser par la version du mainteneur s'il a été modifié par celui-ci. Avec systemd, les fichiers de la distribution vont dans /usr/lib/systemd/ et les fichiers de l'administrateur dans /etc/systemd. C'est beaucoup plus propre.
Un autre point (mais qui concerne plus un usage serveur), c'est le démarrage dans un cgroup, ça veut dire que quand tu fais un stop, tu peux être sûr que tous les processus liés à ton service sont bien tué. Ça évite les comportements bizarres quand tu fais un restart. Ça veut aussi dire que tu peux limiter la consommation de ressource de chaque service.
Un détail pratique, c'est systemd-anaylse qui peut analyser le temps de démarrage de chaque service, si tu as un démarrage très lent, tu peux voir la chaîne de dépendance qui te ralentit. Et même, sans avoir un démarrage lent, en l'utilisant j'ai vu que certains services non-critiques prenaient beaucoup de temps à démarrer à cause d'un problème de configuration.
Il y a une intégration de SELinux/Apparmor mais je ne connais pas ces technologies, je ne peux donc pas dire si c'est utile.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi un fork?
Posté par claudex . En réponse au journal Devuan forks Debian: un choc ou c'était inévitable?. Évalué à 7.
Il faut quand même dire que beaucoup de choses sont possibles sans systemd, cependant, ce dernier les facilitent. Le point principale, je pense, est de pouvoir modifier le démarrage d'un service sans qu'il se fasse écraser (ou que la question soit posée) à la prochaine mise à jour de la distribution. Par exemple, avec sysv, si tu modifie /etc/init.d/myservice, Debian va te proposer de l'écraser par la version du mainteneur s'il a été modifié par celui-ci. Avec systemd, les fichiers de la distribution vont dans /usr/lib/systemd/ et les fichiers de l'administrateur dans /etc/systemd. C'est beaucoup plus propre.
Un autre point (mais qui concerne plus un usage serveur), c'est le démarrage dans un cgroup, ça veut dire que quand tu fais un stop, tu peux être sûr que tous les processus liés à ton service sont bien tué. Ça évite les comportements bizarres quand tu fais un restart. Ça veut aussi dire que tu peux limiter la consommation de ressource de chaque service.
Un détail pratique, c'est systemd-anaylse qui peut analyser le temps de démarrage de chaque service, si tu as un démarrage très lent, tu peux voir la chaîne de dépendance qui te ralentit. Et même, sans avoir un démarrage lent, en l'utilisant j'ai vu que certains services non-critiques prenaient beaucoup de temps à démarrer à cause d'un problème de configuration.
Il y a une intégration de SELinux/Apparmor mais je ne connais pas ces technologies, je ne peux donc pas dire si c'est utile.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche