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.
Si c’est sans doute le cas de certaines d’entre elles, nous ne pouvons en conclure que c’est toujours le cas. En particulier, 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. Si finalement une 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 afin d’améliorer l’usage bureautique de l’utilisateur.
Et si la distribution Fedora est souvent considérée comme une version de test pour la distribution Red Hat Enterprise Linux (RHEL) de Red Hat 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 fait suite à un premier article à ce sujet qui avait donné lieu à une conférence lors des JM2L de 2017 et aux RMLL de 2018 dont la vidéo est disponible.
Sommaire
Expérience utilisateur
Pipewire
Wim Taymans, coauteur de GStreamer et grand contributeur de PulseAudio, étend 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. 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 27. Et son usage commence à produire ses premiers effets.
En effet, grâce à ce composant, GNOME Shell est capable de faire de l’affichage distant de la session avec Wayland via le protocole VNC. Cela permet donc les usages de contrôles à distance graphique. Merci à Jonas Ådahl pour ce résultat.
Séquence de démarrage
Affichage de GRUB
Hans de Goede a travaillé pour masquer GRUB par défaut sous Fedora, sauf si plusieurs systèmes sont installés. En effet, dans ce cas de figure, GRUB ne sert qu’à démarrer un ancien noyau, ce qui est nécessaire uniquement en cas de souci. Pour des raisons de cohérence et de simplicité, les messages de démarrage étant cachés par défaut, ce menu est caché pour ne pas perturber l’utilisateur outre mesure et gagner du temps.
Un nouveau mécanisme est mis en place. Le menu caché est finalement affiché si le précédent démarrage n’a pas abouti à une session valide. Cela autorise ainsi une résolution possible du problème. Pour désactiver cette fonctionnalité, vous pouvez manuellement appliquer la commande suivante avec les droits super‐utilisateur :
# grub2-editenv - unset menu_auto_hideHans de Goede a publié une FAQ à propos de ce changement pour savoir comment l’activer ou le désactiver, et quel est le comportement en cas de problème. Ce travail documenté permet à d’autres distributions de reproduire ce comportement pour simplifier la séquence de démarrage.
Démarrage sans remise à zéro de l’affichage
Pour les utilisateurs d’une carte graphique Intel et d’un ordinateur avec l’UEFI activé, l’affichage durant le démarrage est continu, sans remise à zéro de ce dernier. Cela rend l’expérience plus fluide et jolie. Le changement fait suite à la modification introduite dans Fedora 29 pour qu’un ordinateur mono‐système ait GRUB masqué par défaut. Le nouveau thème Plymouth bgrt récupère également le logo du constructeur de l’ordinateur ou de la carte mère durant le démarrage. Si vous ne souhaitez pas voir ce logo, basculez vers le thème spinner. Vous pouvez regarder cette vidéo pour voir le changement en action et les explications en détails et la FAQ par Hans de Goede, son développeur.
Les jeux vidéo
Beaucoup de tests ont été effectués par Olivier Fourdan et Jonas Ådahl pour identifier les problèmes d’exécution des jeux vidéo Steam avec GNOME sous Wayland. Ils ont pu en corriger l’essentiel. Cela permet de repousser les limites des cas d’usage de Wayland et rendre ainsi chaque jour X11 de moins en moins nécessaire.
Pour améliorer également les performances des jeux vidéo, l’entreprise Feral Interactive a développé le projet GameMode pour optimiser la configuration du système dans le but de maximiser les performances lors de l’exécution d’un jeu. Pour l’instant, Fedora se contente de proposer par défaut ce paquet, mais une réflexion est en cours pour essayer de rendre ce paquet dispensable, en améliorant le gouverneur du processeur par exemple.
Gestion du matériel
Autonomie
Hans de Goede a travaillé sur une meilleure gestion de l’autonomie des ordinateurs portables avec un processeur Intel. Cela passe par une meilleure gestion de l’énergie des ports SATA pour disques durs et SSD (gain estimé entre 1 W et 1,5 W) en reprenant le mode utilisé par Windows : med_power_with_dipm. Pour le multimédia, Intel HDA codec est mis en sommeil après une seconde d’inactivité (gain estimé de 0,4 W). Et activation de l’économie d’énergie pour les récepteurs Bluetooth en USB (gain estimé de 0,4 W si tous les ports USB sont au repos). Sachant qu’un ordinateur portable récent non orienté puissance consomme moins de 10 W (7,5 W, par exemple, sur un Lenovo E560) en usage non intensif. Cela peut donner 20 % d’autonomie supplémentaire.
Thunderbolt 3
Thunderbolt 3 est une norme concurrente à l’USB sur de nombreux points. Cette norme permet en effet de gérer des transferts de données ou de brancher un écran externe par exemple sur le même port. Cependant, ces périphériques pourraient accéder à des informations sensibles de votre machine lors du branchement pour des raisons de performances. En effet, pour alléger la charge processeur, ces périphériques peuvent être maîtres de la communication DMA. C’est pourquoi la norme propose une politique de sécurité pour que l’utilisateur autorise ou non l’accès à l’ordinateur, et éviter ainsi que discrètement un appareil branché sans votre consentement ait un libre accès. Il est maintenant possible de configurer dans GNOME ces accès par le biais des notifications ou du panneau de configuration qui lui est dédié.
Les politiques de sécurité possibles étant :
- none : pas de restrictions ;
- dponly : uniquement la sortie vidéo via DisplayPort ;
- user : les périphériques connectés doivent recevoir une autorisation de l’utilisateur ;
- secure : l’utilisateur doit autoriser l’appareil également et l’appareil doit prouver son identité avec une clef secrète.
Développement
Fedora Toolbox
Debarshi Ray a développé l’outil Fedora Toolbox pour simplifier le développement en utilisant massivement les conteneurs. Ainsi, il sera par exemple plus simple de développer votre projet maison avec Fedora pour bénéficier des dernières versions, de le tester sur RHEL pour la compatibilité et, s’il s’agit d’un jeu, d’exécuter cela dans un environnement SteamOS.
Un gros travail est en cours pour améliorer encore l’expérience utilisateur afin de ne pas avoir à réinstaller les mêmes outils dans chaque conteneur, ou d’être confus à propos du contenu de chacun. Il est envisagé de pouvoir plus facilement travailler sur des environnements complexes précis, tels que Tensorflow ou CUDA, par exemple.
Son intérêt sera particulièrement important dans le cadre du projet Silverblue, détaillé plus bas. En effet, dans le contexte d’un système immutable, l’objectif sera de reposer les outils de développement sur des conteneurs manipulés à travers ce genre d’outils.
Et demain ?
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.
La bonne prise en charge de tels écrans n’est possible qu’avec Wayland, et GNOME dispose à titre expérimental d’une telle fonctionnalité qui a besoin de quelques raffinements encore. Pour ceux qui veulent tester, il suffit d’ajouter la valeur scale-monitor-framebuffer à la clef GSettings org.gnome.mutter.experimental-features pour que le panneau de configuration le propose.
Cela peut être effectué à l’aide de la commande suivante :
$ gsettings set org.gnome.mutter.experimental-features ['scale-monitor-framebuffer']Ce travail est le fruit de la collaboration entre Jonas Ådahl de Red hat et Marco Trevisan de Canonical. Il devrait être bientôt disponible de manière stable.
Pipewire
Pipewire est encore en voie de maturation. De nombreuses choses restent à faire ou à stabiliser. Par exemple, Jan Grulich, Tomas Popela et Eike Rathke travaillent sur la fonctionnalité d’écran partagé avec Wayland pour Firefox et Chrome afin, par exemple, de partager son écran lors d’une visioconférence avec WebRTC. Cependant, cela n’est pas encore assez stable pour être activé par défaut. Si vous le souhaitez, avec Chrome, il suffit d’activer l’option chrome://flags/#enable-webrtc-pipewire-capturer.
La gestion de l’audio n’est pas encore en place, bien que le chantier soit bien avancé. Pipewire peut utiliser un greffon PulseAudio de GStreamer pour jouer le son de certaines applications GNOME. Wim teste également les applications employant Jack pour corriger les problèmes de compatibilité. Il fait également des tests sur une barre de son Sony HT-Z9F pour s’assurer du bon fonctionnement de Pipewire avec ce genre de matériel. Ainsi, à terme, les protocoles S/PDIF, HDMI ou Bluetooth seront pris en charge convenablement. Le codec LDAC, qui est un codec de haute qualité audio pour le Bluetooth, sera également de la partie.
La prise en charge de JACK devrait être disponible avant celle de PulseAudio. Les premiers résultats stables pourraient apparaître pour Fedora 31 à ce niveau.
OpenH264
Cela fait quelque temps que Firefox dispose de la bibliothèque OpenH264 de Cisco pour décoder matériellement le format H.264 qui est très répandu. Cependant, le format H.264 dispose de ce que l’on appelle des profils. L’objectif est d’activer certaines fonctionnalités du format suivant le cas d’usage de la vidéo. Une visioconférence, par exemple, a besoin d’une plus faible qualité d’image que le film enregistré sur votre disque dur, et ce, afin de limiter le besoin en bande passante et en latence.
OpenH264 ne prenait en charge que le profil baseline. Grâce à une collaboration de Red Hat, Endless, Cisco et Centricular, les profils high et main seront proposés prochainement. Le travail est en fait déjà partiellement disponible, mais quelques raffinements restent nécessaires avant de le proposer par défaut. Des plates‐formes de vidéo en ligne comme YouTube pourront en tirer parti prochainement.
Les applications reposant sur la bibliothèque GStreamer, comme Totem de GNOME seront également bénéficiaires de cette amélioration.
Wayland
Firefox
Fedora a beaucoup œuvré pour proposer Wayland par défaut et faire en sorte que les logiciels essentiels fonctionnent bien avec, comme LibreOffice et GNOME. C’est également le cas pour Firefox qui commence à voir le bout du tunnel, ce travail étant porté par Martin Stransky.
Fedora avait un dépôt COPR pour tester Firefox avec Wayland, puis un paquet officiel firefox-wayland était proposé depuis Fedora28. Ce dernier n’étant qu’un script qui lance Firefox avec la variable d’environnement MOZ_ENABLE_WAYLAND définie à 1. Cela a permis de constater de nombreux problèmes qui ont pu être corrigés. Pour Fedora 31, qui devrait sortir en fin d’année 2019, Firefox avec la gestion native de Wayland sera proposé par défaut. Ainsi, l’un des derniers composants par défaut de Fedora Workstation pourrait se passer du besoin d’utiliser XWayland.
Pilote propriétaire de NVIDIA
Il y a également le pilote propriétaire de NVIDIA qui n’offre pas pleinement une bonne expérience avec une session sous Wayland. Ce qui est, bien sûr, un problème pour ceux qui veulent tirer le plein potentiel de la carte graphique, en particulier pour les jeux ou le montage vidéo. Des travaux importants d’Adam Jackson ont pu résoudre des problèmes pour la gestion des espaces de couleur et des écrans multiples. Mais il manque toujours la compatibilité avec XWayland pour offrir une expérience complète d’une session sous Wayland. Si vous n’en avez pas besoin, cela devrait fonctionner convenablement dès maintenant.
Les souris à haute résolution
Les souris à destination des joueurs ou des graphistes ont souvent des résolutions plus hautes afin d’améliorer la sensibilité et la précision du pointage. C’est pourquoi Peter Hutterer et Benjamin Tissoires ont proposé une RFC pour Wayland afin de tenir compte de ces cas d’usage. Le périphérique Dell Totem pourrait avoir une prise en charge pour Fedora 31.
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.
Depuis la dernière fois, des progrès sensibles ont été obtenus. Un site Web a été mis en ligne pour suivre l’évolution de ce travail pour une dizaine de paquets. Une fois que cet essai sera transformé, l’objectif est bien sûr d’étendre ce système à l’ensemble des paquets concernés.
Une réflexion est menée pour que GNOME Logiciels propose via une option de choisir d’installer un logiciel depuis Flatpak ou le dépôt RPM par défaut. À plus long terme l’option disparaîtrait pour laisser place aux Flatpak uniquement, les RPM seraient relégués à la base du système.
L’outil fleet commander avec Active Directory
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. Il permet de gérer des milliers de machines. Il est possible de configurer les postes avec un navigateur Web ou l’outil Cockpit.
Oliver Gutierrez a intégré la sauvegarde de la configuration avec la solution Active Directory en plus de FreeIPA, qui n’attend plus que la mise à disposition de la nouvelle version. Cela permettra de rendre cet outil plus pertinent dans plus d’entreprises et d’administrations, qui utilisent plus souvent Active Directory que FreeIPA.
Fedora Silverblue
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 nativement, 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, par exemple, les risques liés à une procédure exécutée dans un ordre différent de celui prévu. 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.
Une telle architecture propose aussi un système dans un état immutable, le rendant plus fiable. Ce qui impose une séparation plus stricte et claire entre le système et les applications. Cela parachève le travail envisagé par le projet Fedora.next. L’objectif est que Fedora propose un système de base et immutable à travers rpm-ostree, et que les applications traditionnelles soient installées uniquement avec des Flatpak.
Devant l’intérêt récent pour cette technologie, un groupe de travail a été constitué l’année dernière. Le projet a également été renommé en Fedora Silverblue, et de grands progrès fonctionnels ont eu lieu depuis.
En effet, cela fait deux cycles de développement de Fedora pendant lesquelles Fedora Silverblue a bénéficié d’une journée de tests. Ainsi, de nombreuses personnes, dont votre serviteur, ont pu le tester pour vérifier la viabilité du système avec l’image de base et les applications provenant du dépôt Flathub. Et les résultats sont positifs.
Aujourd’hui, la gestion des Flatpak est complète. GNOME Logiciels permet de gérer un système reposant sur rpm-ostree. Les situations un peu particulières ont été réglées, comme Google Chrome qui installe tout dans /opt, ou le pilote graphique propriétaire de NVIDIA qui ne peut être distribué nativement.
Le travail reste important pour gérer l’ensemble des cas d’usage tout en proposant une expérience utilisateur optimale. Par ailleurs, quelques travaux restent nécessaires pour proposer des environnements de développement complets capables de gérer un tel système, la gestion des codecs ou encore des applications complexes comme VirtualBox.
Matthias Clasen a publié un article complet, pour ceux qui veulent plus de détails.
Vous pouvez tester Fedora Silverblue en téléchargeant les images mises à disposition régulièrement.
Conclusion
Comme nous pouvons le voir avec cette liste d’exemples, des distributions d’envergure comme Fedora, mais aussi Ubuntu, Debian ou autres peuvent apporter bien plus qu’une liste de logiciels à installer. Elles proposent des nouveaux outils, participent au développement ou à la stabilisation des logiciels qu’elles fournissent, peuvent collaborer avec d’autres entreprises ou communautés pour améliorer la prise en charge de leurs produits.
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
- Première partie de la série (289 clics)
- Blog de Christian Schaller : An update from Fedora Workstation land (22 clics)
- Blog de Christian Schaller : Preparing for Fedora Workstation 30 (26 clics)
- Vidéo de la conférence des RMLL 2018 (22 clics)
- Site officiel du projet Fedora (52 clics)
- Site officiel de la communauté francophone de Fedora (38 clics)
# Silverblue
Posté par saltimbanque (site web personnel) . Évalué à 3.
Est-ce que tu penses que Silverblue pourra s'imposer comme le modèle unique de Fedora? J'ai vaguement suivi quelques avancées mais je ne me rends pas compte de l'effort restant à fournir. Par ailleurs je ne sais pas si d'autres distribs mènent des travaux similaires
[^] # Re: Silverblue
Posté par daemontux . Évalué à 3.
J'ai testé brièvement récemment et ça m'a fait plutôt bonne impression au niveau de l'avancement. Il me semble que le gros truc qui manque avant que ça soit utilisable au quotidien (pour moi en tout cas) ce sont les paquets Flatpak. Actuellement très peu sont dispos, et il faut passer par rpm-ostree pour installer la grosse majorité des programmes, ce qui implique à chaque fois un reboot.
Une fois que ce sera fait j'ai l'impression que pour le reste l'essentiel est là à part peut-être quelques edge-cases à gérer (personnellement j'avais un truc à fixer dans /usr pour avoir le son sur mon chromebook, j'ai pas trouvé de moyen de le faire donc je suis repassé sur Fedora "normal").
[^] # Re: Silverblue
Posté par François Druel (site web personnel) . Évalué à 2. Dernière modification le 19 mai 2019 à 15:42.
Merci pour cet article sur Fedora…
Est-ce que je peux profiter de cette discussion pour poser une question sur Silverblue car les choses ne sont pas claires dans mon esprit. J'ai un peu regardé et tout ce que j'ai trouvé c'est qu'il s'agit d'une version "immuable"… OK, mais que veux-dire "immuable" au juste ?
Si quelqu'un pouvait m'éclairer un peu, ça m'aiderait bien…
Merci
F
"Il n'y a de richesse que d'hommes" (J. Bodin) - Trésorier de l'association GUTenberg (https://www.gutenberg-asso.fr/)
[^] # Re: Silverblue
Posté par Renault (site web personnel) . Évalué à 10.
Fedora Silverblue est une autre manière de gérer un OS qui est en phase avec les buts exprimés par Fedora.next.
Via rpm-ostree, Silverblue a un système de base immuable, c'est-à-dire que le système de fichier principal (les dossiers /, /usr, etc.) sont en lecture seule à l'exception de /etc et /var. Ce dernier sert notamment à héberger le point de montage de /home par ailleurs.
Le but est que l'image fournie par Silverblue soit minimale. Si tu veux des applications supplémentaires, tu dois recourir aux conteneurs ou aux Flatpaks. Ce qui améliore l'isolation des processus, la gestion des dépendances, les permissions qu'ils ont sur le système, cela simplifie leur déploiement, etc. Ainsi cela améliore grandement la fiabilité du système de base car il a qu'un minimum de choses à fournir.
Il peut donc évoluer plus facilement, et tu peux plus facilement mettre à jour (ou non) tes applications dans le temps, sans devoir suivre le calendrier de sortie des nouvelles versions de Fedora qui dans ce cas de figure ne mettrait à jour que le socle de base du système. Tu gagnes en indépendance de ce point de vue.
Et du coup comme le système est minimal, le but est que ce système fonctionne par états. En réalité quand tu mets à jour ou que tu installes un système actuellement, tout est dynamique, tu dis au système d'extraire des fichiers d'un paquet, de les copier à différents endroits du système et d'exécution de scripts qui permettent par exemple de convertir des fichiers de confs d'un format ancien à un autre, ou de créer un utilisateur système qui exécutera le service plus tard, etc.
Toutes ces procédures étant dynamiques, il faut anticiper pas mal de choses car ta Fedora 30 et ma Fedora 30 ne seront pas identiques, nous aurons chacun des applications différentes installées ou en fonctionnement. Cela est source de bogues difficiles à anticiper et à gérer.
Par ailleurs le problème du modèle traditionnel, c'est que la procédure de mise à jour est critique. Une coupure de courant au mauvais moment et tu peux avoir un système dysfonctionnel voire non fonctionnel.
Avec le mécanisme de rpm-ostree, comme l'image de base est minimale, en fait on télécharge un état complet du système. Et au redémarrage, on applique le changement de cet état. C'est comme effectuer un multiboot sur différents OS, sauf que cette fois ce multiboot concerne un système unique dans un état différent. Et en plus optimisé évidemment pour ne pas gaspiller inutilement des Gio en bande passante ou espace disque. L'état du système étant caractérisé par les applications installées dans le système même et leurs versions.
C'est pourquoi l'autre personne plus haut disait qu'en installant un paquet via rpm-ostree nécessitait de redémarrer la machine pour en tirer bénéfice. Mais l'avantage, c'est qu'en cas de coupure de courant durant l'installation, il n'y a pas de problèmes car l'état du système actuel est préservé.
Du coup, à partir de ce rapide exposé, qui j'espère est assez clair, on peut en déduire aussi les inconvénients de Silverblue et des problèmes à résoudre.
Le système est plus gros, car tu perds beaucoup dans la mutualisation des ressources comme les bibliothèques partagées entre les applications. C'est le problème d'utiliser les conteneurs, cela améliore l'isolation entre les applications au détriment du partage de données communes.
Le système est sans doute plus complexe à appréhender et surtout inhabituel, il faut former les gens à ce genre d'architectures. Que ce soit les utilisateurs, administrateurs systèmes ou les développeurs. Beaucoup d'applications, dont les proprio, ont besoin d'une adaptation pour fonctionner convenablement dans ce cas.
L'intégration des composants est plus délicate à fournir, car on délègue cette tâche aux conteneurs et aux utilisateurs pour les versions utilisées pour els différents logiciels.
Enfin, certains cas d'usage comme le développement, se prête moins bien à ce genre d'architecture. Devoir redémarrer sa machine car on a installé une bibliothèque pour coder sur son projet est pénible, surtout si on réalise qu'on en a oublié en route. Et les Flatpaks ne fournissent que des applications graphiques finales. C'est pourquoi il y a ce travail autour de Fedora toolbox, pour contourner le problème en fournissant un moyen simple d'utiliser les conteneurs applicatifs pour développer à l'ancienne tout en gardant son système de base immuable.
[^] # Re: Silverblue
Posté par François Druel (site web personnel) . Évalué à 1.
Alors là, merci +++ :-)
C'est pas simple mais j'ai compris (cf. https://youtu.be/EMrpcEMlFx8?t=34). Ce que je pige c'est qu'il s'agit d'une sorte de fonctionnement en mode "sandbox", avec ses avantages et ses inconvénients.
Surtout, ce que je pige c'est qu'il s'agit d'approche très différente des "LTS" d'Ubuntu… une autre philosophie en fait…
Merci encore
F
"Il n'y a de richesse que d'hommes" (J. Bodin) - Trésorier de l'association GUTenberg (https://www.gutenberg-asso.fr/)
[^] # Re: Silverblue
Posté par Cᴬᴾᵀ Samavor . Évalué à 1. Dernière modification le 06 juin 2019 à 18:04.
Flatpak c'est pour les applications graphiques…
Si j'ai besoin d'installer quelques paquets -devel et utilitaires en ligne de commande sans redémarrer y a-t-il un utilitaire de sandbox ou container mis en avant par la distribution pour ce usage ?
Le but étant autant de ne pas redémarrer que de ne pas surcharger le système de base, une capacité d'héritage dans le container/sandbox est obligatoire.
Après ça fait un système de MàJ supplémentaire à gérer en plus d'ostree et flatpak…
Sinon j'ai essayé d'essayer Silverblue quand le disque d'un petit système autonome qui tourne sur Fedora m'a lâché, mais y'a apparemment un problème avec les disques chiffrés.
[^] # Re: Silverblue
Posté par Renault (site web personnel) . Évalué à 6.
Certains contributeurs travaillent pour aboutir à proposer Silverblue comme version de référence de Fedora, oui. De là à dire s'ils réussiront leur pari est compliqué à anticiper, tant les difficultés sont nombreuses encore.
Globalement il semble assez aisé d'imaginer de fournir Silverblue comme une version dédiée au cas d'usage lambda mais que pour les cas d'usages plus exotiques comme ceux liés aux développements nécessitent toujours une image traditionnelle.
C'est un travail de longue haleine, il faut se montrer patient et contribuer dans la mesure du possible si cela nous intéresse.
# Petite erreur de date
Posté par daemontux . Évalué à 2. Dernière modification le 19 mai 2019 à 00:20.
Sauf erreur de ma part, c'est fin 2014 et non 2011 qu'est sortie Fedora 21 (ça m'a interpellé car j'utilisais Fedora à l'époque et je n'avais pas souvenir d'avoir utilisé la version workstation).
[^] # Re: Petite erreur de date
Posté par Benoît Sibaud (site web personnel) . Évalué à 5. Dernière modification le 19 mai 2019 à 12:26.
https://fr.wikipedia.org/wiki/Liste_des_versions_de_Fedora
Fedora 16 : 8 novembre 2011
Fedora 21 : 9 décembre 2014
https://fr.wikipedia.org/wiki/Liste_des_versions_de_Fedora#Fedora_21
Fedora 21 est sortie le 9 décembre 2014. Cette version marque l’arrêt des noms de versions. Le développement de cette version a pris un an. Des versions plus ciblées ont fait leur apparition : Workstation, Server et Cloud.
Corrigé, merci.
# Avenir de Linux
Posté par David Demelier (site web personnel) . Évalué à 6.
Attention ce qui suit est sujet à troll / débats.
Étant libriste depuis plus de 15 ans et ayant utilisé d'autres systèmes que GNU/Linux (notamment FreeBSD et NetBSD en bureau) j'ai parfois envie de dire que Red Hat est aussi entrain de tuer l'écosystème.
Pipewire
Comme vous le savez tous, PulseAudio était connu pour être particulièrement populaire pour ces plantages incessants lors de ses débuts. C'était d'ailleurs le cas sur les autres systèmes que Linux, ce qui a accentué sa mauvaise image pendant pas mal d'années. Honnêtement, maintenant ça fonctionne bien et j'avoue que c'est plutôt facile pour moi de passer d'un profile bluetooth / dock / jack sur mon thinkpad.
Pipewire est récent et à priori par encore utilisé tant que ça (corrigez moi si je me trompe) donc son intégration va à nouveau être longue et semée d'embuches. D'autant plus que si ça souhaite intégrer l'audio, on va de nouveau avoir des problèmes de support dans les boites à outils (Qt, Gtk, SDL, Firefox ?). J'aimerais en savoir plus, mais à vue de nez ça m'inquiète.
Flatpak
Alors franchement, flatpak est clairement la technologie qui m'agace le plus ces derniers temps. Je n'aime pas le concept, je n'aime pas son implémentation et encore moins son utilisation. À mon avis, flatpak est entrain de Windowiser les distributions. Bientôt, on va pouvoir se rendre sur telecharger.com et double clicker sur un paquet pour installer nos applications favorites. Les développeurs de distributions font en sorte que tout l'écosystème d'une distribution soit pur et cohérent. Avec flatpak on installe directement les outils et applications depuis le projet. Et un développeur d'une application ne connaît pas forcément tous les rudiments du packaging et ses spécificités. Ainsi on laisse openbar notre système.
Fedora
Fedora était de loin ma distribution préférée dès mes débuts. Mais plus j'ai avancé dans les versions avec, plus je me suis rendu compte à quel point c'est instable.
https://bugzilla.redhat.com/show_bug.cgi?id=1029213
https://bugzilla.redhat.com/show_bug.cgi?id=1416310
https://bugzilla.redhat.com/show_bug.cgi?id=1585276
J'ai donc progressivement quitté Fedora pour des distributions minimaliste où j'ai supprimé tout les Red Hat'ware.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Avenir de Linux
Posté par Jiel (site web personnel) . Évalué à 5. Dernière modification le 20 mai 2019 à 10:01.
De mon expérience, on peut faire beaucoup de reproches à Fedora mais pas celui de l'instabilité. Toutes les distributions ont des bugs, mais Fedora est une distribution pour le bureau qui est très stable. On l'installe, ça fonctionne. Quasiment pas de vilains crash logiciels (VLC?), tout se passe comme prévu. On peut travailler, jouer, faire du multimédia. Il y a une vraie attention à la finition chez Fedora, les versions stables sont vraiment stables. La stabilité est bien supérieure à la majorité des autres grandes distributions.
En revanche, pour un serveur, si on veut quelque chose de similaire, on préférera sûrement davantage une CentOS qui est plus faite pour ça.
[^] # Re: Avenir de Linux
Posté par saltimbanque (site web personnel) . Évalué à 4.
genre l'impression ne marche plus au moment où il fallait tirer l'attestation… ou encore carrément le navigateur web alors qu'il faut payer en ligne… j'ai du renoncer à Fedora alors que j'adorais cette distro
[^] # Re: Avenir de Linux
Posté par Renault (site web personnel) . Évalué à 10.
Et comment tu tues un écosystème alors que le code source de ce qui est produit est libre et que Red Hat ne contrôle pas tous les projets libres du monde ? Il faut m'expliquer.
PulseAudio, c'est une affaire qui remonte il y a une dizaine d'années maintenant. La QA de Fedora (et de Linux en général) a considérablement changé depuis. Croire que le même scénario va se reproduire ne tient pas compte de tout ceci.
Puis concernant PA / Pipewire, outre la QA qui a changé, il y a quelques points qui explique les soucis initiaux de PA et que Pipewire ne connaîtra pas. D'abord Ubuntu (et d'autres distributions en dehors de Fedora) on inclus PA alors que ce dernier n'arrivait pas encore à être pleinement stabilisé. Ils sont allés trop vite, car PA offrait des améliorations fonctionnelles très demandées (ce que Pipewire propose moins). Ensuite, PA a beaucoup souffert de la qualité des pilotes audio sous Linux qui n'étaient pas terribles, ce qui est heureusement corrigé aujourd'hui.
Et en quoi c'est mal, avec de réels arguments autre que Windows ou macOS font pareils ?
Le modèle des distributions classiques a fait son temps, il présente de gros défauts structurels que personne ne souhaite corriger. Un utilisateur veut pouvoir installer facilement plusieurs versions d'une application en parallèle, ou installer un logiciel qui n'est pas dans les dépôts ou dans une version différente (souvent plus récente mais pas que). Or, mettre en place cela pour l'utilisateur actuellement c'est une vraie plaie, même si tu es expérimenté.
Flatpak est une solution à ce problème.
Oui et non. Un flatpak n'est pas forcément généré par le projet lui même. Il y a aussi la notion de dépôts avec Flatpak comme Flathub. Donc ce travail peut être effectué par des gens compétents en la matière d'empaqueter un logiciel.
Également, le monde merveilleux des dépôts de ta distribution c'est bien jusqu'à que tu veilles un logiciel hors dépôt. Or tu n'as pas toujours le temps, l'envie ou les compétences de faire le paquet qui va bien. Flatpak en étant générique permet de répondre ce besoin également.
Actuellement, le paquet que tu installes sur ta machine via les dépôts a des droits très importants, sauf si tu le cloisonnes au maximum avec des solutions comme SELinux.
Avec Flatpak et les conteneurs, tu améliores l'isolation de l'application au sein du système, cela limite grandement son pouvoir de nuisance.
[^] # Re: Avenir de Linux
Posté par gnumdk (site web personnel) . Évalué à 9.
Effectivement, il n'y a pas ou peu de développeur qui package leur applications pour Flatpak.
J'ai fait, puis j'ai quitté GitHub et du coup, j'ai laissé un utilisateur de Lollypop faire le job.
Par contre, il y'a quand même des problèmes avec flatpak:
Le projet flathub est toujours à la bourre et les utilisateurs qui veulent vraiment la dernière version auront plus de chance avec mes paquets (openSUSE, Fedora, Ubuntu) qu'avec ceux de flathub
Chaque créateur de paquet flathub se retrouve à packager le monde (toutes les dépendances d'une application) et chaque packageur refait la même chose à l'infini. Au moins, avec le système traditionnel, le travail est partagé entre les packageurs.
Et du coup, la gestion des nouvelles versions des dépendances est encore plus le bordel… Tu auras toujours un Lollypop plus à jour sous ArchLinux que sous n'importe quelle distro avec flatpak…
[^] # Re: Avenir de Linux
Posté par Renault (site web personnel) . Évalué à 5.
Attention, je ne dis pas que Flatpak c'est merveilleux et que cela résout tout en un claquement de doigts sans ses propres difficultés. Il y a ses inconvénients bien entendu ce que j'ai mentionné en partie dans un commentaire plus haut.
C'était juste pour expliquer les bienfaits de Flatpak aussi et que c'est assez triste finalement de constater que dès qu'on cherche à sortir des sentiers battus où les limites sont connues et posent des problèmes, car oui les utilisateurs veulent plus de flexibilité comme ils ont sous macOS ou Windows, il y a des critiques pour finalement tenter de garder un statu quo qui ne résout rien.
[^] # Re: Avenir de Linux
Posté par barmic . Évalué à 3.
La sécurité de la chaîne : ton navigateur → site quelconque → installation sur ton système est bien plus fragile que la chaîne : gestionnaire de paquets → installation. Savoir quel sites sont sérieux (je ne sais pas trop pour telecharger.com, mais sourceforge a fait pas mal de mal) et avoir un minimum de sécurité pour chacun d'eux et plus complexe.
Donc oui prendre le premier paquet venu d'un site web soulève certains problème (un peu comme avec :
curl -sSL https://awesome-uri/ | sh).C'est l'utilisation des dépôt flatpak qui corrige ce problème.
[^] # Re: Avenir de Linux
Posté par Renault (site web personnel) . Évalué à 7.
C'est plus subtile que cela.
Tu négliges une étape : la réalisation du paquet lui même. Par exemple chez Debian cette étape est décentralisée, l'empaqueteur génère le paquet lui même et pousse le résultat sur les dépôts. Mais est-ce que tous les empaqueteurs ont une sécurité de leur machine suffisante ? C'est difficile à garantir.
Ce n'est pas un hasard si Debian est la distribution qui a le plus investi dans la compilation reproductible, car cela permet à l'utilisateur de s'assurer que le paquet généré correspond bien aux instructions que l'empaqueteur a suivi. D'autres distributions comme Fedora reposent sur un système plus centralisé ce qui permet plus de garanties à ce niveau.
Après bien évidemment la sécurité se pose, mais il me semble un peu ridicule de toujours mettre la sécurité en avant au détriment de l'utilisabilité. Un équilibre est bienvenue et Flatpak est une piste possible. Flatpak permet de gérer plus finement les permissions des applications et les isole du système ce qui est un bon point pour une application dont la provenance n'est pas garantie par la distribution. Et en plus les Flatpak peuvent être utilisées dans le cadre de dépôts pour garantir un minimum de vérification quant à l'origine et à la qualité de l'application.
Car sans les Flatpak par exemple, si tu veux une application hors dépôt (et il y en a beaucoup), c'est vraiment chiant pour l'utilisateur. Il doit le compiler à la main, il doit récupérer le code depuis un site pas plus sûr non plus, voire apprendre à générer un paquet lui même, etc. Il n'est pas normal que d'installer la dernière version de LibreOffice soit bien plus complexe sous Linux que sous Windows. Et non passer à ArchLinux pour ça n'est pas une réponse satisfaisante. Et attendre 6 mois que sa distribution propose la mise à niveau nécessaire peut être très gênant pour l'utilisateur qui a besoin des nouveautés maintenant.
Vraiment, les Flatpak ont des défauts, le modèle traditionnel a ses arguments et je pense que les deux sont complémentaires. Mais refuser tout changement car ça a du mauvais tout en fermant les yeux sur les soucis du modèle actuel n'est pas un comportement très productif à mon avis, ce n'est pas comme ça qu'on pourra satisfaire les utilisateurs au mieux.
[^] # Re: Avenir de Linux
Posté par barmic . Évalué à 3.
Tu as plus de garanti avec le premier site venu ? Il faut s'attaquer à un développeur Debian et que ça passe les ftp master, c'est possible, mais entre l'ordinateur le moins sécurisé parmi les développeurs Debian et le moins sécurisé parmi n'importe qui, mathématiquement le premier est mieux sécurisé. Monter un site de fishing n'est pas forcément très compliqué non plus.
Mon commentaire cite précisément le déni dont tu fais preuve dans ton précédent commentaire et uniquement ça et il fini en particulier le fait que c'est déjà adressable par flatpak en particulier ça l'est avec la même utilisabilité que ce que proposent les 4 OS de grands publiques : des dépôts.
L'usage : je prends un logiciel de n'importe où et je le lance est un problème de sécurité grave quelque soit les technos et OS en jeu. C'est fait avec du js sur tout les sites et ça pose des problèmes de fuites de données par exemple.
[^] # Re: Avenir de Linux
Posté par David Demelier (site web personnel) . Évalué à 1.
J'en ai donné :
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Avenir de Linux
Posté par Renault (site web personnel) . Évalué à 4.
Non, c'est orthogonal.
Tu peux avoir du rolling, suivant le dépôt où tu récupères le Flatpak, tu peux aussi installer le paquet de manière indépendante (comme un .deb ou .exe trouvé sur le Web à l'ancienne), tu peux imaginer un dépôt qui fonctionne par vague aussi pour permettre d'avoir que la dernière ESR de Firefox par exemple ou ce genre de choses…
Bref, justement avec Flatpak tu deviens indépendant du cycle de sortie de ta distribution. Car pas mal de gens par exemples aiment bien avoir des composants stable que Debian propose mais pour quelques logiciels comme Firefox ou LibreOffice ils voudraient plus récents. Concilier les deux avec juste l'approche traditionnelle n'est pas aisée et assez casse gueule en fait.
D'ailleurs je vais parler d'un cas d'usage réel que j'ai rencontré. Dans ma boîte on a déjà fait des LAN avec des jeux libres (comme 0ad, OpenRA, etc.). Or chacun a sa propre distribution, Debian, Fedora et même Windows. Résultat, si on parvenait à récupérer les logiciels via les paquets, on avait tous des versions différentes qui étaient donc incompatibles pour jouer tous ensemble.
Et grâce à Flatpak disponible sur toutes ces distributions, on a récupéré le jeu dans Flathub et en 5 minutes le problème était résolu. Il aurait fallu des heures autrement pour trouver une solution convenable avec l'approche habituelle, et potentiellement en recompilant le jeu nous même. Tu parles d'un confort…
Oui bien sûr, le mainteneur du paquet est un surhomme qui fait un audit de tout en permanence. Ou pas, car c'est un humain avec du temps limité. Cela peut apporter un peu de confiance dans la procédure mais attention à ne pas avoir une foi aveugle non plus. Et personnellement je préfère avoir confiance en upstream que via un mainteneur, car upstream a largement le moyen de pousser des crasses sans que le mainteneur du paquet ne s'en rende compte.
Et sinon justement être indépendant d'un empaqueteur est aussi une plu valu. Si tu veux un logiciel qui n'est pas dans les dépôts, cela est vite difficile pour l'utilisateur d'obtenir le logiciel dont il a besoin. Flatpak se voulant indépendant de la distribution, il y a plus de chances que upstream propose quelque chose d'adapté à l'utilisateur qui fonctionne directement. Il y a peu de logiciels qui fournissent le format de chaque distribution, car c'est chiant et loin d'être facile.
Je bosse sur du Linux embarqué et je ne vois pas le rapport.
Il est très rare qu'un projet embarqué utilise une Debian ou une Fedora, au mieux c'est lors de l'étape du prototypage que cela sert. En général tu t'orientes vers du buildroot ou Yocto (ce qui revient à générer ta distribution et ton image).
Et même si Yocto génère des paquets par exemple, ils sont rarement utiles en production car c'est le merdier à gérer. Une coupure de courant lors de la mise à jour du périphérique et ton système plante, tu fais quoi ? T'es dans la merde, on va utiliser une approche plus proche de Fedora Silverblue justement, où tu télécharges un système entier et tu changes au démarrage le système à lancer. La notion de paquets disparaît dans ce contexte.
Flatpak est destiné à un environnement bureautique, pour des applications graphiques. Les serveurs et autres outils en ligne de commandes utiliseront plutôt les conteneurs. Et l'embarqué n'est pas vraiment concerné par le sujet ici.
Bah je m'en sers depuis quelques temps et non, ce n'est pas le bordel.
[^] # Re: Avenir de Linux
Posté par nokomprendo (site web personnel) . Évalué à 3.
Salut,
Et sinon, pourquoi ne pas plutôt s'inspirer des projets Nixos et Gnu Guix, qui font de la recherche et développent des gestionnaires de paquets depuis plus de 10 ans, pour résoudre ces problèmes ?
[^] # Re: Avenir de Linux
Posté par Renault (site web personnel) . Évalué à 2.
Car dans ce que je mets en évidence même le meilleur gestionnaire de paquets ne résout pas tous les problèmes mentionnés ? Car en fait certaines problématiques sont indépendante du concept même de paquet au sens où on l'entend. Je le répète, le but est aussi que l'utilisateur puisse plus facilement installer un paquet hors dépôt et que l'application soit un minimum isolée au sein du système.
[^] # Re: Avenir de Linux
Posté par nokomprendo (site web personnel) . Évalué à 3.
Nix fait ça très bien. Par exemple, un utilisateur peut installer, de façon isolée et "immutable", un paquet de la logithèque avec :
Et il peut aussi installer n'importe quel logiciel contenant un fichier
default.nixavec (par exemple depuis un dépôt github) :[^] # Re: Avenir de Linux
Posté par Renault (site web personnel) . Évalué à 4.
Oui, mais cela se fait au détriment de l'intégration et de la mutualisation. Car comme je le dis, Nix est un gestionnaire de paquets dopé aux stéroïdes, Flatpak n'en est pas un, il faut plus le voir comme une surcouche à des conteneurs si tu veux mon avis. Donc partir sur Guix / Nix pour répondre à ce besoin n'a pas vraiment de sens.
Le but avec les Flatpak c'est aussi, du moins à terme, proposer un système de permissions comme sur téléphone pour autoriser l'accès à la capture d'écran, aux fichiers de certains répertoires, à la webcam / micro, etc. C'est aussi proposer des couches intermédiaires standardisées pour garantir la compatibilité entre els distributions tout en mutualisant un maximum de ressources car de nombreuses bibliothèques communes sont incluses dans cette couche. Le but est d'aussi proposer l'accès à certains éléments de la configuration du système, comme par exemple le thème graphique ou la langue employée.
Pipewire s'inscrit d'ailleurs dans la démarche de fournir un point d'échange avec une application Flatpak pour l'audio et la vidéo, en étant flexible, performant et sécurisé (gestion fine des permissions).
Pour moi Nix ne s'inscrit pas dans ce genre de démarches. Nix est conçu pour concurrencer frontalement les gestionnaires de paquets traditionnels. Mais n'hésite pas à approfondir si je me trompe.
[^] # Re: Avenir de Linux
Posté par nokomprendo (site web personnel) . Évalué à 4.
Je ne connais pas trop flatpak et je suis conscient que Nix/Guix auraient du travail à faire pour être plus accessibles mais je ne suis pas complètement d'accord avec toutes ces remarques.
Nix fonctionne via des derivations (paquets) immuables et composables, stockées dans le /nix/store. Il n'y a pas de duplication d'un même paquet, tout est mutualisé. Comme une dérivation connait ses dépendances, on peut calculer complètement son périmètre, et même en générer un conteneur Nix ou Docker. Intégrer une nouvelle dérivation se fait donc sans problème particulier.
Et de façon similaire, Nix home manager permet de gérer des configurations utilisateurs et Nixos de gérer des services.
Pour la gestion des permissions par application, ça peut effectivement être une fonctionnalité intéressante. Je ne crois pas que Nix ait quelque chose dans le genre mais ça ne doit pas être très compliqué à ajouter. D'ailleurs il y a déjà une option "unfree" qui permet d'indiquer que le paquet contient du code non libre et d'empêcher son installation si la configuration de l'utilisateur ne l'autorise pas.
[^] # Re: Avenir de Linux
Posté par GnunuX (site web personnel) . Évalué à 3.
Parce que c'était un projet neuf et donc comme tout projet neuf il y a un bashing inutile sur le projet. 3 gus qui râle sur un twitter ne définit pas un sentiment "populaire". Mais c'est systématique et inévitable malheureusement.
Pour ceux qui connaissait les problèmes audios AVANT PA, je n'ai pas de souvenir négatif de l'arrivé de PA bien au contraire (franchement vu les joies de esd, artsd, alsa, oss, jack, …).
Pour moi PA est une vrai réussite qui a considérablement simplifié et amélioré l'audio sur les distributions.
[^] # Re: Avenir de Linux
Posté par gnumdk (site web personnel) . Évalué à 6.
La force de PA, c'est bien d'être devenu transparent… Certes au début, c'était pas la joie mais franchement, aujourd'hui, je n'ai rien à lui reprocher…
Quand je me souviens de ESD et Arts et de leur latence plus que visible.
[^] # Re: Avenir de Linux
Posté par Tarnyko (site web personnel) . Évalué à 4. Dernière modification le 20 mai 2019 à 16:39.
C'est marrant, je n'avais jamais vu ça comme ça.
Ma vision du truc c'était plutôt "Le dév upstream sera forcément infichu de s'adapter à nos versions, chemins -différents des 183 autres distros du marché- donc pas le choix faut faire nous-mêmes".
Qu'après, le fait de construire des paquets ait provoqué une addiction érotique et parfois généré du lien social, je le voyais surtout en à-côté.
[^] # Re: Avenir de Linux
Posté par Zenitram (site web personnel) . Évalué à 4.
Fait le taf, et l'upstream n'aura pas à se le farcir.
Tiens, plus personne…
Donc merci Flatpack pour gérer le manque.
Oui, un des avantages de Windows et qu'on n'est pas limité au repo officiel (qui lui-même limite avec rejet de licences pas libres), on a plus de choix.
Oui, le non libre ici laisse plus de liberté que les défenseurs du libre (à part quelques "emmerdeurs" comme les dév Flatpack qui essayent de libérer l'upstream et les utilisateur en créant des ponts entre les deux).
Faudra peut-être un jour comprendre que ça existe parce qu'il y a un problème avec l'autre système, plutôt que de dénigrer ce qui plaît aux gens pour corriger des problèmes qu'on refuse de voir en face.
# HIDPI, un vrai plus sur les grands écrans
Posté par xidoc . Évalué à 0.
Un nuc branché sur un écran plat, HIDPI est juste amazing pour les grands écrans.
J'utilise Gnome rien que pour cela.
Ce serait tellement bien que les sites web adaptent leur CSS pour les bigs écrans.
Ainsi que certaines applications(comme VLC).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.