Fedora Linux 40 Beta est disponible pour les tests

Posté par  (site web personnel) . Édité par Arkem. Modéré par Ysabeau 🧶 🧦. Licence CC By‑SA.
Étiquettes :
33
25
mar.
2024
Fedora

En ce mardi 26 mars, la communauté du Projet Fedora sera ravie d'apprendre la disponibilité de la version Beta de Fedora Linux 40.

Malgré les risques concernant la stabilité d’une version Beta, il est important de la tester ! En rapportant les bogues maintenant, vous découvrirez les nouveautés avant tout le monde, tout en améliorant la qualité de Fedora Linux 40 et réduisant du même coup le risque de retard. Les versions en développement manquent de testeurs et de retours pour mener à bien leurs buts.

La version finale est pour le moment fixée pour le 16 ou 23 avril.

Sommaire

Expérience utilisateur

  • Passage à GNOME 46 ;
  • L'environnement de bureau KDE Plasma change de version majeure avec sa nouvelle version 6 ;
  • Le fichier firefox.desktop est renommé en org.mozilla.firefox.desktop pour permettre son utilisation dans la barre de recherche de GNOME.

Gestion du matériel

  • Fourniture de ROCm 6 pour améliorer la prise en charge de l'IA et le calcul haute performance pour les cartes graphiques AMD ;
  • Passage à l'étape 2 de la prise en charge du noyau unifié 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.

Internationalisation

  • Le gestionnaire d'entrée de saisie IBus passe à la version 1.5.30 ;
  • Mise à jour de ibus-anthy 1.5.16 pour la saisie du japonais.

Administration système

  • NetworkManager tente de détecter par défaut les conflits d'usage d'adresse IPv4 avec le protocole Address Conflict Detection avant de l'attribuer à la machine ;
  • NetworkManager va utiliser une adresse MAC aléatoire par défaut pour chaque réseau Wifi différent, et cette adresse sera stable pour un réseau donné. Cela permet de concilier vie privée et confort d'utilisation ;
  • Les unités système de systemd vont utiliser par défaut beaucoup d'options pour améliorer la sécurité des services ;
  • Les entrées des politiques SELinux qui font référence au répertoire /var/run font maintenant référence au répertoire /run ;
  • L'outil SSSD ne prend plus en charge les fichiers permettant de gérer les utilisateurs locaux ;
  • DNF ne téléchargera plus par défaut la liste des fichiers fournie par les différents paquets ;
  • L'outil fwupd pour mettre à jour les firmwares va utiliser passim comme cache pour partager sur le réseau local les métadonnées liées aux mises à jour disponibles pour les firmwares ;
  • Les systèmes Fedora Silverblue et Kinoite disposent de bootupd pour la mise à jour du chargeur de démarrage ;
  • Le paquet libuser est marqué en voie de suppression pour Fedora 41 alors que le paquet passwd est supprimé ;
  • Le paquet cyrus-sasl-ntlm a été supprimé ;
  • La gestion des droits utilisateurs pam_userdb passe de la base de données BerkeleyDB à GDBM ;
  • Le filtre antispam bogofilter utilise SQLite au lieu de BerkeleyDB pour gérer sa base de données interne ;
  • Le serveur LDAP 389 passe de la version 2.4.4 à la version 3.0.0 ;
  • Le paquet iotop est remplacé par iotop-c ;
  • L'orchestrateur de conteneurs Kubernetes évolue de la version 1.28 à la version 1.29 ;
  • Par ailleurs ses paquets sont restructurés ;
  • Pendant que podman est mis à jour vers la version 5 ;
  • Le paquet wget2 remplace le paquet wget en fournissant une nouvelle version ;
  • Le gestionnaire de base de données PostgreSQL migre vers sa 16e version ;
  • Les paquets MySQL et MariaDB sont remaniés et mis à jour vers la version 10.11.

Développement

  • Mise à jour de la suite de compilation GNU : GCC 14.0, binutils 2.41, glibc 2.39 et gdb 14.1 ;
  • La suite de compilateurs LLVM est mise à jour à la version 18 ;
  • Mise à jour de la bibliothèque C++ Boost à la version 1.83 ;
  • Le langage Go passe à la version 1.22 ;
  • Le JDK de référence pour Java passe de la version 17 à 21 ;
  • Mise à jour du langage Ruby 3.3 ;
  • Le langage PHP utilise la version 8.3 ;
  • La boîte à outils pour le machine learning PyTorch fait son entrée dans Fedora ;
  • Le paquet python-sqlalchemy utilise la nouvelle branche majeure 2.x du projet, le paquet python-sqlalchemy1.4 est proposé pour garder la compatibilité ;
  • La bibliothèque de validation des données Pydantic utilise dorénavant la version 2 ;
  • La bibliothèque Thread Building Blocks passe du fil 2020.3 au fil 2021.8 ;
  • La bibliothèque OpenSSL 1.1 est supprimée ne laissant que la dernière version de la branche 3.x ;
  • Les bibliothèques zlib et minizip utilisent leur variante zlib-ng et minizip-ng dorénavant ;
  • Le langage Python ne bénéficie plus de la version 3.7.

Projet Fedora

  • L'édition Cloud sera construite avec l'utilitaire Kiwi dans Koji ;
  • Tandis que l'édition Workstation aura son ISO générée avec l'outil Image Builder ;
  • L'image minimale ARM sera construite avec l'outil OSBuild ;
  • Fedora IoT bénéficiera d'images Bootable Containers ;
  • Il bénéficiera également des images Simplified Provisioning ;
  • Et le tout sera construit en utilisant rpm-ostree unified core ;
  • Fedora sera construit avec DNF 5 en interne ;
  • Les macros forge passent du paquet redhat-rpm-config à forge-srpm-macros ;
  • La construction des paquets échouera si l'éditeur de lien détecte certaines classes de vulnérabilité dans le binaire en construction ;
  • Phase 3 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 ;
  • Clap de fin pour la construction des mises à jour au format Delta RPM ;
  • Suite du projet de ne générer les JDKs qu'une fois, et les rempaqueter ainsi à toutes les variantes du système ;
  • Compilation des paquets en convertissant plus d'avertissements comme erreurs lors de la compilation des projets avec le langage C ;
  • Les images immuables comme Silverblue seront nommées sous la dénomination Atomic pour éviter la référence au terme immuable qui est confus pour les utilisateurs.

Tester

Durant le développement d'une nouvelle version de Fedora Linux, comme cette version Beta, quasiment chaque semaine le projet propose des journées de tests. Le but est de tester pendant une journée une fonctionnalité précise comme le noyau, Fedora Silverblue, la mise à niveau, GNOME, l’internationalisation, etc. L'équipe d'assurance qualité élabore et propose une série de tests en général simples à exécuter. Il suffit de les suivre et indiquer si le résultat est celui attendu. Dans le cas contraire, un rapport de bogue devra être ouvert pour permettre l'élaboration d'un correctif.

C'est très simple à suivre et requiert souvent peu de temps (15 minutes à une heure maximum) si vous avez une Beta exploitable sous la main.

Les tests à effectuer et les rapports sont à faire via la page suivante. J'annonce régulièrement sur mon blog quand une journée de tests est planifiée.

Si l'aventure vous intéresse, les images sont disponibles par Torrent ou via le site officiel.

Si vous avez déjà Fedora Linux 39 ou 38 sur votre machine, vous pouvez faire une mise à niveau vers la Beta. Cela consiste en une grosse mise à jour, vos applications et données sont préservées.

Nous vous recommandons dans les deux cas de procéder à une sauvegarde de vos données au préalable.

En cas de bogue, n'oubliez pas de relire la documentation pour signaler les anomalies sur le BugZilla ou de contribuer à la traduction sur Weblate. N'oubliez pas de consulter les bogues déjà connus pour Fedora 40.

Bons tests à tous !

Aller plus loin

  • # À la découverte de Silverblue

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

    Je suis en train de découvrir Silverblue 40, une version immuable de Fedora.

    Il y a encore quelques bugs qui sont gênants, mais je trouve le système très intéressant. Le fait que tout soit conteneur, effectivement, ça signifie que le système et les applications prennent souvent plus de places, mais c'est très pratique pour mettre en place un environnement de développement qui n'affecte pas le reste du système. Après, ça signifie que certaines applications ont du mal à fonctionner.

    Et l'installation d'une application flatpak (format privilégié par Silverblue) est un peu déroutante, car, une fois que c'est téléchargé, ben c'est installé.

    • [^] # Re: À la découverte de Silverblue

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

      C'est parfait pour une utilisation simple, bureautique et autres grand-mères. Le système se met à jour tout seul et c'est extrêmement robuste.

      Par contre, je déconseille pour les power-users. La "toolbox" ne remplace pas bien le fait de pouvoir installer ses paquets à la main.

      • [^] # Re: À la découverte de Silverblue

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

        Oui j'ai silverblue sur un de mes laptops. Toolbox c'est bien mais j'utilises rpm-ostree bien plus souvent que je ne le voudrais.

        Ce serait plus adapté sur la machine que j'utilise comme media center où sur le pc que je prête des fois à mes enfants.

      • [^] # Re: À la découverte de Silverblue

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

        Ah oui ? étant en train de découvrir la distribution, je suis intéressé par les différentes limites et difficultés dues à l'utilisation de conteneurs et de Toolbox.

        Je me disais qu'au contraire, pour les utilisateur⋅es avancé⋅es, c'était hyper intéressant les conteneurs.

        Puis, il doit y avoir moyen de les partager ? par exemple, si j'utilise une application comme Lutris et Wine pour faire fonctionner des logiciels Windows, on doit pouvoir créer et partager des conteneurs dédiés par logiciel (bon, c'est déjà un peu ce que fait Lutris).

        Idem, si j'ai un environnement de développement particulier, je peux facilement le partager à d'autres personnes, et par exemple mettre en place des outils et des configurations identiques pour toute une équipe par exemple. C'est évidemment faisable via Ansible également, mais peut-être pas aussi simple.

      • [^] # Re: À la découverte de Silverblue

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

        Je trouve que l'édition de base est devenu très robuste donc j'ai du mal à comprendre l'apport pour les grands-mères

        • [^] # Re: À la découverte de Silverblue

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

          En moyenne c'est assez stable, mais des problèmes il y en a toujours. En particulier lors des mises à niveau.

          • [^] # Re: À la découverte de Silverblue

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

            Même sans parler des mises à jours de version, je peux donner des exemples (et même des exemples qui n'impliquent pas de dire qu'une femme plus âgée est moins compétente que la moyenne).

            Par exemple, à l'époque ou je faisait le support sur le terrain pour des commerciaux, j'avais régulièrement des gens qui venaient avec un laptop sous RHEL incapable de booter. J'ai fini par diagnostiquer ça comme étant le symptôme d'un reboot pendant les mises à jours.

            J'ai constaté que mes collègues du département Vente avait la bonne habitude de lancer les mises à jour en tache de fond, puis d'oublier l’existence des dites mises à jour en cours et soit de tomber soit en panne de courant, soit d'éteindre le PC. Avec assez de monde et assez de mises à jours, ça finit par arriver.

            Normalement, RPM est assez solide pour survivre à ça dans le sens ou sur une RHEL, ça devrait pas rendre la machine indémarrable. Il faut parfois repasser en root et faire du nettoyage pour finir la transaction, etc, donc passer du temps, mais c'est pas bloquant.

            Par contre, il y a un rpm qui a un souci avec ça, c'est le kernel, car le kernel sur RHEL, il a 2 scripts de post installation. Un script en %post et un en %posttrans. Quand tu installes le rpm, il lance le script en %post, qui va modifier la config grub, et rajouter le nouveau kernel et initrd. Quand tu as fini d'installer tout les autres paquets, le script %posttrans (pour post transaction, la transaction étant l'installation de tout les paquets comme dans un SGBD) va lancer la création de l'initrd. C'est fait après l'installation pour être sur d'avoir tout les fichiers à jour après la mise à jour. Par exemple, si il y a une mise à jour de bash et du kernel, tu veux avoir le dernier bash dans l'initrd, pour éviter les bugs ou les soucis de sécu corrigé par une mise à jour de bash.

            Sauf que, si tu coupes la mise à jour en cours, tu te retrouves avec la config de grub modifié, mais pas l'initrd correspondant, et donc au reboot, le choix de kernel de grub est non fonctionnel vu qu'il pointe vers un initrd qui n'est pas encore sur le disque, donc ça coince.

            Alors il y a plusieurs correctifs possibles. Mettre l'ajout du kernel dans la config grub dans le scipt %posttrans après la création de l'initrd. Faire en sorte que grub soit moins con et vérifie la présence des fichiers et bascule sur un choix par défaut. Faire l'initrd 2 fois, dans le %post et le %posttrans. Ou utiliser ostree.

            Car en effet, tout le probléme disparaît avec ce genre de systèmes. Les mises à jours sont téléchargés en entier avant d'être appliquées d'un coup au reboot. Si tu coupes le téléchargement, rien de dramatique se passe et ça peut reprendre plus tard. Si ça ne démarres pas, tu peux automatiquement revenir en arrière (en théorie).

            Et ça, c'est sur une RHEL, ou les questions de mises à jours majeurs de rpms ne se posent pas trop, en tout cas pas sur la durée d'usage des portables comparée à la durée de vie de la distro.

            • [^] # Re: À la découverte de Silverblue

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

              Oui bien sûr, mais au delà de ça, des mises à jour classiques qui rendent le boot non fonctionnel chez Fedora sans que cela ne soit sous le contrôle de l'utilisateur car tout est allé au bout de la procédure, cela arrive, ce ne sont pas les rapports de bogues ou les questions sur le forum qui diront le contraire. Car il y a toujours des configurations logicielles et matérielles qui rendent ces étapes difficiles à garantir pour tout le monde, et avec suffisamment d'utilisateur il y en a toujours qui de temps en temps ont un pépin.

              Donc avoir la possibilité de revenir à un état stable de manière immédiate c'est vraiment cool.

              • [^] # Re: À la découverte de Silverblue

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

                Dans les faits je ne me suis jamais trouvé dans une situation où je ne pouvais pas booter avec le noyau précédent.

                Et par défaut la fedora avec gnome-software va télécharger et uniquement faire la maj au redémarrage où le proposer à l'arrêt. Le seul truc chiant, c'est que si tu n'utilises pas tpm ou un stockage usb pour ta clé de chiffrement tu dois te la taper à la main une fois supplémentaire. À vrai dire c'est le seul gros avantage que je ressents à l'usage sur le laptop qui a la silverblue par rapport aux autres pc qui ont la fedora standard.

    • [^] # Re: À la découverte de Silverblue

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

      c'est très pratique pour mettre en place un environnement de développement qui n'affecte pas le reste du système.

      À condition de lancer pip/npm/etc en root, car si tu passes par toolbox (qui est l'outil de moindre résistance), tu va partager le /home. Je suppose que ça dépend de ce que tu appelles "environnement de développement", vu que ça va des compilos aux config des éditeurs de code en passant par les libs dispos.

      Après, ça signifie que certaines applications ont du mal à fonctionner.

      Le fait de ne pas pouvoir facilement lancer tcpdump ou des outils bas niveau de ce genre dans un conteneur (notamment celui de toolbox) font que je pense que je repasserait sur une distro normal pour mon prochain PC.

      Je peux avoir toolbox et flatpak sur une Fedora normale, donc le seul avantage, c'est le système en read-only, et j'ai pas le sentiment que ça m'apporte assez pour justifier les limitations que j'ai constaté. Je sais que je peux faire un rpm-ostree install --live, mais je sais aussi que le dev upstream voit ça comme un hack qui va contre la vision du déploiement par image. C'est assez clairement écrit dans la doc de bootc, et j'attends de voir comment tout va se mettre en place en pratique avant de repartir pour 3/4 ans avec ce genre d'OS sur mon portable pro.

      • [^] # Re: À la découverte de Silverblue

        Posté par  (site web personnel) . Évalué à 5 (+2/-0).

        Cela ne m'étonnerait pas que dans le futur on ajoute une couche de plus pour apporter la flexibilité manquante, avoir quelque chose du genre :

        • Système minimal avec rpm-ostree : chargeur de démarrage, noyau, systemd, bibliothèques de base, environnement de bureau et écran de login (pas plus) ;
        • Système classique pour installer des paquets en plus, plutôt orientés utilitaires ou outils bas niveaux pour le développement ou les systèmes qui à priori ne compromettent pas le boot et pour qui l'isolation ne fonctionne pas bien ;
        • Flatpak pour les applications graphiques ;
        • Conteneurs avec toolbox pour ceux qui veulent des environnements de développement plus flexibles que ce qui est proposé par Fedora, notamment concernant les versions des langages de programmations et des outils associés.

        Cela serait cohérent avec la conception derrière et dans la continuité de Fedora.next en un sens. Si jamais du moins aucune solution satisfaisante n'est trouvée autrement.

      • [^] # Re: À la découverte de Silverblue

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

        les rpm-ostree install --live ou apply-live ne fonctionnent pas toujours si tu as eu déjà d'autres transactions donc des fois t'es quand même obligé de rebooter et ça énèèèrve.

      • [^] # Re: À la découverte de Silverblue

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

        À condition de lancer pip/npm/etc en root, car si tu passes par toolbox (qui est l'outil de moindre résistance), tu va partager le /home. Je suppose que ça dépend de ce que tu appelles "environnement de développement", vu que ça va des compilos aux config des éditeurs de code en passant par les libs dispos.

        C'est un des points que je ne comprends pas bien.

        Pour moi, mes contraintes niveau environnement de dev python, c'est de pouvoir avoir des versions de bibliothèques différentes d'un projet à l'autre. Et faire varier les versions de Python. Donc, des choses qui sont gérables via pipenv et poetry.

        • [^] # Re: À la découverte de Silverblue

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

          Oui, mais du coup, pipenv et co, ça marche sans silverblue, non ?

          Du coup, je pige pas quel est l'apport pour ton workflow, à part d'être sur que tu installes rien en root par erreur.

          • [^] # Re: À la découverte de Silverblue

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

            En fait, je me disais que Podman me permettrait de me passer de pipenv et co. Tout simplement, parce que j'aime pas ces outils, y'a toujours un moment où je me mélange les pinceaux. Ce qui est probablement dû au fait que la programmation n'est pas mon activité principale.
            Je me disais aussi que ça serait plus facilement de partager des conteneurs d'un projet à l'autre. Combiné avec l'idée que c'est faisable d'avoir un système d'exploitation aux oignons en fonction des activités qui ont des contraintes particulières. Dev => image dev, Montage video => image video, jeux video => image-système dédié.
            Et, si dans quelques temps je dirige une équipe de chercheur⋅es et d'assistant⋅es, je me dis que Silverblue me permettrait plus facilement de partager un environnement de travail consistant d'un ordinateur à l'autre, que les gens auront plus de difficultés à casser que dans un environnement plus traditionnel, qu'avec Ansible.

            Pour le moment, Silverblue, c'est surtout une exploration de mon côté, voir ce que ça donne, permet etc, et je me projette sur ces possibles utilisations.

            Bref, pour le moment, j'essaie déjà d'avoir oh-my-zsh qui fonctionne correctement…

    • [^] # Re: À la découverte de Silverblue

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

      J'utilise Silverblue au quotidien sur mes portables pro et perso depuis 2 ans maintenant.
      Auparavant, je me servais de Fedora Workstation.

      Elle couvre parfaitement tous mes besoins avec Flatpack et Toolbox.

      VScode est installé dans toolbox. Je le lance en ligne de commande et ça fonctionne nickel.
      Il m'a simplement fallu faire cette manip pour pouvoir lancer le navigateur depuis les liens de vscode:

      1/ Installer flatpak-xdg-utils dans toolbox
2/ Créer un lien symbolique depuis /usr/bin/xdg-open à /usr/bin/flatpak-xdg-open

      Toolbox c'est un régal pour obtenir un environnement cloisonné indépendant des montées de version de l'OS.
      Parallèlement mes bases de données sont stockées dans des containers podman.

      J'ai désinstallé Firefox de rpm-ostree et installé la version fournie par Flathub pour les codecs proprios.

      L'ergonomie de Gnome est parfaite avec qq extensions. Juste dommage qu'il n y ait pas un systray officiel parfaitement intégré.
      Les périphériques fonctionnent bien.

      Les partages d'écran avec Wayland soient parfois foireux (relancer plusieurs fois le partage).

      Mais c'est vraiment une distribution merveilleuse aussi bien pour les power users que les autres. Je n'ai jamais de plantage.

      Juste des soucis de surchauffe de mon thinkpad X1 sur batterie :( que j'ai pu remédier en partie en bricolant des paramètres. Mais c'est une autre histoire.

    • [^] # Re: À la découverte de Silverblue

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

      C'est marrant, cette mode des "Linux immuables" me fait penser à des PC Ordissimo, ou EasyGate de NeufCegetel (je me rappelle qu'il y avait un système astucieux de double partition de démarrage, et les MàJ se faisaient toujours sur l'autre partition, et quand tout était prêt, ça changeait le démarrage dans lilo et comme ça c'était toujours propre, ça switchait de l'un à l'autre à chaque MàJ), ou même les Linux sur CD-Rom ou clé USB démarrable qui étaient à la mode à une époque…

  • # gnome-software

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

    Assez content de fedora workstation aussi, mais j'ai régulièrement des problèmes avec gnome-software, qui n'affiche pas les logiciels disponibles.

    Au démarrage de gnome j'ai aussi des demandes intempestives de mot de passe (après le login).

    A priori ces problèmes sont plutôt côté upstream gnome, mais c'est assez frustrant au quotidien.

    • [^] # Re: gnome-software

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

      Au démarrage de gnome j'ai aussi des demandes intempestives de mot de passe (après le login).
      Pareil. À un moment, je me suis demandé si ça n'était pas lié à Firefox (vu que c'est presque toujours la première chose que je lance après le démarrage ; en fait, mon PC est une machine à faire du Firefox, en vrai), qui débloquerait un accès trousseau, ou quelque chose comme ça.

      • [^] # Re: gnome-software

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

        L'analyse a semble-t-il progressé depuis la dernière fois que j'ai regardé. Il semble que ce soit lié à Flatpak dans gnome-software :

        https://bugzilla.redhat.com/show_bug.cgi?id=2244876

        Pas sûr que quelqu'un ait remonté l'info à l'équipe upstream Flatpak cependant. Je le ferai peut-être quand j'aurai du temps, si personne ne le fait entre-temps.

    • [^] # Re: gnome-software

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

      Personnellement, j'ai toujours trouvé l'application GNOME Software atrocement lente au point de l'avoir tout simplement désinstallée à chaque fois. Je désinstalle aussi le démon packagekitd, qui périodiquement se mettait à faire chauffer l'ordinateur en prenant beaucoup de CPU, et dont je suppose qu'il est à la racine de la lenteur de GNOME Software. J'installe tout en ligne de commande avec dnf et flatpak.

      • [^] # Re: gnome-software

        Posté par  (site web personnel, Mastodon) . Évalué à 3 (+1/-0).

        Avec Debian et le backend packagekit pour apt, Gnome Software est beaucoup plus réactif que sur Fedora.

        En fait, dnf est vraiment très lent comparé à apt, c'est le point qui me chagrine le plus avec Fedora…

Envoyer un commentaire

Suivre le flux des commentaires

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