Le VRAI problème des outils maison, c'est surtout... qu'ils existent ! Non, ce n'est pas un troll, je m'explique :
1. Ces outils sont tous différents et insuffisamment intégrés. Déjà passé d'une RH à une SuSE puis à une Mdk, puis à une Debian ? Vous avez remarqué que rien n'est au même endroit ? Ça ne vous saoûle pas, vous ? Moi, si. Microsoft avait déjà réussi le tour de force de ne jamais faire deux versions de son OS qui se ressemblent. Total, lorsqu'on débarque sur une machine Win32 équipée d'une version qu'on ne connaît pas, eh ben on passe du temps à tâtonner pour retrouver ses répères : la productivité coule. Les distributeurs Linux ont, hélas, réédité cet exploit avec leurs outils trop disparates. Une solution eut été de coder simplement des modules pour les panneaux de contrôle GNOME/KDE, ça aurait donné aux gens un endroit unique où configurer le système (pour ceux qui vont dire que ça aurait pénalisé ceux qui n'utilisent pas ces environnements, on peut lancer lesdits modules indépendamment sauf erreur). Mais on a préféré faire des applis hétérogènes. Ça me dépasse, franchement...
2. Le back-end n'a pas été codifié, ce qui donne lieu à de belles parties de cache-cache lorsqu'on a besoin d'intervenir à la main (par exemple, parce que le cliquodrome est cassé). Avec le temps, évidemment, on finit par se souvenir que sur la Mdk les paramètres rézal sont mis dans /etc/sysconfig/network-scripts/ifcfg-{interface} et sur la Debian dans /etc/network/interfaces. On finit par savoir où sont les fichiers de config, et ce qu'il ne faut pas modifier dedans si on ne veut pas faire péter un boulon au cliquodrome (voire parfois, on abandonne. Mes fstab, je les fais à la mimine, au moins ce qui est dedans est lisible. Il ne reste qu'à ne pas oublier de ne pas laisser le cliquodrome y toucher, autrement il va les bidouiller à sa sauce sans se poser de questions). Et puis, on tombe sur un énième outil qui bouscule tout. Un exemple ? Je mettais toujours les hôtes virtuels Apache dans /etc/httpd/conf/vhosts/Vhosts.conf sur une Mdk, puisque c'est leur méthode. Et puis je suis tombé sur un serveur administré avec Webmin : les vhosts étaient directement dans httpd.conf. On aurait pu espérer que Webmin eut été modifié pour suivre les règles de la distrib. Que nenni. Alors oui, le bazar, c'est bien, mais il faut pas en abuser ! Une solution à mon sens, c'eut été de définir clairement un standard pour tout le monde (tel sous-système il a tel fichier de conf avec tel format) et éventuellement de laisser libre l'implémentation au niveau applicatif (puisque certaines distribs peuvent toujours avoir des besoins particuliers, et/ou vouloir se démarquer des copains). Au moins, un admin arrivant sur n'importe quelle distrib eut pu facilement retrouver ses petits. La LSB eut été le forum idéal pour ça, mais apparemment, ça n'a pas été jugé utile. Résultat : lorsqu'on me pose une question concernant la SuSE par exemple, je ne peux pas répondre (ou le cas échéant, je peux donner une réponse qui a des chances de provoquer un conflit avec l'outil de config). C'est bête, non ?
WSA, qui vote [OUI] à un système de config unifié pour Linusque.
[^] # Re: \o/
Posté par William Steve Applegate . En réponse à la dépêche YaST en GPL. Évalué à 5.
1. Ces outils sont tous différents et insuffisamment intégrés. Déjà passé d'une RH à une SuSE puis à une Mdk, puis à une Debian ? Vous avez remarqué que rien n'est au même endroit ? Ça ne vous saoûle pas, vous ? Moi, si. Microsoft avait déjà réussi le tour de force de ne jamais faire deux versions de son OS qui se ressemblent. Total, lorsqu'on débarque sur une machine Win32 équipée d'une version qu'on ne connaît pas, eh ben on passe du temps à tâtonner pour retrouver ses répères : la productivité coule. Les distributeurs Linux ont, hélas, réédité cet exploit avec leurs outils trop disparates. Une solution eut été de coder simplement des modules pour les panneaux de contrôle GNOME/KDE, ça aurait donné aux gens un endroit unique où configurer le système (pour ceux qui vont dire que ça aurait pénalisé ceux qui n'utilisent pas ces environnements, on peut lancer lesdits modules indépendamment sauf erreur). Mais on a préféré faire des applis hétérogènes. Ça me dépasse, franchement...
2. Le back-end n'a pas été codifié, ce qui donne lieu à de belles parties de cache-cache lorsqu'on a besoin d'intervenir à la main (par exemple, parce que le cliquodrome est cassé). Avec le temps, évidemment, on finit par se souvenir que sur la Mdk les paramètres rézal sont mis dans /etc/sysconfig/network-scripts/ifcfg-{interface} et sur la Debian dans /etc/network/interfaces. On finit par savoir où sont les fichiers de config, et ce qu'il ne faut pas modifier dedans si on ne veut pas faire péter un boulon au cliquodrome (voire parfois, on abandonne. Mes fstab, je les fais à la mimine, au moins ce qui est dedans est lisible. Il ne reste qu'à ne pas oublier de ne pas laisser le cliquodrome y toucher, autrement il va les bidouiller à sa sauce sans se poser de questions). Et puis, on tombe sur un énième outil qui bouscule tout. Un exemple ? Je mettais toujours les hôtes virtuels Apache dans /etc/httpd/conf/vhosts/Vhosts.conf sur une Mdk, puisque c'est leur méthode. Et puis je suis tombé sur un serveur administré avec Webmin : les vhosts étaient directement dans httpd.conf. On aurait pu espérer que Webmin eut été modifié pour suivre les règles de la distrib. Que nenni. Alors oui, le bazar, c'est bien, mais il faut pas en abuser ! Une solution à mon sens, c'eut été de définir clairement un standard pour tout le monde (tel sous-système il a tel fichier de conf avec tel format) et éventuellement de laisser libre l'implémentation au niveau applicatif (puisque certaines distribs peuvent toujours avoir des besoins particuliers, et/ou vouloir se démarquer des copains). Au moins, un admin arrivant sur n'importe quelle distrib eut pu facilement retrouver ses petits. La LSB eut été le forum idéal pour ça, mais apparemment, ça n'a pas été jugé utile. Résultat : lorsqu'on me pose une question concernant la SuSE par exemple, je ne peux pas répondre (ou le cas échéant, je peux donner une réponse qui a des chances de provoquer un conflit avec l'outil de config). C'est bête, non ?
WSA, qui vote [OUI] à un système de config unifié pour Linusque.
Envoyé depuis mon PDP 11/70