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.
J'utilise systemd dans un système embarqué fonctionnant sous Linux. On a pas mal de services à lancer, certes. Mais on doit aussi les relancer quand ils crashent. Attendre que les partitions disques soient montées avant de lancer les services. Attendre que les interfaces réseau soient disponibles (ce qui suppose d'avoir attendu que es disques soient montés pour charger la configuration du réseau). Et ainsi de suite.
On est donc très contents que systemd sache faire tout ça et déclencher les choses dans le bon ordre. Et, d'un autre coté, quand il ne sait pas faire ce qu'on veut, on est bien embetés et dans certains cas il n'y a probablement pas d'autre solution que d'intégrer quelque chose au projet systemd.
Quand au supposé sacrifice du "chaque programme ne fait qu'une chose à la fois", ce n'est pas vrai: systemd comporte de nombreux programmes qui font chacun une seule chose, mais qui communiquent beaucoup entre eux. Ce n'est pas un seul méga-exécutable qui fait tout. Il se trouve que maintenant, ces exécutables sont développés par une équipe réduite et avec une certaine cohérence et versionnés et livrés ensemble. Un peu... comme à l'époque de UNIX, en fait. Avant que Linux et GNU viennent compliquer tout ça avec un modèle de développement beaucoup plus décentralisé et moins coordonné, poussant à l'apparition de distributions essayant de recoller tous ces morceaux ensemble.
[^] # Re: osctl
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Systemd v256. Évalué à 10.
J'utilise systemd dans un système embarqué fonctionnant sous Linux. On a pas mal de services à lancer, certes. Mais on doit aussi les relancer quand ils crashent. Attendre que les partitions disques soient montées avant de lancer les services. Attendre que les interfaces réseau soient disponibles (ce qui suppose d'avoir attendu que es disques soient montés pour charger la configuration du réseau). Et ainsi de suite.
On est donc très contents que systemd sache faire tout ça et déclencher les choses dans le bon ordre. Et, d'un autre coté, quand il ne sait pas faire ce qu'on veut, on est bien embetés et dans certains cas il n'y a probablement pas d'autre solution que d'intégrer quelque chose au projet systemd.
Quand au supposé sacrifice du "chaque programme ne fait qu'une chose à la fois", ce n'est pas vrai: systemd comporte de nombreux programmes qui font chacun une seule chose, mais qui communiquent beaucoup entre eux. Ce n'est pas un seul méga-exécutable qui fait tout. Il se trouve que maintenant, ces exécutables sont développés par une équipe réduite et avec une certaine cohérence et versionnés et livrés ensemble. Un peu... comme à l'époque de UNIX, en fait. Avant que Linux et GNU viennent compliquer tout ça avec un modèle de développement beaucoup plus décentralisé et moins coordonné, poussant à l'apparition de distributions essayant de recoller tous ces morceaux ensemble.