pas qu'on compte sur chaque auteur de chaque script de démarrage d'utiliser cgroups.
+1
Et c'est bien un problème concret de Unix en général : en laissant trop de champ au sysadmin, on peut se retrouver avec du bricolage assez rapidement. Ton argument sur Cgroups je le place aussi pour les scripts d'init dans leur ensemble, tout leur ensemble. Quiconque a travaillé dans une maison dont l'histoire avec unix est aussi vieille que unix lui même, avec un parc de machines conséquent et très disparate, verra bien de quoi il s'agit lorsqu'on parle de bricolage. C'est vrai (heu, ça me semble) que systemd enlève du possible, par défaut, aux sysadmin. Et alors ? Vous en avez pas marre, vous, de voir des scripts d'init foireux partout sur plein de machines, avec un historique, et parfois un objectif, inconnu ? Là, le sysadmin il se contentera d'un déclaratif encore plus simple qu'un script, et c'est très bien comme ça.
Alors oui, moi aussi j'aime bien me toucher en faisant moi même des modifications, des ajouts, et même des règles Cgroups personnalisées. Juste pour le fun. Mais IRL, dans une grosse boite, le sysadmin qui fait ça j'ai tendance à vouloir l'enduire de goudron et de plumes. Donc :
permet un contrôle pratiquement total du processus de démarrage complet
Est un problème dans un parc conséquent avec un environnement mouvant. N'est pas un avantage. Et s'il veut "reprendre le contrôle total", ben il "upgrade son skill".
Bon, ceci dit, cet argument en faveur de systemd peut être retourner en compensant ce défaut de sysV par une bonne centralisation des confs, et des "meilleures pratiques" bien respectées. Mouhai, j'ai quant même un doute.
Su ce point là, précis, le sysadmin que je suis vois dans systemd une sacrée belle avancée. (après, pour le reste, sur dbus surtout, je ne sais pas)
[^] # Re: Mouais
Posté par bubar🦥 . En réponse au journal Traduction : le sophisme systemd -- Leszek Urbanski, tgr, monolight.cc. Évalué à 6. Dernière modification le 07 mars 2012 à 10:48.
+1
Et c'est bien un problème concret de Unix en général : en laissant trop de champ au sysadmin, on peut se retrouver avec du bricolage assez rapidement. Ton argument sur Cgroups je le place aussi pour les scripts d'init dans leur ensemble, tout leur ensemble. Quiconque a travaillé dans une maison dont l'histoire avec unix est aussi vieille que unix lui même, avec un parc de machines conséquent et très disparate, verra bien de quoi il s'agit lorsqu'on parle de bricolage. C'est vrai (heu, ça me semble) que systemd enlève du possible, par défaut, aux sysadmin. Et alors ? Vous en avez pas marre, vous, de voir des scripts d'init foireux partout sur plein de machines, avec un historique, et parfois un objectif, inconnu ? Là, le sysadmin il se contentera d'un déclaratif encore plus simple qu'un script, et c'est très bien comme ça.
Alors oui, moi aussi j'aime bien me toucher en faisant moi même des modifications, des ajouts, et même des règles Cgroups personnalisées. Juste pour le fun. Mais IRL, dans une grosse boite, le sysadmin qui fait ça j'ai tendance à vouloir l'enduire de goudron et de plumes. Donc :
Est un problème dans un parc conséquent avec un environnement mouvant. N'est pas un avantage. Et s'il veut "reprendre le contrôle total", ben il "upgrade son skill".
Bon, ceci dit, cet argument en faveur de systemd peut être retourner en compensant ce défaut de sysV par une bonne centralisation des confs, et des "meilleures pratiques" bien respectées. Mouhai, j'ai quant même un doute.
Su ce point là, précis, le sysadmin que je suis vois dans systemd une sacrée belle avancée. (après, pour le reste, sur dbus surtout, je ne sais pas)