Personnellement je ne te visais pas trop dans mon propos, je répondais plus à Tanguy qui faisait dans la critique gratuite de systemd alors que le problème est plus profond que ça et ne devrait pas s'attarder uniquement sur systemd. Enfin selon la vision des choses, car je pense qu'il y a deux approches que je vais expliciter plus bas.
Note que je ne suis pas particulièrement en désaccord avec toi, je comprends en tout cas ton point de vue.
Mais c'est pas une bonne chose de changer aussi régulièrement les API linux, c'est peut être l'un des gros problèmes de linux sur desktop. C'est les API du bureau linux. Le problème n'est pas fonctionnel. Avoir une vitesse de boot ou une gestion des sessions utilisateurs dans l'absolu c'est joli, mais ça apporte plus de bug d'intégration que de fonctionnalité pour l'utilisateur final.
Je pense que c'est en soit quelque chose à double tranchant en effet :
La compatibilité ascendante et une API stable aident à concevoir un système stable où les composants sont bien intégrés, etc.
Cependant, si cela n'est jamais remis en cause (et certains le montrent clairement au sujet de SysV qui n'a pas beaucoup bougé en 30 ans), ça ne bouge plus du tout ou pas assez vite malgré l'évolution du contexte, des moyens et des technologies disponibles.
C'est un peu comme vouloir la stabilité et l'intégration d'une Debian et les nouveautés de Fedora (par exemple) en même temps, ce sont deux visions à mon sens correctes mais qui s'opposent et qui sont difficiles à concilier. Comme on dit, on ne peut pas tout avoir.
Beaucoup ici aiment les systèmes libres car tout peut être remis en question, que ça évolue suffisamment vite pour être en phase avec l'évolution technique. Ce sont des qualités souvent mis en opposition avec Windows par exemple mais qui nécessite de changer d'API quand on se rend compte que celles existantes ne parviennent pas à convenir à la situation d'aujourd'hui.
Et il sera impossible d'avoir une API stable tant qu'il n'y aura pas de gouvernance suprême. Si le noyau est géré par une poignée de gens qui travaillent main dans la main (ou en tout cas, avec un seul arbre de développement) les couches au dessus ont autant de branches que de projet ce qui rend la coordination difficile. Et certaines tentatives de gouvernances ont été particulièrement rejetées comme la LSB ce qui montre la difficulté de se mettre d'accord pour essayer d'harmoniser l'ensemble.
Si les projets majeurs sont prêts à s'unir sous un même pavillon, sans pour autant vendre leurs âmes au diable, il y aurait moyen en effet d'avoir une conception plus stable des cocuhes du systèmes. Mais étrangement, je n'y crois pas trop pour le moment à la possibilité d'une telle entreprise.
[^] # Re: dépendance à un système d'init
Posté par Renault (site web personnel) . En réponse au journal Debian à l'heure du choix. Évalué à 7.
Personnellement je ne te visais pas trop dans mon propos, je répondais plus à Tanguy qui faisait dans la critique gratuite de systemd alors que le problème est plus profond que ça et ne devrait pas s'attarder uniquement sur systemd. Enfin selon la vision des choses, car je pense qu'il y a deux approches que je vais expliciter plus bas.
Note que je ne suis pas particulièrement en désaccord avec toi, je comprends en tout cas ton point de vue.
Je pense que c'est en soit quelque chose à double tranchant en effet :
C'est un peu comme vouloir la stabilité et l'intégration d'une Debian et les nouveautés de Fedora (par exemple) en même temps, ce sont deux visions à mon sens correctes mais qui s'opposent et qui sont difficiles à concilier. Comme on dit, on ne peut pas tout avoir.
Beaucoup ici aiment les systèmes libres car tout peut être remis en question, que ça évolue suffisamment vite pour être en phase avec l'évolution technique. Ce sont des qualités souvent mis en opposition avec Windows par exemple mais qui nécessite de changer d'API quand on se rend compte que celles existantes ne parviennent pas à convenir à la situation d'aujourd'hui.
Et il sera impossible d'avoir une API stable tant qu'il n'y aura pas de gouvernance suprême. Si le noyau est géré par une poignée de gens qui travaillent main dans la main (ou en tout cas, avec un seul arbre de développement) les couches au dessus ont autant de branches que de projet ce qui rend la coordination difficile. Et certaines tentatives de gouvernances ont été particulièrement rejetées comme la LSB ce qui montre la difficulté de se mettre d'accord pour essayer d'harmoniser l'ensemble.
Si les projets majeurs sont prêts à s'unir sous un même pavillon, sans pour autant vendre leurs âmes au diable, il y aurait moyen en effet d'avoir une conception plus stable des cocuhes du systèmes. Mais étrangement, je n'y crois pas trop pour le moment à la possibilité d'une telle entreprise.