La bêta d'Ubuntu 20.10 vient de sortir. Elle apporte son lot d'améliorations ainsi qu'une nouvelle vague d'optimisations, en plus d'éléments d'interface longtemps désirés. Pourtant, on ne peut s'empêcher de penser que la distribution semble faire, en quelque sorte, du surplace.
Groovy Gorilla, le nom de code d'Ubuntu 20.10, est attendue pour le 22 octobre prochain. Les développeurs sont actuellement en train de la finaliser, sa bêta a été mise en ligne il y a quelques jours. Canonical n’étant pas connu pour ses retards, on peut tabler sur une publication en temps et en heure.
Après une version 20.04 LTS (Long Term Support), la 20.10 est moins attendue. Elle ne bénéficiera en effet pas du support de cinq ans de ces éditions qui ne sortent que tous les deux ans. Ubuntu étant une distribution semestrielle, les trois versions intermédiaires n’ont qu’un support de neuf mois : six pour courir jusqu’à l’édition suivante auxquels se rajoute une rallonge de trois mois pour laisser le temps de migrer.
Ce rythme particulier explique aussi pourquoi les versions LTS sont configurées par défaut pour ne se mettre à jour que vers d’autres LTS. Si vous désirez migrer vers la 20.10 depuis la 20.04, il faudra forcer la main du système.
Si vous attendez cependant de savoir ce que contient Groovy Gorilla pour migrer, soyez rassurés : Ubuntu 20.10 ne bouleversera pas vos habitudes. La distribution a beau partager avec Fedora un amour des dernières versions disponibles des composants, elle est nettement plus frileuse quand il s’agit d’activer ou non des technologies.
Pas question de bascule vers Btrfs ici, ou même encore de Wayland : le système de Canonical reste dans une optique d’évolution douce. D’ailleurs, Groovy bouge essentiellement à travers ses composants.
- Télécharger la bêta d'Ubuntu 20.10 (64 bits uniquement)
GNOME 3.38 : l’essentiel des nouveautés
La plus grande partie des apports d'Ubuntu 20.10 provient de GNOME 3.38, sorti mi-septembre. Les améliorations y sont légion, et même si beaucoup sont « mineures », elles sont pour la plupart très utiles, certaines étant attendues depuis bien longtemps. Canonical y a d'ailleurs largement participé.
Comme déjà signalé dans notre article sur Fedora 33, c’est notamment le cas du bouton Redémarrer que l’on trouve enfin dans le menu Alimentation désormais. Autre ajout bienvenu, l’affichage des évènements directement sous le calendrier quand on clique sur la date en haut de l’écran. De même, on peut enfin épingler le pourcentage de batterie restante en haut à droite pour les ordinateurs portables dans Paramètres > Énergie.
La grille des applications, accessible depuis le menu général dans le dock, reçoit deux apports importants. D’une part, elle s’adapte maintenant beaucoup mieux à la taille de l’écran, plutôt que d’afficher des icônes tronquées. D’autre part, il est possible de réarranger les applications selon son bon vouloir, et plus uniquement l’ordre alphabétique imposé. C’est également vrai pour les sous-dossiers. Les vues Récentes et Toutes disparaissent.
On trouve aussi un meilleur support pour les lecteurs d’empreintes digitales. Il s’agit d’un travail réalisé en bonne partie par Canonical, puis intégré pleinement dans GNOME 3.38, avec pour bénéfice d’être diffusé dans les autres distributions Linux l’utilisant, dont Fedora. Ajoutons le support des touchpads de haute précision dans Firefox 81.
Plus spécifique, Active Directory est maintenant pris en charge dans l’installeur Ubiquity. Les concernés peuvent donc paramétrer le compte distant dès le départ, sans pour autant remiser la création du compte local. L’ajout permet de fluidifier le processus en entreprise, quand la machine est destinée à rejoindre un parc.
L’outil de capture d’écran est entièrement remanié. La fenêtre qui s’affiche propose un choix classique : capture de l’écran entier, d’une fenêtre ou d’une sélection. On peut choisir d’afficher ou non le curseur (masqué par défaut) et paramétrer un délai avant capture, en secondes. Le résultat est enregistré en PNG dans Images par défaut.
L’un des changements les plus importants est sans conteste le support des noyaux OEM. Il permet, pour les constructeurs fournissant des machines sous Ubuntu, de diffuser de nouvelles versions spécialement conçues pour leurs ordinateurs, qui seront distribuées par le même processus de mise à jour que le noyau classique. Pour rappel, de nombreux constructeurs ont misé sur Ubuntu ces dernières années, comme Dell ou encore Lenovo.
Enfin, on note la correction du bug pénible qui entrainait parfois un flou sur le fond d’écran. Si vous avez testé la bêta dès sa disponibilité le 1er octobre cependant, l’absence de fond d’écran dédié à Groovy Gorilla a pu vous surprendre. Même s’il est habituellement prêt à temps, il n’est cette fois apparu que cette semaine. Pour l’obtenir, il suffit d'effectuer une mise à jour. Ajoutons que deux fonds d’écran dynamiques sont également fournis, tous deux sur le thème de la forêt. Ils évoluent pour rappel en fonction de l’heure la journée.
Linux 5.8 et autres composants, performances
Les premières préversions d’Ubuntu 20.10 étaient logiquement basées sur la 20.04 et reprenaient son noyau 5.4. Avec la publication en mai de la 5.8, on pouvait se douter que Canonical l'utiliserait. Dont acte.
Comme toujours avec un noyau Linux, les améliorations étaient nombreuses : support préliminaire de l’USB 4.0, support des pilotes AMD Energy, du suivi de températures et de l’ACP Audio pour les Renoir d’AMD, d’AMDGPU TMZ (Trusted Memory Zone), des GPU Adreno 405/640/650 ou encore de Shadow Call Stack et Branch Target Identification pour ARM64. En clair, le noyau 5.8 a beaucoup apporté aux systèmes embarquant des CPU et/ou GPU AMD. En outre, le pilote gérant exFAT a lui aussi été amélioré.
Pour le reste des composants, on reste sur la liste habituelle, avec presque toujours les dernières versions disponibles. Sur ce point, Ubuntu partage avec Fedora la même philosophie, à ceci près que la distribution de Canonical intègre par défaut un nombre plus important d’applications.
Au sujet de la boutique Ubuntu Software, elle propose désormais une majorité de paquets sous forme de snaps. Ce n’est pas une surprise, mais ce point cristallise des tensions au sein de la communauté open source, car Canonical maitrise en grande partie la chaine permettant de faire fonctionner un snap sur une distribution. La bataille avec les flatpaks et installations classiques, que nous avions résumée, est donc loin d’être terminée.
On retrouve ainsi Firefox 81, Thunderbird 78.3.1, Rhythmbox 3.4.4, la suite LibreOffice 7.0.1.2 (donc la branche Fresh), Remmina 1.4.8 ou encore Transmission 3.0. Côté développement, on retrouve les suspects habituels : glibc 2.32, binutils 2.34, LLVM 11, Make 4.3, Boost 1.73, Golang 1.15, OpenJDK 11, Node.js 14, Erlang 23, GHC 8.8, Haskell Stackage 16 (LTS), Perl 5.32, Ruby on Rails 6.0 ou Python 3.9 (qui vient de sortir).
En ce qui concerne les performances, on est à nouveau sur un très bon cru. Ubuntu, depuis deux versions particulièrement, était déjà très réactive, grâce à plusieurs séries d’optimisations réalisées à la fois dans le système et dans GNOME, souvent en partenariat avec Canonical d’ailleurs pour ce dernier.
L'édition 20.10 remet le couvert et est au moins aussi rapide que l’actuelle 20.04.
Des nouveautés, mais…
Que peut-on dire de cette Ubuntu 20.10 ? Que les aficionados de la distribution en seront probablement satisfaits, si les développeurs règlent les défauts actuels. Car cette bêta présente certaines instabilités.
Par exemple, après une dernière série de mises à jour, le plantage quasi systématique d’Agenda au démarrage. Un envoi de rapport d’erreur et une relance de l’application passent le problème. Des soucis de traduction incomplète sont également à régler, notamment dans la liste d’évènements du centre de notification ou le menu Alimentation.
Cette mouture 20.10 sera probablement considérée comme réussie par beaucoup. Sa réactivité et les apports de GNOME 3.38 ont de quoi ravir. Les améliorations sont suffisamment substantielles pour avoir un impact quotidien et, après tout, c’est surtout ce que l’on demande à un OS. En dehors d’une bonne fiabilité bien sûr.
D’autres, à y regarder de plus près, trouveront que Canonical se repose un peu sur ses lauriers. Certes le système évolue, certes il est plus rapide, mais on ne peut pas rater un certain manque d’ambition. Depuis plusieurs versions, l’ensemble est statique et les améliorations se font à la marge.
C’est particulièrement vrai pour le socle technologique. En dépit de versions très récentes des composants et applications, Ubuntu renforce une impression de frilosité face à des technologies comme Wayland. La distribution la plus utilisée sur « desktop » prend son temps, et n’intègre toujours pas de services aussi importants que la réinitialisation du système, permettant d’éviter le téléchargement d’une image ISO et une réinstallation complète.
Canonical est probablement aujourd’hui moins intéressée par le desktop. L’entreprise se focalisant depuis un moment ses efforts sur le marché des entreprises, les serveurs et surtout le monde des objets connectés, où ses snaps revêtent une importance stratégique. La situation évoluera sans doute si la couronne d’Ubuntu est contestée, mais, en attendant, cette mouture 20.10 fera son lot d’heureux.
Commentaires (25)
#1
snap a tout va, quelle hérésie. C’est tellement dommage, la distribution est globalement bien foutue, mais tout remplacer par des snaps qui prennent des longues secondes à s’ouvrir, c’est la ligne rouge. Je reste sur Debian Sid puisque c’est comme ça
#1.1
Le seul snap installé par défaut est celui de la boutique d’application et chromium est le seul cas niveau desktop où un deb a été remplacé. Ce sont des cas particuliers de composants qui ont besoin de changer sur la durée et où le format snap facile la maintenance (une seule version du paquet, pas besoin de se battre avec des libraires et des versions de compilateurs dépassées, etc).
Et pour ce qui est du temps d’ouverture, les choses se sont améliorées et ça concerne principalement le premier démarrage, quelques secondes de plus pour lancer chromium après s’être connecté ce n’est pas non plus la fin du monde…
#2
Je confirme cette sensation de staticité. Cela fait 2⁄3 versions que j’ai également cette impression alors que des distrib comme Fedora proposent bien plus d’avancées. Même si ça a toujours été le cas cet écart s’est creusé je trouve.
Et puis perso j’ai de plus en plus de mal avec le fait que Snap prenne une place si importante… surtout en terme de performances et d’espace disque occupé (voire de stabilité pour certains). Mon premier réflexe est de retirer ceux par défaut pour les remplacer par leur équivalent sur les dépôts (pourquoi la calculatrice en snap ???).
#3
En même temps ça serait un peu bête de basculer vers Btrfs alors qu’ils travaillent sur la migration vers ZFS… En ce qui concerne Wayland, c’est bien gentil mais encore faut il que le reste du marché suive, entre les applications qui ne fonctionnent tout simplement pas (Zoom, Slack ne fonctionnaient pas la derniere fois que j’ai teste) et les drivers Nvidia qui ne supportent toujours pas Wayland, on est un peu dans la mouise.
Ce n’est peut-être pas le cas en France mais Ubuntu est très utilisée par les développeurs, notamment pour le Machine Learning, et qui dit ML dit Nvidia/CUDA.
La ou je suis d’accord, c’est sur le fait que Fedora innove plus vite, mais bon, le nombre d’utilisateurs est beaucoup beaucoup plus restreint. Et surtout, c’est Redhat derrière (et maintenance IBM), ce n’est pas le même nombre d’employés.
J’utilise Ubuntu (Desktop) aussi bien au travail qu’a la maison et il ne me viendrait pas a l’esprit d’installer Fedora (ou Arch) comme distribution principale.
EDIT: J’allais oublié que je suis d’accord sur les commentaires au dessus a propos des Snap, et je met les Flatpak dans le meme lot
#4
Dans ce cas là il suffit de désactivé Wayland si la hardware ne le support pas comme sous Fedora.
Par contre pour toute les solutions de partage d’écran c’est bloquant en effet mais Canonical ont des développeur ils peuvent essayer d’arranger ça.
#5
Encore faut-il qu’équivalents il y ait, sur les dépôts (coucou, Chromium ! Enfin, encore faut-il avoir l’usage de ce dernier)…
#6
En effet pour certaines app il n’y a pas vraiment d’alternative hormis compiler les sources (quand open source). Ce qui est dommage je trouve…
A choisir une solution portable et/ou isolée je préfère encore les AppImage
#7
Les snaps, en soi, c’est une bonne idée. La place en RAM et sur le disque est de moins en moins limitée. Autant donner à chaque application tous ses éléments pour fonctionner.
Sauf que, en ayant migré sur 20.04, j’ai constaté que Chromium était toujours présent mais ne s’ouvrait pas ! Passons sur les détails : j’ai désinstallé Chromium avec snap et l’ai réinstallé sans snap en suivant ce lien :
http://ubuntuhandbook.org/index.php/2020/06/install-chromium-via-deb-ubuntu-20-04/
Comme tous les liens pointent maintenant vers la version avec snap, ça m’a pris du temps de trouver le bon lien. En clair 20.04 n’est pas bien finalisé en octobre ! C’est du Windows, ça ! Honte !
Pour le reste, ça baigne, même si je n’ai pas tout testé.
#8
Il y a trois choses qui me manquent :
EDIT : j’utilise Pop_OS, qui est très proche d’Ubuntu. Visiblement les gestures sont dispos sur gnome d’après leur site, mais ça ne fonctionne pas chez moi.
#9
Sur les machines neuves. Va dire ça à ceux qui utilisent toujours un PC d’il y a 10 ans (donc avec 4 Gio de RAM, ce qui était le standard à l’époque et l’est resté longtemps), parce que leur usage fait qu’ils n’ont pas besoin d’en changer pour un plus récent (pas besoin de plus quand on se contente d’un navigateur Web et de LibreOffice, vraiment).
De plus, Snap, Flatpak et autres sont en fait des palliatifs à un défaut inhérent aux distributions fixed comme Ubuntu, Debian et autres : le fait que les logiciels (et les bibliothèques, surtout) restent dans des versions figées jusqu’à la sortie de la version suivante, et deviennent donc très vite obsolètes. Là où des distros rolling (allez, citons Manjaro et Calculate pour avoir des exemples qui ne sautent pas tout de suite sur les dernières versions stables en date) auront des bibliothèques à jour (rendant donc ces solutions inutiles dessus), il faut « aider » Debian et ses descendantes à rester capables de faire tourner des logiciels de maintenant, parce que ces derniers réclament des versions de leurs dépendances plus récentes que celles fournies par l’OS (quelle est la version actuelle de glibc ? Et celle fournie dans la dernière Debian ? Ubuntu restait bloquée sur Wine 1.x quand la version 3, contenant plein d’améliorations pour le jeu sur Steam, était sortie depuis longtemps sur Arch). Le vrai problème, il est là : la lutte contre l’obsolescence des distributions fixes, dans un monde où désormais, tout retard n’est plus pardonnable (notamment en matière de sécurité, même si les correctifs sont rétroportés). Et d’aucuns trouvent qu’au contraire, Snap et compagnie ne sont que des pis-allers, mais qui ne font que cacher la m××de sous le tapis, pas de vraies solutions qui vont soigner le mal à la racine (et comment faire, quand le mal en question provient directement du mode de conception même du système ?).
#10
L’auteur de l’article prend en exemple les nombreux changements opérés chez Fedora, mais ne dit pas qu’Ubuntu doit faire les mêmes. Il dit juste que de comparer cette dernière version à celle d’il y a quelques années, hormis les mises à jour de l’environnement de bureau et des applications, qui ne sont pas le propre d’Ubuntu, pour le reste, on ne trouvera pas grand-chose de nouveau.
Ensuite, c’est un peu le serpent qui se mord la queue. Ubuntu et dérivés ayant, de loin, la plus grosse part de marché, s’ils ne font rien, nVidia et compagnie vont se dire qu’ils n’ont eux même pas besoin de faire d’efforts. Par contre, si Ubuntu se mettait à déprécier telle ou telle technologie, en annonçant basculer sur son remplaçant à telle date, ça serait envoyer un signal fort pour inciter certaines entreprises à se bouger enfin un peu.
Mais ils n’en feront rien, se contentant d’attendre, comme d’habitude, que Fedora ai terminé le boulot sur PipeWire, qui doit résoudre ce problème.
Pour les dépendances, ça fonctionne dans les deux sens. Aussi bien pour une application récente qui a besoin des dernières technos à la mode, qu’une vieille application basée sur des technos archaïques, mais que t’as peut-être besoin de continuer à utiliser, pour x raisons. Typiquement, en entreprise, on trouve souvent de vieilles applications métier qui ont besoin de continuer à fonctionner à l’identique durant des années, voir des décennies.
Ensuite, limiter les Flatpak à cette seule histoire de dépendances, c’est passer à côté d’autres fonctionnalités intéressantes :
#11
Il me semble que cette histoire de version de logiciel/bibliothèque fixée vient d’un problème plutôt inhérent au système actuel de package. tel qu’il est fait, un package va être dépendant d’autre package. Mais d’une version à l’autre, un package peut casser la rétrocompatibilité. Or, tous les package ne sont pas forcément mise à jour dès lors qu’une dépendance est mise à jour, voir ne sera jamais mise à jour. Et comme il me semble que les système de package actuel ne gère pas les les histoire de versions, tu n’a aucune garantie que mettre à jour un package casse pas ton OS.
Le boulot d’une distribution c’est de s’assurer que les packages dans les dépôts soient tous compatibles. Les “distributions fixed” assure un environnement stable des bibliothèques et évite de foutre en l’air la moitié de tes programmes (cela inclus aussi ceux installer hors dépôts officiels mais qui sont généralement calqué pour s’assurer de fonctionner avec les versions des packages des dépôts officiels) car un package a été mise à jour.
#12
Euh si, c’est la base même des gestionnaires de paquets de vérifier les dépendances entre les paquets et leurs versions.
#12.1
Ce que je veux dire, c’est qu’a ma connaissance, je ne crois pas que les gestionnaire de paquage comme APT soit capable de manager en local plusieurs version d’un même package et qu’il supervise l’exécution des package pour lui linker les bonnes version des dépendances.
Par exemple, tu as le package A qui a besoin du package P en version 1.0, tu as le package B qui lui demande le package P en version 1.5 et supposons que ces 2 versions soit incompatible (ça arrive que des trucs passent de normal, à déprécié à retiré en quelques sous version). A priori, avec le système de package actuel, il va juste installer la version la plus récent du package P point barre, son boulot est fini. Il ne va pas pouvoir installer les version 1.0 et 1.5 et, au moment de l’exécution d’un des 2 package A ou B et lui rediriger vers la bonne version. Il suppose que les packages sont grand et savent retrouver leur dépendances tous seul.
Un distribution va s’assurer de mettre dans ses dépot les version des package A et B qui sont compatible avec la même version du package P.
C’est par exemple le genre de problème que j’ai souvent avec CUDA (même si CUDA n’est pas dispo dans les dépot), certaine bibliothèque ne fonctionne qu’avec certaine version, il faut que je gère à la main les variables d’environnement pour que la bonne version de CUDA soit celle utilisé.
#12.2
En effet, une seule version par paquet.
#12.3
Le gestionnaire de package de suppose rien, ce sont les specs des paquets qui lui disent quoi faire. (en tous cas pour RPM, je n’ai pas beaucoup d’expérience avec les Deb)
A la création le package peut avoir sa liste de dépendances spécifiées. Si celles-ci sont contraignantes (paquet A veut dépendance D = 1.0 mais D est installée en 1.5), la transaction va échouer car les dépendances ne sont pas satisfaites. Si la dépendance est minimaliste (paquet A veut dépendance D >= 1.0, D est installée en 1.5), la transaction sera validée. Tout ceci est géré avec les instructions Require, Conflict, et Obsoletes pour RPM.
Et en effet, le gestionnaire ne peut pas installer plusieurs versions du même paquet simultanément, mais il y a des moyens possibles, voir plus bas. Par défaut il installera la plus élevée, mais on peut lui spécifier aussi celle qu’on veut (dnf install machin-1.2.3-5.fc32.noarch).
Une possibilité quand on ne veut pas recourir aux snaps ou équivalent, c’est d’embarquer directement les bibliothèques pouvant poser soucis dans son package… Il me semble que par défaut elles seront chargées car présentes dans le répertoire relatif, sinon utiliser LD_LIBRARY_PATH. Après, dans le cas de RPM, il sait compiler le code en installant toutes les bibliothèques nécessaires avec les instructions BuildRequire dans le specfile. Mais ça nécessitera quand même de les installer.
Nous avons géré comme ça pour la compilation de middlewares fournis par un éditeur. Ce sont des logiciels libres mais ils valident à chaque fois un ensemble de versions pour leur produit (sinon pas de support). Donc pour éviter tout conflit avec des bibliothèques système, on compile les packages avec les dépendances requises par l’éditeur (via mock qui utilise un chroot) et on les installe dans /opt. Tout le bundle est compilé en spécifiant les dépendances que l’éditeur veut à l’emplacement indiqué sans perturber l’OS.
Sinon pour gérer des versions multiples de paquets sur des distribs de famille Red Hat, il y a le repo SoftwareCollection qui permet d’y répondre. Je ne sais pas s’il existe un équivalent dans la famille Debian.
#13
La calculatrice n’est plus en snap depuis quelques cycles et était en effet un mauvais choix vu que sur une application simple de ce type on voit surtout les inconvénients de la technologie et les avantages sont limités.
Pour les problèmes de performances vous voulez parler de la relative lenteur du premier démarrage, si c’est le cas il y a eu des améliorations récentes (changement de format de compression sur certains snaps comme chromium par exemple).
#13.1
En 20.04 j’ai pourtant eu la calculatrice Gnome fournit en Snap. A voir si c’est spécifique à Ubuntu Budgie ou non.
Ensuite ce n’est pas que des soucis de lenteur. J’ai eu des snap qui plantaient régulièrement tandis que je n’ai plus aucun soucis avec leur version .deb.
Je ne suis pas radicalement contre cette techno, elle a certains intérêts. Mais je comprends que la façon dont elle est poussée agace la communauté (et moi le premier je trouve cela dommageable et inquiétant).
Et puis en général ajouter une couche d’abstraction se fait toujours au détriment des performances, même si cela peut rester subtil. En tout cas je n’ai jamais vu d’abstraction qui fait mieux que du natif :)
#13.2
La calculatrice en snap est spécifique à Budgie oui, ils ont sûrement oublié de suivre le changement fait au niveau Ubuntu et ça vaudrait le coup de leur signaler [1].
Pour ce qui est de ‘pousser’, il a sûrement été maladroit de remplacer la calculatrice et autre quand ça été fait. Ça partait d’une intention louable d’obtenir le retour d’expérience nécessaire pour éprouver la technologie en commençant par des applications relativement simples et non critiques. Je ne pense pas que l’on puisse dire actuellement qu’il y ait un effort quelconque pour imposer les snaps à la communauté. Comme dit précédemment snap-store et chromium utilisent sur format pour des raisons pragmatique (réduire la charge de travail, simplifier la mise à jours sur les séries stable de la distribution), le reste du travail se concentre sur améliorer le format et les applications disponibles (donc du ‘opt-in’ pour ceux qui sont heureux d’avoir accès à des logiciels à jours ou qui n’était pas forcement disponible aussi facilement avant et intégrés dans la distribution avant (skype, spotify, etc))
Et pour ce qui est des bugs, le format est récent et les problèmes peuvent exister mais la plupart des logiciels couramment utilisés se montrent aussi stable que leur équivalent deb (pour prendre l’exemple des snaps de firefox ou thunderbird, ils proviennent directement des builds de mozilla donc sont plus proche du logiciel comme il est fourni et testé upstream que les paquets debs équivalents)
[1] https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?h=focal&id=feacf6e1
#14
D’un autre côté RedHat a plus de 13 000 employés donc ils ont de quoi investir sur des nouvelles technologies sans avoir besoin de rentabiliser immédiatement le travail fourni…
[1] https://fr.wikipedia.org/wiki/Red_Hat
#14.1
Les employés de Red Hat sont minoritaires dans la contribution à Fedora. Estimation de 35% des effectifs, le reste est communautaire.
https://en.wikipedia.org/wiki/The_Fedora_Project
Canonical a réduit ses investissements sur la version Desktop d’Ubuntu au profit de ses offres liées au Cloud, donc forcément cela doit se sentir dans l’évolution de la distrib d’où l’impression de l’article. Personnellement je n’ai pas touché à Ubuntu depuis la 18.04 donc je ne saurais dire.
#15
On parlait d’écriture de nouveau logiciel, pipewire. Il suffit de regarder les statistiques pour voir que l’essentiel du travail est effectué par un employé de Red Hat qui est virtuellement le seul contributeur
https://gitlab.freedesktop.org/pipewire/pipewire/-/graphs/master
C’est donc trompeur de suggérer que Fedora fait le travail ici, c’est bien Red Hat qui fourni l’effort
#15.1
Fedora est l’upstream de RHEL, c’est normal que le produit soit développé dans le cadre du projet vu qu’il sert à tester toutes les évolutions technologiques dernier cri avant d’avoir une version stable pour la prochaine mouture de RHEL. (A sa sortie, RHEL 8 était basée sur Fedora 28)
#15.2
C’est quoi le rapport avec le commentaire initial qui pointait que Pipewire est un projet financé par Red Hat et que c’est normal que ça soit plus facile pour eux de pouvoir assigner des ressources vu leur chiffre d’affaire et leurs moyens financiers ?
#16
Ce n’est pas tout à fait vrai, du moins ce n’est pas prévu nativement.
Néanmoins, il est possible d’installer plusieurs versions d’un paquet ainsi que ses dépendances en ajoutant en suffix du nom du paquet le numéro de version (majeure)
On a l’exemple de JAVA (OpenJDK/OpenJRE) ou encore PHP qui fonctionne très bien.
Il est alors possible de définir une version qui sera utilisé par défaut via alternatives.
Donc, il existe des parades pour gérer plusieurs versions d’un paquet mais cela demande plus de travail que l’usage d’un flatpak/snap/AppImage.
Pour le développeur qui veut facilement distribuer son application, ces derniers sont très attrayants, d’autant que cela permet également de ne pas tenir compte des différences de format de paquet (DEB, RPM, etc)