Fichue ligne de commande

L’autre jour, une connaissance me montre comment il a installé Linux KUbuntu au sein d’une machine virtuelle. Puis, il essaye de faire une manip ou deux, mais la résolution de l’écran était trop petite. No souci, l’on installe les “vmware tools”. Et là, les choses se sont corsées ! Il a fallu décompresser une tar.gz, puis exécuter un script .pl, dans une konsole. Le script a commencé à poser les questions, dont les réponses par défaut sont ok, jusqu’au message “les modules fournis ne se chargent pas dans le noyau. Voulez-vous les compiler ?”. Voilà le problème avec Linux ! C’est le dernière problème, mais c’est le plus compliqué à régler. Tant qu’il faudra compiler manuellement les programmes, les utilisateurs auront du mal à s’y mettre.

Imaginez le scénario : “(le directeur) Brigitte, s’il te plait, un ami m’a dit du bien de la nouvelle version du logiciel de présentation XXX, pourrais-tu faire le nécessaire ? (brigitte) Oui mon Directeur, ça tombe super bien, puisque je viens d’installer le paquetage build-essentials” … un peu plus tard … “(brigitte) Monsieur ? (le directeur) Oui ? (brigitte) Je n’arrive pas à compiler votre programme. Il me manque libSuperGolf-lib et libSuperGolf-dev et notre distribution n’offre pas les paquetages”. Je vous laisser le plaisir d’imaginer les suites possibles (c’est pas moi qui va vous dire ce qu’il choisiront, quand même).

Par ailleurs, je me demande si dans un monde dominé par des machines Intel le système gnu autoconf & company a encore raison d’exister. Je suis sûr qu’il doit exister une meilleure manière d’insérer les sources sur un système, que de les passer au autoconf et automake. Il suffit juste de se pencher un peu sur le problème !

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>