David Madore's WebLog: Computer hardware

Puisqu'on m'accuse souvent, et on a en partie raison, de n'utiliser les ordinateurs que pour accumuler les échecs, et de n'en parler que pour râler, je voudrais parler de quelques succès récents, sans doute le signe que j'avais un peu de karma à dépenser.

D'abord, je peux parler de notre liaison ADSL : il y a une dizaine de jours, nous avons commencé à observer des pertes de synchronisation, ou des synchronisations à un débit anormalement bas par rapport à ce que notre ligne fait habituellement, ainsi que des pertes de paquets ou des incapacités à établir la connexion (malgré une synchronisation apparemment réussie). J'ai changé le filtre sans que cela améliore la situation, j'ai contacté le service technique de mon opérateur (Nerim), qui m'a dit qu'ils plaçaient notre ligne sous surveillance. Je commençais à m'inquiéter que les travaux d'à côté ou un idiot dans le central aient abîmé la ligne de cuivre. Je sais, ça ne ressemble pas à une success story jusqu'à présent. Mais en fait, il s'est avéré que c'était juste notre modem, que nous avions changé récemment parce que son alimentation était morte, qui était défectueux : j'ai remis l'ancien avec une alimentation universelle, et depuis, plus aucun problème. (Je sais, la manie en France est d'utiliser des « box » pour les connexions ADSL ou fibre : personnellement, je ne jure que par un bon vieux modem qu'on peut changer sans difficulté si on le soupçonne d'avoir des vapeurs, et qui est bien séparé du routeur que j'administre moi-même.)

Ensuite, je peux parler de l'ordinateur qui est chez mes parents. Là aussi, ça ne commence pas trop bien : quand j'ai changé celui qui est chez moi, j'ai repris l'ancienne carte mère et je l'ai apporté chez mes parents ; je soupçonnais (déjà en août) que celle-ci était mourante, et elle est effectivement morte (à la fin, elle fonctionnait juste quelques dizaines de minutes avant de planter brutalement), mais finalement, elle aura tenu plus longtemps que je le pensais, et elle était vieille de dix ans, ce qui n'est pas si mal. Bref, comme je ne voulais pas rester sur celle que j'avais avant et qui était vraiment vieille, j'ai refait des achats.

J'ai commandé (sur LDLC) une nouvelle carte mère, un nouveau processeur et une nouvelle barrette de mémoire (ECC, bien sûr !). J'ai pris le mème modèle de carte mère (Asus P10S-WS) que j'avais achetée chez moi, malgré les difficultés qu'elle m'avait causée, parce que je sais maintenant que ce modèle fonctionne correctement sous Linux, et avec quels paramètres. (À l'exception du watchdog TCO, mais j'ai maintenant de fortes raisons de penser qu'aucune carte mère Intel récente — c'est-à-dire supportant l'UEFI — n'a un watchdog TCO qui fonctionne. Donc pas de raison de tenir grief à cette carte particulièrement.) Ça me permettra aussi de faire d'éventuels échanges entre les deux. Et j'ai pris un processeur de base, un Core i3-6300 à 3.8GHz de la génération Skylake. (Les Core i3, contrairement aux Core i5 et aux Core i7, supportent la mémoire ECC — au moins celui-ci la supporte. Je ne comprends vraiment pas la logique d'Intel à ce sujet, d'ailleurs, et si quelqu'un peut me l'expliquer ça m'intéresse, mais en tout cas pour l'ECC je n'avais pas le choix, c'était un Core i3 ou un Xeon.)

Eh bien rien de comparable aux soucis de mon précédent montage : j'ai monté tout ça en une grosse demi-heure, et tout a marché parfaitement. J'ai juste eu un petit peu de mal à brancher certains câbles coincés derrière les disques durs que je ne voulais pas dévisser, mais à part ça, aucun souci, même pas une vis qui se perd, même pas une carte ou une barrette mémoire mal insérée. Je pensais que j'aurais des soucis avec l'UEFI mais je me suis rendu compte par accident qu'en fait, la carte mère en question était en fait quand même capable de booter en mode BIOS traditionnel, donc je n'ai rien eu à rerégler ; pas non plus dans Linux, puisque j'avais déjà un Linux tout prêt pour cette carte mère. Je n'étais pas content de devoir changer le clavier et la souris (ceux que j'avais étaient à connectique PS/2) ainsi que le graveur de DVD (à connectique IDE/ATAPI) parce que la carte mère ne supporte plus des connectiques « obsolètes », mais j'ai trouvé chez mes parents un clavier (QWERTY !, les seuls que je supporte) et une souris USB excellents, et j'ai trouvé chez moi un adaptateur IDE↔SATA dont j'ai eu la surprise de constater qu'il marche même pour un graveur de DVD. La seule chose à laquelle j'ai dû renoncer, c'est un scanner SCSI vieux de seize ans, parce que la carte SCSI était à connectique PCI et que ça aussi, c'est obsolète (et je ne vais pas en acheter une PCIe juste pour brancher un périphérique comme ça).

J'ai décidé d'utiliser non pas le chipset graphique intégré au processeur, mais celui d'une carte graphique externe (le premier prix des Radeon, j'en avais une qui traînait) : je craignais aussi un peu que la présence de deux chipsets graphiques perturbât le BIOS ou bien Linux, mais rien du tout, tout ça fonctionne parfaitement.

En plus de ça, ma nouvelle carte mère a un oscillateur d'une qualité excellente : le quartz n'est décalé que de 1 partie par million si j'en crois NTP.

Et au passage chez mes parents j'ai même trouvé un modem ADSL tout neuf qui ne servait pas, dont je n'ai plus aucune idée de comment il est apparu là, mais du coup même si l'alim universelle ne tient pas très longtemps (ce que je crains), j'en ai un de secours.

En revanche, je me rends de plus en plus compte que je devrais vraiment tenir une base de données du matériel informatique dont je dispose, parce que je me perds dans le nombre de choses que j'ai et qui traînent un peu partout chez moi ou chez mes parents, je finis par ne plus savoir ce qui marche et ce qui est cassé, quelle est l'histoire de chaque composante, et ce qu'il faut savoir à son sujet.

Il faut d'abord que je commente le mot bricker dans le titre de cette entrée. C'est un anglicisme (l'anglais est to brick, c'est-à-dire que le nom commun brick a été sauvagement verbé), mais je ne crois pas qu'il existe de mot français : on peut écrire bricker en important le mot anglais, ou bien briquer en reproduisant la même construction qu'en anglais (ce verbe existe déjà en français avec un sens différent — frotter pour faire briller — mais je ne trouve pas que la confusion soit problématique, et à la limite ça peut marcher de façon humoristique). Quelqu'un m'a proposé pétrifier, ce qui est effectivement astucieux pour rendre le sens de ce dont je veux parler ici, et du coup je vais l'utiliser dans la suite.

De quoi s'agit-il ? Je définirais ce mot de la manière suivante : rentre, généralement par accident, un appareil électronique inutilisable (aussi utile qu'une brique, donc), en abîmant non pas le matériel lui-même, mais le logiciel qui sert à démarrer.

Expliquons un peu, pour ceux qui ont besoin de plus de précisions. De nos jours, énormément de gadgets électroniques (en gros, tout ce qui est plus complexe qu'une télécommande) sont, en fait, de petits ordinateurs dédiés, dits aussi « embarqué ». Autrefois, un téléviseur (par exemple), c'était de l'électronique spécialisée, maintenant c'est un ordinateur embarqué qui sait décoder la TNT et parle à l'écran LCD ; il en va de même, par exemple, des voitures (et d'ailleurs ça me fait très peur vu le niveau général catastrophique de la sécurité informatique et vu que les constructeurs n'auront aucune obligation à maintenir ad vitam æternam le logiciel). Énormément d'entre ces gadgets, soit dit en passant, tournent sous Linux (tous les téléphones ou tablettes Android, bien sûr, mais aussi les MachinBox qui servent de modem-routeur ADSL ou fibre, et je soupçonne, beaucoup de télévisions, de magnétoscopes, etc.), vu que Linux est très commode pour avoir rapidement un système standardisé sur un matériel à peu près quelconque. Je pense que Madame Michu serait très étonnée de savoir combien de systèmes Linux elle a chez elle.

Certains appareils (montres, frigos, fours, machines à laver) sont encore dans une phase où coexistent plusieurs versions sur le marché : purement électroniques, les véritables ordinateurs embarqués, et quelque chose d'intermédiaire comme un microcontrôleur. Mais avec l'Internet of Things (également appelé, la catastrophe de sécurité informatique qui va nous fondre dessus), les frigos, fours et machines à laver seront aussi de plus en plus souvent de véritables ordinateurs, capables de parler au réseau (et de se faire attaquer par lui). Ironiquement, maintenant, même les périphérique des ordinateurs sont souvent des ordinateurs eux-mêmes : les disques durs modernes, par exemple, ont un véritable ordinateur à l'intérieur (typiquement un processeur ARM), pour pouvoir mener toutes les choses complexes qu'un disque dur est censé faire (positionner les tête, contrôler les sommes de contrôle sur les données lues, analyser sa propre santé et la rapporter à l'ordinateur hôte, etc.).

L'avantage des ordinateurs par rapport à l'électronique pure (par électronique, je veux dire qu'il n'y a pas de puce généraliste, microprocesseur ou microcontrôleur, même si évidemment les frontières ne sont pas parfaitement bien définies), c'est qu'ils permettent de faire des choses beaucoup plus complexes de façon plus simple, et globalement ils sont plus flexibles. L'inconvénient, le pendant du généralisme, c'est qu'un microprocesseur seul ne sait rien faire : il lui faut un logiciel, un programme, également appelé du « code », pour faire quoi que ce soit, et notamment quoi que ce soit d'utile. Dans le cadre d'un ordinateur embarqué ou de périphériques d'un ordinateur, ce logiciel s'appelle souvent firmware (intermédiaire entre hardware, le matériel, et software, le logiciel sous-entendu de plus haut niveau).

On peut imaginer que ce firmware soit fixé une fois pour toutes : stocké en ROM (mémoire en lecture seule), gravé dans le marbre pour toute la vie de l'appareil. On se rapproche de l'électronique (une fois que l'électronique est câblée, plus moyen de changer). Mais cela signifie qu'en cas de problème, il sera impossible de corriger le bug ou le trou de sécurité. Du coup, ces appareils prévoient souvent un moyen de mettre à jour leur firmware : on utilise souvent le terme de flasher le firmware, parce qu'il est typiquement contenu dans une mémoire persistante appelée mémoire flash. Et c'est là que les ennuis commencent : parce que la mise à jour du firmware est à la fois une réponse à toutes sortes de problèmes (comme des trous de sécurité) et la cause de toutes sortes de problèmes (comme des trous de sécurité ! car si un attaquant modifie le firmware, il prend durablement contrôle de l'appareil, c'est plus grave que si le firmware n'était pas modifiable).

La modification du firmware est elle-même une opération qui nécessite l'éxcution de code, ce faisant partie du firmware, et c'est là qu'on comprend que les ennuis commencent vraiment. Parce que si l'opération échoue pour une raison ou une autre (bug, fausse manip', coupure de courant au mauvais moment) et qu'on se retrouve avec du firmware qui ne marche plus, on n'a plus de moyen de remettre en état le firmware : on se retrouve avec une brique : l'appareil ne marche plus, faute de firmware, et il n'y a pas de moyen, ou en tout cas pas de moyen simple, de remettre le firmware en état.

On peut bien sûr imaginer toutes sortes de façons de régler quand même le problème, et de rendre une machine impossible à pétrifier. Discutons un peu ces différentes approches.

La façon la plus évidente, comme je l'ai dit, c'est que le firmware ne soit pas du tout modifiable. Sur certains appareils (mais ce n'est pas courant), il faut actionner un interrupteur mécanique, ou décaler un jumper, ou quelque chose comme ça, avant de pouvoir flasher le firmware (si on ne le fait pas, la mémoire n'est pas modifiable) : ceci évite au moins les modifications malencontreuses dues à un bug ou une attaque, mais ça n'empêche pas qu'on puisse pétrifier la machine en cas de problème lors d'une mise à jour légitime (l'interrupteur étant donc actionné). Une autre solution consiste à avoir deux versions du firmware sur l'appareil, l'une dans une mémoire flash qu'on peut mettre à jour, l'autre dans une ROM inaltérable (en fait, probablement, une mémoire flash dont les pattes servant à réécrire le contenu n'ont pas été câblées) : un petit interrupteur permet de choisir — au niveau purement électronique — la version utilisée, on choisira normalement la première, mais en cas de problème on pourra démarrer sur la seconde, qui est capable de reflasher la première. Ceci permet bien d'avoir un appareil « impétrifiable » dont le firmware peut cependant être mis à jour. Astucieux. Je crois que ma carte mère a quelque chose du genre (un firmware/BIOS alternatif, non modifiable, du moins j'espère, accessible en appuyant sur un bouton, et qui est simplement capable d'aller lire un fichier sur une clé USB qui doit être branchée sur un port précis, et de reflasher le firmware/BIOS principal avec son contenu), mais les explications du manuel ne sont pas un modèle de clarté donc je ne suis pas sûr.

On peut imaginer d'autres moyens de rendre un appareil impétrifiable. Par exemple, si le firmware est flashable depuis un autre ordinateur, on pourra ranimer la brique tant qu'on dispose d'un ordinateur fonctionnel. Une idée serait d'avoir un firmware contenu dans une simple clé USB : pour le flasher, il suffirait de mettre un fichier différent sur cette clé USB. Malheureusement, la simple opération de lire une clé USB nécessite elle-même du code, donc un firmware, et on a un problème de bootstrap si on veut mettre le firmware sur clé USB (bootstrap fait référence à un épisode où le baron de Münchhausen se sort de l'eau en tirant sur les languettes de ses bottes). Mais on peut contourner ce problème de différentes façons. Par exemple, avoir un firmware zéro qui sait simplement lire un firmware sur clé USB, puis l'exécuter et décider que ce firmware zéro sera gravé en ROM donc impossible à modifier (c'est une solution raisonnable, et elle se rapproche de ce que je raconte ci-dessus à propos de ma carte mère). À défaut de clé USB, le firmware peut être contenu dans une puce détachable et on peut vendre un gadget (USB par exemple) permettant d'en modifier le contenu depuis un autre ordinateur. Ou encore, il peut y avoir un tel gadget intégré dans l'appareil lui-même : si on branche une connexion USB et qu'on allume l'appareil d'une certaine manière (peut-être en appuyant sur un bouton), on pourra flasher le firmware depuis un autre ordinateur, par pure électronique.

Les petits systèmes embarqués que j'utilise comme routeurs chez moi et chez mes parents, des DreamPlugs (ce sont des ordinateurs ARM), ont une petite mémoire flash (NOR) de 2Mo qui suffit à stocker un code de démarrage (bootloader, en l'occurrence U-Boot) capable de charger autre chose par Ethernet, USB ou eSATA, en ce qui me concerne un noyau Linux. On peut reflasher la mémoire NOR en passant par Linux ou depuis le bootloader U-Boot lui-même ; mais si l'opération échoue pour une raison ou une autre et que le DreamPlug est pétrifié ? Alors il faut utiliser une autre approche, qui consiste à prendre le contrôle du processeur et de la mémoire du DreamPlug depuis un autre ordinateur, en passant par une interface JTAG côté DreamPlug (et reliée de l'autre côté à un petit boîtier lui-même relié par USB à l'ordinateur qui contrôle) : de cette manière, on peut utiliser le programme OpenOCD pour mettre un U-Boot frais quelque part dans la mémoire du DreamPlug, démarrer dessus, et s'en servir pour reflasher la mémoire NOR. En théorie, c'est très bien. En pratique, il y a quantité de problèmes : la connexion JTAG n'est pas très stable, parfois elle ne marche pas du tout, parfois il faut réessayer plusieurs fois avant qu'elle marche ; en plus, OpenOCD version ≥0.8.0 ne fonctionne plus avec mon boîtier de contrôle JTAG, bref, ce n'est pas la joie. Mais au moins sur le principe, mes DreamPlugs sont « impétrifiables ». On ne peut pas en dire autant de la plupart des téléphones mobiles.

Beaucoup de fabricants de gadgets électroniques ont essayé l'approche suivante, qui ne sert pas seulement à éviter que le gadget soit pétrifié, mais aussi à ce que le le fabricant garde un contrôle sur le code qui tourne dessus : avant que le firmware accepte de flasher un nouveau firmware, il vérifie que celui-ci est acceptable, généralement au sens où il a été signé (par une signature électronique) par le fabricant. Malheureusement, cette approche est condamnée à l'échec pour toutes sortes de raisons, elle n'empêche pas la pétrification et elle pose toutes sortes de problèmes, ce qui n'empêche pas les fabricants de l'aimer. Une raison pour laquelle cette approche n'empêche pas la pétrification, c'est qu'il n'y a rien de magique dans le firmware de démarrage : s'il est capable de flasher la mémoire persistante, un autre bout de code en est aussi capable, donc dès que l'appareil présente un trou de sécurité quelque part (i.e., toujours), l'attaquant risque de pouvoir s'en servir pour reflasher le firmware, et l'approche choisie rend alors quasiment impossible de remettre les choses en état. (The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair. — Douglas Adams, Mostly Harmless) Une autre raison qui fait que l'approche ne marche pas, c'est que la crypto est souvent mauvaise, par exemple au lieu d'utiliser une signature à clé publique, ce qui est possiblement lourd sur un appareil embarqué, on va parfois utiliser un MAC, dont la clé (symétrique) est alors forcément contenue dans le firmware, et qui va donc forcément fuiter. Encore une autre raison est qu'il y a un intervalle de temps entre le moment où le firmware vérifie la signature et le moment où il se reflashe, et il est parfois possible d'exploiter astucieusement cet intervalle pour changer le contenu sous ses pieds (on lui fait croire que la signature est bonne en vérifiant un « bon » nouveau firmware, mais au moment où il flashe la mémoire, c'est autre chose qui se présente). Toutes ces attaques sont menées soit par des attaquants malicieux qui veulent prendre le contrôle de l'appareil à l'insu de son propriétaire, soit par les propriétaires eux-mêmes qui veulent prendre le contrôle de leur propre gadget dont le fabricant essaie de limiter l'usage. Dans les deux cas, la pétrification est un résultat accidentel, mais qui se produit néanmoins dans une certaine proportion des cas.

Pourquoi les fabricants ont-ils si souvent recours à la méthode « vérification du firmware avant de le flasher » (dont je viens de parler) si elle ne marche pas vraiment ? Parce que cette méthode leur garantit — dans la mesure où elle marche, tant qu'elle marche — un certain contrôle sur l'appareil, à l'encontre de son propriétaire/utilisateur. On pourra l'empêcher d'utiliser cet appareil pour autre chose que ce pour quoi il a été prévu, et ce peut être le départ d'une chaîne de sécurité qui interdit certaines choses à l'utilisateur (qui, même s'il est censé être propriétaire de l'appareil, ne l'est alors jamais vraiment), par exemple de copier certaines données dans un sens ou dans l'autre. A contrario, certains des dispositifs qui empêchent la pétrification empêchent le fabricant de se réserver ce contrôle sur l'appareil.

Toujours est-il qu'il existe bien des moyens pour rendre un appareil impétrifiable. Je trouve que cela devrait être une obligation du fabricant de s'assurer qu'un de ces moyens existe (par exemple : si l'appareil est pétrifié, le fabricant aurait l'obligation légale de le rembourser au prix du neuf — une telle mesure augmenterait énormément la motivation à mettre en place des moyens pour éviter cet écueil). Un autre problème est qu'il n'est pas toujours évident de savoir ce qu'il en est, avant d'acheter l'appareil, ou même une fois qu'on l'a. Est-ce que mon téléphone Nexus 5 est pétrifiable, par exemple ? Je ne sais pas vraiment, je pense que oui, mais je n'ai pas franchement envie d'essayer pour vérifier ma sécurité de ce point de vue-là.

Je raconte tout ça parce que j'ai récemment mis à jour le noyau sur mes routeurs DreamPlugs (j'étais coincé depuis une éternité sur la branche 3.2.x du noyau Linux, avec toute une série de patchs, et pour la quitter j'ai dû mettre à jour U-Boot pour pouvoir passer au noyau un device tree, et avant de faire tout ça j'ai dû réapprendre la manière de réparer les choses en cas de pétrification accidentelle — dont je ne pouvais pas négliger les risques, même si au final tout s'est bien passé ; ceux qui veulent en savoir plus peuvent consulter cette page, récemment mise à jour, où je raconte les détails). J'envisage d'acheter d'autres gadgets pour remplacer ces DreamPlugs, par exemple ce truc-là, et une des choses que je cherche systématiquement à savoir c'est qu'elle garantie d'impétrificabilité(?) j'aurai (sur le produit précis que je viens de mentionner, il semble que ce soit bon, mais c'est rarement parfaitement clair).

Comme je consacre l'essentiel de mes entrées de blog parlant de matériel informatique à dire à quel point tout est mal fait et pourri et impossible à trouver et cher et nul, bref, à me plaindre, je vais raconter pour une fois que je suis content.

Comme je l'ai raconté récemment, j'ai un problème avec le watchdog matériel de ma nouvelle carte mère (ou plutôt avec le BIOS), le composant qui est censé redémarrer l'ordinateur automatiquement en cas de plantage : le support technique d'Asus est prévenu, on verra s'il en ressort quelque chose, mais en attendant, ou à défaut, histoire de pouvoir redémarrer l'ordinateur à distance en cas de besoin, j'ai acheté une multiprise commandable par USB, la EnerGenie EG-PMS2. J'avais entendu dire qu'elle était utilisable sous Linux, et je peux confirmer que c'est le cas, et le programme qui le fait (sispmctl) est plutôt commode. Je n'ai pas encore mis la multiprise en place (dans la position où elle servira), mais je peux confirmer qu'elle fonctionne.

C'est une multiprise à 6 prises (numérotées de 0 à 5), protégée contre les surtensions (ce qui n'est pas plus mal), et donc quatre des six prises (les 1 à 4) sont programmables, et peuvent être allumées ou éteintes par la connexion USB. (Il y a aussi un bouton mécanique qui permet de tout couper, et une fois que tout est coupé, de tout réinitialiser sur la position marche.) L'allumage ou l'extinction des prises semble fonctionner par un relai électromécanique — enfin, je n'y connais rien, mais il y a un « clic » audible quand une prise passe de l'état allumé à l'état éteint ou vice versa.

Ce qui est particulièrement agréable, c'est que la multiprise a un petit programmateur : on peut lui envoyer des commandes comme éteindre la prise 3 dans 1 minute, et la rallumer 2 minutes après (sispmctl -A 3 --Aafter 1 --Ado off --Aafter 2 --Ado on ; la granularité, au moins au niveau du programme sispmctl, semble être la minute). Une fois que le programmateur a reçu les commandes, celles-ci ne nécessitent ensuite plus d'intervention de l'ordinateur contrôleur, ni que la connexion USB subsiste.

Ajout : Si on a un ordinateur non-Intel (par exemple mes DreamPlugs ARM), il faudra prendre garde au fait que la version de sispmctl packagée par Debian comporte un bug causant un comportement bizarre (au moins dans l'affichage de la date, peut-être plus) sur à peu près toute architecture non-Intel. Voir ce bug-report où je fournis un patch.

Du coup, même sans l'aide d'un autre ordinateur, cette multiprise peut servir de watchdog primitif : il suffit qu'un programme s'exécute toutes les minutes et envoie à la prise les commandes annuler toutes les commandes précédentes, et, dans cinq minutes, éteindre la prise numéro tant, puis la rallumer une minute après : tant que l'ordinateur ne plante pas, la commande sera sans cesse annulée et reportée d'une minute, mais s'il plante, la commande s'exécutera cinq minutes plus tard, et éteindra l'ordinateur pour une minute. (Les cinq minutes de délai servent à ce que, si l'ordinateur redémarre inopinément, indépendamment de l'action de la prise, il ait le temps de redémarrer complètement et de relancer le programme qui annulera la commande d'extinction. Ce n'est pas parfait, mais c'est raisonnable.) Ceci fournit donc bien la fonctionnalité d'un watchdog, et fonctionnera sur essentiellement n'importe quel ordinateur (sans batterie autonome, bien sûr : sur un portable, ça ne marchera pas, mais bon, un watchdog est rarement utile sur un portable). Je ne sais pas si je procéderai de la sorte, mais c'est agréable, au moins, de savoir que c'est possible.

Plus généralement, je suis sûr que ce genre de gadget peut trouver une grande utilité en domotique, donc je pense que ça peut intéresser des gens.

La prise existe aussi en version Ethernet : le protocole a l'air assez simple, ça a l'avantage de permettre de contrôler la prise depuis plusieurs ordinateurs plutôt qu'un seul, mais je n'aime pas trop l'idée qu'il y ait un serveur HTTP dans ma multiprise (j'aurais préféré une interface à bien plus bas niveau, où on doit envoyer un paquet à une certaine adresse MAC, sans empiler IP, TCP et HTTP dessus). Enfin, il y a une version wifi, mais là je trouve que ça devient vraiment n'importe quoi.

Mise à jour : La multiprise en question est morte tout à l'heure (2018-07-24T22:20+02:00), juste quand je venais de rentrer de vacances (il y a sans doute un lien, mais je ne vois pas quoi ; peut-être parce que j'ai tiré du courant ailleurs sur le réseau électrique de l'appartement) : elle a d'abord désalimenté deux ou trois des cinq prises, dont la lumière témoin était devenue très faible, et quand j'ai donné l'ordre de les couper (avec l'intention de les rallumer après pour voir si ça remarcherait), tout a complètement sauté. Je trouve que « même pas deux ans » (certes à fonctionner quasiment 24h/24 et 7j/7), ce n'est pas franchement terrible, comme bilan, donc je retire le bien que j'en ai dit.

J'aime bien avoir à disposition de ma main droite, quand j'utilise mon ordinateur, à la fois une souris et une trackball. (S'il y a des gens qui ignorent ce que c'est, une trackball est une souris en quelque sorte inversée : on tourne avec les doigts une grosse boule pour déplacer le curseur.) C'est que ma dextérité n'est pas tout à fait la même avec les deux, et je les utilise alternativement, selon mes besoins. (Les deux commandent le même curseur sur l'écran : il est aussi possible de configurer X11 pour afficher deux curseurs différents, mais je trouve ça plus confusant qu'autre chose.) Le principal avantage de la trackball, c'est qu'une fois posée quelque part, elle ne bouge pas, et la mémoire gestuelle arrive beaucoup mieux à la retrouver qu'une souris qui, par définition, change tout le temps d'endroit.

Malheureusement, ma trackball vient de casser. Ou plutôt, la molette de défilement qui était dessus vient de cesser de fonctionner, mais du coup je me retrouvais sans arrêt à essayer de défiler avec la trackball, à me rendre compte que ça ne marche pas, et à passer à la souris, ce qui est encore pire que de ne pas avoir de trackball du tout.

Du coup, je voudrais la remplacer. Mais ce n'est pas si facile. Idéalement, j'aimerais exactement le même produit : c'était une Logitech Trackman Wheel Optical (couleur silver, mais ça je n'y tiens pas des masses). Ce produit n'est plus vendu par Logitech (j'ai déjà dû râler plusieurs fois contre les produits qui cessent d'être disponibles et dont on ne sait jamais pourquoi ni s'ils reviendront un jour). On le trouve certes sur Amazon.fr, mais au prix totalement délirant de 530€ (ou 120€ pour un exemplaire d'occasion), ce qui est quand même hallucinant — et le signe que Logitech devrait peut-être reconsidérer sa décision de ne plus le produire.

À défaut, qu'est-ce que je peux acheter ? Logitech a un produit appelé TrackMan Marble, mais il a l'air de ne pas avoir de molette, et l'utilité de remplacer une trackball dont la molette est cassée par une trackball qui n'a pas de molette est un peu incertain. (Ceci dit, elle a un certain nombre de boutons, et je peux évidemment configurer deux des boutons latéraux pour faire un défilement ; mais je ne sais pas si c'est une bonne idée.) Sinon, il y a la Wireless Trackball M570 dont le design est quasi identique à ma trackball qui s'est cassée, mais elle souffre d'un énorme défaut : elle est sans fil.

Je n'ai jamais compris la manie de la technologie sans fil. Avoir un clavier ou une souris sans fil, ça veut dire qu'il doit avoir ses propres batteries, qu'il va falloir changer régulièrement, et ça veut dire aussi qu'on va avoir des problèmes de connexion initiale (convaincre le truc sans fil de commencer à parler à son récepteur), de perte de connexion, d'interférences (si plusieurs personnes utilisent le même modèle dans la même pièce) ; et évidemment, si on est modérément parano, on se dit que ça signifie aussi que tous les voisins savent exactement[#] ce qu'on fait avec le clavier ou la souris (franchement, taper un mot de passe, ou cliquer sur un code secret, avec un périphérique sans fil, c'est très con), ou, pire, peuvent en prendre contrôle à volonté. À la limite, une souris sans fil, je conçois un peu l'intérêt, vu qu'une souris ça bouge beaucoup. Un clavier, en faisant un effort, j'imagine aussi (on peut le mettre sur les genoux, c'est peut-être pratique). Mais une trackball ??? Tout l'intérêt de la trackball, c'est de la garder au même endroit !

[#] (Ajout) Bien sûr, il est possible que les choses soient bien faites et qu'il y ait de la crypto correcte. En l'occurrence, le mieux serait que chaque couple clavier-ou-souris + dongle récepteur vienne avec une clé symétrique — par exemple AES — préinstallée et impossible à changer, et qu'ils communiquent avec cette clé. Ceci impliquerait aussi, du coup, que si le dongle casse, il n'y a plus qu'à jeter l'autre partie puisque rien ne pourrait communiquer avec. Mais connaissant la tendance impressionnante de l'industrie à mal faire sa crypto, je crains le pire. Le document qu'on trouve ici ne dit rien de clair, et ne suggère rien de bon (manifestement, la clé commune n'est pas préenregistrée dans les deux moitiés ; dans le meilleur des cas, on peut espérer qu'elle soit négociée par Diffie-Hellman, ce qui ne présenterait « que » un risque d'attaque man-in-the-middle lors de l'association : mais je soupçonne que la vérité est encore plus pourrie que ça, et que l'association est passivement espionnable). De toute façon, le fait que Logitech ne documente pas clairement son protocole oblige, selon les standards en vigueur en cryptographie, à considérer qu'il est troué.

Bon, alors rien ne m'oblige à rester chez Logitech. J'aime bien le design de leurs produits, mais je n'y suis pas sentimentalement attaché. Mais en cherchant chez d'autres fabricants, je ne trouve pas vraiment mieux. Keningston fait plusieurs trackballs, dont certaines avec fil, mais soit elles n'ont pas de molette, soit elles remplacent la molette par une « roulette » de défilement, en couronne autour de la trackball, et cette idée me laisse assez perplexe. En plus de ça, j'ai besoin d'une trackball trois boutons (ou à molette cliquable), vu que j'utilise énormément le bouton du milieu pour le copier-coller. Le plus proche de ce que je veux semble être la Kensington Expert Mouse Optical, qui a strictement plus que de boutons et qui a une roulette de défilemnt, mais la disposition des boutons me semble malheureuse (il n'y a pas de bouton « du milieu »), il doit être difficile de défiler sans cliquer par accident, et le prix est quand même élevé.

Finalement, je vais peut-être prendre ce produit par Sanwa (expédié depuis le Japon !), même si ça a l'air d'être de la camelote : le problème, là, est que je n'ai pas de certitude que la molette soit cliquable (pour pouvoir servir de bouton du milieu).

Je raconte tout ça un peu parce que dès que je parle de problèmes informatiques j'ai droit à un florilège de commentaires me racontant que c'est parce que je m'y prends mal (je devrais ne pas utiliser Linux, je devrais commander un ordinateur pré-assemblé, je devrais ceci, je devrais cela), j'ai déjà expliqué le problème avec ce genre de choses. Du coup, je me demande un peu ce qu'on va me dire cette fois-ci : quelqu'un va-t-il dénicher une trackball filaire avec molette et trois boutons (ou deux boutons + molette clickable), ou bien va-t-on m'expliquer que j'ai tort de vouloir quelque chose comme ça ?

Une tragédie en cinq actes (qui respecte l'unité de lieu — l'appartement de Ruxor et du pousinet — et d'action — beaucoup d'énervement —, mais certainement pas de temps) :

Acte I. Présentation du nouvel ordinateur

(Scène 1.) Lundi 29 août, j'ai reçu les trois quarts des pièces de mon nouvel ordinateur (la carte mère, la mémoire, et l'alimentation).

(Scène 2.) Mardi 30, j'ai reçu le quatrième quart (le processeur). J'ai ressorti de ma cave un ordinateur qui y traînait, pour en récupérer le boîtier, et j'ai commencé à monter le tout. Mais les difficultés qu'on rencontre ne sont pas toujours celles qu'on croit : j'ai perdu beaucoup de temps, par exemple, parce que je n'avais que six des neuf vis (je ne sais pas comment appeler ça au juste : ce sont des choses qui sont une vis d'un côté et un écrou — enfin trou à vis — de l'autre) qui servent à relier la carte mère à la plaque arrière du boîtier, et il me fallait donc trouver une solution. Finalement, mon poussinet m'a trouvé les trois vis manquantes.

(Scène 3.) Ensuite, j'ai dû comprendre pourquoi la machine ne bootait pas : elle émettait une série de bips (et montrait un code sur son petit panneau lumineux interne) signifiant qu'elle ne trouvait pas de carte graphique. De fait, je n'avais pas mis de carte graphique, mais je pensais que cette carte mère avait un chipset graphique basique[#] intégré puisqu'elle avait des sorties VGA, DVI et HDMI : la vérité est simplement que cette carte mère est prévue pour accepter les processeurs ayant un coprocesseur graphique intégré (ce qui n'est pas le cas du Xeon E3-1230v5 que j'ai acheté). (Scène 4.) Ce malentendu dissipé (ce qui m'a pris un certain temps, quand même), la machine démarre correctement sur une Ubuntu live.

[#] Ce qui ferait sens pour une carte mère destinée à un serveur (lequel a rarement besoin de quelque chose de très performant en la matière, et un chipset graphique intégré sur la carte mère conviendra donc).

Acte II. De petites complications apparaissent

Mon projet était le suivant : monter une configuration minimale, dans le boîtier que j'ai sorti de ma cave, avec ma nouvelle carte mère (plus processeur et mémoire), et un disque dur de récupération, le temps de vérifier que tout fonctionne, et de préparer une configuration de noyau Linux qui marche bien sur ce matériel, et seulement ensuite déplacer les disques (que je garde) vers ce boîtier. Mon poussinet me dit que mon idée était idiote, que j'aurais dû monter directement la nouvelle carte mère dans le boîtier que j'utilisais déjà (et qui contenait les disques, donc), et régler les problèmes au fur et à mesure qu'ils apparaissaient. Mais je savais que ça pouvait être long, et je préférais ne pas me passer d'ordinateur pendant ce temps.

Bref, mardi 30 au soir, j'avais cette configuration minimale qui marchait : comme expliqué à l'acte I, j'avais dû y mettre une carte graphique elle aussi de récupération. Pour afficher la sortie sur ma télé (faute d'autre écran d'ordinateur qui marche), j'avais aussi dû acheter un adaptateur DVI→HDMI. (Scène 1.) Seulement, mercredi 31, je me suis rendu compte que le ventilateur de cette carte graphique de récupération ne tournait pas, et qu'elle surchauffait : j'ai dû acheter une carte graphique premier prix (30€ environ). Heureusement, ce n'est pas encore complètement impossible d'acheter du matériel informatique à Paris, mais j'ai quand même perdu un peu de temps avec ça (et mon adpatateur DVI→HDMI ne me servait finalement à rien, vu que la carte graphique en question a une sortie HDMI contrairement à celle qui traînait dans ma cave).

(Scènes 2 et 3.) Jeudi 1er septembre et samedi 3 (vendredi, j'avais vraiment autre chose à faire), je me suis occupé de préparer mes disques durs à pouvoir démarrer en mode UEFI (parce que la nouvelle carte mère n'a pas de BIOS traditionnel) ; ceci implique de changer le type de table des partitions (vers GPT). J'ai surtout passé mon temps à comprendre ce que tout ceci signifie, et à mettre au point un plan[#2] pour avoir un système qui peut démarrer, indifféremment, sur n'importe quel disque, que ce soit en mode BIOS traditionnel ou en mode UEFI.

Mais là aussi, les difficultés ne sont pas toujours celles qu'on prévoit : j'ai passé un temps fou à comprendre, par exemple, pourquoi la Ubuntu live, que j'utilisais sur mon (ancien) ordinateur pour faire les manipulations, ne voyait[#3] pas mon disque externe (non concerné par les manipulations, mais sur lequel j'avais stocké des données destinées à les aider).

(Scène 4.) En parallèle de tout ça, je peaufine une configuration de noyau Linux prête à tourner proprement sur la nouvelle machine (et qui continue aussi à tourner sur l'ancienne).

[#2] Pour ceux qui veulent plus de détails : j'ai à la fois un Grub dans le MBR et une partition de type 21686148-6449-6e6f-744e-656564454649 (qui sert à démarrer en mode traditionnel), et un autre dans une partition EFI que j'ai créée après être passage en GPT. Une difficulté était que j'utilisais un vieux Grub, qui ne comprend pas les partitions GPT, donc j'ai dû changer sa version en même temps (et comprendre comment le nouveau fonctionne). Par ailleurs, il est heureux que j'aie l'habitude de laisser plein de place inoccupé entre mes partitions, et au début et à la fin du disque, parce que la création de la table des partitions GPT, et aussi de la partition spéciale pour Grub, ont utilisé une partie de cet espace. J'ai donc évité d'avoir à faire des déplacements sur quelques téra-octets de donnés.

[#3] La solution consistait à ajouter modprobe.blacklist=pata_marvell ahci.marvell_enable=1 dans la ligne de commande du noyau Linux, le genre de choses qui font que les non-linuxiens se moquent des linuxiens et de leurs incantations arcanes. J'avais dû trouver ça autrefois quand j'avais commencé à faire fonctionner cette carte mère, mais j'avais complètement oublié depuis, et la réponse était cachée dans la configuration de mon noyau. Non franchement, je me demande pourquoi le module ahci a une option marvell_enable dont le défaut est à 0 : il faut lui dire explicitement de faire fonctionner ce chipset particulier, c'est un peu absurde (il est vrai que ce chipset a cette bizarrerie qu'il peut gérer soit un port SATA soit un port PATA, mais pas les deux à la fois, donc si on active le SATA, ça désactive le PATA et vice versa ; dans mon cas, cependant, le port PATA n'existe même pas, tout ceci est un reliquat d'une époque un peu ancienne).

Acte III. Le coup de tonnerre

(Scène 1.) Nous arrivons donc le dimanche 4 : je vérifie que tout est prêt au niveau logiciel (je supprime, par exemple, dans la configuration du routeur tout ce qui fixe l'adresse MAC de mon PC) ; je vais profiter d'une absence du poussinet (donc d'une possibilité d'étaler mon matériel informatique dans tout le salon) pour déplacer les disques durs.

(Scène 2.) Je sors les disques de l'ancienne machine. L'opération est un peu longue et compliquée (environ une heure), parce qu'il y en a quatre, et surtout parce qu'il y en a un qui est dans un berceau (pour le mettre sur un emplacement 5″¼ et ainsi gagner de l'espace), et pour le faire sortir du boîtier sans taper dans quelque chose, il faut démonter les barrettes de RAM, déconnecter l'alimentation, et jouer à chercher le chemin qui passe sans taper dans quelque chose d'important.

(Scène 3.) Je refais l'opération à l'envers pour monter les disques dans le nouveau boîtier. De nouveau environ une heure passe.

(Scène 4.) Enfin, tout est prêt. J'appuie sur le bouton d'alimentation.

Rien ne se passe.

Je me dis que j'ai dû défaire les connexions entre le bouton et la carte mère en montant les disques. Je vérifie. Pas d'amélioration. Bon, la carte mère a un bouton d'alimentation directement sur la carte (c'est une excellent idée, soit dit en passant, et je félicite Asus de l'avoir eue). J'appuie dessus. Pas mieux.

(Scène 5.) Je commence à paniquer.

C'est peut-être l'alimentation qui est morte : après tout, il ne se passe rien, pas un ventilo qui tourne, même pas celui de l'alim elle-même. (Il y a des LEDs sur la carte mère qui s'allument quand on branche l'alim, mais rien ne change quand on appuie sur le bouton d'alimentation.) Je vérifie avec l'ancienne carte mère et l'ancienne alim : la nouvelle alim parvient à démarrer l'ancienne carte mère, mais l'ancienne alim ne parvient pas non plus à démarrer la nouvelle carte mère. C'est donc bien la carte mère qui est morte.

La carte mère que j'ai reçu il y a moins d'une semaine est donc morte !

(Scène 6.) Dépité, je mets l'ancienne carte mère dans le boîtier où j'ai transféré les disques. Heureusement, elle n'a pas été abîmée par toutes ces opérations. Il n'y a que la pile CMOS qui est morte, rien de grave. (Bilan de la journée : j'ai simplement déplacé tout le contenu de mon ordinateur d'un boîtier à un autre, pour rien.)

Entracte

Qu'est-ce qui a bien pu se passer pour que cette carte mère meure ? Je n'en sais rien. Je sais à ce stade que c'est forcément la carte mère (si c'était le processeur, les ventilateurs au moins démarreraient ; si c'était la mémoire, il y aurait une série de bips ; pour que rien ne se passe, c'est forcément la carte mère qui est morte — peut-être un condensateur défectueux ou abîmé).

Une possibilité : cette carte mère était défectueuse, elle n'aura tenu que deux ou trois allumages (après tout, je ne l'ai que très peu allumée et éteinte, un défaut peut ne pas se manifester tout de suite). Une autre : je l'ai cassée sans m'en rendre compte en montant les disques. Ça pourrait venir d'un choc électrostatique ou d'un choc mécanique. Mais je ne me suis aperçu de rien, mes observations attentives ne m'ont pas permis de trouver le moindre composant d'apparence suspecte, et un choc électrostatique aurait eu plus de chances d'endommager la mémoire (or je sais qu'elle ne l'a pas été).

Acte IV. Vers un dénouement ?

(Scène 1.) Je commande une nouvelle nouvelle carte mère, identique, et je prépare le retour de celle qui est cassée (vus les délais, il semble que les conditions d'Amazon me permettent d'obtenir un remboursement, et je n'ai certainement pas envie d'attendre un retour). Cette fois avec livraison express.

(Scène 2.) Nous sommes maintenant mercredi 7 septembre. Je reçois la (nouvelle nouvelle) carte mère. Je déplace le processeur dessus. Doute : que faut-il faire pour la pâte thermique ? Pour l'installation initiale, le radiateur fourni par Intel venait avec de la pâte thermique préappliquée. Forcément, cette pâte thermique a été chauffée et s'est dispersée. Quand je retire le radiateur pour déplacer le processeur, avant de le remettre en place, est-ce que je dois réappliquer de la pâte thermique ? réétaler celle qui est déjà là ? J'ai choisi d'en rajouter un petit peu, et j'ai passé un temps fou à essayer de faire un niveau bien plat et mince, mais je crois que j'ai quand même un moins bon contact thermique maintenant que lors de la première installation.

(Scène 3.) Je sors l'ancienne carte mère du boîtier, je mets la nouvelle (nouvelle) à la place. Moralité : mon poussinet avait sans doute raison, c'est plus facile et moins risqué de changer une carte mère que de changer quatre disques.

(Scène 4.) Mercredi soir, l'ordinateur démarre correctement sur une Ubuntu live (comme à la fin de l'acte I, quoi…), mais toujours pas sur mes anciens disques, malgré le noyau spécialement prévu pour. Ou plus exactement, elle démarre, mais je n'ai ni clavier, ni souris, ni réseau. J'ai fini par comprendre qu'il fallait charger le module xhci-pci (ceci expliquait que l'USB ne fonctionnait pas), et que j'avais branché le câble Ethernet dans la mauvaise prise réseau. Rien de compliqué à résoudre, mais trouver le problème exact n'a pas été facile (quand on a un ordinateur qui démarre sans périphérique d'entrée et qu'on ne peut débugguer qu'en modifiant les scripts de démarrage, ça prend forcément un certain temps).

(Scène 5.) Enfin, tout semble marcher. La fin de l'histoire ?

Roulement de tambour…

Acte V. Happy end ou pas ?

(Scène 1.) Mon nouvel ordinateur marche, au moins dans les grandes lignes. (Et avoir 32Go de mémoire au lieu de 8Go rend certaines choses beaucoup plus confortables, c'est incontestable.)

Il est maintenant temps de vérifier un peu plus dans les détails, et notamment les choses pour lesquelles j'ai tenu à acheter une carte mère de serveur.

(Scène 2.) La mémoire ECC semble fonctionner. (Elle fonctionne, bien sûr, mais la question est de savoir si elle fonctionne bien en tant que mémoire ECC.) Évidemment, c'est difficile à tester, parce que les erreurs mémoires sont quand même très (très) rares. Je devrais peut-être monter une attaque rowhammer pour tester. Mais au moins, j'ai un utilitaire Linux (edac-util, couplé au module ie31200-edac) qui prétend lire le nombre d'erreurs par barrette, et qui me signale 0 erreurs sur chaque barrette : j'imagine (j'espère) que si la mémoire n'était pas ECC, il renverrait une erreur. Mais j'avoue que j'aimerais voir dans les réglages du BIOS une indication quelconque du fait que la mémoire est en mode ECC, ce qu'il n'y a pas (ou alors, je ne l'ai pas trouvée).

(Scène 3.) Je crois que je suis censé avoir sur cette carte mère une technologie Intel qui, selon la phase de la Lune et l'humeur d'Intel, s'appelle Active Management Technology (AMT) ou Management Engine (ME), ou encore vPro. (En gros, il y a un second processeur sur la carte mère, qui écoute sur le réseau, et sait répondre à des commantes du genre, allumer ou éteindre la machine, la redémarrer, simuler un clavier et un écran par réseau, et quelques choses de ce genre.)

Cette technologie est certainement un trou de sécurité monstrueux, et un cauchemar pour les paranoïaques (genre, il est certain que grâce à elle, la NSA a un back door complet vers ma machine), mais elle présente aussi des fonctions qui pourraient m'intéresser, notamment le fait de redémarrer à distance. Mais je n'ai absolument rien compris à la façon de m'en servir. On doit sans doute pouvoir l'activer depuis le BIOS, mais je n'ai rien trouvé de la sorte. Linux détecte bien un truc (il crée un device /dev/mei quand on charge le module mei-me, et il a l'air de détecter plein de choses), mais je n'ai rien compris à la manière de m'en servir. Il y a du vieux code fourni avec le noyau, qui ne marche pas (il me renvoie ENOTTY, en fait parce qu'il essaie de passer des commandes avec un UUID qui n'est pas bon). Il y a plein de doc chez Intel, mais elles se contredisent, datent de plein d'époques différentes, et finalement je n'y comprends rien.

Je me demande si je ne suis pas censé payer à Intel une licence pour avoir le droit d'administrer ma machine, ce qui est quand même un peu fort de café. Mais bon, je n'ai rien compris. En tout cas, pas compris comment faire quoi que ce soit d'utile de cette technologie (ni même comment l'activer, ou au contraire comment être sûr qu'elle est désactivée).

(Scène 4.) Je veux vérifier que mon watchdog matériel marche bien (je répète, pour ceux qui n'ont pas suivi, que le watchdog est un composant matériel qui sert à redémarrer la machine automatiquement en cas de plantage : une fois qu'on l'a activé, il doit recevoir un signal à intervalles réguliers, faute de quoi il provoque un reset). Cette scène se déroule elle-même en plusieurs saynettes.

(Scène 4a.) D'abord, j'ai eu peur, parce que Linux ne semblait pas le détecter du tout (le chargement du module iTCO-wdt n'avait aucun effet). J'ai fouillé dans les docs d'Intel, j'ai eu la confirmation que ce watchdog devait bien être présent dans le chipset C236 que j'ai. Je me suis dit que peut-être le noyau ne connaissait pas cette variante et qu'il fallait ajouter un identifiant PCI ou quelque chose de ce genre. Après des heures passées à éplucher des sources illisibles, j'ai fini par avoir une illumination : il faut charger le module i2c-smbus (en plus de i2c-i801), parce que le watchdog est sur un bus dit SMBus, une variante de I²C (je ne comprends pas du tout pourquoi il est nécessaire de savoir ça, alors que ces bus sont essentiellement des détails matériels, en quoi le logiciel arrive à les « voir », mais bon, c'est un fait). Avec ça, le watchdog est détecté.

(Scène 4b.) Maintenant que mon watchdog matériel est reconnu par Linux, je m'apprête à tester qu'il fonctionne bien. J'active le watchdog et je cesse de lui parler, au bout de quelques minutes le système doit redémarrer.

Mais il ne redémarre pas : il plante complètement.

Plus de réaction. Plus de clavier, plus d'écran, plus rien. J'appuie sur le bouton reset : pas d'effet. J'appuie sur le bouton d'alimentation, la machine s'éteint, je réappuie, ja machine se rallume…

…mais ne redémarre pas.

Sueur froide. Est-ce que j'aurais cassé une deuxième carte mère en à peine dix jours ?

(Scène 5.) Non : en éteignant au niveau de l'alimentation et en attendant assez longtemps pour que la carte mère soit totalement hors tension, si je rallume, la machine redémarre bien. Ouf !

Mais l'effet est reproductible : j'ai un watchdog qui, au lieu de redémarrer l'ordinateur, sert à le planter complètement, au point qu'il faut couper l'alimentation complètement pour qu'il remarche. Voilà qui est merveilleusement utile !

Vu que j'ai acheté cette carte mère précise essentiellement pour deux fonctions cruciales, la mémoire ECC et le watchdog, je suis quand même vert de rage.

Rideau.

⁂

Épilogue (ou teaser pour la suite ?)

Je suis absolument furieux de cette histoire de watchdog. J'hésite à acheter une nouvelle nouvelle nouvelle(!) carte mère, mais encore faudrait-il être absolument certain qu'elle a un watchdog qui marche.

Sinon, deux possibilités :

(1) Comprendre l'origine du problème et peut-être le résoudre. En fait, j'ai une petite idée de l'origine : ce n'est pas que le watchdog ne provoque pas de reset, c'est que ce reset échoue. Asus a eu la bonne idée de mettre un petit afficheur LCD sur la carte mère qui, lors du démarrage, montre différents codes correspondant aux différentes étapes de l'initialisation. Lorsque le watchdog s'active, cet afficheur passe par la même suite de nombres que lors d'un démarrage « normal » (19, 41, 50(?), 4c, 28, 31, 4b, 34, 3e, 3a, 46, 32, 35, 45, 36, 37, 3b, 3c, 38, 39, 3f, 5c, 55, 69(?), 3b, 32, 35, 60, 61, 9a, 62, 72 — tout ça en un tout petit peu plus que 11 secondes) ; mais ensuite, alors que l'initialisation normale continue (79, 96, b2, 9c, 64, 99, b2, a2, 99, ad), le reboot par watchdog revient au code 62 et y reste bloqué. La signification de ces codes est donnée dans le manuel de la carte mère, le code 62 se traduit par Initialization of the PCH Runtime Services (je sais que PCH signifie Platform Controller Hub, c'est essentiellement synonyme de chipset, en l'occurrence le Intel C236 ; mais je ne sais pas ce que sont ces runtime services).

Ceci ressemble à un bug du BIOS[#4] : j'imagine que le reset provoqué par le watchdog laisse je ne sais quel composant ou périphérique dans un état tel que le BIOS ne sait pas l'initialiser, et qu'il plante. (Peut-être la carte graphique ? Quand on cherche Initialization of the PCH Runtime Services dans Google, les gens se font souvent diriger vers un problème de carte graphique. Je ne sais pas. Peut-être que le BIOS n'a été testé complètement qu'avec des processeurs ayant un coprocesseur graphique intégré.)

Mais bon, la magie du logiciel propriétaire et opaque, c'est que s'il y a un bug dans mon BIOS, je ne peux pas le corriger, quand bien même j'en serais capable. J'ai écrit au support technique d'Asus. J'ai reçu une réponse qui n'était pas terrible (ils me demandent de faire toutes sortes de tests basiques comme vérifier que le processeur et les barrettes mémoires ne sont pas défectueux, dont certains tests que je ne peux pas vraiment faire), on va voir si je peux accéder à un niveau supérieur.

J'ai aussi lancé différents appels à l'aide (ici et là) pour savoir si des gens ayant des cartes mères semblables (ou pas, justement) peuvent reproduire le problème. Je n'ai reçu jusqu'à présent essentiellement qu'une réponse. Mais quelqu'un me dit avoir le même problème sur une carte mère d'Asrock (qui a un chipset Intel différent mais qui, comme la mienne, a un BIOS écrit par AMI), ce qui suggérerait que le problème peut venir de là.

Évidemment, mes chances d'arriver à faire remonter l'information jusqu'aux programmeurs qui ont écrit le BIOS, et à plus forte raison de leur faire corriger le problème, sont très minces. Je n'ai pas de carnet d'adresses, et je ne peux vraiment pas faire passer le message (pourtant hautement précis) il y a un problème dans le code d'initialisation des services runtime des PCH des chipsets Intel récents lorsqu'ils sont provoqués suite à un reboot initiié par le watchdog TCO à la bonne personne. C'est rageant. D'ailleurs, je n'arrive même pas à trouver plus qu'une personne prête à faire l'expérience que je demande, alors qu'il y a des milliers de fois plus de gens qui pourraient (des gens ayant une carte mère récente avec chipset Intel, ce n'est pas super rare).

Mise à jour (2016-09-20) : J'ai écrit des instructions pour tester le problème à partir d'une Ubuntu live (donc sans avoir à installer Linux) ici. Si des gens veulent tester sur différentes cartes mères à chipset Intel, je suis intéressé par les résultats. (Par exemple, Simon, dans les commentaires, m'apprend que le problème se produit aussi avec une carte mère Gigabyte Gaming 7 de chipset Z170, ce qui, en plus de l'exemple sur une carte mère Asrock H110M-HDS de chipset H110, porte encore plus les soupçons sur les BIOS AMI.) • Par ailleurs, le support technique d'ASUS, à qui j'ai transmis le lien précédent, m'a affirmé avoir remonté le problème à leur cellule d'expertise, on verra s'il en ressort quelque chose.

[#4] Enfin, du firmware : il paraît qu'en UEFI il ne faut plus dire BIOS — mais comme les auteurs du firmware eux-mêmes le disent, je vais le dire aussi.

(2) Trouver une autre solution pour redémarrer la machine quand elle plante. La technologie AMT mentionnée ci-dessus devrait être une solution, mais je n'arrive décidément pas à savoir si ma carte mère la gère, ou, dans ce cas, comment l'activer (ou vérifier si elle est active) ou comment en faire quoi que ce soit (ou comment parler au /dev/mei que Linux peut faire apparaître sur mon système).

Reste la solution bricolée (mais je déteste le principe) : une prise électrique commandée par USB : je brancherais la commande sur mon routeur (qui lui, a un watchdog qui fonctionne), et je me servirais du routeur comme watchdog pour le PC (mais ce serait très malcommode, donc peut-être simplement que je garderais la possibilité de me connecter au routeur pour éteindre et allumer le PC). Même comme ça, trouver une prise électrique commandée par USB et qui fonctionne sous Linux, ce n'est pas franchement gagné. Je suis tombé sur essentiellement deux produits :

• Aviosys USB Net Power 8800 (une seule prise), vendue 39€ ici, qui a un pilote Unix ici
• EnerGenie EG-PMS2 (6 prises protégées contre les surtensions, dont 4 commandables indépendamment), vendu 45€ ici, qui a un pilote Unix packagé par Debian sous le nom sispmctl

Si je dois acheter un de ces produits, je préférerais que ce soit à des gens qui ont fait l'effort, sinon d'écrire un driver libre, au moins de publier les spécifications techniques (qui doivent être franchement assez triviales s'agissant d'une bête prise qu'on peut allumer ou éteindre)[#5]. Pour le premier, ce n'est clairement pas le cas ; pour le second, je ne sais pas bien. Il y a peut-être des produits plus ouverts.

[#5] J'ai toujours du mal à comprendre comment on peut être un connard au point de vendre un produit qui est une simple prise commandée par USB et de refuser d'en publier les spécifications techniques qui permettraient d'écrire un pilote pour un pilote pour un autre système d'exploitation que Windows. J'aimerais pouvoir avoir une conversation en face à face avec un décideur de ce genre, et arriver à comprendre ce qui lui passe par la tête.

Un moment que je craignais depuis longtemps est arrivé : le PC qui est chez moi est mort. Enfin, il n'est pas complètement mort puisque je m'en sers encore pour écrire ces lignes, mais il ne tient apparemment guère plus que 48h sans planter : je suppose qu'un condensateur dans la carte mère s'est usé, ou quelque chose comme ça, et il y a à parier que d'ici quelques jours il ne marchera plus du tout (et même s'il continue au même rythme, 48h sans planter est bien trop court pour les usages que j'ai). Cette carte mère (Asus P5W64 WS Pro) date de 2007 : il est peut-être de toute façon temps d'en changer.

Voici donc mon first world problem du moment : en 2016 il est devenu vraiment difficile d'acheter un PC correct, en tout cas selon ma définition de « correct ». Précisons d'emblée que ce qui m'intéresse surtout est la fiabilité, pas la performance. Or, pour qu'un produit soit trouvable, il faut qu'il y ait des gens (autres que moi) qu'il intéresse.

Je ne sais pas bien qui achète des PC fixes ni pourquoi. Beaucoup de gens qui autrefois eurent acheté des PC sont passés à ces sales merdes qu'on appelle des tablettes : cette évolution a fait chuter le marché des PC. Même parmi les gens qui ont besoin d'un vrai clavier (parce que, quand même, pour taper beaucoup sur une tablette, il faut être motivé), la plupart achètent des portables, ou des transportables (par transportable, je veux dire un truc qui se présente comme un portable mais qui pèse quand même très lourd). Restent les gamers (ceux parmi eux qui utilisent un PC normal et pas un de ces PC propriétaires spéciaux qu'on appelle consoles) ; mais les gamers recherchent des choses complètement différentes de ce qui m'intéresse : uniquement la performance, ils se foutent de la fiabilité tant que la machine n'en est pas à planter plus vite que leur personnage virtuel ne se fait tuer.

Jusqu'à il y a quelques années, je me disais que je pouvais compter sur une autre catégorie d'acheteurs : les gens (ou en fait, typiquement les TPE/PME) qui veulent un « serveur ». Et de fait, même si je déteste profondément la classification des PC en « machines de bureau » et « serveurs », car je parle bien d'acheter un truc pour mettre sur mon bureau, ce que je veux colle bien avec la catégorie « serveur » : fiabilité avant tout, pas mal de mémoire, fiabilité, pas mal de disque dur, fiabilité, peu importe le chipset graphique, et est-ce que j'ai parlé de la fiabilité. Ou du moins, cela collait bien, parce que je ne sais pas si si cette catégorie existe encore en 2016 : maintenant, si on veut un serveur, ce n'est pas pour mettre chez soi — quand on veut un serveur, on prend une machine hébergée en colocation, ou un serveur virtuel sur le nuage à-ma-zone. Et là ça ne colle plus avec mes besoins, parce que je veux quand même un PC physique à mettre chez moi, qui m'appartienne et sur lequel je puisse stocker mes données (les serveurs en colocation, j'en loue déjà quatre, c'est bon, je n'en veux pas d'un cinquième). Bien sûr, ces serveurs en colocation, ou virtuels dans le nuage, ils doivent bien avoir une existence physique quelque part, mais elle peut être hautement spécialisée, peut-être sous une forme qui ne s'achète que par lots de 1024, ou qui impérativement ont besoin d'être rackée dans un datacenter avec une alimentation groupée, que sais-je encore.

Et du coup, je me demande si on ne s'achemine pas vers un monde où seuls Google, Facebook, Amazon et semblables peuvent acheter des vrais ordinateurs, tous les autres devant leur louer de ces ressources.

❦

J'en viens à une petite description de ce que j'entends par fiabilité, et ce en quoi elle affecte le matériel. Il y a deux points cruciaux à la fiabilité : le taux d'erreur le plus bas possible dans le traitement, la reproduction et le stockage de l'information (car l'information est sacrée), et un fonctionnement 24 heures sur 24 avec le moins de downtime possible (i.e., que l'ordinateur soit tout le temps accessible, et avec lui, l'information qu'il stocke).

Concrètement, au niveau stockage de l'information, l'impératif de fiabilité signifie que j'utilise des disques en RAID ; mais ceci ne concerne pas vraiment le matériel (à part la nécessité d'avoir, disons, quatre disques durs identiques). En revanche, au niveau de la mémoire vive (RAM), cela impose d'avoir de la mémoire ECC (j'ai déjà ranté à ce sujet à de nombreuses reprises, par exemple ici), c'est-à-dire avec correction d'erreurs (pouvant corriger 1 bit erroné quelconque sur un mot de 64 bits, et en détecter 2) : c'est le genre de choses qui n'intéresse pas du tout les gamers parce que c'est forcément plus lent, et parce qu'ils n'ont pas de données importantes à protéger, mais pour moi c'est une condition sine qua non de fiabilité.

Pour avoir de la RAM ECC, il faut non seulement des barrettes ECC (avec 9/8 fois plus de bits dessus), mais il faut aussi que la carte mère supporte l'ECC (c'est-à-dire, que le chipset la supporte, que le câblage le supporte, et que le BIOS le supporte) et aussi que le processeur le supporte. Chez Intel, ça veut dire que le processeur doit être un Xeon. Chez AMD, je n'ai pas compris (ça a l'air un peu plus largement disponible au niveau processeurs — au niveau cartes mères c'est autre chose — mais je suis complètement paumé dans les références). Les informations sont très difficiles à trouver en ligne, parce que très peu de gens veulent de la RAM ECC.

Un autre composant matériel que je souhaite avoir, c'est un watchdog matériel dans la carte mère, c'est-à-dire un composant qui redémarre automatiquement la machine si elle est plantée (concrètement, dès qu'on l'active, il faut lui envoyer régulièrement un signal montrant que tout se passe bien, et s'il ne le reçoit pas au bout de quelques minutes, il provoque un reboot). J'ai ça sur mon PC actuel (celui qui est mourant ; et grâce au watchdog, il reboote quand il plante, au lieu de rester bêtement inutilisable). Le problème de trouver des informations est encore pire concernant les watchdogs que concernant la RAM ECC : c'est quasiment impossible de savoir à l'avance quelles cartes mères ont un watchdog (même si on a les références d'une carte mère précise et de son chipset, parfois même quand on a accès au produit lui-même, c'est vraiment difficile de le savoir). Peut-être même que ce genre de système a été complètement remplacé par des gadgets plus sophistiquées comme l'IPMI ou autres choses dont j'ignore jusqu'au nom. Toujours est-il que je voudrais bien un système qui m'assure que si mon PC plante pendant que je ne suis pas chez moi pour le redémarrer, il y aura quelque chose à faire. Je ne considère pas ça comme aussi absolument indispensable que la mémoire ECC, mais si je peux avoir un watchdog, c'est mieux.

À part ça, laissant de côté les questions de fiabilité, j'ai aussi besoin d'au moins 6 ports SATA (j'ai quatre disques durs à brancher plus deux lecteurs/graveurs optiques) plus un eSATA, et de 2 ports Ethernet gigabit ; tout cela peut s'ajouter par cartes d'extensions, donc ce n'est pas rigoureusement indispensable, mais ce serait pratique. Idéalement j'aimerais plusieurs connecteurs internes PCIe disponibles et aussi un PCI (pour y mettre une vieille carte son que j'aime bien). Et je voudrais avoir au moins 16Go de RAM.

Bon, j'ai fini par me décider à opter pour une carte mère Asus P10S-WS (basée sur un chipset Intel C236, supportant la RAM ECC, et dont je suis presque sûr qu'elle a un watchdog), un processeur Intel Xeon E3-1230v5 (je ne comprends rien, mais alors rigoureusement rien, à la nomenclature et à la numérotation des processeurs Intel, et je ne suis d'ailleurs pas le seul, mais je sais au moins que les Xeon supportent la RAM ECC, et je crois que maintenant la réciproque est plus ou moins vraie), et 2×16Go de RAM Kingston (ECC, donc). J'ai aussi pris une nouvelle alimentation, parce que les alimentations sont une source fréquente de problèmes des PC (il n'est même pas exclu que le problème de mon PC actuel, celui que je qualifie de mourant, soit seulement un problème d'alim, mais je n'ai pas vraiment le temps de tester pour voir : il faut que j'envisage qu'il est en train de mourir).

❦

Mais j'en viens à la suite de mes first world problems de 2016 : ce n'est pas tout de décider quel matériel on veut acheter, encore faut-il l'acheter. Autrefois (il y a 5 ou 10 ans), cela signifiait de passer rue Montgallet. Maintenant, il semble qu'il n'y ait plus rien rue Montgallet à part des vendeurs de tablettes et de mobiles : le matériel informatique qui ne soit pas complètement basique, on l'achète en ligne.

Le problème n'est pas juste que je déteste Amazon (mais je déteste Amazon).

Un problème est que les délais de livraison sont très mauvais (la carte mère et le processeur doivent m'être expédiés d'Allemagne, et apparemment l'Allemagne est un pays très lointain parce que la livraison m'est annoncée pour le 7 septembre(!)), tandis qu'à l'époque où un Parisien pouvait acheter des choses rue Montgallet, on avait ce qu'on voulait dans la journée. D'ici le 7 septembre, mon PC actuel a bien le temps de finir son agonie.

Un autre problème est que la réception d'un colis est une entreprise notoirement périlleuse : ici, j'ai opté pour me faire livrer au bureau, ce qui diminue sans doute un peu les problèmes (et en tout cas, les modifie), mais il ne faudrait pas imaginer que tout est réglé pour autant.

Et aussi, je suis quasiment certain que parmi les quatre-cinq articles que j'ai commandés (la carte mère, le processeur, les deux barrettes de RAM et l'alim), au moins l'un d'entre eux va m'être livré remplacé par autre chose — ou défectueux. Je soupçonne vaguement la RAM, dont la page de description ne mentionne quasiment pas qu'elle est ECC (il faut lire attentivement le numéro de modèle Kingston). Le système de recherche d'Amazon est d'ailleurs épouvantablement pourri : on ne peut pas chercher de la RAM ECC parce que tous les descriptifs disent soit ECC soit (le plus souvent) non ECC, et du coup la recherche de ECC renvoie les deux (ils sont au courant qu'un produit peut se décrire et se rechercher de façon plus fine qu'une chaîne de caractères, chez Amazon ?).

Tout ceci étant dit, j'ai commandé les parties d'un nouveau PC. Qui peut-être me seront livrées un jour, et je pourrai alors exprimer mon exaspération sur d'autres sujets (le fait que l'UEFI qui a remplacé le BIOS traditionnel est une sale merde, le fait que c'est affreusement difficile de reconfigurer Linux pour une nouvelle machine, le fait que je ne sais pas appliquer de la pâte thermique, que sais-je encore).

Hier, un de mes disques durs[#] a décidé de ne plus répondre (du point de vue de l'ordinateur, c'était exactement comme s'il avait été débranché brutalement). En fait, je ne sais pas vraiment si ça s'est produit hier : j'ai même des indices selon lesquels ça s'est peut-être produit il y a presque un mois (entre le 9 et le 10 octobre), mais comme toutes mes données sont en RAID, je ne me serais rendu compte de rien : normalement, j'aurais dû être averti du problème par un mail, mais des problèmes de mail complètement indépendants ont fait que ce genre de mails ne m'arrivaient pas. Enfin, peu importe. Ce genre de problèmes matériels a peu de chances de me faire perdre de données : j'ai pris des précautions assez délirantes contre ça, comme en témoigne le fait que j'ai peut-être passé un mois sans même me rendre compte que le disque dur ne réagissait plus, et je m'en suis finalement rendu compte parce que mon ordinateur a planté pour des raisons probablement sans aucun rapport. En revanche, il a une capacité à me faire perdre un temps considérable : pour commencer, changer un disque dur dans le boîtier[#2] ne peut pas me prendre moins d'une heure, et il en faut encore beaucoup pour resynchroniser tout le RAID (même si la machine reste utilisable, quoique ralentie, pendant ce temps) et pour vérifier soigneusement que tout s'est bien passé, mais le plus gros du temps perdu est celui pendant lequel je me demande ce que je dois faire exactement.

Ici, j'avais déjà soupçonné que ce disque dur avait des vapeurs : il m'avait déjà fait un coup semblable, ou produit des messages d'erreur suspects (un peu du genre de ceux rapportés ici, même s'il s'agit là d'un autre disque sur une autre machine). Mais la difficulté, c'est qu'il est très difficile de savoir si ce genre de problèmes vient du disque ou du contrôleur (sans compter que ça peut aussi être la faute du câble !) : si le disque ou le contrôleur ne marche pas du tout, on s'en rend vite compte et on trouve vite le coupable, mais s'il marche généralement-mais-pas-toujours, c'est beaucoup plus compliqué d'enquêter. Idéalement, on devrait juste changer un paramètre, le plus suspect, attendre si un nouveau problème survient, et en changer alors un autre, en notant soigneusement tout ce qu'on a fait : mais, bien sûr, les choses sont rarement idéales, les erreurs sont rarement claires, on peut vouloir changer plusieurs choses suspectes d'un coup pour diminuer les risques aux dépens de la pureté expérimentale, d'autres paramètres viennent ajouter de la confusion (des différences logicielles, par exemple, parce que le noyau ou d'autres choses ont pu être mis à jour entre temps ; ou d'autres disques branchés pour d'autres raisons), on ne note pas toujours parfaitement ce qu'on fait.

Dans ce cas précis, si je simplifie (et que je reconstitue bien), le disque, appelons-le HD204, que je suspecte maintenant d'être mauvais a été branché jusqu'en juillet 2013 sur le port SATA3 de ma carte mère, j'ai eu des problèmes avec, je l'ai retiré et mon poussinet l'a testé de façon approfondie, et n'a trouvé aucun problème après plusieurs tests de surface, du coup je l'ai remis en place (je parle toujours de HD204), sauf que je l'ai branché sur SATA4 parce que j'avais réutilisé SATA3 pour un autre disque ; mais j'ai de nouveau eu des problèmes avec le disque sur SATA3 (pas HD204, donc), du coup je me suis dit : aha, en fait, c'est mon port SATA3 qui doit être pourri, et j'ai rebranché le disque HD204 sur le port SATA5 (relié à un autre contrôleur[#3] SATA, qui gère aussi le SATA externe), mais maintenant c'est la deuxième fois que j'ai des problèmes avec ce disque HD204 branché sur SATA5. Plusieurs hypothèses sont possibles : soit mes ports SATA3 et SATA5 sont tous les deux défectueux (possible, mais quand même peu probable, surtout qu'ils sont reliés à des contrôleurs totalement indépendants, et surtout que je n'avais pas eu de problème avec SATA3 avant d'y connecter HD204) ; soit c'est un problème de câble (je crois que j'ai changé plusieurs fois de câble dans l'histoire, mais je peux me tromper, et en plus j'ai remis un peu stupidement un câble suspect dans mon sac à câbles sans l'étiquetter comme tel) ; soit c'est le disque HD204 qui non seulement a parfois un comportement bizarre mais est aussi capable de causer des erreurs sur un autre port du même contrôleur SATA (SATA3 alors que HD204 était branché sur SATA4). Je penche à présent plutôt pour cette dernière hypothèse, mais je suis loin d'être certain. Tout cela est encore compliqué par le fait que SATA5 a d'autres sortes de problèmes (pas vraiment des défauts, mais des bizarreries de reset et un délai très long de détection des disques, peut-être en lien avec le fait que le même contrôleur gère le SATA externe). Au final, on admettra que tout ceci est confus (et actuellement, le nouveau disque que j'ai branché sur SATA3 et HD204 testé de façon séparée, donnent tous les deux l'apparence de bien fonctionner).

Peut-être que j'aurais simplement dû me dire que ce n'est pas très grave si une fois par an environ, le disque cesse de répondre et qu'il faut redémarrer la machine à froid et reconstruire tout le RAID.

Peut-être aussi que je devrais acheter un nouveau PC. Mais ça veut dire encore un temps fou passé à trouver une configuration qui me satisfasse (je tiens à avoir à la fois de la mémoire ECC et un watchdog matériel, et j'ai peur que ce soit devenu très difficile de trouver un tel matériel rue Montgallet) et à découvrir les problèmes nouveaux qu'elle posera. Bof.

Bref, #FirstWorldProblems.

[#] Nommons les coupables : il s'agit d'un Samsung HD204UI Spinpoint F4 EG (AF) de 2To.

[#2] Donc : passer un grand coup d'aspiro à l'intérieur, s'énerver contre les têtes ou les pas de vis qui s'abîment comme du beurre, se faire mal aux mains à sortir et remettre les barrettes mémoire qui gènent la sortie du disque de son berceau, s'émerveiller de la capacité des câbles à inventer des nœuds toujours plus inventifs, et surtout maudire la géométrie dans l'espace qui fait qu'il y a toujours quelque chose dans le boîtier de l'ordinateur qui gène l'accès à la chose à laquelle on essaie d'avoir accès. Compter toutes ces étapes une fois pour retirer le disque dur défectueux et une nouvelle fois pour mettre le nouveau.

[#3] Mes ports SATA1 à SATA4 sont gérés par un chipset Intel ICH7, tandis que SATA5, SATA6 et le SATA externe sont gérés par un Marvell 88SE6145.

Je ne vais pas commencer à raconter tout le temps que j'ai perdu cet été avec mes ordinateurs : entre mon père qui a décidé de déménager plein de choses dans son sous-sol et qui a branché l'alimentation du disque dur externe de la machine servant de routeur sur un transformateur délivrant la mauvaise tension, et un ordinateur hébergé à l'ENS qui a été déconnecté sans aucun avertissement et qui m'a valu quantité de mails pour expliquer la situation aux utilisateurs, rien que raconter les choses prendrait plus de temps que je n'en ai.

La dernière péripétie est que deux des trois disques durs du PC que j'ai chez mes parents (et qui me sert notamment de stockage de sauvegardes) ont décidé de mourir simultanément, et, qui plus est, pendant que j'étais en vacances en Allemagne. L'un (un Maxtor DiamondMax® STM3750330AS de 750Go, acheté en avril 2008 et utilisé seulement depuis novembre 2011, nommé sdc ou ata2.01 dans les logs qui suivent) a brutalement cessé purement et simplement de répondre à la moindre commande :

Sep  1 22:37:43 pleiades kernel: [1749716.736036] ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Sep  1 22:37:43 pleiades kernel: [1749716.736044] ata2.01: failed command: SMART
Sep  1 22:37:43 pleiades kernel: [1749716.736050] ata2.01: cmd b0/da:00:00:4f:c2/00:00:00:00:00/10 tag 0
Sep  1 22:37:43 pleiades kernel: [1749716.736050]          res 40/00:01:01:4f:c2/00:00:00:00:00/10 Emask 0x4 (timeout)
Sep  1 22:37:43 pleiades kernel: [1749716.736054] ata2.01: status: { DRDY }
Sep  1 22:37:48 pleiades kernel: [1749721.785014] ata2: link is slow to respond, please be patient (ready=0)
Sep  1 22:39:47 pleiades kernel: [1749724.182021] ata2: soft resetting link
Sep  1 22:39:47 pleiades kernel: [1749731.416141] ata2.01: qc timeout (cmd 0xec)
Sep  1 22:39:47 pleiades kernel: [1749731.416149] ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
Sep  1 22:39:47 pleiades kernel: [1749731.416153] ata2.01: revalidation failed (errno=-5)
Sep  1 22:39:47 pleiades kernel: [1749736.312020] ata2: soft resetting link
Sep  1 22:39:47 pleiades smartd[5643]: Device: /dev/sdc, not capable of SMART self-check 
Sep  1 22:39:47 pleiades kernel: [1749736.482563] ata2.01: configured for UDMA/133
Sep  1 22:39:47 pleiades kernel: [1749736.482584] ata2: EH complete
Sep  1 22:39:47 pleiades kernel: [1749746.720034] ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Sep  1 22:39:47 pleiades kernel: [1749746.720043] ata2.01: failed command: SMART
Sep  1 22:39:47 pleiades kernel: [1749746.720050] ata2.01: cmd b0/d0:01:00:4f:c2/00:00:00:00:00/10 tag 0 pio 512 in
Sep  1 22:39:47 pleiades kernel: [1749746.720050]          res 40/00:01:01:4f:c2/00:00:00:00:00/10 Emask 0x4 (timeout)
Sep  1 22:39:47 pleiades kernel: [1749746.720054] ata2.01: status: { DRDY }
Sep  1 22:39:47 pleiades kernel: [1749751.769022] ata2: link is slow to respond, please be patient (ready=0)
Sep  1 22:39:47 pleiades kernel: [1749756.767014] ata2: device not ready (errno=-16), forcing hardreset
Sep  1 22:39:47 pleiades kernel: [1749756.767023] ata2: soft resetting link
Sep  1 22:39:47 pleiades kernel: [1749764.011135] ata2.01: qc timeout (cmd 0xec)
Sep  1 22:39:47 pleiades kernel: [1749764.011140] ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
Sep  1 22:39:47 pleiades kernel: [1749764.011144] ata2.01: revalidation failed (errno=-5)
Sep  1 22:39:47 pleiades kernel: [1749769.060013] ata2: link is slow to respond, please be patient (ready=0)
Sep  1 22:39:47 pleiades kernel: [1749774.058012] ata2: device not ready (errno=-16), forcing hardreset
Sep  1 22:39:47 pleiades kernel: [1749774.058019] ata2: soft resetting link
Sep  1 22:39:47 pleiades smartd[5643]: Device: /dev/sdc, failed to read SMART Attribute Data 
Sep  1 22:39:47 pleiades smartd[5643]: Device: /dev/sdc, Read SMART Self Test Log Failed 
Sep  1 22:39:47 pleiades kernel: [1749786.302021] ata2.01: qc timeout (cmd 0xec)
Sep  1 22:39:47 pleiades kernel: [1749786.302026] ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
Sep  1 22:39:47 pleiades kernel: [1749786.302029] ata2.01: revalidation failed (errno=-5)
Sep  1 22:39:47 pleiades kernel: [1749791.351016] ata2: link is slow to respond, please be patient (ready=0)
Sep  1 22:39:47 pleiades kernel: [1749796.349013] ata2: device not ready (errno=-16), forcing hardreset
Sep  1 22:39:47 pleiades kernel: [1749796.349024] ata2: soft resetting link
Sep  1 22:39:47 pleiades kernel: [1749828.593026] ata2.01: qc timeout (cmd 0xec)
Sep  1 22:39:47 pleiades smartd[5643]: Device: /dev/sdc, Read Summary SMART Error Log failed 
Sep  1 22:39:47 pleiades kernel: [1749828.593035] ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
Sep  1 22:39:47 pleiades kernel: [1749828.593039] ata2.01: revalidation failed (errno=-5)
Sep  1 22:39:47 pleiades kernel: [1749828.593042] ata2.01: disabled
Sep  1 22:39:47 pleiades kernel: [1749833.642016] ata2: link is slow to respond, please be patient (ready=0)
Sep  1 22:39:47 pleiades kernel: [1749838.640016] ata2: device not ready (errno=-16), forcing hardreset
Sep  1 22:39:47 pleiades kernel: [1749838.640028] ata2: soft resetting link
Sep  1 22:39:47 pleiades kernel: [1749840.841810] ata2: EH complete
Sep  1 22:39:47 pleiades kernel: [1749840.842031] end_request: I/O error, dev sdc, sector 15438448
Sep  1 22:39:47 pleiades kernel: [1749840.842036] md: super_written gets error=-5, uptodate=0
Sep  1 22:39:47 pleiades kernel: [1749840.842041] md/raid1:md2: Disk failure on sdc5, disabling device.
Sep  1 22:39:47 pleiades kernel: [1749840.842041] md/raid1:md2: Operation continuing on 2 devices.
Sep  1 22:39:47 pleiades kernel: [1749840.842206] sd 1:0:1:0: [sdc] Asking for cache data failed
Sep  1 22:39:47 pleiades kernel: [1749840.842213] sd 1:0:1:0: [sdc] Assuming drive cache: write through

— tandis que l'autre (un Western Digital Caviar Blue® WD10EALX-009BA0 de 1To, acheté en juin 2012, et nommé sdb ou ata1.01 dans les logs qui suivent) n'a pas tardé à se découvrir quantité de secteurs défectueux :

Sep  2 22:55:54 pleiades smartd[9342]: Device: /dev/sdb, FAILED SMART self-check. BACK UP DATA NOW! 
Sep  2 22:55:54 pleiades smartd[9342]: Device: /dev/sdb, SMART Prefailure Attribute: 3 Spin_Up_Time changed from 176 to 187 
Sep  2 22:55:54 pleiades smartd[9342]: Device: /dev/sdb, Failed SMART usage Attribute: 5 Reallocated_Sector_Ct. 
Sep  2 22:55:54 pleiades smartd[9342]: Device: /dev/sdb, SMART Prefailure Attribute: 5 Reallocated_Sector_Ct changed from 200 to 42 
Sep  2 22:55:54 pleiades smartd[9342]: Device: /dev/sdb, SMART Usage Attribute: 7 Seek_Error_Rate changed from 200 to 21 
Sep  2 22:55:54 pleiades smartd[9342]: Device: /dev/sdb, SMART Usage Attribute: 194 Temperature_Celsius changed from 107 to 108 
Sep  2 22:55:54 pleiades smartd[9342]: Device: /dev/sdb, SMART Usage Attribute: 196 Reallocated_Event_Count changed from 200 to 84 

(Qu'on se rassure, malgré le message trompeur, il n'était pas vraiment à 108°C : le 108 est une valeur normalisée SMART, qui pour ce fabricant semble correspondre à environ 40°C.) Ce disque a continué à plus ou moins fonctionner (mais lentement, en faisant des bruits bizarres, et de rares vraies erreurs), au moins le temps de me permettre d'en récupérer en catastrophe celles de mes données qui n'étaient protégées que contre l'échec d'un seul disque.

Je ne peux pas vraiment dire que je sois passé près de la catastrophe : en vérité, non seulement comme je viens de le dire le disque mourant a tenu le coup le temps que j'en extraie tout ce que je voulais extraire, mais de toute façon les données vraiment importantes étaient en redondance triple (RAID1 sur les trois disques), et même ces données étaient essentiellement des sauvegardes incrémentales de données qui sont en redondance au moins quintuple sur des ordinateurs à deux endroits physiquement séparés (sans compter des sauvegardes sur médias optiques) — bref, je suis passablement parano avec la perte d'information. Néanmoins, j'aurais pu perdre quelques choses qui m'auraient agacé, et beaucoup plus de temps que je n'en ai déjà passé à racheter des nouveaux disques et recopier tout ce que j'avais sur ceux-ci (ce qui, quand le disque dur mourant descend jusqu'à 3Mo/s et qu'on a 750Go à copier, prend… longtemps). J'ai donc augmenté ma paranoïa d'encore un cran et mis encore plus de partitions en redondance triple : après tout, ça ne sert à rien d'économiser vingt gigas par-ci par-là quand j'en ai des centaines dont je ne me sers pas vraiment.

Mais au-delà de cette non-catastrophe, la question demeure de savoir comment il se fait que deux disques durs aient pu mourir en même temps (et cette question a de l'importance, parce que si deux peuvent, alors trois peuvent aussi, et je ne serais vraiment vraiment pas content). J'avais déjà eu une expérience de ce genre qui s'était avérée n'être qu'une vapeur du contrôleur, mais cette fois les disques ont bien l'air d'être endomagés. Il n'y a pas eu d'orage à cette période qui expliquerait, par exemple, une surtension électrique. Je peux vaguement soupçonner soit une insuffisance de l'alimentation ou une chaleur excessive, mais aucune de ces hypothèses n'est corroborée par un indice tangible. Par ailleurs, les deux disques ont commencé à défaillir à presque exactement 24h d'intervalle, ce qui est peut-être significatif, mais je ne sais pas de quoi (il n'est rien censé se passer de particulier à ce moment-là).

J'ai racheté (à Hambourg) trois nouveaux disques durs, en essayant de trouver trois constructeurs différents, mais comme je le soupçonnais c'est une tâche impossible : je ne sais pas exactement combien existent de chaînes vraiment indépendantes de fabrication de disques durs, mais le nombre de marques semble être tombé à 2 (Seagate ayant, je crois, acquis Maxtor ; et Western Digital), comme par hasard ceux qui m'ont empiriquement posé le plus de problèmes par le passé (alors que Hitachi, Samsung et IBM, qui semblaient considérablement plus fiables, soient ne fabriquent plus de disques, soit au moins ont cessé de les revendre aux péquenots comme moi).

Je constate aussi de nouveau ce que j'avais déjà cru détecter, à savoir que (dans des mesures raisonnables) plus un disque dur est ancien, plus il est fiable : ce sont mes disques les plus récents qui ont lâché (pour référence, celui qui continuait à fonctionner était un Samsung SpinPoint® HD501LJ de 500Go, acheté en novembre 2007). Autrement dit, il me semble que sur un disque dur, le phénomène d'usure avec le temps est beaucoup moins important que le phénomène de défaut caché à la fabrication (appelé aussi mortalité infantile des disques durs) et que l'expérience permet de dévoiler : plus votre disque a tenu longtemps, plus il y a des chances qu'il soit de bonne qualité et continue à tenir longtemps. Il est vrai que les deux disques dont on parle étaient tous trop vieux pour vraiment entrer dans la case « mortalité infantile », donc c'est peut-être simplement une coïncidence.

Bien sûr, mes observations aussi bien sur la fiabilité relative des marques que sur la fiabilité avec le temps sont basées sur des données statistiquement insuffisantes, et même pas collectées de façon systématique. Ceux qui pourraient le mieux fournir des informations vraiment scientifiques sur la fiabilité des disques, c'est Google : malheureusement, une étude qu'ils ont publiée il y a quelque temps à ce sujet ne veut rien révéler sur les marques de disques durs plus ou moins fiables. À défaut, j'ai trouvé deux rapports de la compagnie de stockage Blackblaze, celle-ci sur la durée de vie des disques durs en général et celle-là sur les marques plus ou moins fiables, qui corroborent au moins partiellement mes impressions (les disques durs jeunes ont le plus tendance à mourir, le minimum du taux de mortalité se situant d'après eux vers 2 ans d'âge ; et Hitachi semble bien la marque la plus fiable — ou du moins semblait). Il faut néanmoins bien prendre note que les conditions d'utilisation (température, pourcentage du temps passé allumé, nombre de cycles de garage des têtes, etc.) peuvent changer du tout au tout les résultats de ce genre de mesures, donc on reste dans le domaine de la boule de cristal.

Comme promis, je dis un petit mot du nouveau portable que je me suis acheté lors de mon week-end à Londres pour remplacer mon Eee PC devenu trop lent : il s'agit d'un Acer Aspire One725, que j'ai acheté pour 250£, c'est-à-dire un peu moins de 300€, (au Currys PC World de Tottenham Court Road). Avec un clavier QWERTY (GB, mais que je configure comme US), donc, puisque tel était le but d'aller l'acheter en Angleterre.

Le prix est la principale chose qui le rend attractif : en choisissant quelque chose d'aussi bon marché, je ne m'attendais certainement pas à quoi que ce soit d'extraordinaire, et, de fait, il ne l'est pas. Il est néanmoins correct.

Parmi les choses que j'apprécie en tout cas, il y a le poids : avec 1.20kg, il fait quasiment le même poids que mon précédent Eee PC (1.14kg), alors qu'il est nettement plus grand (11.6″ de diagonale d'écran contre 8.9″) : ceci donne l'impression d'une très grande légèreté, et comme l'idée est de l'avoir toujours dans mon sac, c'est éminemment appréciable.

L'écran, de résolution 1366×768 pour une diagonale de 11.6″ (ce qui fait 135dpi) est de bonne qualité, ou plutôt, serait de bonne qualité si je n'avais pas deux pixels morts, ce qui gâche beaucoup les choses. Heureusement, ils sont tous les deux (un rouge et un noir) sur l'extrême bord droit, donc ce n'est pas totalement insupportable, mais j'en suis néanmoins très fâché : j'aurais préféré une résolution bien moindre, et/ou une taille d'écran bien moindre, pour avoir quelque chose que les fabricants sachent correctement contrôler ! À part ça, le chipset graphique est un Radeon HD 6xxx (6290 ou 6250, je ne sais pas exactement, et je ne sais pas s'il y a vraiment une différence), donc aussi bien supporté par Linux qu'on peut l'espérer — un de mes buts était d'éviter certains chipsets Intel communs qui ne le sont que très mal.

Le toucher du clavier n'est pas mauvais, et il est en tout cas assez silencieux. La disposition des touches n'est pas idéale (touche entrée disposée verticalement, avec la touche backslash — enfin, dièse sur le QWERTY-GB — placée à sa gauche plutôt qu'au-dessus), et je n'aime pas trop le pavé de flèches, mais c'est une question d'habitude. Le touchpad est très confortable.

Le processeur, un AMD C70 (double cœur, 1GHz) est correct. Il a l'avantage sur celui que j'avais dans mon Eee PC de pouvoir fonctionner en 64-bits. Il aurait aussi l'avantage d'avoir de fournir la virtualisation si les salopards qui ont écrit mon BIOS ne l'avaient pas désactivée[#], ce qui me donne un peu des envies de meurtre. La RAM est de 2Go, ce qui est le double de ce que j'avais sur mon Eee PC (en fait, pas exactement, parce que la mémoire graphique mange dessus) donc, même si ce n'est pas gigantesque, c'est un progrès.

Le disque dur fait 320Go, ce dont je n'ai que faire : j'avais tout à fait assez des (16+4)Go de mon Eee PC. Mais la différence essentielle est que maintenant il s'agit d'un vrai disque dur, pas d'un SSD. L'avantage est qu'il ne connaîtra pas le phénomène de ralentissement qui m'a forcé à changer ; l'inconvénient est que j'ai maintenant peur de le casser, et j'ose à peine le bouger alors que je savais que mon Eee PC ne craignait rien. Comme, de nouveau, l'idée est de l'avoir toujours dans mon sac, c'est nettement plus problématique.

Globalement, la machine me donne l'impression d'être certes beaucoup plus rapide que mon précédent ultraportable à l'agonie, mais néanmoins pas franchement hyper-rapide. (Il faut dire que je m'obstine à utiliser Ubuntu, qui lance un nombre incroyable de choses qui ne servent à rien au démarrage, mais bon, je ne vais pas parler ici de mes innombrables griefs contre toutes les distributions Linux possibles.)

Le port Ethernet est de 100Mbps, ce qui est franchement décevant en 2013, mais pour l'usage que je vais en faire ça suffira. Le chipset Wifi est un Atheros, donc très bien géré par Linux, et comme je n'utilise que du Wifi 802.11g le fait qu'il sache aussi faire du 802.11n ne m'intéresse pas. Contrairement à mon Eee PC, il n'a pas de Bluetooth, ce qui est aussi un peu décevant, mais je n'en ai pas vraiment usage (quand je fais du tethering avec mon téléphone, c'est par USB et je garde toujours dans mon sac un câble à cet effet). Il semble que j'aie un port USB 3.0, ce dont je n'ai que faire parce que je ne sais même pas vraiment ce que ça veut dire, et j'ai aussi un port HDMI dont je n'ai pas plus usage. J'ai un lecteur de cartes mémoire, ce qui pourrait s'avérer utile, mais je n'ai pas testé si Linux sait l'utiliser.

L'autonomie est plutôt décevante : les tests que j'ai vus en ligne en sont plutôt contents, mais personnellement j'ai mesuré autour de 3 heures dans l'usage que j'en fais, ce qui n'est franchement pas impressionnant ; en fait, c'est à peine plus que ce qu'avait mon Eee PC une fois sa batterie bien vieillie, et donc vraiment beaucoup moins que ce qu'il avait initialement. Bon, il est vrai que mon test n'a pas été très poussé, je n'ai pas cherché à désactiver ce qui consomme de l'énergie, et surtout il alimentait mon téléphone par USB (puisque je faisais du tethering), donc il y a certainement moyen de monter au-dessus de 3h.

La machine était vendue avec Windows 8 préinstallé, que mon premier soin a été d'effacer soigneusement (j'aurais un certain agacement à avoir payé pour cette horreur, mais on m'a soufflé qu'en fait différents logiciels plus ou moins publicitaires qui accompagnent le bouzin servent typiquement à le payer sur ce genre de machines). À cause de ça, la machine a un BIOS UEFI, ce qui me faisait un peu peur a priori (il y a eu des critiques contre Microsoft qui aurait poussé à des standards rendant difficile l'installation de Linux), mais en fait ça ne m'a causé aucune difficulté : primo on peut désactiver le mode UEFI pour revenir en mode historique, secundo même en mode UEFI on peut désactiver le mode « sûr » (c'est-à-dire dans lequel il vérifie la signature cryptographique du code de démarrage), et tertio il est extrêmement facile dans le BIOS d'autoriser l'exécution de nouveaux blocs de démarrage : la machine n'est donc absolument pas verrouillée sous Windows, et je n'ai pas de raison supplémentaire (je veux dire, à part pour avoir désactivé la virtualisation dans le processeur) de détester les auteurs du BIOS.

On verra à l'usage, mais pour l'instant je n'ai ni l'impression d'avoir jeté mon argent par les fenêtres ni celle d'avoir fait une affaire exceptionnelle.

[#] On peut se demander, d'ailleurs, pourquoi le processeur permet que le BIOS désactive la virtualisation d'une manière irréversible (et pas, par exemple, l'unité flottante, ou le deuxième cœur, ou que sais-je encore). Je crois que l'idée à l'origine est une mesure de sécurité : on a pu avoir peur que des virus s'intercaleraient avant le système d'exploitation et feraient tourner celui-ci dans une machine virtuelle (dont ils seraient l'hyperviseur), ce qui les rendrait indétectables. Ce raisonnement est profondément crétin parce que la virtualisation n'apporte pas de fonctionnalité nouvelle à la machine — on peut tout faire purement en logiciel, et avec un compilateur just-in-time assez sioux on devrait perdre assez peu d'efficacité — mais ce ne serait pas la première fois que des gens auraient des idées saugrenues de la sorte. Après, dans mon cas, je suppose qu'il s'agit pour les fabricants de la machine de pouvoir vendre un modèle plus cher où la fonctionnalité ne serait pas désactivée par le BIOS. Malheureusement, à part désassembler le BIOS pour retrouver comment il calcule la clé de verrouillage, il n'y a pas grand-chose que je puisse faire.

Étant entendu qu'on ne dispose pas d'ordinateurs infiniment rapides, il y a quand même quelque chose qui me semble mystérieux : c'est que ceux dont on dispose effectivement semblent aller de plus en plus lentement (je veux dire, un ordinateur donné devient de plus en plus lent au cours de sa vie ; un ordinateur nouvellement acheté va toujours à la même vitesse : comme s'il y avait un phénomène d'inflation dans les temps d'exécution). Je peux imaginer quatre raisons à ça, sans doute toutes les quatre vraies, mais aucune ne me convainc pleinement :

• un effet purement psychologique (peut-être parce qu'on voit des ordinateurs plus rapides, ou parce que s'estompe l'effet de nouveauté d'avoir une nouvelle machine fulgurante) qui donne l'impression que la machine va de plus en plus lentement alors qu'il n'en est rien,
• un effet réel dû à des logiciels de plus en plus gourmands (on est obligé de toujours mettre à jour parce que les trous de sécurité doivent sans arrêt être corrigés, ceux-ci ne le sont que dans la dernière version des logiciels, et ceux-ci utilisent de plus en plus de ressources),
• un effet réel dû à un encombrement logiciel (le terme n'est pas très bien choisi, mais je pense par exemple aux vieux systèmes de fichiers qui se « fragmentaient » avec le temps, je pense aux navigateurs Web qui peuvent avoir un historique de plus en plus lourd, ce genre de choses), ou enfin
• un effet réel dû à une usure du matériel (l'ordinateur devient vraiment de plus en plus lent).

Le dernier peut sembler impossible (un microprocesseur ça ne s'use pas progressivement !) mais il y a certainement de ça dans certains cas : je pense notamment à mon Eee PC acheté il y a quatre ans : non seulement la durée de vie de sa batterie a décru de ~5 heures à ~1 heure, mais en plus il est devenu lent au point d'être quasiment inutilisable, et j'ai de fortes raisons de penser que ce n'est pas seulement Ubuntu qui est de plus en plus gourmand mais aussi que le SSD qui fait office de disque dur est devenu de plus en plus lent (je ne sais pas exactement comment fonctionnent les SSD, mais je sais en tout cas que les accès disques paralysent complètement la machine, à chaque fois qu'elle vide son cache elle cessse totalement de réagir pendant parfois plusieurs minutes alors que ça ne se produisait pas il y a quelques années).

(Je pense m'acheter un nouvel ultraportable, mais je bute contre deux difficultés : celle de trouver une configuration qui soit complètement, et pas seulement à 99%, supportée par Linux, et ce avec des pilotes libres ; et celle de m'acheter une machine avec clavier QWERTY US, ou à la limite GB, sans pour autant renoncer à tout espoir d'avoir une garantie. Si quelqu'un a des idées, je suis preneur.)

Mon téléphone aussi devient de plus en plus lent (il faut maintenant souvent plusieurs secondes pour revenir à l'écran principal) et là je ne comprends vraiment pas ce qui peut causer ça.

Il n'y a pas que mon poussinet qui a des tracas : les disques durs de mon PC ont eu une vapeur bizarre aujourd'hui : deux d'entre eux (sur quatre) se sont mis à rapporter des erreurs en pagaille. J'ai de fortes raisons de soupçonner (ne serait-ce que parce que la coïncidence que deux disques meurent exactement au même moment est un peu trop dingue, encore que ça pourrait être un problème d'alim, un choc ou une surtension, ou je ne sais quoi) qu'il s'agissait surtout d'une vapeur du chipset/contrôleur, toujours est-il qu'après reboot les disques durs en question semblent de nouveau se porter bien ; l'un d'entre eux a effectivement consigné des erreurs dans le SMART, mais elles ne riment à rien (les secteurs indiqués sont parfaitement lisibles, les erreurs elles-mêmes sont bizarres, et aucun secteur n'est indiqué réalloué), l'autre disque n'a rien enregistré du tout. Bref, je ne sais pas ce qui s'est passé.

Mais ça a quand même causé un certain désagrément à mes tableaux RAID. Comme je l'ai déjà expliqué, je fais du RAID 1, 6 ou 5 selon le niveau de redondance voulu (respectivement 3, 2 ou 1 disques de redondance sur 4). Le RAID6 a bien réagi : il a simplement marqué les deux disques comme défectueux et a continué à marcher sur les deux restants. Le RAID1 a fait quelque chose d'un peu bizarre : il a viré les deux disques censément défectueux, mais comme il est hyper-redondant, en fait, les deux disques virés formaient eux aussi un tableau cohérent, ça a dû embrouiller l'autodétection des tableaux, et au reboot suivant je me suis retrouvé avec deux tableaux RAID1 chacun dégradés à 2 disques sur 4, ce qui m'a causé une certaine confusion. Le RAID5, évidemment, n'a pas résisté à la mort de 2 disques sur 4 : mais le fait est qu'ils n'étaient pas vraiment morts, simplement ils avaient cessé de réagir, et les écritures avaient continué sur les 2 autres disques, du coup l'état du tableau était un peu bizarre ; heureusement, mdadm a une option --force qui permet de reconstruire le tableau bien que les membres prétendent être dans des états différents, j'ai pu faire ça et tout revérifier derrière, et il n'y avait rien eu de grave (bon, le fait est aussi que je m'en foutais un peu, c'était mon /tmp — oui, même mon /tmp est en RAID5 — mais c'était intéressant de voir ce qui se passerait).

Bref, j'intitule cette entrée le RAID n'est pas parfait, mais en fait il a plutôt bien rempli sa mission de protéger mes données contre, euh, contre une non-panne de disque dur ; en revanche, il y a eu un peu de confusion dans toute l'histoire, et j'ai quand même eu un peu peur.

Je ne sais pas si ça vaut la peine de changer les disques durs : d'un côté, tout semble indiquer que c'est le contrôleur qui a déconné et un test de surface ne retourne aucune erreur ; de l'autre j'ai tendance à prêcher l'attitude si on a la moindre bizarrerie sur un disque dur, on le change illico et sans se poser de question. Peut-être que je peux changer celui des deux qui a vraiment enregistré des erreurs dans le SMART, mais c'est un peu con, c'est le plus neuf des deux (en fait, c'est le Seagate de 2To qui apparaît dans cette histoire).

TLDR: J'ai remplacé ma carte graphique vieille de cinq ans et mon moniteur (un CRT de 17″ de résolution 1024×768) vieux de huit par une carte graphique récente et un écran LCD de 22″ de résolution 1920×1080, et je me lamente d'avoir perdu au change. Bref, je fais ce que je fais de mieux au monde : le vieux râleur grincheux.

Mercredi matin, la carte graphique de mon ordinateur est morte. J'avoue que je ne pensais pas possible qu'un composant purement électronique mourût, et je ne comprends pas bien ce qui a pu se passer : Linux a sorti des messages d'erreur assez bizarres (et a tué le serveur X), j'ai pensé que c'était peut-être un bug, j'ai commencé à compiler une nouvelle version du noyau, mais en chemin l'écran est devenu complètement gris ; la machine marchait encore normalement à ce stade-là, j'ai pu me connecter à distance et rebooter, mais elle a planté au reboot et ensuite n'a plus du tout voulu redémarrer — le BIOS émettait le code (un bip long suivi de trois brefs) qui indique qu'il n'arrive pas à initialiser la carte graphique. Je maudis au passage ces BIOS qui ont besoin d'une carte graphique pour démarrer l'ordinateur (ça fait partie de cette distinction complètement crétine entre machines « de bureau » et machines « serveur » que les fabricants de matos aiment mettre en place pour des raisons commerciales), mais passons.

Digression : Il y a une sorte de malédiction qui fait que quand je commence à ouvrir l'ordinateur pour toucher au matériel qui est dedans, d'autres choses se mettent à poser des problèmes. En l'occurrence, c'est un disque dur qui est mort (il n'a peut-être pas aimé que je gigote le boîtier pour changer la care graphique). Pas un problème : toutes mes données sont en RAID (5 ou, pour la plupart, 6), indépendamment d'autres mesures de backup. Et pas une surprise non plus : je savais depuis longtemps que ce disque dur avait des problèmes et qu'il risquait de mourir (c'est un Seagate, évidemment, voir la note #5 de l'entrée liée ci-dessus). Il se trouvait même que j'avais sur mon bureau un disque dur (Samsung) de 2To qui attendait de servir pour autre chose, et que j'ai pu récupérer immédiatement en remplacement. Après, il y a une autre malédiction qui fait, qu'en informatique, on commence à vouloir faire quelque chose, ça nécessite de faire quelque chose d'autre pour commencer, puis quelque chose d'autre, et on croit ne jamais en finir : en l'occurrence, ce nouveau disque dur Samsung avait potentiellement un bug dangereux de firmware (potentiellement, parce que ces crétins de chez Samsung ont donné au firmware corrigeant le bug le même numéro de version que le firmware buggué, de sorte qu'il n'y a aucun moyen de tester), du coup j'ai voulu flasher le firmware de mon disque. Ce qui passe par l'utilisation d'un utilitaire DOS. Or le seul DOS auquel j'ai accès est FreeDOS, donc j'ai dû me lancer dans la quête secondaire « réussir à produire une clé USB bootable pour FreeDOS » (pour pouvoir flasher le firmware de mon nouveau disque, pour pouvoir remplacer celui qui est mort en même temps mais sans doute indépendamment de la carte graphique, vous suivez ?), et il m'a fallu un bon nombre d'heures pour trouver la solution, qui n'est expliquée à peu près nulle part sur le Web. Bref, j'ai pu flasher le firmware de mon disque (il m'a fait peur parce qu'il ne marchait plus du tout après : en fait, il fallait faire un reboot à froid). Je passe sur une petite merdouille, complètement sans rapport, que j'ai aussi eue avec Linux au passage (je suis passé à un noyau 3.5.x, et maintenant pour faire marcher le clavier et la souris il faut penser à charger le module hid-generic). Je reviens à ma carte graphique.

Je n'ai jamais bien compris ce qui constituait la différence entre les générations successives de cartes graphiques un peu modernes. Ma précédente (celle qui a grillé) était une Radeon HD 3450 (chipset RV620 de la famille R600), la nouvelle que j'ai acheté hier est une Radeon HD 6450 (chipset Caicos de la famille Northern Islands), et mon poussinet a une Radeon HD 5450 (chipset Cedar de la famille Evergreen) que je lui ai donnée pour des raisons que je vais expliquer : entre ces différentes cartes, il y a certainement des différences, mais ce tableau m'éclaire, à vrai dire, très peu. Je me fais vaguement une idée d'une carte graphique comme juste une batterie de processeurs généralistes auxquels le driver va donner à faire plein de calculs de superpositions de triangles ou je ne sais quoi, et je vois mal ce qui peut changer entre les différentes familles à part la vitesse et le nombre des processseurs. Mais bon.

En revanche, il y a une différence que j'ai clairement remarquée, c'est que sur les deux dernières cartes que j'ai achetées (la 5450 que j'ai donnée à mon poussinet et la 6450 que j'ai achetée hier), la sortie VGA ne marche pas correctement. Enfin, je ne sais pas vraiment si elle est défectueuse ou si c'est le moniteur qui est capricieux dans ce qu'il accepte, mais il y a un phénomène d'« écho » à l'affichage (l'image est accompagnée d'un léger reflet, décalé d'une dizaine de pixels sur la droite, c'est particulièrement visible pour une image noire sur fond blanc), extrêmement désagréable. Je soupçonne que presque plus personne n'utilise la sortie VGA, et qu'ils ne la testent pas trop. Ou peut-être que le problème ne se pose que sur les écrans CRT, ou quelque chose de ce goût-là ; ou peut-être que c'est juste mon moniteur dont le connecteur était bizarre (il faut dire qu'il était un peu cassé au niveau des vis). Toujours est-il que quand j'ai acheté une carte graphique fin 2010 (la 5450), j'ai remarqué cette anomalie d'affichage et je l'ai donnée à mon poussinet en échange de sa carte à lui, plus vieille (c'est la 3450 qui vient de griller, elle datait de 2008 environ) et qui n'avait pas le défaut en question[#]. Comme maintenant cette carte est morte, j'ai dû me résoudre à changer d'écran pour utiliser la sortie DVI.

Le truc, c'est que je n'aime pas les écrans LCD. J'avais un moniteur CRT de 17″ acheté en 2003 auquel je tenais beaucoup non parce qu'il était de bonne qualité, mais parce qu'il avait la vertu d'être un CRT, ou plutôt, de ne pas être un LCD. Je reconnais que les LCD ont un gros avantage, c'est d'être beaucoup moins lourds (mon expérience en 2003 de transport de ce moniteur entre la rue de Charenton et chez moi était, disons, douloureuse) et moins encombrants en profondeur. Mais ce que je n'aime pas chez eux, c'est :

• Le rendu des couleurs. Pas tellement le rendu des couleurs dans l'absolu, mais la manière dont le rendu des couleurs varie selon l'angle de vision. Peut-être que les LCD de très haute qualité n'ont pas ce défaut, mais ceux que j'ai les moyens de trouver et d'acheter l'ont, et ça me rend complètement fou : tout plan uniforme visualisé sur un écran LCD se transforme en un dégradé vertical, parce que les pixels du haut de l'écran (vus d'un peu en-dessous, donc) n'apparaissent pas de la même couleur que ceux du bas (vus d'un peu au-dessus). Il y a eu de légers progrès avec le temps, les premiers LCD étaient encore plus insupportables, et d'ailleurs, l'effet était, je crois, plutôt selon l'angle horizontal, et quelqu'un a fini par avoir la bonne idée de s'arranger pour que ce soit au moins selon l'angle vertical (comme ça les deux yeux voient au moins vaguement la même couleur, c'est déjà un progrès), mais je continue à trouver ça extrêmement gênant. Et ce n'est pas seulement que la luminosité varie selon l'angle de vue : c'est aussi qu'elle semble ne pas varier de façon assez peu continue, ou franchement pas monotone, avec l'intensité supposée du pixel ! Prenez l'image ci-contre : si vous ne voyez rien, c'est plutôt normal, il s'agit d'un texte d'un gris très très sombre sur un fond noir ; mais ce qui est bizarre, c'est que sur les LCD que j'ai pu tester, le texte devient plus ou moins lisible quand on le regarde d'en haut ou d'en bas : or je comprends à la limite que la couleur change un peu, mais le noir et le gris très sombre devraient changer de la même manière, et rester très très proche, si bien que le texte ne devrait pas devenir plus ou moins visible. Le fait qu'il le devienne signifie que tous les effets d'anti-aliasing sont cassés sur les écrans LCD, et je déteste ça.
• La résolution. Je ne comprends pas bien l'intérêt d'avoir une résolution élevée. Jusqu'à la semaine dernière, mon écran était en 1024×768 (ce qui, pour un 17″ de format 4:3, fait du 75dpi) et j'en étais très content. Bon, le truc c'est que je suis terriblement myope et astigmate[#2], les pixels à cette résolution sont déjà en-dessous de ce que mon œil est capable de distinguer à moins de regarder de très près. Mon nouveau CRT de 22″ fait du 1920×1080, soit 96dpi, tout ce que j'y gagne c'est que tout est beaucoup plus petit, notamment le texte, et j'ai du mal à le lire. Je sais ce qu'on va me rétorquer : (1) Je n'avais qu'à acheter un écran de moins haute résolution. Ben en fait j'ai pris le moins cher avec une entrée DVI, je suis sidéré que « le moins cher » (en l'occurrence dans les 140€) soit un écran 16:9 de 22″ qui fait du Full HD, mais c'est comme ça. (2) Je peux configurer l'écran pour être en-dessous de sa résolution nominale. Eh bien ça, c'est justement ce que je n'aime pas avec les LCD, c'est que si on fait ça, c'est horriblement moche, alors que sur un CRT il y a un petit flou agréable à n'importe quelle résolution, là c'est vraiment insupportable même pour mes yeux de taupe. (3) Je peux configurer le texte pour être plus gros. Oui, en théorie, mais Linux étant ce qu'il est, il y a un zillions de programmes à configurer chacun différemment, il y en a pour lesquels j'y arrive, d'autres pour lesquels je cherche encore (bon, on m'a donné des conseils précieux, j'ai bon espoir d'améliorer les choses). Et en tout état de cause, ça ne concerne que le texte : c'est un peu délicat de persuader tous les programmes de quelque sorte que ce soit qui auraient envie d'afficher une image de bien vouloir agrandir cette image de 30%, et si possible avec un algorithme un peu plus intelligent qu'une interpolation linéaire.
• L'aspect-ratio. Ce n'est pas directement lié à la technologie LCD, mais je ne crois pas qu'il existe de CRT de format 16:9. Or je trouve le format 16:9 plutôt pénible : ce n'est pas une télé que j'achète, je ne compte guère regarder des films dessus, et à la limite s'il y a une chose que je prends comme modèle pour mon écran, c'est une feuille de papier, et aux dernières nouvelles, les feuilles de papier, pour écrire, on les tient plutôt dans le sens « portrait » où elles sont plus longues que large. C'est normal : quand une ligne de texte devient trop longue on en perd le fil. Disons que le 4:3 était un bon compromis, mais s'agissant du 16:9, je ne comprends vraiment pas l'intérêt d'avoir des écrans si larges (ou plutôt, si peu hauts), à moins d'écrire principalement de haut en bas. Ça prend plutôt plus de place sur le bureau. Or les écrans LCD format 4:3 sont plus chers que les 16:9 (même à hauteur verticale égale, apparemment). Certains me diront : il y a des écrans pivotables, on peut donc les mettre au format 9:16 (portrait) si on veut lire un texte ; malheureusement, ça ne marche pas, parce que si on fait ça, le problème de rendu des couleurs évoqué plus haut fait qu'on voit quelque chose de totalement différent avec l'œil gauche et avec l'œil droit, et le mal de tête est garanti en un rien de temps (je sais, j'ai essayé au bureau).

[#] En plus, en 2010, la 3450 était nettement mieux gérée par Linux que la 5450, donc j'y ai plutôt gagné. Heureusement, de ce point de vue-là, il y a eu du progrès.

[#2] Normalement ça se corrige avec des lunettes. Normalement. Mais mon astigmatisme a l'air d'être trop bizarre, mon ophtalmo n'arrive pas à en mesurer la direction principale à mieux que 20° près environ, et quant à la myopie, il suffit que mes lunettes tombent d'une fraction de centimètre sur mon nez (i.e., tout le temps) pour que la correction passe de correcte à médiocre.

Un des buts de toutes mes mésaventures (finalement heureusement résolues) avec mon DreamPlug (entrées précédentes ici, là, là et là) était de pouvoir éteindre mon PC la nuit ou, plus exactement, le mettre en hibernation, pour qu'il ne fasse plus de bruit.

Hibernation, ce qui peut désigner deux choses, le suspend-to-RAM où la machine n'est pas vraiment éteinte mais seulement arrêtée et maintient sa mémoire vivante, ou le suspend-to-disk où la machine est techniquement éteinte et a recopié sa mémoire sur disque de manière à pouvoir redémarrer dans le même état. Ces deux modes d'hibernation sont censés être supportés par Linux mais, comme d'habitude, le support peut être aléatoire selon le type de matériel, d'autant plus qu'on parle ici d'un PC fixe et que l'hibernation est surtout testée sur des portables. Mon poussinet, par exemple, n'arrive pas à faire marcher le suspend-to-RAM sur sa machine, probablement à cause d'un problème dans la gestion de la carte graphique (le suspend-to-disk, en revanche, marche bien).

Initialement, j'ai trouvé que j'avais de la chance : le suspend-to-RAM semblait marcher parfaitement (le plus gros problème observé étant que l'horloge système se décale d'environ une seconde lors de l'opération, ce qui fait négligé mais est facile à corriger en reprenant l'heure correcte sur le réseau) ; le suspend-to-disk, lui, perd le contrôle du disque externe, ce qui est pénible mais pas catastrophique (il suffit de couper ce disque avant hibernation et le remettre après : comme ce disque ne me sert qu'à stocker des choses comme des musiques ou des films, pas à faire tourner des programmes, ce n'est pas trop gravement gênant), et il y a aussi un petit couac mineur avec le clavier (il faut refaire le mapping, c'est un bug bizarre, mais ça ne fait qu'une commande à taper).

Indépendamment de ça, je trouvais que le ventilateur de mon PC était devenu plus bruyant que d'habitude au redémarrage de l'hibernation : soit que ce soit le contraste avec le silence précédent qui cause cette illusion, soit que le ventilateur vieillisse et que le fait de l'allumer et de l'éteindre le rende plus bruyant. C'est là que j'ai commencé à regarder de plus près les réglages du BIOS parce que, après tout, mon ventilateur est censé être un modèle super silencieux et on ne pouvait pas dire qu'il le fût. Or il existe, dans ces réglages, deux modes de contrôle des ventilateurs : un mode PWM, c'est-à-dire Pulse Width Modulation, où le ventilateur est contrôlé par un signal spécial, et un mode DC où le ventilateur est bêtement contrôlé par la tension appliquée ; apparemment mon ventilateur ne supporte pas le contrôle PWM, et changer vers le mode DC a eu un effet énorme : au lieu de tourner constamment à 2400tr/min, il s'est mis à descendre à 1800tr/min lorsque la machine ne fait rien, ce qui peut ne pas sembler une différence énorme, mais ce qui représente pourtant une diminution considérable du bruit. Presque au point que l'hibernation n'ait plus d'intérêt.

Presque. Mais c'est là que le bât blesse : lorsque je configure les ventilateurs en mode silencieux (et avec le bon type de contrôle), c'est effectivement très confortable pour les oreilles, mais si jamais je mets l'ordinateur en suspend-to-RAM, au redémarrage, les ventilateurs reprennent leur profil de base (bruyant). Autrement dit, je ne peux pas avoir à la fois le réglage relativement silencieux des ventilateurs et le silence total du suspend-to-RAM de temps en temps. Bon, je peux encore faire un suspend-to-disk si je veux le silence complet sans perdre le silence relatif au réveil, mais outre les problèmes mineurs avec le disque externe et avec le clavier que j'ai signalés ci-dessus, le suspend-to-disk est lent (parce que j'ai 8Go de RAM) : quand je fais de l'insomnie et que je veux regarder un truc ou deux sur Internet avant de me recoucher, je n'ai pas envie d'attendre plusieurs minutes que la machine daigne se réveiller.

Je ne sais même pas si je dois attribuer ça à un bug (de l'ACPI) de ma carte mère (une Asus P5W64 WS Pro) ou de Linux. La carte mère et le BIOS doivent bien avoir des bugs puisqu'un suspend-to-RAM non seulement met les ventilateurs en mode bruyant, mais meme ce mode persiste après un reboot, il faut une extinction complète pour revenir en mode silencieux. Sinon, ce qui est sûr, c'est que Linux devrait être capable de régler lui-même la vitesse des ventilos, mais qu'il n'y arrive pas : il devrait même y avoir deux approches possibles, l'une passant par l'ACPI (module noyau asus-atk0110) et l'autre en parlant directement au matériel (module noyau w83627ehf), et qu'aucune des deux ne marche, dans les deux cas c'est apparemment la faute d'Asus : d'un côté je crois comprendre qu'il manque des interfaces dans l'ACPI, de l'autre je crois comprendre qu'ils n'ont pas publié les specs d'une puce utilisée sur cette carte mère. (J'avoue que l'idée de garder secrètes les spécifications détaillées de quelque chose d'aussi high-tech qu'une puce qui contrôle des putains de ventilos, ça m'échappe un peu : pensez à me rappeler de ranter contre les compagnies qui ont la culture du secret, comme ça, pour des trucs totalement débiles. Mais peut-être que j'ai mal compris.) Ou peut-être que Linux ne sait gérer que les ventilateurs utilisant le contrôle PWM, mais je ne vois pas pourquoi le BIOS arriverait à faire mieux, alors.

On est censé pouvoir désassembler le code de l'ACPI avec des outils comme acpidump, acpixtract et iasl, mais c'est assez chinois et je ne sais pas si je veux passer des heures à essayer d'y comprendre quelque chose, d'autant plus que le problème n'est peut-être même pas là.

J'ai parfois un peu tendance à penser que c'est encore plus frustrant quand l'informatique marche à 99% que quand elle marche à 0%, parce qu'à 99% on a l'impression qu'on pourrait y être, on a la vision du monde parfait qui nous nargue et qui reste cependant inaccessible, alors qu'à 0% au moins les choses sont claires. Le chemin de l'enfer est pavé de petites crottes de ragondin.

The story so far: I bought a Marvell DreamPlug in the hope of using it, among other things, as a Wifi access point. The DreamPlug's own Wifi chipset does not work in access point mode, so I bought some Wifi USB dongles with an Atheros AR9271 chipset that reportedly works well under Linux. Which it does, except that I discovered that if the system is rebooted after Wifi driver has been initialized (by loading the kernel modules), then it gets stuck into a mode where it no longer works and the only way to correct this seems to be by physically removing and reinserting the dongle (every other attempt at provoking a USB reset has failed to do anything but perhaps confuse the system).

Well it turns out my analysis was a bit wrong, and the problem isn't as bad as I thought. What causes the dongle to enter this « stuck » state in which it can no longer be used except by unplugging and replugging it is actually if the system is reset after the driver has been initialized (e.g., modprobe ath9k_htc) but before the Wifi interface is activated (e.g., ip link set wlan0 up). Once the interface is activated, even if it is deactivated later on, or if the modules are removed, or even in case of a sudden reboot, whatever, things appear to be fine: trouble only happens if a reboot happens in the window between loading the module and activating the interface. So this is actually very benign: I can make sure I will always activate the interface immediately after loading the modules, and the probability that a reboot will happen just between the two events is almost negligible.

The reason I didn't understand the exact circumstances triggering the bug, of course, is that I made my tests with minimal intervention, i.e., just loading the modules, and I didn't for a second think that activating the Wifi could fix anything. And I have a hard time imagining how that sort of bug could be caused (I guess loading the module does part of the chipset initialization and activating the interface does another part, but why should a reboot create a problem when simply unloading the modules does not?). I still think it's really wrong that this kind of things could happen, it's probably the sign of sloppy writing or general flakiness, but it could also be the hardware that is buggy in various ways (and, of course, tested under a very limited set of conditions, i.e., an Intel-based PC under Windows or Mac OS, definitely not an ARM embedded device). Whether this will ever be fixed is anybody's guess.

Anyway, now I can turn my attention to the software part of the problem, i.e., how I should reconfigure my network to use this DreamPlug thingy as a router.

The story so far: I'd like to have a completely silent PC that can act, among other things, as a Wifi access point. The DreamPlug I bought is supposed to have a Wifi chipset, but—apparently due to Marvell's greed and/or stupidity—, Linux does not support it in access point mode. So I bought a Wifi USB dongle (TP-LINK model TL-WN422G) with a chipset (Atheros AR9271) that is known to be well supported by Linux (ath9k_htc module) even in access point mode. And, indeed, it works when I plug it in. End of the story? Nay, for a new villain now enters the scene: USB resets.

For here is the problem: I wrote that the dongle works when I plug it in. If, however, I reboot the DreamPlug while the dongle is plugged in (and if the latter has been initialized by Linux), Wifi no longer works after the reboot (ath9k_htc fails to initialize the dongle, providing the following uninformative error message: Target is unresponsive). When it gets into that state, no software operation I could try can get it to work again (hot or warm reboots, targeted USB resets, nothing will do): only physically unplugging and replugging the dongle, or power-cycling the DreamPlug, will make it work again. Completely reproducible.

It is maddening, in fact, and it makes little sense: if the ath modules are unloaded and loaded again, no problem is caused (that doesn't solve the problem, but it doesn't cause it either). However, if they have been loaded, even if they are properly unloaded before reboot, no matter how the reboot is performed short of a power-cycle, the dongle stops working. (At my lovebird's suggestion, I even tried kexec to see whether it amounts to a reset, but I was unable to get it to boot the kernel, so I can report nothing there.)

I have tried all conceivable ways to provoke a cold USB reset, ideally to suspend or power off the dongle (and the dongle alone), but a “simple” USB reset such as provided by this program does not help, and I've been unable to cause Linux to power off the dongle completely (I suspect the DreamPlug's USB controller isn't capable of power management of this sort, and this might, in fact, be a partial cause of the problem).

This is killing me. I felt so close to having something which I would be satisfied with, I was so happy to confirm the dongle worked… that when it stopped working I thought I had been cheated of a rightfully deserved victory over adversity (OK, I may be painting the picture a tad too colorful there, but I was—and I still am—furious).

I asked for help on the linux-wireless mailing-list, but I don't really think I'll get any: for one thing, it seems more of a USB problem than a Wifi problem (but I doubt anybody on the USB subsystem would be interested), and for another, the problem is too complicated to gather real attention (it's not it doesn't work, it's it doesn't work after a reboot and may be tied to a specific dongle or a specific USB host). And I'm pretty pessimistic as to whether anything can be done: if the USB host adapter is fucked up and does something weird on reset, it's fucked up, that's all there is to it and it can't be changed.

And I don't know what to do now. I've ordered another dongle having the same chipset, in the forlorn hope that maybe it's a problem with the USB interface of that specific dongle that will not occur with a different model, but I don't really believe it. I'm afraid it all I'll end up doing is to keep my noisy PC and stash the embarrassing DreamPlugs somewhere (in the vague hope that eventually Marvell might come to their senses and provide master mode support under Linux for their chipset).

Update: Turns out the problem isn't as bad as I thought: see a later entry for details.

My adventures with the DreamPlug seemed suspiciously undisastrous, so I assumed there was something deeply wrong waiting to pounce on me. Indeed.

To explain what it is, I should first emphasize the following simple point about Wifi: a typical Wifi has two kinds of participants: one is called an access point and operates in master (or access point) mode, and basically controls the network, it could be said to be the Wifi server, whereas all other participants are clients and operate in managed (or station) mode. (This is much simplified, as complex networks can also have repeaters, and there are other kinds of networks such as ad hoc or mesh. But your typical Wifi network is as I just said, with the hotspot being the master and all computers connected to it being managed stations.)

Obviously, since I wish to use my DreamPlug as a Wifi server/switch (among other functions), I need master mode to work[#].

Now the bad news in general is that master mode almost never works under Linux. That is, there are dozens of families of Wifi chipsets around, most of them are said to be well supported by Linux, but that is something of a lie: in reality, they are well supported in client mode only, and almost no drivers support master mode. Basically only the Atheros chipsets work really well (ath5k and ath9k) (this page may give a different impression, but in reality nearly all the drivers having a yes in the master mode column are obsolete, not well integrated in the stock kernel, not supporting the present kernel API, or have some other major flaw about them).

This is something I was well aware of. I had done some research before buying the GuruPlugs and DreamPlugs, however, and believed to have learned that master mode was supported on their Wifi chipsets using a free software Linux driver written by Marvell (uap8xxx) which, although of dubious quality, is probably destined to be included in mainline Linux kernels eventually. I can certainly live with a subpar driver for some time. Also, I don't care much that the driver needs an opaque firmware blob to run[#2].

However, here's something I didn't know, and couldn't have discovered because there's almost no indication of it anywhere on the Web: there are two different Marvell Wifi chipsets found on these GuruPlugs and DreamPlugs: the SD8688 and the SD8787. My GuruPlugs have the former while my DreamPlugs have the latter (however, the distribution may not be along the GuruPlug/DreamPlug line in all cases, I don't know). Support for them in Linux is very different. The (older) SD8688 is supported in Wifi client mode using the libertas driver in stock kernels or a driver from Marvell called sd8xxx (whose source code was released); and it is also supported in master mode using the uap8xxx driver from Marvell (whose source code was also released). This is what I had learned and from which I thought it was safe to conclude I could use the Wifi on my DreamPlugs in master mode. The newer SD8787 is not the same chip, and apparently needs different drivers: it is also supported in client mode on stock kernels, the driver being then called mwifiex; however, this driver does not support master mode (just like nearly all Linux Wifi drivers, as I already pointed out). Merely to understand this fact cost me hours of my time, because I had no idea there were two different chipsets involved, and I was lost in a twisty maze of kernel modules whose functions I could not discern.

But then how can the DreamPlug claim to function as a Wifi access point? Now that's the part that really makes me want to murder someone: Marvell wrote a proprietary driver to support Wifi master mode. And apparently these assholes don't intend to release the source code (it seems they must believe that there's some kind of secret to be kept in the source code of a Wifi driver). Even leaving aside any question as to the desirability of free software in principle, their proprietary driver is hopelessly useless, because it works with exactly one kernel version, and that (very old) kernel version has so many known security holes in it that nobody in their right mind would use it on a computer connected to the Internet. Like, you know, a Wifi access point tends to be. I mean, I hate proprietary drivers, but if you're going to write one, you could at least do it the way nVidia does, providing some interface glue around a binary blob so you're not pinning the kernel to exactly one bloody version, especially, you know, one which is pretty much unusable. Oh, and it happens to be named 2.6.33.7-dirty, probably because dirty is exactly what describes the minds of whoever is responsable for such sheer idiocy.

To add insult to injury (I mean, apart from that insult of the kernel being called dirty), the proprietary driver in question, or at least one component of it, has the same name (sd8xxx) as the free driver they wrote for the other of the two chipsets. This means it is almost impossible to know what people are talking about, and very easy to be misled (as I was) into thinking that the DreamPlug supports master mode.

Now I don't know what hope I can have that the situation will evolve. The mwifiex driver (recall that this supports the SD8787 chipset I have, but only in client mode) is being developed by Marvell, so it's not like having two different versions, one with master mode and one without, were not intentional. I can hope that they'll eventually realize that keeping a fucking Wifi driver secret makes no sense whatsoever, but companies are notoriously bad at understanding their own stupidity. I don't know.

I also don't know how difficult it would be, in principle, to produce a driver which supports master mode from one which does not. My naïve view of things is that all a Wifi hardware driver should have to do is provide two functions, send packet and receive packet (OK, make that three with choose channel), and all the stuff about modes, associations, crypto and whatnot, could be handled (in software) in a generic, device-independent way. I'm aware that this is naïve, there's obviously some hardware support for crypto, possibly other stuff like MAC filtering, association lists, or I don't know what. But I still don't know why the hardware driver has to specifically support master mode rather than just accelerating it. Consequently, I have no idea how difficult it is to write that support, assuming, say, you only get to see the hardware specs necessary to write a driver supporting client mode.

In the mean time, it seems I have paid a couple of hundred bucks for a piece of equipment that is completely useless for what I wanted to do with it. Thanks a lot, Marvell!, I'll try to remember that next time I consider buying anything from you or advising someone about your products.

Update (2012-03-18T13:05+01:00): I decided the simplest way out of my conundrum was to give up on Marvell's crappy chipset and buy a couple of USB Wifi adapters that are known to work well (even in master mode) under Linux.

[#] Actually I'd like even more: I'd like it to be possible to have several virtual Wifi networks on the same channel and access point, so I could have both an open network and an encrypted one with different filtering rules. This is why I can't just take an embedded Wifi access point and plug it into my network. Along with the fact that embedded Wifi access points don't let you fine tune some of the parameters I'd like to fix, like the beacon rate or the rekey interval for group transient (aka broadcast/multicast) keys. But, hey, basic support for master mode would be a good start.

[#2] Depends on what the blob does, of course, but I don't have the same religious principles as Debian or the FSF on that matter: I'm willing to pretend the firmware is just some large data table or a magic number that needs to be inserted into the device for it to function. As long as the firmware doesn't run on my CPU, and activates all functions of the hardware, say.

Update on the mess: I was finally able to compile a kernel for my DreamPlug that I'm happy with, and which can boot under any version of U-Boot.

I've written this to summarize some of my findings. Probably of no interest to regular readers of this blog, but it will help me remember what I've found, and it might be of use to someone stumbling on this page using Google.

One of my recurring, probably never-to-be-achieved, dreams, is to own a small, completely noiseless PC that I could leave running 24/7/365 for use as a router, Wifi access point, and server for some basic services (such as NTP and DNS), so as to turn off—or at least, suspend—my main desktop PC at night. The current fad in this area is currently the Raspberry Pi, which is undoubtedly a wonderful gadget, and I'll probably get one eventually, but it doesn't quite match my criteria. (As a matter of fact, there are zillions of similar embedded devices which come quite close to what I want, but never actually there. One of my more outrageous demands is that I want two gigabit Ethernet connectors plus Wifi, and that's where mostly everything fails, except for a few things which are build for use as switches but then they don't satisfy me for other reasons.)

My last attempt at substantiating this dream came in the form of the GuruPlug by GlobalScale Technologies. But I was pretty pissed off when it turned out that the gadget, while it matched my more difficult criteria (dual gigabit Ethernet plus Wifi, eSATA, yada yada) utterly failed in the simple but crucial condition of being silent. Seems it was a design error: they had hoped to make it fanless, but it was found to overheat, and they added the fan ex post facto, making the dang thing pretty much pointless. So, I have two of these GuruPlugs Server ExtraNoisy Deluxe on my hands and I still haven't found any use for them.

Well, later GlobalScale came to realize the evil of its ways and amended them by releasing a new product, the DreamPlug. It differs from its older sibling in two important respects: (1) this time it is truly fanless, hence noiseless, and (2) the internal NAND memory used for permanent storage has been replaced by a removable µSD card, making the device easier to unbrick[#] in case something goes wrong. I resisted buying this DreamPlug for some time, because I was really annoyed by the fiasco of my previous purchase at GlobalScale, but in the end resistance was futile and I bought myself a pair of DreamPlugs. They were delivered to me on Monday.

⁂

Well, I have no gripes with the hardware, now: the DreamPlug is, indeed, completely silent, and from what I have seen so far, it seems to work well. No gripes apart from the general fact that the ARM architecture is a chaotic mess: there seem to be a zillion kinds of ARMs, each with a zillion subtypes and sub-subtypes. And as a consequence of this fragmentation, I ran into a number of software problems which I may or may not be able to solve (but which will probably solve themselves on their own: that's the nice thing about software problems as opposed to hardware ones).

The DreamPlug comes with a Linux distro which is essentially Debian with a custom kernel, including a number of custom drivers (essentially for Wifi), and a custom bootloader. And a number of hastily bundled scripts which were installed by raping the Debian package manager with gravel. Anyway. It works. But I hate badly customized distros and customized kernels, so I'd like to reinstall a fresh Debian (or Ubuntu) on the box. But it's not that simple.

The bootloader (also serving some kind of BIOS functions) used to boot Linux on the ARM architecture is something known as U-Boot. Now Marvell provides a specifically patched U-Boot for this device, which has some annoying limitations, such as not being able to load files from ext2 filesystems: so I thought I'd try a more recent U-Boot provided by Debian (u-boot_2011.12-2_armel.deb), and which is said to support the DreamPlug. Reflashing U-Boot is ridiculously complicated (one takes control of the machine through JTAG using the OpenOCD program, but unfortunately OpenOCD cannot directly flash the particular kind of nonvolatile memory used on the DreamPlug — as opposed to the GuruPlug — so one must go through a strange process of loading the new U-Boot to RAM, booting it there, and using U-Boot itself to reflash itself); but I managed it. However, (1) the U-Boot taken from Debian is incapable of booting the kernel provided by Marvell (it just gets stuck after Uncompressing Linux... done, booting the kernel.), and (2) the Debian kernels for Kirkwood apparently do not support the DreamPlug (as such, they refuse to boot, complaining that they don't know the machine identifier 0xdde; and if I try to trick them in using identifier 0xa63 which is that of the GuruPlug, they fail a bit later on).

So Marvell must have patched both their U-Boot bootloader and kernel in a way that each is compatible only with the other. The details escape me, though it is obviously must have something to do with the annoying mechanism of machine identifiers used by the ARM architecture. And whatever the excuse of ARM being fucked up in the first place, Marvell must have fucked it up some more for their Linux kernel to be unbootable by a standard U-Boot (conversely, their patched U-Boot is said to be able to boot standard kernels, but only with a special option mainlineLinux option and by fiddling with the machine identifier): what a mess! And the enormity of having to use a specific bootloader to load a specific kernel is such that it defeats the whole purpose of a bootloader, namely: to boot more than one kernel.

I thought I'd step out of the mess by avoiding any Marvell patches altogether and using a recent mainline kernel to boot with the standard U-Boot. And when I say recent, I mean essentially today's snapshot of the ARM SoC tree (merged with the 3.3.0-rc7 fixes from the Linux tree). It is supposed to support the DreamPlug, according to this commit (and a couple of later ones): I really don't know why support for a device that has been commercialized for well over a year has only begun finding its way in the kernel a few weeks ago; but unfortunately another problem is that said support is taking the form not of recognizing the infamous machine ID (0xdde) but using something known as a flattened device tree which is a kind of machine description file: only this requires an even newer U-Boot, and it seems I have entered a world of pain.

So in the end, I wasted more than five hours first creating an ARM cross-compiler[#2] and then tediously configuring the kernel (the number of choices to be made is frightening; and even by merging several known configurations it was still a pain in the ass) to get a kernel that simply does not boot and I have no idea why (the most useful message I elicited from it was: Kernel panic - not syncing: ERROR: Failed to allocate 0x1000 bytes below 0x0. — and that's with Marvell's U-Boot because with the standard one it didn't even get that far).

The moral of this is that I probably should have stuck with the working system provided by Marvell, but I still hate it and hate the idea that the system needs specific patches to function. And judging by the patch needed to provide master mode support on the Wifi chipset (which is so obviously a badly fangled port of a Windows driver), I'd like to stay clear of any code of this sort.

The dust will settle eventually, I guess, and maybe someday Linux will run correctly on a device that was, after all, specifically made to run Linux. But in the mean time, I can't say its performance has been brilliant.

⁂

[#] Remind me to rant someday about the fact that it ought never to be possible to brick an electronic device of any kind by purely software means.

mkdir /opt/arm-linux-gnueabi
mkdir /opt/arm-linux-gnueabi-tools
dpkg-deb -x libc6_2.13-27_armel.deb /opt/arm-linux-gnueabi
dpkg-deb -x libc6-dev_2.13-27_armel.deb /opt/arm-linux-gnueabi
dpkg-deb -x linux-libc-dev_3.2.6-1_armel.deb /opt/arm-linux-gnueabi
(cd /opt/arm-linux-gnueabi/usr ; tar cf - *) | (cd /opt/arm-linux-gnueabi ; tar xf -)
rm -rf /opt/arm-linux-gnueabi/usr
ln -s . /opt/arm-linux-gnueabi/usr
cd /tmp ; apt-get source binutils
cd binutils-2.22
./debian/rules patch
mkdir /tmp/binutils-build
cd /tmp/binutils-build
/tmp/binutils-2.22/configure --target=arm-linux-gnueabi --prefix=/opt/arm-linux-gnueabi-tools --enable-shared --enable-plugins --with-sysroot=/opt/arm-linux-gnueabi
make -j4 && make install
cd /tmp ; apt-get source gcc-4.6
cd gcc-4.6-4.6.3
DEB_CROSS_NO_BIARCH=yes ./debian/rules patch
mkdir /tmp/gcc-build
cd /tmp/gcc-build
/tmp/gcc-4.6-4.6.3/src/configure --target=arm-linux-gnueabi --prefix=/opt/arm-linux-gnueabi-tools --with-sysroot=/opt/arm-linux-gnueabi --enable-languages=c
make -j4 && make install

Mon poussinet voulait lire des textes dont je lui avais parlé, que mon papa avait écrit quand j'avais dans les 12–14 ans (soit vers 1988–1990), les Life and Times of Altcee (mon père les écrivait pour se moquer de moi, j'en reparlerai dans une prochaine entrée [ajout : voir la suivante]). Problème : la seule copie de ces textes était, apparemment, sur une disquette 5¼″ de 360ko ; je pense que le fait qu'il n'y en ait pas eu d'autres copies est lié à un crash de disque dur que nous avons eu vers 1995, à une époque où les backups étaient rares et chers : déjà, c'est un peu un miracle que cette disquette ait survécu et qu'on ait pu la retrouver (sans parler du miracle que les données dessus n'aient pas été effacées par le passage de 22 années, mais je m'avance). La disquette étant rangée avec les archives de mon père, elle avait échappé à la grande séance de conversion de toutes mes disquettes en un seul CD (lui-même réarchivé depuis sur plusieurs disques durs) à laquelle je m'étais livré en 1999 quand je pressentais la disparition prochaine du format.

Mais alors essayez de trouver, de nos jours, un lecteur de disquettes 5¼″ : ce n'est pas une mince affaire. Déjà, un lecteur de 3½″ n'est pas évident, enfin, c'est encore vaguement faisable (quoique ce sera forcément un truc mal fabriqué qui va plutôt s'occuper de bouziller les supports que les lire), mais un 5¼″, c'est un peu comme chercher un grand-bi chez un marchand de vélos.

Mon poussinet en a emprunté un auprès d'un responsable informatique de la fac de Bordeaux (où il fait sa thèse). Un autre miracle en notre faveur est que les cartes mères même raisonnablement modernes continuent à fournir la connectique pour brancher un lecteur de disquettes, et heureusement cette connectique est formellement identique entre les lecteurs 5¼″ et les 3½″. Formellement, parce qu'en fait, même si la nappe est la même, la fiche n'est pas la même, et les nappes que j'avais n'avaient pas le connecteur pour les 5¼″. Bon, nous avons quand même trouvé, parmi nos amis, quelqu'un qui avait encore une nappe appropriée et un autre lecteur avec lequel tester en cas de problèmes avec le premier. Je passe sur une nouvelle difficultée due au fait que le câble ne se branchait pas bien dans la carte mère à cause d'un détrompeur trop proéminent.

Le BIOS des ordinateurs modernes, si tant est qu'il gère encore les lecteurs de disquettes, ne prévoit apparemment plus qu'on puisse y mettre un 5¼″. En tout cas, celui de mon poussinet n'offrait que deux options pour configurer le lecteur : 3½″ de 720ko ou bien 3½″ de 1440ko ; nous avons parié sur le fait que Linux arriverait quand même à faire quelque chose du lecteur, mais c'était loin d'être évident. Sur tous nos essais, il n'arrivait à lire que les premiers 4ko de données, c'est-à-dire un peu moins qu'une piste. Pour préciser les choses, les données sur une disquette sont organisées en cylindres concentriques, au nombre de 40 sur celles qui m'intéressent, chaque cylindre étant formé d'une piste sur chaque face de la disquette lorsque celle-ci est double-face, donc 80 pistes dans mon cas, et chaque piste étant divisée en un certain nombre de secteurs, ici 9, de 512 octets chacun : les 360ko de ma disquette sont donc 40×2×9×512 octets. Connaître cette géométrie était certainement un prérequis pour arriver à lire quoi que ce soit, mais quelle que fût la façon dont nous prétendions l'expliquer à Linux, il se limitait à lire les 8 premiers secteurs (sur 9, donc) de la première piste, et échouait avec des erreurs d'entrée/sortie sur tout le reste. Nous avons gardé espoir parce que ça semblait peu vraisemblable que toutes les disquettes de la boîte fussent abîmées exactement de la même façon, ou que les deux lecteurs eussent le meme défaut : et si le problème était logiciel, on devait pouvoir le contourner.

Finalement nous sommes tombés sur le programme fdrawcmd, qui permet d'envoyer des commandes bas niveau au lecteur de disquette : cet utilitaire prend beaucoup de paramètres incompréhensibles, et nous n'avons réussi à nous en servir qu'une fois tombés sur cette page qui nous a donné une clé qui nous manquait, à savoir que pour lire une disquette de 40 cylindres sur un lecteur en supportant 80, il faut demander de positionner la tête au cylindre numéro 2×i avant de lancer la lecture du cylindre numéro i. Si d'aventure ça pouvait servir, voici le script qui a fini par marcher :

#! /bin/sh
fdrawcmd drive=/dev/fd0 rate=1 readid 0 need_seek track=0
for i in `seq 0 39`; do
    fdrawcmd drive=/dev/fd0 seek 0 $((i*2))
    fdrawcmd drive=/dev/fd0 rate=1 read 0 $i 0 1 2 9 0x1b 0xff length=9216
done

Ceci étant fait, nous avons eu la bonne surprise de voir que toutes les disquettes étaient lisibles sans une erreur, malgré leur âge. Ensuite, je savais bien que Linux pouvait lire le système de fichiers du DOS, mais là où j'ai eu une nouvelle heureuse surprise c'est que LibreOffice savait lire le format WordPerfect5 de 1990 dans lequel le texte était écrit, y compris pour les notes en bas de page et quelques autres fioritures.

Toujours est-il que le fichier altcee.wp5 est maintenant parmi mes fichiers celui à la date de modification la plus ancienne (1990-06-04T21:40:04+02:00 : en termes informatiques, ce n'est pas tout à fait de la paléontologie, mais c'est au moins de l'archéologie).

Un des domaines où Linux est incroyablement et obstinément nul, au point que ça en devient presque comique et en tout cas extrêmement embarrassant, c'est l'accélération graphique 3D. En fait, plutôt que comique, ça en devient très problématique, parce que de plus en plus de sites Web sont accessibles uniquement par les navigateurs supportant le WebGL (c'est-à-dire l'extension à l'élément <canvas> du HTML5 permettant d'accéder à l'accélération 3D depuis le navigateur). Par exemple l'extraordinaire site Web d'anatomie humaine bodybrowser.googlelabs.com. Or il n'y a quasiment aucune combinaison de matériel, pilote graphique et navigateur qui permette effectivement d'avoir du WebGL accéléré en matériel sous Linux.

Récapitulons pour ceux qui n'y connaissent rien. D'abord, quand je parle de 3D, il ne s'agit pas de ce qu'on aurait au cinéma en 3D (par vision stéréoscopique), mais de représentation 2D d'images 3D calculées par une technique dont je ne connais pas le nom (mais qui s'oppose à celle du raytracing) et qui consiste à trianguler (=décomposer en petits triangles) les surfaces à projeter et à faire des calculs de rendu de surface (ombres portées, textures, etc.) sur ces triangles pour les afficher finalement en 2D. Tous les jeux sur ordinateur modernes utilisent cette technique. Et l'enjeu est tellement important qu'on a développé des cartes graphiques (actuellement toutes les cartes graphiques) qui sont capables de faire en matériel les principaux calculs nécessaires pour cette technique : on appelle ça l'accélération 3D matérielle (et les cartes en question sont beaucoup, beaucoup plus rapides que le processeur principal dans leur domaine de compétence). Encore faut-il que le logiciel derrière soit capable de s'en servir, c'est-à-dire, d'avoir les bons pilotes, les bonnes bibliothèques, etc. (et éventuellement le bon navigateur s'il s'agit de WebGL et que c'est une page Web dynamique qui veut bénéficier de cette accélération).

Les principales cartes (ou puces) graphiques du marché se rangent en trois familles : celles des constructeurs nVidia, ATI qui a été racheté par AMD, et Intel (ce dernier se concentre plutôt sur les puces graphiques pour portables alors que nVidia et ATI/AMD font plutôt des cartes graphiques pour ordinateurs de bureau). Il y a sans doute des différences de vitesse entre ces différentes cartes, cruciales pour les gamerz qui comptent les fps (frames per second) comme d'autres comptent les centimètres de leur bite, mais pour quelqu'un comme moi qui voudrais juste pouvoir accéder à des sites WebGL assez basiques, cela n'a aucune importance, je veux juste quelque chose d'un peu plus rapide que de la 3D non-accélérée (=rendue en logiciel).

Autrefois, Linux avait une bonne excuse : les fabricants de cartes graphiques ne publiaient pas les spécifications de leurs cartes (ou du moins, seulement sous signature d'un accord de non-divulgation), parce qu'une idée parfaitement stupide abondait chez eux selon laquelle il valait mieux que leur matériel ne marchât pas du tout que d'en faire paraître le mode d'emploi avec lequel, horresco referens, on risquerait de, euh, je ne sais pas, de s'en servir je suppose. Sans spécifications, pas moyen d'écrire un pilote, et l'histoire s'arrêtait là. Maintenant, les choses ont un peu changé : si nVidia persiste dans cette stratégie grotesque, en revanche lorsque AMD a racheté ATI, ils ont inversé la politique et ont publié en 2007 de gros manuels de programmation de leurs puces graphiques (je crois que c'était pour les puces récentes). Quant à Intel, ils sont plutôt ouverts sur la question, même s'il y a des changements occasionnels comme on en a l'habitude avec ce genre de grosse compagnie. Toujours est-il que si j'ai applaudi lorsque ATI a libéré les spécifications de ses puces, j'espérais voir un pilote utilisable apparaître en un an ou deux. Ou trois. Mais quatre ans plus tard, c'est vraiment embarrassant à quel point le progrès est nul. (Et ce n'est pas faute de moyens : il y a des développeurs qui bossent vraiment dessus, y compris des développeurs payés par le constructeur.)

La première chose qui pose problème, c'est que plus Personne N'Y Comprend Rien®. Autrefois, pour faire de la 3D sous un Unix à la Linux, il y avait plusieurs approches possibles : (1) faire les calculs purement en logiciel (c'est-à-dire, sans accélération matérielle, donc sans besoin de matériel spécifique, mais en échange de quoi tout sera très lent), ce qui peut vouloir dire (1a) faire les calculs côté serveur (le serveur, dans la terminologie X11, étant l'ordinateur, ou le processus, qui affiche vraiment l'image sur l'écran) ou bien (1b) faire les calculs côté client (le client, dans la terminologie X11, étant l'ordinateur ou le processus qui fait tourner le programme graphique), la distinction étant pertinente parce que le système X11 est un protocole client-serveur, ce qu'on a tendance à oublier de nos jours ; ou bien (2) utiliser une accélération matérielle côté serveur, c'est-à-dire que le client (qui peut très bien tourner sur un ordinateur différent) fait passer au serveur des demandes d'affichage de triangles (ou je ne sais quoi d'autre) et le serveur les refile à la carte graphique rattachée à l'écran. Pour une raison d'efficacité, on a introduit une nouvelle possibilité, (3) le direct rendering, par laquelle le client graphique parle directement à la carte graphique sans passer par le serveur (il a juste demandé une sorte d'autorisation générale au serveur). Je crois que c'est quand on a introduit ça que tout a foutu le camp ; a commencer par la possibilité (2) d'avoir de l'accélération 3D matérielle en faisant tourner le client graphique sur une machine différente du serveur qui gère l'écran : personne n'est capable de me dire si cette possibilité existe encore sur les X.org/Linux modernes ; et je ne parle pas de la sécurité, parce que permettre à un programme non privilégié de parler à la carte graphique qui a un accès direct au bus mémoire et pas trop de notion de permissions, c'est ouvrir un trou de sécurité de la taille du Brésil dans le modèle de sécurité de l'ordinateur. Toujours est-il que l'idée de faire de l'accélération 3D matérielle sans ce direct rendering a l'air d'avoir complètement échappé à tout le monde (pourtant, j'en ai vu, ç'eut été possible).

Là-dessus, il y a toute une salade de sigles et de termes dont on ne sait pas ce qu'ils recouvrent au juste : il y a OpenGL, qui est une sorte de standard pour les primitives graphiques 3D, et qui a l'air atrocement mal foutu parce que personne n'a l'air d'accord sur ce qu'il contient exactement. Il y a Mesa, qui est apparemment l'implémentation libre d'OpenGL et qui a l'air de servir dans un sous-ensemble des cas (1a), (1b), (2) et (3) évoqués ci-dessus, mais c'est absolument impossible de savoir exactement lesquels (peut-être tous, mais rien n'est moins clair). Il y a des choses nébuleuses appelées libglu, libglut, libosmesa et encore d'autres, dont je n'ai aucune idée de ce qu'elles font (enfin, si, un peu : les deux premières sont des surcouches sur OpenGL, et la troisième permet de faire des calculs 3D offline, c'est-à-dire sans les afficher effectivement à l'écran). Et il y a des choses dans le noyau Linux et dans le serveur X.org qui parlent entre eux, et tout cela est ficelé de la façon habituelle en informatique, c'est-à-dire qu'on peut trouver des explications techniques très précises sur chacun des bouts, mais aucune documentation synthétique pour décrire comment les différentes pièces du puzzle s'assemblent.

Globalement, pour faire de la 3D accélérée sous Linux, au moins dans la solution (3) (les autres, comme je le disais, je ne sais pas s'ils existent encore), on a les possibilités suivantes : (α) avoir une carte nVidia avec le pilote propriétaire fourni par nVidia (qui souffre de quantité de défauts, par exemple de ne pas gérer correctement le XRandR, et de casser à chaque version de Linux, mais qui au moins marchouille) ; (β) avoir une carte nVidia avec le pilote libre Nouveau (non, ce n'est pas un nouveau pilote, enfin, si, ç'en est un, mais c'est surtout un pilote qui s'appelle Nouveau) ; (γ) avoir une carte graphique AMD/ATI avec le pilote libre Radeon ; ou (δ) avoir une puce graphique Intel (typiquement, mais pas exclusivement, sur portable) et le pilote libre qui va avec. (Il est possible qu'il y ait d'autres options, je ne les connais pas bien.) J'ai une machine avec chacune de ces possibilités, et je peux confirmer la chose suivante : rien ne marche. Enfin, (α) marche un peu, si d'une part on n'est pas un intégriste du logiciel libre (ou plus pragmatiquement si on est prêt à laisser nVidia prendre le contrôle de son ordi avec un énorme blob binaire dont on ne sait pas ce qu'il peut contenir) et si d'autre part on veut bien supporter leur politique de distribution vraiment pénible. Pour les gens qui veulent du libre, optez pour (β)–(δ), et là vous aurez vraiment la garantie que ça ne marche pas du tout.

Oh, il est censé y avoir des choses. Certains vous diront que, si, si, Nouveau fait maintenant de la 3D accélérée, ou que Radeon marche correctement, ou qu'ils n'ont pas de problème avec leur puce graphique Intel. Reste que les problèmes sont tellement nombreux et les pilotes tellement buggués que Firefox 4, qui a introduit le WebGL, décide de désactiver cette extension dans tous les pilotes Linux autres que le pilote propriétaire nVidia (ce que j'ai appelé (α)). On peut demander à la réactiver de force en lançant Firefox avec la variable MOZ_GLX_IGNORE_BLACKLIST=1 : j'ai essayé, et j'ai réussi à planter Firefox, à planter mon serveur X, mais jamais à avoir le moindre bout de WebGL qui marche — donc ce n'est pas une blague. Même son de cloche du côté de Chrome/Chromium. (Et je précise que j'essaie avec le noyau 2.6.38.3, X.org 7.6, Mesa 7.10, un pilote Nouveau de moins d'une semaine, et Firefox 4 ou Chromium 10.0.648.205.)

Certes, on peut quand même avoir du WebGL sans accélération (solution (1b)) : sous Firefox 4, il s'agit essentiellement d'installer la bibliothèque libosmesa version 6 et de configurer webgl.osmesalib pour en donner le chemin (typiquement /usr/lib/libOSMesa.so) ; mais c'est tellement lent que j'ai tout de suite craqué.

Mais le pire, c'est que non seulement l'accélération 3D ne marche pas, mais l'accélération 2D ne marche plus non plus. Autrefois ces choses étaient bien séparées : maintenant, la 3D est devenue tellement importante que les cartes graphiques rapportent tout à ça, tant et si bien que si on veut avoir de l'accélération 2D (pour voir un film, pour déplacer les fenêtres de façon fluide, etc.), il faut plus ou moins que la 3D marche. Sur celle de mes machines qui utilise le pilote Radeon ((γ) ci-dessus), par exemple, j'ai de l'accélération 2D, mais uniquement sur le premier serveur X que je lance : que je m'avise d'en ouvrir un second, et plus rien n'est accéléré (il paraît que la solution à ce problème consiste à utiliser KMS, mais tout ce que j'ai réussi à en tirer c'est un écran noir) ; quant au pilote Nouveau ((β)), il a l'air tellement peu accéléré que le simple avertissement visuel du terminal (XTerm a une option pour changer brièvement de couleur au lieu de bipper) est atrocement lent.

Finalement, l'accélération 3D marche mieux sur mon téléphone mobile que sur mon ordinateur.

La semaine dernière, un ordinateur hébergé de façon extrêmement officieuse à l'ENS, et qui sert essentiellement à des anciens élèves de garder un contact, a rendu l'âme : c'est essentiellement moi et mon poussinet qui nous sommes collés à la réparation. En fait, c'est juste l'alimentation qui avait grillé, mais on en a profité pour faire une petite mise à jour matérielle de la carte mère et du processeur, histoire de ne plus avoir de problèmes de processeur qui surchauffe. Ceci me donne l'occasion de faire ce que j'aime le plus faire : râler que le monde est mal foutu. En l'occurrence, râler que si la rue Montgallet est un endroit extraordinaire quand on veut acheter les mêmes choses que tout le monde, dès qu'on cherche quelque chose qui n'est pas exactement ce que cherche le gamerz moyen, on l'a dans le c**.

Râlerie numéro 1 : la vitesse à laquelle le matériel disparaît de la vente. Le problème est que nous voulions acheter une carte mère qui utilise des barrettes de DDR2 (le format de mémoire qui n'est pas le plus récent mais le précédent : le plus récent est la DDR3, et ces formats sont incompatibles) : la raison étant que nous avions des barrettes DDR2 avec ECC (c'est-à-dire avec support pour la détection et correction d'erreurs : j'ai été traumatisé par les problèmes de RAM par le passé et je ne veux prendre que de la mémoire ECC — voilà typiquement le genre de choses en lesquelles je diffère du gamerz moyen, qui s'en fout si sa RAM est défectueuse, seul important le fait qu'elle soit rapide), et les barrettes ECC sont difficiles à trouver et chères, donc il était vraiment souhaitable de les réutiliser. D'où la nécessité de trouver une carte mère DDR2 (et gérant l'ECC). J'en avais repérée une sur le site Web de la rue, une Asus M4A78, indiquée comme disponible à environ 60€ dans plusieurs boutiques qui, bien sûr, une fois vérifié sur place, ne l'avaient plus depuis longtemps : c'est le problème avec ce site : il est bien pratique pour trouver les offres récentes, mais ensuite elles ne disparaissent jamais. Or, en fait, trouver la moindre carte mère prenant des barrettes DDR2 s'est avéré vraiment difficile : on a fini par en trouver une, la Gigabyte GA-MA770-UD3, dans le même ordre de prix, mais c'est toujours déplaisant de devoir prendre des décisions sur le coup sans pouvoir les préparer.

Râlerie numéro 2, et la plus importante : je hais, je maudis, je conchie, celui qui a inventé la distinction entre les cartes mères de « serveurs » et les cartes mères pas de « serveurs ».

Ce quelqu'un, donc, a décidé qu'un certain nombre de fonctionnalités des cartes mères n'intéressait pas le grand public (le proverbial gamerz moyen, donc), et que ces fonctionnalités ne seraient disponibles que sur les cartes mères estampillées « serveurs », ou bien de façon complètement aléatoire et parfois non documentée (i.e., difficile ou impossible à vérifier à l'avance), sur les autres. Il s'agit typiquement des fonctionnalités qui peuvent servir à rendre un peu fiable un ordinateur (le gamerz ne veut pas un ordinateur fiable, il veut un ordinateur rapide) : j'ai mentionné le support pour la RAM ECC (sur les cartes mères pour processeurs Intel non-« serveurs », ce support est très très rare ; il est moins rare sur les cartes mères pour processeurs AMD non-« serveurs » car dans ces processeurs le contrôleur mémoire est dans le processeur et a de toute façon le support ECC) ; une autre fonctionnalité qui me concerne est l'existence d'un watchdog matériel, c'est-à-dire un truc capable de redémarrer l'ordinateur automatiquement si on ne lui donne pas signe de vie régulièrement, et donc d'éviter qu'une machine à laquelle il est difficile d'accéder physiquement se retrouve dans un état « planté » (et cette fois-ci, c'est le contraire : le watchdog matériel a l'air d'être souvent présent sur les cartes mères avec chipset Intel, mais rarement sur d'autres). Souvent, aussi, on décide qu'une carte mère pour non-« serveur » n'a pas besoin de deux interfaces Ethernet gigabit. Les cartes mères « serveurs », elles, sont très difficiles à trouver, très chères, et compensent ces quelques fonctionnalités utiles par un manque dans d'autres domaines.

Mise à jour : La situation est encore pire qu'elle l'eut été, parce que d'après Intel (cf. le dernier paragraphe de la page), aucun des processeurs Core i5 ou Core i7 (dont le contrôleur mémoire est maintenant, comme chez AMD, intégré) ne supporte la mémoire ECC. Donc : pour de la RAM ECC, il faut soit chercher chez AMD (et trouver un watchdog sera difficile) soit prendre un processeur estampillé Xeon, i.e., à un prix exorbitant.

Bref, je trouve ça triste que les choix que je dois faire quand j'achète une carte mère ne sont pas liés au prix de celle-ci mais aux combinaisons disponibles. Et aussi, au temps que je suis prêt à consacrer à éplucher les feuilles de spécification qui, bizarrement, ne sont apparemment pas fournies par les fabricants sous un format standardisé et lisible par ordinateur !

Une autre fois je vous parlerai de la merde que sont les cartes graphique et du fait qu'il est absolument impossible, sans acheter la carte et l'essayer, de savoir ce qui va marcher avec un Linux récent et avec des pilotes libres (enfin, malheureusement, la réponse est un peu que rien ne marche).

C'est devenu tellement habituel pour moi de me plaindre que les ordinateurs ne marchent pas que je devrais plutôt signaler les fois où quelque chose a — inexplicablement — marché. Aujourd'hui, il y en a eu deux.

La première, c'est le Wifi. C'est un peu malhonnête de dire que ça a marché pour dire que je n'ai passé que toute la journée à le faire marcher, mais, tout de même, ça a marché, et s'agissant du Wifi c'est quelque chose de vraiment exceptionnel.

Pour être plus précis, la carte Wifi de mon ordinateur (basée sur un chipset Atheros AR2414) est potentiellement gérée par deux pilotes différents sous Linux (deux pilotes dont, évidemment, on comprend mal les rapports de prime abord, surtout que ce sont les mêmes personnes qui s'occupent des deux) : l'un, ancien, compliqué et plus trop maintenu, s'appelle Madwifi (et qui contient un blob binaire, c'est-à-dire qu'on n'a pas le source de la totalité du pilote), et l'autre, censé être plus petit, plus propre et complètement ouvert, basé sur une réécriture à peu près complète des couches Wifi de Linux, s'appelle ath5k. Jusqu'à récemment, j'utilisais Madwifi (le vieux pilote, donc) : pour des raisons mystérieuses et qui le resteront, Madwifi s'est mis a marcher de moins en moins bien au fur et à mesure que le temps passait (de temps en temps, le réseau cessait complètement de répondre), au point que c'en était devenu vraiment insupportable. Donc j'avais bien envie de passer à ath5k (le nouveau pilote). Malheureusement, ma carte Wifi me sert de point d'accès, pas juste de station, et le mode point d'accès (ou maître) est ce que tous les pilotes semblent implémenter en dernier (voire, jamais) : et ath5k n'implémente officiellement pas encore ce mode point d'accès que j'attends avec impatience à chaque nouvelle version du noyau (il sera officiel dans les noyaux 2.6.31, donc dans environ quatre mois). Ou alors, il faut chercher la toute toute dernière version de l'arbre de développement des pilotes Wifi : c'est ce que j'ai fini par faire, pressé par mon poussinet qui voulait pouvoir utiliser un Wifi correct, et donc je me retrouve avec un noyau 2.6.30-rc8~wireless-testing et l'inquiétude qu'il me claque entre les doigts en détruisant mes systèmes de fichiers (et de fait, il me crache des messages d'erreurs très inquiétants du style WARNING: at fs/fs-writeback.c:292 __writeback_single_inode+0x4ab/0x4c0(), que je vais prier pour pouvoir ignorer parce que ça a l'air de vouloir dire que mes fichiers vont exploser dans un temps très bref).

Évidemment, juste comme ça, ça n'a pas marché. Le poussinet arrivait à se connecter au Wifi géré par le nouveau pilote ath5k, mais mon Eee PC, нет, il n'arrivait pas à s'associer. J'ai un autre copain chez qui j'ai le même problème : mon Eee PC n'arrive pas à s'associer au Wifi de sa *box, alors que lui n'a pas de problème et que le même Eee arrive à utiliser plein d'autres réseaux. Ça m'a sérieusement énervé, alors j'ai décidé que je comprendrais ce mystère coûte que coûte : j'ai fait afficher les trames d'association et j'ai essayé de les interpréter même sans connaître les détails des protocoles IEEE 802.11b/g :

00000000  00 00 30 01 00 1b 11 14  d5 0f 00 22 43 00 6c 54  |..0........"C.lT|
00000010  00 1b 11 14 d5 0f 80 1f  11 04 03 00 00 0a 44 61  |..............Da|
00000020  76 69 64 6f 75 6e 65 74  01 08 82 84 8b 96 0c 12  |vidounet........|
00000030  18 24 32 04 30 48 60 6c  dd 07 00 0c 43 06 00 00  |.$2.0H`l....C...|
00000040  00 01 00 00 0f ac 02 01  00 00 0f ac 04 01 00 00  |................|
00000050  0f ac 02 00 00                                    |.....|
00000055

(Oui, Davidounet c'est le SSID de mon Wifi.) Il manque les octets 30 14 (annonçant 0x14=20 octets de RSN IE) immédiatement avant l'octet 0x41 ! L'explication du problème était donc que le Eee envoyait des trames d'association mal formées et que, contrairement à Madwifi et certaines bornes d'accès qui, plus tolérants, devaient se contenter d'ignorer ce qu'ils ne comprennaient pas, le nouveau driver rejetait la trame complètement et il devenait impossible de s'associer.

Le Wifi, c'est quelque chose de vraiment aléatoire, qui fonctionne uniquement quand les mânes de Maxwell sont de bonne humeur : je déteste ce truc, mais il faut admettre que, quand ça marche, c'est bien pratique. En l'occurrence, le driver incriminé sur le Eee PC, un driver écrit par le fabricant (Ralink), était visiblement porté à la va-vite depuis Windows, et il n'est sans doute pas surprenant qu'il fût buggué. J'ai fini par me rendre compte que quelqu'un avait déjà corrigé le problème et j'ai fini par réussir à associer mon Eee PC à mon Wifi qui, depuis, s'obstine à fonctionner correctement.

La deuxième chose qui a marché, c'est un stick récepteur TNT qu'un ami m'a passé. Là, c'est vraiment incompréhensible : ce genre de choses n'aurait pas dû être si simple à utiliser. Il doit y avoir anguille sous roche.

Un an après avoir acheté mon premier Eee PC (un modèle avec 8Go de SSD et 1Go de mémoire qui n'est bizarrement même pas référencé sur la liste censément complète des modèles), j'ai décidé d'acheter un nouveau modèle 901 pour avoir un écran plus grand, un processeur plus puissant et moins gourmand en énergie (c'est un Atom), un disque SSD plus gros, un support Bluetooth et un meilleur chipset Wifi. Comme je l'ai déjà raconté, acheter la machine n'a pas été facile : heureusement, une amie vivant en Angleterre a pu recevoir pour moi le colis de Amazon.co.uk (que je maudis mille fois) et le réexpédier en France — du coup j'aurai payé 380€ plus encore 40€ de frais de port (plus quelques euros pour un adapteur secteur) au lieu des 360€ annoncés ailleurs, mais au moins j'aurai un clavier plus agréable que les horribles AZERTY.

Je suis quand même assez fâché qu'un produit livré avec Linux ait un matériel aussi mal géré par Linux ! Ma première étape a été de recopier sur la nouvelle machine la distribution Linux de l'ancienne (une Ubuntu 8.04 Hardy Heron à laquelle j'avais déjà dû apporter quelques modifications pour que l'ancien Eee PC fonctionne complètement). Résultat : pas de réseau Ethernet, pas de Wifi, un touchpad qui ne marche pas correctement, et je n'ai même pas osé essayer les hotkeys (ni le suspend-to-RAM/disk ou d'autres choses susceptibles de casser). Pour l'Ethernet, c'est apparemment parce que Asus a pris la décision-à-la-con® d'utiliser un chipset Atheros/Attansic sur PCI Express : je me demande bien comment ils ont pu avoir une idée aussi saugrenue que d'utiliser un chipset Ethernet Gigabit sur PCIe pour un truc qui, finalement, ne peut faire que du 100Mbps ; quoi qu'il en soit, la version suivante d'Ubuntu (8.10 Intrepid Ibex) résout le problème, mais upgrader en l'absence de support réseau est pénible et par ailleurs c'est très long sur une machine aussi minimaliste (l'installeur me dit qu'il en a encore pour plus de deux heures…). Pour le Wifi, il paraît que le chipset Ralink sera plutôt un progrès par rapport au Atheros, mais j'attends d'avoir pu le faire fonctionner pour me prononcer.

Mais le touchpad, c'est vraiment la catastrophe. Actuellement il fonctionne, mais c'est pire que s'il ne fonctionnait pas : il n'y a pas moyen de désactiver cette fonctionnalité atroce qui s'appelle le tapping, c'est-à-dire le fait de pouvoir cliquer au touchpad sans utiliser les boutons (juste en tapant brièvement sur le touchpad). Je ne sais pas qui a pu inventer ce truc, mais pour moi c'est une abomination, ça rend le touchpad complètement inutilisable, pire, dangereux parce qu'il clique aléatoirement partout dès qu'on a le malheur de l'effleurer par erreur. L'ancien Eee PC avait aussi cette misfeature, mais on pouvait sans trop de mal la désactiver parce que le touchpad était un Synaptics, bien géré par Linux+X.org depuis longtemps ; sur le 901 ils ont encore pris une décision-à-la-con® en remplaçant le touchpad Synaptics par un Elantech, beaucoup moins commun, et actuellement non supporté par Linux+X.org : la seule solution pour désactiver le tapping (autrement qu'en désactivant complètement le touchpad, ce qui est peut-être le mieux, en fait) est d'utiliser ce patch encore expérimental qui devrait le faire apparaître comme un Synaptics.

Par curiosité, est-ce qu'il existe des ultraportables qui soient vraiment supportés par Linux ? (Quand je dis vraiment, je veux dire jusque dans les moindres détails par les distributions habituelles et sans les configurer bizarrement ni aller chercher des drivers sur des sites tiers ; et que tous les périphériques et toutes les fonctions marchent parfaitement : réseau, wifi, bluetooth, accélération 3D, son, détection du niveau de la batterie, suspend-to-quidlibet, configuration détaillée du touchpad, toutes les touches magiques du clavier, etc.) Car le Eee PC, il faut bien le dire, échoue encore lamentablement à ce test (et le MSI Wind doit être dans le même cas vu qu'il a, par exemple, le même touchpad).

Pour mon propre cadeau de Noël, je me suis acheté un de ces ultraportables Asus (que j'ai mentionnés récemment), un Eee PC. Inutile que je m'appesantisse sur les caractéristiques matérielles, elles sont données partout : le processeur est un Celeron M à 630MHz (en fait, à 900MHz, mais il est par défaut underclocké à 630MHz par le BIOS) ; l'écran est de 800×480 ; il y a des connecteurs USB2 et Ethernet 100Mbps, des enceintes et un micro intégrés ainsi qu'une webcam et un lecteur de cartes SD et bien sûr un composant Wifi ; le disque dur est en fait un solid-state, ce qui a l'avantage d'éviter une partie mobile et d'assurer plus de résistance aux chocs en contrepartie d'une bien plus faible capacité. J'ai pris le modèle avec 8Go de « disque » et 1Go de RAM. Bref, c'est quelque chose d'intermédiaire entre un jouet (ou une calculatrice ?) et un ordinateur. Logiciellement, c'est un Linux basé sur Xandros (lui-même basé sur Debian) et configuré de façon à cacher autant que possible ce fait aux utilisateurs novices (je pense que le slogan easy to learn, easy to work, easy to play n'est pas trop usurpé mais bon, d'un autre côté, je ne suis pas un utilisateur novice). Le tout pèse moins de 1kg (920g précisément, me dit-on — je n'ai pas vérifié) pour des dimensions de 225mm×163mm×36mm, autrement dit c'est vraiment petit (en gros la moitié d'une feuille A4) ; l'autonomie des batteries est quelque part autour de 3h, mais je n'ai pas encore mesuré précisément (et évidemment ça dépend de ce qu'on en fait, par exemple de si le Wifi est activé ou non, de la luminosité de l'écran, de l'utilisation du processeur, etc.).

Si j'ai bien compris, la chose n'est pas encore en vente en France (j'avoue ne pas comprendre pourquoi ce genre de choses ne sortent pas dans le monde entier simultanément : manifestement la mondialisation a encore du chemin à faire !) et le sera d'ici un ou deux mois. Comme je n'avais ni envie d'attendre (l'utilité de la chose pour moi est notamment de me permettre de me connecter au Wifi des bâtiments de l'ENST où ne se situe pas mon bureau, et ça urge un peu) ni envie d'avoir un clavier AZERTY (je déteste ça, même si de toute façon je vais taper à l'aveugle en QWERTY-us), je l'ai commandé depuis Taïwan : il y a des gens qui en vendent sur eBay (i.e., ils les rachètent là-bas et les réexpédient), ça m'a coûté 420€, peut-être un poil plus que le prix auquel ce sera vendu ici (je ne crois pas qu'on sache encore à combien sera le modèle 8Go), mais je ne crois pas avoir fait une mauvaise affaire (mon copain, pendant ce temps, il s'est acheté un VAIO, et ça lui a coûté, hum, plus cher). Par contre, je n'ai pas vraiment de garantie (enfin, il faudrait que je réexpédie à Taïwan, donc bof ; là aussi, je ne comprends pas l'intérêt de ne pas mondialiser ce service).

Parmi les choses qui me plaisent bien, il y a la vitesse de boot (une petite trentaine de secondes), et aussi le silence complet. Il y a certes un ventilateur (c'est la seule partie mobile), mais il se déclenche rarement, et tant qu'il ne tourne pas la machine n'émet aucun bruit, et même s'il se déclenche il est relativement discret (en revanche, il est vrai que c'est un bruit peu agréable, une sorte de crin-crin de moustique, et par ailleurs une fois qu'il démarre il ne s'arrête jamais jusqu'à ce qu'on éteigne ou suspende le PC). Et la petitesse et la légèreté, bien sûr, qui sont la raison première d'acheter une telle machine : c'est quand même génial, d'avoir un « vrai » PC de la taille d'un calepin (oui, je connais les Zaurus et les iPaq, merci).

L'intégration logicielle n'est pas mal faite ; et, une fois n'est pas coutume, on a l'assurance que le matériel sera bien supporté par Linux. Attention cependant : Linux n'est pas synonyme de logiciel libre ; par exemple, le pilote Wifi est un Madwifi, ce qui, déjà, veut dire, blurb binaire opaque dans le noyau, mais en plus, ici, le blurb binaire doit être spécialement adapté pour le chipset présent sur la machine… beurk ! (Bon, la partie binaire du driver Madwifi est en train d'être reverse-engineerée, peut-être qu'on finira par avoir un truc propre, mais pour l'instant ce n'est pas le cas.) Même pour ce qui est des trucs assez triviaux dans la distribution (comme le petit programme qui remplace init), Asus n'a pas montré une très grande volonté à donner des sources. Ils ont quand même consenti à le faire pour les choses pour lesquelles c'était (vraisemblablement) légalement obligatoire en raison des termes de la GPL, notamment pour ce qui est des patchs qu'ils ont apporté dans la gestion de l'ACPI, mais, à ce sujet, we are not impressed : même si Asus a fait le matériel, le BIOS, le patch au noyau et le logiciel qui l'utilise, ils ne sont pas foutus de donner l'usage de la batterie à mieux que 20% près, c'est ridicule ! Et puis c'est basé sur une Xandros, distribution dont on ne peut avoir accès aux packages qu'en payant (et qui se prétend incompatible avec Debian alors même qu'ils sont basés dessus — c'est pathétique — mais bon, en pratique, j'ai essayé, installer des packages de Debian marche sans problème).

Je ne veux pas donner l'impression de trop critiquer : dans l'ensemble c'est plutôt bien installé et configuré, on commence dans un mode facile dont les grosses icônes amicales rassureront les plus réfractaires à l'informatique (et aussi ceux qui ont du mal à viser avec le touchpad microscopique), mais on trouve rapidement comment passer dans un mode plus avancé sous lequel on a un KDE configuré pour le Eee et dont je suis très content. (De façon générale, ce wiki donne plein de trucs utiles aussi bien pour les novices que pour les connaisseurs.) L'outil graphique de configuration des réseaux (probablement une sorte de KNetworkManager, je n'ai pas regardé de trop près, mais il a peut-être été revu et corrigé par Xandros) est bien pratique, même pour quelqu'un, comme moi, normalement habitué à taper moi-même mes sudo ifup ppp1 et autres sudo iwconfig ath0 essid LeReseauDuFutur key s:glups — là il suffit de cliquer partout et ça marche. J'ai juste eu un petit problème avec une mise à jour du système d'input methods qui faisait segfaulter Firefox, mais j'ai vite pu corriger en virant le système SCIM (en revanche, pour quelqu'un qui ne connaît pas du tout, si cette mise à jour casse effectivement Firefox, c'est vrai que c'est problématique — apparemment je ne suis pas le seul à avoir eu ce souci).

Le clavier est peu agréable mais, finalement, eu égard à sa taille, il n'est vraiment pas trop mal : au moins les lettres sont-elles bien placées et d'une taille raisonnable, je ne me plains donc pas trop qu'on leur ait sacrifié la touche control de droite, ou les touches home/end/page-up/page-down (remplacées par des combinaisons avec la touche Fn). Le touchpad, lui, est assez horripilant, mais bon, ça semblait difficile de faire mieux ; Asus le reconnaît implicitement en fournissant avec l'Eee une souris externe. Quant à l'écran, il est forcément très petit, par contre il est bien lumineux et très net. Tout ça donne finalement peu envie de taper des longs textes (par exemple, cette entrée-ci n'a été qu'en toute petite partie tapée sur l'Eee), mais pour regarder un peu le Web, lire son mail ou utiliser la machine comme calculatrice ou que sais-je encore, c'est sans problème.

(Si vous voulez voir largement plus de photos du Eee PC que ce que je mets pour décorer mon article, allez voir ici.)

⁂

Malheureusement, le Wifi, on est encore loin d'en trouver partout. Quand on en trouve, il est soit payant (j'enrage du nombre de réseaux qui vous promettent un truc gratuit ou ouvert dans leur ESSID et qui sont en fait une arnaque) et pas par micropaiements soit soumis à des limitations pénibles. (Un réseau purement et simplement ouvert ça n'existe décidément pas : partout vous aurez du NAT, une redirection de votre première page Web vers des conditions à la con, un filtrage pénible, une limitation en temps ou en débit, que sais-je encore.) Et je m'abstiens de commentaires sur ces pathétiques bouffons qui au nom du grotesque principe de précaution (lequel est maintenant dans la Constitution ! quelle blague) ont fait fermer certains des réseaux Wifi gratuits de la mairie de Paris sous prétexte qu'ils auraient eu des migraines : je m'y connais en hypocondrie alors je leur conseille de consulter un psy ou bien de prendre des cours de physique. Bref, le réseau, on ne l'a pas encore partout. (Ou alors il faut acheter une clé 3G : il paraît que ça marche bien même sous Linux ; mais c'est quand même un poil cher pour un débit pas terrible.)

L'idée que j'ai eue alors, c'est de chercher à me faire un outil de lecture offline de Wikipédia (après tout, si j'avais accès à un seul site, ce serait sans aucun doute celui-là). C'est-à-dire, mettre sur une clé USB ou sur le disque du Eee, la plus grande sélection possible d'articles pour pouvoir les consulter même sans connexion réseau sous la main. Pas une idée spécialement originale, mais aucune des solutions qui existent ne me satisfait : ce projet-là a une interface extrêmement agréable, mais une sélection d'articles beaucoup trop limitée pour être d'un quelconque intérêt (surtout eu égard à la place utilisée) ; la solution de ce Monsieur ne me convient pas, au contraire, parce qu'elle ne permet pas vraiment de sélectionner les articles et qu'elle demande trop de ressources (je ne veux pas mettre un serveur Apache avec PHP sur mon Eee !). Je suis en train de chercher à voir ce que je pourrais faire en mettant des dumps de ce genre sur un filesystem comprimé (peut-être du SquashFS, peut-être un truc spécifique à base de Fuse). Je vous tiens au courant si j'arrive à pondre quelque chose d'intéressant.

J'ai changé la carte mère de mon ordinateur (passant d'une Asus P5WD2 Premium à une P5W64 WS Pro : j'aaaaaime les noms de produits Asus). Je ne gagne pas grand-chose au changement sauf la possibilité de remplacer, plus tard, le processeur par un Core 2 Quad : il semble qu'en ce moment la manie des constructeurs de changer les interfaces processeur et mémoire s'est un peu calmée, donc j'en profite pour faire une mise à jour par petits morceaux (l'avantage de la manip étant de tester chaque composant séparément plutôt que de tout monter en bloc, mais aussi de pouvoir mettre à jour le BIOS[#] de la carte mère avec un processeur supporté d'emblée ; et bien sûr d'étaler un peu les dépenses dans le temps). Une mention spéciale, cependant, pour le chipset audio, qui prétend faire du 192kHz, 24-bits en 7.1 canaux : est-ce qu'il y a vraiment des gens qui s'imaginent avoir les oreilles capables d'entendre avec une telle précision (ou est-ce une carte mère pour chauves-souris ?) ?

En passant : j'ai l'impression que les ordinateurs me tiennent de moins en moins longtemps avant que l'inflation des logiciels les rende inutilisables ; c'est bizarre, parce que la plupart des gens avec qui j'en ai parlé semblent avoir l'impression contraire. (Cette étude montre que le phénomène, sur vingt ans, est bien réel ; mais il faudrait l'étudier avec une échelle plus précise.)

[#] Amusant : avant de flasher le BIOS l'écran de démarrage représentait, je ne sais pourquoi, des traders et des cours d'actions ; après flashage, il est devenu plus sobre et plus joli. Mettre à jour le BIOS est une opération de plus en plus facile (plus besoin de lecteur de disquette, ça marche avec une clé USB maintenant) mais qui me rend toujours nerveux : j'aimerais bien que les constructeurs recommencent à mettre sur les cartes mères un jumper la rendant impossible (comme il y avait autrefois), parce que la possibilité de rendre la machine essentiellement inutilisable avec tant de facilité est dérangeante (limite malfaçon) ! À tel point que mon poussinet et moi pensons nous acheter un gadget pour se mettre à l'abri.

Aucun rapport avec ce qui précède, un peu de Vélib maintenant. Je trouve décidément ce moyen de locomotion pratique, mais il a des inconvénients. D'abord, je me sens un peu nu à côté des voitures, alors j'ai décidé de porter un casque : mais pour ne pas faire les choses à moitié, j'ai carrément pris un casque de moto (de cross, en fait, ça semble plus pratique pour la visière ; et premier prix, quand même, faut pas exagérer non plus). C'est un peu encombrant à transporter (et ça a suscité quelques regards étonnés[#2]) mais finalement c'est assez confortable, et je me sens nettement plus en sécurité (à tel point que je vais plus vite — du coup je me demande si j'y ai gagné quelque chose en vérité). J'ai aussi pris l'habitude de porter un gilet fluo comme beaucoup de gens le font. Enfin, ce n'est pas une question de sécurité, là, mais je trouve que porter des gants aide à ne pas avoir mal à la paume des mains (les poignées antidérapantes du Vélib sont peut-être un peu trop antidérapantes).

Au chapitre des désagréments, j'ai remarqué les suivants :

• La borne qui imprime un ticket d'abonnement courte durée mais celui-ci reste coincé, du coup on se sent con d'être abonné mais sans connaître le numéro (ils pourraient l'afficher à l'écran, quand même !). J'ai fait de l'acrobatie avec mes doigts et réussi à récupérer… une douzaine de tickets qui étaient restés coincés (dont le mien, que j'ai pu identifier entre les autres d'après sa position en dernier + l'heure + le fait que mon code marche).
• Le vélo qui semble être bloqué en 0.0001-ième vitesse (i.e., c'est presque comme si la chaîne avait déraillé, tourner les pédales ne fait quasiment aucun effet, on arrive un tout petit peu à avancer, mais pour dépasser les 5km/h c'est presque impossible). Sans aller jusqu'à ce cas extrême, le niveau des vitesses semble dépendre fortement du vélo (bizarre, les multiplicateurs devraient être constants ‽) : sur certains la troisième vitesse est vraiment insuffisante, sur d'autres elle est acceptable (certes, ce n'est jamais génial, mais ça c'est voulu, le Vélib n'est pas un vélo de course).
• En liaison avec le problème précédent, pas possible de changer un vélo à une borne sans attendre quelques minutes. À ce propos, une chose que je voudrais vraiment c'est la possibilité de signaler un problème à la borne (e.g. : tel vélo a un changement de vitesse mal réglé, tel vélo à déraillé, l'imprimante coince les tickets), peut-être en s'aidant d'une liste prédéfinie. C'est idiot de ne pas mettre les usagers à contribution pour ça (on pourrait, lors de la tentative d'emprunt d'un vélo, avoir un message attention ! un usager précédent a signalé le problème suivant (encore non confirmé) sur ce vélo : pneu dégonflé ; confirmez-vous ce diagnostic ? (oui / non / ne sait pas)). En attendant, la seule possibilité semble être de retourner la selle.

[#2] Mais les chiffres sont formels : le ridicule fait beaucoup moins de morts à Paris que les accidents de la circulation.

And now for something completely different equally geeky: more about ECC RAM.

First, I'm told that what I called memory sticks should properly be referred to as memory modules (memory sticks are, indeed, something rather different). Well screw the Linux source for confusing me: I should have trusted my feelings in this respect. But no matter.

The mystery of my phony ECC errors has been solved and, of course, the answer is ridiculously simple: my BIOS was in a quick boot mode in which it does not initialize RAM at startup, so there was bogus ECC data causing numerous errors as long as the regions in question were not written to. (Part of the mystery remains, however: if these regions of RAM had never been written to, why ever were they being read? They couldn't possibly contain anything useful… I suspect one of two things: either entire pages were being read, because that's simpler, or else a memory bus read operation always addresses a certain quantity (perhaps 128 bytes) which is greater than a write operation, so bogus data was being read at the edge of previously written valid data.)

The silver lining of this is that now I know the ECC reporting mechanism works, and I was able to use this to test a little ECC-checking Perl script I wrote for my chipset under Linux (you can find it here). So if an error is detected or corrected on one of three computers I administer which have ECC RAM, I will get an email telling me about it. I feel my files are much safer now.

Also along the lines of improving computer reliability, I discovered (almost by accident) that the same three computers, as with most recent Intel chipsets, have a hardware watchdog feature—which I activated. This means that if the computer hangs up, the hardware will detect it (once the watchdog is started, it needs to be pinged at regular intervals) and cause a reboot. Hopefully this means I will no longer (or not so often) need to email my mother and ask her to reboot the computer in my room in Orsay.

I just upgraded my home PC's RAM with four (Kingston) 1GB memory sticks (the older sticks will go in another PC). DDR2 ECC RAM isn't easy to come by in the Chinese-owned computer hardware shops (that's Chinese-owned computer-hardware-shops, not Chinese-owned-computer hardware-shops ) of Paris's rue Montgallet, so I bought them online from RAMShopping.fr. Perhaps I didn't really need 4GB (it's strange to think that I now have as much RAM in my PC now as I had hard disk space in '97), but disk cache is always useful—and since the PC in question operates in 64-bit mode there is no reason not to go beyond 3GB.

Of course, there is a rule of the Universe which says that the first time memory sticks are inserted in their socket they will always fail because they weren't pushed hard enough (even if the plastic thingy clicked satisfactorily). I still don't understand why they can't put a minimal amount of very slow fail-safe RAM directly on the motherboard which would enable the BIOS to boot enough to print your system RAM is not responding or something: the first time I tried, the machine beeped forever on boot, and the second time it didn't even do that—I had to unplug every cable on the computer, lay it horizontally, and reinsert the sticks in the socket, before the system finally agreed to boot successfully.

vega david ~ $ sudo lspci -xxx -s 0:0.0
00:00.0 Host bridge: Intel Corporation 955X Express Memory Controller Hub (rev 81)
00: 86 80 74 27 06 00 90 20 81 00 00 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 78 81
30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00
40: 01 90 d1 fe 01 40 d1 fe 05 00 00 f0 01 80 d1 fe
50: 00 00 02 00 03 00 00 00 01 50 fe bf ff 00 00 00
60: 00 30 d1 fe 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 10 11 11 11 11 33 33 00 40 00 4f 00 c0 0a 38 00
a0: 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 03 02 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 20 01 00 00
e0: 09 00 09 21 c9 40 1a 98 0c 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 86 0f 01 00 00 00 00 00

Incidentally, I added a little JavaScript magic to this blog's comment system so that comments' dates are now displayed in the client's timezone (rather than UTC).

<Insérer ici une excuse interchangeable de blogueur pour expliquer pourquoi il n'écrit pas beaucoup ces derniers jours. Du style : je suis crevé, je suis débordé, etc.>

Ça recommence ! regulus.⁂.net (la machine qui sert ce site) a de nouveau des gros soucis de disque dur. Mais cette fois-ci je pense que c'est vraiment sérieux :

hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=22367974, sector=22367928
ide: failed opcode was: unknown
end_request: I/O error, dev hda, sector 22367928
Buffer I/O error on device hda6, logical block 3802096

et

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       40%     18370         4344093

Du coup, je lance immédiatement la procédure sauve-qui-peut :

• J'ai engagé à l'instant un abonnement chez un autre hébergeur, Dédibox (je dis engagé, parce que apparemment ils sont submergés par les demandes, du coup il y a un petit problème d'approvisionnement en ce moment). Même si je suis mécontent qu'ils n'aient pas de proposition à l'achat (je préfère être propriétaire que locataire de mes ordinateurs, même si ça doit me coûter plus cher pour absolument aucun avantage), au moins, chez eux, j'ai l'impression qu'il y a une vague sécurité contre les problèmes matériels — et aussi contre la perte de contrôle de la machine suite à une manipulation malencontreuse.
• Je vais tenter de recopier toutes les données présentes sur le serveur (il n'y a pas grand-chose, seulement 5Go, et tout ce qui est important est bien sûr déjà sauvegardé depuis longtemps) avant que le disque dur meure définitivement.
• S'il claque avant que j'aie un autre serveur opérationnel, je commuterai les DNS sur mon PC chez moi pour garder un site Web vivant. Ce sera d'une lenteur inimaginable (bête connexion ADSL… je n'ai pas encore la fibre optique à domicile), et il manquera des services, mais ça fera l'affaire temporairement.
• Une fois que ce sera fait, je me ferai expédier regulus (l'ordinateur lui-même), je rachèterai un disque, et je trouverai quelque chose à en faire : soit le faire remettre dans une baie si je ne suis pas content de Dédibox, soit autre chose.

Mais même dans le meilleur des cas, tout ceci va me coûter pas mal de temps (or je n'en ai pas du tout en ce moment) et d'argent (je venais à l'instant de renouveler mon hébergement trimestriel pour regulus : déjà, ça fait 100€ de perdus).

I recently bought myself a birthday (or is it an un-birthday?) present, namely a laptop computer. For years I resisted the idea of getting one, arguing that I would rather have a desktop on every possible desk where I might be than one laptop: indeed, I considered (and perhaps still do) laptops to be expensive, easily prone to breaking, and generally troublesome. Still, my boyfriend pointed out to me that the luxury of having an Internet access from one's bed is not to be eschewed. So I was tempted and, when I found out I could have one of these little beasts for just under 600€, I went for it. So here I am, blogging from my bed, and trying to decide what I think of the tiny laptop keyboard and (to my fingers) alien touchpad. I guess I can get used to it.

It's an Acer Aspire 3633WLMi (with an Intel Celeron M 370 processor at 1.5GHz, 15.4″ WXGA screen, 60GB hard drive, 512MB RAM, DVD burner and WiFi: not a very powerful beast, but I still think it was a good bargain). It's called mizar (after a star in the big dipper: ζ Ursæ Majoris), also known as IPv6 2001:7a8:7171:37:216:36ff:fe2e:867f. And, of course, I use it under Linux… which is were I expected a great deal of trouble and got some (but not as much as I thought).

Here's a more detailed report of the extent to which the hardware works under (Debian) GNU/Linux:

• A number of things worked (sometimes unexpectedly) fine out of the box: the graphics hardware (Silicon Integrated Systems [SiS] 661/741/760/761 PCI/AGP VGA Display Adapter, says lspci) and the sound system (Silicon Integrated Systems [SiS] AC'97 Sound Controller (rev a0)) were among the pleasant surprises (the system has no accelerated 3D, but I don't think the hardware has it anyway; however, it does have accelerated 2D and video, which is good). That the Ethernet controller, USB ports, hard drives and other very common hardware works is of course less of a surprise, but still nice; I didn't try burning DVD's, but I expect no difficulty there, and reading them certainly works. The touchpad has this really cool driver which is configurable in unbelievably many ways.
• I did have a little more trouble with the battery status indicator. This is probably because the BIOS ships with broken ACPI tables or code. However, using a sufficiently recent Linux kernel version (2.6.17.7) solves the problem, so I didn't look into it.
• WiFi probably does not work. The hardware appears to be an Atheros Communications, Inc. AR5005G 802.11abg NIC (rev 01), and it's about the only chipset that the MadWifi driver does not support, so no luck there (and the error message is annoyingly cryptic: unable to attach hardware: 'Hardware revision not supported' (HAL status 13)). Then I tried this cruft which is intended to make it possible to use Windows drivers on Linux: I had some trouble locating the appropriate driver in the first place, and now I think it still doesn't work, but it's not entirely clear. The driver seems to detect the hardware (it succeeds in reading the hardware address) and creates the network device, but then it fails while scanning access points: now it could be simply because there is no access point to be found (indeed, unless one of my neighbors has WiFi at home, there should be none), but the obscure error message (ndiswrapper (set_scan:1167): scanning failed (C0010011)) probably indicates a more serious problem… I don't know for sure, though. If necessary, I can buy some external PCMCIA WiFi card which would is known to be supported.
• Update (2006-08-01T22:00+02:00): Actually, MadWifi works better than described above. The problem was that the laptop has a radio kill switch in front which needs to be pressed to activate the receiver. Now I can at least detect access points around me. However, I still didn't manage to actually get any packet throught (but it may be due to the peculiar nature of the network I'm trying this on).
• Update (2006-08-02): OK, finally it works. I had to play with iwpriv ath0 authmode 2 and similar arcane commands. Urgh…
• Suspend to disk seems to works. This is unexpected: I thought doing a suspend to disk under any kind of Unix was inherently impossible and the best they could achieve would be some horrible and unworkable hack — well, it is a hack, but it seems to work pretty well at least under certain circumstances. (In fact, as is often the case, there are confusingly many different ways to suspend, and I only tried uswsusp a bit.) I was logged in graphically and had various programs open when I tried suspending to disk, and all was restored correctly. (Well, in truth, the Network Time Protocol daemon was confused: but that daemon certainly does not expect to run on a laptop!) I didn't try suspending to RAM, yet.
• Update (2006-08-01T22:00+02:00): Suspend to RAM also works, but causes a few difficulties with the graphics state.

Incidentally, I'm starting to find that Firefox isn't all that crappy (I've found ways to make it suit my needs — more or less). So I'm giving it a try on my laptop.

Le danger avec les ordinateurs, c'est que dès qu'on commence à y toucher, ils vous prennent non seulement tout votre argent mais aussi tout votre temps et toute votre énergie. Bon, il y a quand même des choses qui marchent : ma nouvelle RAM ECC (celle qui a été si difficile a trouver) semble fonctionner correctement (même si j'ai eu une petite frayeur au début en lisant une erreur multiple, mais j'ai compris que c'était en fait un phénomène normal). Ma connexion ADSL a été améliorée (je suis à 6Mbps maintenant) — et évidemment, quelques heures[#] après ma souscription à l'offre en question, mon fournisseur d'accès créait une nouvelle offre, exactement la même mais en dégroupé, pour deux fois moins cher, grrr… Bon, au moins, ça va (douze fois) plus vite, c'est déjà ça. Je me suis aussi acheté une petite Webcam (une Labtec Pro, parce que c'est ce qui, m'a-t-on dit, marche le mieux sous Linux), et elle marche bien. (Non, vous n'aurez pas d'images. Pas pour l'instant en tout cas, je vais éteindre mon ordinateur pour la nuit.) Ah, et puis un disque IEEE 1394 externe, aussi.

Mais le truc qui ne va vraiment pas, c'est que j'ai voulu régler mon problème de surchauffe du processeur. Catastrophe. J'ai acheté une super pâte thermique (la Arctic Silver 5), j'ai acheté un nouveau ventilateur pour mettre au fond de mon boîtier, j'ai réduit la fréquence horloge (il est maintenant à 2.9GHz alors que sa fréquence nominale est 3.4GHz) et le Vcore (de 1.4V à 1.2975V — la plus basse valeur permise par la carte mère) de mon processeur… rien n'y a fait, ce foutu machin continue à surchauffer ! À ce stade-là, c'est de l'obstination. Bon, le fait qu'il fasse 27°C dans mon appartement (ça aussi, c'est un mystère : je ne comprends pas pourquoi il est aussi chaud) ne doit pas aider, mais quand même. Demain j'achète un nouvel ensemble radiateur+ventilateur et je vois ce que ça donne. Enfin, c'est vraiment pénible, quoi. Ah, et puis j'ai un disque dur (le vieux, heureusement ! pas le nouveau) qui semble en train de rendre l'âme. Pfiou…

Mais je ne suis pas le seul à avoir des ennuis : pour ceux qui seraient tentés de me conseiller les Mac, ma mère vient d'amener le sien chez un réparateur, et on lui a dit que la carte mère était à changer (je n'ai pas les détails) — et on lui en demande près de 400€ (main d'œuvre comprise) ! alors que c'est un vieux truc (un G4 en tout cas).

[#] Ce n'est pas une exagération : j'ai posté ma demande de migration le dimanche 7 au soir, et le lundi 8 après-midi, le formulaire que je venais de renvoyer avait une case en plus !

Voilà : je ne sais pas si je dois parler d'un nouvel ordinateur d'une sérieuse mise à jour de l'ancien, mais on va dire que vega (c'est son petit nom) a été réincarné(e?). Les seules choses qui restent sont le boîtier, la carte son (j'aurais pu m'en passer vu que ma nouvelle carte mère a un chipset sonore intégré), un disque dur de 160Go (auparavant monté en rack, j'ai décidé de le « fixer »), et le lecteur et le graveur de DVD. Plus les périphériques externes (écran, clavier, souris, trackball, enceintes, micro, casque, modem ADSL). Mais peut-être que ce qui fait vraiment l'identité de la machine c'est le contenu des disques, et là j'ai presque exactement la même chose qu'avant (modulo des déplacements variés). Ce qui a changé, c'est la carte mère (une Asus P5WD2 Premium), le processeur (Pentium IV 550 à 3.40GHz), la mémoire (temporairement 512Mo de DDR2 mais dès demain je devrais passer à 1Go de DDR2-ECC) et un disque dur SATA (Deskstar T7K250 de 250Go). Et, malheureusement, une carte graphique nVidia GeForce 6200. J'en ai eu pour moins de 1000€, ce qui n'est pas mal quand je pense que le vieux vega m'avait coûté le triple il y a cinq-six ans (faut dire qu'à l'époque un bi Pentium II c'était une machine absolument bestiale, je suppose que je suis devenu plus raisonnable avec le temps).

Pour ce qui est de la carte mère, j'en suis très content. Le seul reproche que j'aurais à faire, c'est qu'il y a peu de connecteurs d'extension PCI (seulement deux — plus un troisième rendu inutilisable par sa proximité avec la carte graphique) ; ils fournissent bien deux connecteurs PCI Express (en plus de celui qui sert à la carte graphique), un universel et un ×1 (un truc absolument minuscule, je n'ai jamais vu de carte de ce format), mais je ne crois pas qu'on puisse brancher quoi que ce soit d'utile dessus. Mais ce n'est pas si grave, parce que la carte mère a presque tout intégré : deux contrôleurs Ethernet gigabit, je ne sais pas combien de ports IDE/ATA/SATA (disons qu'il y a deux, peut-être même trois, chipsets différents — un Intel ICH7 et un ITE IT8211, et de quoi brancher trois nappes et quatre ou cinq câbles SATA), un contrôleur IEEE 1394 (FireWire) et un chipset sonore. De tout ça, les contrôleurs Ethernet sont reconnus par Linux sans problème, ainsi que le contrôleur IEEE 1394 (pour l'instant je n'ai pas essayé d'y brancher des choses, mais je pense que je vais investir de ce côté-là aussi), l'USB et le chipset sonore (dans la toute dernière version du noyau). Pour les contrôleurs IDE/ATA/SATA, j'ai produit ce patch noyau grâce auquel au moins les deux que j'utilise marchent pile-poil (actuellement j'ai le lecteur et le graveur de DVD sur une nappe IDE, un disque dur sur une nappe IDE/ATA133, et un disque dur SATA). Le BIOS, comme toujours avec Asus, est très satisfaisant. Ah, et puis : je ne sais pas si c'est un hasard heureux (il y a toujours une grande variabilité dans ce domaine) ou si ce modèle de cartes utilise des quartz de vraiment de bonne qualité, mais la mesure de dérive de l'oscillateur (l'horloge système, quoi) par rapport à NTP est excellente : le démon ntpd m'informe qu'il corrige une dérive de moins de 1.3 parties par million, soit à peine 0.1 seconde par jour ; par comparaison, mon serveur hébergé a un drift de plus de 320 parties par million.

Pour le processeur, c'est un achat résultant d'un compromis. Peut-être que dans six mois ou un an j'achèterai un dual core 64-bits : là j'étais assez partagé entre le souhait d'en finir avec cette connerie de 32-bits et la crainte d'avoir plein de problèmes en mode 64-bits. Donc j'ai pris un moyen-bas de gamme, qui n'est quand même pas mal. Si je décide de changer, j'ai un ordinateur à Orsay qui pourra bénéficier du processeur que j'ai actuellement (quitte à racheter une carte mère). Ce qui m'ennuie plus, c'est que j'ai des problèmes de surchauffe dès que je l'utilise à plein régime (ce n'est pas souvent, certes, mais dès que je démarre une compilation ou quelque chose comme ça) : bon, comme c'est un processeur malin, quand il surchauffe, plutôt que de s'éteindre bêtement, il ralentit sa fréquence horloge jusqu'à ne plus surchauffer (ça doit durer quelques secondes, le temps de refroidir, puis il repart en surchauffe, et ça oscille comme ça) ; ce n'est pas catastrophique (l'effet principal, c'est que ça remplit mes fichiers de logs de message de panique du noyau), en gros il va 15% plus lentement en vitesse de croisière qu'en vitesse initiale (avant que les problèmes de surchauffe commencent), mais c'est tout de même irritant. Manifestement je n'ai pas une bonne circulation d'air dans mon unité centrale (il y a peut-être aussi que mon appartement est trop chaud, déjà), mais je vois mal comment je peux y remédier : c'est bien de me dire que le passage de l'air ne doit pas être gêné par des fils, mais il y a tellement de choses à brancher dans une unité centrale, je ne vois pas comment je suis censé faire disparaître les deux nappes plus un cordon SATA plus trois ou quatre quadruplets de fils d'alimentation plus encore quelques fils en tout genre qui passent par là. Et je ne parle pas de mon chipset graphique qui chauffe à 70°C minimum (certainement ça n'aide pas le CPU qui n'est pas loin), il paraît que c'est « normal » (???) ; je vais peut-être essayer de l'underclocker, lui, vu qu'il est complètement sous-utilisé.

Pour la RAM, mon revendeur (il s'agit de LCDI) me dit qu'il a fini par me trouver de la DDR2 ECC Unbuffered comme il fallait, et je vais la chercher demain (deux barrettes de 512Mo). En attendant j'ai pris une petite barrette de 512Mo dont j'avoue qu'elle me semble bonne (j'ai fait quelques tests, pas horriblement poussés, mais je n'ai pas trouvé de problème) ; mais je me sentirai quand même plus en sécurité avec de la ECC.

Pour ce qui est du disque dur, pas grand-chose à en dire : c'est la première fois que j'expérimente un SATA, les performances sont bonnes, mais je suis déçu qu'il ne sache pas (ou bien c'est le driver Linux qui ne sait pas — de fait, on me souffle que c'est la faute de la libata et qu'il y a un patch qui corrige ça) faire du SMART — moi j'aimais bien interroger mes disques durs pour leur demander s'ils allaient bien et s'ils étaient heureux dans la vie.

Reste enfin la carte graphique : hélas, faute d'existence de la moindre carte graphique au format PCI Express qui soit gérée par des pilotes libres j'ai dû me résoudre à prendre une nVidia. Non seulement c'est de la merde logiciellement (le module noyau bouffe quatre mégas de mémoire non swappable, c'est d'un grotesque achevé, en plus la version qui en est packagée par Debian est très vieille, et puis ça m'oblige à recompiler la colle autour de ce foutu module dès que je veux changer de version du noyau ! bref, une mine à emmerdes), mais en plus elle n'est même pas très bonne (par exemple, ma bonne vieille Radeon 7500 était capable de régler la luminosité et le contraste sur les overlays XVideo, celle-ci ne peut que faire un réglage global de luminosité et contraste). Et, comme je l'ai mentionné, ce truc chauffe comme pas possible. Que des ennuis, donc.

Mais bon, globalement, je ne suis pas du tout mécontent de cet achat. Il faut dire que le vieux cœur de vega commençait à être un peu dépassé par les événements, même s'il ne m'a jamais donné le moindre problème. Remarquez sur la photo à gauche les deux processeurs (les deux trucs noirs qui dépassent) sur la carte mère Asus P2B-D et, tout à gauche, quelque chose de maintenant totalement parti aux oubliettes, des connecteurs d'extension ISA (j'utilise pourtant encore aujourd'hui, sur mon PC à Orsay, une carte son ISA qui date de 1994, une SoundBlaster AWE32, et elle me donne complète satisfaction).

Parlant de carte son, maintenant que j'en ai deux (ma Sound Blaster Live! d'extension et le chipset sur ma carte mère) je vais pouvoir m'amuser à les relier l'une à l'autre pour comparer leur précision, mesurer la dégradation du signal et ce genre de choses. Ça devrait être intéressant.

La RAM des ordinateurs, c'est absolument invraisemblable. Je ne sais pas si quelqu'un a déjà compté le nombre de types mutuellement incompatibles qu'il en existe, mais il doit être furieusement élevé. Alors voilà : je suis allé ce matin acheter une carte mère Asus P5WD2, parce que c'est à peu près le seul modèle pour Pentium IV qui supporte la RAM ECC, et le processeur qui va avec. Et, bien entendu, les barrettes de mémoire. (Je ne dirai pas où, parce que je leur laisse une chance de réparer le bordel que je vais maintenant décrire avant de chercher à détruire leur réputation.)

Le vendeur m'affirme qu'il a de la RAM ECC adaptée, et m'en fournit deux barrettes (de 512Mo chacune). Je paie et je rentre chez moi. Mais quand il faut monter la machine, catastrophe : les barrettes ne s'insèrent pas dans la carte mère. Pourquoi ? Parce que c'est de la DDR alors que la carte mère n'accepte que la DDR2 (manifestement, la compatibilité ascendante, cette bande de fils de putes qui conçoivent les normes sur les barrettes de RAM n'en a jamais entendu parler). La DDR2 est autant incompatible avec la DDR que tous les autres standards antérieurs, donc (malgré le nom délibérément trompeur et l'apparence quasiment identique). Bref, je retourne au magasin me plaindre, le type s'excuse (il a confondu avec une autre carte mère), il passe un bon moment au téléphone, et me dit finalement qu'il peut me commander de la DDR2 ECC, qu'il me fera au même prix.

Sauvé ? Non ! Ces raclures de chiottes qui conçoivent les normes sur les barrettes de RAM n'ont pas inventé seulement l'incompatibilité DDR2/DDR comme connerie : ils ont aussi imaginé la RAM Registered, qui est incompatible avec la RAM normale, dite Unbuffered (la raison de cette distinction est tout à fait obscure : on me dit que la RAM Registered a un petit registre ou buffer en plus de la Unbuffered, mais son utilité exacte n'est décrite nulle part, on précise juste qu'elle met un cycle horloge de plus à répondre, et pourtant, curieusement, il ne suffit pas au BIOS de régler les timings pour compenser pour ce cycle et rendre la barrette compatible avec les autres ! il faut vraiment une certaine perversité pour rendre les choses aussi stupidement incompatibles) ; bizarrement, la RAM ECC existe presque exclusivement en Registered (et réciproquement la Registered est toujours ECC), mais justement la carte mère que j'ai acheté accepte de la ECC mais exige qu'elle soit Unbuffered. Autrement dit : elle accepte la ECC mais seulement dans une combinaison qui est à peu près introuvable (de la DDR2 ECC Unbuffered, vous suivez ?). Le vendeur me présente de nouvelles excuses (il allait me commander de la Registered, ayant oublié cette bizarrerie de cette carte mère) : il me promet qu'il va essayer de me trouver le monstre qu'il me faut et me tenir au courant, mais j'ai une certaine inquiétude quant à ses chances de succès.

En attendant j'ai acheté une barrette de 512Mo de mémoire non-ECC (en suppliant mon karma de faire que le miracle se produise qu'il n'ait pas de bit défectueux, au moins pour le temps qu'il me faudra faire avec), mais je n'ai pas encore eu le courage de faire le montage et d'affronter tous les ennuis qui vont inévitablement se présenter.

Mon petit frère est allé s'acheter un ordinateur rue Montgallet, aujourd'hui, en l'occurrence chez Galaxy Computer (qui, nonobstant la critique plutôt négative sur ce site, m'a fait très bonne impression[#], mais je suis peut-être biaisé par le fait que le vendeur à qui nous avons eu affaire, était non seulement sympa mais en plus très mignon). Cette rue est quelque chose de vraiment extraordinaire, il ne doit pas exister beaucoup d'endroits de ce genre dans le monde (déjà, il n'y a pas des masses de rues qui ont un site Web !). Et je suis aussi toujours épaté par la puissance de ce qu'on arrive à acheter comme ordinateur pour moins de 800€ (il est vrai qu'en l'occurrence c'était sans écran).

Cela fait déjà un moment que je songe à me racheter un nouvel ordinateur (l'actuel bi-PII450 que j'ai dans mon appartement date de 1999, je crois). J'étais parti sur l'idée de prendre un bi-Optéron, mais ça a l'air difficile à trouver et source d'ennuis (notamment, la seule carte mère facilement trouvable pour deux processeurs Optéron est la MSI K8D Master-F, qui ne fait même pas de SATA) ; depuis qu'Intel s'est rallié à la norme 64 bits créée par AMD, il semble évident que c'est ce qui va s'imposer, mais la distribution Linux que je compte utiliser (Debian), est encore à la traîne dans ce domaine (d'après ceux qui ont essayé, la transparence de l'utilisation des binaires 32 bits sur un système 64 bits laisse à désirer). Du coup, je vais peut-être m'abstenir de mettre quelques milliers d'euros dans un truc qui ne servira qu'à alimenter mes maux de tête. À part ça, l'extrême difficulté de trouver de la mémoire ECC (sans laquelle tout ordinateur moderne est soumis à des plantages aléatoires et intraçables), et une carte mère qui la supporte, freine toutes mes envies d'achat (c'est bien pour le portefeuille, certes, mais ça commence à faire long).

Autre chose : la dernière carte graphique raisonnablement moderne (accélération 2D, vidéo et 3D) qui était entièrement gérée (c'est-à-dire y compris la 3D) par des pilotes libres (par opposition aux catastrophiques pilotes propriétaires fournis par ATI ou nVidia), la Radeon 9200, ne se vend plus. Je trouve que c'est vraiment une catastrophe. Heureusement, j'ai une Radeon quelque chose (7500 ou 8500, je ne sais plus bien), chez moi, à laquelle je tiens comme la prunelle de mes yeux pour cette raison. Curieusement, ça n'a pas l'air d'émouvoir grand-monde à part moi qu'on ne puisse plus faire de la 3D sous Linux. Passons.

Pour finir, il semblerait que le FireWire (enfin, IEEE 1394) soit intéressant. Actuellement, pour mes transferts de données en masse, j'utilise un disque IDE (d'une centaine de gigas) en rack, ce qui est assez satisfaisant sauf que ce n'est pas hotplugable. Ayant regardé le prix des contrôleurs (vraiment pas cher) et des disques (raisonnable), je me dis que c'est peut-être un investissement intéressant.

[#] En vérité, je pense que toutes ces boutiques doivent se valoir d'assez près. Parfois on a une expérience négative ou positive de l'une d'elle, alors on conclut qu'elle ne vaut rien ou qu'elle est excellente, mais en vérité c'est juste le hasard d'une fois.

Après le serveur hébergé (toujours pas de nouvelles de ce côté-là, d'ailleurs), c'est au tour de mon PC de me donner des soucis : manifestement il y a une composante mécanique, peut-être un disque mais plus probablement un ventilateur, qui est en train de rendre l'âme : il émet à intervalles à peu près réguliers des sons qui ressemblent à des longs mugissements d'une bête qu'on égorgerait. Bon, comme cette machine a autour de cinq ans d'âge, ça ne m'étonne pas énormément qu'elle présente des signes de faiblesse. L'ennui, c'est qu'elle a trois disques durs et quatre ventilateurs (un sur l'alim, un à l'avant du boîtier, et un sur chaque processeur), et je ne sais absolument pas d'où vient le bruit, je n'arrive pas à en localiser la source même quand le boîtier est ouvert c'est trop confus. Il n'est pas acquis, non plus, que je puisse racheter des ventilateurs pour Pentium II, d'ailleurs, si c'est l'un d'eux qui se meurt (et il n'est pas non plus acquis que je me souvienne comment on monte et démonte ces satanés trucs).

Il serait temps que je mette un peu à jour mon environnement informatique, parce que ça commence à faire un peu vieillot. Je pense principalement à deux choses.

D'abord, ma connexion Internet. Mon fournisseur d'accès ADSL est Nerim (sous prétexte qu'ils sont les plus compétents techniquement : de fait, ce sont par exemple les seuls à offrir explicitement une plage IPv6 — je ne comprends pas pourquoi les autres ne le font pas, d'ailleurs, alors que, si ça n'intéresse personne, ça ne coûte vraiment rien non plus, tous les routeurs modernes gérant l'IPv6). Mais ma formule chez eux (Nerim Base à 512kbps) est tellement vieille qu'elle n'est même plus listée nulle part sur leur site (ah, oui, c'est compliqué : il y a une différence entre le Pack Nerim Base, que je n'ai pas, et la Formule Nerim Base, que j'ai, et qui n'est plus proposée).

Y rester est d'autant plus absurde que je peux avoir un débit supérieur pour un prix inférieur. L'ennui, c'est surtout que j'ai peur que changer de quelque façon que ce soit m'impose une interruption de service de plus que quelques heures (soit parce que je devrais rendre le modem que je loue actuellement à France Telecom dans le cadre de Netissimo 1, soit parce que la ligne serait effectivement coupée pendant un certain temps. Et il me serait beaucoup plus gênant de faire sans ADSL pendant un jour (surtout que je n'ai plus de modem RTC qui fonctionne) que de payer plus pour un débit moindre pendant un temps assez important — mais, à la longue, ça finit par ne plus être vrai. Enfin bon. Aussi, je suis perplexe de voir que sur les offres Nerim leur offre à 8Mbps n'est pas encore disponible en version dégroupée, et en version non-dégroupée c'est quand même un peu cher (et surtout, ça voudra dire une nouvelle interruption pour passer en dégroupé). C'est quand même pénible, tout ça. Il va falloir appeler le service clients, s'expliquer avec (et espérer qu'ils se souviennent encore de l'existence de ma formule préhistorique) : que de tracas !

Deuxième chose, mon ordinateur lui-même : c'est pour l'instant un bi-processeur Pentium II à (deux fois, donc) 450MHz (enfin, ça c'est ce que j'ai à Paris chez moi ; chez mes parents à Orsay j'ai un Pentium III à 600MHz, il serait aussi peut-être temps de penser à le changer). Je me dis qu'il serait temps d'avoir un truc un peu plus rapide. Mais il y a quelques contraintes. D'abord, j'ai pris goût au bi-processeur (c'est quand même sacrément mieux pour tout ce qui est vaguement temps-réel : Linux était assez mauvais pour la latence à la commutation des tâches, on sent la différence quand on écoute de la musique en même temps qu'on fait autre chose ; et puis, pour envoyer des bug-reports à des gens comme quoi leur makefile ne marche pas avec -j2, c'est excellent). Ensuite, de nos jours, il faut de la RAM ECC parce que j'ai la faiblesse de ne pas vouloir que des corruptions aléatoires apparaissent dans mes fichiers (et j'ai assez donné dans les tests mémoires et les demandes à Linux de démapper des pages parce qu'elles ont un bit buggué). Ça complique un peu la mise à jour, tout ça : le PC moyen qu'on trouve chez Carrefour, ce n'est pas un bi-processeur avec de la RAM ECC, non, vraiment (et c'est bien dommage, d'ailleurs), et même chez le Taïwanais du 12^e ce n'est pas complètement évident à trouver. Bon, et puis, par ailleurs, j'aimerais bien un 64-bits (jeu d'opcodes AMD64 / Intel ia32e, je veux dire : le Intel ia64 ça a vraiment l'air d'être n'importe quoi), parce que les limitations débiles à 4Go (qui débutent dès qu'on veut mettre plus de 1Go de mémoire, sous Linux, en fait, à moins de patchs ad hoc) elles commencent à bien faire. Ça ce n'est pas si dur à trouver (un tantinet cher, c'est tout), c'est juste que ma distribution Linux supporte mal la chose et j'ai médiocrement envie d'en changer (encore !).

Je crois en fait que la grande difficulté est plutôt de trouver la carte mère idéale, qui supporte, disons, un bi-optéron et autour de 2Go de RAM en gérant le ECC et si possible qui donne le tout pour significativement moins de 3000€ (y'a des limites au gaspillage, aussi). Le reste de la machine, je le garde, notamment le ¼To de disques durs, sauf peut-être pour un petit disque système que je rachèterai si je prends un ensemble sans SCSI (je ne me ferai pas arnaquer une nouvelle fois par le SCSI), ou encore la carte graphique Radeon 7500, qui a l'intérêt d'être à peu près la seule carte graphique existante qui soit complètement gérée (accélérations 3D et vidéo comprises) sous X11 par des pilotes libres (enfin, le fait qu'ils soient libres m'importe assez peu, en fait, c'est juste que les pilotes propriétaires fournis par les constructeurs pour d'autres cartes graphiques (1) sont buggués et ont tendance à faire planter Linux et (2) teintent le noyau).

Bon, j'ai un copain qui me dit que je cherche vraiment les ennuis (notamment à cause du 64-bits : c'est vrai que c'est un peu pénible que ça soit toujours vaguement expérimental sous Linux). Il n'a pas forcément tort, je suppose.

Acting upon a sudden uncontrolled impulse, because I had some time and some money to waste this afternoon and since I was walking through the 12th arrondissement of Paris (where all the Chinese computer hardware retailers are located), I bought myself a DVD±R[W] drive (burner, I mean). A Plextor PX-708A, to be precise (whose maximal burning speeds are: 8× for DVD+R, 4× for DVD+RW, 4× for DVD−R, 2× for DVD−RW, 40× for CD-R and 12× for CD-RW; reading speeds are 12× for DVD-ROM and 40× for CD-ROM); I've always bought Plextor burners previously and I've been quite satisfied, so I think I can recommend them.

The difference between ‘+’ and ‘−’ was completely unintelligible to me, and still isn't perfectly clear, but here is a (partial) explanation. (Unfortunately, Google isn't of much help here, since it doesn't distinguish "dvd+r" from "dvd-r", say.) Basically, ‘+’ is less compatible with existing DVD-ROM drives, but in counterpart can be written incrementally and without risk of buffer underrun or such annoyances, whereas ‘−’ is much closer to CD-R[W]. Incidentally, ‘−’ is supported by the people who came up with the DVD (same DVD logo), whereas ‘+’ is sponsored by a different group (and the logo on disks is different). Apart from that, the disks have the same size and—except for an explicit marking—are not recognizable (both have the same purplish hue, for example, for Verbatim disks with AZO-based dyes; strangely enough, their DVD−R are made in Taiwan whereas their DVD+R are made in India). Their capacity is the same (around 4.4 gigabytes—meaning around 4.7 billion bytes—for single-sided single-layer disks) and the price also seems to be precisely the same.

To burn DVDs under Linux, I've tried DVD+RW-tools, and they seem to work (although I've had some strange symptoms here or there); despite the name, they will also work with DVD−R[W], not just ‘+’. And the name (growisofs) is also ridiculously unintuitive, but the program in question is also able to, say, record a cramfs image on the medium, not just grow an ISO9660 filesystem. Plain old cdrecord won't work; and although there is a special different version (cdrecord-prodvd) which will, I don't recommend using it, were it only for the fact that it has a highly obnoxious (and non-free) license—you need a “key” of some sort to do the writing, and you don't get access to the source code, and you might not even be able to use it commercially. There is also a free fork of cdrtools (the kit which includes cdrecord) called dvdrtools which might be useful, but I haven't tried it yet.

Anyhow, it seems to work. Well, the DVDs I've recorded (whether ‘+’ or ‘−’) weren't readable by my DVD-ROM drive, but it's very old and mostly broken anyway, so I'm not really surprised. The burner itself is able to read the disks it wrote (I checked them thoroughly), which is what I mostly care about because I intend to use DVDs for backups.

[Traduction française ci-dessous.]

Obviously my monitor will cease to function shortly. Presently it is losing sync every now and then, so the image distorts for a second, then a click is heard as sync is brought back and the image returns to normal. And it's happening more and more often, so I don't think I have much time left. I must buy a new one tomorrow. Probably another 17″ CRT like I have, because I can't really afford more than that (certainly LCD is out of question, and 19″ CRT I could afford to buy but it's a bit too bulky for my comfort). I use a V-Refresh rate of 85Hz, because I can't stand those flickering things, and since I work in 1024×768 resolution (I've never had use for more), I need something like 70kHz of H-Sync rate (and 95MHz dot clock) to go with. Would someone care to suggest a monitor that will do that and doesn't cost more than €200 or so? A priori, I would look for a Philips, but I don't really have any knowledge there.

Is it just my impression or do monitors have a really short lifespan? That, and power control blocks: something seems to break every six months. Back in my days, things were made to last! But then it's true that I leave my computers running 24 hours (with screen power management, but still).