mount va être patché ou on va bientôt devoir utiliser systemctl ?
Pourquoi continuer d'utiliser un outil lorsqu'un autre le remplace ? ça à l'air anodin, et de prime abord il est plus simple de répondre "pour ne pas casser les habitudes". Oui c'est un bon exemple du côté "bricolage totalement insupportable" qu'on rencontre parfois (souvent ?) sur les unix aux tafs. C'est bien _ au début_ car c'est pratique. A la longue ça va traîner un tas d'outils et de scripts maison basés sur des outils obsolètes mais patchés et maintenus "pour la compatibilité". Or la "compatibilité" ce n'est pas ça, ça c'est du bricolage. La compatibilité c'est que le nouvel outil soit capable de prendre en charge l'ensemble des fonctionnalités de l'ancien. Non ?
J'ai un peu dévié de ta question, et ce n'est pas une réponse à ta question, mais plutôt la continuité d'une interrogation. Je pense que systemd va apporter aussi cela, c'est un effet de bord, mais un effet de bord intéressant : il participe à décimer le côté "jojo la bricole" que, perso, j'ai rencontré bien trop souvent, et qui est la cause de pas mal de problèmes pour le suivi à long terme des systèmes.
Exemple, en reprenant mount. Dans ma fstab, j'ai un /boot noauto,comment=systemd.automount. Ben c'est sacrément confortable (comme un autofs sur du local) Simple, non ? (comparé à d'autres possibilités pour faire la même chose)
vais-je pouvoir continuer à les utiliser aussi pour (continuer à faire comme je veux)
Oui. Il ne semble pas plus compliqué de le faire à la main aujourd'hui, que de le faire avant sched_autogroup et/ou systemd. L'option par défaut change, sans empêcher une configuration maison. Les "nouveaux" outils facilitent également la tâche, par exemple on est loin aujourd'hui de la complexité initiale de la configuration de cgroups, la libcgroup et /etc/cgconfig.conf fait bien l'affaire et s'intègre avec l'usage de systemd.
//ma vie : d'ailleurs je suis un peu perdu avec tout ces nouveaux outils, moi qui avait l'habitude de mes petits tests et configs fait "directement". M'enfin c'est une question d'adaptation.
En fait le "problème" pourrait se poser un peu de la même manière pour de nombreuses choses, par exemple memlock de pam // cgroup mem. On ne devrait pas se focaliser sur systemd parcequ'il peut faire des choses que d'autres peuvent déjà faire, cette situation est très courante, non ?
[^] # Re: Quid de la diversité et des serveurs ?
Posté par bubar🦥 . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 4.
Pourquoi continuer d'utiliser un outil lorsqu'un autre le remplace ? ça à l'air anodin, et de prime abord il est plus simple de répondre "pour ne pas casser les habitudes". Oui c'est un bon exemple du côté "bricolage totalement insupportable" qu'on rencontre parfois (souvent ?) sur les unix aux tafs. C'est bien _ au début_ car c'est pratique. A la longue ça va traîner un tas d'outils et de scripts maison basés sur des outils obsolètes mais patchés et maintenus "pour la compatibilité". Or la "compatibilité" ce n'est pas ça, ça c'est du bricolage. La compatibilité c'est que le nouvel outil soit capable de prendre en charge l'ensemble des fonctionnalités de l'ancien. Non ?
J'ai un peu dévié de ta question, et ce n'est pas une réponse à ta question, mais plutôt la continuité d'une interrogation. Je pense que systemd va apporter aussi cela, c'est un effet de bord, mais un effet de bord intéressant : il participe à décimer le côté "jojo la bricole" que, perso, j'ai rencontré bien trop souvent, et qui est la cause de pas mal de problèmes pour le suivi à long terme des systèmes.
Exemple, en reprenant mount. Dans ma fstab, j'ai un /boot noauto,comment=systemd.automount. Ben c'est sacrément confortable (comme un autofs sur du local) Simple, non ? (comparé à d'autres possibilités pour faire la même chose)
Oui. Il ne semble pas plus compliqué de le faire à la main aujourd'hui, que de le faire avant sched_autogroup et/ou systemd. L'option par défaut change, sans empêcher une configuration maison. Les "nouveaux" outils facilitent également la tâche, par exemple on est loin aujourd'hui de la complexité initiale de la configuration de cgroups, la libcgroup et /etc/cgconfig.conf fait bien l'affaire et s'intègre avec l'usage de systemd.
//ma vie : d'ailleurs je suis un peu perdu avec tout ces nouveaux outils, moi qui avait l'habitude de mes petits tests et configs fait "directement". M'enfin c'est une question d'adaptation.
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/ch-Using_Control_Groups.html
En fait le "problème" pourrait se poser un peu de la même manière pour de nombreuses choses, par exemple memlock de pam // cgroup mem. On ne devrait pas se focaliser sur systemd parcequ'il peut faire des choses que d'autres peuvent déjà faire, cette situation est très courante, non ?