Posté par Domi .
En réponse au message Les cgroups et systemd.
Évalué à 1.
Dernière modification le 13 janvier 2014 à 01:53.
Quoi qu'il en soit, quand j'ai installé Debian, systemd à été installé. De plus, j'ai installé gentoo ce qui a résolu mon problème (voir plus bas).
Le problème de systèmed avec les cgroups est qu'il installe, comme je l'ai compris en lisant ce qui dit Lennart dans l'article de linux.fr, j'ai aussi lu l'entier de ce qu'il dit sur gmane (le lien est dans l'article), le problème est que systemd implémente seulement un subset des cgroups qui correspond à l'option automatique du kernel, qu'il prend le contrôle des cgroups, et que contrairement au kernel associé avec libcgroup/cgroup-bin, systemd ne met aucune réelle possibilité de setup à disposition de l'utilisateur.
Ceci implique que n'importe quel utilisateur qui utilise autre chose que la configuration automatique des cgroups dans le kernel ne peut pas utiliser systemd. Donc, la communauté audio pro n'est sûrement pas la seule concernée par ce problème avec systemd.
La cause de ce problème est pour moi une fausse conception de ce que fait un utilisateur avec son pc. Pour moi, un pc ça sert à travailler. Pour le développeur en chef de systemd, comme il le dit très bien dans son mail sur gmane, un pc sert à faire tourner un GUI et toutes les autres utilisations ne sont pas relevantes.
Ce qui implique que pour résoudre ce problème, il faudrait revoir l'API de systemd pour qu'il supporte toutes les fonctions cgroups du kernel, ceci même en mode non automatique, et pour qu'un plus systemd soit capable de proposer un interface de configuration des cgroups à l'utilisateur.
Quand à mon gentoo, une partie de mes USE flags sont "-systemd -consolekit -policykit -pulseaudio -udisks -udisks2", donc un système léger sans tous ses machins superflus qui apportent plus de problèmes que de solutions. Je ne remet pas en cause l'idée de systemd, mais je constate simplement que son implémentation actuelle est contraire à l'esprit de GNU/Linux qui est d'offrir le choix aux utilisateurs. LEs cgroups du kernel, en conjonction avec libcgroup/cgroup-bin, permettent d'optimiser une machine donnée pour n'importe quelle sorte de charge de travail. Avec systemd, seule une configuration par défaut est proposée, et il n'y a aucune possibilité de sortir de cette configuration par défaut. De plus la documentation est quasi inexistante, ce qui est normal vu le peu de possibilités de configuration.
Lennart le dit lui même:
"In fact, I just prepped a patch to systemd to move every service and every user session into its own cgroup in the 'cpu' hierarchy (in addition to the group it already creates in the 'systemd' hierarchy). On a system that runs systemd for both managing users and sessions this means you are already half-way at what you want.">
Ce qui implique que son implémentation des cgroups dans systemd est à moitié incomplète.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re:
Posté par Domi . En réponse au message Les cgroups et systemd. Évalué à 1. Dernière modification le 13 janvier 2014 à 01:53.
Quoi qu'il en soit, quand j'ai installé Debian, systemd à été installé. De plus, j'ai installé gentoo ce qui a résolu mon problème (voir plus bas).
Le problème de systèmed avec les cgroups est qu'il installe, comme je l'ai compris en lisant ce qui dit Lennart dans l'article de linux.fr, j'ai aussi lu l'entier de ce qu'il dit sur gmane (le lien est dans l'article), le problème est que systemd implémente seulement un subset des cgroups qui correspond à l'option automatique du kernel, qu'il prend le contrôle des cgroups, et que contrairement au kernel associé avec libcgroup/cgroup-bin, systemd ne met aucune réelle possibilité de setup à disposition de l'utilisateur.
Ceci implique que n'importe quel utilisateur qui utilise autre chose que la configuration automatique des cgroups dans le kernel ne peut pas utiliser systemd. Donc, la communauté audio pro n'est sûrement pas la seule concernée par ce problème avec systemd.
La cause de ce problème est pour moi une fausse conception de ce que fait un utilisateur avec son pc. Pour moi, un pc ça sert à travailler. Pour le développeur en chef de systemd, comme il le dit très bien dans son mail sur gmane, un pc sert à faire tourner un GUI et toutes les autres utilisations ne sont pas relevantes.
Ce qui implique que pour résoudre ce problème, il faudrait revoir l'API de systemd pour qu'il supporte toutes les fonctions cgroups du kernel, ceci même en mode non automatique, et pour qu'un plus systemd soit capable de proposer un interface de configuration des cgroups à l'utilisateur.
Quand à mon gentoo, une partie de mes USE flags sont "-systemd -consolekit -policykit -pulseaudio -udisks -udisks2", donc un système léger sans tous ses machins superflus qui apportent plus de problèmes que de solutions. Je ne remet pas en cause l'idée de systemd, mais je constate simplement que son implémentation actuelle est contraire à l'esprit de GNU/Linux qui est d'offrir le choix aux utilisateurs. LEs cgroups du kernel, en conjonction avec libcgroup/cgroup-bin, permettent d'optimiser une machine donnée pour n'importe quelle sorte de charge de travail. Avec systemd, seule une configuration par défaut est proposée, et il n'y a aucune possibilité de sortir de cette configuration par défaut. De plus la documentation est quasi inexistante, ce qui est normal vu le peu de possibilités de configuration.
Lennart le dit lui même:
Ce qui implique que son implémentation des cgroups dans systemd est à moitié incomplète.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.