1 points par GN⁺ 2024-01-01 | 1 commentaires | Partager sur WhatsApp
  • Bazzite est une image personnalisée basée sur Fedora Atomic, qui vise à offrir un environnement de jeu Linux allant des appareils portables comme le Steam Deck aux ordinateurs de bureau et aux HTPC
  • Le projet a été lancé pour résoudre les problèmes de SteamOS liés aux paquets obsolètes et à l’absence d’un gestionnaire de paquets fonctionnel ; bien qu’il soit basé sur des images, il permet d’installer des paquets Fedora, qui sont conservés après les mises à jour
  • Plusieurs variantes sont proposées, dont bazzite, bazzite-deck, des variantes GNOME et des images avec pilotes NVIDIA propriétaires, avec prise en charge du Game mode, du HDR, de Mesa, du portage de paquets SteamOS, du rollback et du Secure Boot
  • La configuration par défaut inclut la prise en charge de Distrobox, Waydroid, vkBasalt, MangoHud, OBS VkCapture, xone, DisplayLink, ROCM OpenCL/HIP, ainsi que de divers pilotes d’entrée, RGB et tablette
  • Des ISO d’installation et des commandes de rebase sont fournies ; les images prennent en charge la vérification des signatures cosign, et les utilisateurs peuvent créer leurs propres variantes de Bazzite avec GitHub Actions et des clés Cosign

Objectif et base de Bazzite

  • Bazzite est une image personnalisée basée sur Fedora Atomic, construite selon l’approche cloud-native de Universal Blue
  • Son objectif est d’étendre l’environnement de jeu Linux aux ordinateurs de bureau, aux HTPC de salon et aux appareils portables comme le Steam Deck
  • Bazzite est construit à partir de ublue-os/main et utilise les technologies Fedora pour fournir une prise en charge matérielle étendue et des pilotes intégrés
  • Le projet a été lancé pour résoudre les problèmes de paquets obsolètes et d’absence de gestionnaire de paquets fonctionnel dans SteamOS
  • Bien qu’il soit basé sur des images, il est possible d’installer des paquets Fedora en ligne de commande, et les paquets installés sont conservés après les mises à jour
  • Il est mis à jour plusieurs fois par semaine avec les paquets Fedora upstream, et prend en charge le noyau Linux récent, SELinux activé par défaut, Secure Boot et le chiffrement du disque

Fonctions communes de jeu et de matériel

  • Bazzite utilise le bazzite kernel pour fournir le HDR et une prise en charge matérielle étendue, avec plusieurs correctifs inclus
  • Le HDR est disponible en Game mode
  • NVK peut être utilisé dans les builds non NVIDIA
  • La prise en charge des codecs avec accélération matérielle pour le décodage H264 est fournie
  • Le runtime ROCM OpenCL/HIP d’AMD est pris en charge
  • Le pilote xone pour les manettes Xbox et DisplayLink sont pris en charge
  • Le thème KDE SteamOS de Valve est inclus
  • vkBasalt, MangoHud et OBS VkCapture sont installés par défaut
  • Winesync/Fastsync/NTsync sont pris en charge
  • Distrobox est préinstallé
  • L’installation de Davinci Resolve basée sur davincibox est simplifiée via ujust install-resolve
  • Un service automatique duperemove est fourni afin de réduire l’espace disque utilisé par le contenu des préfixes wine
  • HDMI CEC est pris en charge via libCEC
  • Google BBR est utilisé comme contrôle de congestion TCP par défaut
  • Input Remapper est préinstallé et activé ; il est disponible dans les variantes Deck, mais désactivé par défaut
  • Bazzite Portal permet d’installer des applications et des ajustements, et fournit des boutons pour mettre à jour, rebaser et réinitialiser l’image système
  • Waydroid est préinstallé pour permettre l’exécution d’applications Android
  • Flatseal, Warehouse et Gear Lever sont utilisés pour gérer Flatpak et AppImage
  • Les pilotes i2c-piix4 et i2c-nct6775 d’OpenRGB sont inclus pour contrôler le RGB de certaines cartes mères
  • Les pilotes OpenRazer sont intégrés et peuvent être utilisés via Bazzite Portal ou ujust install-openrazer
  • Les règles udev d’OpenTabletDriver sont intégrées, et l’ensemble logiciel complet peut être installé via Bazzite Portal ou ujust install-opentabletdriver
  • Les claviers Wooting sont pris en charge par défaut
  • Les GPU AMD Southern Islands HD 7000 et Sea Islands HD 8000 sont pris en charge avec le pilote amdgpu
  • Webapp Manager permet de transformer des sites web de plusieurs navigateurs, dont Firefox, en applications

Variantes pour ordinateur de bureau, Steam Deck et HTPC

  • La variante commune pour ordinateur de bureau est bazzite, adaptée aux ordinateurs de bureau
  • Les mises à jour automatiques de l’OS, des Flatpak et autres sont assurées par uupd et topgrade
  • Les ISO sont disponibles sur le site de téléchargement, et un guide d’installation est fourni
  • Il est possible de rebaser une installation Fedora Atomic existante vers une image avec pilotes GPU open source
rpm-ostree rebase ostree-unverified-registry:ghcr.io/ublue-os/bazzite:stable
  • Les appareils nécessitant des pilotes NVIDIA propriétaires doivent être rebasés vers l’image bazzite-nvidia
rpm-ostree rebase ostree-unverified-registry:ghcr.io/ublue-os/bazzite-nvidia:stable
  • Les utilisateurs ayant Secure Boot activé doivent suivre la documentation Secure Boot avant le rebase
  • NVK, l’option open source de Mesa pour NVIDIA, est sujette aux erreurs au moment de la rédaction ; les problèmes liés à NVK doivent être signalés à Mesa, et non à Ublue/Bazzite
  • bazzite-deck pour Steam Deck et HTPC

    • bazzite-deck est conçu comme alternative à SteamOS sur Steam Deck et pour offrir une expérience de type console sur HTPC
    • Comme SteamOS, il démarre directement en Game mode
    • Le duperemove automatique réduit fortement la taille de compatdata
    • La version récente de Mesa produit un shader cache plus petit et n’exige pas de shader cache pour éviter les saccades
    • Le système peut démarrer même si le disque est plein
    • Toutes les langues prises en charge par Fedora upstream sont supportées
    • Wayland est utilisé sur le bureau, avec prise en charge de Steam input
    • Il inclut des versions portées de la plupart des paquets SteamOS, dont les pilotes, l’outil de mise à jour du firmware et le contrôleur de ventilateur du dépôt evlaV
    • Une version patchée de Mesa est utilisée pour un contrôle correct du framerate dans Gamescope
    • La prise en charge de BTRFS sur carte SD est fournie par défaut, avec les correctifs SteamOS BTRFS
    • Un portage de SDGyroDSU est fourni et activé par défaut
    • À l’installation, Decky Loader, EmuDeck, RetroDECK, ProtonUp-Qt et d’autres peuvent être installés en option
    • Un système de mise à jour personnalisé permet de mettre à jour l’OS, les Flatpak et autres depuis l’interface du Game mode
    • Le dual boot avec Windows est pris en charge en conservant l’installation GRUB de Fedora
    • La fonction de rollback de rpm-ostree permet de revenir à une version précédente de Bazzite, et de sélectionner une image précédente au démarrage
    • Steam et Lutris sont préinstallés dans l’image sous forme de layered packages
    • Par défaut, 4 Go de ZRAM utilisant l’algorithme de compression LZ4 sont utilisés
    • Les ordonnanceurs CPU LAVD et BORE sont inclus pour un gameplay fluide et réactif
    • L’ordonnanceur d’E/S Kyber est utilisé pour éviter l’I/O starvation pendant l’installation de jeux ou l’exécution de duperemove en arrière-plan
    • Les paramètres de noyau de SteamOS sont appliqués
    • Des profils d’affichage avec calibration des couleurs pour les écrans Steam Deck mats et brillants sont inclus
    • Les fonctions pour power users, comme l’undervolting à faible risque du Steam Deck, l’overclocking de l’écran ou le doublement maximal de la VRAM après une modification à 32 Go de RAM, sont fournies mais désactivées par défaut
    • Les services de mise à jour du BIOS et du firmware propres au matériel Steam Deck peuvent être désactivés dans le terminal avec ujust disable-bios-updates et ujust disable-firmware-updates
    • Ces services sont automatiquement désactivés sur le matériel non Deck, ainsi que sur les Deck avec écran DeckHD ou modification à 32 Go de RAM
    • Pour configurer Steam Gaming Mode sur d’autres appareils portables, il faut consulter le Handheld Wiki

Variantes GNOME et fonctions upstream

  • Les builds avec l’environnement de bureau GNOME sont disponibles pour les variantes de bureau comme pour les variantes Deck
  • Les builds GNOME activent le taux de rafraîchissement variable et le fractional scaling sous Wayland
  • Un menu personnalisé dans la barre supérieure permet de revenir au Game mode, de lancer Steam et d’exécuter plusieurs utilitaires
  • GSConnect est préinstallé et prêt à l’emploi
  • L’extension Hanabi est incluse pour offrir une fonctionnalité similaire à Wallpaper Engine de KDE
  • Plusieurs extensions GNOME optionnelles sont préinstallées, avec des modifications de l’expérience utilisateur
  • Les thèmes GNOME de Firefox et Thunderbird sont mis à jour automatiquement s’ils sont installés
  • La commande de rebase pour la variante de bureau GNOME est la suivante
rpm-ostree rebase ostree-unverified-registry:ghcr.io/ublue-os/bazzite-gnome:stable
  • L’image GNOME avec pilotes NVIDIA propriétaires se rebase avec la commande suivante
rpm-ostree rebase ostree-unverified-registry:ghcr.io/ublue-os/bazzite-gnome-nvidia:stable
  • La version GNOME pour Steam Deck/HTPC utilise la commande suivante
rpm-ostree rebase ostree-unverified-registry:ghcr.io/ublue-os/bazzite-deck-gnome:stable
  • Fonctions issues d’Universal Blue et de Fedora

    • Fonctions basées sur Universal Blue
    • Les images NVIDIA ont les pilotes NVIDIA propriétaires préinstallés
    • Flathub est activé par défaut
    • La commande pratique ujust est fournie
    • Les codecs multimédias sont inclus par défaut
    • Bazzite peut être restauré vers n’importe quel build des 90 derniers jours
    • Fonctions basées sur Fedora Linux Kinoite et Silverblue
    • Une base stable est fournie
    • Les paquets système restent relativement à jour
    • Les paquets Fedora peuvent être ajoutés à l’image sous forme de layer et sont conservés après les mises à jour
    • SELinux est préinstallé et configuré
    • Il est possible de rebaser vers une autre image Fedora Atomic sans perdre les données utilisateur
    • CUPS est préinstallé pour prendre en charge l’impression

Vérification, Secure Boot et builds personnalisés

  • Les images Bazzite sont signées avec cosign de sigstore
  • Il est possible de télécharger la clé cosign.pub du dépôt et de vérifier la signature avec la commande suivante
cosign verify --key cosign.pub ghcr.io/ublue-os/bazzite
  • Secure Boot est pris en charge avec une clé personnalisée, et la clé publique se trouve dans secure_boot.der à la racine du dépôt
  • Pour enregistrer la clé Secure Boot avant l’installation ou le rebase, utilisez les commandes suivantes
sudo mokutil --timeout -1
sudo mokutil --import secure_boot.der
  • Si vous utilisez déjà une image Universal Blue, vous pouvez exécuter ujust enroll-secure-boot-key à la place
  • Si un mot de passe est demandé, utilisez universalblue
  • Le Steam Deck n’est pas fourni avec Secure Boot activé et ne possède pas non plus de clé enregistrée par défaut ; il ne faut donc pas l’activer sans bien comprendre ce que cela implique
  • Bazzite est entièrement construit avec GitHub Actions
  • Pour créer une version personnalisée, il est possible de forker le dépôt, d’ajouter une clé de signature personnelle, puis d’activer GitHub Actions dans le fork
  • L’exécution du workflow Build Bazzite crée des images personnalisées pour toutes les variantes de Bazzite
  • Pour ne construire que les variantes nécessaires, commentez les variantes non souhaitées dans la liste strategy.matrix de la tâche push-ghcr dans .github/workflows/build.yml
  • Pour synchroniser le fork avec l’upstream, il est possible d’utiliser la configuration de pull app
  • Procédure de signature de sa propre image

    • Il faut d’abord consulter le mode de gestion des secrets de GitHub
    • Générez une nouvelle paire de clés avec Cosign
    cosign generate-key-pair
    
    • Remplacez le cosign.pub du dépôt public par la clé publique générée
    • Ajoutez le texte de la clé privée contenu dans cosign.key aux Repository Secrets du fork
    • Le nom du secret doit être SIGNING_SECRET

Documentation et communauté

1 commentaires

 
GN⁺ 2024-01-01
Commentaires sur Hacker News
  • J’aime bien. Le serveur multimédia de salon a l’air d’être le cheval de Troie qui relancera l’auto-hébergement et finira par faire revenir Internet vers une orientation P2P.
    Une fois que la plupart des gens auront une connexion symétrique et un système Linux puissant, il ne restera plus qu’un problème logiciel pour empêcher les gens d’utiliser Internet comme il était prévu à l’origine, à la fois comme consommateurs et comme éditeurs.

    • J’ai utilisé des serveurs multimédias de salon pendant des années, et ma recommandation serait justement de ne pas mettre le serveur multimédia dans le salon.
      Mieux vaut y mettre à la place un client petit, silencieux et respectueux de la vie privée, comme un Apple TV, et stocker les médias sur un NAS situé ailleurs. Selon l’UX client que vous préférez, il peut être nécessaire d’avoir une application de diffusion multimédia dédiée comme Plex, ou pas, comme avec Infuse.
      Que le serveur soit dans le salon, dans un bureau ou dans un homelab ne change pas grand-chose à la démocratisation de l’auto-hébergement ; au contraire, il est plus probable que la gestion d’une bibliothèque multimédia locale gagne moins en popularité. Les gens font ça depuis des décennies, donc s’il y avait eu un effet cheval de Troie, il se serait déjà produit.
    • J’aime bien ce point de vue, et je déteste vraiment voir Internet être devenu un Internet centralisé. Maintenant, même la recherche de base ne fonctionne plus correctement sur les principales plateformes.
    • J’ai essayé plusieurs fois de monter moi-même une configuration de PC/serveur media center, mais ça a toujours été très loin derrière ce qu’un Fire Stick fait pour un dixième du prix et avec un effort proche de zéro.
      Donc si un produit vraiment plug-and-play sort dans ce domaine, ça m’intéresse énormément.
    • J’adore vraiment l’idée d’un Roku pour Internet.
  • J’ai découvert plusieurs outils pour les distributions rpm-ostree.
    gnome-randr-rust: https://github.com/maxwellainatchi/gnome-randr-rust
    Fait office de xrandr pour Gnome/Wayland sur les distributions qui ne prennent pas en charge wlr-randr.
    Kernel-fsync: https://copr.fedorainfracloud.org/coprs/sentry/kernel-fsync/
    gnome-vrr: https://copr.fedorainfracloud.org/coprs/kylegospo/gnome-vrr/
    gsettings set org.gnome.mutter experimental-features "['variable-refresh-rate']"
    obs-vkcapture: https://copr.fedorainfracloud.org/coprs/kylegospo/obs-vkcapt...
    system76-scheduler: https://copr.fedorainfracloud.org/coprs/kylegospo/system76-s...

  • Ravi de voir que c’est enfin remonté. Quand je l’avais posté il y a quelques semaines, j’étais surpris de ne pas en avoir entendu parler plus tôt et je pensais que ça irait directement en tête, mais c’est simplement passé inaperçu (https://news.ycombinator.com/item?id=38642298).
    Bazzite m’a pas mal impressionné. Jusqu’ici, je n’ai pas encore vu d’inconvénient à utiliser Bazzite au lieu de SteamOS, alors que j’y ai trouvé beaucoup d’avantages. Je voulais depuis longtemps mettre mon Deck sur mon tailnet, mais ce n’était pas simple, et je voulais aussi installer sur l’OS de base plusieurs paquets qui fonctionnaient mal en Flatpak ; maintenant c’est possible.
    Par exemple, je fais tourner des jeux via Remote Play sur un desktop puissant et je les affiche sur la TV, tout en me connectant en SSH à l’hôte avec tmux, avec htop dans un pane et nvtop pour les cartes AMD dans un autre. Ça fonctionne bien maintenant aussi sur AMD. Pour moi, c’est comme la différence entre conduire en regardant le compteur de vitesse et le compte-tours, ou conduire sans rien. Sur SteamOS, quelque chose d’aussi simple est difficile ; sur Bazzite, c’est facile.

    • Mon Steam Deck est lui aussi sur le tailnet via services.tailscale.enable = true sur NixOS.
      Du coup, Bazzite m’intrigue et je devrais peut-être comparer NixOS et Bazzite.
  • Ça a l’air sympa. Je n’ai pas besoin de portabilité, je déteste le bruit des ventilateurs, mais je veux la simplicité d’usage de Steam, donc j’étais justement en train de chercher quelque chose comme « un PC avec des specs proches du Steam Deck ».
    On dirait qu’il existe désormais une façon simple de faire tourner des jeux sur un PC dédié, standard et silencieux. En revanche, il n’y aura probablement pas les optimisations pour des combinaisons arbitraires de GPU/CPU/RAM comme celles que Valve et AMD font pour le Steam Deck.
    Je trouve intéressant que le patch BTRFS de SteamOS soit inclus, ce qui donne par défaut un support BTRFS complet même pour les cartes SD. Je me demandais quels avantages BTRFS apportait pour les jeux ou dans le contexte du Steam Deck ; en regardant https://gitlab.com/popsulfr/steamos-btrfs, ils disent que la compression transparente et la déduplication permettent d’économiser de l’espace de stockage, que les temps de chargement peuvent aussi s’améliorer puisqu’il y a moins de données à lire, et qu’il est facile de revenir à un état antérieur via des snapshots instantanés. Ça semble utile pour des rollbacks système ou pour revenir à une autre version d’un même jeu.

    • Un système de fichiers copy-on-write est intrinsèquement meilleur pour les supports flash, car il n’écrase pas les données en place.
      Il alloue toujours de nouveaux blocs, puis marque les anciens blocs comme libérables lorsqu’ils ne sont plus référencés par le système de fichiers actif ou, le cas échéant, par des snapshots.
      Les supports flash détestent vraiment les écrasements en place, car il faut d’abord effacer un bloc avant de pouvoir réécrire dessus. Les firmwares flash modernes essaient de toute façon d’allouer de nouveaux blocs, donc une partie du problème est compensée, mais dans l’ensemble c’est un meilleur mode d’écriture pour la flash.
    • J’utilise Bazzite sur un HTPC gaming maison avec un R5-5600, Radeon 6800XT, un dongle sans fil Xbox et 4 manettes Xbone.
      De manière assez surprenante, l’essentiel du travail lourd est fait par le noyau et la pile Mesa, c’est là que le vrai boulot se passe. Fedora récupère relativement vite les mises à jour du noyau et de Mesa, et le client Steam gère les mises à jour de Proton.
      Il y a aussi une bonne synergie entre les distributions orientées jeu comme Bazzite, ChimeraOS et Nobara. Il y a beaucoup de partage de code et de collaboration, et tout est ouvert donc tout le monde peut mettre les mains dedans.
      Ça fonctionne comme un grand Steam Deck, donc l’overlay de performances, les manettes Xbox, le FSR, etc. marchent très bien immédiatement. Il faut appairer chaque manette, mais une seule fois. Personnellement, j’ai terminé en 4K des campagnes AAA comme God of War, Horizon Zero Dawn et Baldur’s Gate 3, et quand je voyage, ma progression est retrouvée telle quelle sur le Deck. C’est une vraie expérience multi-appareils.
      Il faut garder des attentes réalistes. La VR et les jeux multijoueur qui n’ont pas choisi EAC ou qui utilisent un anti-triche au niveau noyau, ainsi que tout ce qu’Epic produit, ne fonctionnent pratiquement pas. Pour moi, c’est comparable à une plateforme console : on peut jouer à beaucoup de jeux, mais pas à tous. À ce stade, l’UX est mauvaise à la fois sur Windows et sur Linux, et les horribles launchers tiers restent le pire problème dans les deux cas.
      Pour précision, je suis impliqué dans universal blue, mais je ne contribue pas directement à Bazzite.
    • J’utilise BTRFS avec la compression activée sur une vieille carte SD lente. Il y a un petit coût CPU pour décompresser les assets, mais les entrées/sorties lentes deviennent nettement plus rapides.
      La déduplication peut aussi être utile si vous stockez les runtimes Proton/Wine sur le même disque. Chaque jeu peut avoir besoin de runtimes différents, la dernière version n’est pas toujours la meilleure, et même un environnement Wine sans aucun jeu peut prendre plusieurs centaines de Mo rien qu’avec les DLL et dépendances communes. La déduplication peut réduire le gaspillage d’espace, mais vu le prix actuel du stockage flash, ce n’est probablement pas un sujet majeur en pratique.
      Certaines personnes aiment aussi les checksums, mais sans mémoire ECC, je ne trouve pas ça très utile.
    • Fedora utilise en fait BTRFS par défaut, et SteamOS aussi pour le système ; seuls le home et la carte SD sont en ext4 par défaut.
      Les principaux avantages sont la compression et surtout l’augmentation des vitesses de lecture, en particulier sur des supports contraints comme les MicroSD. La déduplication de BTRFS résout aussi le problème des prefixes Wine aux dépendances proches qui prennent plus de place qu’ils ne devraient.
    • Toutes les optimisations que Valve et AMD ont mises dans le Steam Deck devraient être présentes, auxquelles s’ajoutent leurs propres ajustements et modifications envoyés en amont dans Fedora.
  • Dans un registre connexe, j’ai découvert aujourd’hui une redistribution de SteamOS pour machines génériques. Il y a cependant la condition de ne pas avoir de GPU Nvidia : https://github.com/HoloISO/holoiso

    • J’utilise https://chimeraos.org/, qui met à jour le système via des mises à jour atomiques.
    • En lisant cette page, j’ai compris que les GPU Nvidia étaient en pratique non pris en charge par cette distribution. Mais je me demande pourquoi.
      Je ne connais pas bien les détails de la compatibilité GPU sous Linux, mais pourquoi est-ce qu’il ne suffirait pas simplement d’installer le paquet propriétaire de Nvidia ?
  • Je me demande quelle a été la motivation derrière ce projet et qui le soutient. Ça donne plus l’impression d’un mouvement open source stratégique que d’un petit projet hobby du week-end.
    Est-ce que ça pourrait avoir un lien avec Nvidia ?

    • Je suis le créateur original du projet. La motivation est totalement organique, il n’y a aucun sponsor, je n’ai jamais reçu de dons d’aucune sorte, et tous les coûts du projet sont entièrement à ma charge.
      Au départ, je voulais quelque chose qui ressemble à SteamOS, mais qu’on puisse aussi maintenir en installant des paquets et en faisant les mises à jour. Après avoir utilisé Silverblue pendant environ un an, j’ai compris que Fedora pouvait offrir ça. À partir de là, le projet a continué d’évoluer et de grandir.
      Je viens d’ajouter le HDR au canal de test, et je travaille aussi sur une signature personnalisée du noyau pour le faire passer sur le canal stable sans casser la prise en charge du secure boot.
      Si vous voulez aider dès maintenant, le mieux est de l’installer et de signaler les bugs que vous trouvez. Plus il y a d’utilisateurs, mieux c’est.
    • C’est une variante d’Universal Blue (https://universal-blue.org)
  • Je me demande à quel point cela fonctionne bien sur des appareils purement tactiles, par exemple des tablettes.
    J’ai une ThinkPad X1 Tablet 3e génération, et je cherche encore une distribution Linux agréable à utiliser comme simple tablette, sans clavier. Fedora de base a des bugs assez agaçants avec le clavier à l’écran, et l’installation de l’extension Phosh en résout la plupart, mais cela introduit d’autres désagréments qui rendent l’usage contraignant.
    Il y a aussi le chiffrement du disque : comme Grub n’a pas de clavier à l’écran, il faut toujours brancher un clavier au démarrage. Je me demande donc comment ce problème est résolu ici.

    • Je ne sais pas si tu feras des choses très sensibles sur une tablette, mais utiliser le chiffrement du dossier personnel au lieu du chiffrement complet du disque pourrait régler les problèmes de saisie tactile.
  • Regardez, Bazzite qui tourne sur un Mac Pro « poubelle » : https://youtu.be/te1AEj_RA64

  • Quand j’ai assemblé un PC gaming il y a quelques mois, ça m’a semblé être une option intéressante, donc je l’ai essayé.
    J’ai rencontré plusieurs problèmes et j’ai abandonné après environ 6 ou 7 échecs ; je suis maintenant passé à Debian (https://blog.c10l.cc/09122023-debian-gaming).
    Cela dit, je serais prêt à redonner sa chance à Bazzite pour voir si les divers problèmes que j’avais rencontrés à l’époque ont été corrigés. Il y avait toutefois une limitation rédhibitoire pour moi : l’absence de prise en charge du dual-boot / multi-boot. Est-ce que quelqu’un sait si cela a changé depuis ?