Bientôt 3 ans de travail avec Linutop, il est plus que temps que je raconte un peu le boulot fait sur le Linutop OS depuis les débuts.
Quand Fédéric Baille et Laurent Bervas m’ont contacté en 2007, suite à Solution Linux, le Linutop 1 avait fait ses premiers pas, livré avec un système Xubuntu Edgy (LiveCD) sur clé USB. C’était vaguement utilisable, pas du tout optimisé. Un gros challenge était là : partir d’une solution fonctionnelle mais lourde (1 processeur AMD LX700 et 256M de RAM), pour réussir à obtenir un système plus léger, robuste et utilisable par plus ou moins tout le monde – sans parler de la réduction du temps de boot, 3 minutes, c’est long.
La robustesse est une des idées essentielles du Linutop. Pas de pièces mobiles (disque dur, ventilateur…), un boitier solide, donc pas de casse. Le LiveCD pour l’OS était le penchant robuste du côté logiciel. Peu importe ce qui est fait durant la session, un reboot remet tout en place.
Ceci étant, on est vite limité sans persistance, et c’est d’autant plus dommage quand l’OS est fourni sur clé USB ! D’où la première modification importante, la création d’une seconde partition sur la clé, destinée à héberger les données de l’utilisateur (bookmarks, documents office, photos, j’en passe). Résultat, /dev/sda1 faisait office de système de base (via les techniques de LiveCD), l’écriture système était faite en RAM, et finalement un /dev/sda2 était monté sur /home pour la sauvegarde des documents. Plusieurs avantages à ce système :
- un système de base intouchable et facilement restoré (reboot)
- l’écriture des logs et données de fonctionnement de l’OS en RAM limitent l’usure de la clé USB
- un formattage de la seconde partition restaure la session utilisateur de base
Cette utilisation d’un système de base (à base de squashfs + unionfs à l’époque) sur une partition, et de gestion des données sur la seconde est encore aujourd’hui utilisée, avec des évolutions.
Parmi ces évolutions, la persistance complète. Certains utilisateurs de Linutops ont voulu ajouter des logiciels, ou modifier les configurations sytème par défaut. Problème : comment faire quand tout est écrit en RAM ? Solution : ne plus écrire en RAM 
Le mode persistant du Linutop est une simple extension du principe d’unionfs, en unifiant un système en squashfs avec une partition physique. Cette fois la partition sda2 contient les changements faits au système de base, y compris les données utilisateur. Le passage d’un mode à l’autre est possible (moyennant un reboot), et les données utilisateur conservées. Évidemment cette solution éloigne un peu l’OS de son idée première : la robustesse. L’OS réagit comme un OS standard, si sa configuration n’est pas bonne, il ne bootera pas. La solution de restauration est pourtant toujours possible, puisque le système de base est toujours contenu dans un fichier squashfs indisponible en écriture. Une option de restauration au boot a été ajoutée pour pouvoir simplement rétablir le système initial.
La dernière évolution a été un retour au concept de base. La persistance permettait plus de souplesse, mais apportait ses problèmes. Par sa « puissance » le Linutop implique une mono-utilisation du système (kiosk web, affichage, monitoring). C’est d’autant plus vrai que ce système s’adresse plus à un marché professionnel que consumer. Avoir une possibilité de figer le système dans une configuration est apparue nécessaire, et en accord avec l’idée première du Linutop. Le passage d’unionfs à aufs a fortement facilité l’ajout d’une 3ème couche au système d’unification, c’était le grand retour le la RAM. Le Linutop Lock superpose 3 parties distinctes du système :
- le système de base (squashfs)
- la configuration système et utilisateur (2nde parition de la clé)
- la couche d’écriture (RAM)
Le principe du Linutop Lock est simplement celui d’un LiveCD auquel on a ajouté une couche de configuration modifiable (configuration au sens large, l’ajout/suppression d’applications est aussi possible). Ce mode est idéal pour placer la machine à disposition d’utilisateurs de non-confiance (pour un kiosk internet par exemple). Si jamais l’utilisateur arrive à endommager le système, les dégats ne sont présents qu’en RAM, et un reboot suffit à tout restaurer. Résultat : 0 maintenance du matériel, 0 maintenance du système.
Un autre élément qu’a apporté ce système de partitionnement est une simplicité de déploiement. La plupart des clients Linutop déploient des machines sur de nombreux sites, systématiquement avec la même configuration. Des outils simplissimes d’utilisation permettent en 2 clics (ou une commande, je reste un geek quand même) de dupliquer intégralement un système sur clé USB bootable. L’opération est faisable en sens inverse bien évidemment. 1 Linutop maître est configuré, dupliqué sur une clé USB, et cette clé contenant le système bootable est utilisée comme source d’installation pour tous les autres Linutop ! Idéal pour diffuser une nouvelle version, ou une clé de restauration à des dizaines de sites. L’automatisation du « flashage » du disque interne permet à n’importe quel utilisateur de faire une installation d’un système préconfiguré en 3 minutes. Pas de prise de main à distance, pas de déplacement, et des connaissances plus que minimum nécessaires pour installer (je pense qu’à peu près tout le monde peut brancher une clé USB et appuyer sur le bouton de power !).
Le matériel Linutop a vraiment été conçu pour réduire les coûts de maintenance, son OS a suivi la même voie, et je pense que le résultat n’est pas mauvais
Parallèlement au développement de l’architecture, celui de l’interface a été le résultat de nombreuses réflexions sur ce que l’utilisateur attend en démarrant son Linutop. Plus du détails dans un prochain post…
