Je termine enfin le récit de mes aventures avec mon vieux PC "Ancient" à base de 486 DX2. Jusqu'ici j'ai pu expérimenter quelques soucis inhérent à cette génération de matériel :
- La pile CMOS avait tout d'abord rendu l'âme bien des années plus tôt, et trouver le bon modèle m'a posé quelques problèmes car ce n'est pas le CR2032 bien standard de nos jours.
- Ensuite, il s'est avéré que 6 Mo de RAM n'étaient pas suffisants pour charger le programme d'installation de Slackware Linux 8.1 datant de 2002. J'ai dû acheter deux barrettes de 8 Mo pour pouvoir passer cette étape avec succès.
- Une fois le programme d'installation chargé, et comme aucun médium autre que la vénérable disquette 3,5" n'est disponible sur la machine, la seule solution pour procéder à la copie des paquets était le montage NFS par le réseau. Et j'ai ainsi réalisé que faire fonctionner une carte réseau ISA "Plug'n'Play" pour Windows n'était pas sans prise de tête sous Linux.
Mais je n'étais pas au bout de mes tribulations...
Si vous avez raté le début :
Les aventures d'un 486 DX2 au XXIème siècle (1ère partie)
Les aventures d'un 486 DX2 au XXIème siècle (2ème partie)
Les aventures d'un 486 DX2 au XXIème siècle (3ème partie)
Les aventures d'un 486 DX2 au XXIème siècle (4ème partie)
X(Free86)
Une fois toute la configuration de base effectuée (réseau, daemons, etc.) je me suis attaqué à ce que je pressentai être un gros morceau : la configuration du serveur X (plus exactement XFree86 version 4.2.0, 2002 oblige), et cela avec le chipset intégré : un Cirrus Logic GD5422-800-D (proche de ce cette carte).
Un essai innocent avec la commande
$ startx
me retourne une erreur, jusque-là rien d'étonnant. Je commence à explorer les fichiers de configuration pour adapter tout ça et obtient "plutôt rapidement" en utilisant le pilote "vesa" ce qui ressemble à un affichage graphique. Pour information, il faut compter environ 20-30 secondes entre le lancement de la commande startx et l'apparition du curseur à l'écran, temps durant lequel on imagine aisément le swap qui turbine à plein régime trahi par le grattement incessant du disque dur.
Vérification faite, la résolution est de 320x200. Sur un écran de 19" tel que j'utilise cela se traduit par un curseur qui a la taille de ma souris, et des boutons qui semblent plus proches de ceux trouvés sur les appareils de la marque Playskool que sur un ordinateur.
(Pour vous faire une idée, affichez la capture d'écran ci-contre en plein écran, en zoomant de sorte qu'elle prenne toute la largeur de celui-ci)
Un autre problème s'impose aussi brutalement : le curseur reste désespérément immobile malgré mes mouvements, seul le clavier semble répondre. Le point positif est qu'il ne s'agit donc pas d'un crash mais simplement d'un mauvais fonctionnement de la souris seule. Sur les deux problèmes, je décide de commencer par la souris : en effet, cela ne sert à rien d'avoir une résolution HD (ha ha) si aucun curseur ne permet l'interaction.
USB et PS/2 sont sur une galère...
Je vérifie la souris sur une autre machine : elle fonctionne. De toute manière, c'est elle que j'utilisais sur Windows 95... Hum. Attends voir, j'ai souvenir d'un problème de souris sur Windows justement depuis que j'ai resuscité cette machine. Mais aucune chance que cela vienne de la souris, non, il n'y a qu'à la regarder : une souris toute neuve, optique, USB évidemment, mais j'y ai mis un adaptateur vers PS/2 pour la rendre compatible... du moins je crois ?
En fait, quand on se renseigne un peu plus sur le fonctionnement du port PS/2 tel qu'il était à l'origine, rien ne permettait de faire fonctionner un périphérique USB avec un simple adaptateur passif comme le mien. En effet, le protocole est bien particulier et ne ressemble en rien à celui utilisé par l'USB. Sur les configurations "récentes" comprenant le protocole USB, le pilote/noyau est simplement capable de s'adapter au périphérique branché et de basculer sur le protocole adéquat.
Mais ici, point de bascule non non. Je n'ai pas poussé mes investigations plus loin mais il semblerait que cela s'explique par le fait que le module noyau pour la gestion de l'USB n'est pas installé sur mon Linux – normal en même temps, pour la machine c'est un protocole encore inexistant. Une souris USB reste donc inconnue et inutilisable. Il faut obligatoirement passer par une vraie souris PS/2 (enfin, peut-être pas "obligatoirement", mais plus aisément). Heureusement, j'ai encore ça dans mon fouillis qui me sert de réserve de matos.
Une fois le changement effectué (après avoir rebooté évidemment, le branchement à chaud restant déconseillé sur ce type de port), voilà mon curseur qui s'anime enfin à l'écran quand le serveur X tourne. On avance !
Une bonne résolution...
Restait donc maintenant à obtenir une définition d'écran plus correcte, ce qui était possible en théorie puisque Windows 95 la proposait : du merveilleux 640x480, voire du 800x600 (mais là sous Windows je restais bloqué en 16 couleurs). J'ai donc commencé à bidouiller les fichiers de configuration, lister les pilotes les plus adaptés pour le chipset vidéo, notre fameux Cirrus Logic GD5422, et les essayer un par un (avec le temps de boire un petit thé entre chaque redémarrage du serveur X...). Après de nombreux essais, je me résigne à rechercher sur Google-est-ton-ami des informations sur ce Mathusalemique matériel et son support sous Linux.
Et voilà que grâce à la machine à remonter le temps qu'est le Web, je tombe sur des archives de "forums" datant de la fin des années 90, plutôt marrantes à parcourir. Il s'agit en fait d'archives de mailing-lists, récupérés par des... chinois ?, mis sous forme de forums et hébergés par leur soin (essayer une URL invalide pour constater que c'est un serveur Microsoft IIS en chinois qui répond).
Mais cette page ne m'en apprendra pas plus. En revanche, et après moultes redirections z'et indirections, je tombe sur une page poussiéreuse au contenu plus que pertinent (et triste) : http://www.xfree86.org/4.2.0/Status9.html. Le chipset CL-GD5422 ne serait tout simplement plus supporté à partir de la version 4.2.0 de XFree86 ! C'est bien ma veine. Inutile donc d'essayer quoi que ce soit de plus en l'état.
Downgrading, please wait...
J'envisage alors la potentielle prise de tête s'il faut que je downgrade XFree86 de la version 4.2.0 vers la version 3.3.6 (dernière version stable de la branche 3.x). Gloups.
Mais c'était sans compter que la Slackware est pleine de ressources, notamment en ce qui concerne les vieux machins dépréciés (troll spotted). En me renseignant un peu, je découvre que le répertoire élégamment nommé "/pasture" du CD de la Slackware (toujours monté via NFS depuis mon serveur) contient quelques packages de précédentes versions stables des logiciels installés automatiquement. Et parmi eux, je vous le donne Luc (non il s'appelle Émile - ah oui) je vous le donne Émile : XFree86 3.3.6 !. Un petit coup d'oeil au README associé et mon écran reflète alors un sourire de joie. Extrait :
These are the X server packages from XFree86 3.3.6. If you have a video card that is not working under XFree86-4.x, you can try installing the appropriate 3.3.6 server on top of your XFree86-4 installation to see if that gets it working. All of these servers will work fine with the newer libraries that are installed with XFree86-4.x.
Mais c'est la fête dites-moi ! D'après ce texte je peux simplement installer les packages de la version 3.3.6 par-dessus ceux de la version 4.2.0 déjà présente. Y'a plus qu'à !
Un petit
# installpkg *.tgz
dans le dossier et quelques minutes de grattements stressants du disque plus tard, l'installation est faite. Je n'ai plus qu'à redémarrer et retenter la configuration du serveur X.
Cette fois, je peux utiliser XF86Setup, un petit utilitaire "graphique" (oui bon, le rendu est simple hein) et simplement suivre le guide pour sélectionner la souris, le clavier, le chipset vidéo, la définition de l'écran et la configuration du moniteur (fréquence). Sur ce dernier point j'y vais un peu au hasard car évidemment les écrans TFT n'étaient pas trop courants à l'époque. Après quelques tentatives infructueuses j'arrive enfin à obtenir un magnifique affichage Hache-Dé en 800x600 et 256 couleurs ! Merveilleux !
C'est le maximum que je pourrai atteindre avec ce matériel car le chipset est équipé de 512 Ko de RAM. Comme le rappelle cette page, la quantité de mémoire équipant le chipset détermine les limites en termes de définition et profondeur de couleur qu'il est possible d'utiliser. Un petit calcul nous apprend qu'avec une profondeur de couleur de 8 bpp (appelée communément "8 bit") nous consommons 800x600x1 (1 car 8 bits = 1 octet) = 480 000 octets ou 480 Ko, soit 94% du total. On ne peut simplement pas trouver une définition supérieure standard qui ne dépasse pas la limite de 512 Ko imposée par le matériel.
À tout hasard, pourrais-je passer en "Haute couleur" (16 bit) en abaissant la définition à 640x480 ?
Réponse : non, car 640x480x2 = 614 400 octets. Il me faudrait pour cela le modèle équipé de 1 Mo de RAM (et qui existe / a existé comme le mentionne ce manuel datant de 1995).
Petit tour sur l'app-store... (ha ha)
J'ai (re)testé un peu tous les environnements de bureau proposés (sauf KDE), mais j'avoue avoir une faiblesse pour WindowMaker(1). C'est surtout un des rares à être suffisamment léger pour être utilisable. J'ai bien sûr essayé Gnome (en version 1.4 ici), mais le bureau n'est chargé qu'après 5 minutes avec un load average qui monte à 6, et un délai de réaction d'au moins 30 secondes à chaque action (ici action = clic pour ouvrir un menu), donc clairement ce n'est pas adapté.
Afin de voir à quoi ressemble le rendu d'une page web contemporaine avec un navigateur de cette époque (et une machine encore plus vieille), je décide de lancer la "suite" Mozilla – par ailleurs en version 1.0 sur cette mouture de la Slackware.
Verdict : la navigation ne va tout simplement pas être possible. Ou alors il faut renommer "navigation" en "traversée de l'Atlantique à la rame, que dis-je, à la cuillère à café". Il aura fallu plus 800 secondes pour lancer l'application et terminer le rendu de la page www.mozilla.com ! Je n'ai pas eu à chronométrer, simplement à lire le temps de génération de la page indiqué dans la barre d'état...
Étrangement par contre la mise en forme est plutôt respectée. J'imagine que le site de Mozilla est plutôt bien construit et reste compatible avec les anciens navigateurs (à condition qu'ils respectent les standards évidemment).
Hum, bon, c'est pas avec ça que je vais avoir une idée plus concrète. Je ferme donc Mozilla et revient (cinq minutes plus tard...) sur le bureau. Je me rappelle alors que j'ai commencé à utiliser Opera sur Windows à peu près à cette époque – grâce à la version 5 obtenue dans le CD vendu avec un magazine – et j'avais été tellement bluffé de la réactivité et des fonctionnalités offertes par ce navigateur que j'en avais immédiatement lâché Internet "Evil" Explorer. Si ça se trouve, je pourrais obtenir un peu le même genre d'effet ici sur Linux. Mais pour cela il faut que je trouve un moyen d'installer – et d'exécuter – une version adaptée à ma configuration...
Pour trouver une archive c'est facile : Opera a eu la bonne idée de conserver l'intégralité de toutes les versions sur un FTP dédié : http://arc.opera.com/pub/opera/linux/505/. À nouveau un petit tour dans la machine à remonter le temps !
Je choisis le fichier opera-5.05_tp1-static_qt-libnpp-0.1.1.x86.tar.gz car c'est la version la plus générique et dont les biblitohèques sont compilées statiquement : en gros c'est un blob avec tout dedans, donc pas de souci de dépendance avec telle ou telle version de telle bibliothèque à prévoir (si tout va bien). Un petit script shell est prévu pour installer l'application de manière didactique, je n'ai qu'à le suivre. Je lance ensuite la commande
$ opera
et quelques... dizaines... de secondes plus tard je retrouve l'interface oubliée d'Opera 5.05 (avec sa petite bannière de pub car il n'était pas encore gratuit !).
Le chargement des pages est tout de suite plus véloce : il faut à présent compter entre 45 et 60 secondes pour des pages simples. Mouais. Fallait s'y attendre.
Verdict final
Mais tout ceci reste bien laborieux, si bien qu'il serait difficile d'imaginer réutiliser une machine pareille aujourd'hui. J'ai également testé rapidement le serveur Apache avec PHP et une petite page simple : on évite le timeout certes, mais la réponse est vraiment très longue à venir. L'utilisation ne serait-ce que du terminal est sujette à des microfreezes pendant lesquels on entend clairement le disque qui subit le swapping, la faute à une quantité de RAM trop faible. Et c'est d'ailleurs ce qui semble être le facteur le plus limitant ici : le débit de la RAM et sa taille. Je pense qu'avec 64 Mo il serait possible d'obtenir une petite machine qui pourrait servir de serveur Web léger (en évitant Apache évidemment) ou de serveur mail.
Mais avec seulement 16 Mo, il n'y a quasiment plus de mémoire libre une fois le système démarré, alors comment imaginer lui demander de faire plus ?
Côté affichage, la configuration souffre de son âge et de son chipset d'entrée de gamme. L'environnement graphique "récent" qu'est WindowMaker, bien qu'extrêmement léger, accuse une lenteur insupportable. Comme la navigation sur le web n'est clairement pas à la portée de la machine, je me suis dit que j'allais au moins tester un traitement de texte simple : Abiword, dans la version fournie avec la Slackware 8.1. Mais là aussi c'est un échec : le texte peine à suivre ma frappe (pourtant souvent laborieuse) et s'affiche avec un fort retard. De toute manière l'interface générale reste elle aussi trop pataude pour être utilisable.
Pas vraiment de surprise donc, il s'agit bien des performances d'une machine du milieu des années 90 sur laquelle on a mis un système d'exploitatoin du début des années 2000. Il ne viendrait à l'idée de personne d'installer Windows XP sur un PC vendu avec Windows 3.1 (l'OS d'origine avant que je n'y mette 95), et pourtant c'est le pari audacieux (et inutile, mais sooo geek) que je me suis lancé. Et au final, malgré le choc générationnel hardware/software, GNU/Linux permet d'éviter l'échec complet et propose une machine – qui bien que très lente – reste stable et parfaitement utilisable en headless ou pour quelques applications graphiques très simplistes. De manière plus hypothétique, on pourrait aussi la proposer à une personne – un enfant pourquoi pas (mais geek forcément) – pour découvrir le C ou d'autres langages bas-niveau et les interactions possibles avec le matériel, plus simples à appréhender sur un PC de cette époque que sur une configuration actuelle.
Reste que j'ai pris beaucoup de plaisir à bidouiller du vieux matos de ce genre et à résoudre tous les problèmes qui se sont posés tout au long de cette expérience, ce qui était bien mon but au départ. Je suis donc complètement satisfait du voyage et espère que ce récit vous aura autant plu à lire que moi à l'écrire.
(1) Dont j'apprends avec stupéfaction que la dernière version est sortie en janvier 2013, incroyable.