Une erreur de quoi ? Il ne s'agit pas d'une erreur, je sais très bien que systemd est plus qu'un système d'init et c'est bien ça que je lui reproche.
Ta comparaison repose sur l'aspect init, ce n'est pas correcte de focaliser son attention dessus alors qu'il propose plus.
Comportements qui posent problème lorsque tu n'es pas dans les cvlous. Systemd oblige ton besoin à s'adapter à l'outil, plutôt que de s'effacer et de laisser l'admin faire ce qu'il a a faire.
Sur la plupart des OS qui implémentent le même type d'approche, la plupart du temps, tu as tout ce qu'il faut pour configurer un service proprement. Et dès que tu as un besoin qui sort de ce qui t'es proposé" tu peux implémenter le comportement que tu veux. Rien n'oblige de le faire en shell, tu peux le faire avec du python, du ruby, lua, ou n'importe quoi d'autre.
Oui, c'est vrai qu'il y a 25000 façons de redémarrer un service qui a échoué, de configurer les droits SELinux et compagnie... Avec init tu dois toujours te le farcir toi même. Pourtant c'est un besoin de base.
Et comme systemd permet d'appeler un shell ou ce que tu veux, par effet de bord tu peux faire ce que tu veux si le comportement de systemd ne te plaît pas. Il y a d'ailleurs de quoi exécuter des scripts init classiques avec systemd. Donc en gros : tu peux faire comme avant si tu y tiens.
J'aime pas les trucs qui me cachent des choses.
Rien n'est caché, le code de systemd est dispo si tu y tiens.
Personnellement en lisant une unité systemd j'ai en quelques secondes les propriétés essentielles du service. Et je peux en déduire son comportement quelque soit le service.
Si c'est un script init à l'ancienne, pour peu qu'il ne soit pas trivial il te faudra bien plus de temps pour en retirer les mêmes informations. Et comme aucun script init n'est rédigé de la même façon contrairement à une unité systemd, prédire le comportement demande de réévaluer le script systématiquement.
Oui enfin, quand un service fait les choses différemment des autres c'est bien souvent parce qu'il a besoin de faire les choses différemment.
Non, c'est juste que pas tout le monde pense à couvrir tous les besoins. Normal, ce n'est pas simple à anticiper. Même quand tu es le développeur de l'application ou le mainteneur dans une distribution.
Pas tout le monde pense à gérer le cas d'un service qui plante et qui doit redémarrer automatiquement, pas tout le monde pense à ajouter des règles SELinux, pas tout le monde pense à bien gérer les dépendances du service comme s'assurer que le réseau soit opérationnel avant, etc.
Si le mainteneur n'a pas fait son boulot correctement (indice, ça arrivait souvent) tu devais te démerder et c'était chiant. Ici cela se règle très simplement.
Je travaille en embarqué par exemple, contrôler ce qui se passe j'aime bien aussi. Mais sur chaque projet où c'était de l'init classique, je devais régler les mêmes problèmes à la con, réinventer la roue 20 fois, etc. systemd gère tous ces problèmes d'entrée de jeu, écrire une unité systemd qui fait ce que tu veux est très simple. Je n'ai littéralement jamais eu de soucis avec, c'est un confort incroyable.
Donc oui, avec l'init tu as plus de contrôle direct, oui, car toute la difficulté repose sur le dos de l'administrateur. Ce n'est selon moi pas la bonne approche. Si l'admin veut reprendre le contrôle avec systemd, il le peut de toute façon en cas de besoin.
[^] # Re: Merci pour la dédicace ... :)
Posté par Renault (site web personnel) . En réponse au journal Petites brèves en vrac. Évalué à 4.
Ta comparaison repose sur l'aspect init, ce n'est pas correcte de focaliser son attention dessus alors qu'il propose plus.
Oui, c'est vrai qu'il y a 25000 façons de redémarrer un service qui a échoué, de configurer les droits SELinux et compagnie... Avec init tu dois toujours te le farcir toi même. Pourtant c'est un besoin de base.
Et comme systemd permet d'appeler un shell ou ce que tu veux, par effet de bord tu peux faire ce que tu veux si le comportement de systemd ne te plaît pas. Il y a d'ailleurs de quoi exécuter des scripts init classiques avec systemd. Donc en gros : tu peux faire comme avant si tu y tiens.
Rien n'est caché, le code de systemd est dispo si tu y tiens.
Personnellement en lisant une unité systemd j'ai en quelques secondes les propriétés essentielles du service. Et je peux en déduire son comportement quelque soit le service.
Si c'est un script init à l'ancienne, pour peu qu'il ne soit pas trivial il te faudra bien plus de temps pour en retirer les mêmes informations. Et comme aucun script init n'est rédigé de la même façon contrairement à une unité systemd, prédire le comportement demande de réévaluer le script systématiquement.
Non, c'est juste que pas tout le monde pense à couvrir tous les besoins. Normal, ce n'est pas simple à anticiper. Même quand tu es le développeur de l'application ou le mainteneur dans une distribution.
Pas tout le monde pense à gérer le cas d'un service qui plante et qui doit redémarrer automatiquement, pas tout le monde pense à ajouter des règles SELinux, pas tout le monde pense à bien gérer les dépendances du service comme s'assurer que le réseau soit opérationnel avant, etc.
Si le mainteneur n'a pas fait son boulot correctement (indice, ça arrivait souvent) tu devais te démerder et c'était chiant. Ici cela se règle très simplement.
Je travaille en embarqué par exemple, contrôler ce qui se passe j'aime bien aussi. Mais sur chaque projet où c'était de l'init classique, je devais régler les mêmes problèmes à la con, réinventer la roue 20 fois, etc. systemd gère tous ces problèmes d'entrée de jeu, écrire une unité systemd qui fait ce que tu veux est très simple. Je n'ai littéralement jamais eu de soucis avec, c'est un confort incroyable.
Donc oui, avec l'init tu as plus de contrôle direct, oui, car toute la difficulté repose sur le dos de l'administrateur. Ce n'est selon moi pas la bonne approche. Si l'admin veut reprendre le contrôle avec systemd, il le peut de toute façon en cas de besoin.