Parution de Fedora 27

En ce mardi 14 novembre 2017, le projet Fedora est fier d’annoncer la sortie de la distribution GNU/Linux Fedora 27.

Fedora est une distribution communautaire développée par le projet éponyme 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.

Sommaire

• Environnement bureautique
• Gestion du matériel
• Administration système
• Développement
• La modularité
• Autour de Fedora
• La communauté francophone
  • L’association
  • La documentation

Environnement bureautique

GNOME est toujours à l’honneur avec sa version 3.26. C’est une version essentiellement de polissage et de stabilité avec :

• la barre principale qui devient transparente, si aucune fenêtre n’est maximisée ;
• de nouvelles animations, plus fluides, en cas de redimensionnement ou de mouvement des fenêtres ;
• la recherche globale fonctionne sur des actions du système (comme Éteindre) et affiche plus de résultats à la fois ;
• les paramètres du système bénéficient d’une refonte complète de l’interface ;
• le logiciel Disques peut enfin redimensionner les partitions, Agenda prenant en charge les évènements récurrents et Web acceptant la synchronisation depuis Firefox Sync ;
• le logiciel de virtualisation Machines peut télécharger et lancer automatiquement une RHEL gratuite ;
• amélioration des performances pour quelques applications ou GNOME en général.

Remplacement de l’interface graphique de gestion de paquets Yumex par dnfdragora qui propose une interface Qt, GTK+ et ncurses. Le développement de Yumex s’est arrêté il y a un an. Cela met fin à une application ayant accompli dix ans de bons et loyaux services et a même su migrer de yum vers dnf. dnfdragora présente la particularité de reposer sur rpmdragora, qui vient de Mageia.

Mise à jour de libpinyin vers la version 2.1 pour les entrées de saisie en chinois. Cette version consiste essentiellement dans la fusion avec la bibliothèque libzhuyin qu’il remplace. Cela apporte la prise en charge du chinois Zhuyin pour la saisie rapide dans cette langue.

La mise à disposition des polices de caractères Serif pour le chinois par défaut. Jusqu’ici Fedora fournissait surtout des polices Sans pour le chinois. Mais depuis la libération de certaines polices de la part d’Adobe et de Google, il est dorénavant possible de fournir des polices de caractères Serif convenables pour ces utilisateurs nativement.

Gestion du matériel

Fedora propose une image unique pour l’architecture AARCH64 (ARM 64 bits) ce qui rejoint la solution proposée pour les cartes disposant d’un ARMv7. Pour l’instant cette image prendra en charge les cartes suivantes :

• Pine64 (et ses variantes) ;
• Raspberry Pi 3 (mode 64 bits) ;
• 96boards HiKey ;
• 96boards Dragonboard 410c ;
• ARM Juno.

L’offre des cartes prises en charge s’étoffera dans le temps, de même que la mise à disposition des versions personnalisées de Fedora.

Toujours à propos du matériel, Fedora a travaillé pour avoir une meilleure gestion des systèmes monopuces Intel Bay Trail et Cherry Trail (essentiellement des puces Pentium, Celeron et Atom sur portables et tablettes). Le travail a consisté en l’amélioration de la surveillance de la batterie (consommation actuelle, temps restant sur batterie, savoir si la machine est en charge ou non) et de la gestion de l’audio. Les écrans tactiles et les accéléromètres seront également mieux détectés et donc exploitables par le système et les applications.

Fedora 27 peut enfin tourner sur les ordinateurs ayant un micrologiciel UEFI 32 bits tout en ayant un processeur 64 bits. Cela consiste en l’installation d’un amorceur GRUB 32 bits (chargé par l’UEFI lui‐même) qui lui‐même charge un noyau et l’espace utilisateur en 64 bits. Cette configuration, assez atypique, a nécessité un travail sur GRUB, Anaconda et les utilitaires EFI pour les prendre en charge. Fedora sera ainsi installable sur ces configurations comme l’Asus Transformer T100TA, le HP Stream 7, le Dell Venue 8 Pro 5830 et les premiers Macintosh Intel d’Apple.

Administration système

Suppression du script 256term.sh (/etc/profile.d/256term.sh et /etc/profile.d/256term.csh) qui changeait la valeur de la variable $TERM pour activer les couleurs dans les terminaux selon le terminal employé. Maintenant, ce sont les émulateurs de terminal qui s’en chargent directement, ce qui rend la procédure plus reproductible, plus simple et plus rapide, car le script n’est plus exécuté pour chaque nouveau shell.

Activation de l’option TRIM pour les nouvelles partitions chiffrées avec LUKS1. L’option TRIM permet aux unités de stockage SSD de connaître les cellules mémoire utilisées par le système de fichiers afin de pouvoir contrôler l’usure des cellules au mieux en conservant les performances en écriture dans le temps. Les SSD étant de plus en plus populaires, il a été décidé d’activer cela par défaut pour les partitions chiffrées, ce qui aurait un impact négligeable pour ceux qui utilisent un disque dur. Cela consiste à l’ajout natif de l’option discard dans /etc/crypttab. Le manque de place dans les métadonnées de LUKS1 explique pourquoi cela ne concerne que les nouvelles partitions.

Nouveau système de cache par défaut pour les identifiants Kerberos nommé KCM. C’est le quatrième système de cache à ce sujet, le premier était basé sur les fichiers, le deuxième sur les répertoires et le troisième sur le porte‐clefs du noyau. Mais :

• celui basé sur les fichiers est, certes, largement pris en charge, mais il ne peut gérer plusieurs caches pour une même collection ;
• celui basé sur les répertoires corrige ce problème, mais cela nécessite son propre contrôle d’accès pour la gestion des répertoires, ce qui est délicat ;
• le dernier utilisant le noyau, il n’est pas adapté pour les environnements isolés (qui partagent le même noyau), ne bénéficiant pas des espaces de noms de l’utilisateur.

L’architecture ici change énormément. Cela va reposer sur un principe client‐serveur où l’application qui utilise Kerberos, comme kinit, va communiquer avec un serveur KCM comme sssd. Jusqu’alors, seul Heimdal Kerberos implémentait un serveur KCM. Heimdal et MIT ont implémenté un client KCM dans libkrb5. Fedora a proposé d’inclure un serveur KCM dans SSSD, plutôt qu’un démon isolé, pour bénéficier de l’API D-Bus qu’emploie SSSD afin que, par exemple, une application graphique puisse recevoir les notifications associées, la possibilité de sauvegarder des données secrètes facilement pour exploiter à nouveau le cache en cas de redémarrage et un accès facile à l’authentification de SSSD côté utilisateur, qui est également bien testé.

libcurl réutilise OpenSSL pour la cryptographie et le protocole TLS au lieu de NSS. En effet, il y a dix ans, c’était la décision inverse que le projet Fedora avait actée. L’objectif de ce revirement est de permettre la conception d’images de base de Fedora plus légères (dans le cadre des conteneurs, entre autres). Cela facilite la possibilité d’enlever NSS dans ce genre de contexte nativement. En revanche, l’inconvénient est que libcurl ne peut plus exploiter nativement les bases de données de certificats de NSS, dont ceux fournis avec Firefox. Une exportation est nécessaire pour cela.

Le serveur OpenVPN utilise un nouvel algorithme de chiffrement par défaut, qui est AES-256-GCM au lieu de BF-128-CBC, améliorant la sécurité des connexions. En effet, il y a un an, avec l’attaque SWEET32, il a été révélé que les blocs chiffrés d’une taille de 128 bits et inférieure sont vulnérables. La nouvelle politique passant par défaut à 256 bits, cela évite le problème. Le changement consiste dans la liste d’options par défaut du service openvpn qui était :

   ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --config %i.conf

devenant :

   ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --cipher AES-256-GCM --ncp-ciphers  AES-256-GCM:AES-256-CBC:AES-128-GCM:AES-128-CBC:BF-CBC --config %i.conf

Comme vous le voyez, dans la nouvelle version, AES-256-GCM est employé par défaut mais, en cas de clients non compatibles (versions 2.3 et inférieures), il reste possible d’employer BF-128-CBC ou un autre algorithme compatible par une classique négociation au début de la connexion. Ainsi, la compatibilité reste préservée au maximum, tout en améliorant la sécurité par défaut des clients qui en sont capables.

Le serveur OpenSSH rejoint la politique centralisée des mots de passe, comme le client OpenSSH, GnuTLS, NSS, OpenSSL et OpenJDK avant lui. En effet, depuis quelques versions de Fedora, les utilitaires pouvant avoir une politique de mots de passe, par exemple de huit caractères avec au moins un chiffre et deux majuscules, bénéficient peu à peu de l’unification de cette politique. En définissant la politique une fois via l’utilitaire update-crypto-policies, elle sera disponible pour l’ensemble des applications compatibles.

Suppression du protocole SSH-1 dans les clients OpenSSH. Ce protocole, de vingt ans d’âge, n’était plus sécurisé. Par ailleurs, le projet OpenSSH va supprimer prochainement l’ensemble du code le concernant. Fedora ne le compilait plus dans le binaire standard depuis deux ans, mais le protocole subsistait dans le paquet de compatibilité openssh-clients-ssh1 qui sera supprimé. Cela améliorera la sécurité globale du système en réduisant la surface d’attaque disponible.

Les paquets officiels ayant besoin de Java n’utiliseront plus la variable $PATH pour retrouver la JVM à employer mais directement la JVM fournie par défaut par Fedora (OpenJDK). La méthode employée nativement pour exécuter les applications Java jusqu’à Fedora 26 consistait à :

• lire le fichier /etc/java/java.conf ;
• si la variable d’environnement $JAVA_HOME existait, charger la JVM qu’elle pointait ;
• si cette même variable était définie dans le fichier de configuration, faire de même ;
• tenter de trouver via la variable $JVM_ROOT qui valait par défaut /usr/lib/jvm ;
• en dernier recours, utiliser directement la variable $PATH.

Cette méthode est plutôt complexe et risquée. Un utilisateur pour installer durablement une version alternative de la JVM devait être superutilisateur (pour agir sur l’avant‐dernière étape) ou pouvait modifier deux variables d’environnement qui changeaient la JVM d’exécution de référence pour les applications fournies par Fedora. Applications qui ne sont peut‐être pas compatibles avec la JVM réclamée par les applications de l’utilisateur.

La méthode actuelle consiste à supprimer la dernière étape (pour les applications système). L’utilisateur pourra jouer sur la variable $PATH pour spécifier la JVM de référence pour ses applications. L’administrateur système pourra toujours changer la JVM pour les applications système via la variable $JAVA_HOME ou le fichier de configuration mentionné plus haut.

Suppression des paquets krb5-appl-clients et krb5-appl-servers qui ne seront bientôt plus officiellement maintenus et ne sont plus assez sécurisés aujourd’hui. Pour la petite histoire, ces paquets n’ont plus été touchés depuis 2013 par le projet Fedora. Et ces paquets n’ont rien reçu de nouveau depuis 2010 par le projet d’origine.

Ajout de Samba AD pour la gestion d’un Active Directory. Si FreeIPA et Samba traditionnel sont déjà employés pour déployer les contrôleurs de domaine, ils n’étaient pas capables de gérer les enregistrements et la gestion des clients Windows 8 et supérieurs. Et, jusqu’ici, il était impossible de compiler Samba AD avec MIT Kerberos (employé par Fedora, Debian et Ubuntu exploitant Heimdal Kerberos).

Samba AD est une bonne alternative à l’implémentation de référence de Microsoft. Il serait capable de gérer des déploiements de centaines de milliers d’utilisateurs par groupe sur plusieurs sites. Et ce, avec un matériel considéré comme peu cher, ce qui le rend intéressant pour les petites et moyennes structures. L’interopérabilité avec FreeIPA a été également améliorée ce qui permet aujourd’hui d’employer des environnements entièrement sous Fedora dans ce cadre.

Mise à jour de RPM à la version 4.14. Au menu de ce composant central, des erreurs plus lisibles et pertinentes, une meilleure fiabilité en désactivant les signaux durant une opération d’écriture, ou avec une fonction de rappel plus sûre si la base de données principale est ouverte. La compatibilité avec les compilations reproductibles est améliorée. Il peut également utiliser OpenSSL pour les opérations cryptographiques. Et l’écart entre le RPM officiel et celui de Fedora s’est également réduit.

Développement

La bibliothèque standard Glibc progresse à la version 2.26. Cette version ajoute un cache par fil d’exécution pour malloc() ce qui améliore significativement les performances des allocations et suppressions de petites zones de la mémoire. Comme souvent, elle bénéficie de la dernière norme Unicode 10.0. Les architectures IA64, PowerPC64le, x86-32, et x86-64 peuvent gérer des nombres flottants sur 128 bits via le type float128. Et enfin, le résolveur DNS détecte les changements du fichier /etc/resolv.conf automatiquement pour le recharger à la volée.

La bibliothèque majeure du C++ Boost donne un coup de boost à la version 1.64. Elle ajoute une nouvelle bibliothèque process qui permet la création de processus enfants, de configurer leur flux d’entrées‐sorties, de communiquer avec eux de manière synchrone et asynchrone et, bien entendu, d’attendre et de tuer ces processus. Un changement de l’API de la partie Context est à noter. Puis, comme d’habitude, de nombreuses corrections de bogues dans l’ensemble de la bibliothèque.

Le serveur de rendu de JavaScript Node.js s’exécute à la version 8.6 LTS (au lieu de la branche 6.x). Cette nouvelle version majeure fournie async_hooks dans le module core. Elle ajoute expérimentalement une API Node pour garantir la compatibilité ascendante de l’ABI des modules natifs, afin d’éviter leur recompilation à chaque changement de node.js. Le module interne expérimental pour gérer le protocole HTTP/2 a été ajouté. Le moteur JavaScript V8 a été mis à jour à la version 6.0, plus proche donc de la version disponible dans Google Chrome avec une amélioration des performances.

La boîte à outils Web Ruby on Rails 5.1 est sur les rails. Parmi les changements annoncés, nous pouvons noter la possibilité d’utiliser NPM via Yarn pour résoudre les dépendances de JavaScript, ce qui simplifie l’usage de bibliothèques telles que React ou VueJS. Il devient possible d’utiliser Webpack via le gem Webpacker afin d’assembler les différents éléments de votre application dans un seul fichier JavaScript automatiquement. La bibliothèque jQuery n’est plus une dépendance obligatoire. Il devient possible de facilement insérer des données secrètes dans un fichier chiffré prévu à cet effet, mécanisme inspiré du gem sekrets. Et bien d’autres changements.

Le langage Go fonce à la version 1.9. Il devient possible de spécifier que deux types ont la même représentation via l’instruction type T1 = T2, où T1 est un alias de T2. L’instruction multiplication suivie d’une addition, qui est souvent optimisée par les processeurs modernes, supprime la nécessité de l’arrondi intermédiaire lors du calcul. Pour la réactiver, vous pouvez faire float64(x*y) + z, ce qui dégrade bien sûr les performances. La compilation des différents paquets se fait maintenant en parallèle. Le code généré est également plus rapide maintenant, le ramasse‐miettes est également plus performant. Le paquet time prend en charge nativement le temps monotonique pour éviter les problèmes de saut du temps (à cause d’une synchronisation NTP, par exemple). Enfin, ajout d’un nouveau paquet math/bits pour la manipulation des bits. Et d’autres corrections encore.

Le langage Perl a été poli à la version 5.26. Pour des raisons de sécurité, le répertoire courant . est supprimé de la recherche des chemins @INC pour éviter de charger des modules provenant d’un répertoire non sûr. Perl gère maintenant l’Unicode 9.0. Les sous‐routines lexicales ne sont plus expérimentales. Et d’autres changements plus mineurs ou de problèmes résolus.

Installer le paquet perl installera l’ensemble des modules core du projet officiel. Ce comportement est plus conforme vis‐à‐vis des autres distributions et de ce qui est attendu par les développeurs de Perl. Pour les utilisateurs qui souhaitent un environnement Perl plus léger, comme proposé avant par Fedora, vous pouvez vous rabattre sur le paquet perl-interpreter qui nécessite moins de modules par défaut.

La nouvelle version de la machine virtuelle OpenJDK danse la Java pour une neuvième fois. Bien entendu, après quelques années, Java se met à niveau avec l’inclusion d’Unicode 8.0, le portage vers l’architecture AArch64, l’utilisation de GTK+ 3 pour les interfaces graphiques sous GNU/Linux et l’ajout d’un client HTTP/2. Côté sécurité, Java prend en charge le protocole applicatif de négociation de TLS, et remplace la fonction cryptographique SHA-1 par SHA-3. OpenJDK devient plus modulaire, les modules standards sont placés derrière le préfixe java., les autres derrière jdk.. Et, bien entendu, tous les changements apportés par le langage Java 9 lui‐même.

Make sudo pip safe again! qui propose enfin un meilleur nettoyage lors de la désinstallation d’un module installé via pip et une meilleure séparation entre les modules de Fedora et ceux des utilisateurs. En effet, jusqu’ici, les modules installés via sudo pip install allaient s’installer au même endroit que les modules installés via dnf ce qui induisait un conflit entre les deux mécanismes. Pour régler ce problème, les modules installés sans dnf sont installés dans le dossier /usr/local/lib/pythonX.Y, ce qui est en plus conforme au standard Filesystem Hierarchy Standard (FHS).

Il est possible d’installer les paquets de débogage (les paquets debuginfo) en 32 bits et 64 bits pour une même application en même temps. Typiquement, sous Fedora x86_64, il est possible d’installer des paquets en 32 ou 64 bits, car il y a compatibilité ascendante de l’architecture. Dans certaines situations où les deux sont installés en parallèle, cas de nombreuses bibliothèques, il est possible de faire de même pour leurs informations de débogage. Cela simplifiera la tâche des développeurs et des testeurs pour identifier les problèmes des applications multi‐architectures.

Les paquets debuginfos sont scindés en debuginfos et debugsources. Le premier contient les binaires et autres bibliothèques avec les symboles de débogage, tandis que les seconds contiennent uniquement le code source du paquet. Cela permet non seulement de ne télécharger et installer que le strict nécessaire au débogage (les sources ne sont pas toujours requises) et va dans le sens d’harmoniser les pratiques autours du format RPM avec d’autres distributions.

La modularité

Création et mise à jour des outils dans le cadre de la Factory 2.0 pour permettre le découplage entre la version d’un paquet, la version de rattachement dans Fedora et sa fin de vie. Le principal concerné est l’outil pkgdb, la pièce maîtresse de Fedora qui contient la liste des paquets, permet d’en créer un nouveau, d’en faire une revue, de lire leurs métadonnées, le lien avec les versions de Fedora et, bien entendu, les développeurs et empaqueteurs responsables de leur maintenance. Jusqu’ici, cet outil associait à chaque paquet une branche nommée, par exemple f26, pour signifier qu’il est disponible dans Fedora 26 et dont la fin de vie de cette branche est la même que Fedora 26.

Mais dans le cadre de la modularité, il est possible que plusieurs branches d’un paquet soient disponibles pour une même version de Fedora grâce aux différents modules. Donc, l’outil a été profondément remanié pour permettre à un module de spécifier n’importe quelle branche d’un paquet et de définir sa propre date de fin de vie plutôt que celle d’une version de la distribution.

Séparation du Base Runtime en Plate‐forme et Hôte, le premier prenant en charge l’espace utilisateur et la base du système, quand le second s’occupe uniquement de la gestion du matériel. En somme, la seconde partie contient le noyau, le chargeur de démarrage, les micrologiciels et quelques pilotes. Dans le cadre de la modularité, le but de ce changement est de découpler la gestion du matériel du reste du système pour proposer des cycles de vie différents et autonomes. L’utilisateur pourra ainsi bénéficier de plus de souplesse, comme avoir la dernière version de la prise en charge du matériel avec le reste de Fedora un peu plus ancien et inversement. À terme, on pourrait avoir une sorte de gestion de matériel fournie par Fedora 27 avec un espace utilisateur fourni par Fedora 28. Ou inversement, selon le cas d’usage.

L’édition Fedora Server reçoit les premiers travaux officiels pour gérer la modularité, alors qu’elle a été testée par l’édition spéciale Boltron lors de Fedora 26. L’objectif est de mettre en place la modularité dans une image officielle de Fedora et non annexe comme l’a été Boltron. Cela permettra aux administrateurs système de prendre en main le projet de manière plus large pour bénéficier d’un maximum de retours. Il sera également possible de voir le comportement de la modularité durant le cycle de vie complet de Fedora 27.

Comme pour Fedora 26, je vous invite à consulter la documentation de la modularité et leur chaîne YouTube pour en apprendre plus à ce sujet. À cause de ce changement important, l’édition Server sera disponible un mois après les autres éditions.

Le concept du Python Système est revisité et devient la Plate‐forme Python. L’objectif est de fournir un Python pour les applications système de base comme dnf et rpm (dont le binaire devient /usr/libexec/platform-python) qui puisse différer de celui des autres applications (dont le binaire reste /usr/bin/python). En effet, dans le cadre de la modularité, l’objectif est de séparer la base du système avec le reste des applications, afin d’autoriser une certaine souplesse à l’usage. Auparavant, toutes les applications devaient utiliser Python 3.6 par exemple et il était assez compliqué de faire autrement pour l’utilisateur. Avec cette séparation, les outils système pourront rester à Python 3.6 quand les applications pourront bénéficier en simultanée de Python 3.7 ou 3.8 quand ils seront disponibles. Cela autorise également Fedora à n’embarquer qu’un sous‐ensemble de Python pour ses propres applications afin d’alléger le système minimal pour les images destinées aux environnements Cloud.

Autour de Fedora

Comme annoncé, Fedora 27 n’a pas bénéficié et le projet Fedora n’utilisera plus de version alpha durant son développement grâce à l’amélioration des outils et des procédures de qualité. L’objectif est d’améliorer la qualité de la branche de développement Rawhide de sorte à atteindre la qualité d’une alpha en permanence. En procédant ainsi, le projet Fedora gagne du temps durant le processus et peut libérer les ressources mobilisées pour produire une alpha à d’autres tâches. En effet, la sortie d’une version alpha nécessite des ressources pour gérer le processus, geler le développement, identifier et corriger les bogues bloquants, communiquer autour de sa sortie, mettre à jour les sites Web, construire des images spécifiques, les tester…

L’utilitaire Bodhi, qui sert notamment au déploiement et aux retours des mises à jours RPM et des images ISO de Fedora, peut prendre en charge les applications Flatpak, OStrees, les images Docker, etc. Cela va dans le sens d’améliorer la qualité des produits de Fedora. Il devient ainsi possible de noter la mise à jour de ces fichiers suivant si elle est bonne ou non (ce que l’on appelle le karma), de facilement remonter les problèmes vers le système suivi de bogues du projet, d’exécuter les tests automatisés ou encore d’envoyer des courriels aux listes de diffusion concernées.

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 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 et 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 de 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 moindre que l’on puisse dire, c’est que le travail abattu est important : près d’une cinquantaine d’articles corrigés et remis au goût du jour. Un grand merci à Charles‐Antoine Couret, Nicolas Berrehouc, Édouard Duliège et aux 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 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.

Aller plus loin

• Site de la communauté francophone de Fedora (664 clics)
• Site officiel du Projet Fedora (505 clics)
• Notes de version de Fedora 27 (258 clics)
• Images Torrents officielles (179 clics)
• Procédure de mise à niveau (218 clics)