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.
Non. Cela veut dire prendre en compte les différente spécificités.
Tout dépend de la quantité de code en dehors du socle commun.
Si la quantité est faible et peu impactant (ne change pas l'architecture du programme) oui tu peux te permettre à gérer l'ensemble des différences.
Ici, ce n'est pas le cas. Typiquement les cgroups sont trop liés à Linux et trop au cœur de son architecture pour rendre cela élégant et simple sur d'autres systèmes.
videmment qu'il n'y aura pas de cgroup sous bsd, et alors est-ce que ça rend le 99% restant des autres features non pertinant ?
L'architecture de systemd a été conçue pour coller au fonctionnement de Linux car c'était son but d'exploiter les possibilités du noyau que ne permet pas POSIX par exemple.
C'est loin d'être aussi trivial que tu ne le prétends, et c'est pour ça que Lennart encourage les forks du projet plutôt que de gérer la portabilité.
Oui c'est plus difficile (logique) mais c'est ce travail qui rend au final la solution plus robuste.
Non.
Si le code a des #ifdef de partout pour gérer Linux d'un côté, *BSD de l'autre, XXXX finalement, c'est difficile à maintenir et ça va créer beaucoup de bogues pour un gain discutable.
La portabilité peut rendre robuste un programme, oui, mais pas si ce programme a couplage fort avec un autre composant où l'effet est inverse.
Oui justement car ne pas le faire c'est reporter ce coût sur l'espace utilisateur justement...
Pas forcément, la preuve j'ai parlé d'exposer et de déterminer une API publique qui serait commune à ces projets histoire d'étendre POSIX.
Et là l'espace utilisateur n'aurait rien à secouer de la "fragmentation" de systemd en différentes versions suivant les système.
surtout que la surface système dépendant de SysV init c'est un juste un sh, ça aurait été tout à fait possible
SysV, ce n'est pas que le shell, c'est tout ce qu'il y a derrière les scripts et c'est là le problème. La gestion des périphériques ? Pas standardisée. Les modules de sécurité (SELinux et autres) ? Non plus. Les cgroups ? Oublie. Etc.
Même entre les différentes distributions ce n'était pas possible d’homogénéiser les scripts proprement. Et c'était très complexe dans une même distribution d'être cohérent, certains typiquement géraient que partiellement l'existence de SELinux par exemple.
Donc homogénéiser avec d'autres systèmes qui ont des différences fondamentales sur ces questions, c'est chercher la merde pour la maintenance de ce code unique.
Au final c'est l'utilisateur qui trinque et doit gèrer 50 façons différentes, ce qu'il ne fait pas. évidemment. Résultat ? Fragmentation de l'éco-système et affaiblissement/mort générale. Dire que seul Linux importe, c'est reffaire la même erreure et faire preuve de trop d'optimisme, il est probable qu'il soit perdant aussi...
À t'écouter on dirait que tout l'espace utilisateur doit prendre en charge systemd d'un côté, SysV de l'autre, etc.
C'est faux... À part quelques programmes assez spécifiques, les applications et utilisateurs s'en cognent de systemd. Les applications libres communes à Linux et *BSD n'ont pas cessé le support de l'un des deux depuis, et sans devoir être modifié...
Oui 100% d'accord. Vu que systemd est en gros cette nouvelle API/standard, c'est dommage de ne pas avoir pris l'opportunité de le faire correctement. 95% du code de systemd n'est pas du code system dépendant hein...
Vu que tu trouves le correctif nécessaire trivial, je t'invite à l'écrire, le maintenir et le soumettre. Lennart refuse car il sait que ce serait un gros travail. On attend ton code pour prouver le contraire.
[^] # 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é à 8.
Tout dépend de la quantité de code en dehors du socle commun.
Si la quantité est faible et peu impactant (ne change pas l'architecture du programme) oui tu peux te permettre à gérer l'ensemble des différences.
Ici, ce n'est pas le cas. Typiquement les cgroups sont trop liés à Linux et trop au cœur de son architecture pour rendre cela élégant et simple sur d'autres systèmes.
L'architecture de systemd a été conçue pour coller au fonctionnement de Linux car c'était son but d'exploiter les possibilités du noyau que ne permet pas POSIX par exemple.
C'est loin d'être aussi trivial que tu ne le prétends, et c'est pour ça que Lennart encourage les forks du projet plutôt que de gérer la portabilité.
Non.
Si le code a des #ifdef de partout pour gérer Linux d'un côté, *BSD de l'autre, XXXX finalement, c'est difficile à maintenir et ça va créer beaucoup de bogues pour un gain discutable.
La portabilité peut rendre robuste un programme, oui, mais pas si ce programme a couplage fort avec un autre composant où l'effet est inverse.
Pas forcément, la preuve j'ai parlé d'exposer et de déterminer une API publique qui serait commune à ces projets histoire d'étendre POSIX.
Et là l'espace utilisateur n'aurait rien à secouer de la "fragmentation" de systemd en différentes versions suivant les système.
SysV, ce n'est pas que le shell, c'est tout ce qu'il y a derrière les scripts et c'est là le problème. La gestion des périphériques ? Pas standardisée. Les modules de sécurité (SELinux et autres) ? Non plus. Les cgroups ? Oublie. Etc.
Même entre les différentes distributions ce n'était pas possible d’homogénéiser les scripts proprement. Et c'était très complexe dans une même distribution d'être cohérent, certains typiquement géraient que partiellement l'existence de SELinux par exemple.
Donc homogénéiser avec d'autres systèmes qui ont des différences fondamentales sur ces questions, c'est chercher la merde pour la maintenance de ce code unique.
À t'écouter on dirait que tout l'espace utilisateur doit prendre en charge systemd d'un côté, SysV de l'autre, etc.
C'est faux... À part quelques programmes assez spécifiques, les applications et utilisateurs s'en cognent de systemd. Les applications libres communes à Linux et *BSD n'ont pas cessé le support de l'un des deux depuis, et sans devoir être modifié...
Vu que tu trouves le correctif nécessaire trivial, je t'invite à l'écrire, le maintenir et le soumettre. Lennart refuse car il sait que ce serait un gros travail. On attend ton code pour prouver le contraire.