Résumé

  • Xinu était un système d’exploitation compact mais complet, que les étudiants pouvaient construire par étapes puis démarrer sur des cartes d’expérimentation.
  • À Purdue, le laboratoire automatisait l’attribution d’une carte, le chargement de l’image et l’accès à la console série. Cela rendait le parcours vers un système en marche répétable, sans mesurer ce que les étudiants avaient appris.

Randy Bond se souvient d’un moment précis : au printemps 1984, en dernière année à Purdue, il suivait le cours de systèmes d’exploitation de Doug Comer avec la première édition du livre consacré à Xinu. Des décennies plus tard, il a décrit la construction d’un système de bas en haut comme une expérience décisive pour son travail d’ingénieur logiciel embarqué. C’est le témoignage rétrospectif d’un étudiant, pas une évaluation de toute la classe. Il éclaire néanmoins le pari pédagogique de Comer : un système devient plus intelligible lorsque les étudiants peuvent suivre sa construction, puis démarrer le résultat. Le récit de Purdue conserve ce souvenir ; les ressources du projet Xinu montrent le dispositif qui l’entourait.

La préface du manuel part d’un problème courant : on peut apprendre les services fournis par un système d’exploitation tout en laissant son fonctionnement interne dans une boîte noire. La réponse de Comer n’a pas consisté simplement à réduire le sujet. Il a proposé un système dont les composants se construisent dans une hiérarchie réfléchie, depuis la machine nue, afin que leurs dépendances deviennent visibles. La préface de l’ouvrage décrit la gestion des processus et de la mémoire, la synchronisation, les entrées-sorties indépendantes des périphériques, les pilotes, les protocoles et les systèmes de fichiers comme des éléments d’une même architecture exécutable, plutôt que comme une liste de fonctions.

Xinu était petit, mais Purdue ne le présente ni comme un jouet ni comme une variante de Unix. Le nom signifie « Xinu Is Not Unix » et le site précise que la conception interne diffère. L’affirmation pédagogique est plus circonscrite : un système de taille modeste peut exposer les composants ordinaires d’un système d’exploitation et les abstractions qui les relient. Pour un cours, cela fournit une implémentation unique à examiner. Cela ne démontre ni qu’il n’existe qu’une seule architecture valable, ni qu’un étudiant capable de construire Xinu comprend tous les systèmes commerciaux. La description du projet Purdue en expose à la fois le périmètre et les limites.

Le laboratoire physique faisait du manuel autre chose qu’une suite de schémas et d’extraits de code. Les étudiants utilisaient des postes Linux classiques pour compiler et lier une image. Un parc distinct de machines de test reliait les cartes d’expérimentation à Ethernet, à des dispositifs de redémarrage à distance et à un multiplexeur de ports série. Le logiciel du laboratoire attribuait une carte disponible, y téléchargeait l’image, ouvrait une fenêtre de console et lançait le système. L’étudiant pouvait ainsi passer d’une modification à une image en cours d’exécution sans reconstruire manuellement tout le chemin matériel à chaque essai. La description du laboratoire de Purdue détaille ces étapes.

Cette séparation constitue la véritable surface opérationnelle de l’enseignement. Le poste de travail offrait les outils habituels ; le parc arrière rendait l’exécution physique disponible comme une ressource partagée. Automatiser l’attribution et le téléchargement réduisait les manipulations répétitives, mais n’automatisait pas le raisonnement. Un démarrage réussi montrait qu’une image était parvenue sur une carte et qu’elle s’exécutait. À lui seul, il ne prouvait pas que l’étudiant comprenait l’ordonnancement, la mémoire, les interruptions ou les accès aux périphériques.

C’est précisément à la frontière entre exécution observable et compréhension démontrée que les affirmations doivent rester prudentes.

L’accès au matériel était aussi une contrainte de conception. La préface indiquait que les cartes Galileo et BeagleBone Black retenues coûtaient moins de 50 dollars à l’époque de sa rédaction. La chronologie du projet rapporte ensuite qu’en 2014 le laboratoire a été réaménagé avec 120 cartes Galileo données et quelques BeagleBone Black. Ce sont des données historiques, pas des prix actuels ni un coût publié par étudiant. Les sources ne donnent ni taux d’occupation des cartes, ni temps d’attente, ni taux de panne, ni coût d’assistance. Elles montrent la mise en place d’un laboratoire partagé à faible coût, pas son économie complète.

Le travail était collectif. Comer a écrit le manuel et piloté le système, mais la préface remercie les étudiants diplômés pour les ports et les pilotes, cite Rajas Karandikar et Jim Lembke pour les pilotes Galileo et le système de téléchargement en plusieurs étapes, puis nomme des étudiants qui ont trouvé des défauts et contribué au code. La chronologie de Purdue crédite aussi Dave Stevens d’un travail avec Comer sur une implémentation complète de TCP/IP.

Présenter Xinu comme l’œuvre d’un seul homme effacerait la méthode pédagogique que les sources documentent : des collaborateurs et des étudiants ont fait évoluer le système en travaillant dessus.

La voie de la machine virtuelle est utile, mais elle n’est pas identique à celle des cartes. Purdue indique que la version VirtualBox remplace certains accès mémoire par des opérations adaptées aux entrées-sorties mappées sur ports et utilise un pilote Ethernet différent. Une machine virtuelle réduit la barrière matérielle ; elle change aussi l’interface expérimentée. Tout compte rendu de résultat devrait préciser s’il provient d’une carte physique ou d’un émulateur.

L’héritage défendable est donc précis. Xinu réunissait une implémentation lisible et un parcours répétable du code source au matériel, donnant aux étudiants accès à une plus grande partie du système qu’une simple API. Le témoignage de Bond documente l’effet ressenti par une personne. Les ressources du projet décrivent le code, l’organisation du laboratoire et des usages rapportés ; elles ne prouvent ni des progrès pédagogiques mesurés dans une étude contrôlée ni un recensement indépendant des adoptions ultérieures.

Faire tourner le code rendait la leçon vérifiable ; un journal de démarrage ne devenait pas pour autant une étude de l’apprentissage.

Sources