En ce mardi 29 octobre, les utilisateurs du Projet Fedora seront ravis d'apprendre la disponibilité de la version Fedora 31.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, X.Org, systemd, la célèbre suite de compilateurs GCC, etc. Cliquez ici pour voir l’ensemble des contributions de Red Hat.
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 LiveCD, 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.
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 à très haute définition. Cela apporte en outre :
- la gestion de la synchronisation verticale pour le rafraichissement 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.
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èmes 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.
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.
Firefox utilise Wayland nativement par défaut avec GNOME. Cela 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.
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 l'utilisation d'un Client-Side Decorations pour définir la décoration des fenêtres ce qui n'était pas possible avec Qt jusqu'ici. Les décorations de fenêtre proviennent du programme QGnomePlatform.
Les paquets RPM utilisent le format de compression zstd au lieu de xz. Le temps de décompression est bien 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 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 architectures plus émergentes comme AArch64. Les utilisateurs concernés sont invités soit à utiliser une image x86_64 si leur matériel le leur permet, ou alors à envisager de changer de distribution d'ici la fin du support de Fedora 30.
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é.
Sur les machines avec la fonctionnalité Secure Boot de l'UEFI activé, 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
Les paquets langpacks sont subdivisés avec une partie langpacks-core qui ne propose que la police par défaut et la locale correspondante. Les polices additionnelles tout comme les traductions complètes, comme celle de LibreOffice, nécessitent l'installation du paquet langpacks correspondant. L'utilisateur a donc plus de flexibilité à ce niveau pour bénéficier d'un support minimal d'une langue.
Mise à jour d'IBus 1.5.21. Cette version repousse les raccourcis de composition de 7 touches à 255 touches. De plus, IBus permet maintenant l'écriture de caractères représentés par 4 octets au lieu de 2 octets jusqu'ici. Il rejoint ainsi X11 en termes de possibilités de saisis.
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
Le binaire /usr/bin/python fait référence dorénavant à 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'à leur fin de vie respective, c'est-à-dire vers juin et décembre 2020. Python 2 sera par contre totalement supprimé pour Fedora 32. Cette décision permet de garder une compatibilité fonctionnelle importante au sein d'une même version de Fedora.
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 hashage SHA1 et MD5 ou d'exiger au minimum TLS 1.3.
Le noyau propose les cgroups 2 au lieu de la version 1 utilisée jusqu'alors. Pourtant cette version est disponible dans le noyau de manière stable depuis près de 3 ans déjà, mais n'était pas assez éprouvée par l'espace utilisateur. Cette version corrige les défauts de jeunesse de cgroups v1 en éliminant des comportements étranges comme des threads 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 conteneurs 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 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.
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é.
Le compteur RPM atteint la version 4.15. Cette version apporte un meilleur parallélisme pour les tâches de compilation. De nombreux rapports d'erreurs 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 émettra une erreur par défaut si un dépôt est non accessible 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 et 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'information 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, seuls des liens symboliques vers DNF sont maintenus. Son API n'est également plus accessible.
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 quelques temps.
Développement
Mise à jour de la bibliothèque C glibc vers la version 2.30. Cette version propose la prise en charge de Unicode 12.1.0, les appels systèmes 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. Cette version corrige essentiellement de nombreux bogues. Son moteur d'expressions régulières récupère celui de GNULIB ce qui met fin à une grosse activité de maintenance. Mais surtout il prend en charge les espaces de nom. L'espace de nom par défaut étant awk. La compatibilité ascendante n'est pas totalement garantie avec cette mise à jour.
Node.js en est à son 12e 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ées par défaut. Le nouveau parseur HTTP expérimental llhttp a été ajouté. Et bien entendu de nombreux autres correctifs plus mineurs.
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 HTML5.
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.
Le langage Go fonce vers 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. Il 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 régulières tiennent compte partiellement d'Unicode, par exemple [0-5] peut correspondre évidemment aux chiffres 0 à 5 dans les langues latines, mais aussi à leurs équivalents dans d'autres alphabets.
Mise à jour du langage Erlang et OTP à 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 terme d'optimisation, il prend en charge le Erlang Distribution Protocol qui scinde les gros paquets en paquets plus petits pour éviter de bloquer. Fedora a spécifiquement travaillé pour migrer les journaux des applications Erlang vers journald et d'utiliser D-Bus grâce à erlang-dbus pour avoir un système toujours plus cohérent.
Alors que 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 l'underscore comme séparateur de milliers. Et beaucoup de corrections encore.
La pile .Net libre Mono bénéficie de la version 5.20. Cette mise à jour comporte principalement l'ajout de Security Support Provider Interface pour établir une connexion à une base de données SQL. Et le reste est essentiellement de la correction de bogues.
L'environnement et la chaîne de compilation MinGW passent la 6e. MinGW qui permet de compiler des binaires Windows depuis 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. Le runtime C est aussi complété pour une meilleure compatibilité.
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 :
| Code : | Sélectionner tout |
$ update-alternatives --set ld /usr/bin/lld
| Code : | Sélectionner tout |
$ update-alternatives --set ld /usr/bin/ld.bfd
L'éditeur de lien GOLD de binutils, développé par Google, mais maintenu par GNU maintenant 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
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.
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 QA 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.
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.
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 maintenant ils disposent 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.
Les dépendances autour du langage R au runtime peuvent maintenant être résolues automatiquement. En effet les modules R décrivent les dépendances dans les métadonnées, mais cette information n'était pas jusqu'ici exploitée. Maintenant cette information est collectée et assignée automatiquement dans la source RPM du paquet. Cela simplifie la charge de travail et réduit les erreurs de maintenance.
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 bon à 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 Mo à télécharger au lieu de 77 Mo et passe de 339 Mo à 249 Mo 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.
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 leur architecture de base qui les précède à 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, leur équivalent 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.
Maintenant 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
Borsalinux-fr est l'association qui gère la promotion de Fedora dans l'espace francophone. Nous constatons depuis quelques années une baisse progressive des membres à jour de cotisation et de volontaires pour prendre en main les activités dévolues à l'association.
Nous lançons donc un appel à nous rejoindre afin de nous aider.
L'association est en effet propriétaire du site officiel de la communauté francophone de Fedora, organise des évènements promotionnels comme les Rencontres Fedora régulièrement et participe à l'ensemble des évènements majeurs concernant le libre à travers la France principalement.
Si vous aimez Fedora, et que vous souhaitez que notre action perdure, vous pouvez :
- Adhérer à l'association : les cotisations nous aident à produire des goodies, à nous déplacer pour les évènements, à payer le matériel ;
- Participer sur le forum, les listes de diffusion, à la réfection de la documentation, représenter l'association sur différents évènements francophones ;
- Concevoir des goodies ;
- Organiser des évènements type Rencontres Fedora dans votre ville.
Nous serions ravis de vous accueillir et de vous aider dans vos démarches. Toute contribution, même minime, est appréciée.
Si vous souhaitez avoir un aperçu de notre activité, vous pouvez participer à nos réunions hebdomadaires chaque lundi soir à 20h30 (heure de Paris) sur IRC (canal #fedora-meeting-1 sur Freenode).
Vous pouvez aussi nous rencontrer lors du prochain Paris OpenSource Summit le 10 et 11 décembre (c'est 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 5 années de retard accumulées sur le sujet.
Le moins que l'on puisse dire, c'est que le travail abattu est important : près de 90 articles corrigés et remis au goût du jour.
Un grand merci à Charles-Antoine Couret, Nicolas Berrehouc, Édouard Duliège, José Fournier et les autres contributeurs et relecteurs pour leurs contributions.
L'équipe se réunit tous les lundis soir après 21h (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 ?
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.
Liens
