par exemple, quand l'admin dit "je veux que ce logiciel tourne sans réseau", il fait abstraction de la méthode ( à savoir les namespaces réseau )
Cette abstraction ne tiens pas la route, vu que ce n'est pas Systemd qui configure le service, c'est moi.
Si je configure le service pour qu'il se connecte à localhost vers un autre service, le mettre dans un network namespace séparé ne marchera pas, sauf configuration particulière du namespace. Pourtant j'ai bien envie qu'il n'accède pas au réseau. Et j'ai pas envie qu'il accède à tout mes services locaux en plus.
Leaky abstractions. Il aurai mieux fallu ne rien abstraire du tout, tout expliciter et tout rendre configurable. Les systèmes magiques c'est peut-être mignons pour les desktop, mais ça n'a rien à faire sur un serveur.
Tu confonds "contraintes pour qu'un système démarre" et "contraintes pour qu'un systéme tourne sans jamais aucun souci".
Je ne fais pas de différences entre les deux, moi je veux un système qui marche. Si il merde au démarrage ou après, c'est déjà un échec, parce que ce système devait marcher.
Le problème, c'est juste que beaucoup de ces contraintes posent des problèmes au niveau du démarrage. Le service buggé qui supporte pas les changement d'heure doit être lancé après un ntpdate, et aucun autre logiciel ne doit changer l'heure après que l'autre ai démarré. Pareil pour l'autre contrainte qui implique de connaître tout les cwd des processus et les fichiers qu'ils peuvent garder ouvert.
Ça veut dire regarder absolument tout les logiciels qui tournent (même l'init) et savoir ce qu'ils font tous. S'il font tous ce que je demande, c'est cool. S'ils ne font pas ce que je demande, il va falloir que je les patche, et je préfère patcher du shell script plutôt que de patcher du C.
Et le syndrome de systemd qui consiste à uniquement regarder ce qu'on besoin 80% des personnes et a envoyer chier les autres ne simplifie vraiment pas le problème. Pour systemd, ils ont du regarder les besoins de la plupart des services et ils vont se dire qu'ils ne vont gérer que ces contraintes là, les autres pouvant aller se faire foutre. Pareil pour system-networkd: ils ont du rencontrer un admin qui leur à demandé une certaine liste de fonctionnalité et ils n'ont pas du se dire que peut-être un jour d'autres personnes auront d'autres besoins. On se retrouve avec des logiciels qui sont utiles que pour une certaines majorité de personnes qui viennent ensuite expliquer aux autres comment ils n'ont pas besoin des fonctionnalités qu'ils avaient avant.
[^] # Re: De plus en plus complexe, le système d'init...
Posté par Batchyx . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à -1.
Cette abstraction ne tiens pas la route, vu que ce n'est pas Systemd qui configure le service, c'est moi.
Si je configure le service pour qu'il se connecte à localhost vers un autre service, le mettre dans un network namespace séparé ne marchera pas, sauf configuration particulière du namespace. Pourtant j'ai bien envie qu'il n'accède pas au réseau. Et j'ai pas envie qu'il accède à tout mes services locaux en plus.
Leaky abstractions. Il aurai mieux fallu ne rien abstraire du tout, tout expliciter et tout rendre configurable. Les systèmes magiques c'est peut-être mignons pour les desktop, mais ça n'a rien à faire sur un serveur.
Je ne fais pas de différences entre les deux, moi je veux un système qui marche. Si il merde au démarrage ou après, c'est déjà un échec, parce que ce système devait marcher.
Le problème, c'est juste que beaucoup de ces contraintes posent des problèmes au niveau du démarrage. Le service buggé qui supporte pas les changement d'heure doit être lancé après un ntpdate, et aucun autre logiciel ne doit changer l'heure après que l'autre ai démarré. Pareil pour l'autre contrainte qui implique de connaître tout les cwd des processus et les fichiers qu'ils peuvent garder ouvert.
Ça veut dire regarder absolument tout les logiciels qui tournent (même l'init) et savoir ce qu'ils font tous. S'il font tous ce que je demande, c'est cool. S'ils ne font pas ce que je demande, il va falloir que je les patche, et je préfère patcher du shell script plutôt que de patcher du C.
Et le syndrome de systemd qui consiste à uniquement regarder ce qu'on besoin 80% des personnes et a envoyer chier les autres ne simplifie vraiment pas le problème. Pour systemd, ils ont du regarder les besoins de la plupart des services et ils vont se dire qu'ils ne vont gérer que ces contraintes là, les autres pouvant aller se faire foutre. Pareil pour system-networkd: ils ont du rencontrer un admin qui leur à demandé une certaine liste de fonctionnalité et ils n'ont pas du se dire que peut-être un jour d'autres personnes auront d'autres besoins. On se retrouve avec des logiciels qui sont utiles que pour une certaines majorité de personnes qui viennent ensuite expliquer aux autres comment ils n'ont pas besoin des fonctionnalités qu'ils avaient avant.