Bah, il me semble que le deal évident, c'est que si tu administres ta machine, tu assumes, et tu corriges les boulettes (et tu réinstalles ta distrib si tu as tout pété).
Le problème, c'est qu'en recherche, tu as tout le temps besoin de faire des trucs sales : récupérer un programme écrit par des chinois, le compiler, l'exécuter, le modifier, le coller sur un serveur de calcul, et tout faire péter avec une fuite mémoire, par exemple, et le tout dans une seule journée. C'est la procédure normale, et toute autre procédure va simplement arriver au même résultat, sauf que ça prendra plus longtemps.
Dans mon cas, le service info me laisse gérer mon serveur de calcul et ma machine perso, plus les machines des étudiants. Je n'ai donc qu'à administrer un seul serveur, et j'ai déja l'impression de passer pas mal de temps à installer des trucs : des libs, des python-machin, des perl-machin, le même python-machin mais pas la même version, et des milliers de paquets pour R… ça ne s'arrête jamais, et ça peut être bloquant si tu en as besoin le vendredi soir. Et encore, on a imposé que les programmes perso ou non-packagés soient exécutés dans le /home , quitte à les dupliquer entre utilisateurs, de manière à n'avoir que les paquets de la distrib en root, sans /opt ni /usr/local. Franchement, je ne vois pas comment on peut réussir à gérer un parc de plusieurs dizaines de machines en production si on ne délègue pas ce genre de trucs. La seule solution serait de dire aux utilisateurs d'arrêter de faire des trucs crades, mais dans un labo de recherche, faire des trucs crades est justement ce pour quoi les gens sont payés.
[^] # Re: Premier boulot ?
Posté par arnaudus . En réponse au message Pratique professionnelle douteuse. Évalué à 6.
Bah, il me semble que le deal évident, c'est que si tu administres ta machine, tu assumes, et tu corriges les boulettes (et tu réinstalles ta distrib si tu as tout pété).
Le problème, c'est qu'en recherche, tu as tout le temps besoin de faire des trucs sales : récupérer un programme écrit par des chinois, le compiler, l'exécuter, le modifier, le coller sur un serveur de calcul, et tout faire péter avec une fuite mémoire, par exemple, et le tout dans une seule journée. C'est la procédure normale, et toute autre procédure va simplement arriver au même résultat, sauf que ça prendra plus longtemps.
Dans mon cas, le service info me laisse gérer mon serveur de calcul et ma machine perso, plus les machines des étudiants. Je n'ai donc qu'à administrer un seul serveur, et j'ai déja l'impression de passer pas mal de temps à installer des trucs : des libs, des python-machin, des perl-machin, le même python-machin mais pas la même version, et des milliers de paquets pour R… ça ne s'arrête jamais, et ça peut être bloquant si tu en as besoin le vendredi soir. Et encore, on a imposé que les programmes perso ou non-packagés soient exécutés dans le /home , quitte à les dupliquer entre utilisateurs, de manière à n'avoir que les paquets de la distrib en root, sans /opt ni /usr/local. Franchement, je ne vois pas comment on peut réussir à gérer un parc de plusieurs dizaines de machines en production si on ne délègue pas ce genre de trucs. La seule solution serait de dire aux utilisateurs d'arrêter de faire des trucs crades, mais dans un labo de recherche, faire des trucs crades est justement ce pour quoi les gens sont payés.