Nouvelle version de Fedora dite 33

Posté par  (site web personnel) . Édité par Davy Defaud, Pierre Jarillon, M5oul, patrick_g et bubar🦥. Modéré par claudex. Licence CC By‑SA.
65
27
oct.
2020
Fedora

En ce mardi 27 octobre, les utilisateurs du Projet Fedora seront ravis d’apprendre la disponibilité de la version Fedora 33.

Fedora 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 peut se voir comme une sorte de vitrine technologique pour le monde du logiciel libre, 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, Wayland, systemd, la célèbre suite de compilateurs GCC, etc. Cliquez ici pour voir l’ensemble des contributions de Red Hat.

Cela a été aussi abordé dans une série d’articles ici, et par ici encore.

GNOME Nature

Sommaire

Expérience utilisateur

Passage à GNOME 3.38. Cette mise à jour apporte de nombreux changements :

  • les grilles d’applications fréquemment utilisées et toutes ont fusionné ;
  • l’application Visite a été revisitée pour guider les utilisateurs lors de leur première utilisation de GNOME, pour présenter les fonctionnalités de base et être plus accessible aux débutants ;
  • un contrôle parental a été ajouté au panneau de configuration des utilisateurs, des applications peuvent ne pas être lancées ou installées par un utilisateur particulier ;
  • quelques améliorations ergonomiques avec l’option pour afficher le pourcentage de batterie (sans recourir aux paramètres avancés) ou la possibilité de redémarrer la machine directement depuis le menu principal ;
  • certaines applications ont été redessinées, comme l’outil de capture d’écran ou l’enregistrement vocal ; de nombreuses icônes d’application ont été aussi redessinées ;
  • amélioration des performances lors de l’enregistrement de l’écran ;
  • avec Wayland uniquement, les écrans peuvent avoir un taux de rafraîchissement différent, selon les spécifications de la machine ;
  • le navigateur Web de GNOME active par défaut une protection contre le pistage, permet de rendre un onglet muet et désactive la lecture automatique des vidéos ;
  • le gestionnaire d’index de fichiers Tracker a été mis à jour vers la version 3 et la plupart des applications GNOME en tirent profit — il permet principalement à chaque application d’avoir son propre index, ce qui est aussi utile dans le cas des applications fonctionnant avec Flatpak.

Nettoyage de la fonction pour cacher le menu du chargeur de démarrage. Cette fonction introduite avec Fedora 29 permet de mettre à jour le noyau de manière transparente pour l’utilisateur. Si après une mise à jour du noyau le démarrage échoue, le chargeur de démarrage le détectera et choisira le noyau précédent automatiquement par la suite. Cette fonction était spécifique à Fedora et l’objectif ici est de la rendre disponible en amont et sera également plus maintenable en tirant parti de l’API de systemd et de sa variable d’environnement SYSTEMD_REBOOT_TO_BOOT_LOADER_MENU.

C’est le retour des fonds d’écran animés par défaut, le fond d’écran a une teinte qui varie en fonction de l’heure de la journée. Fedora avait introduit cette nouveauté dans Fedora 7 avant de la rendre facultative par la suite.

L’environnement de bureau LXQt 0.15.0 a été mis à jour. Cette version apporte entre autres :

  • un nouveau widget pour la barre principale pour changer la luminosité de l’écran ;
  • la luminosité de l’écran peut également se réduire automatiquement si l’ordinateur est inactif trop longtemps ;
  • depuis la barre des tâches, il devient possible de changer le bureau virtuel d’une application ;
  • le navigateur de fichiers peut sauvegarder les mots de passe pour monter un système de fichiers, si le démon gnome-keyring est actif.

Nouveau menu pour facilement redémarrer ou voir l’état de la batterie

L’éditeur de texte en console nano devient l’éditeur de texte par défaut en lieu et place de vi . En réalité, la variable $EDITOR n’a jamais été configurée par défaut dans Fedora et pour de nombreux outils tels que Git, vi devenait le choix alternatif privilégié. Cependant nano est considéré comme plus intuitif pour les utilisateurs en ne nécessitant pas de connaissances particulières pour s’en servir. Que les amateurs de l’éditeur du diable se rassurent, le paquet vim-minimal qui installe vi (mais pas Vim) est installé par défaut, il reste donc disponible sur une nouvelle installation. Seule la variable $EDITOR est ici affectée.

L’extension de mémoire avec le mécanisme d’échange (swap) utilise maintenant zram par défaut. En effet, quand la mémoire vive physique vient à manquer, le noyau peut utiliser la pagination pour transférer des programmes ou données en mémoire sur la mémoire de masse comme le disque dur ou un SSD. Cela est transparent pour l’utilisateur et les programmes mais cependant cette procédure est lente car ces périphériques ne sont pas aussi rapides d’accès que la mémoire vive. Il n’est pas rare en effet que l’usage de swap puisse ralentir un ordinateur trop fortement, nécessitant de le redémarrer brutalement. Pour améliorer la réactivité et les performances, on peut à la place compresser en mémoire vive ces données. Cela libère de la place tout en étant plus rapide que d’utiliser la mémoire de masse en échange d’un léger surcoût en mémoire de 0,1 % à 0,04 %. C’est ce que propose zram. Ce changement concerne aussi les systèmes existants. Les partitions ou fichiers d’échange existants sont préservés et obtiennent une priorité d’utilisation plus faible, donc uniquement quand zram aura atteint ses propres limites. Par défaut, zram sera configuré pour avoir une taille équivalente à la moitié de la mémoire vive du système, borné à 4 Gio si l’ordinateur a plus de 8 Gio de mémoire vive.

Btrfs devient le système de fichiers par défaut des variantes orientées bureautiques dont Fedora Workstation. Il remplace ainsi ext4, qu’il reste évidemment possible d’utiliser pour ceux le souhaitant. Notons qu’OpenSuse 13.4 avait sauté le pas en 2014 et que Facebook l’utilise en interne depuis un moment, un employé de l’entreprise ayant d’ailleurs participé à ce changement dans Fedora. Les bénéfices attendus sont :

  • la correction de certains bogues liés à la séparation stricte entre les partitions / et /home ;
  • une compression native des données redondantes, réduisant l’espace de stockage occupé et l’usure des périphériques de stockage ;
  • la possibilité de réserver des entrées‑sorties minimum à certains processus via l’usage des cgroups, ce que Btrfs gère bien ;
  • une réduction de la complexité du stockage en ayant Btrfs qui gère l’ensemble depuis le noyau.

Les systèmes existants ne sont pas concernés par ce changement pour éviter les problèmes liés à une telle migration qui serait compliquée d’automatiser de manière fiable.

DXVK devient l’implémentation de référence de Wine3D en étant basé sur Vulkan. Cela améliorera les performances et la compatibilité des programmes graphiques prévus pour Windows et fonctionnant sous Fedora, en particulier les jeux vidéo. Le paquet wine-dxvk était disponible depuis Fedora 31 pour activer ce changement manuellement.

Alors que earlyoom était apparu sur Fedora Workstation 32, la variante Fedora KDE le propose désormais par défaut. En somme, quand la mémoire vive descend en dessous de 4 % de mémoire disponible et que la mémoire d’échange descend en dessous des 10 %, un signal SIGTERM sera envoyé au processus choisi pour être coupé proprement afin de libérer assez de mémoire pour que la machine continue de tourner dans ces conditions. Si cela descend respectivement à 2 % pour la mémoire vive et 5 % l’espace d’échange, un signal SIGKILL sera envoyé ce qui mettra fin au processus immédiatement. L’objectif est de garder un système fluide et utilisable pour l’utilisateur, en évitant de devoir recourir à un redémarrage forcé.

Un cgroups a été créé pour réserver des ressources minimum aux sessions graphiques actives. Un utilisateur actif avec une session graphique a 250 Mio de réservé, plafonnés à 10 % de la mémoire vive disponible. Ce dispositif repose sur le démon uresourced pour le moment, l’objectif sera de le l’intégrer dans les projets en amont plus tard.

Gestion du matériel

Activation des techniques ARM Pointer Authentication et de Branch Target Identification pour l’architecture AArch64 afin d’améliorer la sécurité des programmes par défaut. La première technique permet de se protéger contre les attaques de type Return Oriented Programming, les pointeurs reçoivent une étiquette qui est ensuite vérifiée pour s’assurer qu’elle n’a pas été altérée. Le second consiste à identifier les sauts et branchements dans le code pour qu’ils ne puissent aller que dans une liste d’instructions autorisées, limitant le risque d’exécution de code arbitraire. Les paquets sont donc compilés avec GCC et son option -mbranch-protection=standard.

Meilleure gestion des pics d’activité et de la chauffe des processeurs Intel, entre autres via le démon thermald. En effet, les processeurs modernes, notamment ceux d’Intel, disposent d’une grande variété de capteurs de température et de différents modes pour limiter la fréquence du processeur afin de réduire ou contenir la température. Ce démon va collecter les données du processeur pour choisir le mode de fonctionnement le plus optimal.

Le service dmraid-activation.service ne sera pas activé si aucun micrologiciel RAID n’a été détecté lors de l’installation (un système « firmware RAID » est conditionné à la présence d’un RAID géré au niveau de la carte mère et du BIOS). Cela permet d’éviter de dépendre du service systemd-udev-settle.service qui attend particulièrement longtemps pour détecter les périphériques, même quand cela n’est pas nécessaire si aucun micrologiciel RAID n’est exploité. Le temps de démarrage pour ces utilisateurs est ainsi réduit.

Nouvelle option pour voir l’état de la batterie plus facilement

L’écosystème .NET Core est disponible pour AArch64 et non plus uniquement pour l’architecture x86‑64.

L’édition Internet des objets devient une édition officielle de Fedora. Il obtient donc le même statut que l’édition Workstation ou Server. Cette édition qui cible les architectures x86‑64, AArch64 et ARMv7 repose sur rpm-ostree, comme Fedora Silverblue, et les applications dans des conteneurs pour faciliter la maintenance et la mise à jour des composants internes. C’est également une édition minimaliste par défaut.

Internationalisation

Mise à jour d’iBus 1.5.23. Cette mise à jour affiche surtout une autre liste de dispositions clavier provenant de XKB. Cela permet notamment aux outils comme ibus-setup ou au centre de configuration de GNOME de proposer une liste plus complète de ces dispositions par défaut.

La plate‑forme de traduction Zanata tire complètement sa révérence de l’écosystème Fedora. Cela met fin à la transition de la plate‑forme de traduction de Zanata vers Weblate qui a franchi une grande étape déjà dans Fedora 32. Ainsi, il n’y a plus qu’une seule plate‑forme de traduction active, ce qui simplifie la maintenance et la gestion des traductions.

Weblate apporte aussi entre autres pour les contributeurs :

  • de simplifier l’accès aux nouveaux, en n’ayant pas besoin d’approuver les comptes avant qu’ils ne puissent contribuer ;
  • la possibilité d’ajouter des notifications ou des commentaires pour simplifier le travail ;
  • d’utiliser un outil utilisé par d’autres projets libres, permettant de mutualiser les développements autour de cet outil ;
  • d’automatiser certaines tâches comme la mise à jour automatique des fichiers de traduction.

Administration système

La synchronisation du temps par le réseau sécurisé (NTS) est prise en charge dans le client NTP chrony et l’installateur Anaconda. Cela permet d’éviter les attaques de type « homme du milieu » pour le changement d’heure, trop loin dans le futur ou dans le passé. Cette synchronisation utilise le protocole de sécurité TLS.

Les dépôts modulaires sont proposés dans un paquet à part : fedora-repos-modular. Ce paquet reste installé par défaut. Cela permet aux utilisateurs de désactiver facilement les dépôts en supprimant le paquet plutôt qu’en changeant la configuration des dépôts, ce qui aurait empêché les mises à jour ultérieures de ces fichiers de configuration.

La résolution des noms de domaine dans les applications se fera via systemd-resolved. La bibliothèque glibc utilisera nss-resolve au lieu de nss-dns jusqu’à aujourd’hui. Notons que la première partie du changement a été faite par Ubuntu 16.10 mais pas la seconde partie. Cela permet d’utiliser l’outil resolvectl nativement, cela donne accès à un mini cache DNS ce qui améliore la performance de ces requêtes pour les applications qui n’en disposent pas elles‑mêmes. Les utilisateurs de plusieurs VPN (un personnel et un professionnel par exemple), n’auront plus les requêtes DNS qui peuvent aller échouer sur la mauvaise connexion. La fonctionnalité de sécurité DNS avec TLS est également accessible par ce biais, bien que non actif pour le moment, par défaut.

Renforcement de la politique de sécurité globale du système :

  • désactivation des protocoles TLS 1.0 et TLS 1.1 ;
  • rejet des clefs Diffie‐Hellman 1 024 bits et de la fonction de hachage SHA‑1 en guise de signature.

En cas de problèmes, pour revenir à une politique plus souple, vous pouvez exécuter la commande (en tant que super‑utilisateur) :

update-crypto-policies --set LEGACY

La prise en charge du format dbm dans NSS a été supprimée. Depuis Fedora 28, le format SQLite était utilisé par défaut. NSS propose de migrer les formats de stockage des clefs si c’est nécessaire. La bibliothèque est de fait plus légère.

Ajout de PARSEC pour proposer une API pour le matériel de sécurité ou des services de cryptographie en étant indépendant du matériel. Il peut exploiter les matériels de sécurité suivants : TPM2, HSM et Arm TrustZone. L’édition Internet des objets propose cette API par défaut.

Storage Instantiation Daemon fait son arrivée en grande pompe. L’objectif est d’avoir un démon unique pour étendre udev pour la gestion des espaces de stockage pour éviter d’aboutir à des règles complexes que l’on pouvait avoir dans des systèmes complexes. Cela permet de collecter facilement tous les évènements relatifs à un périphérique de stockage comme son insertion ou son retrait du système. Il prend en charge des périphériques employés à travers plusieurs sous‑systèmes comme LVM, multipath ou MD avec les mêmes commandes.

La collection d’outils X.Org sera proposée via des paquets plus individuels que les paquets génériques xorg-x11-{apps,font-utils,resutils,server-utils,utils,xkb-utils} employés jusqu’ici. Certains utilitaires sont également supprimés. Ces collections d’utilitaires étaient assez historiques mais offrent peu de flexibilité et ne représentent plus la réalité. Par exemple, les utilitaires luit ou edid-decode ne sont même plus développés sous l’égide de X.Org. Le versionnage de ces paquets ne collait plus avec ceux des projets embarqués. Mettre à jour un paquet pour un composant nécessitait de régénérer cette mise à jour pour l’ensemble. Les paquets étaient aussi plus gros que nécessaire pour beaucoup d’utilisateurs. Tout ceci est donc simplifié et plus cohérent avec le nouveau découpage.

Version de l’environnement LXQt

Mise à jour de Stratis 2.1. Cette version apporte le chiffrement des données avec notamment une interface DBus pour leur gestion. Les clefs de chiffrement sont ensuite gérées dans le noyau. L’utilitaire en ligne de commande peut aussi initialiser le cache avec la commande init_cache. Les sous‑commandes report et key sont ajoutées pour gérer ou voir respectivement les rapports générés par Stratis et les clefs de chiffrement.

Le paquet device-mapper-multipath a été supprimé des médias autonomes (et de fait des installations par défaut) ce qui améliore le temps d’amorçage pour les usages bureautiques. En effet, ce service dépendait aussi du service systemd-udev-settle.service dont on a expliqué la problématique plus haut. Les serveurs et centres de données qui en ont besoin pour leur usage pourront toujours l’installer ou en disposer via une image plus adaptée comme celle de l’édition Server.

Les profils de connexion de NetworkManager seront sauvegardés dans le format officiel keyfile au lieu d’utiliser le format spécifique à Red Hat qui est ifcfg-rh. En réalité, NetworkManager utilisait déjà, même dans Fedora, les nouveaux profils mais uniquement pour les profils non supportés par l’ancien format. L’objectif est d’essayer de recourir au nouveau format systématiquement pour à terme uniformiser leur gestion. Les nouvelles configurations sont sauvegardées dans les fichiers /{etc,usr/lib,run}/NetworkManager/system-connections. Les anciens profils ne sont pas migrés automatiquement, la compatibilité est pour l’instant conservée pour ces profils préexistants.

Le gestionnaire de paquets RPM 4.16 a été mis à jour. L’analyseur des fichiers SPECS et des macros a été amélioré. Les macros disposent de nouvelles fonctionnalités comme l’opérateur ternaire ou une comparaison des versions en natif. Les métadépendances sont également ajoutées.

Les bases de données RPM passent du format Berkeley DB à SQLite. Ceci arrive grâce à la nouvelle version de RPM. L’ancien format n’était plus maintenu depuis des années car la nouvelle version de l’utilitaire Berkeley DB 6.x a adopté une licence incompatible. De plus, ce format n’était pas transactionnel, donc incapable de détecter et de corriger lui‑même les erreurs suite à un crash ou à une corruption de données par exemple. SQLite offre donc une solution plus robuste.

Développement

LLVM passe à la onzième version. Son compilateur Clang compile par défaut en C17 et non plus C11. Il propose aussi l’option -fstack-clash-protection pour protéger contre ces attaques pour les architectures x86/x86‑64, s390x, et POWER 64 bits. Les instructions asm inline sont également prises en charge, de même que le gestion préliminaire du C++20. De nouvelles instructions ARMv8 sont gérées, de même que celles d’Intel AMX. WebAssembly est également mieux géré.

Make prépare sa version 4.3. Cette version a plusieurs changements qui cassent la compatibilité avec les versions antérieures. Le symbole « # » n’introduit plus un commentaire lors de l’appel d’une fonction ou d’une macro, il ne doit donc plus être échappé. L’instruction += sur une chaîne vide n’introduit plus un espace initial. L’ordre d’exécution des fichiers Makefile est aussi déterministe. Les listes obtenues via des jokers $(wildcard…) sont dorénavant triées. Les performances sont également globalement améliorées.

Mise à jour de la bibliothèque C glibc 2.32. Elle prend en charge Unicode 13.0.0. De nombreuses fonctions sont annotées avec access pour générer des alertes en cas de risque d’un accès en dehors de la mémoire lors de ces appels. De nombreuses suppressions de symboles, corrections de bogues et de failles de sécurité complètent cette version.

Mise à jour des outils Binutils 2.34. Le désassembleur objdump --disassemble génère en art ASCII l’arc entre le début et la fin d’un point dans le flot d’exécution. Il prend en charge aussi debuginfod qui est un service HTTP pour télécharger les informations de débogage ELF/DWARF, tout comme le code source associé. En plus d’autres corrections plus mineures.

Petit coup de Boost 1.73 pour la bibliothèque générique C++. La compatibilité avec C++20 se renforce, tandis que pour certains modules le C++03 est déprécié pour une suppression ultérieure. De nombreux algorithmes d’interpolation ont été ajoutés. Le module pour les histogrammes se dote de nouvelles opérations pour réduire le champ de certains calculs. Enfin, la compilation est plus rapide en retirant l’inclusion de l’en‑tête standard algorithm qui est particulièrement lourd.

Mise à jour de l’environnement MinGW pour la compilation d’applications Windows sous GNU/Linux. Ainsi, il est possible d’utiliser GCC 10, binutils 2.34 et GDB 9.1 en tirant parti de leurs améliorations respectives.

Passage de Golang à la version 1.15. La taille des binaires compilés est réduite d’environ 5 % en optimisant l’usage des métadonnées du ramasse‑miettes. L’éditeur de liens est significativement amélioré avec ses opérations 20 % plus rapides en consommant jusqu’à 30 % de mémoire en moins. D’autres optimisations du genre sont attendues par la suite. Les données des fuseaux horaires tzdata peuvent être incluses dans un programme. La variable GOPROXY peut lister différents serveurs mandataires et utiliser les suivants dans l’ordre en cas d’indisponibilité des premiers.

OpenJDK 11 danse la Java. Cela fait deux ans que Fedora attendait de faire ce changement, mais les grandes incompatibilités qu’elles génèrent ont retardé cette mise à jour. Ce qui est maintenant privé dans les API le sont réellement. Autrement, il apporte notamment un client protocole HTTP, de l’Unicode 10 ou la gestion du protocole de sécurité TLS 1.3.

Node.js fait un quatorzième nœud. Il met à jour le moteur JavaScript V8 8.3, qui améliore les performances. Il apporte une nouvelle API pour DOM afin d’écouter des évènements ou une autre pour compter le nombre de fois qu’une fonction est appelée. Et, bien entendu, des corrections de bogues et de failles de sécurité.

Erlang 23 est disponible. Cette version améliore les performances, en particulier concernant les opérations SSL/TLS, et la montée en charge. La gestion de SSL 3.0 est abandonnée car plus suffisamment sécurisée. Une nouvelle API pour les sockets pour gérer TCP et UDP fait son apparition. Fedora en profite pour mieux exploiter l’intégration les journaux applicatifs dans syslog ou journald. Les règles SELinux particulièrement anciennes ont été rafraîchies.

Mise à jour de GHC 8.8 et de Haskell Stackage LTS 16. Les chaînes de caractères prennent en charge l’Unicode 12. Une nouvelle optimisation optionnelle pour l’architecture x86 a été introduite via l’option -fblock-layout-cfg, pour deviner et précharger la prochaine instruction lors d’un saut afin d’améliorer l’usage du cache. Et, bien sûr, d’autres corrections sont de la partie.

Le langage Perl est proposé à la version 5.32. La gestion d’Unicode 13.0 est proposée cette fois. Il est possible avec l’opérateur isa de vérifier si un objet est d’une classe particulière ou une classe fille de celle‑ci. Quelques optimisations sont également là pour vérifier les fonctionnalités disponibles plus rapidement.

Ruby on Rails embarque dans la voiture 6.0. Cette boîte à outils Web peut paralléliser les tests. Il apporte également Action Mailbox pour rediriger des courriels entrants vers des contrôleurs afin de les traiter. Tandis que Action Text arrive pour pouvoir éditer du texte riche, qui permet de facilement inclure du formatage de base.

La version 3.9 de Python débarque. Elle introduit quelques simplifications, avec removeprefix et removesuffix pour remplacer avantageusement startswith pour supprimer un début ou une fin de chaîne de caractères. Il est possible de fusionner deux dictionnaires avec l’opérateur |. Un nouveau module zoneinfo est proposé pour gérer les différents fuseaux horaires.

Alors que les versions 2.6 et 3.4 de Python sont supprimées. Ces versions étaient disponibles pour ceux qui voulaient faire des développements pour RHEL 6 qui prenait en charge ces versions. Or, ils n’ont respectivement plus aucun support depuis octobre 2013 et mars 2019. Le support était tout de même fourni par Red Hat jusqu’ici, mais avec la fin de RHEL 6, la maintenance et le besoin autour de ces versions ont disparu. Cela simplifiera grandement la maintenance de l’écosystème Python.

À propos de Python, le paquet python-pytoml est déprécié et sera supprimé prochainement. Les développeurs et utilisateurs sont encouragés à recourir au paquet python-toml à la place.

mod_php est supprimé, il permettait au serveur Apache d’exécuter du PHP directement. Cette méthode n’est plus la plus employée depuis longtemps et est même un risque de sécurité, car il partage sa mémoire avec le processus du serveur HTTP. Il faut utiliser php-fpm à la place qui a une bonne compatibilité avec HTTPd et Nginx.

La bibliothèque libdb est dépréciée et sera supprimée définitivement dans une prochaine version de Fedora. Comme expliqué plus haut dans le cas RPM, la licence de la version 6 de ce projet est plus restrictive, passant de LGPL v2 à AGPL v3. De nombreux projets qui en dépendent ne peuvent pas en bénéficier, donc l’idée est de progressivement le supprimer, dans la mesure du possible pour Fedora 35, avec un outil pour faire les migrations nécessaires.

Les paquets glibc-headers.i686 et glibc-headers.x86_64 ont fusionné dans le nouveau paquet glibc-headers-x86.noarch. Pour les autres architectures le paquet glibc-headers a fusionné dans glibc-devel. Ce changement permet d’améliorer la fiabilité de la mise à niveau du système car il pouvait être installé par erreur assez facilement sans que cela soit utile.

Les paquets de BLAS/LAPACK seront compilés avec FlexiBLAS qui est un wrapper pour pouvoir choisir la bibliothèque compatible BLAS de référence de son choix.

Projet Fedora

CMake peut être utilisé pour faire des compilations dans un répertoire distinct du code source pour la conception des RPM. Cela suit par ailleurs les recommandations du projet CMake et donc probablement ceux de nombreux projets qui s’en servent. Les macros %cmake_build, %cmake_install et %cmaketest ont été ajoutées, par ailleurs, pour mieux correspondre aux opérations similaires utilisées par d’autres outils et, de plus, facilement avoir des outils agnostiques à ce sujet.

Mise à disposition d’ELN, qui est un nouveau buildroot qui permettra de simuler un environnement RHEL afin d’évaluer les impacts des changements de Fedora dans RHEL directement. Ainsi, les compilations dans ce système se baseront sur une Fedora Rawhide qui simulera, aujourd’hui, une RHEL 9. L’objectif est de rapprocher le travail effectué entre Fedora et Red Hat. Ainsi, les développeurs de Red Hat sont incités à utiliser Rawhide comme plate‑forme d’expérimentation avant de porter le résultat dans RHEL.

Les paquets générés avec rpmbuild sont maintenant compilés avec l’optimisation au niveau de l’éditeur des liens qui supprime le code inutile. Concrètement, le drapeau -flto a été ajouté dans redhat-rpm-config. Les paquets résultants sont plus petits et plus rapides à charger. Comme cela nécessite aussi des analyses plus poussées par le compilateur, certaines erreurs et bogues potentiels sont détectés plus tôt.

Phase 3 pour supprimer les éléments « automagiques » pour la construction des paquets RPM autour de Python. La macro %global _python_bytecompile_extra 1 n’est plus autorisée.

Les dépendances additionnelles des paquets Python seront automatiquement générées. Des programmes Python peuvent en effet déclarer certaines dépendances optionnelles pour des fonctionnalités supplémentaires. Et si le code y a recours, le programme ne crashera pas mais invitera l’utilisateur à installer la dépendance pour en profiter. Pour simplifier le travail des mainteneurs de paquets, ces dépendances sont générées automatiquement, ce qui évitera d’avoir des paquets redondants ou qui manquent. Le projet Fedora aura un comportement plus proche de l’écosystème Python Extra et sa gestion est maintenant plus standardisée.

La macro non versionnée %{__python} génèrera une erreur. Cela permet de mettre un terme à la référence vers /usr/bin/python qui a posé beaucoup de problèmes pour la transition de Python 2 à 3. Maintenant, le mauvais comportement ne sera plus autorisé par défaut et ne sera pas le plus simple.

Ajout des macros %make_build et %make_install pour la conception des RPM afin d’avoir un usage plus uniforme de la commande make pour créer ces paquets.

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

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 quatre‑vingt‑dix 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 soir 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 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 33 ?

Logo de MediaWriter

Si vous avez déjà Fedora 32 ou 31 sur votre machine, vous pouvez faire une mise à niveau vers Fedora 33. 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 33.

Aller plus loin

  • # zram

    Posté par  . Évalué à 4.

    Il y a un problème avec cette phrase:

    Cela libère de la place tout en étant plus rapide que d’utiliser la mémoire de masse en échange d’un léger surcoût en mémoire de 0,1 % à 0,04 %.

    Si l'utilisation de zram induit un surcout (même léger) en mémoire, c'est contre-productif!
    Je suppose que le surcout n'est pas en mémoire, mais en CPU? (du fait de la compression)

    • [^] # Re: zram

      Posté par  (site web personnel) . Évalué à 7.

      Non parce que zram doit conserver en mémoire quelques paramètres et où sont stockés les informations compressées pour les retrouver. Cela a un coût, faible donc peu problématique, mais pas nul.

      • [^] # Re: zram

        Posté par  . Évalué à 4.

        D'accord, mais je rejoins la remarque, le but est bien de compresser la mémoire, donc de réduire sa taille. Il y a un problème avec la formulation.

      • [^] # Re: zram

        Posté par  . Évalué à 2.

        Il y a un surcout en métadonnées mais un gain en quantité totale de données stockée au final ?

        • [^] # Re: zram

          Posté par  (site web personnel) . Évalué à 5.

          Quand le swap est utilisé, c'est ça.

          Car le surcoût est là même quand le swap n'est pas encore utilisé.

          • [^] # Re: zram

            Posté par  . Évalué à 4.

            Le « en mémoire » dans la formulation initiale ne précise pas de quelle mémoire il s’agit. Or ce n’est certainement pas la totalité de la mémoire, il manque la précision exacte de quelle mémoire est touchée. Ce n’est certainement pas la totalité de la RAM non plus, parce que zram a pour vocation de stocker plus de données en RAM. Donc, quelle sous-partie est concernée, une partie de la mémoire utilisée par le noyau j’imagine.

            Par ailleurs question pinaillage, il y a une précision de pourcentage qui est donnée, mais si on ne sait pas quel sous-partie de la mémoire est concernée, a fortiori on peut pas en estimer le volume, donc le pourcentage ne donne que peu d’infos (si ce n’est que c’est léger, mais si c’est sur des Teras ou des Zetas de volumes ça pourrait faire quand même des chiffres significatifs)

            • [^] # Re: zram

              Posté par  (site web personnel) . Évalué à 7.

              Je ne comprends pas le blocage que vous avez sur ce point. Après si vous avez une meilleure formulation je veux bien qu'on modifie ma phrase mais je peine à le reformuler.

              Je veux dire, utiliser zram implique d'avoir un bout de mémoire qui stocke des métadonnées liées à cette activité. De l'ordre de 1 Mio / Gio (d'où les pourcentages annoncées dans la dépêche). Cette consommation existe même quand la RAM n'est pas saturée, donc de fait quand zram ne sert encore à rien. Cette mémoire est évidemment de la RAM (quoi d'autres ?).

              Donc oui bien sûr à la fin zram permet de stocker plus de données que la capacité de la RAM réelle grâce à la compression, métadonnées additionnelles incluses. Sinon cela serait effectivement inutile. Mais cela introduit quand même une consommation mémoire non nulle quand il ne sert pas encore.

              • [^] # Re: zram

                Posté par  . Évalué à 1.

                J’aurai mis un truc du style « zram réserve/utilise quelques fractions de % de la RAM pour son fonctionnement », s’il est indispensable de le préciser.

                • [^] # Re: zram

                  Posté par  . Évalué à 4. Dernière modification le 28 octobre 2020 à 17:40.

                  Je pense que ta formulation est pire.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Merci Renault

    Posté par  (site web personnel) . Évalué à 10.

    Merci Renault pour ce résumé de qualité encore une fois :)

  • # $EDITOR

    Posté par  (site web personnel) . Évalué à 6.

    Pourquoi ne pas utiliser micro l'un des rares (le seul?) éditeurs de texte les reliures de clefs standards (comment on dit keybinding en français?) ?

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: $EDITOR

      Posté par  (site web personnel) . Évalué à 3.

      comment on dit keybinding en français ?

      raccourci clavier, non ?

      moui, d'après https://en.wiktionary.org/wiki/key_binding ça a comme "synonyme" keyboard shortcut ce qui donne https://fr.wiktionary.org/wiki/keyboard_shortcut

      • [^] # Re: $EDITOR

        Posté par  (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 31 octobre 2020 à 12:06.

        Hum… Pour moi, le raccourci a toujours été la « combinaison de touches » certes, mais « pour aboutir directement à une fonctionnalité de l'application autrement accessible par un système hiérarchique/conversationnel » (typique menu→sous-menu→sous-sous-menu ou fenêtre→onglet→section→sous-section ou quand on un formulaire ou une suite de boîtes de dialogues)
        De l'autre côté, le « binding » est un peu comme le mappage des déplacements (ligne/colonne suivante/précédente, début/fin de ligne/fenêtre/fichier, etc.), selon une certaine convention (la ligne à la vi, le T inversé, le losange), avec des touches (dédiées ou avec modificateurs) ; et quelques autres petites conventions d'édition. Du coup, je ne le traduit pas, ou rarement par « convention de touches »

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: $EDITOR

      Posté par  (Mastodon) . Évalué à 3.

      Probablement parce qu'utiliser par défaut un éditeur de texte dont le binaire fait 11MB est un peu abusé. L'idée de l'éditeur par défaut, c'est d'être le même que celui dispo dans le système de recovery et de pouvoir être intégré au ramdisk.

  • # je ne peu pas laisser passer ça ...

    Posté par  (site web personnel) . Évalué à 3. Dernière modification le 28 octobre 2020 à 10:29.

    Que les amateurs de l’éditeur du diable se rassurent

    J'invoque Lucifer Morning Star pour qu'il réinstalle ton PC sous Windows Millenium …

    Na !

    Sinon merci pour le boulot de présentation de la nouvelle version …

  • # nano

    Posté par  (Mastodon) . Évalué à 10.

    Je deviens fou avec toutes ces distribs qui mettent du nano par défaut. À chaque fois je me retrouve avec des :x au milieu du fichier et je n'arrives jamais à sortir de l'éditeur.

    • [^] # Re: nano

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      L'autre fois, après avoir fait un less sur un fichier, suivi d'un sudoedit sur le fichier et machinalement je tape 12j3ddGp avant de voir ma frappe au début du fichier. Sur le coup, n'ayant pas percuté, et me demandant à quel moment j'étais entré en édition à l'issu de mon plein gré, j’appuie sur Échapp puis u …avec plus de désarroi. Finalement je comprends que c'est nano…
      Le fichier faisant près de 300 lignes, je n'ai pas eu la force de poursuivre. J'ai lancé une autre session pour kill ce truc pas intuitif. puis j'ai fait un sudo vi sur le fichier (ce que j'aurais du faire depuis le début.)

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # btrfs, ce n'est à plus rien comprendre

    Posté par  . Évalué à 3.

    Alors, oui je sais, que fedora et centos/RHEL sont différent, mais c'est quand même lié

    Alors que la RHEL 8 abandonnait btrfs ( https://access.redhat.com/discussions/3138231 )
    Voilà que fedora 33 le met comme fs par défaut, est ce qu'il y a une raison à ça ?
    un échec de leur FS startis ?

    Est ce que cela signifie un retour de btrfs popur RHEL9 ?

    • [^] # Re: btrfs, ce n'est à plus rien comprendre

      Posté par  (site web personnel) . Évalué à 10.

      Voilà que fedora 33 le met comme fs par défaut, est ce qu'il y a une raison à ça ?
      un échec de leur FS startis ?

      Pour commencer, Stratis n'est pas un système de fichiers, c'est un outils pour en simplifier sa gestion. RHEL a misé plutôt sur xfs.

      Puis, comme tu le mentionnes, Fedora est lié à Red Hat oui, mais Fedora a aussi sa propre gouvernance et ses propres choix.

      Déjà il faut comprendre que les problématiques sont différentes. RHEL est maintenu pendant 10 ans, et Red Hat doit fournir du support à des clients payants. Quitte à devoir corriger des bogues tordus ou ajouter des fonctionnalités pour que ce que le client souhaite soit faisable.

      Cela demande une certaine expertise. Que Red Hat n'a apparemment pas.

      Fedora a moins de préoccupations de ce genre, la maintenance excède rarement les 13 mois, les noyaux sont toujours les dernières versions à trois semaines près et la maintenance est communautaire donc s'il y a des problèmes vraiment tordus ou des cas d'usage pas bien gérés ce n'est pas vraiment un problème. L'important est que les cas d'usages de base soient eux bien gérés et assez fiables ce qui est le cas.

      Ce n'est pas la première fois que Fedora introduit des changements sans que cela ne soit lié à une demande de Red Hat. Il n'y a pas de raison que Btrfs puisse arriver dans Fedora que si Red Hat est pour.

      • [^] # Re: btrfs, ce n'est à plus rien comprendre

        Posté par  . Évalué à 1.

        merci bien Sir

      • [^] # Re: btrfs, ce n'est à plus rien comprendre

        Posté par  (site web personnel, Mastodon) . Évalué à 4.

        On pourrait ajouter que le passage à Btrfs ne concerne que la version workstation de Fedora, quand la version serveur continue d'utiliser XFS. Et Red Hat, c'est tout de même majoritairement du serveur.

        • [^] # Re: btrfs, ce n'est à plus rien comprendre

          Posté par  . Évalué à 3.

          On pourrait ajouter que Fedora Workstation est maintenant pré-installé avec certains ordinateurs vendus dans le commerce : First Lenovo laptop with Fedora now available on the web! (c'est le blog du manager de l'équipe desktop chez Red Hat).

          Lenovo contribue à Fedora et à certaines couches bas-niveau pour que Fedora offre une bonne expérience utilisateur à ses clients.

          Alors, peut-être (ce n'est qu'une supposition) que c'est Lenovo qui voulait apporter Btrfs à Fedora Workstation. En attendant que Silverblue soit prêt pour le grand public. Silverblue apporte, notamment, un système robuste pour les rollbacks complets. Btrfs le permet également, dans une moindre mesure (en faisant des snapshots du système de fichier).

          OpenSUSE et SUSE utilisent aussi Btrfs, et c'est un concurrent principal de Red Hat. Ça pourrait être une autre raison.

    • [^] # Re: btrfs, ce n'est à plus rien comprendre

      Posté par  . Évalué à 2.

      Alors, oui je sais, que fedora et centos/RHEL sont différent, […]

      Tu aurais pu dire "fedora et centos et RHEL" :-) (certes, centos s'appuie sur les sources de RHEL, mais il y a une structure, une gouvernance et une communauté dédiées)

      mais c'est quand même lié.

      Pour illustrer les propos de Renault, je cite le FPL lors d'un AMA sur Reddit :

      I guess the major misconceptions relate to Red Hat and Fedora.

      First, Fedora is not just a beta for Red Hat Enterprise Linux. We do a lot of thing RHEL just plain isn't interested in, and set our own direction. As a very important downstream made by our major sponsor (including things like paying my salary), RHEL is a key stakeholder, but Fedora is so much more than that.

      Second and related, all of the crazy conspiracy theories about Red Hat either forcing Fedora to do some thing, or dominating other distros, or whatever — they're really silly. From an in-the-company perspective, there's plenty of politics and problems just as in any company, but most of it is 180° (or 270° or 32° or whatever) from the online imagination.

      And third, Fedora definitely isn't just Red Hatters. Of the core 300-or-so people in the project (out of 3000-or-so who contribute something every year), about ⅓ are Red Hatters and the rest from elsewhere.

    • [^] # Re: btrfs, ce n'est à plus rien comprendre

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      Btrfs pour les postes de travail, Xfs pour les serveurs.

      Et sinon Red Hat utilise Fedora comme lab des technos qu'elle développe ou soutient, mais depuis quelques années Fedora a sa propre gouvernance si j'ai bien compris. L'un n'empêche pas l'autre car les trucs poussés par la maison mère ne sont juste pas mis en avant (Fedora faisant des choix d'intégration et de packaging orienté usage de-base/domestique/bureautique) mais restent ainsi testables par un grand nombre. Ce qui est retenu par contre par la maison mère (dans RHEL, la version entreprise donc, puis CentOS tous deux orientés serveurs/entreprise) sera maintenu sur du très long terme (et ils vendent du support dessus via les souscriptions pour RHEL)

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # Merci

    Posté par  (site web personnel) . Évalué à 5. Dernière modification le 30 octobre 2020 à 10:08.

    merci pour cette dépêche sur le nouveau GNOME !

    (vu qu'il n'y en a plus des autonomes, c'est sympa d'avoir la tienne en rattrapage :)
    Bon, sinon c'est toujours sympa de voir aussi les choix d'intégration de Fedora ;)

  • # état de Wayland ?

    Posté par  . Évalué à 2.

    Où en est-on niveau Wayland ? Je sais que c'est par défaut depuis un moment mais est-ce qu'on est arrivé à un point où ça fonctionne mieux que X.org ? (fonctionnalité, performance, stabilité, …)

    • [^] # Re: état de Wayland ?

      Posté par  . Évalué à 4.

      Que veux-tu dire "mieux" ? Si c'est intégré (depuis plusieurs versions comme tu l'as dit) c'est que Wayland remplace sans aucun problème Xorg.

      • [^] # Re: état de Wayland ?

        Posté par  (Mastodon) . Évalué à 4.

        c'est que Wayland remplace sans aucun problème Xorg.

        Dans vraiment tous les cas d'utilisation ?

        • [^] # Re: état de Wayland ?

          Posté par  . Évalué à 1.

          Je reformule : qu'est-ce que tu crois qui manque à Wayland ? Depuis qu'il est par défaut sous Fedora je n'ai jamais eu besoin de retourner sous X.org.

          • [^] # Re: état de Wayland ?

            Posté par  . Évalué à 4.

            Je crois que tu as mal compris ce que j'ai dis.
            Je demande ce que Wayland apporte de concret (pour le moment) comparé à Xorg. On ne passe pas des années de transition de l'un vers l'autre juste pour avoir la même chose

            • [^] # Re: état de Wayland ?

              Posté par  . Évalué à 5.

              Alors ma question reste. On a envie de croire que vous semblez déçu mais on ne sait absolument rien en quoi.
              Qu'est-ce qu'apporte Wayland ? On l'a dit de nombreuses fois par le passé : sécurité et fluidité* pour l'utilisateur final ; maintenabilité du code pour les développeurs.

              *fluidité ne veut pas dire plus performant : en faisant des tests comparatifs entre Xorg et Wayland, j'ai effectivement plus de fps sous Xorg, mais rien d'extraordinaire, mais j'ai plus d'impression de fluidité sous Wayland, pourquoi ? Parce que le phénomène de "tearing" (image qui semble "déchirée") est très présent sous Xorg, pas sous Wayland ! Et je ne parle pas forcément en jeu vidéo, il suffit de tester le scrolling sous Firefox…

              • [^] # Re: état de Wayland ?

                Posté par  . Évalué à 4.

                Sécurité ok, maintenabilité du code ok c'est déjà pas mal. Fluidité honnêtement je ne perçois aucune différence entre les deux même en scrollant sous Xorg. En fait je serais incapable de savoir sous Gnome si je suis sous l'un ou l'autre sans regarder la liste des processus.
                Pour l'instant, au bout de plusieurs années de migration, les apports de Wayland a l'utilisateur final sont assez faibles. Ce n'est pas une critique mais une constatation.

                • [^] # Re: état de Wayland ?

                  Posté par  . Évalué à 8.

                  Le gros avantage pour l’utilisateur, c’est la sécurité. Une application ne peut plus espionner une autre (par exemple, votre client mail ne peut plus lire les entrées que vous faites sur votre password manager). Il y a aussi tout ce qui touche aux DPI, il est possible d’avoir des ratios non multiple d’entier entre deux écrans, ça évite d’avoir des fenêtres gigantesque ou minuscule sur l’écran externe branché au PC portable.

                  Un point accessoire, Wayland permet d’avoir des écrans non rectangulaire, ça permettrait de l’utiliser sur des montres par exemple.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                  • [^] # Re: état de Wayland ?

                    Posté par  . Évalué à 1.

                    Le gros avantage pour l’utilisateur, c’est la sécurité. Une application ne peut plus espionner une autre

                    C'est tellement sécurisé et qu'il est impossible de partager ton écran en appel slack / teams / tout ce que tu veux. Donc professionnellement la première chose que font les gens c'est se virer wayland et de remettre XOrg. Gros pas en avant :(

                    Wayland semble stagner fortement depuis des années. Peut être que l'approche était finalement trop "simpliste" et montre maintenant ses limites ?

                    • [^] # Re: état de Wayland ?

                      Posté par  . Évalué à 6.

                      C'est tellement sécurisé et qu'il est impossible de partager ton écran en appel slack / teams / tout ce que tu veux.

                      Ça tombe bien, je veux partager avec Google Meet et ça marche https://wiki.archlinux.org/index.php/PipeWire#WebRTC_screen_sharing Bon, c'est loin d'être sec, mais ça arrive. De mon côté, j'utilise toujours Xorg parce qu'il y a des fonctionnalités de ce genre qui ne sont pas encore prêtes pour la prod (je pense que c'est comme Pulseaudio, ça n'était pas prêt pour être par défaut dans les distrib généralistes mais uniquement celles qui se veulent bac à sable de fonctionnalités comme Fedora). Mais ça ne veut pas dire que ce n'est pas en train de se mettre en place.

                      Wayland semble stagner fortement depuis des années. Peut être que l'approche était finalement trop "simpliste" et montre maintenant ses limites ?

                      Tu dis ça à quel niveau ? Il y a pas mal de développement toujours en cours.

                      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                      • [^] # Re: état de Wayland ?

                        Posté par  . Évalué à 6.

                        Ça tombe bien, je veux partager […] Bon, c'est loin d'être sec, mais ça arrive

                        Merci pour le lien. J'irais regarder du côté de xdg-desktop-portal et pipewire, mais d'un point de vu utilisateur ne pas avoir cette possibilité 10 ans après le début du projet et 4 ans après que Wayland soit par défaut sur Fedora ca fait tout de même mal

                        Tu dis ça à quel niveau ?

                        Ex. https://news.ycombinator.com/item?id=24884988

                        Il me semble y avoir le sentiment qu'après toutes ces années Wayland n'a pas apporté grand chose alors que l’accueil initial était très favorable. Ca fait la même chose qu'avant, en dehors d'un nombre encore significatif de régressions. Les performances sont globalement les mêmes (j'ai un utilisateur sous Wayland et un autre sous XOrg sur la même machine et je suis incapable de dire la différence). Ca fait 10 ans que c'est en chantier et qu'on a demandé à tout le reste de la pile graphique de refaire dans son coin ce qui a été viré du serveur.

                        Je suis totalement incompétent pour juger des choix, de l'architecture et de la pertinence de ma perception. En tant qu'utilisateur le constat ne me semble pas fou.

                        À côté, Pulseaudio marche sans problème depuis des années, fait ce que je lui demande et le progrès par rapport à avant est sans appel.

                        • [^] # Re: état de Wayland ?

                          Posté par  (site web personnel) . Évalué à 10.

                          Il me semble y avoir le sentiment qu'après toutes ces années Wayland n'a pas apporté grand chose alors que l’accueil initial était très favorable.

                          Le but de Wayland n'est pas de faire une révolution extraordinaire, mais de repenser la base du système pour améliorer son évolution à venir.

                          X11 faisait de nombreuses choses bien mais avaient aussi de nombreux défauts intrinsèque, le but est surtout de corriger ses défauts. Pas d'apporter des killers features que le quidam moyen pourrait voir directement.

                          Et ce n'est pas facile de changer un composant central qui a posé des bases de la pile graphique depuis 30 ans. Cela impact de nombreux projets et cas d'usage qu'il faut revoir et corriger aussi. Car le fait par exemple que X11 autorise l'accès à tout simplifie de nombreuses fonctionnalités : capture d'écran / vidéo, gestion centralisée du presse papier, économiseur d'écran qui devient trivial à écrire, mode nuit qui le devient également, les outils d'accessibilité peuvent facilement faire ce qu'ils veulent, etc. Il faut donc tout repenser l'architecture de ces composants nombreux et et ce n'est pas trivial. Cela prend du temps, surtout que c'est assez récent finalement que Wayland est massivement adopté, plus de la moitié des 10 ans dont tu parles c'est du travail de l'ombre qui n'a impliqué que les personnes vraiment motivées par ce projet et pas ceux qui étaient impactés par cela.

                          Ca fait la même chose qu'avant, en dehors d'un nombre encore significatif de régressions.

                          Il y a des régressions oui, mais de moins en moins. Après Wayland apporte des choses que X11 n'avait pas. Je veux dire, la sécurité de sa conception n'est pas un détail. Mais c'est oublier aussi tous les bogues bizarres et difficilement solubles qu'avait X11 et que Wayland n'a pas. Ou encore certaines technos modernes que X11 ne gère pas bien comme les écrans HiDPI qui sont de plus en plus nombreux.

                          Bref, rien qui ne mérite un Waouh d'un utilisateur lambda, mais ce n'est pas rien. Et Wayland n'a jamais promis de révolutionner le système à ce point, peut être que tu as un peu trop fantasmé sur ce qu'allait apporter ce projet.

                          Les performances sont globalement les mêmes (j'ai un utilisateur sous Wayland et un autre sous XOrg sur la même machine et je suis incapable de dire la différence).

                          Le but de Wayland, comme systemd d'ailleurs, n'était pas d'améliorer la vitesse mais que cela pourrait être un gain collatéral grâce à sa conception différente et plus proche des attentes d'un système graphique moderne.

                          Dans certaines configurations ou cas d'usage cela ne se verra évidemment pas.

                        • [^] # Re: état de Wayland ?

                          Posté par  . Évalué à 4. Dernière modification le 01 novembre 2020 à 22:22.

                          Ex. https://news.ycombinator.com/item?id=24884988

                          Ça parle de Xorg. Sauf si tu link un commentaire particulier.

                          À côté, Pulseaudio marche sans problème depuis des années, fait ce que je lui demande et le progrès par rapport à avant est sans appel.

                          Pourtant, au début, il apportait plus de problème que de progrès.

                          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                          • [^] # Re: état de Wayland ?

                            Posté par  . Évalué à 2.

                            Ça parle de Xorg. Sauf si tu link un commentaire particulier.

                            La commentaires étaient globalement sur Wayland que j'ai lu. C'est plus pour prise de température sur la perception de Wayland par diverse personnes.

                            Pourtant, au début, il apportait plus de problème que de progrès.

                            Perso, jamais eu de problème avec Pulseaudio.

                            L'exemple était simplement pour souligner que globalement systemd et pulseaudio ont été accueilli avec beaucoup d'hostilité. À l'inverse Wayland était plutôt attendu et a été bien accueilli lors de son annonce, mais cela ne semble plus aussi net.

                            • [^] # Re: état de Wayland ?

                              Posté par  . Évalué à 6.

                              C'est plus pour prise de température sur la perception de Wayland par diverse personnes.

                              Je ne suis pas sûr que ton échantillon soit très représentatif

                              Wayland était plutôt attendu et a été bien accueilli lors de son annonce, mais cela ne semble plus aussi net.

                              On ne doit pas vivre dans le même monde. Depuis le début, il est attaqué parce qu'il ne sert à rien, parce que X est mieux, parce qu'il ne respecte pas la philosophie Unix…

                              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                        • [^] # Re: état de Wayland ?

                          Posté par  . Évalué à 2.

                          Peut-être parce que plus personne ne veut maintenir Xorg

                          It's Time To Admit It: The X.Org Server Is Abandonware

                          https://www.phoronix.com/scan.php?page=news_item&px=XServer-Abandonware

                    • [^] # Re: état de Wayland ?

                      Posté par  (site web personnel) . Évalué à 3.

                      il est impossible de partager ton écran en appel slack / teams / tout ce que tu veux

                      Je ne sais pas bien ce que tu entends pas "partager" mais si c'est diffuser un bureau ou une application wayland, moi cela marche sur firefox/jit.si.

                    • [^] # Re: état de Wayland ?

                      Posté par  (Mastodon) . Évalué à 3. Dernière modification le 02 novembre 2020 à 09:39.

                      chezmoiçamarche.com

                      Jette ta distrib pourrite. Nore: j'utilise la version web de slack et teams, par leurs applis merdiques.

          • [^] # Re: état de Wayland ?

            Posté par  (site web personnel) . Évalué à 1.

            La capacité à redémarrer le shell seul quand on a un souci avec Gnome par exemple ?

            Et après, pas lié à Wayland directement, mais certaines applications ont encore des comportements relativement erratiques, Eclipse en tête.

            • [^] # Re: état de Wayland ?

              Posté par  . Évalué à 0.

              Pas de souci, je peux comprendre qu'il y ait des problèmes, simplement, se plaindre et ne pas exposer les problèmes ? Et ce sont des personnes comme moi qui devrions exposer ces problèmes ? Là je ne comprends pas.

              Sinon oui, le Alt+r me manque aussi, mais… un petit redémarrage n'a tué personne ? Si ?

              Sinon un petit comparatif (plus objectif que vous et moi) sur le sujet :
              https://www.phoronix.com/scan.php?page=news_item&px=GNOME-Xorg-Wayland-AMD-Renoir

              • [^] # Re: état de Wayland ?

                Posté par  . Évalué à 4.

                un petit redémarrage n'a tué personne ? Si ?

                Windows Me le faisait il y a 20 ans ! Grâce à Wayland, Linux bientôt prêt pour le Desktop !

                • [^] # Re: état de Wayland ?

                  Posté par  . Évalué à -2. Dernière modification le 01 novembre 2020 à 12:18.

                  Caricature grotesque qui n'a aucun sens. On redémarre toujours autant sous Windows 10 lors de mises à jour (je le sais sur le PC de mon entreprise).
                  Et j'avoue m'être mal exprimé : il suffit de fermer sa session pour réouvrir derrière. Donc pas besoin de redémarrage.
                  Je constate un point : les critiques sur Wayland (voire sur Linux-même de ce que je lis) ne relève que du troll…

              • [^] # Re: état de Wayland ?

                Posté par  . Évalué à 5.

                Sinon oui, le Alt+r me manque aussi, mais… un petit redémarrage n'a tué personne ? Si ?

                En lien avec le Alt+r :

                Quand gnome-shell plante sous Wayland, les applications plantent avec. Donc, ça ne tue personne, mais ça peut tuer des applications (et les données qui vont avec).

                Tandis que quand gnome-shell plante sous X11, gnome-shell est redémarré automatiquement. gnome-shell n'étant qu'un client X11 parmi d'autres.

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

                • [^] # Re: état de Wayland ?

                  Posté par  (Mastodon) . Évalué à 1.

                  Ça arrive combien de fois dans ta vie que gnome-shell plante?

                  Les rares fois où le mien plantait c'était quand j'utilisais cette bouse de display link pour ma docking station, depuis que j'ai arrêté de l'utiliser tout va bien.

                • [^] # Re: état de Wayland ?

                  Posté par  . Évalué à 3.

                  C'est que la conception de Gnome (ou de KDE) n'essaie pas particulièrement d'être robuste, il y a arcan https://arcan-fe.com/about/ qui montre qu'il est possible d'être robuste au dessus de Wayland, maid par défaut ça n'est pas le cas..

    • [^] # Re: état de Wayland ?

      Posté par  . Évalué à 4.

      État de Wayland ? Le Massachusetts, évidemment !

      (Le nom « Wayland » a été choisi par son créateur, vivant dans les environs de cette ville aux États-Unis ;-)

      https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#History

      Høgsberg was driving through the town of Wayland, Massachusetts when the underlying concepts "crystallized", hence the name.

  • # Fedora IoT

    Posté par  . Évalué à 2.

    Apparemment c'était plus ou moins lancé avec Fedora 32 mais maintenant c'est plus qu'officiel. D'ailleurs ça supporte le RPi. Quelqu'un a essayé ?

    • [^] # Re: Fedora IoT

      Posté par  (site web personnel) . Évalué à 7.

      Attention, l'image IoT était officielle avec Fedora 32, mais ce n'était pas une édition officielle. C'est-à-dire que maintenant s'il y a un bogue important qui empêche son utilisation, la sortie d'une nouvelle version de Fedora peut être différée. Avant l'image était générée officiellement mais s'il y avait un problème important, cela n'avait pas d'impact.

Suivre le flux des commentaires

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