Bluefin vs Fedora Silverblue My 8-Year Immutable Journey
Cette vidéo retrace huit années d’évolution personnelle avec les distributions Linux immuables, de Fedora Silverblue 29 à Bluefin, en passant par Kinoite, et explique pourquoi l’auteur a finalement adopté Bluefin comme système quotidien.
SYNTHÈSE STRUCTURÉE
Le premier contact avec Silverblue : une confusion initiale
L’auteur admet que sa première tentative avec Fedora Silverblue 29 en 2018 a été un échec, non pas à cause du logiciel, mais parce qu’il ne comprenait pas son intention. Il décrit cette version comme « expérimentale, incomplète et un peu déroutante », notamment à cause de la multiplicité des méthodes d’installation de logiciels. Il a donc choisi de ne pas publier sa vidéo et de continuer à tester en arrière-plan.
La révélation : un système de contrôle de version pour une distribution
C’est un commentateur de la version 30 qui a fait tilt : « ça ressemble à un système de contrôle de version pour une distribution Linux ». L’auteur précise que cette analogie est juste, mais incomplète, car le vrai changement est la séparation stricte entre les parties du système de fichiers en lecture seule et celles en lecture-écriture. Cette architecture est le fondement de l’immuabilité.
La discipline d’installation : garder l’immuable propre
L’auteur insiste sur une règle apprise après des années de tâtonnements : « la discipline est de garder la partie immuable aussi propre que possible, aussi proche de l’état d’origine que possible ». Il recommande d’utiliser rpm-ostree pour installer des services, car ils ont une influence plus large que les applications isolées. Il met en garde contre l’exécution de logiciels depuis un répertoire de travail, une pratique qu’il qualifie de « à ne jamais faire ».
Le besoin de redémarrage après chaque installation
Un point d’adaptation majeur a été le fait que chaque ajout via rpm-ostree nécessite un redémarrage pour être actif. L’auteur compare cela à Windows, avec une pointe d’ironie : « j’ai cru revenir sur Windows pendant une minute ». Il mentionne qu’il existe peut-être une option expérimentale pour éviter ce redémarrage, mais sans certitude sur son statut actuel.
Kinoite et l’échec matériel : le problème du CPU Intel
L’auteur a testé Kinoite (la version KDE de Silverblue) à partir de Fedora 35, puis l’a adoptée en 37, mais a dû revenir en arrière. Le problème n’était pas le logiciel, mais son laptop avec un CPU Intel de 9e génération qui « tournait chaud, même au repos ». Il explique que même après avoir augmenté la RAM de 16 à 32 Go, le système restait surchargé par les processus Linux standard. Il est revenu à Fedora Workstation 38 pour pouvoir désactiver manuellement les services inutiles, comme on éteint une lumière.
Le passage à AMD : un changement décisif
En décembre 2024, l’auteur a acheté un Minisforum X7 Ti avec un Intel Core Ultra 9 185H, mais le noyau Linux n’était pas encore prêt pour cette machine. Il a ensuite testé un GMK Tech Evo X1 avec un Ryzen 9 HX370, et là, tout a changé : « le système AMD était rapide, avec de la marge, et il tourne frais même avec une charge importante ». Il conclut que la course entre Intel et AMD est « terminée » en faveur d’AMD, du moins pour son usage.
Bluefin : la découverte de la curation
Après avoir testé Bazzite (orienté gaming) sans conviction, l’auteur a installé Bluefin sur un second disque, par habitude de considérer GNOME comme la version flagship. Il explique que Bluefin offre bien plus de fonctionnalités pour rendre GNOME utilisable : un dock, des indicateurs d’applications, Homebrew (via Bubblewrap), de meilleurs codecs, et des ISO prêtes à l’emploi pour les cartes NVIDIA. Il note que Bazzite et Aurora proposent aussi ces ISO.
La gestion des mises à jour avec ujust
Bluefin et Aurora utilisent ujust pour gérer les opérations dans l’arbre rpm-ostree. La commande rebase-helper permet de choisir entre plusieurs canaux de mise à jour : le défaut est une mise à jour à long terme (stable), mais on peut opter pour des mises à jour quotidiennes ou même un modèle plus proche d’une rolling release. L’auteur apprécie cette flexibilité, qu’il compare à la rigidité de Fedora standard.
La migration entre GNOME et KDE : un avertissement
L’auteur cite le guide de migration Universal Blue : il est possible de rebaser Silverblue vers Bluefin, ou Kinoite vers Aurora, mais il est déconseillé de passer de GNOME à KDE ou inversement. Il confirme avoir vu des problèmes même sur des systèmes non immuables lors de tels changements. Il prévoit donc de tester la migration de Kinoite vers Aurora comme prochain défi technique.
L’usage quotidien : une combinaison d’outils
L’auteur décrit son workflow actuel : rpm-ostree pour les services, Homebrew pour quelques outils, Flatpak pour la majorité des applications, et deux AppImages pour des logiciels qui ne sont disponibles que sous ce format. Il note que Bluefin utilise distrobox comme gestionnaire de conteneurs par défaut, là où Silverblue utilise toolbox, et qu’il trouve distrobox plus simple à utiliser.
Le souhait d’une version sans systemd
En conclusion, l’auteur exprime un regret : « j’aimerais qu’ils sortent une version sans systemd, ce serait génial ». Il évoque aussi l’état des autres distributions immuables : Ubuntu travaille sur quelque chose, Debian reste discret, et il recommande Vanilla OS pour ceux qui préfèrent une base Debian.
CONCEPTS CLÉS
- Immuabilité : séparation stricte entre les fichiers système en lecture seule et les données utilisateur en lecture-écriture, permettant des mises à jour atomiques et des rollbacks.
rpm-ostree: outil de gestion des images système pour les distributions Fedora immuables, permettant d’installer des paquets dans l’arbre système.ujust: commande de gestion des tâches et des canaux de mise à jour pour Bluefin et Aurora, basée surjust.distrobox: outil de gestion de conteneurs Podman, utilisé par Bluefin pour fournir un environnement de développement intégré.- Rebase : opération qui change la base d’une installation immuable d’une image à une autre, par exemple de Silverblue à Bluefin.
CONCLUSION
Cette vidéo illustre un parcours d’adoption progressif, marqué par la compréhension de la philosophie immuable, la gestion des contraintes matérielles, et la découverte de la curation offerte par Bluefin. Le message principal est que l’immuabilité n’est pas une mode, mais une discipline qui, une fois maîtrisée, offre stabilité et flexibilité. L’auteur conclut : « après huit ans de tests, c’est devenu mon système quotidien, et je reste sur Bluefin ». Pour un administrateur, cela souligne l’importance de choisir une distribution immuable adaptée à son matériel et à ses besoins, et de respecter les bonnes pratiques d’installation pour éviter les pièges.