On peut aussi appeler ça, réduire la complexité, refactorer, ce qui réduit le nombre de bugs potentiels, et accroit la facilité de maintenance.
Bien sur, c'est intenable sur le long terme sauf à ce que rien d'autre ne bouge à coté.
Ou peut-être que ce qui est intenable sur le long terme, c'est un outil qui n'est pas stable dans ses fonctionnalités, qui ajoute en permanence de nouvelles choses (qui sait s'il ne finira pas par en supprimer?). Un tel outil, c'est bien pour jouer, mais en tant que dev, je ne me baserais jamais sur un outil plus glissant qu'une anguille, et les raisons sont simples:
comment je fais dans 10 ans, si tout à changé radicalement?
comment feront mes successeurs, ils vont devoir mettre le nez dans un code basé sur un outil devenu une véritable usine à gaz?
si un jour le projet meurs, comment faire pour le porter, s'il est inextricablement lié à mon propre code?
10 ans, ce n'est pas si énorme que ça, du code peut très bien tourner avec 10 ans d'âge sans souci, et on peut très bien avoir besoin de déployer le même programme sur une machine plus récente. Sauf qu'en 10 ans, bien des choses peuvent se passer en informatique...
Et d'ailleurs, un code qui augmente de taille en permanence, dont personne ne connaît la finalité réelle, c'est ça, qui est vraiment intenable. Ça finit en usine à gaz, et, en admettant que systemd ait la même solidité et le même futur que Xorg, regardes donc les arguments pour la création de wayland: repartir sur une base de code propre qui ne fasse pas peur à tout le monde, qui ne fasse pas fuir les éventuels contributeurs.
Systemd ne me semble pas du tout dans cette optique: au début, le but, c'était juste de se passer de scripts shell pour gérer les daemons, maintenant j'ai pas l'impression que ce soit toujours le même: il s'insère dans les systèmes de journalisation (ce qui aurait très bien pu être fait, mais par un projet autre, complètement séparé, pourquoi pas), de login, et j'en oublie.
Avoir un projet qui sait limiter sa sphère d'influence, c'est avoir plus de chances d'avoir un truc fiable à la fin. Et quand ça bug, c'est plus simple de cerner l'origine du bug, et de le corriger sans en rajouter ailleurs. Ça ne semble pas être le cas de systemd, et uselessd semble vouloir corriger ce problème.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par freem . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 7.
On peut aussi appeler ça, réduire la complexité, refactorer, ce qui réduit le nombre de bugs potentiels, et accroit la facilité de maintenance.
Ou peut-être que ce qui est intenable sur le long terme, c'est un outil qui n'est pas stable dans ses fonctionnalités, qui ajoute en permanence de nouvelles choses (qui sait s'il ne finira pas par en supprimer?). Un tel outil, c'est bien pour jouer, mais en tant que dev, je ne me baserais jamais sur un outil plus glissant qu'une anguille, et les raisons sont simples:
10 ans, ce n'est pas si énorme que ça, du code peut très bien tourner avec 10 ans d'âge sans souci, et on peut très bien avoir besoin de déployer le même programme sur une machine plus récente. Sauf qu'en 10 ans, bien des choses peuvent se passer en informatique...
Et d'ailleurs, un code qui augmente de taille en permanence, dont personne ne connaît la finalité réelle, c'est ça, qui est vraiment intenable. Ça finit en usine à gaz, et, en admettant que systemd ait la même solidité et le même futur que Xorg, regardes donc les arguments pour la création de wayland: repartir sur une base de code propre qui ne fasse pas peur à tout le monde, qui ne fasse pas fuir les éventuels contributeurs.
Systemd ne me semble pas du tout dans cette optique: au début, le but, c'était juste de se passer de scripts shell pour gérer les daemons, maintenant j'ai pas l'impression que ce soit toujours le même: il s'insère dans les systèmes de journalisation (ce qui aurait très bien pu être fait, mais par un projet autre, complètement séparé, pourquoi pas), de login, et j'en oublie.
Avoir un projet qui sait limiter sa sphère d'influence, c'est avoir plus de chances d'avoir un truc fiable à la fin. Et quand ça bug, c'est plus simple de cerner l'origine du bug, et de le corriger sans en rajouter ailleurs. Ça ne semble pas être le cas de systemd, et uselessd semble vouloir corriger ce problème.