openSUSE, Fedora, Flatpak...
Je lisais et participais à un post du forum d'Alionet que j'ai engendré et qui a pour titre "openSUSE LEAP va t'elle continuer au-delà de la 15.5?", qui a du reste un certain intérêt des lecteurs. Bon j'évite le cafouillage qui raconte que j'essaye d'attirer dans mon église (soit disant Debian) ceux qui seront perdus, alors que moi-même je suis sous Tumbleweed --ou était-- et que j'ai des machines en Leap 15.3 15.4, je passerais donc ceci sous silence car il n'y a pas lieux d'en parler. En fait dans ce post, on voit deux choses, de un la plupart des personnes du forum francophone ne sont que des utilisateurs, contribuer est au dessus de leurs forces ou simplement ils s'en foutent...; de deux, ce que nous proposent Fedora et openSUSE pour l'avenir de leurs distributions pose de sèrieuses inquiétudes pour les utilisateurs (en dehors des développeurs) dans le meilleur des cas et même une fuite vers autre chose pour tous les autres, y compris moi...
Avec tout ça, j'ai dû faire des recherches, tester des choses comme Silverblue (Fedora), Nixos, Microos (openSUSE) et j'ai appris beaucoup en peu de temps. A part le fait qu'une seule des trois me convienne qu'a moitié, mais que je suis perdu dès qu'il s'agit d'aller au-delà du simple utilisateur, j'ai appris et vu par mes yeux que Microos n'a pas de Yast, ce n'est pour le moment pas prévu, oui vous avez bien lu, mais au-delà de cette ineptie, car oui à quoi bon choisir une distribution openSUSE si ce n'est pour Yast, je ne peux m’empêcher de me dire que le monde des distributions va subir un tsunami. Dans les news de juillet 2022 d'openSUSE, on peut lire en bas d'article ceci:
In managing expectations, people testing MicroOS should be aware that it is based on openSUSE Tumbleweed, that YaST is not available and that MicroOS’ release manager would appreciate contributions rather than bug reports. MicroOS currently supports two desktop environments. GNOME is currently supported as a Release Candidate and KDE’s Plasma is in Alpha. MicroOS Desktop is currently the closest representation of what users can expect from next generation Desktop by SUSE.
Qu'on traduira par Google:
Lors de la gestion des attentes, les personnes qui testent MicroOS doivent être conscientes qu'il est basé sur openSUSE Tumbleweed, que YaST n'est pas disponible et que le responsable des versions de MicroOS apprécierait les contributions plutôt que les rapports de bogues. MicroOS prend actuellement en charge deux environnements de bureau. GNOME est actuellement pris en charge en tant que Release Candidate et Plasma de KDE est en Alpha. MicroOS Desktop est actuellement la représentation la plus proche de ce que les utilisateurs peuvent attendre de la prochaine génération de Desktop par SUSE.
J'ai lu deux bons articles qui parlent des distributions dites immuables, Distributors entering Flatpakland et Fedora, FFmpeg, Firefox, Flatpak, and Fusion et encore une fois je suis étonné de la façon que Fedora gère la chose, je parle de rpmfusion bien sûr. Je trouve fantastique ce deux poids, deux mesures ou cette justice à géométrie variable... Je livre les traductions de ces deux billets.
Distributeurs entrant dans Flatpakland Par Jonathan Corbet #
8 juillet 2022
Les distributions Linux ont beaucoup changé au cours des 30 dernières années, mais la façon dont elles conditionnent les logiciels est restée relativement statique. Alors que les formats .deb et RPM (et autres) ont évolué avec le temps, leur forme actuelle ne serait pas méconnaissable pour leurs créateurs. Cependant, les distributeurs poussent au changement. Les projets Fedora et openSUSE s'efforcent de réduire le rôle du vénérable format RPM et de passer à Flatpak pour une grande partie de leur distribution de logiciels ; cependant, certains utilisateurs ont du mal à convaincre que c'est une bonne idée.Un paquet binaire traditionnel d'une distribution contient le programme qui vous intéresse, bien sûr, ainsi que tous les fichiers supplémentaires dont il a besoin. Le package contient également des métadonnées décrivant, entre autres, quels autres packages doivent être installés pour que le programme fonctionne. Le gestionnaire de packages de la distribution utilise ces informations de dépendance pour s'assurer que chaque package est correctement installé.
Le format Flatpak a été décrit comme "juste un autre format de distribution" et, dans une certaine mesure, c'est vrai. Un package Flatpak (ou, simplement, "un flatpak") a tout ce qu'un package .deb ou RPM aurait, mais il existe des différences significatives. Peut-être en haut de la liste se trouve la façon dont les dépendances sont gérées. Un package traditionnel aura une liste (éventuellement longue) indiquant tous les autres packages nécessaires ; un package Flatpak, à la place, listera un seul "runtime" contenant l'ensemble de base des bibliothèques sur lesquelles le package est construit. S'il existe des bibliothèques ou d'autres dépendances qui n'apparaissent pas dans l'environnement d'exécution de votre choix, elles sont simplement regroupées avec l'application dans son flatpak.
Cet arrangement a un certain attrait pour les conditionneurs. L'approche "runtime plus bundling" simplifie la gestion des dépendances, et la possibilité de regrouper des versions corrigées du système ou des bibliothèques d'exécution est appelée en tant que fonctionnalité Flatpak. Un package créé pour un runtime donné peut être installé sur n'importe quel système sur lequel ce runtime est installé, ce qui permet de créer un seul package pouvant être installé sur plusieurs distributions. Les distributeurs peuvent ainsi utiliser ce format pour se simplifier la vie ; les fournisseurs de packages propriétaires voient également un charme évident dans cette idée.
Dans un sens, Flatpak a entrepris de résoudre bon nombre des mêmes problèmes que l'effort malheureux de Linux Standard Base résolu il y a de nombreuses années.
Flatpak est conçu pour fonctionner avec des distributions construites autour d'un noyau immuable ; il ne s'installera pas dans les répertoires système comme /etc ou /usr/bin . Cela le rend attrayant pour les distributeurs qui essaient de créer ce type d'offre.
Un autre argument de vente clé pour Flatpak est le mécanisme de bac à sable intégré. Les applications installées avec Flatpak seront, par défaut, exécutées dans un conteneur qui n'a pratiquement aucun accès au système sous-jacent ou à Internet. Grâce à des déclarations dans le fichier manifeste utilisé pour créer le package, une application spécifique peut demander l'accès, par exemple, aux fichiers locaux de l'utilisateur, à Internet ou au serveur du système de fenêtres. En théorie, au moins, ce bac à sable rend l'installation des packages plus sûre et limite les dommages pouvant être causés par un package compromis ou malveillant.
Flatpak n'est pas sans critiques. Bien que les packages puissent partager le même environnement d'exécution, rien n'empêche une prolifération d'environnements d'exécution et de versions ; cela semble déjà se produire dans une certaine mesure. Les runtimes et les packages eux-mêmes sont volumineux, ce qui augmente considérablement la quantité d'espace de stockage et de mémoire consommée. Il est courant que les applications demandent l'accès aux fichiers locaux et à Internet, qu'elles en aient besoin ou non, au point que certains voient les affirmations du bac à sable de Flatpak comme étant plus exagérées que la réalité.
Tout cela s'ajoute à une certaine opposition à l'utilisation de Flatpak. Il semble également possible qu'une grande partie de l'opposition à Flatpak puisse résulter d'une résistance instinctive à changer la façon dont les choses ont toujours été faites.
Flathub (non) filtré de Fedora
Du côté de Fedora, la discussion a été attisée par cette proposition de modification de Fedora 37 supprimant les filtres actuellement appliqués au référentiel de packages Flathub dans l'application logicielle GNOME de Fedora . Une fois le filtre supprimé, tous les packages disponibles sur Flathub, y compris ceux contenant des logiciels propriétaires ou des programmes qui, pour des raisons telles que des problèmes de brevets, ne peuvent pas être livrés avec Fedora, seront disponibles pour être installés. Flathub dans son ensemble sera toujours désactivé, à moins que les utilisateurs n'activent les référentiels tiers.
On dit que les avantages de ce changement sont qu'il rend plus de logiciels facilement disponibles pour les utilisateurs de Fedora et rend ce logiciel plus sûr en le mettant en bac à sable. Cette dernière raison fait partie des raisons pour lesquelles l'outil logiciel GNOME préférera les flatpaks aux packages RPM traditionnels lorsque les deux sont disponibles. Mais il y a des membres vocaux de la communauté Fedora qui sont fortement opposés à l'idée. Vitaly Zaitsev, par exemple, s'est plaint de la préférence pour les flatpaks, affirmant que cela amènerait les flatpaks à remplacer les packages RPM lors de la mise à jour d'un système. Un grand nombre des points mentionnés ci-dessus - la taille de l'installation et les bacs à sable poreux, par exemple - ont été soulevés dans cette discussion, tout comme le parti pris perçu contre le référentiel RPM Fusion, qui a été discuté en profondeur ici en juin.
Il semble peu probable que ces objections arrêtent le non-filtrage de Flathub - ou la transition vers Flatpak en général. La distribution semble engagée dans cette direction, et la variante Silverblue , qui est construite autour d'une installation de base immuable, nécessite déjà Flatpak. Au cours de la discussion, Michael Catanzaro a vanté les avantages de sécurité du format et a souligné que, malgré des années de plaintes, les opposants à Flatpak n'ont pas proposé d'alternative viable offrant des avantages de sécurité similaires. Richard Hughes a fait valoir que " "les flatpaks sont dans presque tous les cas ce que les utilisateurs devraient utiliser" ". À moins que quelque chose ne change, il semble que le futur Flatpak de Fedora avance à toute vitesse.
Les ALP d'OpenSUSE sont plats
En avril, SUSE a annoncé un effort connu sous le nom de "plate-forme Linux adaptable" (ALP) qui est, d'une certaine manière, destiné à définir l'avenir de la distribution SUSE Linux Enterprise (SLE). Il y avait beaucoup de texte sur la façon dont le processus serait ouvert, mais les observateurs extérieurs pourraient être pardonnés de penser que l'ALP reste assez trouble jusqu'à présent. Il n'y a pas encore beaucoup d'informations publiques sur ce que sera ALP ou comment cela affectera les offres d'entreprise de SUSE ou openSUSE. Les indices qui sont sortis, cependant, suggèrent une distribution construite sur un petit noyau immuable avec des applications gérées séparément, très probablement en utilisant un format comme Flatpak.
Le 5 juillet, Dan Čermák a publié le procès-verbal d'une réunion du groupe de travail ALP qui portait sur « à "quoi ressemblera le bureau ALP et comment nous pouvons dissiper les craintes concernant les flatpaks et les conteneurs en ce qui concerne le bureau ALP" ». Le procès-verbal note que Flatpak sera effectivement utilisé comme format de distribution, mais souligne qu'il ne serait pas nécessaire d'installer des flatpaks à partir de sources externes comme Flathub ; " "le modèle d'emballage ne changera pas, seul le format" ".
Interrogé sur les avantages du passage au flatpak, Čermák a mentionné le mécanisme de sandboxing, mais a déclaré que le principal avantage résidait dans la réduction du travail d'emballage. Les applications de bureau telles que Firefox ou LibreOffice pourraient être construites une fois sur la distribution openSUSE Tumbleweed , puis expédiées pour Tumbleweed, Leap , ALP et probablement tout ce que SUSE pourrait créer. Il n'est pas difficile de comprendre pourquoi les distributeurs sont attirés par une option qui pourrait réduire considérablement la quantité de travail nécessaire pour maintenir les packages actuels d'applications complexes.
Il y avait également une opposition fondamentale à l'utilisation de Flatpak dans la communauté openSUSE. Robert Kaiser, par exemple, a déclaré " "s'il ne reste plus de distribution basée sur RPM sans cet emballage étrange comme flatpak, il est probablement temps de revenir à Windows" ". Dans l'ensemble, cependant, la communauté openSUSE semble moins agitée par la perspective - jusqu'à présent du moins. Il peut y avoir plusieurs raisons à cela, notamment un manque relatif d'expérience avec Flatpak dans la communauté openSUSE et la nature amorphe d'ALP en général. Mais cette assurance de Čermák ne peut qu'aider aussi :
Tumbleweed sera le lieu où le développement aura lieu, mais il n'est pas prévu de modifier fondamentalement Tumbleweed. Vous pourrez toujours utiliser Tumbleweed comme vous l'utilisiez auparavant. De plus, vous pourrez utiliser les "trucs conteneurisés", mais vous n'aurez pas à le faire, du moins dans un avenir prévisible.
Il pourrait bientôt arriver un moment où l'utilisation de Flatpak sur Fedora est inévitable, du moins lorsqu'il s'agit d'installer certaines applications complexes. Jusqu'à présent, openSUSE ne semble pas aller dans cette direction, donc les utilisateurs de Tumbleweed (qui constituent une grande partie de la communauté openSUSE) n'ont pas à craindre d'être poussés contre leur gré dans le monde Flatpak.
Il ne faut pas sous-estimer la valeur de ce dernier point. Une grande partie de l'amertume autour de la transition systemd était certainement causée par le sentiment qu'elle était imposée aux utilisateurs qui étaient satisfaits de leur configuration existante et ne ressentaient pas le besoin de changer. Même si Flatpak est aussi bon que certains le prétendent, une transition mal gérée risque de créer des niveaux de mécontentement similaires.
Cette transition semble susceptible de se produire ; dans une publication ultérieure , Čermák a remis en question la valeur de l'emballage de certaines applications complexes et a suggéré qu'elles ne puissent être mises à disposition que sous forme de flatpak si elles sont expédiées par la distribution. Robert Schweikert a dit plus succinctement : « "Ce que nous avons aujourd'hui a fonctionné raisonnablement bien pendant probablement environ 30 ans, mais le modèle montre certainement son âge" ». Évoluer pour répondre aux besoins actuels est exactement ce que les distributeurs doivent faire, et cette évolution apportera sûrement des changements visibles pour les utilisateurs finaux. La clé sera de gérer les changements avec sympathie pour ces utilisateurs et, espérons-le, d'éviter certaines des turbulences que nous avons vues avec les changements passés.
Et le second:
Fedora, FFmpeg, Firefox, Flatpak, and Fusion Par Jonathan Corbet #
16 juin 2022
L'objectif de Fedora de devenir la distribution Linux de bureau de choix a longtemps été entravé par le service juridique averse au risque de Red Hat, qui limite strictement le type de logiciel que Fedora peut livrer. Plus précisément, tout ce qui pourrait être encombré par des brevets est interdit, avec pour résultat qu'une grande partie des médias que les utilisateurs pourraient trouver sur le net sont illisibles. Cette situation s'est améliorée au fil des ans à la suite de beaucoup de travail au sein du projet Fedora, mais elle place toujours Fedora dans une situation désavantageuse par rapport à certaines autres distributions. Une discussion récente sur le support vidéo, cependant, met en lumière la façon dont certains raisonnements juridiques surprenants peuvent fournir une solution à ce problème ; cette façon peut ne pas plaire à toutes les personnes impliquées, cependant.FFmpeg et Firefox
Début juin, Otto Urpelainen a posté (sur la liste de développement de Fedora) un comportement surprenant qu'il avait observé sur son système. Initialement, le navigateur Firefox était capable de lire les vidéos qu'il voulait regarder. Cependant, l'installation du package sans ffmpeg de Fedora a entraîné l'échec de la lecture de ces vidéos. Comme l'a noté Urpelainen : " "C'est inattendu, car on s'attendrait à ce que l'installation de n'importe quelle variante de ffmpeg améliore le support vidéo, et non le dégrade" ".
Comme l'a souligné Kevin Kofler , ce comportement ressemble à un bug de Firefox, qui est incapable de trouver la variante OpenH264 du décodeur H.264 trouvée dans le package ffmpeg-free . Mais personne n'a perdu de vue que ce problème ne se produit pas si la version de FFmpeg fournie par RPM Fusion est installée à la place, et que le codec H.264 qui s'y trouve ne nécessite pas les diverses convolutions nécessaires pour obtenir OpenH264 sur Fedora. Certains pensent que la prise en charge H.264 dans RPM Fusion fonctionne mieux également. Pour cette raison, Vitaly Zaitsev a déclaré que la solution appropriée consiste uniquement pour les utilisateurs à activer RPM Fusion.
Michael Catanzaro a contesté ce conseil :
Vitaly, vos suggestions pour activer rpmfusion ne sont pas utiles pour les utilisateurs inexpérimentés de Fedora, qui s'attendent à ce que le multimédia fonctionne immédiatement. Les besoins multimédias courants tels que "jouer une vidéo" doivent absolument fonctionner sans rpmfusion, et nous avons besoin que les développeurs de Fedora testent cela pour s'assurer que cela fonctionne.
Mais Kofler a répondu que " "Il est de notoriété publique que Fedora est/était effectivement inutile pour tout ce qui concerne à distance le multimédia sans les packages RPM Fusion" ". Zaitsev a doublé plus tard en disant que Fedora devrait simplement précharger le référentiel RPM Fusion afin que les utilisateurs n'aient pas besoin de passer par le processus d'apprentissage qu'ils en ont besoin et de trouver comment l'activer eux-mêmes.
C'est le processus qui est requis maintenant; une nouvelle installation de Fedora ne sera pas configurée pour obtenir des packages de RPM Fusion et n'aidera pas les utilisateurs à comprendre que, tôt ou tard, ils devront configurer ce référentiel. Mais la résolution de ce problème ne semble toujours pas être en cours ; l'une des contraintes imposées au projet Fedora est qu'il ne peut pas aider les utilisateurs à trouver des référentiels contenant du code qui, par exemple, pourrait avoir des problèmes de brevet dans certaines juridictions. Cette approche "faire comme si ce n'était pas là" a conduit à une certaine frustration au fil des ans.
Entrez Flatpack
Plus récemment, cependant, il y a eu un développement sur un front connexe. En juin 2021, le projet a adopté une proposition visant à configurer le référentiel Flathub par défaut sur les systèmes Fedora. Flathub est, comme RPM Fusion, un référentiel indépendant (géré par la Fondation GNOME) et, encore une fois comme RPM Fusion, il contient des logiciels que Fedora ne peut pas distribuer, mais il distribue des packages au format Flatpak plutôt qu'en utilisant RPM. Il y a une poussée au sein de Fedora pour expédier les applications sous forme de flatpaks plutôt que sous forme de RPM. Flatpak facilite la gestion des dépendances et, en théorie du moins, peut exécuter des applications dans des bacs à sable sécurisés, mais de nombreux développeurs considèrent le format comme inférieur et préféreraient l'éviter.
Le référentiel Flathub a été configuré en mode "filtré", ce qui signifie que seules les applications acceptables pour Fedora seraient disponibles (par défaut), mais cela laissait encore de la place pour des flatpaks propriétaires comme Zoom, Microsoft Teams et Minecraft. En avril dernier, cependant, la situation a changé : la permission avait été reçue d'abandonner le filtrage et de présenter le référentiel Flathub complet aux utilisateurs. Les développeurs de Fedora travaillent actuellement à activer ce changement pour la prochaine version de Fedora 37. Catanzaro s'est félicité de cette nouvelle :
Euh, donc tout de Flathub va bien maintenant, pas de restrictions ? Sérieusement une excellente nouvelle. Dans ce cas, je dirais que la priorité numéro un est d'arrêter complètement d'expédier Firefox et Totem de Fedora, et de les obtenir par défaut de Flathub à la place.
Tout le monde n'était pas si joyeux, d'autant plus que le plan est de faire en sorte que le système sélectionne un package flatpak plutôt qu'un package RPM traditionnel lorsque les deux sont disponibles. Le report vers un référentiel extérieur pour des packages importants comme Firefox n'est pas non plus universellement accepté comme idéal. Mais l'idée que Fedora puisse désormais configurer librement l'accès à un référentiel externe avec un logiciel que Fedora ne peut pas livrer lui-même est généralement la bienvenue. Cela pourrait être une solution aux limitations de longue date de Fedora en ce qui concerne les formats de médias problématiques.
Pourquoi pas RPM Fusion ?
Depuis que cette décision a été prise, les développeurs ont demandé si l'accès à RPM Fusion pouvait également être préchargé dans Fedora, toujours pour se faire dire que ce n'était pas possible. La question est également revenue dans cette conversation; Catanzaro a répondu
Pour éviter tout doute, Fedora Legal a décidé que nous pouvons utiliser flathub mais pas rpmfusion. Comme je vous l'ai expliqué précédemment, ils ont également décidé de ne pas partager leur raisonnement à ce sujet.
Le chef du projet Fedora, Matthew Miller, a répondu avec un pointeur vers cette explication :
Flathub est un référentiel tiers qui fournit des logiciels pour diverses distributions Linux. Il ne façonne pas le logiciel qu'il transporte, ce que Fedora ne fait pas. Il existe fondamentalement pour résoudre un problème avec la distribution d'applications Linux auquel nos politiques concernant les licences, la liberté des logiciels, etc., sont accessoires. Cela en fait un cas différent.
Il est juste de dire que tout le monde ne trouve pas cette explication convaincante. Kofler l'a décrit comme « "un double standard absolument ridicule" ». "Maxwell G" l'a appelé " "un argument assez fragile" ". Petr Pisar a essayé d'expliquer la différence : RPM Fusion cible spécifiquement Fedora, tandis que Flathub n'est pas spécifique à Fedora, et cela fait en quelque sorte une différence.
La logique derrière cette politique a sûrement du sens pour quelqu'un du service juridique de Red Hat, mais elle peut avoir des conséquences fâcheuses pour la communauté des utilisateurs de Fedora. Il n'est pas difficile d'imaginer que cela pourrait causer un manque de moral parmi les développeurs de RPM Fusion, qui ont travaillé pendant de nombreuses années pour combler une lacune clé des systèmes Fedora. Si Fedora pousse ses utilisateurs vers la solution Flathub, RPM Fusion pourrait éventuellement abandonner, ne laissant aucune alternative à Flathub, qui est un référentiel moins attrayant pour beaucoup. Il n'est pas du tout clair que Fedora et sa communauté d'utilisateurs seraient mieux dans ce monde.
Plusieurs choses m'interpellent, chez openSUSE pour commencer, je ne vois pas l'intérêt d'une distribution sans son outils qui l'a rend si unique. Microos ne date pas d'hier et de voir que pour le moment Yast n'y est pas possible, c'est juste incohérent... Chez Fedora c'est juste le fait de ne pas inclure tout ce qui juridiquement pourraient poser problèmes, de ne pas rendre rpmfusion disponible en sortie de boite sans rien faire de plus, mais par contre si c'est flatpack pourquoi pas. Je sais que le but de Fedora tôt ou tard est de passer en force les flatpacks mais quand même...
Je vous laisse vous faire votre opinion.
Commencer la discussion: Venez écrire un commentaire dans le forum