"dans tous les sens" ? Carrément ? Ça veut dire quoi pour toi dans tous les sens ?
Ben le login, le réseau, les cgroups, certains paramètres LXC, certaines fonctionnalités acpi/apm, et bien entendu toute la couche d'interface DBus de discussion avec les processus (et j'en passe). Je pense que dans tous les sens est assez approprié dans ce cas.
Sérieusement ? Va falloir réexpliquer l'intérêt de l'utilisation des cgroup dans l'init ? T'es juste ridicule.
Oui il va falloir réexpliquer encore et encore. Par exemple l'intéret qu'il y a de lancer un résolveur local unique dans un cgroup. Il existe en une seule instance, le mapping service/pid est évident, il ne spawnera jamais de fils, son empreinte mémoire et CPU ne varira pas et si je veux de la sécurisation il faudra de toute façon que je passe par des MAC. Donc pourquoi le caller dans un cgroup et exiger les droits root pour pouvoir modifier sa config ?
Mais surtout pourquoi m'obliger à passer par systemd pour gérer mes cgroups. Contrairement à ce que tu impliques je connais et j'utilise les cgroups depuis un bon moment, et par exemple je veux que certains de mes services soit dans le même cgroup. Avant systemd c'était très simple, avec systemd à jour avec les slices et les scopes c'est une horreur (de l'aveu de Lennart lui même, c'est une des raisons pour laquelle il est en train de modifier complètement les intefaces cgroup).
Les cgroups sont très interressant dans certains cas, à savoir tague des processus qui sont potentiellement capables de faire spawner d'autres processus, ou suivre une instance spécifique d'un service que l'on lance en 25 exemplaires. Mais pour une majorité de cas c'est juste un overhead dont on aurait pu se passer.
ces logiciels peuvent toujours se servir des cgroups
Dans le nouvelle version de systemd avec lock exclusif sur les cgroups ca n'est possible que si
a) le processus en question possède les libs DBus et systemd qui vont bien
b) le processus en question a les droits root
c) la gestion des cgroups voulues par les processus n'est pas en conflit avec le tagging cgroup de systemd.
ces logiciels ne se sont JAMAIS servi des cgroups
Magie du code respectueux de la philosophie Unix, même si ces logiciels n'ont jamais implémenté de fonctionnalités cgroups en interne, il était tout à fait possible pour un admin de gérer et de faire gérer par ces processus des cgroup. En d'autres termes c'était flexible. L'inconviennient de systemd est que désormais les cgroup ne peuvent plus être appelés qe d'une seule façon et depuis un seul point d'entrée. En plus la modification d'appartenance d'un processus à un cgroup avant de le relancer est devenue une tache complexe. (Modifier dynamiquement la slice d'une unit est loin d'être uen sinécure) etc.
c'est une problématique d'intégration. L'administrateur d'un site d'e-commerce peu vouloir gérer ça différemment de celui qui fait de l'hébergement. Donc c'est forcément au niveau de l'intégration dans l'OS que ça va devoir se gérer
Donc le fait que systemd oblige tout le monde à utiliser le même tuyau de la même façon est une pénalité non ?
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Kaane . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 9.
"dans tous les sens" ? Carrément ? Ça veut dire quoi pour toi dans tous les sens ?
Ben le login, le réseau, les cgroups, certains paramètres LXC, certaines fonctionnalités acpi/apm, et bien entendu toute la couche d'interface DBus de discussion avec les processus (et j'en passe). Je pense que dans tous les sens est assez approprié dans ce cas.
Sérieusement ? Va falloir réexpliquer l'intérêt de l'utilisation des cgroup dans l'init ? T'es juste ridicule.
Oui il va falloir réexpliquer encore et encore. Par exemple l'intéret qu'il y a de lancer un résolveur local unique dans un cgroup. Il existe en une seule instance, le mapping service/pid est évident, il ne spawnera jamais de fils, son empreinte mémoire et CPU ne varira pas et si je veux de la sécurisation il faudra de toute façon que je passe par des MAC. Donc pourquoi le caller dans un cgroup et exiger les droits root pour pouvoir modifier sa config ?
Mais surtout pourquoi m'obliger à passer par systemd pour gérer mes cgroups. Contrairement à ce que tu impliques je connais et j'utilise les cgroups depuis un bon moment, et par exemple je veux que certains de mes services soit dans le même cgroup. Avant systemd c'était très simple, avec systemd à jour avec les slices et les scopes c'est une horreur (de l'aveu de Lennart lui même, c'est une des raisons pour laquelle il est en train de modifier complètement les intefaces cgroup).
Les cgroups sont très interressant dans certains cas, à savoir tague des processus qui sont potentiellement capables de faire spawner d'autres processus, ou suivre une instance spécifique d'un service que l'on lance en 25 exemplaires. Mais pour une majorité de cas c'est juste un overhead dont on aurait pu se passer.
ces logiciels peuvent toujours se servir des cgroups
Dans le nouvelle version de systemd avec lock exclusif sur les cgroups ca n'est possible que si
a) le processus en question possède les libs DBus et systemd qui vont bien
b) le processus en question a les droits root
c) la gestion des cgroups voulues par les processus n'est pas en conflit avec le tagging cgroup de systemd.
ces logiciels ne se sont JAMAIS servi des cgroups
Magie du code respectueux de la philosophie Unix, même si ces logiciels n'ont jamais implémenté de fonctionnalités cgroups en interne, il était tout à fait possible pour un admin de gérer et de faire gérer par ces processus des cgroup. En d'autres termes c'était flexible. L'inconviennient de systemd est que désormais les cgroup ne peuvent plus être appelés qe d'une seule façon et depuis un seul point d'entrée. En plus la modification d'appartenance d'un processus à un cgroup avant de le relancer est devenue une tache complexe. (Modifier dynamiquement la slice d'une unit est loin d'être uen sinécure) etc.
c'est une problématique d'intégration. L'administrateur d'un site d'e-commerce peu vouloir gérer ça différemment de celui qui fait de l'hébergement. Donc c'est forcément au niveau de l'intégration dans l'OS que ça va devoir se gérer
Donc le fait que systemd oblige tout le monde à utiliser le même tuyau de la même façon est une pénalité non ?