Pour arriver à ses objectifs fonctionnels il a besoin d'utiliser des fonctionnalités qui n'existent pas (encore ?) sur d'autres systèmes.
Non, non, pour arriver a ses objectifs fonctionnels, il impose d'utiliser exclusivement les API linux - avec une hierarchie de droits et une arbo fichier fixé par lui, en se foutant bien de tout ce qui peut exister en dehors.
Je me suis retrouvé dans le même cas que lui il y a quelques mois. Je ne pouvais pas assurer une fonctionnalité sans les cgroups.
J'ignore quels sont les autres OS "possibles" envisagés, mais au niveau fonctionnel on peut faire à peu prèt tout ce qui est fait en cgroup avec diverses API des autres systèmes. Je ne connais pas MacOSX et je sais que sous Windows il y a quelques lacunes au niveau de la gestion de la consommation de bande passante par le system ressource manager.
En fait j'adorerai savoir quelle fonctionnalité tu ne pouvais pas implementer et sur quelle cible elle ne pouvait pas être implémentée.
Mais tu ne peux pas tout faire avec l'API POSIX... Triste réalité.
Certes, mais en réalité on couvre 99% des besoins avec les API POSIX. Quand tu poses sur la table les API Capabilities, ACL, Threads et Limits. Tu as déjà un excellent controle de ce qui peut arriver à ton processus. Même si il y a des sérieux soucis de sécurité dans tout çà (Notamment la granularité des capacities qui est légèrement à la ramasse).
Quelles sont les propositions concrètes pour permettre de supporter plus de systèmes ?
Généralement quand il y a des besoins définis, et que certains problèmes ne peuvent pas être résolus par un programme gentillet - on commence à faire des interfaces. Par exemple même si BSD-Jail et LXC sont assez différents il est possible de créer une interface d'abstraction commune pour une bonne partie des fonctionnalités de l'un et de l'autre. Bien entendu ca obligera les devs à se passer d'une partie (généralement très spécifique, mais parfois pratique) des fonctions de leur API.
Et au fur et à mesure du temps qui passe, l'interface s'affine et les efforts de portage diminuent jusqu'à ce qu'on ait finalement une implémentation native et en direct de l'interface dans le kernel.
Le gros problème de Lennart Poettering et qu'il veut faire un système d'init - c'est à dire le truc le plus sensible qui soit, ex-aequo avec le kernel. Et qu'au lieu de chercher à faire un truc aussi simple que possible, il part sur une solution qui fait le café quand on dit bonjour dans un micro. Au niveau config/sécurité/maintenance/reprise du système d'un tiers/ ce truc me terrifie.
[^] # Re: Ça fait peur
Posté par phxonx . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 10. Dernière modification le 05 juillet 2011 à 19:43.
Non, non, pour arriver a ses objectifs fonctionnels, il impose d'utiliser exclusivement les API linux - avec une hierarchie de droits et une arbo fichier fixé par lui, en se foutant bien de tout ce qui peut exister en dehors.
J'ignore quels sont les autres OS "possibles" envisagés, mais au niveau fonctionnel on peut faire à peu prèt tout ce qui est fait en cgroup avec diverses API des autres systèmes. Je ne connais pas MacOSX et je sais que sous Windows il y a quelques lacunes au niveau de la gestion de la consommation de bande passante par le system ressource manager.
En fait j'adorerai savoir quelle fonctionnalité tu ne pouvais pas implementer et sur quelle cible elle ne pouvait pas être implémentée.
Certes, mais en réalité on couvre 99% des besoins avec les API POSIX. Quand tu poses sur la table les API Capabilities, ACL, Threads et Limits. Tu as déjà un excellent controle de ce qui peut arriver à ton processus. Même si il y a des sérieux soucis de sécurité dans tout çà (Notamment la granularité des capacities qui est légèrement à la ramasse).
Généralement quand il y a des besoins définis, et que certains problèmes ne peuvent pas être résolus par un programme gentillet - on commence à faire des interfaces. Par exemple même si BSD-Jail et LXC sont assez différents il est possible de créer une interface d'abstraction commune pour une bonne partie des fonctionnalités de l'un et de l'autre. Bien entendu ca obligera les devs à se passer d'une partie (généralement très spécifique, mais parfois pratique) des fonctions de leur API.
Et au fur et à mesure du temps qui passe, l'interface s'affine et les efforts de portage diminuent jusqu'à ce qu'on ait finalement une implémentation native et en direct de l'interface dans le kernel.
Le gros problème de Lennart Poettering et qu'il veut faire un système d'init - c'est à dire le truc le plus sensible qui soit, ex-aequo avec le kernel. Et qu'au lieu de chercher à faire un truc aussi simple que possible, il part sur une solution qui fait le café quand on dit bonjour dans un micro. Au niveau config/sécurité/maintenance/reprise du système d'un tiers/ ce truc me terrifie.