En ce mardi 18 avril, les utilisateurs du Projet Fedora seront ravis d'apprendre la disponibilité de la version Fedora Linux 38.
Fedora Linux est une distribution communautaire développée par le projet Fedora et sponsorisée par Red Hat, qui lui fournit des développeurs ainsi que des moyens financiers et logistiques. Fedora Linux peut être vu comme une sorte de vitrine technologique pour le monde du logiciel libre, c’est pourquoi elle est prompte à inclure des nouveautés.
Cette 38e édition propose principalement une mise à jour de son interface principale GNOME 44 et de l'environnement de bureau plus léger Xfce 4.18. Notons l'arrivée d'images officielles pour les environnements Sway, Budgie et Phosh, ce dernier étant l'interface de GNOME pour mobile !
Sommaire
- Expérience utilisateur
- Gestion du matériel
- Internationalisation
- Administration système
- Développement
- Projet Fedora
- La communauté francophone
- Comment se procurer Fedora Linux 38 ?
Expérience utilisateur
Passage à GNOME 44. Cette version apporte comme d'habitude de nombreuses fonctionnalités pour l'interface par défaut de Fedora Workstation.
Tout d'abord le sélecteur de fichiers permet de voir les fichiers en grille avec prévisualisation, ce qui simplifie la sélection pour l'envoi de photos ou de vidéos par rapport à la vue en liste qui était jusqu'à présent la seule disponible.
Le panneau de configuration bénéficie d'améliorations diverses. Il est possible de partager un mot de passe Wifi par un simple QR code affiché à l'écran. Concernant le réseau les VPN Wireguard sont officiellement pris en charge. La page sécurité de l'appareil est plus simple à comprendre, permettant de savoir en un clin d’œil si la vérification a échoué ou réussi, et le résultat de cette vérification. Le résultat détaillé peut facilement être copié / collé pour l'envoyer sur des forums par exemple.
La page accessibilité a été remaniée également pour être plus simple d'accès. Quelques nouvelles options ont été ajoutées comme la possibilité de sur-amplifier le son au détriment de sa qualité en cas de déficit auditif. Il y a un champ de test pour la configuration du clignotement du curseur de souris ou encore la possibilité de toujours voir la barre de défilement sur le côté.
La page son permet de désactiver le son d'alerte, la liste des alertes a d'ailleurs été déplacée dans une fenêtre popup. La page de test du son s'adapte mieux aux différentes tailles d'écran.
La page souris et pavé tactile a été entièrement réécrite. Des vidéos montrent la direction du défilement pour rendre l'explication plus claire à l'utilisateur. De même pour les tests des paramètres, la page a été refaite pour être plus simple et complète.
Pour le reste, le menu principal affiche la liste des applications en arrière plan, pour l'instant seules les applications Flatpak sont concernées. L'application Logiciels est plus réactive et elle supprime automatiquement les runtimes Flatpak quand ils ne sont plus nécessaires. Le logiciel Fichiers quant à lui réintroduit la vue expansion de dossiers qui avait été brièvement supprimée lors du passage à GTK4. Il est maintenant possible de déplacer un onglet vers une autre fenêtre.
Le navigateur Web de GNOME passe d'ailleurs à GTK4 ce qui améliore la cohérence de l'interface avec le reste de l'écosystème et sa réactivité. Une fenêtre popup surgit pour enregistrer ou non un mot de passe lors de la connexion à un site web.
La petite souris Xfce est mise à jour après 4.18 tours de roue. Cette version apporte aussi de nombreux changements pour sa communauté comme l'amélioration du renommage des fichiers dans Thunar pour remonter des erreurs ou avoir de long noms de fichier. Ce dernier comme le terminal ou l'éditeur de texte peuvent voir leur raccourcis clavier personnalisés dans leurs préférences. Les miniatures de fichiers sont générées plus rapidement.
Le navigateur de fichiers affiche le nombre de fichiers dans un répertoire lors d'une vue en liste, la colonne de date de création d'un fichier est également disponible. Les dix dernières opérations sur les fichiers peuvent être annulées ou effectuées à nouveau. Chaque fichier peut être mis en évidence avec une couleur spécifique en fond. Sa barre des tâches peut être personnalisée. Elle bénéficie d'une vue scindée au sein d'une même fenêtre pour voir deux dossiers différents en même temps. Par ailleurs, elle permet la recherche récursive dans les dossiers ou de voir les derniers fichiers récemment utilisés.
Le tableau de bord fusionne DateTime et l'horloge pour les préférences concernant l'heure et le calendrier pour supprimer des doublons. L'horloge dispose par ailleurs d'un affichage alternatif en binaire.
Le gestionnaire de configuration comme pour GNOME bénéficie de certains changements. Il est possible de décider quelle action effectuer quand un nouvel écran est branché.
Enfin, le gestionnaire de fenêtres permet la synchronisation verticale de son affichage. Une meilleure mise à l'échelle de l'interface est également proposée.
Le gestionnaire de connexions SDDM (utilisé par KDE par exemple) utilise Wayland par défaut. Cela signifie que le spin KDE Plasma et Kinoite ont fini leur transition vers Wayland par défaut. Cela a été rendu possible grâce au travail en amont pour le permettre au sein de SDDM, mais aussi aux changements opérés dans Fedora Linux 36 qui a remplacé fbdev par simpledrm pour la gestion de l'affichage en cas d'absence de pilote vidéo dédié.
L'image Fedora Linux avec le bureau Budgie devient une image Spin officielle. Cela permet de simplifier la découverte de ce bureau moderne d'une part en le mettant en avant et en facilitant son installation. Sa communauté pourra également l'installer plus rapidement tout en n'ayant pas des composants inutiles par ailleurs.
De même pour l'image Fedora Linux avec le gestionnaire de fenêtres Sway. Cela fourni les mêmes avantages que pour Budgie, avec en plus le bénéfice que Sway, en tant que i3 sous Wayland, peut être exploité sur des machines très minimalistes en puissance ce qui rend son installation directe plus pertinente encore.
L'utilitaire initial-setup n'est plus fourni dans l'image KDE et l'image Kinoite. Cette application est centrée sur GNOME pour permettre la création de l'utilisateur et quelques paramètres après l'installation, en particulier pour les installations OEM. L'objectif sera de le remplacer plus tard par un utilitaire plus adapté à l'interface de KDE Plasma, en attendant c'est Anaconda qui prend en charge ces paramètres lors de l'installation.
Flathub n'est plus filtré par défaut lors de l'installation de Fedora Linux, tous les paquets proposés sont donc accessibles. Depuis Fedora Linux 35, Flathub est proposé comme un dépôt tiers facilement activable pour récupérer des paquets Flatpak provenant de ce dépôt sans manipulations supplémentaires. Cependant il y avait un filtrage pour supprimer les applications propriétaires, ou les doublons, etc. Cependant cela rendait confus les utilisateurs qui n'avaient pas accès à tout le dépôt et rendait plus difficile la tâche de ceux qui voulaient accéder à ce dépôt en entier.
Le filtre est donc supprimé, pour éviter les effets de bords GNOME Logiciels doit proposer dans l'ordre les Flatpak de Fedora, les paquets RPM de Fedora puis les Flatpak de Flathub (ou autre dépôts) par défaut si un logiciel est disponible sous ces formats là. GNOME Logiciels doit garantir de rendre clair le fait que le logiciel à installer est propriétaire ou libre. Pour rappel, ce dépôt Flathub n'est pas actif par défaut.
Le timer systemd pour l'extinction de la machine passe de 2 minutes à 45 secondes, envoyant un signal SIGABRT puis un SIGKILL si jamais des services n'ont pas réussi à s'arrêter dans ce délai. En effet un service bloqué dans cette procédure pouvait bloquer le redémarrage ou l'extinction de la machine pendant 2 minutes ce qui est particulièrement long et souvent dû à un problème comme le service PackageKit qui est souvent concerné par cette problématique.
Il a été suggéré de baisser cela à 15 secondes, mais cela a été jugé trop agressif pour une première baisse de la durée. L'objectif est d'observer le résultat avec 45 secondes avant d'envisager une baisse supplémentaire. Les services pouvant être longs à s'éteindre dans leur comportement normal peuvent de toute façon désactiver ce temps d'attente ce qui est le cas de PostgreSQL ou de virt-manager pour éviter de mauvaises surprises pour des systèmes qui en ont besoin. Les utilisateurs qui en ont besoin sur leurs services peuvent se renseigner au sujet de XDG inhibit pour les applications ou de systemd inhibit pour les services.
cups-filters passe à la version 2.0b. Cette nouvelle version est essentiellement un redécoupage des composants avec cups-filters, libcupsfilters, libppd, braille-printer-app et cups-browsed. L'objectif est de rendre la prise en charge du format PPD indépendant du reste pour une éventuelle suppression future quand il ne sera plus pris en charge ce qui est planifié pour CUPS 3.X. Les applications spécifiques des constructeurs seront dès lors nécessaires, mais l'avènement de l'impression sans pilotes rend cette contrainte future de moins en moins gênante en pratique.
Dans le domaine de l'impression le paquet ipp-usb devient une dépendance faible de cups ou de sane-airscan pour proposer la prise en charge des imprimantes USB par défaut sans installation supplémentaire de la part de l'utilisateur. En effet de nombreuses imprimantes proposent de nos jours une prise en charge sans pilotes spécifiques pour l'impression via le réseau, mais aussi par USB via le protocole IPP over USB ce que prend en charge le paquet en question. Par conséquent un utilisateur qui souhaite imprimer ou scanner (et même faxer) aura par défaut une possibilité supplémentaire de s'en servir sans devoir chercher les paquets manquants éventuels. Ceux qui n'en veulent pas pourront toujours supprimer ce paquet dans ce cas précis.
La distribution LaTeX TeXLive version 2022 est proposée, qui est la dernière version avec une prise en charge longue durée.
L'ancien cache personnel devrait être supprimé pour s'assurer du fonctionnement, à savoir supprimer le répertoire ~/.texlive2021.
Gestion du matériel
L'installateur Anaconda utilise mdadm au lieu de dmraid pour la prise en charge des stockages RAID reposant sur un firmware ou un BIOS. En effet ce dernier n'est plus très maintenu ce qui pose des soucis pour la correction de bogues ou de failles de sécurité. D'ailleurs mdadm est plus utilisé par les logiciels de gestion des configurations RAID de nos jours. Cependant mdadm ne prend en charge que deux formats de RAID : Common RAID Disk Data Format (DDF) par SNIA et Intel Matrix Storage Manager. Cela signifie que les formats RAID gérés matériellement les plus anciens ne seront pas forcément pris en charge par Anaconda.
L'image LXQt est proposée pour l'architecture aarch64. Le bureau étant particulièrement léger, cela le rend pertinent de le proposer pour cette architecture directement.
Fourniture d'une image avec Phosh, GNOME Shell pour mobile, à destination des téléphones ou des tablettes pour l'architecture x86_64 et aarch64. Cette interface proposée par l'entreprise Purism peut tourner sur des téléphones ou tablettes si les noyaux classiques permettent une telle prise en charge native. Proposer une image dédiée permet cette installation et rend cette action plus facile.
L'architecture s390x utilise les processeurs de la génération z13 comme base, les plus anciens ne seront plus forcément compatibles. Les processeurs de générations antérieures ne sont plus prises en charge par le fabricant. Et l'architecture z13 propose des instructions vectorielles dont il est possible de tirer profit sur l'ensemble des logiciels grâce aux nouvelles options de compilation, ce qui était impossible par la prise des modèles plus anciens.
Les implémentations du serveur X (Xorg et Xwayland) refusent par défaut à des clients ayant un boutisme différent du serveur de s'y connecter. Il devient donc impossible par défaut d'utiliser un client X avec un processeur Intel pour afficher une interface provenant un serveur X sous processeur s390x. En effet ce cas de figure particulier est difficile à prendre en charge en l'état actuel du code, il est peu testé et est source d'une grande surface d'attaque pour un usage considéré comme marginal. Le désactiver par défaut permet de protéger les utilisateurs qui n'en ont pas besoin contre des clients malveillants. Cependant pour ceux qui en ont réellement besoin, il est possible de le résoudre via l'option de configuration AllowByteSwappedClients dans le fichier xorg.conf ou par l'usage de l'option +byteswappedclients en démarrant le serveur X.
Première partie de la migration vers une image noyau unifiée nommée UKI (donc unifiant noyau, initrd, ligne de commande du noyau et signature) pour les plateformes avec UEFI mais rien ne change par défaut à ce sujet. L'objectif est de rendre le démarrage du système plus sûr, robuste et uniforme car moins dépendant des spécificités de chaque système, idéalement avec un tel système, le noyau, l'initrd et la ligne de commande seraient uniques sur tous les systèmes Fedora Linux.
Cependant c'est irréaliste de tout faire en une étape, trop de choses dépendent encore de la méthode actuelle à savoir l'initrd qui est générée à partir de l'ordinateur de l'utilisateur qui se base notamment sur les pilotes actuellement chargés par le système. Le plan a été phasé ainsi :
- Phase 1 : fournir les blocs de base, à savoir pouvoir installer, démarrer et mettre à jour de tels fichiers, pour permettre de développer et de tester des images UKIs en machine virtuelle ;
- Phase 2+ : étendre la prise en charge en gérant de plus en plus de cas d'usage un par un ;
- Phase X : une fois qu'il y a parité avec les noyaux non-UKI, discuter de l'usage par défaut pour tous les cas d'usage. En particulier les images cloud ou serveurs pourraient y passer plus tôt car ils ont moins de contraintes quand le système est virtualisé.
- Non prévu : la suppression des images non UKI.
Pour ceux qui veulent tester en machine virtuelle, le paquet kernel-uki-virt est proposé à cette fin. Dans les difficultés à résoudre il y a la question des secrets matériels provenant de l'UEFI qu'il faut récupérer, il y aussi la partition où se situe la partition système qui doit être auto-détectée ce qui est possible grâce à la norme UEFI. En effet, chaque partition a un type défini sous forme de UUID unique ce qui nous renseigne sur sa nature. Ou encore la question des options particulières à envoyer au noyau pour configurer le système, utilisées par exemple pour éviter le conflit entre le pilote libre ou propriétaire de nVidia.
L'installateur de l'image IoT récupère celui de CoreOS pour simplifier son installation. Ainsi c'est une simple image OSTree qui peut être écrite sur l'espace de stockage via un argument noyau à spécifier. Pas besoin d'utiliser l'outil kickstart ou une quelconque manipulation supplémentaire. L'avantage c'est de simplifier l'installation pour des systèmes avec une connexion Internet lente ou non fiable, l'installation se faisant en une fois après que l'image ait été entièrement récupérée. Cela rapproche également Fedora IoT de l'image de RHEL dédiée à cet usage.
Internationalisation
La police par défaut pour la langue thaï et le cambodgien passe à Noto. Ces langues rejoignent ainsi celles qui avaient déjà effectué ce changement pour Fedora Linux 36 ce qui réduit la taille du système d'environ 344 kio dans ce cas et rend l'affichage plus cohérent pour l'ensemble des langues. La qualité d'affichage devrait aussi être meilleure pour ces langues.
Tandis que les polices Noto CJK pour les langues chinoises, japonaises et coréennes utilisent la variante variable au lieu de static comme auparavant. Cette variante est en effet plus légère d'un facteur deux environ, de quoi gagner plusieurs dizaines de Mio sur le système par défaut et sur les images Live.
Mise à jour de libpinyin 2.8. Ce gestionnaire d'entrée de saisie pour la langue chinoise ajoute la proposition d'expressions candidates à partir de l'entrée en cours. Cela permet d'accélérer la saisie dans cette langue.
Administration système
Les clés du serveur SSH suppriment le droit de lecture par les utilisateurs du groupe ssh_keys, qui est supprimé au passage, pour rétablir le SUID bit de l'utilitaire ssh-keysign. Cela revient à supprimer un correctif spécifique de Fedora qui date de 11 ans, ce correctif échangeait le setuid du compte root avec une permission sur ces fichiers 0600 par un sgid associé au groupe ssh_keys mais des permissions plus lâches à savoir 0640. La raison derrière ce changement n'a pas été documentée et semble perdue, cependant de plus en plus d'utilitaires, notamment pour l'authentification basée sur l'hôte, font des vérifications de ces permissions et cette déviation par rapport à une installation OpenSSH standard était source de problèmes difficiles à justifier.
RPM utilise Sequoia pour traiter le format OpenPGP au lieu de sa propre implémentation interne. Pendant près de 20 ans, toute la partie pour gérer OpenGPG était développée en interne. Cela avait plusieurs inconvénients, évidemment en terme de sécurité car ce code sensible était pris en charge par des développeurs pas experts du domaine. Mais aussi le temps de développement étant limité, améliorer la prise en charge d'OpenGPG était au détriment du reste. Le tout pour une implémentation imparfaite de la norme RFC 4880. Ce changement ouvre la possibilité d'améliorer les messages d'erreurs relatifs aux signatures des paquets à l'avenir.
Le paquet systemd-udev fourni par défaut la règle Link.MACAddressPolicy=none au lieu de Link.MACAddressPolicy=persistent pour les interfaces réseaux logiciels ponts ou agrégées. Cette information est fournie dans le fichier /usr/lib/systemd/network/99-default.link. La configuration reste inchangée pour les interfaces réseaux logiciels plus classiques ce qui garanti une stabilité dans l'assignation des adresses MAC. Ce changement a été décidé suite aux interférences avec le comportement du noyau Linux dans ce cas de figure qui utilise l'adresse MAC de la première interface. Cela peut aussi affecter les machines virtuelles qui s'attendent à ce que le pont ou l'agrégation de liens ait une des adresses MAC des interfaces réseaux impliquées.
Le gestionnaire de paquet Microdnf est mis à jour à sa 5e version. Il est à terme prévu que microdnf devienne l'implémentation de référence de dnf, le gestionnaire de paquets actuel de Fedora Linux, et ce peut être même dès Fedora Linux 39. Cette version majeure rapproche l'objectif d'une compatibilité des deux outils tout en gardant une taille plus raisonnable. Il est disponible sous le nom de paquet dnf5. Cette version améliore l'affichage des bars de progression et la gestion des transactions. L'exécution des scriptlets (les scripts avant ou après l'installation / suppression d'un paquet à des fin de conversion ou de nettoyage) est aussi affichée. Les opérations impliquant des RPM locaux est aussi améliorées de même que l'auto-complétion des commande fournie par le shell Bash qui devient meilleure que celle de dnf lui même. La gestion des dépôts modulaires est également totalement intégrée, les plugins C++ et Python sont mutualisés pour réduire le coût de maintenance. Les performances sont également améliorées dans l'ensemble parmi d'autres changements plus mineurs.
Développement
La mise à niveau de la chaine de compilation GNU est à l’œuvre avec GCC 13.0, binutils 2.39, glibc 2.37 et GDB 12.1. GCC bénéficie ainsi d'une meilleure prise en charge de l'évolution de la norme du langage C dénommée C23. De même par ailleurs pour le langage C++ avec C++23. Sinon c'est l'analyseur statique de code qui bénéficie de nouveaux avertissements plutôt nombreux. Les architectures x86 et ARM ou Aarch64 bénéficient comme souvent d'une meilleure prise en charge des spécificités des différentes micro-architectures dans ces familles.
Concernant binutils, l'éditeur de lien ELF va émettre un avertissement pour des raisons de sécurité si la pile est exécutable. La commande objdump a sa sortie de désassemblage qui est colorée syntaxiquement pour favoriser sa lecture pour les architectures AVR, RiscV, s390, x86 et x86_64. La bibliothèque C bénéficie essentiellement de corrections plus mineures dont de sécurité.
Enfin pour le débogueur, l'architecture LoongArch est prise en charge, pendant que celle d'OpenRISC s'améliore. Sinon l'API des plugins de Python s'étoffe de même que la gestion des templates C++.
Retrait de la prise en charge du langage Guile pour étendre GDB pour laisser la place à Python pour cela. La prise en charge de Guile est en effet en déclin, elle est moins complète que Python qui est de plus en plus utilisée et améliorée à cette fin. La documentation de GDB met d'ailleurs en avant Python plutôt que Guile dans cette tâche, ce qui peut laisser à penser qu'un jour cette prise en charge de Guile sera supprimée à terme. Anticiper ce mouvement permet de simplifier la tâche des mainteneurs.
Pendant que LLVM version 16 débarque. Cette mise à jour s'accompagne d'abord d'une amélioration de la prise en charge des architectures, avec les nouveaux processeurs AMD Zen 4 ou Intel Emerald Rapids. L'architecture RISC V bénéficie des options _ -mcpu=native / -mtune=native_ pour une mise au point plus fine. Le compilateur JIT prend en charge le langage OpenMP. Il peut également compresser avec l'algorithme Zstd les sections de débogage ELF.
GNU Make prépare sa version 4.4. Il y a beaucoup d'annonces de rupture de la compatibilité ascendante, dont l'usage plus important du répertoire temporaire ce qui peut casser tout script manipulant ou nettoyant TMPDIR. Il apporte l'ajout d'une nouvelle cible .WAIT pour permettre d'attendre la fin de l'exécution de plusieurs cibles avant de débuter le traitement d'une nouvelle. L'option -l va utiliser l'information exposée dans le fichier /proc/loadavg pour définir le nombre de tâches à exécuter en parallèles.
Le langage Go quant à lui passe à la version 1.20. Cette version apporte le début de la prise en charge du PGO (profile-guided optimization) pour se baser sur des données collectées à l'exécution d'un logiciel pour que le compilateur puisse recompiler ce logiciel par la suite autrement afin d'en optimiser ses performances, jusqu'à 3-4 % d'amélioration pour le moment. Par ailleurs les performances d'un logiciel Go en terme de pression mémoire et d'utilisation du processeur sont améliorées par une optimisation du ramasse miettes, pouvant aller jusqu'à 2% d'amélioration. Il est également possible de régler la micro-architecture cible à la compilation pour améliorer les performances en utilisant les fonctionnalités du processeur cible.
Le langage Ruby expose sa version 3.2 en vitrine. Son nouveau compilateur JIT nommé YJIT n'est plus considéré comme expérimental et est d'ailleurs plus performant jusqu'à 41% par rapport à la version précédente. YJIT alloue maintenant la mémoire de manière paresseuse et fonctionne aussi sur les architectures ARM et Aarch64. Les expressions régulières bénéficient d'une amélioration notable des performances pour une évaluation de la correspondance qui devient linéaire par rapport à la taille des entrées et si l'évaluation est trop lente, un timeout est généré basé sur la valeur de configuration Regexp.timeout. L'objectif était d'éviter une dégradation trop importante des performances dans certains cas, notamment dans un cadre malveillant.
Le langage PHP évolue vers la version 8.2. Cette version apporte entre autre la possibilité de définir des classes en lecture seule. Les types null, false et true deviennent des types autonomes. Les types de forme normale disjonctive sont pris en charge pour faciliter l'expression des unions et intersections de types pour faciliter la lecture et l'écriture de code.
Le gestionnaire de base de données PostgreSQL met à jour à la version 15. Cette version apporte la prise en charge de la commande SQL MERGE. L'algorithme de compression Zstd peut être employé également notamment pour les sauvegardes. Les journaux côté serveur peuvent être exportés au format JSON. Enfin les performances sont améliorées en particulier pour les opérations de tris.
Pendant que Haskell GHC (le compilateur Haskell) 9.2 avec sa suite Stackage 20 sont disponibles. Du côté des performances, les architectures Aarch64 et s390x bénéficient d'une amélioration de ce côté. Pour le premier grâce à une prise en charge native par le compilateur GHC au lieu de LLVM utilisé jusqu'à présent. Pour le second par l'usage du système de construction Hadrian fourni par LLVM. Le langage lui même évolue, en proposant les types LinearTypes ou ImpredicativeTypes ou encore UnliftedDatatypes.
L'écosystème Node.js est repackagé pour autoriser des installations multiples et parallèles, abandonnant l'usage des modules qui était la voie privilégiée jusqu'ici. En effet, si les modules permettent de changer la version d'un paquet sans changer de version de Fedora Linux, il ne permet pas l'installation parallèle ce qui est embêtant particulièrement pour l'écosystème JavaScript qui évolue rapidement et dont le test sur plusieurs versions est nécessaire. Le travail est ainsi rendu plus simple pour le développeur sans l'usage de conteneurs. Par ailleurs la maintenance pour Fedora Linux était globalement plus complexe. Le paquet nodejs renvoie actuellement à la version 18.15, tandis que les paquets nodejs16 et nodejs20 fournissent respectivement la branche 16.x ou 20.x.
La bibliothèque pcre est marquée comme obsolète au bénéfice de pcre2, sa suppression totale des dépôts (et de ses dépendances) est à prévoir prochainement. En effet sa dernière version 8.45 sortie en juin 2021 est la dernière, ce qui signifie qu'aucun bogues ou failles de sécurité associés ne seront corrigés. Cela concerne encore 67 paquets dans les dépôts qui n'ont pas achevé la transition.
OpenJDK est compilé pour ressembler plus aux implémentations standards de JDK avec les bibliothèques internes au lieu de celles du système et la compilation avec la bibliothèque libstdc++ liée statiquement. Cela signifie que les options de compilation dorénavant utilisées sont les suivantes : --with-stdc++lib=static --with-zlib="bundled" --with-freetype="bundled" --with-libjpeg="bundled" --with-giflib="bundled" --withlibpng="bundled" --with-lcms="bundled" --with-harfbuzz="bundled". L'objectif est de réduire les différences entre les JDK depuis Fedora Linux et les autres systèmes. Ces différences étaient coûteuses à maintenir pour Fedora Linux notamment pour certifier le résultat de chaque version de JDK que Fedora Linux propose ce qui ralentie les mises à jour mais aussi la correction d'autres bogues. Mais en contrepartie, OpenJDK ne tire plus bénéfice du partage de ces bibliothèques avec le reste du système notamment en consommation de ressources ou corrections liées à ces bibliothèques.
La boîte à outils pour le développement Web en Python nommé Pyramid bénéficie de la version 2.0. Tout d'abord cette version n'est compatible qu'avec Python 3. D'un point de vue fonctionnel, son changement majeur est la fusion des politiques d'authentification et d'autorisation au sein d'une politique unique. L'ancienne méthode reste disponible pour des raisons de compatibilité ascendante.
Mise à jour de python-packaging version vers la version 22.0. Les paquets utilisant LegacyVersion ou LegacySpecifier ne peuvent plus être générés tels quels et doivent se conformer à la PEP 440 ce qui améliore la compatibilité avec le reste de l'écosystème Python.
Le paquet python3-toml est considéré comme obsolète avant suppression définitive à venir depuis la prise en charge de cette fonctionnalité dans la bibliothèque standard depuis Python 3.11. Cela signifie qu'aucun nouveau paquet ne pourra dépendre de lui et qu'une étape de conversion progressive des dépendances actuelles est en cours. Ce qui peut permettre par ailleurs de bénéficier des évolutions du standard TOML, non pris en charge par ce même paquet. À cause des divergences d'API et de nommage, la transition de l'un vers l'autre n'est pas trivial et ne peut reposer sur un paquet python3-toml qui pointe vers python3-libs ou python3 directement.
Le paquet du compilateur FreePascal fpc est subdivisé en trois paquets : fpc pour le compilateur lui même, fpc-ide pour l'environnement de développement en ligne de commande et fpc-units-NOMARCHITECTURE-linux pour la bibliothèque standard précompilée. Les utilisateurs peuvent se contenter d'installer uniquement ce dont ils ont besoin.
Le générateur d'interface SWIG se balance vers la version 4.10. Ses évolutions dans la prise en charge des langages sont multiples. Côté Nodejs il peut fournir maintenant pour la version 12 à 18, tout en supprimant la prise en charge des versions antérieures à version 6. Octave 6.0 et 6.4 sont fournis également, tout comme PHP 8 qui perd par contre les versions plus anciennes que la version 5.8. Côté Python c'est 3.3 la version minimale supportée, jusqu'à la version 3.11. Les évolutions de C et C++ sont également mieux prises en charge avec notamment le début de compatibilité avec C++20 et de std::unique_ptr.
L'utilitaire ImageMagick tire profit de sa 7e version. Cette version n'est pas compatible avec l'ancienne version 6. Elle bénéficie de nombreux changements comme la prise en charge native des images HDRI. La structure de donnée Pixel Channels a été totalement remaniée, au lieu d'en avoir 4 définie dans PixelPacket (pour rouge, vert, bleu et l'opacité) et d'autres éventuellement comme le niveau de gris, ou l'index des couleurs dans IndexPacket, maintenant il peut y en avoir 1 à 64 par pixels définis ensemble. Cela rend le code plus générique et plus clair, mais aussi autorise le compilateur d'optimiser le code dans les boucles de traitement en particulier. Beaucoup de fonctions sont fournies autour de cela pour faciliter leur utilisation et rendre le code plus générique. L'opacité devient aussi un canal `alpha´ ce qui inverse la logique, une opacité de 0 signifie opaque, quand c'est totalement transparent pour alpha. Mais cela correspond mieux à la terminologie habituelle pour manipuler des pixels dans une image. Les API ont été remaniées pour prendre en compte ces changements de conception, d'où la rupture de compatibilité.
Projet Fedora
La génération des images Fedora IoT reposera sur osbuild. Cela permet de corriger le retard pris par cette édition de Fedora Linux par rapport à RHEL for Edge qui est son équivalent proposé par Red Hat ce qui facilitera notamment les travaux communs.
Les paquets sont compilés avec l'option _FORTIFY_SOURCE=3 au lieu de _FORTIFY_SOURCE=2 pour mieux se protéger contre les buffers overflow dans les logiciels fournis. Cela concerne des fonctions au sein de la bibliothèque glibc qui concernent beaucoup plus de fonctions avec cette nouvelle édition. Notons que cela a déjà été mis en place du côté de chez Swann, de Gentoo ou de OpenSUSE par exemple.
Les paquets sont également compilés avec les options -fno-omit-frame-pointer et -mno-omit-leaf-frame-pointer par défaut. L'objectif est d'améliorer le profilage et le débogage des paquets ainsi compilés, ce qui est particulièrement utile pour vérifier les performances des logiciels ayant beaucoup de dépendances. Une baisse de performances est cependant possible bien que faible d'après les essais préliminaires menés et les retours du terrain chez Google. Les résultats étant en résumé :
- La compilation du noyau Linux avec GCC est 2,4% plus lente ;
- Le rendu effectué par Blender peut être jusqu'à 2% plus lent ;
- OpenSSL, Botan, Zstd ou Redis n'ont pas d'impacts mesurables ;
- Les tests spécifiques de CPython peuvent avoir une perte de 1 à 10% suivant les tests.
Les paquets qui veulent changer leur option de compilation doivent passer par les macros %_pkg_extra_cflags, %_pkg_extra_cxxflags, %_pkg_extra_fflags et %_pkg_extra_ldflags pour plus de lisibilité et de traçabilité. L'objectif est d'avoir un moyen standard et unifié de personnaliser ces options de compilation pour l'ensemble des paquets ce qui simplifie la lisibilité et donc la maintenance. Les mainteneurs de la chaine de compilation peuvent plus facilement expérimenter en utilisant ces options plutôt que de changer redhat-rpm-config directement. Enfin il est possible de voir tous les paquets qui personnalisent la compilation ainsi par des requêtes assez simples.
La macro rpmautospec (qui emploie les macros %autorelease et %autochangelog) est recommandée pour l'ensemble des paquets par défaut. En effet, introduit par Fedora Linux 35, seulement 3423 paquets sur 23045 s'en servaient soit environ 15% d'entre eux. Les avantages attendus sont multiples, les mainteneurs n'ont plus à toucher au champ Release qui est généré automatiquement, le commit pour générer le nouveau paquet permet de remplir le champ changelog automatiquement ce qui fait gagner du temps au mainteneur. Comme ces champs sont générés par une macro à la construction, il est plus simple de réutiliser une mise à jour du fichier spec entre les différentes version de Fedora Linux car les conflits sont moins nombreux, de même pour les pull requests vers src.fedoraproject.org qui ont moins de conflits.
Activation de la macro %clamp_mtime_to_source_date_epoch à 1 qui configure mtimes (le temps de modifications des fichiers) en $SOURCE_DATE_EPOCH pour la compilation reproductible des paquets. La date est ainsi liée à la date du dernier champ dans la macro %changelog. Il devient ainsi beaucoup plus simple de faire de la compilation reproductible car l'information est facilement disponible et n'est pas altérée par l'heure où le paquet a été effectivement construit. Cependant la compilation reproductible n'est pas complète au sein du projet Fedora encore.
La macro pour gérer les dépendances des modules Perl perl(:MODULE_COMPAT%(eval "%{__perl} -V:version"; echo $version))_ est supprimée au profit de perl-generators. L'objectif est de réduire le besoin de recompilation des paquets Perl à chaque mise à jour de Perl pour ne concerner que les paquets qui en ont besoin, soit à cause d'une rupture de compatibilité ou parce qu'ils contiennent eux même du code compilé qui en dépendent directement. Cela simplifiera beaucoup la tâche des mainteneurs Perl, en passant de 3259 paquets impactés par ces mises à jour à environ 600.
Les paquets Python fournissant la métadonnée python3dist(…) = 0 échoueront dans leur construction. Il était parfois employé par les paquets quand la version exigée par le programme n'était pas connue mais cela relevait souvent d'une erreur du mainteneur des paquets. Cela pouvait générer des problèmes, par exemple si un paquet dépend de python3-ssh-python > 0.9 alors que la version de ce paquet 0.10.0 est disponible dans les dépôts, le générateur automatique de dépendances ne va pas identifier le paquet et générer des erreurs lors de la résolution des dépendances. Au moment de la décision d'effectuer ce changement, seulement 10 paquets étaient ainsi construits mais cela évitera que ce problème n'apparaisse également encore dans le futur.
Début de l'usage généralisé des noms abrégés de licence provenant du projet SPDX pour la licence des paquets plutôt que des noms du projet Fedora, de manière facultative pour l'instant. En effet au sein du projet Fedora si les licences sont bien renseignées, leur usage n'était pas totalement uniforme avec des variations possibles entre les paquets ou des imprécisions dans leur mention. Le projet SPDX commence à s'imposer comme une référence dans la résolution de ce problème avec une nomenclature standardisée et en étant largement adopté par le noyau Linux, Debian, OpenSUSE ou FreeBSD. Cela rendra également le travail de Fedora Legal et de la documentation autour des licences plus simple.
Par exemple le paquet tmux avait pour champs de licence ISC and BSD qui devient maintenant ISC AND BSD-3-Clause AND BSD-2-Clause ce qui met en exergue une meilleure précision.
À ce jour environ 20% des paquets ont été convertis. Et les nouveaux paquets devront dès le départ utiliser cette nomenclature. Le reste devrait suivre pour Fedora 39 maintenant que les outils et la procédure sont en place.
La communauté francophone
L'association
Borsalinux-fr est l'association qui gère la promotion de Fedora dans l'espace francophone. Nous constatons depuis quelques années une baisse progressive des membres à jour de cotisation et de volontaires pour prendre en main les activités dévolues à l'association.
Nous lançons donc un appel à nous rejoindre afin de nous aider.
L'association est en effet propriétaire du site officiel de la communauté francophone de Fedora, organise des évènements promotionnels comme les Rencontres Fedora régulièrement et participe à l'ensemble des évènements majeurs concernant le libre à travers la France principalement.
Si vous aimez Fedora, et que vous souhaitez que notre action perdure, vous pouvez :
- Adhérer à l'association : les cotisations nous aident à produire des goodies, à nous déplacer pour les évènements, à payer le matériel ;
- Participer sur le forum, les listes de diffusion, à la réfection de la documentation, représenter l'association sur différents évènements francophones ;
- Concevoir des goodies ;
- Organiser des évènements type Rencontres Fedora dans votre ville.
Nous serions ravis de vous accueillir et de vous aider dans vos démarches. Toute contribution, même minime, est appréciée.
Si vous souhaitez avoir un aperçu de notre activité, vous pouvez participer à nos réunions mensuels chaque premier lundi soir du mois à 20h30 (heure de Paris). Pour plus de convivialité, nous l'avons mis en place en visioconférence sur Jitsi.
La documentation
Depuis juin 2017, un grand travail de nettoyage a été entrepris sur la documentation francophone de Fedora, pour rattraper les 5 années de retard accumulées sur le sujet.
Le moins que l'on puisse dire, c'est que le travail abattu est important : près de 90 articles corrigés et remis au goût du jour.
Un grand merci à Charles-Antoine Couret, Nicolas Berrehouc, Édouard Duliège, José Fournier et les autres contributeurs et relecteurs pour leurs contributions.
La synchronisation du travail se passe sur le forum.
Si vous avez des idées d'articles ou de corrections à effectuer, que vous avez une compétence technique à retransmettre, n'hésitez pas à participer.
Comment se procurer Fedora Linux 38 ?
Si vous avez déjà Fedora Linux 37 ou 36 sur votre machine, vous pouvez faire une mise à niveau vers Fedora Linux 38. Cela consiste en une grosse mise à jour, vos applications et données sont préservées.
Autrement, pas de panique, vous pouvez télécharger Fedora Linux avant de à son installation. La procédure ne prend que quelques minutes.
Nous vous recommandons dans les deux cas de procéder à une sauvegarde de vos données au préalable.
De plus, pour éviter les mauvaises surprises, nous vous recommandons aussi de lire au préalable les bogues importants connus à ce jour pour Fedora Linux 38.
Aller plus loin
- Site officiel du projet Fedora (143 clics)
- Site officiel de la communauté francophone de Fedora (82 clics)
- Image Torrents officiels (47 clics)
- Procédure de mise à niveau (31 clics)
# accessible ?
Posté par spell (site web personnel) . Évalué à 3.
Houla, cela ne va pas du tout ce titre !
Cela n'a rien à voir avec l'accessibilité de FEDORA, mais sa disponibilité.
Je pense que le titre : "Fedora Linux 38 est disponible" serait meilleur.
[^] # Re: accessible ?
Posté par Renault (site web personnel) . Évalué à 9.
Jeu de mots avec le fait que le panneau de config de l'accessibilité a été remanié.
[^] # Re: accessible ?
Posté par FlashCode (site web personnel, Mastodon) . Évalué à 3.
Même si c'est un jeu de mots, je ne le trouve pas approprié : cela laisse penser que la distribution devient globalement "accessible", alors qu'il s'agit juste d'un "remaniement de la page accessibilité" parmi plein d'autres changements.
Cela est donc trompeur, je vote pour changer le titre par exemple en : "Fedora Linux 38 est disponible !".
WeeChat, the extensible chat client
# ironie
Posté par Psychofox (Mastodon) . Évalué à 2.
Ma fedora 38 beta semble s'être autodétruite il y a 3 jours. Et be m'a pas laissé faire un dnf hiatory
Bon elle boote toujours et certaines applis se lancent mais d'autres non. Pas vraiment eu le temps d'investiguer.
[^] # Re: ironie
Posté par Psychofox (Mastodon) . Évalué à 7.
Finalement résolu par un dnf distro-sync --refresh.
J'ai aussi appris l'existence du paquet et de la commande "remove-retired-packages" qui permet de nettoyer les paquets qui ne sont plus fournis et maintenu par la distro (ou qui ont changé de nom pour certains).
# Flou sur le QR Code
Posté par raphj . Évalué à 8.
Super travail pour la dépêche.
J'ai un doute sur la suffisance du flou sur le QR Code du réseau, à mon avis il vaudrait mieux un bon vieux carré blanc ou noir, ou utiliser un mot de passe temporaire bidon pour générer le QR code et en changer.
[^] # Re: Flou sur le QR Code
Posté par woffer 🐧 . Évalué à 2.
Oui, car si je me souviens bien, il y a un mécanisme pour conserver les informations même si le QR Code est dégradé.
[^] # Re: Flou sur le QR Code
Posté par ben51 . Évalué à 3.
Alors oui mais c'est juste de la redondance.
Donc si tout ou en grande partie du qrcode est illisible tu ne pourra pas aller plus loin.
Mais c'est vrai qu'un simple floutage ne suffi plus forcément.
# Vivement l'avènement de Silverblue
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 8. Dernière modification le 19 avril 2023 à 17:22.
Je me suis décidé à quitter Arch Linux pour Fedora après avoir été séduit par la promesse de Silverblue, celle d'un système qui est "pareil" pour tout le monde, qu'on peut facilement downgrader en cas de pépin à l'upgrade, et qui permet un écosystème d'applis commun à toutes les distros, en l'occurrence Flatpak. J'en avais déjà parlé ici, mais Fedora semble toujours résolu à faire de Silverblue la nouvelle configuration par défaut de sa distribution, d'ici les 5 prochaines années. Je vous recommande la discussion à ce sujet sur leurs forums.
En ce qui me concerne, j'ai mis à jour mon Silverblue vers la version 38, et à part deux-trois soucis que j'avais déjà sur la 37, ça marche comme sur des roulettes. Je partage donc l'enthousiasme autour de l'idée, et j'ai hâte de la voir prendre de l'ampleur dans l'avenir.
[^] # Re: Vivement l'avènement de Silverblue
Posté par antistress (site web personnel) . Évalué à 5.
Pas impossible qu'un jour je quitte ma Debian GNU/Linux Testing avec Flatpak pour Silverblue
[^] # Re: Vivement l'avènement de Silverblue
Posté par antistress (site web personnel) . Évalué à 3. Dernière modification le 20 avril 2023 à 13:55.
Intéressant en suivant ton lien :
Q
R
Il y a donc les flatpak fedora et ceux de flathub ? Pourquoi ? Et y a t-il des doublons ? Est-ce que l'idée de flatpak fedora ne tue pas l'idée même de flatpak ?
[^] # Re: Vivement l'avènement de Silverblue
Posté par Okki (site web personnel, Mastodon) . Évalué à 3.
À mon avis, c'était juste temporaire. Maintenant qu'avec Flathub et les dernières versions de GNOME Logiciels on peut filtrer pour n'avoir que les logiciels libres ou les applis vérifiées, les distributions pourront activer plus facilement le dépôt par défaut, en se disant qu'il y aura sans doute bien moins de Flatpak problématiques.
[^] # Re: Vivement l'avènement de Silverblue
Posté par Psychofox (Mastodon) . Évalué à 3. Dernière modification le 20 avril 2023 à 16:02.
Fedora a son propre repo flatpak avec une liste réduite.
Mais:
1. Il est possible d'activer le flathub
2. Je crois quec'est maintenant fait par défaut justement depuis la 37 ou 38
Pour ce qui est des raisons, au départ je crois qu'il y avait une question de qualité. Il n'est pas non plus impossible que le problème ait été sur la partie légale (brevets logiciels, etc) pour la même raisons que certaines applis, codecs, ne sont dispos que via le repo tiers rpmfusion.
[^] # Re: Vivement l'avènement de Silverblue
Posté par Renault (site web personnel) . Évalué à 10.
Oui il y a des doublons, et j'ai mentionné d'ailleurs dans la dépêche que GNOME Logiciels affiche ceux de Fedora avant ceux de Flathub dans ce cas de figure.
Pourquoi c'est là ? Pour plusieurs raisons.
Tout d'abord l'avantage est d'en avoir le contrôle et de pouvoir automatiser la chose. Nouvelle version du paquet X ? Hop le Flatpak est généré automatiquement à partir de la construction du RPM. Cela évite de dupliquer l'effort.
L'autre avantage est que Fedora a des dépôts assez fourni, cela peut permettre de proposer à terme plus de paquets que Flathub. Et comme Flatpak est universel, cela permet à tout le monde d'en tirer profit. Un utilisateur d'Ubuntu est intéressé par un composant plus récent que Flathub ne propose pas ? Il peut piocher dans les dépôts de Fedora s'il existe.
Flatpak n'est pas antinomique avec le fait d'avoir plusieurs dépôts concurrents et des doublons, libre à l'utilisateur de choisir selon ses critères ce qu'il veut installer. L'avantage est surtout côté utilisateur, rien ne l'empêche d'installer un paquet Flatpak quelque soit sa provenance initiale.
Pour le développement et le tests c'est d'ailleurs cool aussi. Tu peux envisager des dépôts proposant les applications de GNOME construits à partir des derniers commits chaque nuit. Un dépôt peut se spécialiser en logiciels avec longue durée de support (comme par exemple ne proposer que Firefox ESR au lieu du dernier Firefox dispo).
[^] # Re: Vivement l'avènement de Silverblue
Posté par barmic 🦦 . Évalué à 3. Dernière modification le 23 avril 2023 à 09:07.
Est-ce que ceux de fedora utilisent les mêmes layers que flathub ou une base fedora ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Vivement l'avènement de Silverblue
Posté par bbo . Évalué à 4. Dernière modification le 24 avril 2023 à 21:04.
Une base Fedora.
Je cite :
Je comprends donc que le dépôt Flatpak de Fedora est juste un packaging différent des logiciels qui sont déjà dans les dépôts officiels de Fedora. D'où probablement le fait que ça puisse lagguer derrière Flathub.
[^] # Re: Vivement l'avènement de Silverblue
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 5.
Avec la sortie de Fedora 38, j'ai aussi essayé d'installer Silverblue.
Je n'avais pas bien compris ce que c'était vraiment et j'ai cru que tout le système d'exploitation serait en lecture seule.
Heureusement, j'ai essayé et j'ai appris que "/etc" est toujours modifiable, ouf !
Finalement, c'est surtout
/usrqui est en lecture seule: ça permet de laisser la gestion de ces données exclusivement à la distribution Linux et de permettre des mises à jour plus fiable, car personne ne touche à ce répertoire.Colin Walters a bien expliqué sur son blog pourquoi cette propriété est intéressante.
Notamment, parce que, même si personnellement je ne touche pas à
/usr, je ne suis pas à l'abri qu'un script d'installation y touche malgré moi.Au début, j'avais aussi un peu peur par rapport à l'installation de service système: par exemple, j'ai besoin de pouvoir connecter mon ordinateur à un service VPN. Eh bien, avec
rpm-ostree, on peut encore ajouter des composants systèmes via les RPM de Fedora.Si j'ai bien compris le système ce n'est pas un soucis, car lors d'une mise à jour majeur,
rpm-ostreefera unrebasedes paquets RPMs installés à la main sur la nouvelle version de Fedora. Autrement dit, ça ressemble exactement aux rebases quotidiens que je fais avec git durant mes développement, ça me plaît :)L'utilisation des Flatpak de Flathub ça me plaît bien également, je l'utilisais déjà avec Debian et Fedora Workstation.
Il me reste enfin l'utilisation de toolbox dont je ne suis toujours pas trop sûr de l'intérêt. Vous avez des retours ?
J'ai installé mon environnement de développement dans toolbox comme conseillé. Mais je me dis que, quand je vais devoir mettre à jour le container toolbox, eh bien, j'aurai perdu tout l'intérêt de Silverblue : je vais repasser par les mises à jours via
dnfavec un/usrpotentiellement plein de modifications. Je ne ferais pas mieux d'utiliser les packages Fedora avecrpm-ostree?Est-ce que l'idée est de pouvoir juste délier la mise à jour de l'hôte et des containers ? Par exemple, ça me permettrait d'activer les mises à jour automatique de Fedora Silverblue sur l'hôte sans prendre de risque de casser mes outils de développement tout le temps ?
[^] # Re: Vivement l'avènement de Silverblue
Posté par Psychofox (Mastodon) . Évalué à 5.
J'utilise de temps en temps toolbox. L'intérête selon moi c'est d'avoir des environnements de dev potentiellement jetables.
Tu as un ticket pour corriger un bug sur un outil en go, tu crées la toolbox, installes les dépendances que tu veux, bosse dessus, une fois que c'est fait tu peux détruire ta toolbox. Si 3 jours après tu travailles sur un truc en typescript/node, perl ou en python, tu en crées une autre.
Plutôt que de maintenir ta toolbox, tu la crées à la demande. À chaque fois elle sera installée depuis une image actualisée. Si tu as des besoins récurrents dans des projets, c'est pas compliqué d'avoir un script qui installes toutes ces dépendances à la racine du dépôt git de ces projets.
[^] # Re: Vivement l'avènement de Silverblue
Posté par ff9097 . Évalué à 4.
quelle différence avec Docker ?
[^] # Re: Vivement l'avènement de Silverblue
Posté par Renault (site web personnel) . Évalué à 5.
Cela repose sur podman, d'un point de vue base c'est donc similaire.
Mais Fedora toolbox a été conçu pour te simplifier la vie, DBus est par exemple configuré pour permettre le partage entre l'hôte et le système dans le conteneur, la gestion des permissions, etc. Les commandes sont également plus simples car totalement définies pour ce cas d'usage.
Il faut voir ça comme une surcouche simple d'accès et pratique car optimisée dans ce but, cependant tu ne pourras pas vraiment t'en servir pour lancer un service isolé en arrière plan car ça n'a pas été conçu en ce sens même si c'est possible.
[^] # Re: Vivement l'avènement de Silverblue
Posté par Psychofox (Mastodon) . Évalué à 6. Dernière modification le 21 avril 2023 à 13:28.
Comme dit plus haut c'est basé sur podman donc la difference est mini.
Cela dit à l'usage tu fais toolbox create puis toolbox enter .
C'est un peu plus long que de faire docker run -it --pull=always --name mais tu t'affranchis aussi de la partie configuration du volume monté, ta toolbox monte directement ton home. Et t'as sudo déjà configuré dans le container.
Note qu'il existe aussi distrobox qui supporte plein d'autres distribs que fedora:
Perso je trouve dommage que les commandes toolbox/distrobox create n'ont pas un petit argument qui permet de faire le toolbox/distrobox enter directement une fois créée.
[^] # Re: Vivement l'avènement de Silverblue
Posté par ff9097 . Évalué à 2.
Je développe habituellement via vscode dans le conteneur avec l'extension remote container. Est ce faisable ?
[^] # Re: Vivement l'avènement de Silverblue
Posté par Psychofox (Mastodon) . Évalué à 4.
Je n'utilise pas cette horreur propriétaire mais apparemment quelqu'un a bossé dessus:
https://discussion.fedoraproject.org/t/toolbox-and-visual-studio-code-remote-containers/27987
[^] # Re: Vivement l'avènement de Silverblue
Posté par gnumdk (site web personnel) . Évalué à 3.
Ce n'est pas une très bonne idée d'utiliser rpm-ostree pour autre chose que des paquets obligatoires (drivers, …)
Donc distrobox ou toolbox, ça permet d'avoir un environnement pas en lecture seul justement.
Ici j'ai mon shell par défaut sous ArchLinux, une Debian qui fait tourner le client syncthing (même version que sur mon serveur Debian) et une KaliLinux.
[^] # Re: Vivement l'avènement de Silverblue
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 21 avril 2023 à 20:49.
C'est ce que je lis partout au sujet de silverblue mais je n'ai vu nul part les raisons techniques expressément décrites. Du coup pourquoi?
Ça fout le bordel quelque part? Ça augmente le temps des majs? Ça rend ton système moins robuste?
De ce que je vois à vue de nez tu ne perds pas l'atomicité. Le seul truc évident que je vois c'est qu'après install/upgrade la couche rpm os-tree correspondante n'est pas utilisable et requiert un reboot ce qui fait que c'est moins pratique pour une appli ou une commande que tu veux utiliser immédiatement dans ta session.
[^] # Re: Vivement l'avènement de Silverblue
Posté par Renault (site web personnel) . Évalué à 5.
Il y a plusieurs raisons.
La première tu l'as souligné et elle est d'ordre pratique, le système fonctionne par état et le changement d'état implique un redémarrage. Plus tu utilises cela, plus tu devrais redémarrer le temps d'expérimenter, c'est vite pénible.
Ensuite la philosophie du système est la suivante :
Garder rpm-ostree minimal a plusieurs avantages. Déjà plus tu es proche de l'état du système officiel distribué par Fedora, plus ton image sera identique aux autres et donc plus la QA effectuée dessus sera pertinente pour éviter que tu n'aies des bogues qu'ils n'ont pas identifié.
Enfin, l'idée de garder cela minimal est une question de robustesse. L'objectif est toujours d'avoir un système minimal qui démarre permettant éventuellement d'être sauvée sans utiliser l'artillerie lourde type live USB. Plus tu ajoutes des composants, plus le risque d'avoir des effets de bords dans ce niveau là augmente.
[^] # Re: Vivement l'avènement de Silverblue
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2.
Merci, je comprend l'idée, mais j'ai l'impression que si je suis vraiment ces conseils, je vais me retrouver avec beaucoup de logiciels installés dans mon toolbox.
Typiquement dans le toolbox que j'ai fais durant mes tests, j'ai: zsh, powerline, vim-X11, shellcheck, nodejs, git… La plupart de ces outils n'auront pas de Flatpak disponible et du coup il me reste le choix soit d'utiliser rpm-ostree, soit toolbox.
Si j'utilise toolbox, alors je vais devoir faire moi-même les mises à jour avec dnf ou la création d'un nouveau toolbox de zéro et donc réappliquer un script qui installe mes outils.
Là, j'ai l'impression de perdre tous les avantages de Silverblue et de devoir gérer une distribution finalement comme si j'utilisais Fedora Workstation. Bien que mon système principale fasse parti de la QA prévue par Fedora Silverblue, la plupart de mes outils ne seront pas couverts par cette QA.
Si j'utilise rpm-ostree, alors les mises à jours sont gérées directement par Fedora Silverblue et mes paquets sont réinstallés en tant que surcouche par dessus le système de base.
Comme dit plus bas, si je me limite à installer des paquets distribués par Fedora, mon système se retrouve finalement aussi dans un état prévu par Fedora, non ?
[^] # Re: Vivement l'avènement de Silverblue
Posté par Renault (site web personnel) . Évalué à 4.
Je ne vois pas trop des avantages dont tu parles en fait, tu peux étayer ?
Oui, mais je vais expliqué ce que j'entends par état.
Une Fedora classique n'est jamais une autre, même si tu installes les mêmes logiciels. L'ordre d'installation peut différer, suivant quand la mise à jour est faite les transitions peuvent différer, l'ordre d'installation des paquets n'est pas forcément la même, etc. Notons que c'est pareil partout ailleurs, ce n'est pas propre à Fedora.
Cela n'a l'air de rien, mais ces détails sont source de bogues difficilement reproductibles et parfois bien pénibles. En particulier à cause des scripts de conversion pré / post mise à jour.
Avec Silverblue, le système de base fourni par Fedora, tu es sûr que l'état est le même pour tout le monde qui a téléchargé le "commit X".
Après évidemment l'usage de rpm-ostree fonctionne et sera à priori toujours possible (car de toute façon pour certaines choses il n'y a pas forcément de solutions alternatives à ce jour). Et la qualité ne sera pas plus basse qu'avec une Fedora Linux classique. Mais clairement le concept de Fedora Silverblue est d'avoir cette base du système qui soit la plus petite possible et la plus commune possible entre les utilisateurs.
[^] # Re: Vivement l'avènement de Silverblue
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2.
Si jamais, je n'ai pas beaucoup de recul, car ça fais moins d'une semaine que j'essaie Silverblue et toolbox. C'est justement pour ça que je demandais des retours :)
Je pose comme hypothèse que Fedora Silverblue amène plus de stabilité et de facilité pour les mises à jours par rapport à Fedora Workstation. Fedora Workstation amène plus de flexibilité et moins d'assurance pour la QA.
Si j'installe des outils dans toolbox, alors ceux-ci seront installés dans une distribution de type Fedora Workstation: beaucoup de flexibilité, mais moins de stabilité.
Comme j'utilise tous les jours ces outils, de mon point de vue, c'est comme si j'avais installé Fedora Workstation sur ma machine: mes outils quotidiens ne bénéficient pas de la stabilité et des mises à jour de Fedora Silverblue.
En y réfléchissant, je serai dans la même situation avec rpm-ostree finalement, puisque l'ajout d'overlays de paquets RPM réduit aussi la stabilité du système.
En conclusion, je pense qu'il serait mieux que j'utilise toolbox, parce qu'il permet au moins de garder mon système principale stable et, en plus, il délie la mise à jour de ma machine de la mise à jour de mes outils.
Pour mes outils de base, je peux faire un Dockerfile pour simplifier les mises à jours.
J'aime bien aussi l'idée de pouvoir ponctuellement créer des environnements de développement jetable quand je donne un coup de main sur d'autres projets, comme expliqué par Psychofox plus haut.
Merci tout le monde pour les éclairages :)
[^] # Re: Vivement l'avènement de Silverblue
Posté par Renault (site web personnel) . Évalué à 4. Dernière modification le 22 avril 2023 à 18:41.
Pas tout à fait, ça dépend où on regarde.
Au niveau système, oui. Au niveau applicatif la flexibilité est du côté Silverblue. Par exemple avec Fedora Workstation, tu veux la dernière version de LibreOffice qui vient de sortir car une fonctionnalité t'intéresse, mais LibreOffice chez Fedora ne change de version majeure qu'avec une nouvelle version du système, pendant ces quelques mois tu fais comment ? Tu dois attendre ou te démerder souvent à la main. Avec Flatpak pour peu qu'un dépôt le fournisse l'affaire est réglé. Tu veux une nouvelle version de GNOME Fichiers mais pas mettre à jour le reste car pas le temps ou envie de casser ton système qui fonctionne, même topo. Etc.
Les Flatpak apportent une flexibilité que tu n'as pas dans Fedora classique (et toute distribution classique au fait). Si tu veux sortir des version fournie des dépôts officiels, faut croiser les doigts que quelqu'un ait fait le sale boulot, et que niveau dépendance ça passe.
Silverblue est rigide au niveau du système pour être stable, mais au dessus du système cela devient en fait plus flexible.
Le but ici est d'isoler la partie du système qui démarre et initialise le système du reste. C'est ça l'objectif, quand tu mets à jour ta Fedora toolbox tu ne risques pas d'empêcher le démarrage de ton ordinateur ce qui rend la maintenance bien plus facile.
C'est aussi un des objectifs, de même que de faciliter la prise en compte de "j'ai un projet au boulot qui a un bogue avec Python 3.9 qui n'est pas dans les dépôts, comment m'en sortir rapidement et simplement ?".
Je pense que tu as une vue globale, ce n'est pas après une hérésie de faire ce que tu fais, je te donne juste les clés pour comprendre l'intention initiale. Après on verra, la vision bougera peut être aussi à mesure que Silverblue soit adoptée par les utilisateurs avec la variété de situations que cela implique.
[^] # Re: Vivement l'avènement de Silverblue
Posté par Psychofox (Mastodon) . Évalué à 3.
euh…les flatpaks sont aussi disponibles sur fedora workstation. Pas besoin de la silverblue.
[^] # Re: Vivement l'avènement de Silverblue
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2.
J'avais entendu ça aussi au début, mais en lisant l'article de Colin Walters, je me suis rendu compte que le terme "en lecture seule" veut seulement dire que le répertoire "/usr" doit être considéré comme dossier géré par Fedora et non pas que le système entier doit être en lecture seule.
Or, pour les RPMs distribués par Fedora, je pense qu'il n'y a pas de problème de les ajouter par dessus l'image de base fournie aussi par Fedora, non ?
Je pense ça, parce que même si mon installation s'éloigne effectivement un peu de la distribution de base, elle reste dans un état prévu par Fedora.
# sddm
Posté par jeep . Évalué à 4.
bonjour,
merci pour la news, j'ai passé le pas et pour le moment tout fonctionne bien sauf
sddm, qui se met le clavier en us au lieu de bépo, qui n'est même pas dans la liste.
si je ferme la session, c'est bon, y a du bépo.
si quelqu'un sait comment corriger ça, je suis preneur.
je pense ne pas être le seul à qui ça peut être bénéfique
Merci.
# Félicitations et merci !
Posté par Eridor . Évalué à 3.
Excellente nouvelle pour une excellente distribution !
C'est peut-être une vue de l'esprit, mais je trouve que Fedora prend du galon ces dernières années : en plus d'être à la pointe de l'innovation, la qualité finale (fiabilité, absence de problèmes majeurs, facilité d'utilisation, outils graphiques, etc.) est parmi les meilleures. De mon point de vue, devant Ubuntu qui a pourtant été la référence dans les années 2010. Fedora est LA distribution que je conseille et installe à celles et ceux qui veulent découvrir le monde de Linux.
Utilisateur depuis plus d'une décennie de Fedora, j'ai paradoxalement arrêté de l'utiliser à cause des mises à jour trop fréquentes et trop volumineuses. Même si c'est un plus pour beaucoup d'utilisateurs que Fedora puisse proposer des applications avec des versions très récentes et même des passages à la version supérieure en cours de cycle (ex. Firefox ou transmission-gtk qui est passé à la version majeure 3.00 sur Fedora 37), il faut bien admettre que recevoir une notification de Gnome-software TOUS LES JOURS pour vérifier les mises à jour en téléchargeant les méta-informations, télécharger lesdites mises à jour et redémarrer dans la foulée pour les installer, c'est barbant (enfin, surtout avec une connexion ADSL à 1 Mo/sec… :).
J'ai testé et ai été agréablement surpris par RockyLinux mais le faible nombre de paquets disponibles (même après ajout des EPEL et Flatpak) ne permet pas de faire un système qui correspond aux attentes d'un PC de bureau polyvalent.
Finalement, retour chez Debian (ça tombe bien la future version stable Bookworm est en freeze), c'est simple, ça marche mais surtout : qu'est-ce que c'est calme ! :)
Merci Fedora, merci à la diversité des distributions Linux.
[^] # Re: Félicitations et merci !
Posté par Okki (site web personnel, Mastodon) . Évalué à 4.
Dans les paramètres réseau de GNOME, t'as une option « Connexion avec quota : limite les données ou peut engendrer des frais. Les mises à jour logicielles et autres téléchargements importants ne seront pas démarrés automatiquement ».
Puis tu peux ensuite désactiver les notifications dans GNOME Logiciels.
Comme ça, à l'arrivée, tu lances les mises à jour manuellement, de toi même, quand t'en a envie.
[^] # Re: Félicitations et merci !
Posté par Olivier Jeannet . Évalué à 1.
Pour ma part je désactive toujours les mises à jour automatiques, je trouve également qu'il y en a beaucoup trop. En plus, ça ne sert à rien de mettre à jour quand tout fonctionne, et rares sont les failles qui pourraient justifier une installation immédiate.
Je fais les mises à jour de temps en temps, mais moins d'une fois par mois (j'évite de rebooter), juste pour le principe, car je ne vois aucune différence à l'utilisation.
[^] # Re: Félicitations et merci !
Posté par Psychofox (Mastodon) . Évalué à 3.
C'est quoi votre problème avec les maj automatiques? Elles se font au reboot/arrêt de toute manière. Ce n'est pas comme si vous êtes interrompus dans votre utilisation par les majs.
[^] # Re: Félicitations et merci !
Posté par Eridor . Évalué à 3.
L'intérêt n'est pas évident (tout ça pour passer de Linux-6.1.0.8 à Linux 6.1.0.9 ?…) pour une gêne non négligeable :
réseau saturé au démarrage des 3 PC sous Fedora (gnome software va chercher les nouvelles métadonnées dès le démarrage), et bien souvent cela coïncide avec le retour du petit monde à la maison, la bande passante souffre et on ne peut rien en tirer (à moins de tuer Gnome Software.)
obligation de redémarrer un fois tous les 2/3 jours : j'ai pour habitude de laisser le PC tourner en permanence en laissant toujours un nombre considérable de fenêtres ouvertes pour le boulot, le PC se met tout seul en veille (en cas d'inactivité, la nuit par exemple). Redémarrer oblige tout rouvrir/actualiser/reconnecter les fenêtres/onglets. Une fois par mois voire par semaine ça peut passer, mais tous les 2/3 jour, non.
En soit, c'est pas grave mais je pense que c'est à la machine de s'adapter à l'utilisateur, pas l'inverse. En ce sens je trouve les mises à jour fréquentes de Fedora plutôt contraignantes pour un intérêt tout relatif (même si j'entends qu'on puisse souhaiter la dernière version de machin-chose et que c'est totalement dans les objectifs affichés de Fedora).
Les notifications à ce sujet sont toujours omniprésentes et ma conscience de geek est perturbée à l'idée de ne pas faire régulièrement les mises à jour (et si ce patch comblait une CVE importante ?)
Comme propose Okki, on peut aussi ruser pour faire taire ces notifications (mises à jour disponibles / mises à jour effectuées), mais au risque de passer totalement à côté. C'est ce que fait ma compagne : pas de mises à jour faites depuis 2 mois… ça n'est pas non plus satisfaisant. x)
Et puis l'idée des mises à jour auto. en arrière plan via un service systemd sur Fedora n'est pas conseillé et me tente pas trop : comme ça bouge beaucoup au cours d'un cycle, j'ai peur de devoir faire du dépannage x3 en cas de pépin suite à une mise à jour foireuse.
Dans l'idéal on rêverait d'un paramétrage dans Gnome Software qui permette de choisir la fréquence de recherche et d'installation des mises à jour (tous les jours, tous les deux jours, toutes les semaines, tous les mois, etc.) À ce propos, Debian propose un outil bien pratique à cet effet (software-properties-gtk) :
Mais comme Fedora se veut à la pointe de la nouveauté, une telle option n'aurait que peu d'intérêt car la majorité de ses utilisateurs veut et attend les dernières versions disponibles et la fréquences des mises à jour n'est pas un problème pour eux.
Bref, mon cas d'utilisation ne colle pas avec ce que propose la distribution. Ce n'est pas un problème dans le monde Linux et on a une offre pléthorique pour trouver chaussure à son pied.
Actuellement, j'ai trouvé un compromis tout-à-fait satisfaisant avec Debian, bien qu'étant plus habitué au monde de RHEL. Mais c'est là qu'une distribution intermédiaire entre Fedora et RHEL serait bienvenue (mais ne risque pas de voir le jour car l'intérêt serait économiquement nul pour l'entreprise.)
[^] # Re: Félicitations et merci !
Posté par Okki (site web personnel, Mastodon) . Évalué à 4.
Si tu n'es pas contre les Flatpak, t'as Rocky Linux. C'est la version communautaire de RHEL créée suite à la nouvelle direction prise par CentOS. Comme ça t'as un socle stable dans le temps, qui ne devrait pas mettre à jour le noyau quotidiennement, tout en ayant des applications à jour grâce aux Flatpak.
[^] # Re: Félicitations et merci !
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 3.
Il en parle dans son premier commentaire :
[^] # Re: Félicitations et merci !
Posté par Renault (site web personnel) . Évalué à 4.
Oui et non.
Disons que c'est entre autre pour ça qu'il y a plein de distributions, chacune a une politique différente les uns des autres sur la question de fréquence des mises à jour, les logiciels à fournir et à intégrer ensemble, la fraicheur des paquets, etc. Fedora a une politique très agressive par définition, c'est son but d'avoir une bonne fraicheur des paquets.
Cela ne me choque pas que Fedora ne propose rien de spécial qui ne colle pas avec ses objectifs affichés. Comme tu le dis, le choix est suffisamment vaste pour qu'on y trouve son bonheur à ce sujet.
C'est techniquement un peu le rôle pris par CentOS Stream en fait.
[^] # Re: Félicitations et merci !
Posté par Eridor . Évalué à 2.
J'ai regardé aussi de ce côté mais on reste sur une offre très proche de RHEL et on y trouve pas plus de paquets dans se dépôts, le problème est le même que celui soulevé plus haut à propos de RockyLinux.
Après CentOS Stream est encore jeune, peut-être verra-t-on dans les prochaines années des dépôts communautaires plus étoffés se développer autour du projet pour s'approcher de ce que peut offrir Debian par exemple.
[^] # Re: Félicitations et merci !
Posté par Psychofox (Mastodon) . Évalué à 1.
Je crois que là on a plus un problème familial si dès que vous rentrez à la maison vous vous jetez sur l'ordi.
Bizarrement cette info contredit celle du-dessus.
Du reste, c'est faux, il n'y a aucune obligation de redémarrer une fois tous les 2/3 jours. Gnome Software te permet de voir ce qu'il y a dans les majs, si tu ne vois pas de choses comme la libc, le noyau, systemd t'as pas vraiment besoin de redémarrer et tu peux lancer un dnf update manuellement. Si tu as un service activé tu peux choisir de le mettre à jour manuellement et redémarrer le service manuellement. Idem si c'est une maj de navigateur.
Du reste il existe dnf automatic pour lequel tu peux filtrer et retirer les maj de trucs qui imposent un reboot.
[^] # Re: Félicitations et merci !
Posté par Olivier Jeannet . Évalué à 2.
Assez en accord avec ton commentaire. Je comprends tout à fait la gêne que tu décris (le réseau saturé, et les reboots demandés). Note que souvent on n'est en fait pas obligé de rebooter, si on n'est pas pressé de passer sur le nouveau noyau.
Quand on a connu l'informatique sans les mises à jour un peu permanentes, on n'a pas envie qu'elles se fassent en tâche de fond déjà (au moins qu'on puisse choisir de les télécharger, puis de les installer), et puis surtout 99 % du temps elles ne servent à rien (pour un usage concret), il faut en être conscient. Et même sur un serveur exposé, les failles de sécurité exploitables ne sont pas fréquentes.
Pour moi l'informatique doit en effet s'adapter à nous, pas l'inverse. Les gens sous Windows en particulier sont tellement habitués aux mises à jour et reboots imposés (surtout au bureau, je ne suis pas admin de mon poste et ça me gave, en plus ça ne rouvre pas les applications qui tournaient ou pas toutes).
On avait donné à ma mère un ancien PC portable sous Windows, mais il y avait le cercle vicieux : elle ne l'allumait pas souvent, donc à chaque fois N minutes de mises à jour, du coup elle l'allumait encore moins. Elle s'est enfin mise à l'informatique avec une tablette Apple, où il n'y avait pas toutes ces cochonneries.
Dans mon Ubuntu j'ai désactivé les mises à jour automatiques, mais j'ai laissé la "popup" qui dit qu'il y a des mises à jour disponible et qui liste des paquets.
[^] # Re: Félicitations et merci !
Posté par Dafyd . Évalué à 1. Dernière modification le 11 mai 2023 à 00:22.
Ça va Windows, c’est une fois par mois, et encore tu peux repousser. Ce qui me permets d’éviter de dépasser 30 jours d’uptime sur le laptop. Au delà, sur Windows 11, certaines choses comme l’IHM de Windows Defender ou celle des réglages système commencent à deconner.
[^] # Re: Félicitations et merci !
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
T'as de la chance de pouvoir repousser… J'ai déjà vu le PC du boulot redémarrer en pleine réunion Teams alors que dix minutes avant j'avais demandé que le redémarrage soit repoussé dans la soirée. D'ailleurs, je ne comprends pas pourquoi sur une machine qui est restée allumée toute la journée ça choisi de redémarrer en dehors des plages indiquées et même pas quand c'est en idle
Pour le une fois par mois, ici, ça ne semble concerner que les mises à jour non critiques heureusement.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Félicitations et merci !
Posté par Dafyd . Évalué à 1.
Le report des MAJ est peut être bloqué par GPO sur ton PC du boulot ?
[^] # Re: Félicitations et merci !
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Certainement ou probablement :) Je ne sais pas trop comment c'est goupillé parce-que parfois ça marche (même si je n'utilise pas systématiquement la possibilité de report, mais je crois une fois sur trois je reporte d'une heure le temps de finir un travail en cours) et parfois pas. C'est pour ça que je parlais de chance (quand on ne sait pas expliquer c'est toujours magique haha)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# MAJ RAS, tout est OK !
Posté par François Druel (site web personnel) . Évalué à 1.
Bonjour à tout.e.s,
J'ai fait la maj le 18 avril, en mode clicodrome et tout s'est passé comme sur des roulettes.
Donc pas de problème pour l'utilisateur "bureautique de base" que je ne veux pas cesser d'être.
Et d'ailleurs, c'est certainement ce qui me marque le plus : Fedora est parfaitement adapté à une utilisation par un n00b total, qui ne met jamais les pieds dans le terminal (enfin, presque : seule l'installation et la gestion de TeXLive le demande encore).
Par dessus le marché, Fedora est dans la "grande famille" IBM et c'est très rassurant.
À bientôt,
François
"Il n'y a de richesse que d'hommes" (J. Bodin) - Trésorier de l'association GUTenberg (https://www.gutenberg-asso.fr/)
# Retour d'expérience d'une migration Pop!_OS 22.04 vers Fedora SilverBlue 38
Posté par ds9 . Évalué à 2.
Je suis très content de Fedora Workstation que j'ai installé en version 36 sur un portable Asus - et mis à jour en version 37 puis 38 sans problème majeur (mis à part quelques problèmes liés à des dépôts tiers) donc j'ai décidé de remplacer Pop!_OS 22.04 par Fedora SilverBlue 38 sur mon Lenovo ThinkCentre.
Installation avec chiffrement du disque classique mais ensuite petit souci au premier démarrage : https://discussion.fedoraproject.org/t/keyboard-layout-is-always-english-when-unlocking-encrypted-drives-on-silverblue-kinoite-sericea/81095
Apparemment il n'y a pas eu de test avec des claviers non US.
Un problème existait aussi pour Fedora Workstation 36 lorsqu'on utilisait un clavier non-US.
Aucun problème par la suite : Gnome 44.1 est vraiment agréable.
J'ai utilisé Toolbox pour installer yt-dlp .
Par contre j'ai installé via rpm-ostree :
- openssl nécessaire à GsConnect
- tcpudmp pour des captures réseau - dans la Toolbox on a le message ou don't have permission to perform this capture on that device. Je ne sais pas si on peut configurer la Toolbox pour utiliser ce genre de programmes.
- autofs pour monter les partitions CIFS de mon NAS - avec montage dans /var (les autres répertoires /media & /mnt ne marchent pas) - Utiliser /var est
problématique pour les applications disponibles via Flatpak - gThumb notamment - qui n'ont pas accès à /var. Du coup j'ai contourné le problème avec un ln -s /var/nas $HOME/nas
- gnome-tweaks pour changer des options de Gnome
Comme à chaque version de Gnome, des extensions ne sont pas encore compatibles.
Côté Flatpak, j'ai eu des applications qui n'ont pas fonctionné du tout car j'ai installé les versions Fedora Linux (choix par défaut) et non Flathub : Secrets, KeepassXC et Audacious.
On a vraiment l'impression que les Flatpak Fedora Linux ne sont pas testés avant la publication. Un point à améliorer.
A l'arrivée je suis satisfait même si utiliser Toolbox pour avoir d'autres outils donne l'impression de devoir gérer les mises à jour sur 2 systèmes.
Côté bugs que j'ai encore :
- crash régulier de nautilus quand on utilise la fonction rechercher - un segfault juste après un g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
- Gthumb en Flatpak ne permet pas de lancer gnome-terminal : var/run/host/usr/bin/gnome-terminal: error while loading shared libraries: libvte-2.91.so.0: cannot open shared object file: No such file or directory . Ce n'est pas la faute de Fedora mais plutôt du Flatpak.
# Commentaire supprimé
Posté par 31121 . Évalué à -2. Dernière modification le 11 mai 2023 à 13:40.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.