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.
ou se comporter sous Linux et *BSD de manière différente.
Oui. Ne pas offrir un match à 100% des features ? Big deal... É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 ?
Scoop: systemd se comporte différemment sur différentes distros (relire ce journal...)
Ce qui en plus rend difficile la détection de problème, de la création de la documentation, etc.
Oui c'est plus difficile (logique) mais c'est ce travail qui rend au final la solution plus robuste.
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 ?
Oui justement car ne pas le faire c'est reporter ce coût sur l'espace utilisateur justement...
SysV
Exactement la même situation: une solution d'un vendor, non standardisée, et non libre-réutilisable tel quel (surtout que la surface système dépendant de SysV init c'est un juste un sh, ça aurait été tout à fait possible). D'autres vendors s'en inspirent mais font un truc différent. 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...
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.
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...
[^] # Re: systemd, le nouveau Multics
Posté par benja . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 2.
Rapidement.
Non. Cela veut dire prendre en compte les différente spécificités.
Oui. Ne pas offrir un match à 100% des features ? Big deal... É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 ?
Scoop: systemd se comporte différemment sur différentes distros (relire ce journal...)
Oui c'est plus difficile (logique) mais c'est ce travail qui rend au final la solution plus robuste.
Oui justement car ne pas le faire c'est reporter ce coût sur l'espace utilisateur justement...
Exactement la même situation: une solution d'un vendor, non standardisée, et non libre-réutilisable tel quel (surtout que la surface système dépendant de SysV init c'est un juste un sh, ça aurait été tout à fait possible). D'autres vendors s'en inspirent mais font un truc différent. 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...
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...