Fedora Silverblue est une autre manière de gérer un OS qui est en phase avec les buts exprimés par Fedora.next.
Via rpm-ostree, Silverblue a un système de base immuable, c'est-à-dire que le système de fichier principal (les dossiers /, /usr, etc.) sont en lecture seule à l'exception de /etc et /var. Ce dernier sert notamment à héberger le point de montage de /home par ailleurs.
Le but est que l'image fournie par Silverblue soit minimale. Si tu veux des applications supplémentaires, tu dois recourir aux conteneurs ou aux Flatpaks. Ce qui améliore l'isolation des processus, la gestion des dépendances, les permissions qu'ils ont sur le système, cela simplifie leur déploiement, etc. Ainsi cela améliore grandement la fiabilité du système de base car il a qu'un minimum de choses à fournir.
Il peut donc évoluer plus facilement, et tu peux plus facilement mettre à jour (ou non) tes applications dans le temps, sans devoir suivre le calendrier de sortie des nouvelles versions de Fedora qui dans ce cas de figure ne mettrait à jour que le socle de base du système. Tu gagnes en indépendance de ce point de vue.
Et du coup comme le système est minimal, le but est que ce système fonctionne par états. En réalité quand tu mets à jour ou que tu installes un système actuellement, tout est dynamique, tu dis au système d'extraire des fichiers d'un paquet, de les copier à différents endroits du système et d'exécution de scripts qui permettent par exemple de convertir des fichiers de confs d'un format ancien à un autre, ou de créer un utilisateur système qui exécutera le service plus tard, etc.
Toutes ces procédures étant dynamiques, il faut anticiper pas mal de choses car ta Fedora 30 et ma Fedora 30 ne seront pas identiques, nous aurons chacun des applications différentes installées ou en fonctionnement. Cela est source de bogues difficiles à anticiper et à gérer.
Par ailleurs le problème du modèle traditionnel, c'est que la procédure de mise à jour est critique. Une coupure de courant au mauvais moment et tu peux avoir un système dysfonctionnel voire non fonctionnel.
Avec le mécanisme de rpm-ostree, comme l'image de base est minimale, en fait on télécharge un état complet du système. Et au redémarrage, on applique le changement de cet état. C'est comme effectuer un multiboot sur différents OS, sauf que cette fois ce multiboot concerne un système unique dans un état différent. Et en plus optimisé évidemment pour ne pas gaspiller inutilement des Gio en bande passante ou espace disque. L'état du système étant caractérisé par les applications installées dans le système même et leurs versions.
C'est pourquoi l'autre personne plus haut disait qu'en installant un paquet via rpm-ostree nécessitait de redémarrer la machine pour en tirer bénéfice. Mais l'avantage, c'est qu'en cas de coupure de courant durant l'installation, il n'y a pas de problèmes car l'état du système actuel est préservé.
Du coup, à partir de ce rapide exposé, qui j'espère est assez clair, on peut en déduire aussi les inconvénients de Silverblue et des problèmes à résoudre.
Le système est plus gros, car tu perds beaucoup dans la mutualisation des ressources comme les bibliothèques partagées entre les applications. C'est le problème d'utiliser les conteneurs, cela améliore l'isolation entre les applications au détriment du partage de données communes.
Le système est sans doute plus complexe à appréhender et surtout inhabituel, il faut former les gens à ce genre d'architectures. Que ce soit les utilisateurs, administrateurs systèmes ou les développeurs. Beaucoup d'applications, dont les proprio, ont besoin d'une adaptation pour fonctionner convenablement dans ce cas.
L'intégration des composants est plus délicate à fournir, car on délègue cette tâche aux conteneurs et aux utilisateurs pour les versions utilisées pour els différents logiciels.
Enfin, certains cas d'usage comme le développement, se prête moins bien à ce genre d'architecture. Devoir redémarrer sa machine car on a installé une bibliothèque pour coder sur son projet est pénible, surtout si on réalise qu'on en a oublié en route. Et les Flatpaks ne fournissent que des applications graphiques finales. C'est pourquoi il y a ce travail autour de Fedora toolbox, pour contourner le problème en fournissant un moyen simple d'utiliser les conteneurs applicatifs pour développer à l'ancienne tout en gardant son système de base immuable.
[^] # Re: Silverblue
Posté par Renault (site web personnel) . En réponse à la dépêche Apports de Fedora à l’écosystème du logiciel libre (2de partie). Évalué à 10.
Fedora Silverblue est une autre manière de gérer un OS qui est en phase avec les buts exprimés par Fedora.next.
Via rpm-ostree, Silverblue a un système de base immuable, c'est-à-dire que le système de fichier principal (les dossiers /, /usr, etc.) sont en lecture seule à l'exception de /etc et /var. Ce dernier sert notamment à héberger le point de montage de /home par ailleurs.
Le but est que l'image fournie par Silverblue soit minimale. Si tu veux des applications supplémentaires, tu dois recourir aux conteneurs ou aux Flatpaks. Ce qui améliore l'isolation des processus, la gestion des dépendances, les permissions qu'ils ont sur le système, cela simplifie leur déploiement, etc. Ainsi cela améliore grandement la fiabilité du système de base car il a qu'un minimum de choses à fournir.
Il peut donc évoluer plus facilement, et tu peux plus facilement mettre à jour (ou non) tes applications dans le temps, sans devoir suivre le calendrier de sortie des nouvelles versions de Fedora qui dans ce cas de figure ne mettrait à jour que le socle de base du système. Tu gagnes en indépendance de ce point de vue.
Et du coup comme le système est minimal, le but est que ce système fonctionne par états. En réalité quand tu mets à jour ou que tu installes un système actuellement, tout est dynamique, tu dis au système d'extraire des fichiers d'un paquet, de les copier à différents endroits du système et d'exécution de scripts qui permettent par exemple de convertir des fichiers de confs d'un format ancien à un autre, ou de créer un utilisateur système qui exécutera le service plus tard, etc.
Toutes ces procédures étant dynamiques, il faut anticiper pas mal de choses car ta Fedora 30 et ma Fedora 30 ne seront pas identiques, nous aurons chacun des applications différentes installées ou en fonctionnement. Cela est source de bogues difficiles à anticiper et à gérer.
Par ailleurs le problème du modèle traditionnel, c'est que la procédure de mise à jour est critique. Une coupure de courant au mauvais moment et tu peux avoir un système dysfonctionnel voire non fonctionnel.
Avec le mécanisme de rpm-ostree, comme l'image de base est minimale, en fait on télécharge un état complet du système. Et au redémarrage, on applique le changement de cet état. C'est comme effectuer un multiboot sur différents OS, sauf que cette fois ce multiboot concerne un système unique dans un état différent. Et en plus optimisé évidemment pour ne pas gaspiller inutilement des Gio en bande passante ou espace disque. L'état du système étant caractérisé par les applications installées dans le système même et leurs versions.
C'est pourquoi l'autre personne plus haut disait qu'en installant un paquet via rpm-ostree nécessitait de redémarrer la machine pour en tirer bénéfice. Mais l'avantage, c'est qu'en cas de coupure de courant durant l'installation, il n'y a pas de problèmes car l'état du système actuel est préservé.
Du coup, à partir de ce rapide exposé, qui j'espère est assez clair, on peut en déduire aussi les inconvénients de Silverblue et des problèmes à résoudre.
Le système est plus gros, car tu perds beaucoup dans la mutualisation des ressources comme les bibliothèques partagées entre les applications. C'est le problème d'utiliser les conteneurs, cela améliore l'isolation entre les applications au détriment du partage de données communes.
Le système est sans doute plus complexe à appréhender et surtout inhabituel, il faut former les gens à ce genre d'architectures. Que ce soit les utilisateurs, administrateurs systèmes ou les développeurs. Beaucoup d'applications, dont les proprio, ont besoin d'une adaptation pour fonctionner convenablement dans ce cas.
L'intégration des composants est plus délicate à fournir, car on délègue cette tâche aux conteneurs et aux utilisateurs pour les versions utilisées pour els différents logiciels.
Enfin, certains cas d'usage comme le développement, se prête moins bien à ce genre d'architecture. Devoir redémarrer sa machine car on a installé une bibliothèque pour coder sur son projet est pénible, surtout si on réalise qu'on en a oublié en route. Et les Flatpaks ne fournissent que des applications graphiques finales. C'est pourquoi il y a ce travail autour de Fedora toolbox, pour contourner le problème en fournissant un moyen simple d'utiliser les conteneurs applicatifs pour développer à l'ancienne tout en gardant son système de base immuable.