Fedora Silverblue en pratique

Posté par  (site Web personnel) . Édité par Davy Defaud, tankey, Benoît Sibaud, Xavier Claude, tisaac et palm123. Modéré par tankey. Licence CC By‑SA.
Étiquettes :
25
9
mai
2020
Fedora

Fedora Silverblue tente d’établir un système fonctionnel conciliant Fedora Workstation, la version bureautique de la distribution éponyme, et le projet Atomic. Cette déclinaison de Fedora commence à monter en puissance en termes de développements depuis quelque temps et nous réalisons que pour beaucoup de personnes extérieures ce projet reste très flou, tant dans ses objectifs que sur les implications techniques.

Nous avons présenté dans un article précédent l’historique et ce qui a motivé la conception de Fedora Silverblue. Ici, nous allons nous attarder plutôt à un cas d’usage en pratique pour voir la différence avec une Fedora classique.

Logo de Fedora Silverblue

Sommaire

Généralités

Beaucoup de choses restent identiques par rapport à une Fedora Workstation classique. Même bureau, même interface, logithèque ou fraîcheur des versions. La procédure d’installation avec Anaconda ne change pas vraiment non plus.

Si vous souhaitez tester, vous pouvez télécharger Fedora Silverblue directement ou par Torrent. Ensuite pour l’installer vous pouvez lire le début de cette page de documentation, cela fonctionne aussi bien sur Silverblue.

La différence, comme expliqué dans l’article précédent, réside dans la gestion de la logithèque. Et nous allons en étudier cela en pratique.

Base du système avec RPM ostree

Comme vous le savez, la base du système est un tout uni et dans l’ensemble en lecture seule. Mettre à jour le système signifie passer d’un état vers un autre sans autre altération.

Cela se passe avec la commande suivante :

# rpm-ostree upgrade

Mise à jour de Fedora Silverblue avec GNOME Logiciels

Une fois cela fait, il suffit de redémarrer et vous basculez vers le nouvel état du système, à jour. Notons que GNOME Logiciels permet de réaliser aussi la mise à jour de la base du système mais graphiquement.

On peut voir en effet qu’un nouvel état est installé sur votre machine via la commande :

$ rpm-ostree status
State: idle
AutomaticUpdates: disabled
Deployments:
● ostree://fedora:fedora/31/x86_64/silverblue
                   Version: 31.20200410.0 (2020-04-10T14:27:44Z)
                    Commit: 16f67d3577701f988cb6c32a6376700f24e720e0896b2f5f4a6b6ab65f030b31
              GPGSignature: Valid signature by 7D22D5867F2A4236474BF7B850CB390B3C3359C4
                      Diff: 524 upgraded, 24 downgraded, 13 removed, 18 added

● ostree://fedora:fedora/31/x86_64/silverblue
                   Version: 31.1.9 (2019-10-23T21:44:48Z)
                    Commit: c4bf7a6339e6be97d0ca48a117a1a35c9c5e3256ae2db9e706b0147c5845fac4
              GPGSignature: Valid signature by 7D22D5867F2A4236474BF7B850CB390B3C3359C4

Le système avec le symbole « ● » est la version courante du système, sur lequel j’ai démarré après l’installation de Fedora. On constate qu’après la mise à jour, un nouvel état est disponible avec sa date d’installation et la référence de la version employée.

Notez la ligne Diff pour cet autre état, il explique la différence entre l’état actuel et celui‑ci, qui consiste ici majoritairement en paquets plus récents.

Et, en effet, après redémarrage de la machine, le symbole a changé de place. La mise à jour a bien été effective et le redémarrage aussi rapide que d’habitude. La référence vers l’état précédent reste présente, ce qui nous autorise à revenir en cas de gros souci pour démarrer sur le nouvel état, ou si l’on a un problème qu’on a constaté nous‑mêmes.

Amusons‑nous à revenir, cela se fait simplement :

# rpm-ostree rollback

Et après un redémarrage, on a basculé vers l’état précédent. Simple, fiable et rapide. Notez qu’il est possible de choisir l’état au démarrage via GRUB. En cas d’installation mono‑système, le menu de GRUB est caché par défaut, appuyez sur la touche Échap au démarrage de GRUB pour l’afficher et faire votre choix.

Bien sûr, il est possible de configurer un peu ce système de base pour résoudre certains problèmes, même si cela viole un peu l’esprit derrière Silverblue. Par exemple, si nous voulons profiter du pilote propriétaire de NVIDIA, car le pilote libre nouveau ne fonctionne pas suffisamment bien sur notre machine. Nous pouvons faire les choses ainsi :

D’abord, il faut installer le dépôt externe RPMFusion, qui dispose du paquet RPM nécessaire. Un redémarrage est évidemment nécessaire pour changer d’état avec ce dépôt disponible :

# rpm-ostree install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-31.noarch.rpm  https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-31.noarch.rpm
# systemctl reboot

Ensuite, on peut installer le paquet nécessaire et changer l’argument de démarrage du noyau pour désactiver le recours au pilote nouveau. Un redémarrage sera encore nécessaire pour valider l’action :

# rpm-ostree install akmod-nvidia xorg-x11-drv-nvidia-cuda libva-utils libva-vdpau-driver gstreamer1-libav
# rpm-ostree kargs --append=modprobe.blacklist=nouveau --append=rd.driver.blacklist=nouveau
# systemctl reboot

rpm-ostree se charge de tout pour altérer l’état du système de base.

Comme vous pouvez le voir, il reste possible d’installer des paquets RPM à l’ancienne, bien que dans le cas de Silverblue, cela reste déconseillé en dehors de quelques cas comme celui évoqué plus haut. Cela se fait dans une couche indépendante du système de base et sera déployé au‑dessus de votre version de référence après chaque mise à jour de ce dernier.

Notez que pour certaines applications, le fait que le système principal soit en lecture seule, peut poser des soucis de compatibilité.

Et si jamais vous souhaitez revenir dans l’état de base de votre système, vous pouvez utiliser simplement cette commande :

# rpm-ostree reset

Et comme Silverblue fonctionne par état pour les mises à jour, ce que l’on a vu plus haut, changer de branche de Fedora est également possible facilement.

Menu GRUB avec les états d’OSTree

D’abord listez les versions possibles et enfin déployez cette version :

# ostree remote refs fedora
# rpm-ostree rebase fedora:fedora/32/x86_64/silverblue

Redémarrez et mission accomplie, vous voilà sous Fedora 32. Cela fonctionne également dans l’autre sens, pour revenir sur Fedora 31 si vous êtes sur la version 32.

Fedora Toolbox

Comme cela a été expliqué dans l’autre article, Fedora Toolbox est une surcouche à podman et buildah. Son but est de facilement créer un conteneur avec une version de Fedora comme base. Il se charge lui‑même de récupérer les données, de faire en sorte que l’utilisateur soit le même que sur l’hôte, etc. Par ailleurs, le répertoire /home est partagé entre l’hôte et les conteneurs, ce qui autorise d’exploiter les outils sur vos données.

podman est pour rappel un utilitaire compatible avec Docker mais qui ne nécessite pas un démon avec les droits super‐utilisateur pour fonctionner. Pour des raisons de sécurité.

Créer un conteneur est très simple :

$ toolbox create

Qui va en créer un avec un nom par défaut et la même version de Fedora que votre instance de Silverblue. Ici fedora-toolbox-31.

Mais on peut, bien entendu, personnaliser tout ça ainsi :

$ toolbox create --container <nom> --release <version>
$ toolbox create --container fedora30 --release f30

Ensuite, on peut utiliser une session de shell pour entrer dans le conteneur de votre choix :

$ toolbox enter --container <nom>

Vous constaterez que le prompt se dote d’un « ⬢ » coloré au début, pour vous rappeler que vous êtes dans un conteneur.

Notez le symbole dans le prompt qui signifie que nous sommes dans un conteneur

Une fois à l’intérieur, vous pouvez faire ce que vous voulez. Utilisez dnf pour installer des paquets, les mettre à jour comme avant, configurer votre système, etc. Lancer des applications depuis un tel conteneur est aussi possible.

D’ailleurs, pour exécuter une commande dans un conteneur sans y obtenir un shell, vous pouvez faire :

$ toolbox run --container <name> <commande>
$ toolbox run --container fedora30 gnome-builder

Pour vous y retrouver si vous avez plusieurs conteneurs, vous pouvez les lister ainsi :

$ toolbox list
Images created by toolbox
IMAGE ID      IMAGE NAME                                        CREATED
64e68e194389  registry.fedoraproject.org/f31/fedora-toolbox:31  6 weeks ago

Containers created by toolbox
CONTAINER ID  CONTAINER NAME     CREATED            STATUS                IMAGE NAME
dc75753d59a2  fedora-toolbox-31  2 hours ago        Up 2 hours ago        registry.fedoraproject.org/f31/fedora-toolbox:31
1a9eaf6067c9  fedora30           About an hour ago  Up About an hour ago  registry.fedoraproject.org/f31/fedora-toolbox:31

Et si un conteneur n’est plus utile, vous pouvez le supprimer ainsi :

$ toolbox rm <name>
$ toolbox rm silverblue

L’objectif de Toolbox est de vous simplifier la vie dans la configuration du conteneur pour cet usage, surtout si vous n’êtes pas habitués à cet écosystème. Mais rien ne vous empêche d’utiliser podman ou Docker manuellement. Les commandes podman peuvent être exploitées à la place de Toolbox, par exemple sur les conteneurs créés par ce dernier.

Flatpak

Par défaut, il n’y a pas beaucoup de paquets Flatpak disponibles dans Silverblue (mais c’est en cours de résolution). La première étape étant d’en installer un dépôt externe comme Flathub. C’est très simple et rapide.

GNOME Logiciels gère les Flatpak et indique sa provenance

Globalement, cela consiste à exécuter cette commande :

$ flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

Ensuite, vous pouvez utiliser GNOME Logiciels pour télécharger et mettre à jour ces applications.

Ou alors à la main comme suit :

$ flatpak update
$ flatpak list
Name                                              Application ID                                Version          Branch          Origin           Installation
Platform                                          org.fedoraproject.Platform                                     f32             fedora           system
default                                           org.freedesktop.Platform.GL.default                            19.08           flathub          system
openh264                                          org.freedesktop.Platform.openh264                              2.0             flathub          system
Geary                                             org.gnome.Geary                               3.36.1           stable          fedora           system
Lollypop                                          org.gnome.Lollypop                            1.2.33           stable          flathub          system
GNOME Application Platform version 3.36           org.gnome.Platform                                             3.36            flathub          system

Comme vous pouvez le voir, Geary et Lollypop ont été installés par Flatpak, l’un via Flathub, l’autre via Fedora Registry, qui propose ses propres Flatpak aussi exploitables dans un conteneur podman ou Docker. Les environnements d’exécution nécessaires pour ces applications ont aussi été installés et sont listés ici comme GNOME Application Platform.

Il suffit donc de chercher si un tel paquet existe puis l’installer. Prenons GNOME Agenda comme exemple :

$ flatpak search calendar
Name         Description                  Application ID                Version         Branch  Remotes
Agenda       Agenda de GNOME              org.gnome.Calendar            3.36.0          stable  fedora,flathub
$ flatpak install org.gnome.Calendar

Comme l’application existe dans Flathub et Fedora, Flatpak vous demandera la source à utiliser ici.
Par défaut, un Flatpak est installé dans /var/lib pour être accessible pour l’ensemble des utilisateurs. Mais si pour une raison particulière vous souhaitez que seul votre utilisateur ait accès, vous pouvez ajouter l’argument --user :

$ flatpak install --user org.gnome.Calendar

L’un des avantages de Flatpak est qu’il repose aussi sur des états. Si une mise à jour ne vous plaît pas, car elle introduit une régression gênante pour vous, vous pouvez facilement revenir à l’état précédent. D’abord, il faut identifier la liste des états disponibles de votre application.

$ flatpak remote-info --log flathub org.gnome.Geary

Ensuite, choisir un état et l’appliquer.

$ flatpak update --commit bba3bbb1ab3b127de0fd984279d99170f9ec671b05c18cc64a0c102243664a1c org.gnome.Geary

GNOME Shell permet de les lancer comme une application native, évidemment, mais depuis le terminal, c’est possible ainsi :

$ flatpak run <application id>
$ flatpak run org.gnome.Geary

Peu à peu les Flatpak disposent d’un système de permissions et de portails pour permettre l’accès aux ressources dont les applications ont besoin uniquement.

Notons aussi que GNOME Logiciels peut présenter les choses de manière un peu trompeuse. Par exemple, installer Lollypop, qui était le premier Flatpak, nécessitait de télécharger près de 1 Gio de données pour 40 Mio installés. En fait, le gigaoctet de données était lié aux environnements d’exécution nécessaires à télécharger. Mais Geary, qui utilise les mêmes environnements d’exécution n’a eu besoin que de quelques mégaoctets seulement pour être installé par après. Comme Silverblue repose énormément sur les Flatpak, vos environnements d’exécution seront rentabilisés car partagés par beaucoup d’applications.

Si vous souhaitez voir les changements opérés sur les Flatpak comme les installations et mises à jour, une commande est possible :

$ flatpak history
Time              Change         Application                         Branch Installation        Remote
avril 11 18:00:17 add remote                                                system              flathub
avril 11 18:06:07 deploy install org.fedoraproject.Platform          f32    system              fedora
avril 11 18:06:12 deploy install org.gnome.Geary                     stable system              fedora

Mode de travail avec Silverblue

Avant nous avions un système unifié avec des dépôts centralisés pour tout, et il n’y avait pas beaucoup de possibilités pour installer des applications ou maintenir le système. Silverblue introduit en plus une certaine redondance par endroit. Comment s’y retrouver ?

La base du système est globalement en lecture seule et minimaliste. À part le mettre à jour, il n’y a pas grand‑chose à faire en temps normal. Y toucher peut devenir essentiel pour ce qui a trait à la gestion du matériel, comme le chargeur de démarrage GRUB ou le noyau et ses pilotes. En dehors de cela, il n’est pas recommandé d’essayer de le manipuler. L’objectif est qu’il soit minimal, simple et fiable. Le reste repose sur les conteneurs et Flatpak.

Les Flatpak seront à privilégier pour les applications graphiques. Après tout, seules ces applications peuvent être installées par ce biais.

Pour le reste, il y a les conteneurs avec Fedora Toolbox. Utile pour les applications textes, environnements de développement, etc. Le fait d’avoir plusieurs conteneurs permet de séparer les tâches. Le développement Python d’un côté, le serveur Web de l’autre, l’expérimentation d’un projet, un environnement pour le travail professionnel, etc. À vous de voir selon vos envies et besoins. S’il reste possible d’avoir un conteneur fourre‑tout pour simuler une Fedora classique, cette approche n’est pas réellement dans l’esprit de Silverblue.

Le gain ?

Une partie des gains a été largement relatée dans l’article précédent. Mais avec un peu de pratique, que pouvons‑nous observer ?

Tout d’abord, la séparation du système en plusieurs parties permet de leur donner une responsabilité propre, ce qui améliore dans un sens sa fiabilité mais aussi son élégance. Le système de base se charge de fournir un système qui démarre et qui est exploitable. Il est beaucoup plus difficile d’aboutir à une situation complexe inextricable avec une machine peu fonctionnelle.

La flexibilité est plus grande, via Fedora Toolbox et Flatpak, il est plus facile d’expérimenter des choses et d’adapter votre système à vos besoins. Vous souhaitez tirer profit d’une version de Python qui est dans Fedora 32 et dans Fedora 29 pour vos tests ? Vous pouvez avoir les deux facilement avec Fedora Toolbox en ayant un conteneur pour chaque.

Et si vous avez fini un projet professionnel et que vous n’avez plus besoin de ces conteneurs spécialisés de Python avec les versions spécifiques, il suffit de les supprimer. Plus besoin de chercher les paquets qui étaient nécessaires pour cette tâche et dont vous n’avez plus besoin pour toiletter le système.

Vous souhaitez une version de Firefox très récente mais une de LibreOffice plus ancienne ? Flatpak permet de concilier les deux facilement comme nous l’avons vu.

Et chaque application n’aura accès qu’aux données et ressources pour lesquelles elle dispose de votre autorisation, limitant les problèmes dus à des bogues ou des failles.

Mais, bien sûr, cela a un coût. Besoin de plus de bande passante, de mémoire, de temps processeur et d’espace disque. Le système dans son ensemble est aussi plus complexe à appréhender, de nouvelles choses sont à apprendre.

Aller plus loin

  • # Fedora Toolbox

    Posté par  (site Web personnel) . Évalué à 6 (+3/-0).

    Merci pour cette nouvelle dépêche

    Je suis un peu perplexe avec cette histoire de Fedora Toolbox.
    Si je comprends bien il y a trois grammaires à apprendre pour installer ou mettre à jour le système : rpm-ostree, Fedora Toolbox, Flatpak.
    Bon, c'est peut être pas plus simple à l'arrivée du coup ?
    Est-ce que finalement il n'aurait pas été plus simple de faire prendre en charge les applis non graphiques par Flatpak ?!
    Cette décision de limiter Flatpak à des applis graphiques m'échappe.
    Je prends l'exemple de youtube-dl : impossible de l'installer en Flatpak. Pourtant il est présent dans des Flatpak d'applications graphiques qui reposent dessus.
    Et là, il est théoriquement possible de l'utiliser
    https://github.com/nedrichards/youtube-dl-flatpak/issues/2#issuecomment-600657528
    Du coup, pourquoi ne pas le proposer dès le départ ?!
    De mon point de vue d'utilisateur, cela ressemble à une complication gratuite

    • [^] # Re: Fedora Toolbox

      Posté par  (site Web personnel) . Évalué à 4 (+1/-0).

      Si je comprends bien il y a trois grammaires à apprendre pour installer ou mettre à jour le système : rpm-ostree, Fedora Toolbox, Flatpak.

      Oui. Du moins en théorie.
      Pour un usage bureautique pur, il te suffit de savoir manipuler un outil comme GNOME Logiciels qui gère tout ça pour toi. Car Fedora toolbox ne sert pas dans ce contexte et rpm-ostree ne serait que pour des mise à jour.

      rpm-ostree, il faut bien comprendre que le but de cette partie du système est d'être vraiment minimal. Une fois que ton système est installé, à part les MaJ et problèmes particuliers, tu ne devrais pas y toucher. Donc à la limite sa maitrise n'est pas requise. Toolbox ou Flatpak par contre un peu plus oui.

      Bon, c'est peut être pas plus simple à l'arrivée du coup ?

      Qui a dit que cela devait être plus simple ? :)
      Je dirais que tout dépend du profil d'utilisateur et de son but, dans certains cas je vois un apport important de Silverblue, parfois non.

      Par exemple prenons le cas d'un utilisateur lambda, ni développeur, ni utilisateur avancé. Par exemple un travailleur de bureau qui n'est pas informaticien.

      Il installe des paquets avec Flatpak, mets à jour le système quand on lui demande. Il accepte ou refuse des permissions et basta. Il profite de la flexibilité des Flatpak.

      Pour le système de base, il s'en fout, il ne le gère pas. Par contre ce système est plus robuste donc moins probable qu'il y ait besoin d'une maintenance. Et s'il faut remettre à 0 le système pour X ou Y raisons, c'est assez facile à faire (genre donner la machine à un autre collègue ou lors d'une revente). Avec une distro classique c'est bien plus chiant comme opération.

      Est-ce que finalement il n'aurait pas été plus simple de faire prendre en charge les applis non graphiques par Flatpak ?!

      Pas sûr, disons que peut être qu'il y aurait moyen mais je vois un argument pour ne pas le faire du moins pour l'instant. Mais comme je ne connais pas la raison, elle est peut être fausse.

      Un Flatpak est isolé, et son intérêt est de pouvoir autoriser des actions à la volée pour sortir du bac à sable. La capture d'écran faite maintenant, ton application peut y accéder ou pas ? La caméra, elle peut y accéder maintenant ?

      Avec une interface graphique c'est facile de gérer le cas, une pop up ou une notification et tu peux facilement avoir la requête et son traitement par l'utilisateur. Tu fais ça comment avec une CLI ?

      La CLI par essence impose que les droits dans ce cas soient permanents et peut être que cela est un problème.

      Mais si quelqu'un a une source à ce sujet, je suis preneur.

      • [^] # Re: Fedora Toolbox

        Posté par  . Évalué à 2 (+0/-0).

        J'espère que tu ne va pas me trouver trop relou :)

        Il pourrait y avoir des notifications aux outils en cli. Si tu veux les utiliser dans des scripts automatisés libre à toi d'avoir valider leurs autorisations avant.

        Mais surtout c'est quoi un outil cli par rapport à un outil graphique ? network-manager est dans une sandbox, mais pas nm-cli ? Il y a un paquet d'outils comme ça, c'est bizarre de considérer que ça doit s'installer différemment et avoir des droits différents alors qu'ils font la même chose voir qu'ils collaborent.

        • [^] # Re: Fedora Toolbox

          Posté par  . Évalué à 2 (+2/-0).

          Comment faire des notifs en CLI? Quand tu es dans un terminal dans ton environnement de bureau, c'est jouable, mais si tu n'as pas d'environnement graphique? Genre Serveur, ou tout simplement TTY, ça se passe comment?

          • [^] # Re: Fedora Toolbox

            Posté par  . Évalué à 3 (+1/-0).

            Il y a pleins d'options :

            • tu peux accepter le fait que ça ne marche pas, à toi d'avoir préconfiguré tes droits avant si tu utilise en TTY ;
            • tu peux avoir un mode statique, les droits sont attribué à l'installation ;
            • tu peux regarder ce que font les LSM qui ont des modes, comme selinux.

            Il ne s’agit pas d'une impossibilité technique, mais d'un choix. Ça peut probablement se justifier (complexité, une volonté de définir le bureau linux sans CLI,…).

  • # Système en lecture seule ? Mais pourquoi ?

    Posté par  . Évalué à 1 (+1/-0).

    Pour le coup, l'idée de proposer un os en lecture seule me semble contre productif. On a toujours besoin de modifier des configs système…
    Par exemple, modifier vconsole.conf pour passer les tty en bépo. Ajouter un montage automatique dans fstab (ou par Gnome Disks qui modifue fstab), etc.

  • # Et donc concrètement?

    Posté par  . Évalué à 2 (+2/-0).

    Quels sont les besoins du projet SilverBlue en particulier? Je suis utilisateur Fedora, et ça fait un moment que j'envisage de passer sous cette variante. Tes 2 articles m'ont décidé (au passage, merci pour leur rédaction), mais si je veux aller plus loin?

    Ça fait un moment que je souhaite participer à Fedora, donc si je me lance dans l'aventure, pourquoi pas avec SilverBlue. Dans ce cas, où sont les besoins au delà des simples retours?

    • [^] # Re: Et donc concrètement?

      Posté par  (site Web personnel) . Évalué à 4 (+1/-0).

      Je ne sais pas. :)

      Je dirais tester, relever les problèmes et contribuer pour les résoudre. Donc savoir développer / empaqueter c'est nécessaire pour faire avancer le sujet.

      Rejoins la liste de diffusion liée à Silverblue.

  • # KDE

    Posté par  . Évalué à 2 (+2/-0).

    Je vois que Silverblue propose Gnome. Est-ce que KDE est maintenant supporté ? Sinon, quels moyens pour l'installer ? Je crois que ça n'est pas (encore) possible. Dommage, c'est ce qui me freine à essayer Silverblue. Sinon le principe me semble top.

    • [^] # Re: KDE

      Posté par  (site Web personnel) . Évalué à 4 (+1/-0).

      En théorie c'est possible si tu ajoutes le bureau KDE à minima comme overlay via rpm-ostree.

      Mais je n'ai pas testé, je ne vois pas de raisons pour laquelle cela ne fonctionnerait pas. Après idéalement ce serait pris en charge via les Spins quand Silverblue sera suffisamment mature.

      • [^] # Re: KDE

        Posté par  . Évalué à 2 (+2/-0).

        Il semble que ce ne soit pas officiellement supporté, mais qu'il existe bien un moyen (intitulé joliment Kinoite) d'utiliser KDE avec Silverblue (et XFCE).

  • # Installation

    Posté par  . Évalué à 2 (+1/-0).

    Bonjour,

    Je note que pendant l'installation, il faut laisser le partitionnement en mode automatique. Si on s'amuse à tenter un partitionnement manuel, l'installation de GRUB crash.

    Cependant ce n'est pas très grave, par défaut l'installeur créé un volume LVM, donc rien n'empêche après l'installation de le redécouper.

  • # Ma propre conclusion

    Posté par  . Évalué à 5 (+3/-0).

    J'avais essayé silverblue en version 31.

    Au final ma conclusion c'était que le flathub est encore tellement pauvre qu'au final on finis par utiliser rpm-ostree un peut trop souvent pour que ça en vaille le coup.

    J'en étais arrivé à la conclusion qu'utiliser une Fedora normale était finalement pas si mal, d'autant que flatpak, podman et toolbox y sont aussi dispos et que je pouvais toujours lui greffer nix si j'avais vraiment envie de faire une ségrégation système/applications utilisateur.

    Le seule avantage réel que je voyais à silverblue c'est que l'update est plus rapide que de mettre à jour chaque package individuellement.

  • # Isolation à configurer sur les flatpaks

    Posté par  (site Web personnel) . Évalué à 0 (+0/-0). Dernière modification le 13/05/20 à 11:10.

    J'utilise FSB depuis un moment, et on va migrer au boulot notre équipe dessus. Il nous reste pour l'instant un défaut qu'on a pas eu le temps de creuser, qui concerne les flatpak en général. Souvent à cause de leur isolation, et de leur configuration, soit on a pas accès à nos fichiers (ex riot), soit ça rend difficile l'ajout de plugins, de commandes etc (ex vscode), soit ça bloque l'accès à des périphériques (par ex impossible d'imprimer depuis libreoffice). Y'a moyen de reconfigurer ces paramètres d'isolation sur un flatpak ?

    Enfin, il y a souvent le problème des themes et icones qui ne sont pas toujours pas partagés avec le système, et les flatpaks.

  • # Outil de dev dans flatpak (ou pas) et toolbox, cohabitation compliquée

    Posté par  . Évalué à 0 (+0/-0).

    Que ce soit avec Vim, nvim ou VScode, il est un peu compliqué d'utiliser pleinement ces outils alors que les langages de développement sont dans un container.

    L'ensemble des plugins et assistants utilisés dans les IDE ont besoin d'avoir sous la main les langages en question.
    On se retrouve donc à installer java/go/rust/python/… dans le container pour ne pas polluer notre rpm-ostree et lorsque l'on installe le plugin qui va bien dans mon IDE il nous annonce fièrement qu'il lui faut java/go/rust/python/… pour pouvoir fonctionner.
    L'usage de flatpak s'en trouve du coup un peu réduit. Même chose si l'outil est installé avec rpm-ostree.

    Pour vim, ce n'est pas encore trop gênant lorsque le container est un toolbox, ça l'est déjà plus lorsque c'est un container spécialisé pour le langage, sans trop de possibilité d'ajouter vim à chaque mise à jour.

    Idem pour VScode, il faut oublier les plugins, ou alors il faut l'installer dans le toolbox. Il existe des astuces pour lancer des outils graphique dans le container, mais ce n'est pas super pratique.

    Est-ce que quelqu'un a trouvé une meilleure solution?

    • [^] # Re: Outil de dev dans flatpak (ou pas) et toolbox, cohabitation compliquée

      Posté par  (site Web personnel) . Évalué à 3 (+0/-0).

      Idem pour VScode, il faut oublier les plugins, ou alors il faut l'installer dans le toolbox. Il existe des astuces pour lancer des outils graphique dans le container, mais ce n'est pas super pratique.

      Personnellement je peux lancer gnome-builder dans un conteneur comme si c'était installé via un Flatpak. Ce qui permet de répondre à la question : il doit être dans un conteneur et ça devrait fonctionner.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.