Fedora 31 est sortie !

47
30
oct.
2019
Fedora

En ce mardi 29 octobre 2019, les utilisateurs et les utilisatrices du projet Fedora seront ravis d’apprendre la disponibilité de la version 31 de Fedora.

Fedora est une distribution GNU/Linux communautaire développée par le projet Fedora et sponsorisée par Red Hat (récemment acquise par IBM), qui lui fournit des développeurs ainsi que des moyens financiers et logistiques. Fedora peut se voir comme une sorte de vitrine technologique pour cette multinationale, c’est pourquoi elle est prompte à inclure des nouveautés.

Fedora garde un rôle central dans le développement de ces nouveautés via le développement en amont. En effet, les développeurs de la distribution contribuent également directement au code d’un certain nombre de logiciels libres contenus dans la distribution, dont le noyau Linux, GNOME, NetworkManager, PackageKit, PulseAudio, X.Org, systemd, la célèbre suite de compilateurs GCC, etc. Suivez ce lien pour voir l’ensemble des contributions de Red Hat.

Sommaire

Expérience utilisateur

Passage de l’environnement par défaut GNOME à la version 3.34

Cette version apporte de nombreux changements :

  • la création de groupes d’applications dans l’overview a été simplifiée et est plus intuitive ;
  • les processus de rendus Web du navigateur Epiphany sont maintenant dans des bacs à sable pour plus de sécurité ; par ailleurs, les onglets peuvent être épinglés et le bloqueur de pub est plus performant ;
  • le gestionnaire de machines virtuelles Machines peut activer ou désactiver l’accélération du rendu 3D pour chaque machine virtuelle, il accepte de démarrer un média temporaire, comme un CD autonome, pour réparer la machine virtuelle, et dispose d’une interface de création de machines virtuelles plus complète ;
  • le panneau de configuration du fond d’écran a été remanié pour visualiser la configuration actuelle et permet d’ajouter facilement de nouvelles images dans la liste ;
  • l’application Musique vérifie automatiquement la présence de nouveaux morceaux dans le répertoire personnel et permet de lire un album en entier sans coupure entre les morceaux ; les albums conçus ainsi peuvent être écoutés comme un tout cohérent ;
  • certaines applications ont reçu une nouvelle icône pour avoir un style plus moderne.

Nouveau panneau de configuration des fonds d’écran de GNOOME

La roue tourne pour Xfce avec la version 4.14

Après plus de quatre années de développement, cette version propose de nombreux changements. Le portage vers GTK+ 3 et GDBus est terminé, ce qui permet la prise en charge native des écrans à haute résolution (HiDPI). Cela apporte en outre :

  • la gestion de la synchronisation verticale pour le rafraîchissement de l’écran ;
  • les barres du bureau disposent d’un meilleur regroupement des applications dans la liste des applications ouvertes, tout comme une horloge retravaillée et la possibilité d’avoir des tailles d’icônes différentes entre les différentes barres ;
  • la prise en charge des différents profils de couleurs pour permettre un calibrage des couleurs entre l’écran et différents périphériques, comme une imprimante ;
  • la configuration du multi‐écran peut être sauvegardée et restaurée, et est spécialement conçue pour ceux qui ont un ordinateur portable avec un dock ;
  • le navigateur de fichiers Thunar dispose d’une nouvelle barre d’adresse ;
  • un nouveau thème et un mode « ne pas déranger » pour désactiver temporairement les notifications sont aussi de la partie ;
  • et tant d’autres.

Bureau Xfce 4.14
Nouveau panneau de configuration des profils de couleurs pour Xfce

Mise à jour de l’environnement de bureau DeepinDE 15.11

Depuis la version 15.9 disponible dans Fedora 30, les améliorations sont :

  • une moindre consommation mémoire et plus de performances pour le gestionnaire de fenêtres ;
  • les fichiers du bureau peuvent être automatiquement regroupés par type dans des répertoires comme Musiques ou Vidéos ;
  • le fond d’écran peut être une collection d’images affichées les unes après les autres ;
  • les sons système peuvent être activés ou désactivés individuellement ;
  • l’icône de charge de batterie peut révéler au survol la capacité et l’autonomie restante ;
  • l’application de lecture vidéo accepte le glisser‐déposer d’un fichier de sous‑titres pour les afficher ;
  • le navigateur de fichiers peut graver des CD et DVD ;
  • et beaucoup d’autres corrections.

Bureau Deepin avec nouvel indicateur de batterie

État du clavier dans Plymouth pour la saisie de mots de passe

Plymouth indique au démarrage des informations sur l’état du clavier lors de la saisie du mot de passe pour déchiffrer les partitions. Si vous chiffrez vos partitions pour améliorer la sécurité de vos données, vous aurez constaté qu’il y a un mot de passe à saisir au démarrage de la machine pour accéder à son contenu. Plymouth, qui récupère ce mot de passe, affiche maintenant la disposition clavier utilisée et si le verrouillage majuscule est actuellement actif. Cela permet à l’utilisateur qui n’a pas de possibilité de vérifier comment son clavier est configuré d’avoir cette information lors de la saisie.

Plymouth et le nouvel indicateur de clavier pour déverrouiller les partitions chiffrées

Firefox utilise Wayland nativement par défaut avec GNOME

L’activation de Wayland dans Firefox permet d’améliorer la gestion des ressources dans un tel cas, XWayland n’étant plus nécessaire par défaut. Firefox devrait bénéficier d’une expérience plus fluide et plus cohérente, en particulier pour les écrans à haute densité de pixels qui seront correctement pris en charge. Le paquet firefox-x11 reste à disposition pour utiliser Firefox avec X11 comme avant.

Utilisation de Wayland avec les applications Qt sous GNOME

Les applications Qt utiliseront de manière analogue Wayland lors d’une session GNOME sous Wayland. Les mêmes bénéfices que pour Firefox sont à attendre. En réalité, GNOME était le seul bureau où les applications Qt se comportaient ainsi, car le module Qt Wayland n’était pas activé pour une telle session. En effet, le gestionnaire de fenêtres de GNOME, Mutter, demande aux applications qu’elles gèrent elles‑mêmes la decoration de leurs fenêtres (Client‑Side Decorations), ce qui n’était pas possible avec Qt jusqu’ici. Les décorations de fenêtres proviennent du programme QGnomePlatform.

Compression zstd dans les paquets RPM

Les paquets RPM utilisent le format de compression zstd au lieu de xz. Le temps de décompression est plus rapide d’un facteur trois ou quatre pour le paquet Firefox, par exemple. La taille d’un paquet sera aussi sensiblement plus faible. En contrepartie, la génération d’un paquet est légèrement plus longue. Les opérations d’installation ou de mise à jour des paquets seront plus rapides et le projet Fedora économisera également un peu de bande passante pour fournir ces paquets aux utilisateurs.

Gestion du matériel

Fedora abandonne l’architecture x86 32 bits

Le noyau Linux i686 n’est plus généré et les dépôts associés sont également supprimés. De fait, il n’y aura plus d’images amorçables de Fedora pour cette architecture, ni de mise à niveau possible depuis Fedora 30 pour ces installations. Des paquets i686 peuvent subsister dans les dépôts à destination des utilisateurs ayant l’architecture x86-64 uniquement.

Cela résulte d’un processus amorcé depuis Fedora 27 où cette architecture était une architecture dite secondaire, c’est‑à‑dire avec une maintenance minimale et qui ne pouvait pas bloquer la procédure de sortie d’une nouvelle version de Fedora. Cette architecture qui était finalement assez peu utilisée ces derniers temps, avec environ 1 % des utilisateurs, souffrait de nombreux bogues, souvent découverts et corrigés tardivement faute de testeurs et de développeurs pour identifier et corriger ces problèmes.

Le projet espère ainsi libérer des ressources matérielles, en espace disque et bande passante, mais aussi humaines, pour se concentrer sur les autres architecture plus émergentes comme AArch64. Les utilisateurs concernés sont invités, soit à utiliser une image x86-64, si leur matériel le leur permet, soit à envisager de changer de distribution d’ici la fin du support de Fedora 30.

Xfce sur architecture AArch64

Le spin Xfce de Fedora dispose d’une image pour l’architecture AArch64. L’objectif est de fournir par défaut un environnement de bureau plus léger ne nécessitant pas l’accélération matérielle. L’usage de Fedora pour les ordinateurs monocartes exploitant cette architecture, et qui ont souvent une configuration matérielle moins puissante, s’en trouvera facilité.

Prise en charge des modules de sécurité lors d’un amorçage UEFI sécurisé

Sur les machines avec la fonctionnalité Secure Boot de l’UEFI activée, GRUB inclut maintenant les modules de sécurité. Les modules concernés sont verify, cryptodisk et luks. En effet, Secure Boot, par conception, ne permet pas à GRUB de charger des modules externes, ce qui était paradoxal car les modules de chiffrement des partitions n’étaient pas disponibles pour ces utilisateurs.

Internationalisation

Subdivision des paquets langpacks

Les paquets langpacks sont subdivisés avec une partie langpacks-core qui ne propose que la police par défaut et la localisation (locale) correspondante. Les polices additionnelles, tout comme les traductions complètes, comme celle de LibreOffice, nécessitent l’installation du paquet langpack correspondant. L’utilisateur a donc plus de flexibilité à ce niveau pour bénéficier d’un prise en charge minimale d’une langue.

Mise à jour d’IBus en version 1.5.21

La version 1.5.21 d’IBus repousse les raccourcis de composition de 7 touches à 255 touches. De plus, IBus permet maintenant l’écriture de caractères représentés par quatre octets au lieu de deux octets jusqu’ici. Il rejoint ainsi X11 en termes de possibilités de saisie.

Priorisation des polices de caractères variables Google Noto

Les polices Google Noto variables auront maintenant la priorité sur les polices non variables du même fournisseur. Une police variable est un fichier de police de caractères qui contient le dessin de base des caractères avec les éléments permettant de générer des variations de ces dessins, comme le gras ou l’italique. Alors qu’une police non variable contient un fichier complet par variation de ce type. Le rapport d’espace disque nécessaire varie d’un facteur 4 à 10 en faveur de la police variable, d’où ce choix.

Administration système

Fedora aime Python

Python 3 par défaut

Le binaire /usr/bin/python fait dorénavant référence à Python 3 et non plus à Python 2. En effet, Python 2 ne sera plus supporté par le projet officiel en janvier 2020. Le projet Fedora respecte donc la PEP 394 pour entamer cette transition. En cas de problèmes, vous pouvez créer le lien symbolique de ~/.local/bin/python, pour un utilisateur, ou de /usr/local/bin/python, pour le système entier, vers /usr/bin/python2 afin de restaurer le comportement historique.

Le nom des paquets suit également ce nouveau schéma, le paquet python-requests installera par exemple la version compatible Python 3 de ce paquet. Il faudra nommer spécifiquement python2-requests pour préciser le paquet compatible avec Python 2 de ce module.

De plus, il y a une suppression massive de paquets Python 2 pour ne garder essentiellement que les derniers projets non convertis à Python 3 aujourd’hui. Seuls les paquets nécessitant Python 2 qui n’ont pas une version Python 3, ou qui sont une dépendance à de tels paquets, sont conservés. Cela réduit la tâche de maintenance nécessaire après janvier 2020 et permet d’amorcer la transition en plusieurs étapes.

Les mainteneurs du projet Fedora continueront à maintenir Python 2 dans Fedora 30 et 31 jusqu’à leurs fins de vie respectives, c’est‑à‑dire vers juin et décembre 2020. Python 2 sera, en revanche, totalement supprimé pour Fedora 32. Cette décision permet de garder une compatibilité fonctionnelle importante au sein d’une même version de Fedora.

Amélioration des politiques de sécurité

La fonction des politiques de sécurité offre maintenant la possibilité aux administrateurs de personnaliser les règles comme le choix des protocoles et les algorithmes de sécurité utilisables ou non sur le système. Cette fonctionnalité, introduite peu à peu dans Fedora ces dernières années, permet aux administrateurs de configurer de manière globale et centralisée la sécurité du système. Avec ce changement, il est possible de bannir globalement l’utilisation des fonctions de hachage SHA1 et MD5 ou d’exiger au minimum TLS 1.3.

Passage aux cgroups 2

Le noyau propose les cgroups 2 au lieu de la version 1 utilisés jusqu’alors. Cette version 2 est disponible dans le noyau de manière stable depuis près de trois ans déjà, mais elle n’était pas assez éprouvée par l’espace utilisateur. Elle corrige les défauts de jeunesse de cgroups v1 en éliminant des comportements étranges, comme des fils d’exécution d’un processus qui sont dans des cgroups différents, a une API plus claire et propre, et une hiérarchie unifiée.

Les projets systemd ou les outils de conteneurisation comme Docker ou Podman sont particulièrement concernés. D’ailleurs, pour Docker, il est nécessaire de passer l’argument systemd.unified_cgroup_hierarchy=0 au noyau pour qu’il continue de fonctionner.

OpenSSH refuse par défaut l’authentification par mot de passe au super‑utilisateur

OpenSSH refuse par défaut les identifications par mot de passe pour le compte super‑utilisateur. Cela ne fait que suivre la configuration par défaut du projet officiel depuis 2015 à ce sujet. La sécurité s’en retrouve renforcée.

Ping accessible à tous

Tous les groupes utilisateurs ont la possibilité native de faire des ping sur le réseau sans binaire setuid. Cela est surtout à destination des environnements avec conteneur ou Fedora Silverblue. Ce changement affecte à la configuration sysctl net.ipv4.ping_group_range la valeur maximale pour que tous les groupes utilisateurs y aient le droit. Les capacités CAP_NET_ADMIN et CAP_NET_RAW ne sont pas nécessaires non plus en recourant aux sockets ICMP Echo au lieu des sockets raw. Ils nécessitent en effet moins de droits que le second, car il ne permet pas d’usage abusif ou ne présente pas un risque de sécurité.

Gestionnaires de paquets

Le compteur RPM atteint la version 4.15

Cette version 4.15 du gestionnaire de paquets RPM apporte un meilleur parallélisme pour les tâches de compilation. De nombreux rapports d’erreur sont plus clairs, et de nombreuses macros ont été ajoutées comme %elif, %elifos et %elifarch, ce qui devrait simplifier la vie des empaqueteurs.

DNF avertit mieux qu’un dépôt est inaccessible

DNF émettra une erreur par défaut si un dépôt est inaccessible, au lieu d’émettre seulement un avertissement. Cela est surtout à destination des dépôts tiers qui n’activaient pas forcément cette option dans leur propre configuration. C’est l’option skip_if_unavailable qui a la valeur false par défaut dorénavant et concerne aussi libdnf ainsi que, de fait, les outils tiers qui s’en servent.

L’objectif est de rendre plus visible le fait qu’un dépôt n’est pas accessible pour l’utilisateur. L’avertissement était souvent noyé dans une grande quantité d’informations pour l’utilisateur. En cas de mise à jour, avec un dépôt mal configuré ou d’un problème quelconque, l’utilisateur pouvait croire que ses applications étaient à jour, alors qu’en réalité il devait résoudre ou signaler un problème pour les obtenir.

YUM 3 tire sa révérence

YUM cède sa place à DNF, seuls des liens symboliques vers DNF sont maintenus. Son API n’est également plus accessible.

Suppression des paquets liés à 389‑console

Les paquets liés à 389-console sont retirés au profit d’une nouvelle interface Web via Cockpit. Cela concerne les paquets 389-console, 389-ds-console, 389-admin-console, 389-dsgw, 389-admin et 389-adminutil. Ces interfaces écrites en Java n’étaient en effet plus maintenues depuis quelque temps.

Développement

Glibc 2.30

Mise à jour de la bibliothèque C glibc vers la version 2.30. Cette version propose la prise en charge d’Unicode 12.1.0, les appels système getdents64, gettid et tgkill ont été ajoutés, et elle propose aussi, depuis une révision POSIX, des fonctions d’attente de pthread basées sur une horloge monotone ou réelle, ce qui complète les fonctions existantes basées sur un delta temporel exploitant une structure timespec. Et, bien sûr, de nombreuses autres corrections.

Gawk passe à la branche 5.0.

La version 5.0 de GNU Awk corrige essentiellement de nombreux bogues. Son moteur d’expressions rationnelles récupère celui de GNULIB, ce qui met fin à une grosse activité de maintenance. Mais surtout, il prend en charge les espaces de noms. L’espace de noms par défaut étant awk. La compatibilité ascendante n’est pas totalement garantie avec cette mise à jour.

Node.js en est à son douzième nœud

Depuis la version 10, Node.js gère le protocole de sécurité TLS 1.3, alors que les versions 1.1 et 1.0 sont désactivés par défaut. Le nouvel analyseur HTTP expérimental llhttp a été ajouté. Et, bien entendu, de nombreux autres correctifs plus mineurs.

Sphinx passe à la version 2

Le générateur de documentation Sphinx passe à la version 2. La conséquence principale est l’abandon de la prise en charge de Python 2 par le projet. La sortie par défaut est maintenant en HTML 5.

Renommage du paquet Python 3 dédié aux tests

Les tests Python passent du paquet python3-libs au paquet python3-test. Cela permet de résoudre quelques bogues liés à ce choix qui n’était pas non plus très cohérent.

Go fonce vers la version 1.13

Le langage Go passe à la version 1.13. Cette version apporte de nouvelles syntaxes pour exprimer des nombres en binaire, octal, hexadécimal flottant ou avec des séparateurs de milliers, afin de rendre le code plus clair et proche de ce qu’on retrouve dans d’autres langages comme Python ou C++. Quelques améliorations de performances aussi autour de l’instruction defer et la mémoire qui est libérée plus rapidement quand l’application n’en a plus besoin. Il gère aussi TLS 1.3 par défaut.

Le langage Perl reluit à la version 5.30

Perl 5.30 installe les modules CPAN dans le dossier lié à une version de Perl comme /usr/local/{share,lib*}/perl5/5.30 au lieu de /usr/local/{share,lib*}/perl5. L’objectif étant d’éviter de casser la compatibilité des modules à cause d’une mise à niveau de Perl. Mais les utilisateurs devront procéder à une réinstallation des modules. De plus, Perl 5.30 prend en charge Unicode 12.1 et améliore la vitesse de conversion vers UTF-8. Les expressions rationnelles tiennent compte partiellement d’Unicode, par exemple « [0-5] » peut correspondre évidemment aux chiffres de 0 à 5 dans les langues latines, mais aussi à leurs équivalents dans d’autres alphabets.

Erlang et OTP passent en version 22

Le langage Erlang et OTP passent à la version 22. Le compilateur est plus rapide et efficace, notamment sur les opérations sur les chaînes de caractères. Il met à disposition une nouvelle API bas niveau pour les sockets à titre expérimental. Les opérations de sécurité SSL et TLS sont également plus rapides. En termes d’optimisation, il prend en charge le Erlang Distribution Protocol, qui scinde les gros paquets en paquets plus petits pour éviter les blocages. Fedora a spécifiquement travaillé à la migration des journaux des applications Erlang vers journald et à l’utilisation de D-Bus, grâce à erlang-dbus, pour avoir un système toujours plus cohérent.

Haskell GHC 8.6 et Stackage LTS 13

Le compilateur Haskell GHC et Stackage LTS passent respectivement à la version 8.6 et 13. Cette évolution du langage bénéficie du QuantifiedConstraints pour exprimer plus finement des contraintes sur un type. La réduction des opérations arithmétiques devrait être plus efficace. Les nombres entiers acceptent le caractère de soulignement (underscore) comme séparateur de milliers. Et beaucoup de corrections encore.

Mono 5.2

La pile .Net libre Mono bénéficie de la version 5.20. Cette mise à jour comporte principalement l’ajout de l’interface Security Support Provider Interface pour établir une connexion à une base de données SQL. Et le reste est essentiellement de la correction de bogues.

MinGW 6

L’environnement et la chaîne de compilation MinGW passent la sixième. MinGW, qui permet de compiler des binaires pour Windows depuis GNU/Linux, gère maintenant la branche WinRT et notamment les derniers ajouts liés à la prise en charge de l’architecture ARM64. Il tire parti aussi des dernières évolutions de WINE dans la compatibilité avec l’interface COM de Windows. L’environnement d’exécution C est aussi complété pour une meilleure compatibilité.

Utilisation de LLVM LDD en alternative à GNU LD

Le projet Fedora propose une configuration alternative de l’éditeur de lien, pour passer aisément de celui du projet GNU LD à celui de LLVM LDD et vice versa sans changer l’environnement de développement. Cela permet de contourner facilement les environnements de développement qui font appel directement à LD car il est le plus répandu et disponible par défaut. Pour passer à LLD, il suffit d’appeler la commande suivante :

$ update-alternatives --set ld /usr/bin/lld

Et pour revenir en arrière :

$ update-alternatives --set ld /usr/bin/ld.bfd

/usr/bin/ld est donc maintenant un lien symbolique.

GOLD a son propre paquet

L’éditeur de lien GOLD de binutils, développé par Google mais maintenant maintenu par GNU, a son propre paquet, binutils-gold, pour facilement s’en séparer si la maintenance s’arrête. Le projet n’étant plus développé activement.

Projet Fedora

Publication d’une image Cloud chaque mois

L’image Cloud de Fedora bénéficiera d’une nouvelle image chaque mois. L’objectif est de favoriser la mise à jour des installations existantes, mais surtout que les nouvelles puissent tirer bénéfice des paquets les plus récents dès l’installation.

Activation de Bodhi dans Rawhide

Dans la continuité de rendre Rawhide plus stable et d’améliorer l’assurance qualité, Bodhi est activé pour la branche Rawhide. Rawhide est la branche de développement de Fedora et reçoit beaucoup de mises à jour au fil du temps, pour relativement peu de testeurs. Son fonctionnement à part justifiait aussi le peu de ressources d’assurance qualité qui lui étaient dédiées.

Ce changement signifie qu’un paquet peut suivre le même processus pour une mise à jour sur Rawhide que pour une version stable. C’est‑à‑dire qu’un paquet soumis, sauf exceptions, attend quelques jours dans des dépôts de tests. Si la mise à jour n’a pas reçu d’avis négatifs provenant d’utilisateurs (qui est appelé aussi le karma) ou si cela fait trop longtemps qu’elle attend, soit environ deux semaines, la mise à jour sera diffusée plus largement. Mais surtout, la mise à jour n’est poussée que si les tests automatiques ont réussi.

Gestion dynamique des dépendances de sources RPM

Les sources RPM peuvent avoir des dépendances lors de la compilation qui sont gérées dynamiquement. En effet, de plus en plus de langages comme Rust, Node.js, Ruby, Python, Haskell ou Go gèrent eux‑mêmes les dépendances pour compiler un projet. Ainsi, pour un projet donné, l’empaqueteur n’a plus à recopier les dépendances que le projet a déjà lui‑même renseignées à la main. Ce qui devrait réduire le risque d’erreurs et faciliter le travail du mainteneur.

Nouvelles règles d’empaquetage pour les projets en Go

De nouvelles règles d’empaquetage pour les projets utilisant Go ont été édictées. Jusqu’ici, les règles d’empaquetage autour des projets employant Go étaient un brouillon jamais formellement adopté. L’arrivée de Go 1.13 et du concept de modules par défaut est le bon moment pour aller plus loin. Ainsi, ils disposent maintenant de la macro go-rpm-macros pour simplifier et uniformiser la description des paquets. Ils attendent une maintenance simplifiée et moins d’erreurs dans la gestion des 775 paquets concernés.

Résolution automatique des dépendances du langage R

Les dépendances autour du langage R lors de l’exécution peuvent maintenant être résolues automatiquement. En effet, les modules R décrivent les dépendances dans les méta‑données mais cette information n’était pas jusqu’ici exploitée. Maintenant, cette information est collectée et assignée automatiquement dans le source RPM du paquet. Cela simplifie la charge de travail et réduit les erreurs de maintenance.

Utilisation d’un gdb minimal lors de la compilation de Fedora

L’environnement de compilation de Fedora, le buildroot, utilise un gdb minimal pour gagner en efficience. Cet environnement de compilation est utilisé pour la génération de chaque nouveau paquet, la moindre optimisation est donc bonne à prendre car il est sollicité un très grand nombre de fois. Il ne dispose plus de la gestion de la coloration syntaxique, XML ou de Python qui ne sont pas nécessaires dans ce contexte. Cela permet du coup de ne plus avoir besoin de Python 3 dans buildroot. Il nécessite maintenant 54 Mio à télécharger, au lieu de 77 Mio, et passe de 339 Mio à 249 Mio en espace disque. Cette version allégée est disponible via le paquet gdb-minimal, qui installe le binaire /usr/bin/gdb.minimal pour ceux qui le souhaitent.

Génération de glibc32 sur infrastructures 64 bits

Le paquet glibc32 nécessaire pour le buildroot de Fedora bénéficie d’une amélioration de sa compilation pour être plus maintenable et garantir le respect de la licence LGPL. En effet, les architectures 64 bits x86-64, PPC64 et s390x sont compatibles avec leurs architectures de base respectives qui les précèdent, à savoir i686, PPC et s390. Donc, un logiciel compilé pour les secondes peut fonctionner sur les premières architectures. Cela permet donc de faire ce qui est nommé du « multilib ». Une version de Fedora x86-64 native peut installer des paquets destinés à la base pour i686 pour des raisons de compatibilité.

Cependant, glibc est une bibliothèque centrale et est nécessaire pour beaucoup de composants de base, dont GCC. Or, Fedora ne permet pas de compiler dans son infrastructure un paquet i686 pour du x86-64, par exemple. Donc, globalement, l’astuce employée jusqu’ici était de récupérer les paquets générés pour l’image i686 directement pour x86-64. Mais, pour PPC64 et s390x, leurs équivalents 32 bits ne sont plus du tout générés, ce qui pose problème car une copie ancienne de glibc32 est utilisée et Fedora n’est plus capable de la compiler à nouveau. Ce qui semble problématique au regard de la LGPL du projet.

Désormais, une exception a été incluse dans l’infrastructure pour générer glibc et glibc32 ensemble, en partant donc du même code source.

La communauté francophone

L’association

Logo de Borsalinux-fr

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 régulièrement des évènements promotionnels, comme les Rencontres Fedora, et participe à l’ensemble des évènements majeurs concernant le Libre, principalement à travers la France.

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 hebdomadaires chaque lundi soir à 20 h 30 (heure de Paris) sur IRC (canal #fedora-meeting-1 sur Freenode).

Vous pouvez aussi nous rencontrer lors du prochain Paris OpenSource Summit les 10 et 11 décembre (ce sont un mardi et un mercredi) aux Docks de Paris à Aubervilliers. Un stand sera installé pour présenter Fedora, obtenir vos retours et répondre à vos questions.

La documentation

Depuis juin 2017, un grand travail de nettoyage a été entrepris sur la documentation francophone de Fedora, pour rattraper les cinq 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.

L’équipe se réunit tous les lundis soirs après 21 h (heure de Paris) sur IRC (canal #fedora-doc-fr sur Freenode) pour faire progresser la documentation par un travail collaboratif. Le reste de la semaine cela se passe sur les listes de diffusion.

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 31 ?

Logo Media Writer

Si vous avez déjà Fedora 30 ou 29 sur votre machine, vous pouvez faire une mise à niveau vers Fedora 31. 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 avant de procéder à 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 31.

Aller plus loin

  • # Fedora Toolbox

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

    Fedora Toolbox est un petit utilitaire bien pratique.
    Il crée une sorte de chroot mais on conserve son home. Il ne demande pas d'être root même pour y installer des paquets. C'est à moitié vrai, on fait "sudo ou su" sans avoir à rentrer de mot de passe. Tout est dans $HOME ($HOME/.local/share/containers). Depuis ce chroot on peut aussi lancer des applis graphiques.
    C'est très simple d'emploi. Idéal pour un environnement de développement où on peut être amené à installer plein de paquets. Ainsi ça évite de "saloper" son OS principal. Si on fait tout son boulot dans $HOME comme il se doit, il n'y a rien à sauvegarder, c'est le $HOME principal (on peut détruit le container, rien est perdu).
    https://docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/
    Très cool.

    PS: je ne sais pas ce qu'il y a sous le capot (je le devine un peu néanmoins).

    • [^] # Re: Fedora Toolbox

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

      Fedora Toolbox repose sur podman qui est une alternative à Docker pour la création et la gestion de conteneurs. Qui eux mêmes reposent sur des cgroups. C'est donc bien plus puissant et flexible qu'un simple chroot.

      Et l'un des intérêts de podman est que justement, contrairement à Docker, tu n'as pas besoin d'être superutilisateur pour t'en servir.

    • [^] # Re: Fedora Toolbox

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

      Je ne connais pas cet outil. Que fait-il de plus ou de mieux qu'un nix-shell ou qu'un nix run ?

  • # Boot Loader Specification (blscfg de grub2)

    Posté par . Évalué à 4 (+3/-0). Dernière modification le 31/10/19 à 13:43.

    (c'est uniquement pour vous mettre l'eau à la bouche)
    Ce n'est pas une nouveauté f31, mais f30 ou f29, que j'ai raté car je suis passé de f29 à f31 (oui c'est mal).

    Quand on ajoute un noyau à son GNU/Linux chéri, vous savez comment ça se passe, il faut changer grub.cfg. C'est fait, sous Fedora, par une usine à gaz nommée grubby. Si c'est automatisé et que les programmes font bien leur job, ce n'est pas vraiment souci. Mais si vous ajoutez à la main un noyau, etc.

    Donc Fedora utilise maintenant Boot Loader Specification :
    https://systemd.io/BOOT_LOADER_SPECIFICATION

    Comment ça marche concrètement ?
    Si j'ajoute un noyau (avec son initrd) à ma machine, il me suffit de déposer un fichier qui décrit ce noyau dans /boot/loader/entries/ . Le nom du fichier doit être machineId_CeQueVousVoulez.conf. machineId est à récupérer de /etc/machine-id.

    Exemple de fichier :

        $ cat /boot/loader/entries/16218b18041341aa845c9ed438f5c154-5.3.7-301.fc31.x86_64.conf
        title Fedora (5.3.7-301.fc31.x86_64) 31 (Thirty One) version 5.3.7-301.fc31.x86_64
        linux /boot/vmlinuz-5.3.7-301.fc31.x86_64
        initrd /boot/initramfs-5.3.7-301.fc31.x86_64.img
        options $kernelopts
        grub_users $grub_users
        grub_arg --unrestricted
        grub_class kernel
    

    Si vous supprimez le noyau, il vous suffit de supprimer le ficher pour qu'il n'apparaisse plus dans grub lors du boot.

    Un lecteur attentif aura remarqué qu'on n'a pas tout pour pouvoir booter, notamment il manque la partition root. Quand on ajoute un noyau, on ne change pas de root, donc l'information n'a pas à être dans ce fichier. Néanmoins c'est récupéré dans la variable $kernelopts qui est définit dans grub.cfg.
    Dans mon grub.cfg j'ai :
    set default_kernelopts="root=UUID=033fead8-f5bf-4433-a108-74c7359b96c1 ro rd.md.uuid=8ac3b7b8-1bc9-7973-15a8-1361718c00ae"

    Comment grub prend en compte les fichiers dans /boot/loader/entries ?
    Il le fait lors du boot et va créer "à la volée" une entrée grub classique (qu'on pourra éditer avec grub au boot si nécessaire) genre :

        menuentry 'Fedora 31' ... {
            set root=...
            linux /boot/vmlinuz-... root=...
            initrd /boot/initramfs-...
        }
    

    C'est demandé dans le fichier grub.cfg par :

        insmod blscfg
        blscfg
    

    Et voilà !

    C'est une petite chose mais je suis ravi de le voir car avant c'est vraiment "hugly".

    • [^] # Re: Boot Loader Specification (blscfg de grub2)

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

      Désolé pour la présention, mais "code block" marche pas.

    • [^] # Re: Boot Loader Specification (blscfg de grub2)

      Posté par . Évalué à 9 (+8/-0). Dernière modification le 31/10/19 à 23:10.

      Bon sang, je dois vraiment être réfractaire au changement, mais sous GRUB 1, on avait un petit fichier menu.lst à éditer, à la syntaxe simple et claire. C'est devenu tellement compliqué sous GRUB 2 qu'on en est arrivé à pondre des utilitaires douteux tels que grubby ou blscfg pour rendre le truc éditable par un être humain.

      Alors je comprends bien que GRUB 2 est une avancée sur pleins de sujets par rapport à GRUB 1, mais pourquoi avoir rendu sa conf aussi complexe ??

      • [^] # Re: Boot Loader Specification (blscfg de grub2)

        Posté par . Évalué à 4 (+3/-0). Dernière modification le 01/11/19 à 08:31.

        Ah la résistance au changement…

        Le menu.lst que tu édites à la main (donc que le système ne devrait pas gérer) est maintenant : /etc/grub.d/40_custom

        Le gros problème de menu.lst, est qu'il est édité par l'utilisateur et le système. 40_custom est géré que par l'utilisateur.

        Est-ce que le menu.lst gérait les échecs de boot pour proposer un mode "sans échec" ? Je ne crois pas.
        Est-ce qu'il gère le boot par défaut "automatiquement" ? Je ne crois pas.

        Je donne un exemple concret d'avantage pour moi de Boot Loader Specification.
        J'ai plusieurs disques durs sur mon système. Un disque est le boot "habituel", un autre un backup (typiquement hebdomadaire avec rsync). Si le boot habituel ne marche pas, je boote sur le backup.
        Avant à chaque backup je devais éditer grub.cfg (c'est fait par script avec des sed). Maintenant je n'ai rien à faire. Évidemment que je dois toujours copier /boot (pas /boot/efi), mais c'est tout. Et il ne faut pas oublier que /boot n'a pas forcément à avoir sa propre partition, ça peut être la partition racine (ce qui est le cas chez moi).

  • # Fedora spin et KDE

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

    Je viens de voir l'article, en ce moment je veux quitter les distributions ayant pour base ubuntu, et Fedora m'intéresse. J'étais autrefois sur Solus (quand mon besoin pour certains logiciels était faible) et il a toujours été réactif et fiable.

    Je voudrais une distribution ou les drivers sont installés d'office (qu'ils soient libre ou non), mais aussi où la dernière version de plasma est présente (si le retard avant la maj est de quelques mois ce n'est pas gênant).

    Ps: si quelqu'un sait, quelle est la version de plasma dans Fedora Spin 31 ?

    • [^] # Re: Fedora spin et KDE

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

      Sur Fedora Packages on trouve plasma-desktop 5.16.5 pour la Fedora 31.

      • [^] # Re: Fedora spin et KDE

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

        J'avoue que j'ai pas eu le réflex !
        Merci, je saurais ou aller la prochaine fois 🙂

        • [^] # Re: Fedora spin et KDE

          Posté par (page perso) . Évalué à 1 (+0/-0). Dernière modification le 02/11/19 à 22:29.

          À noter que Fedora a une politique strict au niveau des logiciels, et donc les pilotes également, non libres : rien d'inclus par défaut. Il faudra installer des dépôts tiers genre rpmfusion.org.

    • [^] # Distribution pour utiliser KDE

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

      Je voudrais une distribution ou les drivers sont installés d'office (qu'ils soient libre ou non), mais aussi où la dernière version de plasma est présente (si le retard avant la maj est de quelques mois ce n'est pas gênant).

      Les développeurs de Fedora s’investissent beaucoup sur Gnome (par exemple pour le passage à Wayland). KDE est un citoyen de seconde zone.

      Si je voulais utiliser KDE, je passerais plutôt une distribution dont c’est l’environnement graphique principal et dont les développeurs s’investissent dessus, OpenSUSE. Ce n’est pas non plus une distribution basée sur Ubuntu (ni Debian) et accessoirement, si tu aimais le côté rolling release (d’après Wikipedia) de Solus, il y a une version rolling release : OpenSUSE Tumbleweed.

      Je ne dis pas ça pour faire la pub d’une distribution que j’utilise. Je n’utilise pas OpenSUSE, notamment parce qu’elle se concentre sur KDE et que je n’ai pas trop confiance en lui (surtout du fait de la propension de ses développeurs à changer une version qui fonctionne par une très boguée). Cela dit, pour le peu que j’ai essayé OpenSUSE, elle m’a laissé une très bonne impression (même KDE semblait fonctionner étonnamment bien). C’était sur une machine très récente, avec des composants très récents, sur laquelle d’autres distributions ne fonctionnaient pas ou assez mal.

      ¯ : macron (typographie), petit signe diacritique, qui prétend ne pencher ni à gauche ni à droite, mais se place nettement au dessus des vraies lettres, qu’il considère avec mépris.

  • # Lien wikipedia fr AArch64 inexistant

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

    Le lien https://fr.wikipedia.org/wiki/AArch64 envoie vers une page que Wikipedia fr ne connaît pas. Par contre ça marche pour l'anglais : https://en.wikipedia.org/wiki/AArch64

  • # GDM, Wayland et NumLock

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

    Apparemment, enfin le NumLock est activé dès le boot. Quelqu'un peut-il me confirmer cela ?

  • # Compression

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

    Les paquets RPM utilisent le format de compression zstd au lieu de xz. Le temps de décompression est plus rapide d’un facteur trois ou quatre pour le paquet Firefox, par exemple. La taille d’un paquet sera aussi sensiblement plus faible. En contrepartie, la génération d’un paquet est légèrement plus longue. Les opérations d’installation ou de mise à jour des paquets seront plus rapides et le projet Fedora économisera également un peu de bande passante pour fournir ces paquets aux utilisateurs.

    Il est dit partout (exemple, mais il y en a plein quand on cherche des benchs) que zstd est pour le temps de décompression (ça OK dans ton texte) mais au prix d'un ratio de compression moindre (opposition par rapport à ton texte), et que le temps de compression est aussi meilleur (opposition par rapport à ton texte).
    Bref, de ce qu'on lit ailleurs justement Zstd doit faire augmenter plutôt qu'économiser de la bande passante, le prix à payer pour gagner de la perf.

    Avez-vous une source (par exemple taille du paquet Firefox avec xz et avec zstd, mais mieux tailler totale) pour le gain en taille?

    • [^] # Re: Compression

      Posté par (page perso) . Évalué à 5 (+2/-0). Dernière modification le 03/11/19 à 19:28.

      Ce que tu dis est vrai pour des valeurs similaires de niveau de compression de xz et de zstd. Sauf qu'ici il a été décidé d'utiliser le niveau de compression maximale de zstd, tellement le temps de décompression reste avantageux et que finalement le temps de compression n'est pas un gros critère (les RPM sont crées sur un serveur de Fedora, pas chez tout le monde).

      Ma source

      • [^] # Re: Compression

        Posté par (page perso) . Évalué à 2 (+0/-0). Dernière modification le 04/11/19 à 09:26.

        Merci pour le lien, quelques remarques :
        - "niveau de compression maximale de zstd" je pensais à celui-la, et même comme ça on parle plutôt d'être moins performant en compression que LZMA. exemple avec le niveau de compression indiqué (et incluant 19)
        - ta source indique que le niveau de LZMA n'est pas le maximum (niveau 2 sur 9), donc la compétition sur le taux de compression est biaisé (niveau haut de zstd contre niveau bas de LZMA), dire simplement que zstd compresse mieux que LZMA est simpliste et faux objectivement (quand on compare le taux de compression sans préciser qu'on s'interesse à d'autre paramètre, généralement on sélection le niveau max de chaque côté).
        - Dans le mien d'exemple, le taux de compression LZMA qui correspond au taux de compression zstd a le même temps de compression, et le temps de décompression change peu.
        - Le gain en taille pour l'exemple Firefox est de… 2%. Soit pas grand chose, et sur une seul exemple. Parler de changement pour le gain de place, même moi qui aime optimiser au max, me laisse plus dans la tentative d'ajouter du hype la où il n'y a pas assez à "vendre" (alors que pas besoin, voir plus loin) en tordant un peu la réalité (pas de comparaison avec LZMA 9, alors qu'il le faudrait si le but est gagner de la place).

        Bref, je trouve la façon de "vendre" le passage à zstd un peu limite, pour gagner les 2% de taux de compression on a juste à passer de LZMA 2 à LZMA 4 pour la même charge CPU que zstd 19, pas besoin d'autre chose, le point à retenir est la vitesse de décompression (et l'argument est largement suffisant pour passer à zstd!)

        • [^] # Re: Compression

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

          Je ne vois pas pourquoi tu te focalises sur ce point. Mon paragraphe me semble assez clair sur le fait que le temps de décompression est le gain important, que le gain de place est faible mais existant. Je ne crois pas avoir spécialement travesti la réalité.

          Oui bien sûr la comparaison avec LZMA est un peu biaisée. Mais si le temps de décompression est le critère principal, alors augmenter le taux de compression de LZMA n'est pas le critère. Par contre si pour un temps de décompression qui reste faible zstd sait faire mieux qu'un LZMA avec un taux de compression faible, tant mieux par rapport à la situation existante car on gagne sur plusieurs tableaux !

          • [^] # Re: Compression

            Posté par (page perso) . Évalué à 2 (+0/-0). Dernière modification le 04/11/19 à 09:53.

            Je ne vois pas pourquoi tu te focalises sur ce point.

            Euh… Parce que j'aime débattre de ce sujet?

            tant mieux par rapport à la situation existante car on gagne sur plusieurs tableaux !

            Justement non :
            - LZMA 2 : actuel
            - LZMA 4 contre LZMA 2: -2% taille, +100% compression
            - zstd 19 contre LZMA 2 : -2% taille, +100% compression, -75% décompression

            Donc zstd 19 contre LZMA 4 : 0% taille, 0% compression, -75% décompression

            Le passage de LZMA à zstd ne fait gagner que sur 1 tableau. la taille, elle aurait été juste un changement de niveau et pas de format (le passage à zstd ne change rien à la taille par rapport à une option de LZMA).

            Je ne crois pas avoir spécialement travesti la réalité.

            Je l'ai sans doute mal compris en lisant trop rapidement, mais je comprenais que le passage de LZMA à zstd fait gagner un peu de place, ce qui n'est pas le cas (c'est le passage d'un faible niveau de LZMA à un haut niveau de zstd qui le fait). Disons que cette partie me semble prendre trop de place alors que c'est un effet de bord.

            Ca reste un détail, et maintenant je sais que LZMA compresse toujours mieux que zstd dans l'absolu (sans regarder d'autres critères, qui peuvent être importants) même avec ce que j'ai compris en premier en lisant ce paragraphe et qui me faisait tiquer.

  • # Publication d’une image Cloud chaque mois

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

    Si j’en crois le wiki et le bug, la mise à jour mensuelle des images Cloud n’a pas été terminée à temps pour Fedora 31:
    https://fedoraproject.org/wiki/Releases/31/ChangeSet#Cloud_Provider_Image_Updates
    https://bugzilla.redhat.com/show_bug.cgi?id=1619451

Envoyer un commentaire

Suivre le flux des commentaires

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