Cher journal,
Aujourd’hui je m’interroge : Canonical, l’éditeur de la distribution GNU/Linux Ubuntu, retomberait‐il dans ses vieux démons ?
Au cours de ces dernières années, l’éditeur a lancé plusieurs projets en solo au détriment d’une participation à des projets plus largement soutenus dans le monde du logiciel libre, soulevant au passage de nombreuses critiques. Citons à titre d’exemple : Upstart face à systemd, Unity face à Gnome Shell, Mir face à Wayland, Ubuntu Software face à GNOME Logiciels, Snap face à Flatpak.
Le bilan pour Canonical n’est pas très glorieux : le temps ne lui a pas donné raison puisque ces projets ont été abandonnés (Upstart, Unity, Ubuntu Software) ou mis au placard (Mir). La « bataille » entre Snap et Flatpak pour s’imposer comme le nouveau standard de facto de format de paquet « nouvelle génération » (je ne trouve pas de terme approprié…) n’étant pas encore été gagnée par une des deux parties.
Pourtant Canonical récidive en annonçant retirer son soutien au développement de GNOME Logiciels (GNOME Software en V. O.) qui ne sera vraisemblablement pas intégré à Ubuntu 20.04 LTS en faveur d’une nouvelle boutique logicielle centrée sur Snap, faite maison. Richard Hugues, un des développeurs de GNOME Logiciels a aussitôt annoncé le retrait de la prise en charge des paquets Snap dans l’application en arguant une baisse prévisible de la qualité de la prise en charge des paquets Snap dans l’application, des difficultés techniques et s’éviter un effort de maintenance supplémentaire.
Bref, les efforts multilatéraux entrepris pour faire de GNOME Logiciels un portail de gestion des logiciels dans l’écosystème libre capable de rivaliser (en termes de qualité et de facilité d’utilisation) avec les App Store et autres Play Store viennent d’en prendre un coup.
Qu’en penses‐tu cher journal ?
Je trouve ça dommage. GNU/Linux semblait tellement prêt pour le desktop, 2019 aurait pu être son année ! Mais que les barbus se rassurent : cela ne change finalement rien pour eux. :)
Il me faut donc terminer ce journal par l’image de circonstance :
# upstart ?
Posté par mahikeulbody . Évalué à 10.
Je ne suis pas sûr que ce soit un bon exemple vu que upstart est antérieur à systemd.
[^] # Re: upstart ?
Posté par Fabien PRORIOL . Évalué à 0.
Alors upstart face a openrc, puisque dans ce cas, openrc est bien bien bien plus vieux, et fournis la même plus-value par rapport a systemV (le démarrage de service en parallèle)
[^] # Re: upstart ?
Posté par FluffyHamster . Évalué à 1.
Upstart et systemd sont vachement inspirés du système d'init de macOS, et la plus-value en plus de la vitesse, c'est surtout le système d’événements. Je ne suis pas sur qu'openrc joue dans la même court.
[^] # Re: upstart ?
Posté par flan (site web personnel) . Évalué à 4.
launchd a même été envisagé par certaines distribs, de mémoire.
[^] # Re: upstart ?
Posté par Nicolas Casanova . Évalué à 2.
Ubuntu, justement. La licence ne leur convenait pas et ils ont préféré miser sur Upstart. FreeBSD y avait réfléchi également.
[^] # Re: upstart ?
Posté par Melodie (site web personnel) . Évalué à -1.
"dans la même cour". (je cours tu cours il court dans la cour ♪♩♪♫♬)
# flatpak
Posté par FluffyHamster . Évalué à 10.
J'aurai envie de dire, pourquoi flatpak est plus un standard que snap ? Par ce que RedHat c'est mieux que Canonical ? Les deux sont assez anciens, et Snap est déployé dans une distribution depuis plus de temps.
J'ai personnellement beaucoup, beaucoup de mal avec flatpak.
Je n'ai pas besoin d'un deuxième gestionnaire de paquet dans ma distribution. J'en ai déjà un, il marche mieux, et il est infiniment plus facile de faire des paquets pour lui que pour flatpak.
Flatpak, niveau efficacité, on repassera. Installé le moindre flatpak de quelques Mo demande entre 880Mo (j'ai pas trouvé moins, mais ça existe sans doute) et 1.4Go. Kewl. Pour peu qu'on ai des applis qui link pas avec les mêmes overlays (ou versions des overlays) on multiplie tout par X (ou plusieurs drivers nvidia, ou comment avoir 2 Go de drivers sur une seule machine…)
Le fait qu'il s'impose comme standard de facto, c'est bien, maintenant on va avoir la même efficacité qu'une installation neuve de Windows 10. Ça fera vendre des SSDs…
Enfin, pour que Gnome Software devienne "capable de rivaliser (…) avec les App Store et autres Play Store", c'est un objectif louable, mais mon dieu il y a encore du boulot.
[^] # Re: flatpak
Posté par rewind (Mastodon) . Évalué à 10.
Je crois que dans tous les exemples donnés, c'est bien de ça dont il s'agit. Dans tous les cas, c'est bien une solution RedHat qui s'est imposé face à une solution Canonical (y compris quand parfois, la solution Canonical a démarré avant la solution RedHat). Bref, quand je lis «au détriment d'une participation à des projets plus largement soutenus dans le monde du logiciel libre», je m'étrangle un peu. Parce que je ne suis pas sûr que des communautés tel que Debian ou ArchLinux ait été à l'origine ou disons fortement impliqué dans un seul des exemples donnés. Ils ont juste suivi RedHat plutôt que Canonical, parfois douloureusement (voir les très longs débats à propos de systemd dans Debian).
[^] # Re: flatpak
Posté par saltimbanque (site web personnel) . Évalué à 10.
Personne n'a force de distrib a adopter pulse audio ou systemd, GNOME ou Wayland. Les distrib adoptent ce qui leur paraissent le meilleur. Et bien souvent RH a contribué très fortement a ces technos.
[^] # Re: flatpak
Posté par flan (site web personnel) . Évalué à 7.
Quelque part, c’est assez logique que le second arrivé sur le marché ait appris des erreurs du premier :)
[^] # Re: flatpak
Posté par Gabin3 . Évalué à -3.
Quelque part ça montre la fragilité du modèle opensource communautaire. Les distros le feraient certes parce que cela leur paraîtrait le meilleur mais aussi, je pense, car il s'agit de tâche énorme que le modèle économique communautaire dans le cas de GNU/Linux, inexistant donc, ne permet pas. Bon, ça serait majoritairement vrai pour un Xorg/Wayland mais normalement pas pour un système d'init (ce que n'est pas systemd).
Bref, ce genre de projet d'ingénierie "dur", c'est autre chose que de faire un fork de Debian avec un wallpaper brandé et quelques paquets compilés avec -O4.
[^] # Re: flatpak
Posté par Okki (site web personnel, Mastodon) . Évalué à 10.
Snap, c'est Ubuntu. Flatpak, bien que développé par des développeurs payés par Red Hat, c'est un projet communautaire Freedesktop, déjà adopté par défaut par plusieurs distributions autres que celles liées à Red Hat. On peut citer Endless OS et Linux Mint, et j'ai cru comprendre que c'était également la méthode privilégiée par ChromeOS pour l'installation d'applications Linux. Même l'Agence nationale de la sécurité des systèmes d'information (ANSSI) a prévue d'utiliser Flatpak dans CLIP OS, son système sécurisé.
Quant au poids des paquets Flatpak, ils ne sont guère plus gros que des paquets traditionnels. Ce qui t'induit en erreur, c'est qu'ils dépendent d'un runtime (GNOME, KDE, Freedesktop…) qui peut effectivement occuper une certaine place. Mais si t'installes quinze applications dépendantes d'une même version d'un runtime, ce dernier n'aura besoin d'être installé qu'une seule fois.
Que ce soit des paquets traditionnels ou des Snap / Flatpak, chacun ont leurs avantages et leurs inconvénients. Que les paquets de ta distribution te conviennent et te suffisent, c'est très bien, mais tu ne peux pas non plus passer sous silence les différents avantages apportés par les Flatpak.
Par exemple, si tu souhaites installer une application propriétaire, qui a de fortes chances d'être absente des dépôts de ta distribution, jusqu'à présent, la seule solution était d'aller récupérer le paquet proposé par l'éditeur et de lui faire entièrement confiance. Puisque une fois installée, l'application peut faire à peu près tout ce qu'elle veut (accéder à tous les périphériques auquel ton utilisateur a accès, à toutes tes données personnelles, espionner les autres applications…). Et ce, que ce soit ou non volontaire. On se souvient du client Steam qui supprimait toutes les données personnelles… Tandis qu'en Flatpak, l'application est isolée et tu peux choisir de lui accorder plus ou moins de droits. Cette partie est encore en chantier, mais à terme, comme pour les applications mobiles, tu pourras accorder ou non un accès à la localisation, à tel ou tel périphérique (caméra, micro…) et pourquoi pas à l'agenda, aux contacts et que sais-je encore.
Autre avantage, pouvoir privilégier un système particulièrement stable et éprouvé (CentOS, Debian stable…), tout en ayant tout de même la possibilité d'installer les dernières versions de certaines applications à l'aide de Flatpak.
Ou installer facilement plusieurs versions en parallèle, comme la version stable et la version de développement.
Et pour finir, quand tu dis qu'il est plus facile de créer des paquets pour ta distribution que des Flatpak, c'est surtout que les développeurs de logiciels libres se reposent sur les distributions pour qu'elles refassent le même travail chacune dans leur coin. Quant aux applications propriétaires, à elles de se démerder pour créer tout plein de paquets. Honnêtement, je ne saurai dire si la création d'un Flatpak est réellement plus compliqué, mais une chose est sûre, de faire un Flatpak qui tournera partout doit être bien plus rapide que de créer différents types de paquets pour tenter de satisfaire le plus de monde possible.
[^] # Re: flatpak
Posté par FluffyHamster . Évalué à -1.
Je vais même pas essayer de répondre point par point à ton commentaire.
La seule question qu'on devrai se poser, c'est qu'est ce qu'essaie de résoudre flatpak ?
Et vu que ça va me prendre une page, que ce n'est pas exactement l'objet de ce journal, et puis bien sur qu'on est vendredi… Je vais aller écrire un journal… Ça faisait longtemps…
[^] # Re: flatpak
Posté par Okki (site web personnel, Mastodon) . Évalué à 9.
Ce qui est déjà pas mal comme avancée ;-)
[^] # Re: flatpak
Posté par PS12r . Évalué à 1.
Non, non, je n'ai pas vraiment de parti pris pour l'un ou l'autre, simplement Flatpak est un projet Freedesktop (pour autant qu'on puisse lui reconnaitre une quelconque légitimité). Plusieurs distributions l'ont d'ors et déjà adopté, je ne crois pas qu'on puisse en dire autant de Snap, mais je veux bien que tu éclaires ma lanterne si c'est le cas.
Oui mais là, j'ai l'impression qu'avec des moyens en moins, l'objectif soit encore plus hors de portée.
[^] # Re: flatpak
Posté par FluffyHamster . Évalué à 2. Dernière modification le 12 juillet 2019 à 12:01.
Pas forcément un problème de moyen. Les stores ont des façades très simples justement, pas si difficiles à émuler. Sur Gnome Software je vois de grosses erreurs niveau UI/UX, comme une icone rouge pour indiquer le sandboxing (c'est une fonctionnalité de sécurité, pourquoi la marquer en rouge ?). Je vois des gros encarts rouges pour les logiciels propriétaires, sympa… La moitié des applis ont une description qui tient en deux lignes et pas ou peu de captures d'écrans, c'est dommage.
Ensuite les stores, ils permettent aussi (même surtout) de monétiser des applications. La, on en est ou ?
Devenir une vrai boutique d'application par contre c'est sur qu'il va falloir y mettre des moyens…
[^] # Re: flatpak
Posté par damaki . Évalué à 3.
C'est assez similaire à ce que j'ai pu voir avec les snaps. Il n'y a pas de miracle, si tu veux une compatibilité au top, tu es obligé de te traîner des tonnes de libs, comme par exemple pour Windows 10. Mais on est d'accord, un humain moyen ne veut pas télécharger des Gos de fichiers sans raison claire.
Jusque là on parlait pas mal du desktop, mais côté serveur, le problème est déjà résolu, on a Docker qui fait déjà tout. Alors je sais que Canonical essaie de pousser les snaps côté serveur mais qui va s'embêter à apprendre une nouvelle techno utilisée par 3 pèlerins alors que Docker s'impose déjà ?
[^] # Re: flatpak
Posté par Melodie (site web personnel) . Évalué à -2.
Conditionnel Présent : j’aurais
:>
# Plein de choses
Posté par Malizor . Évalué à 10.
Que tout cela est un peu/beaucoup trollesque, mais on va dire que c'est presque dredi et que c'est fait exprès.
Point principal :
Snap ≠ Flatpak
Flatpak n'est pas conçu pour être utilisé sur les serveurs, contrairement à Snap: https://flatpak.org/faq/#Can_Flatpak_be_used_on_servers_too_
On peut installer tmux, lxd, nextcloud, cmake ou que sais-je encore via Snap alors que Flatpak n'est juste pas fait pour ça.
On peut installer un OS entier uniquement avec des Snaps, c'est le principe d'Ubuntu Core: https://ubuntu.com/core
Bref, si les deux ce font sûrement concurrence sur le périmètre des applis desktop, Flatpak ne pourra jamais remplacer tout ce pourquoi Snap est utilisé aujourd'hui (donc le xkcd sur les standards concurrents n'a aucun sens ici).
Quand au titre même du journal, je précise que celui-ci est faux: Canonical n'a rien annoncé du tout.
Comme les liens du journal le montre, c'est Phoronix qui a trouvé un nouveau dépôt git et qui extrapole a son sujet. Il n'y a eu aucune annonce sur le fait que ce nouveau projet allait ou pas remplacer Gnome-Software dans Ubuntu (et encore moins de "quand").
Le fait que les développeurs de Gnome-Software veuillent dès maintenant supprimer le support de Snap n'a aucun sens logique, puisqu'il est établi que de toute manière Gnome-Software sera toujours utilisé par Ubuntu au minimum dans sa prochaine version. Il n'y a donc vraiment aucune urgence, d'autant plus que le support Snap en question est maintenu directement par Canonical.
Bref, de ma fenêtre ça ressemble plus à une résurgence de la guerre d'égos entre développeurs RedHat et Canonical.
Je trouve ça triste car la technique est laissé au second plan et qu'au final personne n'a rien a y gagner.
[^] # Re: Plein de choses
Posté par Sufflope (site web personnel) . Évalué à -10.
Pardon, mais, t'es qui ?
Parce que l'auteur du message lié à propos de gnome-software, Richard Hughes, je sais vaguement ce qu'il a fait pour l'écosystème. Donc quand il dit
Puis quand il explique que le support des snaps dans g-s n'est pas vraiment bien testé et qu'il est d'accord pour un support des snaps dans g-s, mais pas un plugin abandonné dont on lui refilerait le support parce que merde…
… bah pardon mais j'ai plus envie de le croire plutôt qu'un évangéliste ubuntu random.
[^] # Re: Plein de choses
Posté par Malizor . Évalué à 10. Dernière modification le 11 juillet 2019 à 23:56.
Les attaques personnelles ne servent pas tes propos.
Sur le fond, je t'invite à lire les réponses au message que tu cites, ainsi que les commentaires sur la merge-request côté GNOME: https://gitlab.gnome.org/GNOME/gnome-software/merge_requests/253
Tu noteras que Richard Hughes dit bien
(ce qui, la encore, est en contradiction avec ce que dit le journal)
Tu noteras également que des devs Snap ont rapidement rejoint la discussion pour proposer leur aide et voir ce qui pouvait être amélioré dans la maintenance de l'écosystème Snap, que ce soit dans GNOME ou dans Fedora.
Donc le côté "méchant Ubuntu/Canonical qui fait toujours tout dans son coin" n'a juste aucun sens dans ce cas précis.
Mon avis perso est que Richard Hughes a surréagi en postant son message initial. À moins que son but était justement de faire réagir Canonical, difficile à dire.
[^] # Re: Plein de choses
Posté par Sufflope (site web personnel) . Évalué à -5.
Ça n'est pas une attaque personnelle, tu affirmes des choses en contradiction avec ce que le mainteneur dit, donc soit tu es mieux informé (possible), soit…
Lorsque j'ai lu son message lié dans le journal il n'y avait qu'une réponse, donc pas "les réponses" dont tu parles, et j'avoue ne pas faire F5 sur le fil toute la journée. Si depuis la situation s'est tassée, tant mieux.
Peut-être qu'il a frappé fort pour faire réagir et éviter de se la faire faire à l'envers par Canonical, oui.
# Commentaire supprimé
Posté par Anonyme . Évalué à 9.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Toujours le même
Posté par David Demelier (site web personnel) . Évalué à 4.
Snap était là bien avant flatpak. Red Hat a fait flatpak par après et a décidé de propulser son support dans GNOME Software. Je pense que c'est tout à fait compréhensible de la part de Canonical de se sentir frustré de pas être logé à la même enseigne pour quelque chose qu'ils ont débuté avant. Je pense que c'est plutôt Red Hat qui a un syndrôme NIH. Systemd après Upstart, Flatpak après Snap. Il y a d'autres choses mais je n'ai plus toute la liste en tête.
Note : je ne défends en aucun cas Canonical, pour moi ça reste une entreprise qui « détruit » tout autant la simplicite et beauté de Linux que Red Hat.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Toujours le même
Posté par Renault (site web personnel) . Évalué à 8.
Snap et Flatpak ne visent pas les mêmes buts. Le but de Snap c'est de facilement installer n'importe quel composant logiciel sur un système sans se préoccuper des dépendances et autres.
Flatpak partage en partie ce but, mais son objectif c'est aussi de fournir une couche commune pour mutualiser un maximum de choses entre les Flatpak, de fournir de limiter les droits d'accès des applications par défaut en utilisant un système de permission ou de requêtes de permissions pour faire plus (comme sur les téléphone mobile) et autres. Pour plus de sécurité et d'isolation des dites applications.
Bref, la conception n'est pas la même, ils ne visent pas vraiment le même besoin. Ce n'est donc pas choquant qu'il y ait cohabitation des deux.
Red Hat a collaboré sur upstart et l'a même adopté. L'abandon d'upstart s'est fait quand ils (Red Hat et Canonical) ont identifié les limites d'upstart qui nécessitait une profonde reconception de la chose. Quand systemd était prêt, on notera que Canonical et Ubuntu n'ont pas fait un scandale et l'ont adopté assez sobrement. Ce n'est pas aussi manichéen qu'on pourrait le croire.
Pourtant ces entreprises ont fait énormément pour l'écosystème, le libre n'a jamais signifié être gratuit et on devrait se féliciter que le libre permette à des gens d'être payé pour le faire avancer. Et ils font un gros travail.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Toujours le même
Posté par Kerro . Évalué à 4.
Avec ses petites mains il a obligé GNOME et toutes les distributions à obéir ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4. Dernière modification le 13 juillet 2019 à 17:15.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Toujours le même
Posté par Kerro . Évalué à 1.
Il n'a pas attendu : il a fait.
La grande attente dont tu parles n'a pas emballé les foules puisque personne d'autre n'a produit un truc accepté par GNOME et les mainteneurs des distributions.
Il a produit un logiciel d'une manière qui ne te convient pas. Peut-être que c'est un sale type, admettons. Ça ne change strictement rien à TA capacité à régler ce problème : tu forkes le truc et hop tu ouvres la porte à de belles collaborations sans même écrire une ligne de code.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
# « Guerres »
Posté par David Demelier (site web personnel) . Évalué à 2. Dernière modification le 12 juillet 2019 à 09:09.
Je souris légèrement à ces réactions excessives du côté des développeurs chez Red Hat et GNOME. « Ah vous n'installez plus GNOME Software dans votre distribution ? Tant pis on supprime le support de snap ».
Red Hat et GNOME sont loin d'être blancs comme neige et ne jouent pas toujours franc jeu non plus. Il y a qu'à voir la plupart des réactions chez systemd qui se finissent souvent par « on fait comme ça et tant pis si vous ne suivez pas ». Autre exemple dont je suis affecté, un développeur GNOME qui pense que glibc est le standard sous Linux et ne souhaite visiblement pas supporter d'autres alternatives.
Pour faire bref : l'herbe n'est jamais plus verte ailleurs. Chaque distribution fait un peu des conneries dans son coin. Mais c'est aussi grâce à ça qu'on fait des erreurs et on arrive à trouver parfois une bonne solution. Exemple simple : les fichiers .desktop, XDG, FDO en général.
En revanche, on peut pas vraiment jeter la pierre à Canonical pour développer snap, ça a commencé avant flatpak.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: « Guerres »
Posté par Renault (site web personnel) . Évalué à 7.
Oui, enfin tu oublies une part essentielle de son propos :
En gros, rien n'empêche à ce que ce composant soit compatible avec musl mais il ne va pas se charger lui même pour ton plaisir de s'en occuper.
Le libre et le développement communautaire ne signifient pas que les développeurs doivent répondre au moindre desiderata de ses utilisateurs. Si tu veux une fonctionnalité ou un support, tu as le code, envoie un correctif et maintiens le.
C'est trop facile d'exiger aux autres de faire l'effort.
[^] # Re: « Guerres »
Posté par David Demelier (site web personnel) . Évalué à 4.
Rien à voir.
Comme tu peux le voir, il y a une personne qui a envoyé plusieurs patchs et il ne l'a toujours pas inclus et a argumenté contre l'idée de musl avant en gros : pourquoi intégrer votre patch ? c'est vous qui ne voulez pas vous plier à glibc alors payez les conséquences.
Le patch est là, il y a juste à appliquer.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: « Guerres »
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 2.
C'est une vision très "bisounours", oui il y a un patch (et pour le coup il est assez basique) mais ça veut dire que ce patch duplique du code et donc que s'il y a un dysfonctionnement à l'avenir il faudra prendre en compte que si libc != glibc alors vérifier que les différents bout de code rajoutés pour compléter les différentes librairies C ne sont pas sources de bug et retracer les différents fix apportés sur ces bouts de codes et les re-implémenter.
Il ne faut pas oublier que le code est fourni "tel quel" par quelqu'un qui n'est pas payé pour ça et du coup n'a de compte à rendre à pas grand monde, sauf peut-être quelques obligations morales s'il fait parti d'un gros projet, et encore..
[^] # Re: « Guerres »
Posté par FluffyHamster . Évalué à 7. Dernière modification le 12 juillet 2019 à 11:39.
Le tout premier commentaire sur l'article de phoronix résume bien le propos et m'a fait beaucoup rire :
[^] # Re: « Guerres »
Posté par Anonyme . Évalué à -3.
Perso, tu viens ouvrir une issue chez moi en trollant comme tu le fais sur celle-ci, je te bloque direct.
[^] # Re: « Guerres »
Posté par David Demelier (site web personnel) . Évalué à 3.
Regarde avant de commenter. Je n'ai pas ouvert quoi que ce soit c'est une personne qui fournit un patch et le mainteneur qui ne veut pas l'intégrer parce que pour lui glibc est la référence et tout le monde doit s'y plier.
git is great because linus did it, mercurial is better because he didn't
# La position de Linux Mint
Posté par maitrepylos . Évalué à 8.
Clément lefevbre de LinuxMint en parlais dans son dernier post et visiblement il est pas chaud d'intégrer le store Ubuntu dans Mint :
When snap was announced it was supposed to be a solution, not a problem. It was supposed to make it possible to run newer apps on top of older libraries and to let 3rd party editors publish their software easily towards multiple distributions, just like Flatpak and AppImage. What we didn’t want it to be was for Canonical to control the distribution of software between distributions and 3rd party editors, to prevent direct distribution from editors, to make it so software worked better in Ubuntu than anywhere else and to make its store a requirement.
If you’re a Fedora user and you want to install Spotify, you’re told to go to https://snapcraft.io/spotify. Spotify doesn’t distribute RPM packages, appimage, Flatpak or anything useful to a Fedora user who wants to download it, or to a Fedora maintainer who wants to add it to a repository. Fedora users are told to go to what is essentially a commercial store operated by a RedHat competitor where stats tell them their distribution is only 7th best.
We’re in luck, we can still download the .deb. If Spotify stops caring, what do we do? We move to snap because we have to? Will the snap store continue to let people download actual .snap files in the future or will that get locked down ? Will the snap store continue to operate without an Ubuntu One account or will we get vendor-locked ? I think it’s important to appreciate these aspects.
We all have smartphones, and we all know how great the Google Play store is. How often do we see .apk (Android packages) on the web ? How hard are they to install without the Google store ? How free is an editor to publish its .apk itself while being present in the store ? Who controls all that and what does it mean for us ? Who governs what can and cannot go into the store ? Who makes commercial deals ? Who do we rely on ? And why ?
As long as snap is a solution to a problem, it’s great. Just like Flatpak, it can solve some of the real issues we have with frozen package bases. It can provide us with software we couldn’t otherwise run as packages. When it starts replacing packages for no good reason though, when it starts harming our interaction with upstream projects and software vendors and reducing our choice, it becomes a threat.
A Fedora user shouldn’t be told about Ubuntu and Ubuntu One when downloading software. His browser shouldn’t have bookmarks pointing to another distribution. His software shouldn’t be designed and tested primarily with another desktop environment and distribution in mind, and when he looks at screenshots he shouldn’t see Ubuntu everywhere. It’s wrong for Spotify to do that and it’s wrong for any vendor to think that such a store can be the only store for all Linux users. For this to work it would need to be governed by us all, with clear goals, without bias and without conflict of interest.
When Flatpak came out it immediately allowed anyone to create stores. The Flatpak client can talk to multiple stores. Spotify is on Flathub and they can push towards it. If tomorrow they have an argument with Flathub they can create their own store and the very same Flatpak client will still work with it. When Snap came out, it was only a client. The server was behind closed doors and the client couldn’t talk to multiple servers. We’ve been worried about this since then, but it was OK. As long as Snap didn’t become the de-facto standard for all editors to publish to all users of Linux, it was OK. As long as editors didn’t stop distributing packages, it was OK. As long as Snap didn’t remove what we already had, it was perfectly OK. The Ubuntu Store, which is now called the Snap Store (which makes sense since there can only be “one” store, by design), was promising because it could provide software we didn’t have access to, and a payment platform to purchase commercial software. It’s doing much more than that though, it could reduce access to free (as in beer) software and free (as in freedom) software.
There are a lot of things you can do with package managers (apt/dpkg in Linux Mint), that you can’t do with Snap, and there are two reasons for this. First, they’ve been around for a while. They’re mature, they’re integrated fully within the OS in every distributions. Second, they’ve been developed with Free Software in mind. There are no commercial aspects in the design of apt/dpkg, it’s all about empowering users and distributions. You can’t modify, rebuild, pin, patch, mirror a snap, you’re not supposed to.
I’ve been invited to participate by the Snap developers and I’m hoping one day we’ll be able to integrate snap into Linux Mint. Although I’m worried about the impact on the market, I think snap could work both as a client and a file format, if it didn’t lock us into a single store. You might wonder why I’m so outspoken about this all of a sudden. There’s a certain sense of urgency which demands action on our side. Ubuntu is planning to replace the Chromium repository package with an empty package which installs the Chromium snap. In other words, as you install APT updates, Snap becomes a requirement for you to continue to use Chromium and installs itself behind your back. This breaks one of the major worries many people had when Snap was announced and a promise from its developers that it would never replace APT.
The plan isn’t just to delegate part of APT with Snap in the current Ubuntu releases, but also to backport this change towards Ubuntu 18.04 LTS. We don’t want this to affect Linux Mint.
I don’t think the points we’re raising here are well understood by the community. I hope we’ll talk with Ubuntu and the Snap project about this. We’re very interested in your feedback as well. A self-installing Snap Store which overwrites part of our APT package base is a complete NO NO. It’s something we have to stop and it could mean the end of Chromium updates and access to the snap store in Linux Mint.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: La position de Linux Mint
Posté par maitrepylos . Évalué à 5.
Voici : https://blog.linuxmint.com/?p=3766 sur le titre snap :)
[^] # Re: La position de Linux Mint
Posté par Melodie (site web personnel) . Évalué à 2.
c'est du déjà vu, avec entre autres des logiciels libres qui nécessitaient un paquet non libre (AdobeAir ça vous parle ?). Et bien sûr paf, une fois le logiciel pas libre plus fourni pour nunux, c'est tombé dans le trou (ou à l'eau, adieu le zoli programme avec sa petite interface). Idem pour flashplayer… et pour Acroread… Heureusement, Okular le remplace avantageusement (ainsi que Libreoffice Draw pour compléter des champs dans des pdf). (Tiens, un programme issus du monde KDE/Qt… )
# Et alors ?
Posté par totof2000 . Évalué à 2.
En quoi est-ce problématique ? Redhat a bien lancé systemd au détriment d'upstart …
[^] # Re: Et alors ?
Posté par dani . Évalué à 1.
Nop. C'est Lennart seul qui a lancé systemd, sur son temps personnel. Il était employé de Red Hat, mais pas payé pour systemd. Red Hat a ensuite adopté systemd une fois qu'il était devenu l'init par défaut de pleins de distribution majeures (dont Fedora). En fait systemd n'est pas, et n'a jamais été un projet de Red Hat
[^] # Re: Et alors ?
Posté par totof2000 . Évalué à 4.
Ah ?
https://getfedora.org/fr/sponsors/ :
Red Hat, Inc. est le sponsor principal de Fedora Project. Red Hat propose le projet Fedora avec une grande variété de ressources, y compris le soutien d’employés à plein temps, du matériel d’infrastructure et de bande passante, le financement d’événements et des conseils juridiques.
Tu as beau dire que "Il était employé de Red Hat, mais pas payé pour systemd", j'ai du mal à croire qu'il n'ait pas poussé bien fort pour que systemd soi intégré a Fedora et a Redhat plus tard.
[^] # Re: Et alors ?
Posté par dani . Évalué à -1.
Oui, Red Hat est le sponsor principal de Fedora. Mais je vois pas de rapport avec la choucroute. D'une part parce que même si Fedora est sponsorisé, c'est un projet communautaire indépendant, et d'autre part parce que systemd n'est pas un projet Fedora non plus (Fedora a simplement été l'une des premières distributions majeure à l'adopter)
[^] # Re: Et alors ?
Posté par modr123 . Évalué à 1.
la première pas l'une des premières
Lennart Poettering and Kay Sievers, the software engineers working for Red Hat who initially developed systemd
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.