Il est courant, au sein de la communauté du logiciel libre, de présenter une distribution GNU/Linux comme une simple intégration ou un assemblage de tous les logiciels qu’elle propose. Une sorte de glu entre eux.
La distribution Fedora va au‐delà de ce constat. Ses objectifs et sa communauté lui permettent de réaliser d’autres choses. En effet, depuis sa création, Fedora est une « vitrine technologique » et à ce titre a essayé de mettre en avant ou de développer des solutions novatrices pour le logiciel libre. Mais depuis Fedora 21, sortie fin 2014, Fedora s’est découpée en trois produits distincts : Workstation, Server et Atomic. Si Fedora Workstation et Server ont accès aux mêmes paquets, le projet a souhaité fournir des expériences utilisateur adaptées à chaque cas d’usage dès la fin de l’installation. Par conséquent, Fedora Workstation a sa liste de travail pour intégrer et développer de nouvelles solutions pour améliorer l’usage bureautique de l’utilisateur.
Et si la distribution Fedora est souvent considérée comme une version de tests pour la distribution Red Hat Enterprise Linux (RHEL) nous allons constater que finalement toute la communauté tire des bénéfices de ses travaux.
Le présent article est une adaptation des articles de blogs ici et là de Christian Schaller qui m’en a donné l’autorisation. Il a fait l’objet d’une conférence lors des JM2L de fin novembre 2017 dont vous pouvez retrouver le support.
Sommaire
Expérience utilisateur
GNOME Logiciels
GNOME Logiciels est un pur produit de la vision Fedora Workstation de la distribution GNU/Linux pour simplifier la vie de ses utilisateurs. Essayer de reprendre certains codes provenant des magasins applicatifs concurrents, en proposant uniquement des applications graphiques (et donc visibles pour le commun des mortels), avec des captures d’écran, des notes des utilisateurs et des commentaires.
Mais l’objectif est de fournir un tout intégré. GNOME Logiciels est donc capable de détecter si vous avez une police de caractères qui manque pour afficher un contenu dans une langue exotique, ou encore un codec multimédia pour votre film. Ainsi, il peut vous proposer de l’installer à la volée via une fenêtre surgissante (pop‐up). Il gère également de manière transparente les extensions de GNOME Shell, les mises à jour et les mises à niveau du système en passant par les micro‐logiciels des différents périphériques.
L’ensemble repose sur un format de fichier nommé appdata qui se retrouve peu à peu dans les sources de tous les logiciels concernés. Cela ouvre la possibilité à partir des mêmes données d’offrir différentes expériences utilisateur, de ne remplir et de ne traduire ces métadonnées qu’une fois.
Fedora Media Writer
Fedora s’est attaqué au fameux problème de la création d’une image installable sur clé USB. D’habitude il faut télécharger un fichier ISO, l’installer en suivant des procédures pas toujours évidentes et tester l’image. Et comprendre ce qu’est un fichier ISO n’est pas évident pour tous les utilisateurs.
Fedora propose un utilitaire multi‐plate‐forme, pour Windows, macOS et GNU/Linux afin de choisir l’image souhaitée (Fedora GNOME ou KDE par exemple) et procéder automatiquement à l’installation sur le média choisi. Cela est plus clair et plus simple pour l’utilisateur qui a besoin de moins de compétences de base pour débuter. Cela permet également de simplifier la documentation et la communication autour du projet Fedora, cette étape étant maîtrisée et ne dépendant plus de la gestion des ISO sur différents systèmes.
De plus, certains se sont amusés à concevoir par impression 3D autour d’un Raspberry Pi, un petit ordinateur nommé Fedorator pour les salons où le visiteur peut enficher sa clé USB, choisir l’image qu’il souhaite et repartir avec une image de Fedora prête à l’emploi en totale autonomie.
L’outil Fleet Commander
Fleet Commander est un outil pour gérer des flottes entières de machines sous Fedora ou RHEL, notamment pour les universités, les grosses entreprises ou les administrations et, ainsi, de pouvoir gérer des milliers de machines. Il est possible de configurer les postes avec un navigateur Web ou l’outil Cockpit.
Actuellement il est capable de configurer tout ce qui est accessible pour dconf (l’utilitaire de configuration de GNOME), les extensions de cet environnement, Networkmanager (dont le réseau privé virtuel — VPN — ou le serveur mandataire — proxy ). Ou de facilement migrer la configuration de Evolution vers un autre serveur de courriels. Ou encore de configurer Firefox, LibreOffice et quelques autres outils plus génériques.
La configuration est intégrée avec la solution FreeIPA, et donc les informations sont liées au compte LDAP, ce qui évite devoir gérer un autre service en interne.
Les performances de GNOME Shell
Carlos Garnacho a travaillé quelque temps pour identifier et résoudre des soucis de performance dans GNOME Shell.
Que l’on aime ou pas GNOME Shell, réduire sa consommation en ressource est toujours une bonne chose.
Les portails captifs
Dans les lieux publics, il y a souvent du Wi‐Fi offert aux clients, dans les aéroports ou les hôtels, par exemple. Pour permettre l’authentification de l’utilisateur, un portail captif est souvent en place pour que l’utilisateur saisisse ses identifiants et obtienne ainsi accès à Internet.
L’inconvénient de ce procédé est qu’il est indispensable d’ouvrir une page Web quelconque pour visualiser la page d’authentification et ainsi obtenir l’accès à Internet après la saisie. Si vous ne le faites pas, la machine sera considérée comme connectée au réseau mais n’aura pas accès aux ressources du réseau. Les requêtes pour collecter ses courriels échoueraient sans indication sur la raison de l’échec.
Fedora a travaillé pour que GNOME et NetworkManager ouvrent automatiquement une fenêtre dédiée si un portail captif a été détecté. Cela permet la saisie des identifiants nécessaires sans que l’utilisateur ait besoin d’effectuer cette manipulation manuellement.
Améliorations de GNOME
Quelques fonctionnalités de GNOME sont l’œuvre de la communauté de Fedora. Par exemple, Carlos Soriano a apporté le renommage multiple dans Nautilus et un rafraîchissement de son interface.
GNOME Terminal notifie maintenant l’utilisateur quand une tâche est terminée (vraiment utile pour connaître la fin d’une longue compilation). GNOME Builder a reçu également quelques ajouts de ce côté‐là.
libratbag
Fedora a conçu cette bibliothèque pour faciliter la configuration des souris et d’autres périphériques d’entrées dont les manettes. Il a également une collaboration en cours avec des constructeurs pour améliorer la gestion des souris orientées jeux.
Un outil est en cours d’élaboration pour tirer partie de cette bibliothèque sous GNOME, pour configurer les touches additionnelles, les différentes résolutions de la souris ou encore les LED qui arborent ces souris.
La libération des codecs audio
Ces deux dernières années, des brevets autour des codecs audio MP3, AAC et AC3 sont peu à peu tombés. Cela autorisait de fait les différents composants libres à fournir leur gestion par défaut sans devoir verser de contributions financières. Red Hat et Fedora étant des entités américaines légalement, il fallait s’assurer que tout était clair de ce côté avant de fournir le feu vert. Pour des questions légales, il vaut mieux éviter de se fier aux déclarations de personnes inconnues sur Internet.
Red Hat Legal a donc planché sur la question de la conformité des solutions libres sur le sujet (comme GStreamer) avec leur développeur pour s’assurer qu’ils ne violaient pas des brevets sur des sujets annexes encore en cours sur ces technologies ou que les brevets étaient vraiment bien tombés.
Le feu vert juridique a été donné, et normalement ces codecs ont pu intégrer la section codecs libres des différentes bibliothèques qui les implémentent.
L’intégration de Qt sous GNOME
Avec Fedora 25 et 26, il y a eu un travail pour concevoir QtGNOME plateforme. Un outil pour faire en sorte que les applications réalisées avec Qt (au lieu de GTK+ pour les applications de GNOME) se marient bien visuellement.
Cela passe aussi par l’intégration des différents paramètres, avec prise en compte des écrans à haute résolution (HiDPI), du thème sombre, du thème GTK+ actuel, etc. L’objectif est de minimiser au maximum l’écart visuel entre les deux écosystèmes et de s’assurer que les choix de l’utilisateur s’appliquent aux deux bibliothèques. Ainsi, l’utilisateur en configurant son interface GNOME n’a pas à reproduire ces changements sous Qt également, cela est automatiquement pris en charge.
Gestion du matériel
Intégration du pilote propriétaire de NVIDIA
Hans de Goede et Simone Caronni ont collaboré sur les travaux de NVIDIA et d’Adam Jackson autour de glvnd. Donc, si vous installez le pilote propriétaire NVIDIA provenant de dépôts correctement gérés, il n’y aura plus de conflits avec la pile graphique fournie par Mesa.
Et en cas de mise à jour du noyau, s’il y a incompatibilité, le pilote libre nouveau prendra automatiquement le relais le temps que le pilote propriétaire soit à nouveau disponible. Cela permet de corriger un souci récurrent du délai de la mise à disposition des derniers pilotes de NVIDIA pour le nouveau noyau.
Gestion native du pilote invité de VirtualBox dans le noyau Linux
Hans de Goede a travaillé pour incorporer dans le noyau Linux officiel le pilote invité de VirtualBox. D’habitude une fois votre système invité installé, il était nécessaire de télécharger les pilotes additionnels et les installer dans la machine virtuelle pour bénéficier du plein écran, du dossier partagé, etc.
Cette étape ne sera bientôt qu’un lointain souvenir, le pilote Linux a déjà été accepté en partie le mois dernier. La gestion du dossier partagé devrait suivre bientôt.
Prise en charge de Thunderbolt 3 et de sa politique de sécurité
Christian Kellner a travaillé sur un autre pan du matériel moderne de l’ordinateur : Thunderbolt 3. Cette norme concurrente de l’USB type C propose en plus des fonctionnalités usuelles de ce type de bus (affichage, transfert de données, etc.) un système de sécurité pour éviter qu’un périphérique inconnu ait accès de manière privilégiée à votre machine dans votre dos.
Grâce à son travail, l’utilisateur est notifié dans GNOME de la présence d’un nouveau périphérique et peut ainsi décider de lui octroyer l’accès ou non à certaines fonctionnalités de la machine.
La mise à jour des micro‐logiciels
Richard Hughes, mainteneur de PackageKit, de GNOME Logiciels et fwup, a fourni un grand effort pour simplifier la mise à jour des différents micro‐logiciels de nos machines : l’UEFI de nos cartes mères, celui des souris, des cartes réseau ou graphiques, etc. Il y a quelques mois, il a collaboré avec Logitech pour fournir la mise à jour automatique du micro‐logiciel d’une souris de la marque, suite à une faille de sécurité récemment découverte.
De nombreux ordinateurs portables de Dell sont aussi pris en charge par cette solution, qui est pleinement intégrée à GNOME Logiciels également. Des discussions seraient en cours avec d’autres marques.
Ce travail reste important pour garantir la sécurité de composants matériels souvent invisibles et même négligés dans la politique de mise à jour du système.
L’autonomie
Souvent GNU/Linux est considéré comme moins performant que Windows ou macOS sur la question de la gestion de l’énergie. Pour résoudre ce problème, Christian Kellner et Owen Taylor ont œuvré pour fournir un utilitaire Battery Bench Tool pour récupérer des données variées et exploitables pour identifier les problèmes réels et y apporter des solutions. En effet, cet outil génère différents scénarios d’utilisation pour identifier les composants responsables de la baisse d’autonomie (le processeur, le disque dur, etc.) et ce de manière reproductible.
Pendant ce temps, Hans de Goede souhaite activer de manière générique la SATA Link Power Management dans le noyau, ce qui améliorait la gestion de l’énergie des périphériques accessibles via SATA, soit des SSD ou disques dur principalement. Seulement, par le passé, cela causait des corruptions de données sur certains SSD à cause d’un micro‐logiciel foireux. Il souhaite des retours d’utilisateurs sur la question pour savoir le gain d’autonomie estimé et si des corruptions de données sont à signaler ou non.
Hans souhaite également désactiver les modules multimédia des processeurs quand ils ne sont pas actifs, ce qui permet de gagner un peu d’autonomie également.
RADV, Vulkan pour le module libre Radeon
Fedora a apporté l’implémentation libre et complète de Vulkan pour les processeurs graphique d’AMD qui sont certifiés compatibles avec la norme. David Airlie a annoncé que ce pilote avait obtenu le statut de « pilote conforme aux spécifications Vulkan », approuvé par le Groupe Khronos, ce qui est une première pour X.Org.
libinput
Cette bibliothèque est le Wayland des entrées du système (claviers, souris, pavés tactiles, tablettes tactiles, écrans tactiles, etc.). Mais, contrairement à Wayland, il était possible d’utiliser libinput dans X.Org directement (à des fins de tests, mais aussi pour améliorer ce dernier). Cela a permis l’apport de la gestion du multi‐tactile, par exemple, et a rendu libinput fonctionnel plus rapidement.
Travail de fond
Wayland
Wayland est le remplaçant de X11 dans les systèmes UNIX ou GNU/Linux. La remise à plat du protocole comporte son lot de surprises et de régressions. Après huit ans de gestation et deux ans de tests intensifs sous Fedora, il a été proposé par défaut pour Fedora 25, première distribution à avoir fait ce changement nativement.
Cela a été possible grâce à Olivier Fourdan, Jona Ådahl et la communauté Wayland pour notamment résoudre les derniers problèmes de stabilité et de rendu. L’attention a été portée notamment sur XWayland pour assurer la compatibilité ascendante avec les applications ne pouvant utiliser Wayland directement aujourd’hui.
Mais le travail continue. Actuellement, ils travaillent sur l’affichage distant du bureau.
Construction reproductible
La construction reproductible est la capacité, pour le même code source, le même environnement de compilation et les mêmes instructions de compilations, de pouvoir recréer une copie identique bit‐à‐bit de tous les objets spécifiés (exécutables, mais aussi paquets de distribution, également image de système de fichiers). Le résultat ceci étant vérifiable et vérifié avec des hachages pour chaque étape et objet.
Une documentation complète explique comment mettre en œuvre cela, et fourni des outils d’administration et d’utilisation, depuis la définition d’un environnement de compilation reproductible, jusqu’aux cas d’usages, en passant par sa mise en œuvre.
Des contributeurs de tous horizons participent à ce projet. En marge du projet lui‐même, le cadriciel PHP Symphony vient d’annoncer que sa dernière version était reproductible, et l’on commence à lire des éléments pour Java (Gradle vient d’introduire la reproductibilité).
Portage vers GTK+ 3
GTK+ 2 est une bibliothèque graphique qui fut très utilisée mais qui est aujourd’hui obsolète. Elle ne bénéficie plus d’évolutions et ne gèrera jamais Wayland ou le HiDPI, par exemple. La communauté Fedora a œuvré pour porter LibreOffice et Firefox sous GTK+ 3 en proposant des correctifs en ce sens et en proposant ces logiciels en premier avec cette implémentation. Ce qui a donné lieu à l’identification de nombreux bogues qui ont pu être corrigés avant leur prise en charge par d’autres distributions.
Ce qui est prévu à l’avenir
Fedora n’est pas en reste pour l’avenir. Outre son évolution vers la modularité, la communauté a d’autres éléments à ajouter.
La construction des applications Flatpak
Owen Taylor travaille sur l’infrastructure de Fedora pour apporter de quoi construire des applications Flatpak directement, en parallèle des formats RPM classiques. L’objectif est de faciliter la vie du mainteneur qui pourra concevoir en une fois la construction des deux formats. Et les autres distributions ou utilisateurs pourront récupérer le Flatpak à jour directement s’ils le souhaitent.
Pipewire
Wim Taymans, coauteur de GStreamer et grand contributeur de PulseAudio projette d’étendre le spectre de ses travaux avec Pipewire. Il souhaite avec ce composant unifier l’audio et la vidéo sous GNU/Linux. L’objectif au long terme n’est pas de gérer uniquement la vidéo, mais de prendre en compte également tout type de flux audio. Et non seulement il souhaite s’attaquer aux cas d’usage de PulseAudio, mais également à ceux de Jack (qui est plutôt dédié au traitement audio professionnel ou d’amateurs éclairés). Cela passera notamment par une compatibilité avec les applications existantes sans réécriture de leur part.
L’objectif est de rendre la plate‐forme GNU/Linux plus attirante pour les compositeurs et autres artistes du milieu. Pipewire a fait sa première apparition dans Fedora 26.
Tests automatisés des ordinateurs portables
Les ordinateurs portables sont des machines ayant un grand nombre de périphériques en simultanée, ce qui nécessite une bonne intégration avec le système d’exploitation pour en tirer pleinement partie.
Pour détecter les régressions dans ce domaine et avoir une vue d’ensemble de la compatibilité actuelle du parc, Benjamin Berg conçoit une suite de tests dédiée à la question avec un site listant les fameux rapports.
Optimus et équivalents
Adam Jackson travaille autour d’un nouveau composant glxmux pour permettre l’exploitation de plusieurs sessions GLX sur un même système. L’objectif est de pouvoir facilement passer de la pile Mesa, à celle d’Intel ou à celle de NVIDIA. Cela est, bien sûr, en lien pour un usage transparent de solutions hybrides comme Optimus.
Les contacts avec NVIDIA sont nombreux à ce sujet pour finir ce travail.
Le HiDPI fractionnel
Les affichages à haute densité de pixels (HiDPI) sont de plus en plus fréquents dans les configurations milieu et haut de gamme. Ils permettent d’améliorer la finesse de l’affichage sans pour autant réduire la taille des éléments affichés. Cependant sur certains modèles d’écran, les ratios entiers du HiDPI produisent des affichages trop grands ou trop petits. Pour résoudre ce problème, on souhaite introduire des valeurs intermédiaires non entières. Le travail est en cours pour le permettre, d’autant qu’il faut s’assurer que cela s’applique également aux programmes tournant avec XWayland sans nécessiter une gestion directe depuis leur bibliothèque graphique ou de leur gestionnaire de fenêtre.
Le HDR
La technologie High Dynamic Range se répand de plus en plus sur les moniteurs et les ordinateurs aujourd’hui. L’objectif est de fournir une plus grande gamme de rendu des couleurs. Une collaboration est en cours avec Intel, NVIDIA et AMD sur le sujet pour fournir ce type de solution à GNU/Linux.
Fedora Atomic : c’est de la bombe
Fedora travaille beaucoup pour concevoir un système atomique, selon les travaux de Project Atomic. Actuellement, c’est la version Cloud qui en bénéficie, mais les travaux sur la version Workstation sont en cours. Le but est d’améliorer la fiabilité du système, il sera ainsi possible de facilement mettre à jour le système en diminuant les risques liés à une procédure exécutée dans un ordre différent de celui prévu, par exemple. Le retour à une situation antérieure en cas de problème sera également plus facile en sélectionnant l’état précédent du système dans GRUB.
Devant l’intérêt récent pour cette technologie, un groupe de travail a été constitué ce mois‐ci pour faire avancer le sujet.
Conclusion
Comme nous pouvons le voir avec cette liste, non exhaustive, d’exemples, une distribution d’envergure comme Fedora, mais aussi Ubuntu, Debian ou autres peuvent apporter bien plus qu’une liste de logiciels à installer. Ils proposent des nouveaux outils, participent au développement ou à la stabilisation des logiciels qu’ils fournissent, peuvent collaborer avec d’autres entreprises ou communautés pour améliorer la prise en charge de leur produit.
Et encore, nous ne parlons que des travaux significatifs de ces trois dernières années, Fedora a également œuvré pour PulseAudio, systemd, PackageKit, NetworkManager, le pilote libre nouveau et tant d’autres composants par le passé !
Et malgré les liens forts entre Red Hat et Fedora, nous pouvons voir que beaucoup des travaux de Fedora de ces dernières années ont bénéficié à la plupart des distributions aujourd’hui. Et cela n’est pas près de se terminer.
Aller plus loin
- Blog de Christian Schaller : Fedora Workstation 26 and beyond (137 clics)
- Blog de Christian Schaller : Looking back at Fedora Workstation so far (91 clics)
- Get Fedora (193 clics)
# Communication et remontée de bugs = 0 pointé
Posté par romu . Évalué à 10.
Bonjour,
Merci pour cette dépêche qui donne un bon aperçu des évolutions de Fedora. J'adore Fedora et l'utilise depuis la version 19 comme OS unique sur mes machines pro et perso.
Mais p… les aspects communication et remontée de bugs sont justes lamentables. A chaque fois que je suis confronté à un problème :
1. Je vais sur Bugzilla, je cherche un peu mon problème, si je ne le trouve pas, je tente de créer un rapport de bugs
2. Ah oui, mais là, il me demande quel est le composant concerné. En tant qu'utilisateur, j'en ai juste rien à faire, mais je ne peux quand même pas remonter le bug.
3. Si je trouve un composant approchant et que je crée le rapport là-dessus, le responsable va le rejeter parce que ça ne le concerne pas, et on tombe dans les limbes de la boucle infinie.
4. Ah mais faut aller sur IRC mon monsieur…sauf que personne ne répond jamais. J'ai tenté Fedora, fedora-qa, gnome, etc. Sans compter les "chambres" IRC qui demandent une authentification qui ne fonctionnent pas bien.
…Bref, avant d'imaginer des super fonctionnalités, un tout petit travail sur le support des utilisateurs serait VRAIMENT bienvenu.
Merci encore pour la dépêche, ça m'aura permis de me défouler un peu :D
Je vous donne ma bénédiction de remonter tout ça à qui vous voudrez, je veux même bien participer à des réflexions là-dessus, j'ai plein d'idées.
[^] # Re: Communication et remontée de bugs = 0 pointé
Posté par dinomasque . Évalué à 4.
Je comprend et partage ton avis (j'ai rencontré le même problème) mais vais tout de même me faire l'avocat du diable :)
Quelquepart, ce mode de fonctionnement est cohérent. Fedora est une distribution de hacker (au sens noble bien sûr) et pas une offre de produit+services grand public.
C'est à dire qu'en cas de problème, le service de qualification et de résolution n'est pas fourni par la communauté Fedora qui fournit juste des espaces d'entraide.
Il y a donc 2 possibilités :
- se comporter en hacker-contributeur : qualifier soi-même le problème en identifiant finement la nature du problème, le composant impacté et pourquoi pas une piste de correction
- déléguer ces actions à un prestataire d'un service de support
BeOS le faisait il y a 20 ans !
[^] # Re: Communication et remontée de bugs = 0 pointé
Posté par freem . Évalué à 8.
Debian non plus (c'est probablement encore pire, dans le sens ou Debian n'a probablement pas la même puissance financière que RH), et pourtant elle a un outil nommé reportbug, qui guide l'utilisateur afin de faire un rapport d'erreur correct.
Je ne dis pas que c'est parfait, mais enfin, au moins rapporter un bug sur Debian est simple ;)
[^] # Re: Communication et remontée de bugs = 0 pointé
Posté par microlinux (site web personnel) . Évalué à 9.
La seule distribution où le rapport de bugs est simple, c'est Slackware. Dans mon expérience, un mail à volkerdi@slackware.com avec une description sommaire du problème, et le plus souvent, quelques jours plus tard, le problème est résolu. Des fois, on a même une mention honorable dans le ChangeLog.txt de Slackware.
J'ai également soumis des rapports de bogues à Debian, et le souvenir que j'ai de cette expérience, c'était que ça me rappelait l'année 1991, où j'ai dû demander un visa et une carte de séjour pour la France et que mon pays natal ne faisait pas encore partie de l'Union Européenne. Au bout de plusieurs échanges empreints d'un esprit de bureaucratie et de rigidité, j'ai tout simplement laissé tomber.
Dyslexics have more fnu.
[^] # Re: Communication et remontée de bugs = 0 pointé
Posté par Sytoka Modon (site web personnel) . Évalué à 6.
reportbug marche très bien je trouve et le tout est archivé, classé, trié… Tu nous sors en parallèle un courriel à une personne. C'est bien mais cela ne fait pas très communauté. Je pense qu'on n'est pas sur la même échelle ;-)
[^] # Re: Communication et remontée de bugs = 0 pointé
Posté par microlinux (site web personnel) . Évalué à 4.
Reportbug marche très bien effectivement. Le problème c'est qu'après on se voit obligé de sauter à travers des cerceaux en feu pour expliquer qu'il s'agit manifestement d'un bug, et quand le tout se termine par un WONTFIX et que la personne en face prend des airs de Louis XIV congédiant un quémandeur, on n'a plus trop envie d'y retourner.
Dyslexics have more fnu.
[^] # Re: Communication et remontée de bugs = 0 pointé
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
J'ai eu un retour de fermeture hier sur un bug que j'avais déclaré il y a au moins 3 ans… Donc c'est un système géré et organisé. J'ai eu une fois une fin de non recevoir sinon cela a toujours été accepté.
Ce qui est vrai est qu'il est difficile de modifier un paquet stable en cours. Parfois c'est un petit bogue chiant mais pas bloquant donc il n'est pas toujours corrigé dans stable. Mais bon, c'est aussi ça l’appellation "stable" chez Debian.
La valse actuelle des noyaux est assez chiante et semble assez bricolée…
[^] # Re: Communication et remontée de bugs = 0 pointé
Posté par freem . Évalué à 2.
D'ailleurs, je me demande pourquoi Debian se cale sur des kernels non LTS. Ça simplifierai probablement la vie de tout le monde?
[^] # Re: Communication et remontée de bugs = 0 pointé
Posté par claudex . Évalué à 4.
Actuellement, Debian se cale sur les noyau Ubuntu LTS, du coup, leur boulot n'est pas si grand que ça pour toute la partie portage des patchs.
« 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: Communication et remontée de bugs = 0 pointé
Posté par freem . Évalué à 3.
Tu noteras que j'ai juste dit que rapporter un bug était simple, pas le faire accepter ou corriger. Perso, j'ai souvenir d'un bug d'udev qui partait en boucle infinie avec allocation de mémoire quand le MBR était corrompu. Pas de nouvelles jusqu'a la version stable suivante de Debian (près d'un an plus tard donc) qui demandait des infos et si c'était toujours d'actualité. Étrangement, je n'ai pas gardé mon iso de 500G tout ce temps, donc le bug à été classé résolu.
En bref: rapporter un bug, c'est simple. Qu'il soit pris en compte c'est autre chose.
[^] # Re: Communication et remontée de bugs = 0 pointé
Posté par Renault (site web personnel) . Évalué à 10.
On a une documentation française à ce sujet, en plus d'un outil nommé ABRT qui permet de rapporter un bogue en étant guidé, et celui-ci se charge de transmettre le tout à Bugzilla avec les traces et autres coredump qui vont bien.
Bref, Fedora aussi a des outils pour cela, même si cela mériterait d'être simplifié encore.
[^] # Re: Communication et remontée de bugs = 0 pointé
Posté par antistress (site web personnel) . Évalué à 6. Dernière modification le 27 février 2018 à 10:24.
Je pense que quand on ne connaît pas bien les entrailles d'une distrib (ce qui n'est pas honteux, c'est d'ailleurs mon cas) mais qu'on est désireux de faire remonter un bug, une possibilité est de le dire sur un forum communautaire (ce que j'ai déjà fait) pour être orienté sur le composant contre lequel rapporter le bug.
C'est une 3è solution par rapport au commentaire précédent ;)
[^] # Re: Communication et remontée de bugs = 0 pointé
Posté par MTux . Évalué à 6. Dernière modification le 27 février 2018 à 12:40.
J'ai eu la même impression la première (et dernière) fois que j'ai voulu remonter un bug.
Autant je peux comprendre qu'ils ne veulent pas se transformer en helpdesk et traiter des ticket "ça marche pas" donc il faut demander à l’utilisateur de faire des efforts, mais c'est tellement compliqué que ça en devient dissuasif.
[^] # Re: Communication et remontée de bugs = 0 pointé
Posté par glisse . Évalué à 2.
Par curiosité pourrais tu donner un exemple concret d'un problème que tu as eu ?
[^] # Re: Communication et remontée de bugs = 0 pointé
Posté par romu . Évalué à 1.
Bien sur, par exemple récemment, pendant disons 2/3 semaines, la fonction veille ne fonctionnait plus. Si je cliquais le bouton veille dans le menu système, le PC s'éteignait directement avec le risque de perdre les données non sauvées.
J'ai relaté le problème ici
[^] # Re: Communication et remontée de bugs = 0 pointé
Posté par glisse . Évalué à 2.
Ok, ce genre de bug c'est effectivement dure pour un utilisateur de savoir qu'elle composant est coupable. Pour ce genre de bug je conseil de taper (pointer du doigt pour les moins violent) sur le kernel en premier :)
On gagnerai probablement à écrire un guide du genre: "How to pin-point your problem" avec les trucs usuel (suspend-resume, lock screen, …).
[^] # Re: Communication et remontée de bugs = 0 pointé
Posté par Renault (site web personnel) . Évalué à 3.
Il faut bien comprendre que si tu ne sais pas sur qui taper, tu vas potentiellement spammer des tas de gens pour rien. C'est pour cela qu'il y a ce filtre, pour limiter l'envoie de trop de messages à tous les mainteneurs.
Si un doute est permis, taper sur un des coupables possibles est souvent suffisant. La plupart des mainteneurs changeront ce champs pour désigner le bon mainteneur si jamais un autre composant est incriminé.
Sinon il existe quelques pages (en anglais) dans le sens que tu dis :
https://fedoraproject.org/w/index.php?title=Special%3ASearch&search=how+to+debug
Ce n'est pas complet, c'est en anglais mais c'est un premier pas. Il y a le même genre de chose pour tester de manière sommaire si un logiciel fonctionne correctement ou non (entre autre pour vérifier la non régression après une MaJ).
[^] # Re: Communication et remontée de bugs = 0 pointé
Posté par Maz (site web personnel) . Évalué à 1.
Je sais que la question n'était pas pour moi, mais je suis d'accord avec l'auteur. Ce n'est pas toujours évident de remonter un bug sur Fedora.
Du coup, la plupart du temps j'attends quelques semaines, puis je rapporte si ce n'est pas corrigé. Mais ça ne fait pas toujours avancer les choses.
Le pire que j'ai eu, c'est un ticket toujours ouvert sur une fonctionnalité qui me semble critique en entreprise. Comme je n'ai ni le temps, ni les compétences de le corriger, j'attends patiemment. De toute façon, nous sommes très loin de déployer Fedora sur les postes informatiques.
https://bugzilla.redhat.com/show_bug.cgi?id=1348843
[^] # Re: Communication et remontée de bugs = 0 pointé
Posté par Misc (site web personnel) . Évalué à 6.
Alors, je pense que le noeud du problème est la. Si tu va sur bugzilla, c'est pour contribuer et ça requiert un minimum de connaissance technique hélas pour ça. Par pour du support.
Ce que tu sembles vouloir, c'est du support comme tu demanderais à ta banque ou ailleurs, ce qui est différent. Et je sais pas si tu as lu la GPL ou les licences du même genre, mais c'est marqué que c'est globalement pas inclus, partout.
Par la, je veux pas dire que "fallait lire avant d'accepter". Je veux dire que l'idée qu'aider les gens est optionnel et n'est pas un but fait parti des principes fondateurs du logiciel libre, à tort ou à raison.
Et ça se voit partout dans ce qui est mis en place.
Tu donnes l'exemple du support sur irc. C'est globalement mauvais et le niveau 0 de support, loin des bonnes pratiques du métier.
Pas de concept de shift (genre, tu sais pas si il y a une personne qui va te répondre).
Pas de suivi des gens ou des problémes (genre, si tu reviens le lendemain, les gens vont ou ne vont pas avoir de contexte).
Pas de process sur qui fait quoi et comment. C'est courant d'avoir 3/4 personnes qui vont aider 1 personne d'un coup, ce qui serait risible si c'était au téléphone. Y a globalement pas de formation ou de bonnes pratiques, c'est directement les gens qui savent et basta.
Et je parle même pas du média en lui même, qui est pas non plus super intuitif. Tu t'en sort quand tu es techie, bien sur.
Quand je raconte ça, les gens en général me disent "oui, mais ç'est pas du support professionnel, c'est des volontaires". Je dirais que oui, mais c'est pas une raison. Si tu prends une association du style Artisan du monde, les gens ont des shifts pour tenir la caisse dans les boutiques. Si tu prends des développeurs, ils vont utiliser les mêmes outils dans le libre et dans une startup.
Mais pas pour le support, qui ressemble plus au café du commerce qu'autre chose en général. Parce que le support, c'est dévalué, c'est éprouvant. Mais aussi parce que le support, c'est ce que les gens vont payer dans certains business modèles autour du logiciel libre.
Donc oui, le support est pas terrible. Et franchement, je pense pas que ça change dans le futur. Framasoft a un formulaire de contact, c'est sans doute un peu mieux, mais pas de beaucoup. C'est aussi des gens payés pour ça. Des gens ont tentés stackoverflow ou askbot. C'est un peu mieux, mais ça donne pas forcément des trucs de qualités. Et visiblement, les gens ne conseillent pas ça (la preuve, tu as pas mentionné ça). Je sais que Tails a fait des trucs à ce niveau aussi, mais j'ai oublié quoi. Mais tails fait plein de trucs bien.
Sans un changement des mentalités au niveau du libre entier, non, je vois pas le support changer.
[^] # Re: Communication et remontée de bugs = 0 pointé
Posté par David Demelier (site web personnel) . Évalué à 1.
Perso les quelques bugs que j'ai rapporté ont été résolus très vite (un problème avec TortoiseHG et Qt Creator).
git is great because linus did it, mercurial is better because he didn't
# Impressionnant
Posté par antistress (site web personnel) . Évalué à 10.
Tant la dépêche (captures en français et tout) que le travail de Fedora est impressionnant.
Intéressante conclusion :
-> C'est d'autant plus vrai avec Atomic et Flatpak, si j'ai bien compris, puisque la partie applicative sera directement poussée par les développeurs des ces applications à l'avenir.
Merci pour cette dépêche instructive !
PS : Une coquille sous « Les performances de GNOME Shell » : c'est le même lien qui est pointé deux fois.
[^] # Re: Impressionnant
Posté par Renault (site web personnel) . Évalué à 5.
Merci pour le signalement. le premier lien devrait être celui-ci : https://bugzilla.gnome.org/show_bug.cgi?id=782344
Si un modo pouvait corriger cela, merci.
Sinon je serais intéressé que d'autres personnes fassent une dépêche de ce type pour Ubuntu, Debian et autres car je pense qu'il y en a des choses à en dire. S'il y a des amateurs, j'ai pris un plaisir à m'occuper de Fedora. ;)
[^] # Re: Impressionnant
Posté par bepolymathe . Évalué à 1.
Oui merci à toi de l'avoir fait ! Et merci Fedora !
# Pour Wayland
Posté par gnumdk (site web personnel) . Évalué à 2.
Fedora peut faire ce qu'elle veut pour rendre GNOME Shell plus performant sous Wayland, c'est un problème d'architecture donc ce ne sera jamais corrigé.
Je suis surpris de voir que la situation risque de rester tel quel pendant quelques années encore (réécriture complète du Shell en utilisant GTK4). Donc Xorg a de beaux jours devant lui.
[^] # Re: Pour Wayland
Posté par Arthur Accroc . Évalué à 10.
Tu éveilles ma curiosité. Pourrais-tu détailler ce problème d’architecture (ou mettre un lien vers une explication) ?
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Pour Wayland
Posté par Frédéric Péters (site web personnel) . Évalué à 5.
Comme on est dans une dépêche Fedora, le lien approprié pourrait être : https://fedoraproject.org/wiki/Wayland_features#Restarting_gnome-shell
Dans l'architecture actuelle, GNOME Shell prend le rôle de "compositeur" Wayland; le résultat est qu'il n'est pas possible de redémarrer GNOME Shell sans redémarrer toute la session; la nécessité de redémarrer GNOME Shell étant présente à cause de bugs dans le shell même ou plus bas dans la stack côté VM javascript, ou côté pilots graphiques, qui peuvent amener le processus à consommer beaucoup trop de mémoire (ex: https://bugzilla.gnome.org/show_bug.cgi?id=642652).
[^] # Re: Pour Wayland
Posté par antistress (site web personnel) . Évalué à 3. Dernière modification le 28 février 2018 à 10:13.
Bug 757579 - (WaylandRelated) Tracker for Wayland-related issues
Plus précisément :
Bug 745032 - Mouse Tracking 'Laggy' on Wayland, and mouse movements cause frame drops in other OpenGL applications (j'en parlais dans la dépêche de GNOME 3.26)
Lire aussi sur phoronix GNOME Shell 4 Proposal Published To Be More Wayland-Focused
[^] # Re: Pour Wayland
Posté par pingoomax . Évalué à 4.
Tu peux expliquer un peu?
Balancer une "vérité" sans argumentation, ca ne fait pas avancer le problème et n'éclaire pas non plus les ignorants.
[^] # Re: Pour Wayland
Posté par Fabrice Mousset (site web personnel) . Évalué à 4.
Je pense que tu fais référence au problème de plantage récurrent de Gnome Shell qui sous Wayland se termine en clôture de la session parce que Gnome Shell est un composeur. Il me semble que des travaux sont en cours sur Wayland pour prendre en charge ce type de problème, et ainsi ne pas perdre la session complète lors d'un plantage du composeur. Je suis désolé, mais je n'arrive pas à trouver un lien potable :(
[^] # Re: Pour Wayland
Posté par gnumdk (site web personnel) . Évalué à 7.
Je me répond à moi même, non je fais référence au fait que l'architecture actuelle fait que tout tourne dans le même thread et que si le système est un peu chargé, Gnome Shell se met à ramer (pointeur souris, animations, …)
https://wiki.gnome.org/Initiatives/Wayland/GnomeShell/GnomeShell4
[^] # Re: Pour Wayland
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 03 mars 2018 à 08:49.
Si je comprend bien le problème d'architecture est pour Gnome Shell 3 et non pas l'architecture de Wayland, ouf !
De ce que j'ai survolé dans le lien Gnome Shell 4, ils ont les mêmes problèmes que Firefox Quantum est en train de résoudre : il faut absolument alléger au maximum le process principal pour être toujours réactif. Plusieurs solutions existent, notamment, en créant un process de composition dédié, en utilisant encore plus le GPU pour les graphismes et en utilisant au mieux les multiples cœurs du CPU.
Ça va demander d'utiliser un langage tel que Rust pour assurer un code sûr pour le multi process…
Donc, finalement, il faudrait finalement remplacer Gnome Shell 4 par un Firefox Quantum :D On pourrait même l'appeler Firefox Quantum OS !
[^] # Re: Pour Wayland
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2.
Ils parlent dans cette page même de casser le système d'extension, je leur suggérerait le système WebExtension pour les prochaines, quitte à faire du JavaScript et du CSS :)
# Légal
Posté par claudex . Évalué à 10.
Un point que tu n'as pas mentionné. C'est toute la partie respect des licences. Certaines distributions (je pense à Fedora et Debian) font un gros travail pour être sûr que les logiciels intégrés respectent bien les 4 libertés, mais aussi qu'ils n'incluent pas du code sans respecter cette licence.
« 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 Fedora
Posté par Leniwce . Évalué à -10. Dernière modification le 28 février 2018 à 12:01.
Il est vrai que beaucoup des travaux de Fedora de ces dernières années ont bénéficié à la plupart des distributions aujourd'hui.
Grâce à systemd, la communauté a vu naître une nouvelle distribution, Devuan. Mieux encore, jamais auparavant je n'avais vu autant d'effervescence autour du programme d'initialisation. Les nombreux travaux sur OpenRC et sa progression jusqu'au systeme BSD integré à la distribution TrueOS. N'oublions pas le formidable travail sur l'init s6 accompagné d'un travail tout autant impressionant pour l'integrer à la distribution 'Obarun' dérivée de Arch. Mais aussi Gentoo avec les logiciels elogind et eudev.
Grâce à Pulseaudio, Alsa ne s'est jamais aussi bien porté et le nombre de logiciels compatibles 'sndio' ne cesse de croître.
Grâce à Pipewire, on peut déja prévoir un avenir radieux pour 'Jack Audio' et son successeur.
Merci Fedora.
attention chérie ça va moinsser
[^] # Re: Merci Fedora
Posté par Tonton Th (Mastodon) . Évalué à 2.
Si tu parles bien de https://man.openbsd.org/sndio mais en version Linux, je veux bien que tu nous en parles un peu, voire même un journal pour nous expliquer tout ça…
Parce que bon, le son sous Linux, c'est un peu la grouille quand même :}
[^] # Re: Merci Fedora
Posté par David Demelier (site web personnel) . Évalué à 1. Dernière modification le 23 mars 2018 à 11:41.
Merci systemd, écrire des fichiers de service n'a jamais été aussi simple. En plus je peux faire en sorte que mon service s'exécute que si mon disque dur est branché, monté et le timer lancé.
git is great because linus did it, mercurial is better because he didn't
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.