Journal Fedora Silverblue sur un mini laptop

Sommaire

• • choix de la distribution et support
  • Expérience flatpak mitigée
  • Installations d'applications: alternatives
  • les cas nix/guix/pkgsrc
  • la compilation des applis
  • le cas des applis écrites dans des langages interprétés
  • les conteneurs
  • l'outil Toolbox
  • Conclusion

Aujourd'hui je vais vous compter une expérience récente l'acquisition un mini laptop 7", le Pocket 2 de la marque GPD. On pourrait palabrer longtemps sur la pertinence de ce type de mini laptop à processeur intel lorsque les smartphones sont de plus en plus efficaces et où une tablette tournant sur ios ou android pourrait aisément remplir le même usage associé à un clavier externe. Pour ma part le choix s'est fait pour les raisons suivantes:

• je voulais un outil le plus léger et compact possible pour pouvoir l'emporter avec moi en vélo ou autre activité sociale ou d'extérieur lorsque je suis d'astreinte sans avoir à porter un lourd sac à dos. Même les solutions à base de petite tablette + clavier ont du mal à passer sous les 600gr.
• je voulais un système libre. Les tablettes supportées par lineageOS sont essentiellement des modèles haut de gamme chères et/ou difficilement trouvable en bon état d'occasion.
• je veux un truc fiable. D'expérience, les trucs à base de bluetooth c'est pas toujours top et tu dois des fois t'énerver à desappairer/reappairer le bordel pour que tout remarche. Je ne veux pas devoir gérer ce genre d'épisode quand je réponds à une alerte du monitoring ou un appel d'un collègue/client.
• je voulais un truc qui soit maintenu/maintenable plusieurs années et qui peut éventuellement être réutilisé comme mini serveur le jour où la batterie perd beaucoup d'autonomie, j'ai essayé une fois avec un vieux smartphone et une vieille tablette. Malgré quelques applis serveurs et termux, c'était difficilement réutilisable en quelque chose de sécu et pertinent.
• je voulais un système très proche du laptop que j'utilise au quotidien, sur lequel je peux utiliser les mêmes outils et applications et synchroniser certaines config.

Il existe d'autres modèles de mini laptop, de la marque onemix par exemple, ou son frère le GPD Pocket 2 Max qui disposent d'un vrai trackpad, un clavier plus agréable et un cpu plus puissant mais celui-ci a gagné la main pour son prix plus abordable et son poids/ encombrement plus réduit.

choix de la distribution et support

Ce modèle a déjà quelques années donc toute éventuel problème de support matériel a été réglé depuis belle lurette et on peut choisir sa distro avec sérénité. Vu que ce laptop n'est pas utilisé quotidiennement, je me suis orienté vers un systèm̀e atomique afin de faciliter les mises à jours système. Utilisant quotidiennement Fedora sur mes laptops pros et personnels, mon choix s'est naturellement tourné vers Fedora Silverblue, initialement dans sa version beta 34. Il propose un système à base de rpm-ostree où les répertoires systèmes sont montés en lecture seule à base d'image. Une update consiste à télécharger une nouvelle image et l'utiliser au boot suivant. En cas de problème le boot sur l'image précédente reste accessible via une entrée grub. L'usage normal proposé pour les applications supplémentaires est de les installer dans le home de l'utilisateur sous forme de flatpaks ou de containers via podman. En cas de non disponibilité ou pour installer une appli touchant au plus près au système il est possible d'utiliser rpm-ostree pour l'installer sous forme de couche supplémentaire de type "overlay" mais globalement il est conseillé d'éviter pour garder l'atomicité du système.

La particularité de ce laptop est qu'il a sans doute été fabriqué avec un écran tactile destiné aux tablettes dont le sens par défaut est en mode portrait. J'imagine que le windows 10 qui vient livré avec dispose d'un driver qui réoriente tout dès le départ mais sur un linux ce n'est pas le cas jusqu'à ce que tu le configure dans le bon sens. Pour ma part j'ai atteins un stade où grub, gdm et gnome sont en mode paysage mais le reste du boot, y compris l'invite pour déchiffrer la partition LUKS, sont en mode portrait. Du coup quand on zappe plymouth pour voir les logs du boot on a l'impression de regarder les leds d'un equalizer. C'est pour l'installation que c'est plus compliqué car le seul moyen de le connecter à un écran est d'utiliser usb-c, je n'avais pas d'écran avec entrée usb-C et la seule connectique que j'avais à ce moment à disposition était une docking usb-c nécessitant un driver display link. Heureusement l'écran se déploie à plat et je l'ai donc connecté à clavier et souris externe en le regardant en mode portrait, posé comme un livre sur un pupitre.

Une fois installé dans gnome l'orientation se fixe de manière permanente dans l'option orientation de l'outil de paramétrage des écrans. Cela génère un fichier dans ~/.config/monitors.xml qu'il suffit de copier dans /var/lib/gdm/.config pour qu'il l'applique aussi à l'invite de login.

Le reste est sans histoire.

Expérience flatpak mitigée

Le repo flatpak Fedora fournit avec la Silverblue se limite aux applications Gnome. Une fois installé le flathub comme source on a accès à un peu plus mais force de constater qu'en terme d'applications disponibles et intéressantes, le flathub c'est un peu le désert de Gobi. Pire, la qualité des packages, non auditée ni soumise à des règles strictes, est très inégales et certaines applications une fois installées ne démarrent tout simplement pas et certaines applications packagées ont parfois des fonctionnalités bridées par le sandboxing si il n'a pas été pris en considérations lors de son developement. Cela touche particulièrement les applications ayant un support de plugin ou des fonctionnalités d'exports où les chemins utilisables seront différents de ceux mentionnés dans la documentation. Un admin chevronné et rompu au concept des sandbox peut s'en sortir, mais je pense que c'est inadapté et déroutant pour un débutant ou quelqu'un de non intéressé par ce qui se passe sous le capot.

Cette expérience mitigée m'a fait étudier les différents autres modes d'installation/exécutions à notre disposition.

Installations d'applications: alternatives

Nous vivons dans un monde où certaines applications sont fournies sous forme de paquets AppImage, téléchargeables sous forme de binaire statique sur une forge. C'est typiquement le cas, mais pas exclusif, des outils cli écris en go de l'univers devops/kubernetes. On a aussi la tripotée d'outil installable via un script shell, le fameux curl pipé vers bash. Non seulement c'est très bordélique mais en plus c'est parfois incompatible avec une distro ayant le système en lecture seule quand cela demande des droits root et que le script tente d'écrire dans des dossier systèmes sans contrôle des destinations par l'utilisateur.
Globalement, même si je n'exclus pas ce moyen pour certaines applications que j'apprécie vraiment, comme le très pratique client kubernetes k9s, je tente de limiter ces modes d'installation au maximum car c'est une plaie à gérer en terme de maintenance et mises à jours, sans compter sur l'obscurité et la confiance nécessaire pour les installeurs. Aussi, en terme de sécurité c'est pas top. Ayant toute liberté sur le répertoire home de l'utilisateur, il suffit qu'une seule application soit accompagnée de code malicieux pour que celui-ci se répande sur tout autre binaire installé de la même manière.

Cette expérience mitigée m'a fait étudier les différents autres modes d'installation/exécutions à notre disposition.

les cas nix/guix/pkgsrc

Ces 3 systèmes s'attendent à pouvoir écrire dans / et ne sont pas adaptés à silverblue. Il est possible de les faire tourner dans un schroot ou proot (pour les amoureux de weboob) mais encore faut-il avoir le binaire statique dans son homedir pour pouvoir l'exécuté. C'est au final peu élégant.

la compilation des applis

Si le projet est petit, actif, respecte l'utilisateur final et présente proprement ses sources avec descriptions des dépendances et recettes de constructions (makefile, meson, …) c'est relativement sans douleur. Dès que le projet est plus gros on rigole moins (temps de compilation, consommation énergétique,…) et si le dev est brouillon ou ne gère pas bien le cycle de vie de ses dépendances toute la simplicité disparaît. Et on en revient à faire le travail d'un mainteneur de package de distro, vite chronophage si l'application doit être mise à jour fréquemment pour raison de sécurité.

le cas des applis écrites dans des langages interprétés

Dans le cas d'applications en ligne de commande, nombre d'entre elles s'installent facilement via les outils tels que pip, rubygem, npm, cpan (et j'en passe). De plus ces projets de partage de modules ont de la peine à convaincre quand à leur capacité d'audit des modules présentés et les dev analysent rarement le code des modules dont ils font dépendent leurs applications. Il est relativement facile de contaminer des centaines voir milliers de projets à partir d'un module très populaire.

Pour les applications ayant des dépendances plus complexes ou utilisant des toolkits graphiques particuliers, l'installation à partir des sources du projet est un peu plus aléatoire.

les conteneurs

L'utilisation des conteneurs parait de prime abord fastidieuse. D'une part je n'aime pas utiliser des images toute faites par des inconnus et je préfère me limiter aux images de base officielles des distros ou de gros projets upstream sérieux. Il peut m'arriver de naviguer dans le docker hub, découvrir des images intéressantes, mais dans ce cas- ou de gros projets upstream sérieux. Il peut m'arriver de naviguer dans le docker hub, découvrir des images intéressantes, mais dans ce cas-là j'irai chercher le dockerfile correspondant sur la forge ad hoc, analyser le contenu et éventuellement recréer l'image en local. Pour le cas de l'installation d'une appli packagée par les distros, l'écriture d'un dockerfile avec 3 instructions simples FROM/RUN/CMD suivi d'un podman build est relativement rapide mais toujours moins que de faire un dnf/apt install ou pacman -S. Au final on se retrouve aussi vite avec une palanquée d'images avec dockerfile correspondantes à maintenir et construire/mettre à jour régulièrement pour avoir des applis à jour. Si on possède plus d'une machine dispo on a vite intérêt à mettre en place un flux de travail de type déploiement continu avec reconstruction des images automatiques et push vers une registry publique ou privée.

Cette organisation est fragile, et peut casser à tout moment si on ne se limite pas à des paquets disponibles via les distributions et oblige à se maintenir au courant des changements des projets upstream. Projet qui change de forge, source qui ne compile plus sans faire des changements dans les dépendances, chemin et nom des binaires précompilés difficiles à deviner/automatiser, etc.

l'outil Toolbox

Toolbox est un outil dont le but est de faciliter la création d'environnements dédiés utilisant les conteneurs avec podman. C'est un peu comme un virtualenv pour les pythoniste mais se fait à niveau d'une distro, un peu comme installer un chroot mais en plus facile et plus élégant. S'il n'est à la base pas destiné à cet usage il est parfaitement apte à fournir la possibilité à un utilisateur d'installer rapidement un ou une liste de packages, de séparer logiquement des environnements d'exécution (travail, loisir, jeu) et simplifie la gestion des containers. Pas besoin de déclarer manuellement le montage du home pour avoir y avoir accès. Sous Silverblue, l'installation d'une appli se résume à créer une toolbox (toolbox create mabox), intaller l'appli via dnf (toolbox run -c mabox sudo dnf install -y monappli) et l'exécuter (toolbox run -c mabox monappli). Les applis graphiques fonctionnent (en tout cas sous wayland, je n'ai pas testé hors de gnome sous wayland). C'est donc devenu mon outil privilégié pour installer des applis sur mon Pocket 2.

Mais il y a un bémol. Il en fallait bien un non? Tout appli qui devrait être accessible rapidement via le launcher de votre environnement de bureau favori ne l'est pas. Ben oui, le fichier .desktop est confiné dans la toolbox. Alors il est possible de le créer manuellement dans votre ~/.local/share/applications mais c'est pas drôle, et requiert une recherche/copie manuelle de l'icône si vous en voulez un.

Conclusion

Mis à part que la touche tab et quelques autres ne sont jamais là où je le voudrais je suis assez content de mon GPD Pocket 2. D'ailleurs ce journal a été intégralement écris avec celui-ci, d'abord dans un train Suisse, puis dans un avion easyjet pas réputé pour l'espace disponible pour travailler sur un ordinateur.

Je suis beaucoup moins convaincu par le flathub et l'utilisation d'une distro de bureau atomique. C'est une très bonne idée pour des systèmes serveurs destinés à héberger des applications sous forme de conteneurs mais pas encore prêt pour le desktop. Oui j'ai pu finalement installer tous les outils disponibles et toolbox m'a beaucoup facilité la tâche, mais il aurait été bien plus pratique et rapide d'utiliser une fedora traditionnelle. Si rpm-ostree facilite les maj système, je dois toujours continuer à maintenir les applications sur les toolbox à coup de dnf update. Je n'y ai pas gagné, ni en temps, ni en applications. Et pour qui veut toujours utiliser ses technologies pour des cas particuliers, podman et toolbox sont disponibles aussi sur une Fedora standard.

Je vais continuer encore à l'utiliser quelque temps car je veux tenter de faire tourner une toolbox sur une distro différente de la fedora. C'est techniquement possible, mais j'ai échoué à ma première tentative de construction d'images alpine, archlinux et nixos. Je dois éplucher un peu plus la doc et reviendrait un rapport en bonne et due forme.