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
Amalgame
Emmanuel Saint-James - le 27 juillet 2014

Cher Laurent

Merci pour cet article, très intéressant
et plein de détails importants trop peu connus.
Un passage néanmoins me semble passablement confus.
C’est dans la section "Naissance d’un communauté",
les 3 paragraphes avant "Le schisme".
Tu y amalgames le succès d’Unix, réel, à celui, qui reste à démonter,
de la classe sociale qui en serait l’auteur, paternité d’ailleurs elle aussi
discutable, et plus discutable encore le fait que cette classe sociale
serait aussi méprisée que tu le dis. Et pour terminer, tu opposes ce succès
à l’affirmation d’un échec des "autorités académiques", que tu identifies en
France à 3 personnes, dont seule la première, Arsac, a fait une carrière
académique. Je vais essayer de démêler cet écheveau.

Un peu de matérialisme historique d’abord. Tu n’évoques jamais le fait
que pendant les dix ans mis par Unix pour s’imposer, le prix et les
capacités des ordinateurs ont considérablement changé. Si les "autorités
académiques" faisaient beaucoup de théorie à l’époque, c’est d’abord
parce qu’elles n’avaient pas les moyens de faire autre chose.
C’était même une nécessité économique : Arsac racontait ses journées
perdues à porter ses cartes perforées à l’autre bout de la ville pour
apprendre de l’unique ordinateur disponible au CNRS qu’il manquait un
" ;" à la deuxième ligne, et aux essais suivants que la mémoire avait
été saturée par une poignée d’appels récursifs ! Ca motive quand même
beaucoup pour théoriser l’analyse syntaxique et la transformation
recursif / itératif. Ta critique s’adresse plutôt à la génération qui
a suivi, qui n’avait pas cette excuse ; j’y reviendrai.

Ensuite, il est doublement incohérent d’opposer le succès public d’un
outil d’ingénieur, ici un système d’exploitation, à un travail
théorique, toujours destiné à des spécialistes, ici sur les langages
de programmation. Ce contre quoi Unix a gagné, ce sont les systèmes
d’exploitation spécifiques aux constructeurs d’ordinateurs qui voulaient
garder leur clientèle captive par ce biais. Et cette victoire a de
nouveau une raison historique. Unix est né dans le laboratoire de
recherche d’un opérateur de télécommunications, non ceux des
constructeurs informatiques encore marqués par l’usage des cartes
perforées, d’où a découle ce que Bachelard aurait appelé une rupture
épistémologique, affirmant que le coeur d’un système d’exploitation
n’est pas le fichier de données mais le flux d’informations.
Autrement dit on passe de l’archive statique consultée rarement, au
flux dynamique presque toujours en activité. Qu’une rupture
épistémologique vienne d’outsiders au milieu académique est assez
classique : on a assez souligné qu’Einstein était ingénieur au bureau
des brevets, où des brevets sur des horloges ont nourri son inspiration.

Peut-être veux-tu suggérer que les "milieux académiques" ont cru
bon de réinventer des langages de programmation universels alors que
le besoin était d’inventer le premier système d’exploitation
universel. Mais Arsac s’est bien gardé de proposer un langage, tandis
que Meyer et Ichbiah ont proposé les leurs alors qu’ils étaient
ingénieurs dans une entreprise. On a ici plutôt un clivage assez
fréquent entre un normalien qui analyse le monde, et deux
polytechniciens qui prétendent le transformer autoritairement.
Dans le cas de Meyer, son langage Eiffel est un échec mérité car il
avait trop peu de choses nouvelles à y inclure pour justifier une
telle prétention. Pour Ichbiah, il a fait le travail qu’attendait son
employeur, répondre à un appel d’offres, et relativement bien
puisque’ADA a gagné le concours face à des concurrents très sérieux.
C’est plutôt au commanditaire, l’armée américaine, qu’on peut
reprocher d’avoir demandé un nouveau langage, alors que la bonne
réponse (mais c’est facile à dire des decennies plus tard) aurait été
de définir un sous-ensemble de C où on aurait remplacé son mal fichu
"typedef" par le système de types d’ADA, qui se justifie dans le
secteur où il était destiné car un bug y est dramatique.

Par ailleurs, les universitaires s’intéressaient déjà aux systèmes
d’exploitation, notamment Dijkstra que tu cites. Je ne suis pas sûr
que ce soit eux qui ont inventé la notion de sémaphore, indispensable
à Unix, mais au minimum ils l’ont considérablement améliorée. Quant à
la notion de flux d’entrée et de sortie de processus en Unix, c’est
une transposition directe de la programmation fonctionnelle, à
l’époque sujet fétiche des universitaires (à quelques exceptions dont
Arsac, c’est pour moi sa seule vraie erreur de jugement), il est
probable (ça vaudrait la peine de le vérifier) que les auteurs d’Unix
avait un peu de cette culture. A l’inverse, la communauté de la
programmation fonctionnelle s’est très tôt intéressé à Unix, d’une
part à cause de cette transposition, d’autre part parce que la
programmation dite concurrente qu’il offrait était au départ étrangère
à la programmation fonctionnelle, étendre celle-ci pour inclure
celle-là était un défi intellectuel majeur qui sera relevé d’aboard
inélégament avec la pile-spaghetti, ensuite superbement avec la
capture de continuation en Scheme. Bref, tu opposes deux communautés
qui se sont écoutées que tu ne le prétends.

Reste la question de la pénétration de la culture de l’ingénieur dans
le monde universtaire. De nouveau il faut prendre de la distance
historique. Dans les thèses de physique d’avant-guerre, on trouve des
descriptions d’expérience où le matériel est désigné par le nom de
leur fabricant : les chercheurs de l’époque n’étaient nullement gênés
de faire implicitement de la publicité à des entreprises commerciales.
Cette idéologie qu’une science digne de ce nom ne doit
pas se compromettre avec les objets techniques est en fait un moment
très précis de l’histoire de sciences, celui de l’immédiat
après-guerre où le milieu académique sortait traumatisé de la
collaboration de scientifiques avec les pouvoirs militaires pour en
décupler la puissance destructrice. C’était particulièrement le cas
en France, avec le groupe Boubarki. Ce collectif toujours changeant de
mathématiciens a eu le mérite d’inventer le développement collaboratif
en maths, mais il a eu aussi le tort d’imposer l’idéologie sus-dite,
et à ce titre est coupable de beaucoup de choses, en particulier du
démarrage tardif de l’informatique au pays de Descartes, qui avait
pourtant tous les atouts pour l’inventer. Les premiers laboratoires
publics d’informatique en France se sont inscrits dans cette idéologie
(jusqu’à exclure Arsac de la direction de son labo, coupable de trop
s’intéresser à la programmation que ses successeurs se vantaient de ne
pas maîtriser !) mais cela a disparu avec le départ en retraite de
toute cette génération marquée par cette problématique de
l’après-guerre.

Ce qu’il faut voir c’est que la démocratisation de l’enseignement
supérieur ne se traduit pas seulement par l’arrivée de bacheliers
issus des classes défavorisées sur les bancs des amphis, mais aussi
par leur accès à des postes de chercheur et d’enseignant-chercheurs,
et aussi à des rapports moins inégalitaires entre enseignants et
non-enseignants à l’université, 68 étant passé par là. Les questions
soulevées par les ingénieurs sont donc plus audibles qu’auparavant,
car les milieux sociaux sont moins clivés qu’aux générations
précédentes. Il faut aussi prendre en compte la prise de pouvoir
progressive du manager dans les établissements scientfiques, qui a
remplacé l’évaluation qualitative des laboratoires, par une évaluation
strictement comptable en nombre de publication et de contrats avec des
entreprises, qu’elle qu’en soit les qualités et les buts. Cela ne
pouvait qu’encourager l’acceptation de sujets d’études que la
génération précédente aurait qualifié de pas assez noble.

On peut quand même se poser la question de savoir si aujourd’hui on
n’est pas tombé dans l’excès inverse : les mandarins universitaires ont
empêché la science d’avancer dans certaines directions, mais au moins
ils la faisaient avancer dans d’autres. Les managers d’aujourd’hui
n’ont même pas cette excuse.

Bien à toi.

Amalgame
Laurent Bloch - le 27 juillet 2014

Merci cher Emmanuel pour cette riche contribution. Comme bien tu te doutes, parmi les choses que tu écris je suis d’accord avec certaines et pas avec d’autres, alors je corrigerai certaines erreurs que tu relèves, et répondrai pour certaine points que je maintiens. Notamment, si Ichbiah et Meyer n’étaient pas des universitaires, les équipes avec qui ils travaillaient en comportaient. Bon, plus de détails plus tard ! Amicalement.

Ingénieurs, chercheurs, universitaires
Laurent Bloch - le 27 juillet 2014

Cher Emmanuel,

Tu écris « Tu y amalgames le succès d’Unix, réel, à celui, qui reste à démonter, de la classe sociale qui en serait l’auteur, paternité d’ailleurs elle aussi discutable, et plus discutable encore le fait que cette classe sociale serait aussi méprisée que tu le dis. »

En fait, pour ce qui est du mépris (éventuellement mutuel) entre chercheurs et ingénieurs je te renvoie à un texte sur le sujet. Et quant à l’organisation d’Ancien Régime de l’université française, en société d’ordres et de statuts, j’ai pu vérifier par moi-même lorsque j’y travaillais.

Sémaphores
Robert Ehrlich - le 29 juillet 2014

la notion de sémaphore, indispensable
à Unix

La notion de sémaphore était si peu indispensable à Unix à ses débuts que ses auteurs, tout en connaissant fort probablement son existence, ont soigneusement évité d’y recourir. Les raisons sont probablement le coût en temps d’exécution et en place mémoire que cela aurait représenté. Il faut se rappeler ce qu’était un PDP11, la machine du premier Unix multi-tâche, voir mes commentaires précédents.

Il leur fallait néanmoins un mécanisme d’exclusion mutuelle, pour éviter des modifications incohérentes de structures de données du noyau par plusieurs processus s’exécutant en simultanéité apparente. Toute la ruse de Thompson et Ritchie a été de profiter de ce que cette simultanéité n’était qu’apparente, ces premiers Unix ne s’exécutant que sur des mono-processeurs.
Le principe de base était que le noyau est non-préemptif : un processus exécutant du code en mode kernel ne perd la min au profit d’un autre que volontairement, et s’il décide de le faire alors qu’il a laissé une ou plusieurs structures du noyau dans un état non cohérent, il y laisse un indicateur "booléen", un bit à 1, qui veut dire "personne ne touche à ça à part moi tant que ce bit est à 1"., ce qui sous-entend qu’il est assuré de reprendre la main au moins pour remettre les chose dans l’ordre (conséquence : le "kill" d’un processus ne devient effectif qu’au moment où il tente de retourner en mode user, auparavant il est dans un état dit "zombie" (mort-vivant)). Comme le processus qui positionne ce bit est assuré de ne pas perdre la main entre le moment où il teste ce bit et le moment ou il le positionne, point n’est besoin de mécanisme matériel du type test & set assurant l’indivisibilité des deux opérations, ça s’écrit en C avec les opérateurs usuels.

Reste la question des interruptions qui peuvent éventuellement exécuter du code entre le test et le set, où consulter des structures dans un état incohérent. Il faut donc interdire les interruptions entre le test et le set et aussi bien dans une routine d’interruption qu’ailleurs, tester ce bit d’exclusion avant d’accéder à la structure, tout ceci seulement pour les interruptions qui peuvent accéder à cette structure.

Malgré cette politique non-préemptive le partage du temps équitable entre processus est assuré par le fait que le code que tout processus exécute avant de retourner en mode user teste si entre temps un autre processus n’est pas prêt à l’exécution et plus prioritaire et dans ce cas décide de perdre la main son profit, ces priorités évoluant en fonction du temps consommé par chaque processus, chose gérée par l’interruption d’horloge.

Evidemment tout ce mécanisme tombe à l’eau dès qu’on a plus d’un processeur exécutant le code du noyau. Les premiers Unix multi-processeurs s’en sont sorti en décidant qu’un seul processeur exécutait le code du noyau. Plus tard Linux par exemple a introduit de vrais sémaphores en lieu et place de ce mécanisme, ce qui permet à plusieurs processeurs d’exécuter du code du noyau sans s’emmeler les pinceaux.

Sémaphores
Emmanuel Saint-James - le 29 juillet 2014

Grand merci pour cette précision. J’avoue ma méconnaissance des premiers Unix, dont j’ignorais que c’était des systèmes plus coopératifs que concurrents. Cela dit le concept de sémaphore n’est qu’un parmi d’autres dans les systèmes d’exploitation que les chercheurs ont investigués très tôt : l’ordonnancement, par exemple, relève à la fois du système et la recherche opérationnelle. Il faudrait faire les histoires parallèles des différentes versions des systèmes et des articles de chercheurs sur leurs concepts : mon propos est simplement de dire que dès le début ces deux histoires ne sont certainement pas disjointes..

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, (...)