On connaît la bataille de clochers entre libristes, ou du moins entre fervents libristes de l'église de St-GNU et ceux qui promeuvent le libre uniquement pour supériorité technique -- tels Linus Torvalds : faut-il dire "Linux" ou "GNU/Linux" ? Pour ma part, je me sers de l'expression "GNU/Linux" dans mes interventions afin de bien différencier ce qui relève du noyau "Linux" de ce qui relève du système libre "GNU". Car on peut fort bien utiliser GNU sans Linux, par exemple avec des environnements Cygwin, gcc, gdb, OpenOCD, Eclipse, pour des systèmes propriétaires tels que VxWorks, LynxOS ou QNX (qui ont tous trois des SDK basés sur les logiciels libres précédemment cités ! Et peuvent en partie utiliser des logiciels libres, sans que cela constitue l'intégralité du système hors noyau). La question d'utiliser Linux sans GNU se pose aussi : certains diront que le projet Busybox ou que la uClibc n'en font pas partie, cependant on peut pondérer cette assertion sur le fait que la licence est la GNU/GPLv2, et qu'à vrai dire je ne suis pas convaincu du tout qu'un projet comme la busybox ne soit amusé à recoder les plus de 200 logiciels regroupés qui la composent, notamment des aussi complexes que vi ; quelque part, tout est issu plus ou moins du projet GNU.

Mais peu importe à vrai dire, car le message technique associé pour l'embarqué et la redéfinition des relations associés à l'emploi de (GNU/)Linux est le suivant : le système d'exploitation hors noyau est indépendant dans une large mesure du noyau lui-même. C'est-à-dire qu'il a été conçu certes en utilisant par exemple des IOCTL propres à Linux, d'une manière marginale, mais surtout sur une base POSIX la plus indépendante possible, puisque le projet de noyau de GNU reste avant tout le Hurd. Et que donc même la libC (glibC) est fondé dans cette optique-là. Ceci est une différence fondamentale avec le projet libre OpenBSD, par exemple : ne désignant pas seulement le noyau mais l'ensemble du système d'exploitation complet, même si le noyau /bsd est bien délimité (contrairement à Windows, par exemple, où l'on ne sait jamais très bien où ça commence et où ça finit), le système forme un tout homogène et surtout inséparable dans ses versions. C'est-à-dire que non seulement il est bien spécifié que l'on ne doit pas s'amuser à mélanger les versions de logiciels, car sinon aucun support ne sera assuré par la communauté, mais en plus de cela il y a réellement des problèmes dans la réalité (on aurait pu croire à un simple warning anti-n00bs, comme le découragement de recompiler à partir des sources).

Sur un projet récent j'embarquais de l'OpenBSD 4.2 ; manque de chance, le support de la carte flash était très lent sur cette version, alors que sur la version 4.3 sorti entre temps, cela allait beaucoup mieux. Nul problème quant à une mise en production (le gain est faible sur de petites tailles à écrire, et aucune échéance de temps n'était à respecter absolument), mais gros problème quant à la mise en place usine de master complet sur une mémoire d'un giga octets : la décision fut prise d'utiliser en interne, pour l'opération de flashage, le noyau d'OpenBSD 4.3 sur le système 4.2 longuement mis au point. Et un problème arriva rapidement : le but étant de flasher une image téléchargée sur le réseau via notre ramdisk hybride 4.2/4.3 (opération très classique inspirée par la méthode de gestion de parcs via PXE), une configuration réseau via ifconfig était nécessaire, et autant un ifconfig <interface> <ip> passe très correctement, autant un ifconfig tout court renvoie les pires erreurs imaginables, au lieu de lister les interfaces et leurs propriétés. On ose imaginer ce que cela donnerait pour des programmes plus complexes dont il faudrait retester toutes les options possibles pour s'assurer du bon fonctionnement complet du système : ce n'est pas envisageable !

Fort heureusement, cette éventualité d'impossibilité de pouvoir changer le noyau seul sans le reste du système, ou inversement, avait été évoqué dès le début, et cela ne pose aucun problème à notre projet (il n'est pas impossible de patcher manuellement des logiciels particuliers et d'en assurer la rétrocompatibilité, cependant, mais on ne saurait changer totalement de version). Cependant, ce genre de problématique est à prendre à compte dès lors que l'on souhaite obtenir un système pouvant être mis à jour de manière massive, par exemple lorsque Nokia décide de changer l'interface complète de son système basé sur Maemo (incluant une mise à jour de la libC) ; en l'occurrence, leur choix de reposer sur un ramdisk pour Linux a eu pour avantage la possibilité de mettre à jour le noyau pour activer au passage le support de l'EABI (ce qui impliquait à l'époque du noyau 2.6.16 une recompilation totale du système ; il existe à présent une fonctionalité de rétrocompatibilité avec/sans EABI marquée expérimentale dans le kernel), mais cela ne saurait être toujours le cas (notamment parce que cette solution de ramdisk implique un temps de boot allongé, c'en est même indécent sur le N770) : comme nous le disions la dernière fois, ne serait-ce que pour des questions de sécurité, positionner le noyau en flash au dehors de tout file system est pratique extrêmement courante (on remarquera d'ailleurs l'option "-kernel" de qemu qui permet de faire booter un système de fichier en utilisant un kernel Linux externe). Il est donc souvent inenvisageable de mettre le noyau à jour (on peut toujours faire des dd avec seek pour écrire dans /dev/mem en raw, en calculant de ne pas déborder et en serrant les fesses... Je ne conseille pas !), alors que le système peut être appelé à évoluer (la mode est au reflashage de firmware ajoutant et corrigeant des fonctionnalités, les téléphones proposent cela, toutes les STB des FAI du marché aussi).

On peut élargir cette vision ultra-modulaire des choses au noyau Linux lui-même, qui hérite en sa conception intrinsèque de cette philosophie : alors que le noyau BSD forme un tout dont on déconseille très fortement de toucher à quelque option que ce soit (et il n'y a qu'à voir le fichier de configuration pour s'en convaincre), le mode de compilation de Linux se base sur une interface (en ligne -- make config --, en curses -- make menuconfig --, en Qt -- make xconfig --, ou en GTK -- make gconfig), où l'on coche et décoche ce que l'on souhaite (avec quasiment toujours la possibilité de mettre un support kernel en module chargeable et déchargeable à chaud), et uniquement cela, on peut même penser à activer le support des modules et tout mettre en dur, en prévision du jour où l'on voudra supporter des matériels brachés sur un hypothétique USB, et que l'on voudra alors supporter en ajoutant un driver au système (y compris rajouter le support d'un système de fichier : je suis bien content de pouvoir brancher mon disque dur en XFS sur mon disque dur multimédia, et j'aimerais bien que ce support revienne comme avant sur ma Freebox). La configuration de Linux supporte en outre la gestion des dépendances des modules les uns aux autres, et au final, alors que le projet OpenBSD dont la cible est l'informaticien expérimenté est peu propice au bidouillage, les sites pour utilisateur débutant de Linux proposent des tutoriels de (re)compilation du noyau !

Lorsque l'on voit sur distrowatch l'hétérogénéité des versions logicielles utilisées pour de mêmes kernels Linux (qui eux-mêmes ont un nombre de versions différentes très important, et non une release chaque semestre), ou inversement d'ailleurs (de mêmes versions logicielles pour des kernels différents), on voit bien que le problème ne se pose pas pour GNU/Linux : sa conception modulaire puisqu'agrégative de projets différents (GNU, Linux, autres projets de l'embarqué greffés sans pouvoir préjuger des autres logiciels employés, la Busybox marchant tout aussi bien avec la glibC qu'avec l'uClibc), assure une supériorité technique indéniable. Si l'on considère que les autres projets propriétaires de l'embarqué ont toujours été conçus comme le sont les projets BSD (incompatibles entre eux par ailleurs), on peut donc préjuger là encore d'un avantage majeur de l'emploi du noyau Linux et des projets libres utilisés pour consituer un système d'exploitation complet, dans la droite ligne de ce qui est attendu d'un système embarqué moderne gérant la communication, et donc potentiellement la mise à jour, tout autant que la possibilité de faire "librement" son marché entre les versions logicielles, amenant au problème du packaging (il faut choisir des versions logicielles compatibles entre elles, bref gérer la problématique propre à toute distribution Linux, qu'elle s'appelle Debian, OpenSUSE ou OpenEmbedded), mais aussi à sa puissance incomparable et jamais égalée par aucune autre solution logicielle existante.