Ouep. Ça ressemble à bcp de projets, de logiciels, que ceux-ci soient ou non ouvert.
Au début, ça part d'un bon sentiment. Il y a un problème et le logiciel propose une solution possible à ce problème. En l'occurrence ici une unification homogène et cohérente du mécanisme d'initialisation et de gestion des services systèmes et applicatifs. Lorsque l'on a un parc de serveurs à gérer, ce n'est pas du tout déconnant. Les choix qui ont été fait l'ont été en sacrifiant certains pans qui ont fait le succès d'Unix (chaque programme ne fait qu'une chose à la fois, configuration et log en texte et accessible avec n'importe quel éditeur de texte, etc.) pour des raisons qui s'entendaient, discutables, oui, mais rationnels.
Puis, petit à petit le logiciel prend de l'embonpoint en voulant résoudre des vrais faux problèmes. On ne part plus d'un problème à résoudre mais d'une solution à la recherche d'un problème à résoudre. Quand on a un marteau, tout devient d'un coup des clous.
Ceci peut survenir, par exemple, lorsque chaque dév ou groupe de dév cherche à faire évoluer un logiciel pour répondre à un de leur besoin très spécifique (et parfois un besoin pas toujours bien appréhendé) et voilà que le logiciel part dans plusieurs directions et perd de vue, avec le temps, ses fonctions principales. Ceci survient aussi (et c'est le cas le plus fréquent) par un besoin frénétique d'en faire toujours plus, d'aller toujours plus loin, au delà du scope du logiciel, quitte à le dénaturer.
[^] # Re: osctl
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Systemd v256. Évalué à 10. Dernière modification le 19 juin 2024 à 08:54.
Ouep. Ça ressemble à bcp de projets, de logiciels, que ceux-ci soient ou non ouvert.
Au début, ça part d'un bon sentiment. Il y a un problème et le logiciel propose une solution possible à ce problème. En l'occurrence ici une unification homogène et cohérente du mécanisme d'initialisation et de gestion des services systèmes et applicatifs. Lorsque l'on a un parc de serveurs à gérer, ce n'est pas du tout déconnant. Les choix qui ont été fait l'ont été en sacrifiant certains pans qui ont fait le succès d'Unix (chaque programme ne fait qu'une chose à la fois, configuration et log en texte et accessible avec n'importe quel éditeur de texte, etc.) pour des raisons qui s'entendaient, discutables, oui, mais rationnels.
Puis, petit à petit le logiciel prend de l'embonpoint en voulant résoudre des vrais faux problèmes. On ne part plus d'un problème à résoudre mais d'une solution à la recherche d'un problème à résoudre. Quand on a un marteau, tout devient d'un coup des clous.
Ceci peut survenir, par exemple, lorsque chaque dév ou groupe de dév cherche à faire évoluer un logiciel pour répondre à un de leur besoin très spécifique (et parfois un besoin pas toujours bien appréhendé) et voilà que le logiciel part dans plusieurs directions et perd de vue, avec le temps, ses fonctions principales. Ceci survient aussi (et c'est le cas le plus fréquent) par un besoin frénétique d'en faire toujours plus, d'aller toujours plus loin, au delà du scope du logiciel, quitte à le dénaturer.