En fait, c'est simple, les distributions l'utilisent car elles pensent que c'est sur le long terme plus facile à maintenir. Il y a moins de code à faire pour lancer un demon, ça permet des choses choupis, c'est moderne. Les raisons que j'estime pleinement valable de pas y passer sont soit d'ordre du minimalisme ( exemple, lfs et co ), soit de l'ordre de la diversité, soit de l'ordre de la portabilité ( exemple debian ).
La plupart des distribs ne sont pas dans ce cas la. La diversité, c'est un cout à la QA, à la compilation et à la gestion et tente d'être diminué avec plus ou moins de bonheur. Autant offir X WM, ça va, autant offrir par exemple X serveurs webs et espérer une intégration fine, c'est plus dur ( d'ailleurs, c'est pour ça que la plupart le font pas, et propose juste une intégration avec apache, et pas X fichiers de conf pour nginx, lighttpd, pour php en fastcgi, en demon avec fpm, etc ). Et dans le cas d'un truc comme un système d'init qui touche tout le monde c'est simplement trop complexe.
La portabilité, ça a un cout aussi, et la plupart des distribs ne sont pas prêtes à le payer. EN fait, il y a que Debian ( et Arch ) qui tente de tourner sur autre chose qu'un noyau Linux. Pour les autres, avant, les initscripts n'étaient pas compatible avec les BSDs, et était fait par la distro, maintenant, ça ne va pas changer. Donc globalement, ça, à part pour Debian, ça change rien.
Enfin je pense que la plupart des distributions ne souffrent pas des soucis de lfs, vu que la plupart ont besoin déjà de tout un tas de trucs. Donc c'est déja un souci qui est maitrisé, et qui n'affecte pas trop l'utilisateur ( ie, les deps de systemd sont déjà toutes dans les distros, donc le surcout est mineur du point de vue packaging ).
Et moi, en tant que packageur de longue date, je pense que le format de fichier de systemd est beaucoup plus facile à écrire, à comprendre et à vérifier qu'un script shell à base de boilerplate et de copier coller, et qu'il fait juste des tas de trucs en plus. Systemd gére aussi de façon élégante des cas à la con comme "lancer plusieurs fois un service", "gérer des services à la con comme bind qui utilise un canal de com à part pour se couper" ou d'autres exemples que je sort à chaque fois ( bla bla sympa bla bla 5 services bla bla bloquant bla bla postgresql pas lancé bla bla ).
Et je suis aussi sensible à l'idée "on pousse le fichier upstream", car ç'est la façon la plus simple de collaborer, ce qui est la base du logiciel libre. Ça a relativement bien marché pour les menus en .desktop ( pour ceux qui sont assez vieux pour se souvenir du merdier infame que c'était avant ), je vois pas pourquoi ça ne marcherais pas pour les services. Et autant j'ai rarement confiance dans un script d'init qui vient d'upstream ( qui va toujours faire 3 fois trop de trucs, et qui va tourner correctement sur 1 distro ), autant, un fichier de config, je pense que ça peut passer.
Donc tout ce qui peut réduire la charge de travail d'un packageur est la bienvenue.
Et ça, c'est mon avis en tant que mec du coté distro.
# Parce que les distributions et les users, c'est 2 choses différentes
Posté par Misc (site web personnel) . En réponse au journal yet another journal about systemd. Évalué à 10.
En fait, c'est simple, les distributions l'utilisent car elles pensent que c'est sur le long terme plus facile à maintenir. Il y a moins de code à faire pour lancer un demon, ça permet des choses choupis, c'est moderne. Les raisons que j'estime pleinement valable de pas y passer sont soit d'ordre du minimalisme ( exemple, lfs et co ), soit de l'ordre de la diversité, soit de l'ordre de la portabilité ( exemple debian ).
La plupart des distribs ne sont pas dans ce cas la. La diversité, c'est un cout à la QA, à la compilation et à la gestion et tente d'être diminué avec plus ou moins de bonheur. Autant offir X WM, ça va, autant offrir par exemple X serveurs webs et espérer une intégration fine, c'est plus dur ( d'ailleurs, c'est pour ça que la plupart le font pas, et propose juste une intégration avec apache, et pas X fichiers de conf pour nginx, lighttpd, pour php en fastcgi, en demon avec fpm, etc ). Et dans le cas d'un truc comme un système d'init qui touche tout le monde c'est simplement trop complexe.
La portabilité, ça a un cout aussi, et la plupart des distribs ne sont pas prêtes à le payer. EN fait, il y a que Debian ( et Arch ) qui tente de tourner sur autre chose qu'un noyau Linux. Pour les autres, avant, les initscripts n'étaient pas compatible avec les BSDs, et était fait par la distro, maintenant, ça ne va pas changer. Donc globalement, ça, à part pour Debian, ça change rien.
Enfin je pense que la plupart des distributions ne souffrent pas des soucis de lfs, vu que la plupart ont besoin déjà de tout un tas de trucs. Donc c'est déja un souci qui est maitrisé, et qui n'affecte pas trop l'utilisateur ( ie, les deps de systemd sont déjà toutes dans les distros, donc le surcout est mineur du point de vue packaging ).
Et moi, en tant que packageur de longue date, je pense que le format de fichier de systemd est beaucoup plus facile à écrire, à comprendre et à vérifier qu'un script shell à base de boilerplate et de copier coller, et qu'il fait juste des tas de trucs en plus. Systemd gére aussi de façon élégante des cas à la con comme "lancer plusieurs fois un service", "gérer des services à la con comme bind qui utilise un canal de com à part pour se couper" ou d'autres exemples que je sort à chaque fois ( bla bla sympa bla bla 5 services bla bla bloquant bla bla postgresql pas lancé bla bla ).
Et je suis aussi sensible à l'idée "on pousse le fichier upstream", car ç'est la façon la plus simple de collaborer, ce qui est la base du logiciel libre. Ça a relativement bien marché pour les menus en .desktop ( pour ceux qui sont assez vieux pour se souvenir du merdier infame que c'était avant ), je vois pas pourquoi ça ne marcherais pas pour les services. Et autant j'ai rarement confiance dans un script d'init qui vient d'upstream ( qui va toujours faire 3 fois trop de trucs, et qui va tourner correctement sur 1 distro ), autant, un fichier de config, je pense que ça peut passer.
Donc tout ce qui peut réduire la charge de travail d'un packageur est la bienvenue.
Et ça, c'est mon avis en tant que mec du coté distro.