Site WWW de Laurent Bloch
Slogan du site

ISSN 2271-3905
Cliquez ici si vous voulez visiter mon autre site, orienté vers des sujets moins techniques.

Pour recevoir (au plus une fois par semaine) les nouveautés de ce site, indiquez ici votre adresse électronique :

Forum de l’article

De Multics à Unix et au logiciel libre

modération a priori

Ce forum est modéré a priori : votre contribution n’apparaîtra qu’après avoir été validée par un administrateur du site.

Qui êtes-vous ?
Votre message

Pour créer des paragraphes, laissez simplement des lignes vides.

Lien hypertexte

(Si votre message se réfère à un article publié sur le Web, ou à une page fournissant plus d’informations, vous pouvez indiquer ci-après le titre de la page et son adresse.)

Rappel de la discussion
De Multics à Unix et au logiciel libre
- le 27 juillet 2014

Ma compétition de planeur est terminée, j’ai donc du temps pour d’autres commentaires. Au sujet de ce qui suit :

Nous venons de dire qu’Unix était un système de production de programme, conçu pour satisfaire les programmeurs professionnels et à peu près personne d’autre. Comment expliquer alors qu’il se soit répandu dans beaucoup d’autres domaines, souvent au prix de beaucoup de crises de nerfs de la part d’utilisateurs furieux ? Parce qu’il faut bien dire qu’Unix n’est pas un système confortable pour qui n’est pas disposé à y consacrer la moitié de son temps de travail.

Pire que ça, Unix a été conçu pour satisfaire une personne : Ken Thompson, dont le but était de faire un programme de jeux d’échecs.
Pour ce qui est des crise de nerfs, là encore, il s’agit d’utilisateurs de 2ème ou 3ème génération. A l’époque de mon premier contact avec Unix (6th edition), c’était de loin le plus convivial des systèmes existants. Ses deux principales caractéristiques : interactivité et multi-tache ne se trouvaient simultanément que sur des systèmes beaucoup plus gros et couteux.

Cette notion de convivialité est extrêmement relative et entachée de tas d’a priori. J’ai souvent dit que l’interface graphique initié par la célèbre marque à la pomme (en fait le centre de recherche de Xerox à Palo Alto) et devenu un quasi standard obligatoire de nos jours représente le stade nourrisson de l’interface homme-machine : le nourrisson ne sait pas parler, il montre (pointe) ce qu’il veut et crie (clique) pour l’obtenir. Plus tard il apprend à parler et du coup ses possibilités d’expression s’accroissent infiniment. De même l’utilisateur sérieux d’un système informatique apprend un langage qui lui permet d’exprimer ce qu’il veut faire. La difficulté d’un tel apprentissage est à mon expérience bien plus faible que celle de l’apprentissage de l’anglais par lequel doit passer tout chercheur aujourd’hui.
Pour donner une idée de ce que pouvait être les "convivialités" de différents systèmes à l’époque, l’auteur d’un des articles parus dans le journal des Bell Labs sur le système Unix proposait le test suivant : écrire un programme FORTRAN (quasiment le seul langage de programmation évolué trouvable à peu près sur tous les systèmes de l’époque) dont le résultat soit un programme FORTRAN, compiler et exécuter le premier puis le deuxième programme. La première partie ne présentait pas grande difficulté pour qui connaissait le système sur lequel il voulait le faire, mais la deuxième étape présentait des difficultés quasi insurmontables sur beaucoup de systèmes dans lesquels les fichiers avaient des types et le type d’un fichier "sortie de résultat d’un programme FORTRAN" n’avait rien à voir avec le type "programme source FORTRAN", il fallait passer par un utilitaire de conversion en supposant qu’il en existe un. Je me souviens d’avoir été confronté à un problème voisin quelques annés plus tard, à l’époque où le quasi standard en matière d’ordinateur de prix "abordable" était devenu le VAX de Digital Equipement Corporation. Un laboratoire de la fac d’Orsay avait un tel ordinateur fonctionnant sous le système du constructeur (VMS) et désirait passer sous Unix BSD. Le problème était de transférer les fichiers des utilisateurs d’un système à l’autre. Le responsable du labo m’avait demandé si je pouvais réaliser la chose. Après consultation de la doc disponible (un gros classeur papier parmi une ou plusieurs dizaines d’autre), j’ai abouti à la conclusion que le seul utilitaire sous VMS capable de sauvegarder toute une hiérarchie de fichiers avec toute l’information associée s’appelait "backup", qui créait des "bandes backup" dont le format était décrit sur de nombreuses pages de la doc, car il y avait de nombreux formats de fichiers, pour chacun il fallait trouver comment le convertir en un fichier Unix qui soit vu par ce dernier système à peu près comme il l’était sous VMS. Comme je me doutais que certains formats n’étaient utilisés par aucun utilisateur j’ai fait l’impasse sur ces formats en me contentant d’un message d’erreur "Je ne sais pas convertir ce type de fichier". Je pensais écrire ce jour là un programme à usage unique, mais il a resservi ultérieurement à l’INRIA quand après le crash du vol Ariane 501 l’INRIA a entamé un collaboration avec Arianespace qui fournissait ses données sur des bandes de ce format, ainsi que par Jean Paul Chieze, ingénieur système à l’INRIA dans un équipe graphique, pour des échanges avec des groupes utilisant ce format, il a complété le programme en rajoutant le traitement de types que j’avais ignoré mais dont il avait besoin.

Derniers commentaires

Informatique confidentielle
Merci pour vos précisions à tous les deux, mais je continue à penser que la locution "machine (...)

Les programmes du manuel ISN traduits en Scheme
Oui, votre critique est fondée. Ces programmes sont tous un peu bâtards (au sens propre), (...)

Les programmes du manuel ISN traduits en Scheme
Le programme de résolution du second degré me fait réagir et c’est sûrement dû à une (...)

Analyse de l’algorithme de Fibonacci
> Curieux, ce principe d’avoir un vecteur contenant à l’indice 1, un autre vecteur : (...)

Quand la machine apprend
Merci Pierre-Éric de vos lectures. Certes, Yann Le Cun a réussi, mais pas en France. Ni lui, (...)