Alors que, objectivement, porter un logiciel n'impacte pas sa qualité, au contraire. C'est tellement gros que venir affirmer le contraire est faire preuve d'une mauvaise foie flagrante.
Objectivement, il a en partie raison quand même sur ce point. Sinon c'est ignorer les impacts d'un portage.
Un portage, pour être réussi et élégant doit se résoudre à exploiter le dénominateur commun entre les deux systèmes à gérer. Cela impose des limites, typiquement systemd repose sur les cgroups que les *BSD n'ont pas (ou en équivalent clair). Porter systemd revient soit à virer tout ce qui exploite les cgroups, ou alors à faire du code sale / difficile à maintenir pour se comporter sous Linux et *BSD de manière différente. Ce qui en plus rend difficile la détection de problème, de la création de la documentation, etc. si les comportements doivent différer car les mécanismes sous-jacents sont différents.
Bref, la raison technique invoquée est loin d'être délirante et pour un projet comme systemd les risques de soit le vider de son sens, soit de le rendre vraiment horrible à maintenir sont grands. La question à se poser est : est-ce que cela a un grand intérêt qu'un composant qui fait l'interface entre le noyau et l'espace utilisateur soit portable ? C'est discutable. À dire vrai, je pense que pour exploiter au mieux les possibilités de chaque système, il est plus intéressant que ce soit disjoint. Après tout, cela a été globalement le cas depuis toujours (SysV n'a jamais été sous *BSD, et même entre les différents Linux ce n'était pas la joie). Pourquoi nécessairement changer ?
De la même façon que de nombreux outils autours du noyau ne sont pas portables pour des raisons évidentes, je dirais que systemd peut en faire partie. Par contre, je pense qu'il serait intéressant de faire une API commune sur certains points dans ces systèmes. Une sorte de POSIX plus moderne sur cette question, mais laissant libre court à sa mise en œuvre.
[^] # Re: systemd, le nouveau Multics
Posté par Renault (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 7.
Objectivement, il a en partie raison quand même sur ce point. Sinon c'est ignorer les impacts d'un portage.
Un portage, pour être réussi et élégant doit se résoudre à exploiter le dénominateur commun entre les deux systèmes à gérer. Cela impose des limites, typiquement systemd repose sur les cgroups que les *BSD n'ont pas (ou en équivalent clair). Porter systemd revient soit à virer tout ce qui exploite les cgroups, ou alors à faire du code sale / difficile à maintenir pour se comporter sous Linux et *BSD de manière différente. Ce qui en plus rend difficile la détection de problème, de la création de la documentation, etc. si les comportements doivent différer car les mécanismes sous-jacents sont différents.
Bref, la raison technique invoquée est loin d'être délirante et pour un projet comme systemd les risques de soit le vider de son sens, soit de le rendre vraiment horrible à maintenir sont grands. La question à se poser est : est-ce que cela a un grand intérêt qu'un composant qui fait l'interface entre le noyau et l'espace utilisateur soit portable ? C'est discutable. À dire vrai, je pense que pour exploiter au mieux les possibilités de chaque système, il est plus intéressant que ce soit disjoint. Après tout, cela a été globalement le cas depuis toujours (SysV n'a jamais été sous *BSD, et même entre les différents Linux ce n'était pas la joie). Pourquoi nécessairement changer ?
De la même façon que de nombreux outils autours du noyau ne sont pas portables pour des raisons évidentes, je dirais que systemd peut en faire partie. Par contre, je pense qu'il serait intéressant de faire une API commune sur certains points dans ces systèmes. Une sorte de POSIX plus moderne sur cette question, mais laissant libre court à sa mise en œuvre.