Dans mon billet humoristique – seuls les pisse-froid auront pris au pied de la lettre l’article sur les prédictions de 2018 – je parlais des paquets universels.
Je disais ceci en substance :
Sur le plan des paquets universels, je ne pense pas que leur adoption progresse énormément en 2018, surtout avec un duo/duel comme avec Flatpak (projet développé pour être multiplateforme) et Snap (projet centré sur Ubuntu au départ).
À moins qu’un troisième larron arrive et dise aux deux larrons de fermer leurs grandes gueules ?
Je dois dire que les formats universels, c’est un serpent de mer du monde linuxien. Et depuis 1996, année où j’ai commencé à m’intéresser au libre, il y a eu quelques tentatives plus célèbres que d’autres. Je pourrais citer 0install ou encore les autopackages.
Pour 0install, on a un projet qui date de 2005 et qui est toujours développé en 2017. Mais qui en parle mis à part quelques blogs obscurs et quelques magazines purement technique ? Pas grand monde.
Pour les autopackages, le projet a fusionné en 2010 avec Linstaller. Qui en entend parler ? Pas grand monde.
Bien entendu, il y a le trio Appimage, Flatpak et Snap qui tient le haut de la scène actuellement. Si je devais parier sur un survivant à terme, je penche pour Flatpak. Pourquoi ? Car c’est un format proposé par le site FreeDesktop.org.
On y trouve aussi des technologies dont les sites officiels y sont hébergés : le pilote nouveau, gstreamer ou encore le diabolique conflictuel systemd.
Donc, dans un de ses derniers articles, Sebastien de Passions GNU/Linux n’a pas tort quand il dit :
IL FAUT que ça soit le standard Freedesktop qui s’impose et rien d’autre, il faut que ça soit une distribution communautaire à la Debian, si ce n’est Debian, qui s’en sorte le mieux avec.
Je pense que la Debian et son impératif historique de stabilité ne soit pas le meilleur choix ici, surtout avec un cycle de sortie relativement long pour le libre, deux ans entre chaque version majeure en moyenne.
Pour moi, et contrairement à l’article reprit par Seb, ce ne sont pas toutes les distributions qui risquent de disparaître à terme, mais seulement celles qui sont redondantes avec l’existant. Ou qui ne survivent que par leur format de paquets spécifique et les outils qui vont avec pour toute justification.
Car pour faire vivre une distribution, il faut des mainteneurs. Qui dit mainteneurs dit souvent empaquetage de logiciels. Si un dépot plus ou moins centralisé proposant des applications universelles finit par s’imposer comme standard, il ne devra plus rester que la base.
Les applications de plus haut niveau, spécialement celle à destinations des utilisateurs finaux s’installant en reproduisant le principe développé peu ou prou depuis le début par Apple et son MacOS.
Même si cela donne des paquets qui sont souvent proche de l’obésité morbide, cela permet d’avoir des logiciels qui ont autour d’eux tout ce qu’il faut pour les faire fonctionner.
On pourrait arriver ainsi à récupérer un paquet universel pour LibreOffice qui pèserait facilement un bon demi-Go, voire plus si on doit rajouter les bibliothèques qui vont bien pour faire fonctionner le logiciel.
Évidemment, cela serait une plaie pour les personnes ayant des connexions limitées, mais qu’est-ce qu’on en a à foutre ? Tout le monde à l’ADSL, non ? Et bientôt tout le monde aura une connexion style fibre, non ?
Euh, comment dire… Quid des pays en voie de développement ? Des zones rurales où tirer la fibre ne serait pas le moins du monde rentable ?
Pour moi, de part le nombre de standards qui s’entretuent pour obtenir cette solution miracle du paquet universel, et surtout de part la dispersion des distributions, les paquets universels auront du mal à s’imposer.
On peut être alarmiste et hurler au loup en disant que l’on va tous crever. C’est vrai, mais cela est un autre problème. Ce qui ressort, c’est souvent que les mainteneurs de paquets pourraient perdre une partie de leurs pouvoirs. Oui, le pouvoir de dire à l’utilisateur de base : tu vois, chose insignifiante, je sais empaqueter ton logiciel. Tu es sous ma coupe !
Désolé, je me suis laissé emporté dans le paragraphe qui précède, mais c’est l’impression que j’en ai.
Empaqueter un logiciel, surtout sur les distributions nées à partir de l’époque de la Gentoo 1.0 (soit à partir de 2002), c’est prendre une recette, la modifier, vérifier si ça compile et vogue la galère.
On est loin des horreurs de complexité que sont les paquets pour debian ou encore le rpm. Du moins, c’est ce que j’en ai retiré en lisant la documentation de génération des paquets.
Je sais que je vais précher pour ma propre paroisse ici, mais quand je vois la simplicité syntaxique d’un PKGBUILD, je me dis que le système de paquets a été pensé pour être facilement applicable.
Ce qui explique le nombre astronomique de recettes disponibles sur le dépôt utilisateur AUR, un peu plus de 43000 au moment où je rédige ce long billet en décembre 2017. Bien sûr, on y trouve tout et n’importe quoi, ce qui est explicable par la simplicité syntaxique des PKGBUILD.
Donc pour conclure cet article, ce qui disparaîtrait au final, en dehors de distributions n’ayant pas réussi à s’imposer sur le marché qu’elles visent, ce serait le pouvoir de certaines personnes qui empaquetent les logiciels. Car il n’y aurait plus besoin que de profils largement plus techniques pour s’occuper des bases comme le noyau, le serveur graphique X ou son successeur Wayland, ou encore l’intégration de l’outil de gestion des paquets universels. Vous imaginez un paquet universel pour le serveur graphique ? Moi, pas 🙂
Vu la dispersion et les guerres intestines constantes entre les communautés qui constituent le monde du libre, je ne pense pas que les paquets universels finissent par s’imposer.
Les utilisateurs classiques ne viendront pas dans le monde du libre tant qu’il y aura plusieurs dizaines de distributions bureautiques dont la seule différence au final n’est que le format de paquets employés pour les logiciels.
Tant qu’il n’y aura pas de ports d’applications non-libres comme des ogres à la Photoshop (pour prendre cet exemple), toutes les guerres intestines du libre ne compteront pas plus qu’une tempête dans un verre d’eau.
L’utilisateur lamda soit mme Michu veut son Pc sans entretien. Au USA ChromeOs progresse.
Ce que google a fait avec Android ou Linux a gagné la partie sur Microsoft sur le portable mais au prix de ne plus etre libre. Google veut faire la meme chose maintenant sur Pc fixe, il y a deja peut-etre plus de Pc vendu sous ChromeOs que sous Ubuntu. Et a terme c’est comme ça que je vois que si Linux veut arriver en tete des ventes ils seront obligés de passer par une entreprise privée comme Google qui aura profité du bénévolat des acteurs du libre pour faire un programme certe fonctionnel mais complètement fermé. J’utilise ChromiumOs sur mon laptop et je dois dire qu’une mise a jour tout les 3 mois c’est pas désagréable, on ne pense plus a la maintenance. Sur mes 2 autres Pc fixes j’utilise Debian et Archlinux donc en gros j’ai que la Arch a surveiller mais pour le plaisir.
Pour le moment, ChromeOS progresse, mais il est inutilisable sans connexion réseau, car tout est stocké en ligne. Il suffira d’un scandale de grande ampleur sur le « cloud » et je pense que les ChromeBook auront du soucis à se faire.
Il y a régulièrement des scandales et rien ne change pour autant. Les gens préféreront toujours un produit simple qui viole leur vie privée qu’un produit compliqué qui la respecte.
Un PC sans connexion internet, ça sert à quelque chose? Pour moi non.
A+
@Daniel, en effet, du même avis.
J ai dit la meme chose , dans un article précédent de l ami Fred. Linux a deja gagné sur smartphone grace a Android. Possible qu il gagne aussi sur Desktop grace a ChromeOS.
Quid du projet Fuchsia développé par Google ? Je pense qu’à terme la firme se séparera du noyau linux. Une question de temps. Surtout avec Linus Torvalds qui approche de la cinquantaine et qui risque après son départ – voulu ou accidentel – de laisser une sacrée merde pour gérer le noyau 🙁
Bonjour,
Curieusement, je ne me fait pas trop de soucis pour l’avenir du noyau linux.
En cas de départ de M. Thorvald il y aura probablement une alternative.
Soit à la manière de xorg qui a remplacé xfree86. Cela me paraît très possible avec des structures capables de prendre ce genre de projet en charge qu’elle soient communautaire (Debian) ou non (redhat ou autre).
Sinon il y a toujours Hurd 😀
Sinon au pire les noyaux bsd seront là même si du coup nos distributions ne seraient plus des gnu/linux mais des gnu/kfreebsd.
@+ gempaouindo
Salut,
Pas tout à fait, d’une part parce que c’est Kroah-Hartman l’actuel mainteneur de la branche stable, et que ce serait lui le plus disposé à prendre la suite. D’autre part parce que Google est le plus gros sponsor de la Linux Foundation, que Torvalds est sur Google+ (avec 2, 3 autres 😊 ) et qu’il n’y a aucune raison qu’ils se séparent d’un noyau qui marche parfaitement bien.
Ah ok mais on a déjà vu des guerres d’ego suite au départ de grande figures que tout le monde écoute (je ne pense pas forcément à l’informatique d’ailleurs). J’espère évidemment que la suite se passera bien mais même dans le cas contraire je ne me fais pas trop de soucis. C’était cela le sens de post.
Je n’aime pas trop les paquets dit universels, puisque généralement, on se retrouve avec des paquets qui incluent toutes les dépendances, aux bonnes versions. C’est un truc à avoir 10 fois la même lib, dans 3 versions différentes. Je trouve ça absurde. D’ailleurs, c’est une cause de BSoD sous Windows (deux DLL de version différentes en mémoire, une mise en veille, c’est la mauvaise DLL qui charge au lancement, et paf).
Les gestionnaires de paquets ont deux avantage : simplicité d’utilisation et gestion des dépendances. Je trouve le second très important. Les paquets universels, c’est un coup à retrouver sous Linux la même merde que sous Windows.
Après, je suis d’accord, un DEB ou un RPM, c’est immonde et complexe. Mais si on gérait ça à la Arch Linux, qui n’utilise qu’un fichier de définition (le PKGBUILD), puis gère automatiquement tout le reste…
De plus, l’arborescence des systèmes GNU/Linux étant similaire sur toutes les distribs, il est aisé d’installer manuellement des logiciels, dans `/usr/local` et `/opt`. La plupart des `make install` installent par défaut en utilisant ces répertoires.
Donc si les paquets universels arrivent, il *faut* qu’ils respectent cette arborescence, en restant dans ces deux dossiers. Et laisser `[/usr]/[s]bin` aux mains du gestionnaire de paquets.
La situation n’est pas comparable avec Windows. Les Flatpak sont isolés (donc bien plus sécurisés). Par principe, un Flatpak A ne pourra jamais utiliser les bibliothèques du Flatpak B. Par contre, pour gagner de l’espace disque et faciliter les mises à jour, les bibliothèques les plus communes peuvent être fournies sous forme de runtime. Il existe déjà des runtimes GNOME, KDE, Freedesktop… Ce qui évite par exemple aux Flatpak des applications GNOME de dupliquer bêtement toutes les bibliothèques du projet GNOME.
Ensuite, par rapport aux paquets DEB ou RPM traditionnels, les Flatpak ont plusieurs avantages. Comme dit précédemment, on peut déjà citer le fait qu’ils soient isolés, ce qui renforce la sécurité et les droits que l’utilisateur souhaite bien leur accorder : accès aux périphériques (webcam, micro…), à la géolocalisation, au gestionnaire de contacts… Accès qu’on pourra accorder par application et non de façon globale par utilisateur comme c’est trop souvent le cas actuellement. Autorisations que l’on pourra bien évidemment révoquer à tout moment. Et ce, à l’aide de simples « interrupteurs » dans les paramètres de l’environnement de bureau, plutôt que de devoir jouer avec chown et chmod en ligne de commande. Ce qui rendra donc la fonctionnalité bien plus accessible pour les utilisateurs.
Autre avantage, le fait de pouvoir facilement installer plusieurs versions d’une même application en parallèle. Ce qui peut tout aussi bien être une version stable et une version de développement pour tester et faire des rapports de bugs, sans nuir à notre productivité quand on a besoin de quelque chose de stable. Mais aussi plusieurs versions stables différentes. Par exemple, une vieille version qui aurait vu l’une de ses fonctionnalités supprimées entre temps et dont on pourrait avoir besoin de temps à autre.
Ça permettra également à des distributions qui visent la stabilité plutôt que les dernières nouveautés (telles que Debian ou les versions LTS d’Ubuntu) de pouvoir tout de même bénéficier des dernières versions des différentes applications utilisateur.
Ça peut également profiter aux distributions qui n’ont qu’une petite équipe (comme Solus), qui pourront désormais se concentrer sur le système de base et leur environnement de bureau, plutôt que de perdre du temps à packager d’innombrables applications, sans y apporter la moindre plus-value.
Simple question : tu parles de runtime… Mais cela me fait penser un peu aux bibliothèques partagées aussi vieille que les systèmes d’exploitation… Donc en gros, on réinvente ce principe en rajoutant des paquets avec des bacs à sable ?
Super !
La question, c’est surtout de savoir, dans un monde toujours plus connecté, avec des menaces durables et continues, si l’on souhaite privilégier l’espace disque ou la sécurité.
Pendant longtemps, X.org a joué son rôle et c’était très bien. Sauf qu’il n’a jamais été pensé pour être sûr et n’importe quelle application l’utilisant pouvait enregistrer secrètement les frappes clavier effectuées dans les autres applications ou prendre des captures d’écran de ces dernières. Wayland n’est peut-être pas encore totalement au point, mais il répond parfaitement à ces problématiques.
Il en va de même pour les Flatpaks. Tout n’est pas encore parfait (prise en charge par les logithèques, implémentation des portails dans les différents environnements de bureau pour demander à l’utilisateur s’il souhaite ou non accorder tel ou tel droit…), mais à l’arrivée, la sécurité sera bien plus renforcée qu’elle ne l’est aujourd’hui.
Et chose importante, cette sécurité sera facile d’accès pour l’utilisateur. Parce que souvent, renforcer la sécurité équivaut à compliquer la tâche des gens, qui ont tendance à la contourner pour se simplifier la vie et qui lui fait perdre, au passage, tout son intérêt.
Oh, c’est beau, on dirait un communiqué de presse d’une boite spécialisée dans la sécurité qui ferait tout pour vendre sa popote 🙂
Tu parles de Xorg, mais il faut se souvenir que X11 est né au début des années 1980… Internet était plus que balbutiant à l’époque. Et même s’il a des faiblesses, tant que Wayland – un peu ralenti par le projet Mir – n’a pas atteint sa maturité complète, X11 et ses implémentations font le travail qu’on lui demande.
Je peux te dire que je ne crois pas une seule seconde en l’imposition d’un format à la Flatpak… Pas avant plusieurs années au minimum… Car tu auras beau dire que ce que tu voudras, les paquets universels seront toujours plus lourds que des paquets en natif.
Quant à la sécurisation par bac à sable, combien de fois cette sécurité est contournée chaque année ? Ce n’est pas le genre d’attaque préférée des concours à la pwn2own ?
En 2012 contre le Google Chrome de l’époque par VUPEN -> http://www.zdnet.com/article/pwn2own-2012-google-chrome-browser-sandbox-first-to-fall/
En 2013, contre IE10 sur la Surface Pro de l’époque -> https://www.theregister.co.uk/2013/03/08/pwn2own_contest_cansecwest/
Même si depuis la sandbox semble tenir, elle n’est pas parfaite. Pour paraphraser Manon Roland, je dirai simplement : « Sécurité, que de crimes l’on commet en ton nom ! » 😀
Euuh le format de paquet importe peu aux Mr et Mme. Michu qui installent leur applications depuis la logithèque graphique et pour l’installation, rien ne change, il faut juste cliquer sur le bouton « installer ».
Le plus gros problème de ces paquets actuellement c’est qu’ils ne s’intègrent pas toujours très bien à l’environnement (par exemple au niveau du thème utilisé, etc.)
Je ne crois pas que le poids de ces paquets soit un réel frein. Déjà le poids ne sera pas forcément plus élevé, ensuite ces paquets seront surtout utilisés pour les applications de haut-niveau que l’utilisateur choisira d’installer (et ensuite les mises à jour se font avec des deltas). Les applications de bases resteront dans le format natif de la distribution.
Un avantage qui n’a pas été abordé avec ces systèmes de paquets et qu’ils permettent aux éditeurs de publier DIRECTEMENT leur applications tout en couvrant un panel plus large de distributions qu’en se contentant des formats .deb/.rpm (qui pourrissent la vie des distro qui ne supportent pas ces formats)
Sinon pour arch, si on y trouve autant de paquets, ce n’est peut-être pas qu’une question de simplicité mais le fait que dans les paquets communautaires, on y accepte tout et n’importe quoi, on prend des sources, on prend du binaire, on se fiche de savoir si les termes des licences sont respectés, la gestion des conflits est me semble-t-il laissé à la discrétion du packager etc. Bref, on y trouve le meilleur mais aussi le pire. C’est à la fois une force, mais aussi une faiblesse.
Simple remarque : AUR n’est pas supporté officiellement par Archlinux. Seul les dépots core, extra, community, multilib (et les contreparties testing, community-testing ou encore multilib-testing) sont supportés.
AUR est un dépôt fourre tout, et il y a toujours une forme de surveillance gérée par les Trusted Users et les utilisateurs pour nettoyer le site.
Je fais un mini hors-sujet par rapport à ta remarque:
Cuda par exemple se trouve dans le dépôts community de ArchLinux alors que la redistribution est explicitement interdite dans la licence !!??
C’est une licence de type EULA donc il serait étonnant que personne n’y ait jeté un oeil où ne s’en soit pas aperçu au fil des années…
Une tolérance pour des raisons purement pratiques ? Ce n’est pas en relation avec certains pilotes non libre pour nVidia ?
À moins que je confonde avec un logiciel au nom proche ?
Contrairement à cuda, les pilotes nividia sont re-distribuables, donc de ce côté là no problemo. 🙂
Heureusement car sans les pilotes propriétaires utiliser un GPU nvidia c’est pas top pour l’utilisateur final !
Cuda n’est qu’un exemple parmi d’autres. C’est pour ca que j’avais ouvert cette parenthèse.
Tout le monde est là à se demander ce qui serait mieux pour l’utilisateur, si c’est bien pour sa sécurité, si c’est pas trop lourd etc …
Alors que d’un côté on a Billou qui a fricoté avec les fabricants pour avoir son OS de base sur tous les PC du monde, et de l’autre Steve qui disait que les gens utiliseront ce qu’on leur dira d’utiliser. Bref, à aucun moment ces 2 géants n’ont placé l’utilisateur au centre du débat. Est-ce que le libre doit le faire ? Je ne sais pas …
Bonjour;
J’ai quelques soucis pour poster un commentaire, je te fais un mail si celui-ci passe pas (j’en ai fais 3 autres avant)…
A bientôt