Je crois que la clé est dans le courriel de Lennart Poettering. Il ne cache pas que le but à terme est d'avoir une pile noyau/systemd/GNU comme socle du système Linux, ce qui va fatalement nécessiter, au fur et à mesure que les composants de base seront intégrés à systemd (syslog, la console, etc.), de coder/maintenir des alternatives, aboutissant lentement mais sûrement à élaborer deux piles de base distinctes (noyau/systemd/GNU et noyau/un tas d'outils indépendants/GNU).
Finalement, ce ne sera pas très différent de ce qui se fait sous BSD, où chaque projet, même s'il n'a pas beaucoup de ressources, maintient sa propre pile de base en reprenant/intégrant les fonctionnalités qui l'intéresse chez les autres. Je pense que, comme le suggère l'auteur original, le vrai problème des détracteurs de systemd est qu'actuellement ils savent qu'ils ne veulent pas de systemd sans savoir où ils veulent vraiment aller, (contrairement à ceux qui font systemd, qui ont de toute évidence les idées claires).
Il y a aussi le problème de la perméabilité des couches. Si on est quasi-sûr que Linus ne laissera jamais l'intégration noyau/systemd se faire, il se pourrait que dans les couches hautes les gros environnements de bureau cèdent à la tentation, auquel cas ce sera très compliqué pour la pile alternative (faire du bricolage pour avoir une pile qui fonctionne sans systemd quand une partie est prévue pour, ça risque de susciter beaucoup de frustration chez ceux qui tiennent à la propreté des implémentations).
[^] # Re: Trop facile résumé...
Posté par Ignatz Ledebur . En réponse au journal Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 8.
Je crois que la clé est dans le courriel de Lennart Poettering. Il ne cache pas que le but à terme est d'avoir une pile noyau/systemd/GNU comme socle du système Linux, ce qui va fatalement nécessiter, au fur et à mesure que les composants de base seront intégrés à systemd (syslog, la console, etc.), de coder/maintenir des alternatives, aboutissant lentement mais sûrement à élaborer deux piles de base distinctes (noyau/systemd/GNU et noyau/un tas d'outils indépendants/GNU).
Finalement, ce ne sera pas très différent de ce qui se fait sous BSD, où chaque projet, même s'il n'a pas beaucoup de ressources, maintient sa propre pile de base en reprenant/intégrant les fonctionnalités qui l'intéresse chez les autres. Je pense que, comme le suggère l'auteur original, le vrai problème des détracteurs de systemd est qu'actuellement ils savent qu'ils ne veulent pas de systemd sans savoir où ils veulent vraiment aller, (contrairement à ceux qui font systemd, qui ont de toute évidence les idées claires).
Il y a aussi le problème de la perméabilité des couches. Si on est quasi-sûr que Linus ne laissera jamais l'intégration noyau/systemd se faire, il se pourrait que dans les couches hautes les gros environnements de bureau cèdent à la tentation, auquel cas ce sera très compliqué pour la pile alternative (faire du bricolage pour avoir une pile qui fonctionne sans systemd quand une partie est prévue pour, ça risque de susciter beaucoup de frustration chez ceux qui tiennent à la propreté des implémentations).