David Madore's WebLog: 2012-03

Conversation entre Ruxor et le poussinet :

— Dis, tu ne sais pas où est passé le catalogue des 3 Suisses printemps-été 2010 ?

— Je crois que je l'ai jeté à la poubelle en faisant du rangement.

— Argh ! Il ne fallait pas.

— Pourquoi diable voudrais-tu garder un catalogue de vente par correspondance périmé depuis deux ans ?

— Oh, rien, aucune raison…

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.

Je suis finalement allé voir un dermatologue pour la petite lésion à ma paupière (en médecine de ville parce qu'obtenir un rendez-vous au service de dermatologie « pavillon Tarnier » de Cochin prend trois mois, et il faut une première consultation avant toute intervention ; je me suis adressé au même spécialiste qui m'avait traité un grain de beauté en 2003, et qui m'avait fait une bonne impression[#], d'ailleurs confirmée cette fois-ci). Apparemment, donc, c'était une verrue que j'avais, et il l'a traitée sans difficulté, et sans bistouri, en la brûlant à l'azote liquide (il m'a prévenu que pendant dix-quinze jours ma paupière aurait un aspect un peu effrayant) ; et les autres petites lésions que j'ai au visage sont sans rapport, ce sont des adénomes sébacés, disgracieux mais d'aucune importance médicale (il m'a traité deux ou trois des plus gros).

Ce qui m'impressionne avec la dermatologie, c'est qu'il y a un zillion de trucs différents possibles, chacun pouvant prendre un zillion d'aspects, mais, en fait, avec énormément de ressemblance entre certains aspects de X et certains aspects de Y pour à peu près n'importe quelle paire (X,Y), et malgré ça les spécialistes arrivent généralement à faire un diagnostic en un coup d'œil. (Mais pas tous les médecins, apparemment, puisque mon généraliste ne savait visiblement pas quoi dire, là.)

[#] Puisque je le recommande autant donner son nom : il s'agit du Docteur Raoul Triller, 36 ave. Hoche (Paris 8^e).

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.

…pourpre, rutilant, cramoisi, grenat, carmin, incarnat, vermillon, rubis, cinabre, amarante, garance, coquelicot, ponceau, nacarat, andrinople, zinzolin (ce n'est pas exactement un rouge, mais j'adooore le mot zinzolin).

Je suis sûr que j'en oublie, mais voilà, grâce à ça, les autorités pourront élever encore au moins seize fois le niveau d'alerte Vigipirate. Avec d'autres métonymies (fraise, tomate, cardinal, cruor…), on peut jouer très longtemps à ce petit jeu. M'enfin, si vous vouliez une nomenclature où il est toujours possible de trouver un niveau incroyablement plus élevé que tous les niveaux précédents, il fallait plutôt utiliser vous-savez-quoi (ou, si ou veut donner l'impression que le pas franchi est qualitativement différent que tous les pas précédents, même s'ils avaient été infiniment nombreux, vous-savez-quoi). J'avoue que je ne sais pas ce qui serait le plus amusant, entre le président de la République qui annonce qu'on passe à Vigipirate niveau fuchsia ou bien niveau ε_ω.

(Je suis sûr que je radote, moi, d'ailleurs… ah ben oui, gagné.)

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.

J'ai publié la version 0.0.4[#] de ma petite table Unicode pour Android (qui a maintenant sa propre page Web mais ça ne dit rien d'intéressant). Les changements sont assez mineurs : le plus important est que j'ai mis à jour les données pour Unicode 6.1[#2] (avant c'était 5.2) ; j'ai aussi ajouté deux-trois boutons plus pratiques sur la description d'un caractère, rien de bien passionnant[#3]. Malgré ça, c'est fou la perte de temps que peut représenter l'écriture d'une nouvelle version : le mécanisme de compilation sous Android (basé sur ant) a changé depuis la dernière fois que j'y ai touché et il m'a fallu me rappeler ce que je savais et recomprendre ce qui avait changé ; mais au passage ils n'ont pas corrigé le bug qui faisait que dès qu'on touche aux ressources de l'application, si on ne force pas une recompilation complète, elles ne sont pas correctement mises à jour dans le paquet, ce qui peut causer de graves maux de tête ; il faut aussi se rappeler comment signer un paquet, quoi faire avec pour l'installer manuellement[#4], etc., et bien sûr comment fonctionne le système de widgets d'Android, comment accéder à la console développeur pour uploader le package, rédiger un changelog ; et se battre pour comprendre comment ils numérotent les versions du système (genre, il faut passer --target 11 à certains programmes pour compiler avec le niveau 10 de l'API, c'est-à-dire celle de la version 2.3.3 d'Android qui s'appelle aussi Gingerbread, c'est terriblement intuitif). Bref.

Tout ça pour avoir le droit de me faire spammer par (1) des mails semi-automatisés de la part de marchés d'applications autres que celui de Google[#5], me demandant de mettre mon programme aussi sur leur site, et (2) des mails d'utilisateurs qui me demandent pourquoi la plupart des caractères s'affichent comme des carrés. Ça c'est la rançon du fait de publier une application Android.

En contrepartie, Google vous donne des caramels mous : c'est comme quand on publie une vidéo sur YouTube, on a droit à plein de stats profondément inutiles donc indispensables sur combien de gens utilisent votre application (resp. regardent votre vidéo), dans quels pays ils sont, quelle est leur couleur préférée et quel est le prénom de leur chat, tout ça avec des courbes interactives et plein d'autres choses encore plus inutiles. Là par exemple, avant la mise à jour, Google me prétend qu'il y a 3455 personnes qui ont actuellement mon application installée (sur 4052 dispositifs Android, et 17105 personnes l'ayant installée un jour ou un autre), que 64% d'entre eux sont aux États-Unis (ce qui est beaucoup parce que — toujours d'après Google — les Américains ne sont que 30% parmi les utilisateurs d'une application quelconque de la catégorie dans laquelle la mienne s'inscrit ; j'imagine que c'est tout bêtement parce que mon application est uniquement en anglais, mais je ne pensais pas que ça jouerait autant), et que j'ai encore autour de 3% d'installations sous Android 1.5 alors que pour l'ensemble de la catégorie c'est plutôt 0.2% (probablement parce que justement mon application tourne encore, contrairement à beaucoup d'autres, sous Android 1.5). Bon, sans doute que dans trois jours je vais voir que le nombre d'utilisateurs sera tombé à ~1000 parce que l'upgrade aura rappelé aux gens qu'ils ont cette application qu'ils n'utilisent jamais, ou parce qu'elle se sera mal passée.

[#] Je crois que je vais toutes les numéroter 0.0.n pour n un entier naturel.

[#2] Voilà, maintenant vous pouvez utiliser le merveilleux U+1F61B FACE WITH STUCK-OUT TONGUE. 😛

[#3] Et j'ai toujours un bug que je ne comprends pas qui fait que parfois la première initialisation de l'application échoue et laisse la base de données verrouillée.

[#4] Ah, et aussi se rappeler comment lancer un émulateur, histoire de tester l'application sur différentes configurations, par exemple une tablette sous Android 4, chose que je n'ai pas sous forme matérielle. Et pester que l'émulation est très (très) très lente. Et se demander pourquoi ces bananes n'ont pas prévu une configuration émulant une tablette Intel au lieu d'une tablette ARM, histoire de bénéficier de l'émulation matérielle du processeur (enfin, à supposer qu'ils en profitent, ce dont je ne suis malheureusement pas certain).

[#5] Ce dernier ne s'appelle plus Android Market, d'ailleurs, mais Google Play. J'ai déjà dit que je détestais la manie de changer le nom des choses ?

On fait tellement de trucs impressionnants en JavaScript de nos jours que ça finit par ne même plus être drôle : là je viens de voir passer SQLite en JavaScript, ce n'est pas tellement impressionnant, en fait, vu qu'ils utilisent Emscripten ; je suis plus impressionné par cet afficheur de PDF écrit par l'équipe Mozilla et qui devrait idéalement permettre de voir des PDF sans plugin, et bien sûr il y a le célèbre JSLinux de l'inénarrable et génial Fabrice Bellard, qui fait tourner un Linux dans votre navigateur. J'attends le jour où quelqu'un portera Firefox ou Chrome en JavaScript qui tourne dans tous les navigateurs, ce qui permettra de dire ah, vous avez un vieux navigateur ? c'est pas grave, on va faire tourner un navigateur moderne dans votre navigateur. [Ajout (2012-04-02) : Tiens, badass JS en a fait son poisson d'avril.]

Mais une chose qui m'étonne est que personne n'a apparemment passé TeX (ou LuaTeX) à la moulinette Emscripten pour produire un TeX-en-JavaScript (le plus proche de ça est JSMath [ajout : ou MathJax, avec lequel je confondais], qui comprend certes un bon bout de la syntaxe de TeX, mais qui n'est pas, et ne prétend pas être, un TeX complet). Outre que ce serait, comme les geeks normaliens aiment dire, grassouille (synonyme approximatif de badass dans badass JavaScript), je peux imaginer différentes raisons pour lesquelles ce serait potentiellement utile.

En vrac et sans rapport :

✱ Dans le cadre de la campagne présidentielle, on nous parle beaucoup des grands meetings que font les candidats, et de l'influence qu'ils peuvent avoir sur les intentions de vote. Mais qui, au juste, assiste à ce genre de meetings ? Et surtout, qui y assiste qui ne soit pas déjà convaincu de voter pour le candidat qui le tient ? Parce que pour assister à un grand show de ce genre où on doit s'ennuyer prodigieusement et être mal assis, pour entendre exactement les mêmes choses qui seront répétées dans tous les médias le lendemain, il faut être sacrément fan du mec en question et vouloir impressionner les copains à dire qu'on l'a vu de près. Du coup, j'ai du mal à concevoir que ces événements puissent servir à quoi que ce soit.

✱ La Belgique pleure la mort d'une vingtaine d'enfants dans un accident de car en Suisse. Le traitement journalistique de ce genre de choses m'agace toujours par le côté « nous n'avons rien à dire, alors disons-le » (si possible avec un envoyé spécial sur place qui n'a rien à dire non plus). Mais je suis aussi toujours agacé par la prémisse implicite que les morts ne sont pas tous égaux : parce que je crois profondément que les êtres humains sont égaux et que par conséquent la mort d'un enfant n'est pas plus triste que celle d'un adulte, et la mort de ces gens que celle des environ 300 personnes qui ont dû mourir aujourd'hui en Belgique (comme n'importe quel autre jour).

✱ De temps en temps, il me prend l'idée saugrenue, en zappant sur ma télé (ce que je fais généralement de façon méthodique en partant de 1), de regarder les chaînes de la TNT au-delà de France Ô (canal 19), qui est normalement la limite au-delà de laquelle il n'y a plus la moindre chance de se trouver quoi que ce soit d'intéressant. Au-delà se trouve une terra incognita peuplée de créatures étranges, des chaînes locales qui ne sont généralement même pas foutues de diffuser un aspect ratio correct, et dont la liste semble changer toutes les quelques semaines. C'est un peu autocratique, la TNT, d'ailleurs : mon récepteur ne me laisse même pas la possibilité de choisir moi-même les numéros que je veux donner aux chaînes, ni de créer manuellement un canal dont je connaîtrais la fréquence, ou de les renommer, ou quoi que ce soit ; et de temps en temps, j'ai un petit encadré qui apparaît pour m'avertir que la liste des chaînes a été modifiée (que ça me plaise ou non). Soit dit en passant, ça a l'air aussi assez impossible de trouver sur le Web une liste complète, parfaitement à jour et si possible autoritative, des chaînes de la TNT avec toutes les chaînes régionales : je m'attendais à trouver ça sur le site du CSA, mais si elle y est elle est bien cachée. Bref, on trouve parfois des choses rigolotes dans cette région mal exploré au-delà du canal 20 : par exemple Demain TV, qui a l'air de partager le canal 21 avec deux ou trois autres, sur lequel je tombe de temps en temps sur des pubs sous-titrées en chinois. Il fut un temps, aussi, où une certaine chaîne diffusait, à chaque fois que je tombais dessus, exactement le même enregistrement d'une sorte de jeu télévisé où les participants étaient dans un théâtre et je n'ai même pas compris ce qu'ils faisaient.

✱ Tant que j'y suis à parler de TNT, un truc qui m'a toujours causé la plus grande consternation, c'est le fait que les chaînes en HD ont besoin d'être sur des canaux différents. Le concept de diffuser deux fois la même information, une fois en basse résolution et une fois en haute résolution, est quand même monstrueusement crétin : est-ce qu'il n'aurait pas été sensé de prévoir dès le début que la résolution allait sans doute être augmentée un jour, et de créer un codec qui permet de trouver l'information basse résolution à partir de la version haute résolution sans décoder celle-ci complètement (par une sorte de mécanisme de peeling) ? Je suppose que des zillions de thèses ont été écrites sur le sujet (et sans doute, malheureusement, aussi, des zillions de brevets déposés), mais qu'au lieu de les utiliser, on a fait la chose la plus stupide qui soit.

✱ Toujours aucun rapport (comme je l'avais promis) : la manière dont est gérée la sécurité de nos locaux à l'ENST Télécom ParisTech est assez étrange. Quand on entre par une entrée de l'école (celle située rue Vergniaud) il faut présenter une carte, mais par l'autre (l'entrée principale rue Barrault) généralement non, alors que les deux mènent exactement aux mêmes bâtiments. Mais ce n'est pas tout : les conditions qui font qu'on demande quand même une carte par l'entrée où on n'en demande généralement pas sont soit qu'on cherche à entrer vers 8h30 (l'heure à laquelle les élèves entrent : peut-être s'agit-il de vérifier que personne ne cherche à se mêler à eux pour assister à nos excellents cours) soit qu'on demande un renseignement à l'accueil (vous cherchez la salle B555 ? commencez par me montrer votre carte). Le concept m'échappe un peu, je dois dire. Et ce qui est rigolo aussi, c'est qu'on a un Wifi Vachement Sécurisé®, mais que dans toutes les salles (où on entre comme dans un moulin, donc) il y a des prises Ethernet sur lesquelles n'importe qui pourrait brancher ceci. Promis, ce n'est pas la raison pour laquelle je me suis acheté des DreamPlugs…

✱ Oui, oui, je sais que j'ai promis une entrée sur les octonions. Mais j'ai commencé à lire des freudenthaleries, alors ça a monopolisé mon attention.

✱ Speaking of which, Jacques Tits est presque mon voisin (il habite rue du Moulin des Prés, et il va dans le même laboratoire d'analyses médicales que moi).

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

On a (en MathML, donc à condition que votre navigateur sache l'afficher correctement) :

$$\cos \left(\frac{2\pi }{3}\right)=-\frac{1}{2}$$

$$\cos \left(\frac{2\pi }{5}\right)=-\frac{1}{4}+\frac{1}{4}\sqrt{5}$$

$$\cos \left(\frac{2\pi }{7}\right)=-\frac{1}{6}+\frac{1}{6}\sqrt[3]{\frac{7}{2}-\frac{21}{2}\sqrt{\mathrm{-3}}}+\frac{1}{6}\sqrt[3]{\frac{7}{2}+\frac{21}{2}\sqrt{\mathrm{-3}}}$$

$$\cos \left(\frac{2\pi }{11}\right)=-\frac{1}{10}+\left(-\frac{1}{40}+\frac{1}{40}\sqrt{5}+\frac{1}{40}\sqrt{-10-2\sqrt{5}}\right)\sqrt[5]{-\frac{979}{4}-\frac{275}{4}\sqrt{5}-55\sqrt{-10-2\sqrt{5}}+\frac{275}{4}\sqrt{-10+2\sqrt{5}}}+\left(-\frac{1}{40}+\frac{1}{40}\sqrt{5}+\frac{1}{40}\sqrt{-10-2\sqrt{5}}\right)\sqrt[5]{-\frac{979}{4}+\frac{275}{4}\sqrt{5}-\frac{275}{4}\sqrt{-10-2\sqrt{5}}-55\sqrt{-10+2\sqrt{5}}}+\left(-\frac{1}{40}+\frac{1}{40}\sqrt{5}-\frac{1}{40}\sqrt{-10-2\sqrt{5}}\right)\sqrt[5]{-\frac{979}{4}+\frac{275}{4}\sqrt{5}+\frac{275}{4}\sqrt{-10-2\sqrt{5}}+55\sqrt{-10+2\sqrt{5}}}+\left(-\frac{1}{40}+\frac{1}{40}\sqrt{5}-\frac{1}{40}\sqrt{-10-2\sqrt{5}}\right)\sqrt[5]{-\frac{979}{4}-\frac{275}{4}\sqrt{5}+55\sqrt{-10-2\sqrt{5}}-\frac{275}{4}\sqrt{-10+2\sqrt{5}}}$$

$$\cos \left(\frac{2\pi }{13}\right)=-\frac{1}{12}+\frac{1}{12}\sqrt{13}+\left(-\frac{1}{24}+\frac{1}{24}\sqrt{\mathrm{-3}}\right)\sqrt[3]{-\frac{65}{2}-\frac{39}{2}\sqrt{\mathrm{-3}}}+\left(-\frac{1}{24}-\frac{1}{24}\sqrt{\mathrm{-3}}\right)\sqrt[3]{-\frac{65}{2}+\frac{39}{2}\sqrt{\mathrm{-3}}}+\left(\frac{1}{24}+\frac{1}{24}\sqrt{\mathrm{-3}}\right)\sqrt[6]{-\frac{4381}{2}-\frac{195}{2}\sqrt{\mathrm{-3}}}+\left(\frac{1}{24}-\frac{1}{24}\sqrt{\mathrm{-3}}\right)\sqrt[6]{-\frac{4381}{2}+\frac{195}{2}\sqrt{\mathrm{-3}}}$$

$$\cos \left(\frac{2\pi }{17}\right)=-\frac{1}{16}+\frac{1}{16}\sqrt{17}+\frac{1}{8}\sqrt{\frac{17}{2}-\frac{1}{2}\sqrt{17}}+\frac{1}{4}\sqrt{\frac{17}{4}+\frac{3}{4}\sqrt{17}-\frac{1}{2}\sqrt{\frac{17}{2}-\frac{1}{2}\sqrt{17}}-\sqrt{\frac{17}{2}+\frac{1}{2}\sqrt{17}}}$$

L'existence de ces formules n'a rien de nouveau ou d'extraordinaire (celles de cos(2π/3) et cos(2π/5) sont essentiellement connues depuis l'antiquité, celle de cos(2π/17) a été trouvée par Gauß en 1796, lequel a aussi trouvé la méthode permettant de calculer toutes les formules de ce genre ; j'ai d'ailleurs déjà écrit une formule de ce genre ici, et la formule la plus compliquée, celle de cos(2π/11), dans l'exercice 5 de cette feuille d'exercices que je donnais quand j'enseignais à l'ENS) ; il s'agit de résultats classiques tournant autour de la théorie de Galois, et d'ailleurs c'est parce que j'écrivais quelque chose sur la théorie de Galois que je les ai calculées (et aussi pour m'amuser avec Sage). Ceci dit, la formule de cos(2π/13) ou cos(2π/11), je ne l'ai jamais vue écrite nulle part dans un bouquin.

Mais une question qui me laisse modérément perplexe, c'est la question de formes plus canoniques que d'autres (plus naturelles, plus élégantes, ce que vous voudrez, bref, préférables) pour ces expressions. Je ne parle même pas de factorisations possibles (comme on peut factoriser une racine 5-ième de 11/4 dans l'expression de cos(2π/11)), mais de réécritures un peu plus profondes. Par exemple, l'expression de exp(2·i·π/17) donnée dans l'entrée liée ci-dessus n'est pas la même que celle donnée dans le livre Galois Theory (formule (9.11) page 239) : j'ai tendance à trouver que la mienne (avec deux racines sixièmes plutôt qu'une racine carrée d'expressions faisant intervenir des racines cubiques) est préférable. Mais une autre formule pour cos(2π/17), qui est assurément moins agréable que celle donnée ci-dessus, et qui apparaît pourtant plus naturellement quand on applique un algorithme systématique, est la suivante :

$$\cos \left(\frac{2\pi }{17}\right)=-\frac{1}{16}+\frac{1}{16}\sqrt{17}+\frac{1}{16}\sqrt{\mathrm{-1}}\sqrt[4]{-255-136\sqrt{\mathrm{-1}}}-\frac{1}{16}\sqrt{\mathrm{-1}}\sqrt[4]{-255+136\sqrt{\mathrm{-1}}}+\left(\frac{1}{32}\sqrt{2}-\frac{1}{32}\sqrt{\mathrm{-2}}\right)\sqrt[8]{73185+39032\sqrt{\mathrm{-1}}+3264\sqrt{2}-6120\sqrt{\mathrm{-2}}}+\frac{1}{16}\sqrt{\mathrm{-1}}\sqrt[8]{73185-39032\sqrt{\mathrm{-1}}-3264\sqrt{2}-6120\sqrt{\mathrm{-2}}}-\frac{1}{16}\sqrt{\mathrm{-1}}\sqrt[8]{73185+39032\sqrt{\mathrm{-1}}-3264\sqrt{2}+6120\sqrt{\mathrm{-2}}}+\left(\frac{1}{32}\sqrt{2}+\frac{1}{32}\sqrt{\mathrm{-2}}\right)\sqrt[8]{73185-39032\sqrt{\mathrm{-1}}+3264\sqrt{2}+6120\sqrt{\mathrm{-2}}}$$

Une autre question sur laquelle je ne sais pas dire grand-chose, c'est comment produire de façon systématique de telles expressions en MathML (pour celles que je viens de donner, j'ai utilisé un mélange de techniques pas complètement automatisées, jusqu'à terminer quelques réécritures à la main). Rien que mettre les termes dans un ordre raisonnable, ou transformer quelque chose qui apparaît naturellement comme −1·x + (−3/2)·y + (2−t)·z (une somme pondérée par des coefficients) en −x − (3/2)·y + (2−t)·z (extraire les signes pour les mettre au niveau de la somme), ce n'est pas évident.

Depuis environ dix-douze ans, j'ai une sorte de nævus, de kyste ou de petite verrue sur le bord de la paupière inférieure de l'œil droit. Je ne sais pas comment cette tumeur a décidé de pousser là, je n'avais rien quand j'étais petit. Mais bon, elle n'était pas gênante non plus, à part un peu quand je pleure (ou que je mets des goutte dans mon œil) car elle doit émettre des sécrétions grasses qui me piquent un peu. Bref. Mais très récemment (deux-trois jours), elle a changé d'aspect, développant elle-même en son bord une petite protubérance d'aspect fort vilain, et un peu noire (ça ne se voit pas vraiment bien sur la photo ci-contre, où on a l'impression que c'est juste le bord qui est un peu plus foncé, mais en fait la couleur noirâtre est plutôt vers l'arrière). Comme en plus elle me gratte un peu plus que d'habitude, tout ceci fait hurler mes alarmes d'hypocondriaque[#] (même si mon poussinet me fait remarquer que la partie altérée est vraiment minuscule), et je vais vouloir la faire opérer le plus vite possible. D'ailleurs j'ai pris rendez-vous lundi chez mon généraliste pour lui demander conseil (qui va-t-on voir dans ce cas-là, quel est le degré d'urgence…).

Je l'ignorais[#2], mais il semble que les paupières relèvent de l'ophtalmologie et non de la dermatologie. Un dermatologue (qui avait pratiqué l'exérèse d'un grain de beauté au menton qui me gênait quand je me rasais) m'avait pourtant assuré qu'il pourrait m'enlever cette chose (je parle de la tumeur, pas de la paupière) si je le voulais. D'un autre côté, il l'avait mentionnée en me demandant qu'est-ce que vous avez à la paupière ?, à quoi j'ai eu envie de lui répondre que c'était plutôt à lui de me le dire que le contraire.

En tout cas, l'idée de voir passer un bistouri à quelques millimètres de mon globe oculaire me réjouit fort peu, mais il va bien falloir s'y résoudre.

Ajout (2012-03-05T18:00+01:00) : Mon généraliste m'a conseillé de voir un dermatologue (il m'a suggéré de m'adresser au pavillon Tarnier, qui est une annexe de Cochin), plutôt qu'un ophtalmologiste, parce qu'il pense que c'est lié à une autre petite lésion que j'ai à la joue du même côté. En tout cas il m'a dit de le faire enlever sans trop tarder. (Et comme il n'a pas voulu se mouiller et a utilisé le mot lésion dans sa lettre au dermatologue, je ne sais toujours pas de quoi il s'agit.)

[#] D'ailleurs, je viens de faire un cauchemar dans lequel une araignée venimeuse entrait dans mes vêtements : et je pense que c'est lié.

[#2] Je ne connaissais pas non plus le mot palpébral.

Puisque l'entrée promise il y a quelques jours semble me prendre un temps infini à écrire, je vais faire ce que je sais faire le mieux dans la vie : râler.

Le modem ADSL de mes parents a des vapeurs assez semblables à celles que le mien avait eues, alors j'ai voulu en acheter un autre. Moralité : c'est devenu à peu près impossible de trouver un modem ADSL qui ne fasse pas le café aussi (le café ? point d'accès Wifi, routeur, firewall, filtre parental[#], what else ?). C'est peut-être idiot, mais psychologiquement ça me gêne d'acheter un truc qui fait le café si je ne vais pas m'en servir pour faire du café, surtout que j'ai déjà une vraie machine à café. Il y a des raisons un peu objectives, d'ailleurs (outre le fait de payer pour rien) : si le truc fait routeur avec N ports Ethernet, c'est prendre le risque que mon papa ait l'idée de brancher un câble dans ces ports-là au lieu de les brancher en aval du vrai routeur ; si le truc fait Wifi, il faut désactiver le Wifi sinon il va faire interférence avec le vrai point Wifi qui est sur un brin différent (pareil, en aval du vrai routeur) : apparemment on peut toujours désactiver le Wifi, mais il y a des risques qu'un reset subreptice le réactive. À part ça, chez Surcouf, pas moyen de trouver un vendeur qui ne soit pas déjà occupé dans une longue conversation avec un client pour lui expliquer que s'il veut imprimer en couleur il lui faut une imprimante couleur alors que s'il ne veut pas imprimer en couleur il suffit d'une imprimante noir et blanc (j'exagère à peine) ; bon, je doute que le vendeur aurait pu me dire quoi que ce soit à part que non tous leurs modems ADSL font le café. Faute de quoi, je me défoule en râlant sur mon blog.

[#] Oui, c'est pour mes parents, mais je ne pense pas qu'ils aient besoin de filtre parental. Les bêtises que mon papa peut faire ne sont pas trop le genre contre lesquelles ce genre de truc protège.