Résurrection d’UNIX V2 « Beta » de 1972

 (tuhs.org)
2 points par GN⁺ 2025-02-21 | 1 commentaires | Partager sur WhatsApp
  • Une analyse forensique des bandes s1/s2 de DMR a permis de constituer un système UNIX fonctionnel ; s1 est une UNIX INIT DECtape contenant le noyau, et s2 contient la majeure partie des fichiers de distribution
  • Le noyau s1 est le plus ancien noyau UNIX lisible par machine identifié à ce jour ; il se situe entre V1 et V2 et peut exécuter à la fois les a.out V1 et V2
  • La taille du core utilisateur a été portée, comme dans V2, à 16 KiB(8K words), mais la table des syscalls est identique à celle de V1 et du noyau unix-jun72, et n’inclut donc pas les syscalls V2
  • Les conditions de démarrage sont délicates : seul l’émulateur PDP-11/20 d’aap a réussi à démarrer le noyau, tandis que SIMH et Ersatz-11 se bloquent avant l’invite de login
  • L’image disque RF publiée ne contient que les fichiers s1/s2, peut démarrer dans l’émulateur d’aap, et le comportement de init(7) suggère que /usr se trouvait sur le RF

UNIX V2 « Beta » restauré à partir des bandes s1/s2

  • L’analyse forensique des bandes DMR a montré qu’il était possible de créer un système fonctionnel à partir des bandes s1/s2
    • Les DMR tapes sont l’ensemble de bandes qui a été analysé
    • La bande s1 est une UNIX INIT DECtape contenant le noyau
    • La bande s2 contient la majeure partie des fichiers de distribution
  • Le noyau s1 est le plus ancien noyau UNIX lisible par machine identifié à ce jour, et se situe entre V1 et V2
    • Le noyau unix-jun72 non modifié ne prend en charge que les a.out V1
    • Le noyau s1 peut exécuter nativement à la fois les a.out V1 et V2
    • La taille du core utilisateur passe de 8 KiB(4K words) à 16 KiB(8K words)
  • La table des syscalls est identique à celle de V1 et du noyau unix-jun72
    • Elle n’inclut pas les syscalls V2
    • Du point de vue des syscalls, elle est proche de V1 ; mais par la taille du core et la capacité à exécuter les binaires V2, elle présente des caractéristiques de V2, d’où sa qualification de « V2 beta »
  • Le système permet d’exécuter ed, cc et a.out
    • Dans la session d’exemple, un programme hello world! est écrit, compilé et exécuté

Contraintes de démarrage et image disque RF

  • Les environnements capables de démarrer sont limités
    • Seul l’émulateur PDP-11/20 d’aap a réussi à démarrer le noyau
    • SIMH et Ersatz-11 se bloquent avant d’atteindre l’invite de login
  • La procédure d’installation d’origine consistait à démarrer depuis s1, puis à restaurer les fichiers depuis s2
    • L’émulateur d’aap ne prenant pas en charge le TC11, il est difficile d’installer directement depuis les bandes s1/s2
  • La configuration réelle a donc été réalisée en créant indirectement une image disque RF
    • Les fichiers de la bande s1 ont été extraits et placés sur un disque RF vierge
    • Le noyau unix-jun72 a ensuite été installé, puis le démarrage sur RF effectué dans SIMH
    • Les fichiers restants de s2 ont été extraits
    • Enfin, le noyau unix-jun72 a été remplacé par le noyau s1 à l’aide d’un éditeur hexadécimal
  • L’image RF générée ne contient que des fichiers provenant de s1/s2
    • Elle est disponible sur Research-UNIX-V2-Beta
    • Un lien de téléchargement direct est fourni pour s1s2unix_rf.img
    • Cette image démarre dans l’émulateur d’aap, mais pas dans SIMH
  • Le programme init(7) ne monte pas RK sur /usr
    • Ce comportement suggère que /usr était stocké sur le RF

À lire aussi

1 commentaires

 
GN⁺ 2025-02-21
Avis de Hacker News

  • Cela me rappelle une blague entendue lors d’une conférence de Brian Kernighan. Ken Thompson aurait créé un éditeur de texte, un compilateur B et l’ossature de gestion des fichiers d’entrée/sortie en trois semaines, et c’est finalement devenu UNIX
    Le fond de la blague, c’est qu’aujourd’hui nous sommes un peu moins efficaces qu’à l’époque

    • Ken est clairement un programmeur de tout premier plan, et quand quelqu’un comme lui peut se concentrer pendant trois semaines, il peut accomplir énormément de choses
      Si je me souviens bien, sa femme était partie en Angleterre avec les enfants, ce qui lui a laissé la liberté de faire ce qu’il voulait. Bien sûr, il avait déjà beaucoup d’expérience avant même d’écrire le premier UNIX
      Pour un programmeur qui a un projet en tête, ça vaut la peine d’essayer. Partir trois semaines dans une sorte de cabane, loin du travail et de la famille, emporter les livres et documents nécessaires et couper Internet. Si possible, utiliser un téléphone basique, et voir jusqu’où on peut aller
      Cela dit, il faut que ce soit un projet déjà suffisamment mûri, avec même un peu de code déjà écrit. À bien y réfléchir, un projet bas niveau qui dépend très peu de bibliothèques externes est ce qui se prête le mieux à ce genre d’expérience. Si le projet repose sur une pile de bibliothèques tierces, on risque vite d’être bloqué sans Internet au moindre problème ; Ken avait donc aussi choisi le bon type de projet
    • L’interview est ici : https://www.youtube.com/watch?v=EY6q5dv_B-o
      Elle dure une heure et Thompson y raconte beaucoup d’histoires intéressantes. Kernighan joue très bien son rôle en laissant Thompson parler
    • Une blague plus contemporaine dit que Ken Thompson, avec Rob Pike et Robert Griesemer, a conçu Go en attendant la compilation de C / C++
    • Je me demande comment les premiers développeurs d’UNIX ont atteint un tel niveau de productivité
      J’aimerais savoir s’ils travaillaient comme de 9 h à 17 h, ou s’ils mettaient le reste de leur vie de côté et passaient en mode gobelin pour terminer
    • Les premiers 80 % des fonctionnalités d’un projet peuvent vraiment avancer très vite. Surtout quand le sujet est intéressant et que la motivation est forte
      Mais les 20 % restants forment une longue traîne et deviennent généralement une corvée énorme qui finit par casser l’élan

  • Fascinant, au point que même Spock serait impressionné. J’aimerais apprendre à compiler un émulateur PDP-11 sur Mac

    • Compiler l’émulateur est assez facile. Regarde simh. Il est portable, donc il devrait fonctionner presque immédiatement
      Ensuite, ce serait bien d’essayer d’installer la distribution 2.11BSD. Elle est bien documentée et date d’après une bonne partie du chaos des premiers Unix. Après ça, jouer avec RT-11 a aussi été très amusant, et j’ai même écrit quelques petites applis dessus
    • https://opensimh.org/
      Fonctionne aussi très bien sur Apple Silicon
    • On dirait le moment où l’on déterre une relique religieuse avec un détecteur de métaux
    • Trop facile ! Je vais en construire un moi-même avec des portes NAND

  • Vraiment excellent
    C’est la première fois que je vois des gens utiliser ed pour du vrai travail
    Je me demande aussi qui d’autre a dû se débrouiller avec ed. Récemment, j’ai dû me connecter à un très vieux système sans vi, alors j’ai écrit mon propre éditeur ; si quelqu’un a besoin d’un éditeur pour systèmes antiques, il peut me contacter. Il n’est pas très sophistiqué
    Le travail des personnes et des chercheurs qui ont créé ce logiciel est impressionnant, et tout mon respect va aux vrais ingénieurs

    • Je me souviens avoir utilisé dans les années 1960, sur un système temps partagé Honeywell via un Teletype ASR-33, un éditeur proche de ed
      Je ne me souviens plus des détails, mais pour créer un nouveau fichier on le lançait avec make . Quand on tapait make love, il affichait not war avant d’entrer dans l’éditeur
    • Ce n’était pas ed, mais il en était clairement inspiré : je suis assez vieux pour avoir passé des tests d’école de dactylo avec edlin sous MS-DOS 3.3
      Je ne l’ai plus jamais utilisé ensuite, et quelques années plus tard, quand j’ai eu accès à Xenix, je n’ai pas utilisé ed non plus. vi était une alternative bien plus raisonnable
    • En août, j’ai utilisé ed dans Termux sur mon téléphone pour écrire http://canonical.org/~kragen/sw/dev3/justhash.c
      Quelqu’un disait que le clavier virtuel Android était tellement horrible avec vi qu’il utilisait ed sur son téléphone, et comme c’était effectivement vrai, j’ai essayé. Sur téléphone, ed était un peu pire que vi, mais les deux sont mauvais de manières différentes
      Avec HeliBoard, saisir des commandes ed au clavier était bien plus facile qu’avec vi, mais j’ai été plusieurs fois dérouté par l’état du tampon, ce qui ne m’aurait pas embrouillé avec vi. Peut-être que ça s’améliore avec l’entraînement, mais je suis finalement revenu à vi
    • Au milieu des années 90, j’avais un AT&T 3B2 sur lequel il n’y avait que ed, et je l’utilisais avec un terminal DEC VT-102
      ed fonctionne, mais selon les critères modernes ce n’est pas très amusant. Cela dit, comparé à une sortie sur télétype, l’utiliser sur un écran devait être énorme
      Au passage, un 3B2 d’environ 1 MIP pouvait supporter une vingtaine d’utilisateurs simultanés
    • L’un de mes premiers boulots de conseil consistait à écrire un tutoriel ed pour le système Coherent
      J’utilise souvent ed, et je m’en suis même servi hier. J’avais besoin de modifier quelque chose sans effacer l’écran
      Avant cela, j’avais aussi créé un éditeur pour des images de cartes stockées sur disque, mais il était très rudimentaire

  • J’aime bien parcourir de temps en temps la liste de diffusion tuhs. C’est chouette d’y voir des noms comme Ken Thompson, Rob Pike, ainsi que d’autres moins connus mais qui ont participé aux débuts d’UNIX et de l’informatique sur le terrain

  • On dirait de l’archéologie logicielle

    • L’une des nombreuses raisons pour lesquelles je n’aime pas l’ère du SaaS, c’est que ce genre de chose ne se reproduira plus. En 2075, personne ne démarrera un vieux Notion ou Figma pour des recherches ou par nostalgie.
      Comme la culture produite et consommée sur les réseaux sociaux, et bien d’autres aspects de la culture Internet, c’est totalement éphémère et jetable. Pas d’histoire, pas d’avenir.
      Le SaaS n’est pas seulement fermé : en pratique, il est souvent littéralement lié à une installation unique. On pourrait l’archiver et le redémarrer ailleurs, mais y parvenir des années plus tard sans l’équipe d’origine représenterait une tâche bien plus lourde que de démarrer Unix de 1972 dans un émulateur sur un PC moderne.
      Cet Unix avait des manuels, et il avait été conçu pour être installé et exécuté dans plusieurs environnements de distribution. Le SaaS ressemble plutôt à un fourre-tout que seuls ses auteurs peuvent déployer, pas forcément par intention, mais parce qu’il n’existe pas de pression évolutive qui pousse à faire autrement.
      Il est aussi souvent imbriqué en interne avec d’autres SaaS, au point qu’il faudrait peut-être archiver et restaurer l’état complet du cloud, comme s’il s’agissait d’un ordinateur global unique où du logiciel propriétaire est modifié sur place.
    • Ce n’est pas aussi génial que ça en a l’air.

  • Quelqu’un aurait-il une référence expliquant ce que signifient ces permissions de fichiers ? Je peux à peu près deviner, mais je n’ai rien trouvé sur les permissions Unix v2.
    La sortie de ls a l’air familière, mais la partie sdrwrw m’est inconnue.

    • Dans le fil de la liste de diffusion, quelqu’un a mis un lien vers une page de manuel extraite :
      https://gitlab.com/segaloco/v1man/-/blob/master/man1/stat.1?...
      Dans sdrwrw, la première colonne est s ou l, pour small ou large. La deuxième colonne est d, x, u ou -, pour répertoire, exécutable, setuid ou rien. Le reste correspond aux bits de lecture/écriture pour le propriétaire et les non-propriétaires.

  • Hello world en 1328 octets ? Quelle obésité !

    • Ça me rappelle ce compilateur qui, pour plaisanter, mettait de longs poèmes dans tous les binaires. Vous avez déjà entendu parler de magic number, mais là il y avait pour ainsi dire un sonnet magique.
      Je pensais que c’était un des premiers compilateurs Rust, mais je ne retrouve pas de source. C’était peut-être Go.
      Mise à jour : trouvé. « rust-lang/rust#13871: "hello world" contains Lovecraft quotes » https://github.com/rust-lang/rust/issues/13871
    • Mon https://github.com/pts/minilibc686 peut faire un hello world avec printf en moins de 1 KiB sur i386. Un hello world avec write fait moins de 170 octets.
    • Il est temps d’optimiser mon Unix !

  • Super. Est-ce que je peux entrer dans ce portail temporel et vivre dans une réalité alternative ?

    • À l’époque de l’essence au plomb, où la fumée de cigarette allait de soi partout, et où l’amiante était utilisé dans tout ce qu’on pouvait imaginer ? C’est une décennie fascinante, mais la qualité de vie a très probablement énormément augmenté depuis.
    • C’est possible. Il suffit d’acheter un vrai terminal VT. Par exemple quelque chose comme https://www.ebay.com/itm/176698465415?_skw=vt+terminal&itmme...
      Procurez-vous un adaptateur pour le connecter à votre ordinateur, puis lancez le *nix de votre choix dans simh. Comme référence, je recommande https://jstn.tumblr.com/post/8692501831.
      Une fois que tout fonctionne, poussez la machine hôte derrière le bureau, ou ailleurs hors de vue, et vous pourrez vivre comme en 1980.

  • En récupérant des bandes RF, on voit que même de simples fichiers texte révèlent de l’espace tampon que DOS ou les fichiers .iso n’utilisent pas.
    Même avec la distribution 2.11 BSD, le carrelage de base et le gestionnaire de fenêtres doivent être installés sur l’OS natif. C’est pour ça qu’on finit par utiliser KDE ou un gestionnaire de fenêtres X11.