Skip to main content
Seb's blog
logo PassionGNU/Linux

Pourquoi je déconseille openSUSE Aeon?

C’est rare chez moi, mais pour une fois je déconseille un projet openSUSE, tout ce qui touche de loin ou de près à Aeon, je pense à sa version kde ou encore Xfce avec Baldur, mais on va parler avant un peu du projet.

Alors Aeon qu’est que c’est? C’est plus ou moins une Silverblue sans être Silverblue, ça se veut atomique, immuable, tout ce qui est normalement cool et moderne mais en faite ça n’est rien de ça.

Si je lis un peu sur Fedora Silverblue, je trouve ceci:

Ostree fournit l’infrastructure nécessaire pour mettre à niveau efficacement le système de base. Les mises à jour du système d’exploitation adoptent une approche appelée mise à jour atomique, dans laquelle il vous suffit de télécharger une nouvelle image et de la déployer, sautant ainsi l’étape d’installation requise pour les mises à jour de packages conventionnelles. Cela élimine les pannes potentielles du système ou des applications qui pourraient survenir lors des mises à jour de packages en direct. De plus, grâce à Ostree, il est possible de revenir facilement aux versions précédentes du système, offrant ainsi une couche supplémentaire de sécurité et de flexibilité.

En gros de ce que j’ai compris et vu, c’est que nous avons une image en lecture seule, que pour ajouter des applications nous avons deux possibilité et une autre un peu à part, nous avons les flatpack et RPM-Ostree, puis nous avons Toolbox, où nous pouvons avoir une distribution classique conteneurisée. Les mises à jours seront une installation globale d’une nouvelle image, nos applications installées en dehors de cette image sera juxtaposé par dessus. A chaque nouvelle version, nous devons pointer sur l’ISO/image pour migrer, ce n’est pas une rolling.

Le projet openSUSE, ou plutôt un groupe de personnes opiniâtres du projet ont voulu faire une autre approche qui semblait à première vu bien plus flexible que la chose de Fedora, une base rolling, continuellement mis à jour basé sur le système de fichier BTRFS, où on installerai principalement des flatpack; avec une autre façon d’avoir quelque chose de plus coutumier avec une distribution conteneurisée via distrobox, et pour finir il serait autorisé mais déconseillé d’installer des RPM via zypper-transactional.

Chez Fedora, le coté immuable / atomique est de base par sa façon d’être construite, or l’openSUSE c’est avant tout le système de fichier qui va encore faire le rôle, tout ce qui va être retour en arrière, annulation d’une configuration, sera géré par BTRFS. Là où Fedora permettra de revenir facilement à la configuration et l’état d’origine par sa façon d’être pensé, openSUSE ne sera pas capable de le faire aussi facilement, et surtout c’est au niveau système de fichier que ça sera possible.

Ce qui me gêne le plus c’est le coté opiniâtre des personnes sur ce projet, c’est bien d’avoir ses opinions, de savoir en parler, de les imposer quand il faut le faire, mais là ça va trop loin. Zola est un projet opiniâtre, j’en ai déjà parlé ici, le développeur à ses idées et il ne partira pas autre part; son application tout comme lui veut faire une chose bien et d’une façon bien stipulé, ça me va pas je vais ailleurs, dans les choses qui me font hurler je note l’utilisation du TOML au lieu du habituel Yaml pour les entêtes dans les fichiers .md, entre autre chose,… Et bien là c’est pareil, nous avons donc du flatpack, sur des machines ultra récente on ne ressent rien, sur des machines de 2018 on commence à voir des lenteurs, ensuite le flatpack n’est pas flexible, ce seront les seuls reproches que je ferai sur ce point. Que ce soit Fedora ou openSUSE pour el coup on est au même tarif, personne s’en sort gagnant. L’autre point qu’ils ont en commun est d’avoir conteneurisé une distribution classique via distrobox / toolbox pour avoir un semblant de fonctionnement plus commun à ce que l’on connaît et pour finir nous avons l’utilisation des RPM plus classiques, le soucis c’est que sous openSUSE c’est en dernier recours et c’est déconseillé. Un exemple de decisions stupides et même dangereuses, l’absence total de pare-feu, avec la non possibilité d’en installer un autrement que par les RPM qui forcément d’après le grand Richard donnera droit à un WONTFIX en cas de soucis.

Richard Brown à toujours été un personnage clivante, soit on adore soit on déteste, tant qu’on a pas affaire avec ce personnage, c’est bon… Dans Richard Brown has retired as chairman of openSUSE. New chairman is Gerald Pfeifer (et c’est un exemple parmi tant d’autre) on peut comprendre le personnage et le soulagement de le voir partir de son role de chairman.

I hope he can steer that ship around. openSUSE has some nice ideas that are let down by lack of polish in other areas, and IME in interacting with him the previous chairman wasn’t exactly a welcoming fellow that facilitated the entry of new contributors, to put it mildly.

Best of luck to Mr. Pfeifer!

ou encore

I had a few encounters with him. He seemed kind of blunt and aggressive in his defense for openSUSE. You can be passionate without being aggressive. That guy did not get the difference. Best of luck to the new Chair. I hope he paints a nicer, more mature image.

Donc revenons sur les points qui me poussent à déconseiller la openSUSE Aeon et ses semblables, elles sont atomiques et immuables, oui c’est vrai, mais tout de même j’ai pas une grosse différence entre ça et ce que je peux avoir avec une Leap (ou autre) + BTRFS + Flatpack. En fait, je n’ai pas l’impression que c’est la distribution qui fait le taf, mais juste le système de fichier, or celui-ci est disponible partout. Le coté immuable est avant tout obtenu par l’utilisation du flatpack, et le coté atomique est surtout dû au système de fichier.

Si je regarde un billet de Linux-Console, on m’explique ce que c’est justement le atomique/immuable:

Une distribution Linux immuable est un système d’exploitation (OS) qui est essentiellement en lecture seule. Cela signifie que vous ne pouvez pas facilement modifier le système d’exploitation. Cela inclut le système de fichiers, les répertoires, les applications et même les configurations. Même en tant qu’administrateur, vous ne pouvez apporter aucune modification à la distribution.

Si quelque chose est modifié dans une distribution immuable, ce n’est que temporaire et revient au redémarrage. C’est pourquoi ces systèmes d’exploitation sont appelés « immuables ».

Mises à jour atomiques, ces distributions suivent une approche différente lors de la mise à jour du système d’exploitation. Au lieu de traiter les mises à jour par package, les mises à jour sont effectuées sur l’ensemble du système d’exploitation. En d’autres termes, l’ensemble du système d’exploitation est traité comme une seule unité indivisible. En cas d’échec lors de la mise à jour, le système revient à l’état précédent.

Un autre aspect intéressant est le processus de mise à niveau basé sur l’image. Lors de la mise à jour, le système crée une nouvelle image dans une partition distincte. Toutes les mises à jour ont lieu dans cette nouvelle image pendant que vous utilisez l’image existante. Au prochain démarrage, vous démarrerez dans la nouvelle image mise à jour au lieu de l’ancienne.

En vrai, si je suis de mauvaise foi, je dirai qu’une openSUSE classique avec Btrfs et flatpack ou encore Snap, rentre presque dans cette catégorie, effectivement le coté rollback est fait via le Btrfs, donc là dessus on est un peu juste. Mais le point qui m’agace c’est ce coté ChromeOS, on ne mets pas de pare-feu car c’est trop compliqué de faciliter la vie de l’utilisateur quand on y met de la sécurité. Et oui le code de sa carte bleu est pénible, on peut l’oublier, mais vaut mieux ce petit inconvénient que de ne pas en avoir du tout.

Je le dis rarement, je suis anti-redhat et encore plus depuis IBM, mais je dois aussi avouer que personnellement je suis plus rassuré d’avoir IBM derrière mon projet que le consortium plus ou moins inconnu que nous avons derrière SUSE. C’est surtout que Redhat ne fait pas à moitié pour la sécurité, alors que pour le coup, soit disant que c’est compliqué de faire simple quand on a un pare-feu, soit disant que puisque l’on est en conteneurisé, puisque l’on est en lecture seule, ect, nous avons pas besoin de pare-feu… Je l’espère mais pour moi ça sera next.

On aura compris que je n’aime pas le personnage, je n’aime pas jouer avec la sécurité, je n’aime pas l’instabilité du projet et de son entourage, je ne peux donc que déconseiller et dire d’aller voir ailleurs ou de rester sur une version plus classique d’openSUSE.

Commencer la discussion: Venez écrire un commentaire dans le forum.