Je vai peut-être passer pour un type qui n'aime pas le changement (et je m'en fous), mais tant pis, d'autant plus que je ne suis pas contre le changement en soi mais contre les changements qui emm***ent le monde.
De plus en plus de paquets sont maintenant distribués, non plus au format de packaging historique des distributions mais dans des formats style flatpack, snap ou autre.
Beaucoup ont l'air de dire que le flatpack/snap/autre est bien, mieux que l'autre à côté, que c'est l'avenir, et que ça a vocation à remplacer les paquets historiques des distributions.
Ben désolé de vous décevoir mais …. NON. JE NE VEUX PAS DE CES M**DES SUR MA DISTRIB.
Pourquoi ? Parce que ça passe son temps a tomber en panne sans prévenir. Encore un problème récent : https://forum.snapcraft.io/t/almost-all-snaps-broke-overnight-and-need-to-be-reinstalled/22032/10.
Ce n'est pas la première fois que j'ai des snaps qui tombent en panne sans rien dire. Parfois ça retombe en marche quelques jours/semaines plus tard sans que je ne fasse rien. Comme je n'ai que peu de snaps qui tournent sur mon système, je ne suis que rarement impacté (et quand je le suis ça me donne l'occasion de trouver un repo qui fournit le paquet en format classique). Mais franchement C'EST PENIBLE !!!!
Je n'aime absolument pas ce truc opaque qui fait des choses sans te tenir au courant, et qui te laisse avec des softs qui ne fonctionnent pas alors que tu n'as rien demandé. J'ai quitté le monde Windows justement à cause de ce genre de problèmes. Si je voulais ce mode de fonctionnement, je serais sous Windows.
Un autre problème qui m'est arrivé cette semaine avec snap : l'impossibilité d'étendre la partition / de ma VM pro via gparted parce que le snap de firefox verrouillait ladite partition. J'ai dû virer le snap avant de pouvoir étendre celle-ci via gparted.
Donc pour résumer, messages aux devs de toute sorte : je n'ai rien contre les changements, mais si ce sont des changements qui me pourrissent la vie, gardez-les pour vous. Autre point : ne pensez pas que les gens sont venus sous Linux pour retrouer le même mode de fonctionnement que sous Windows : non, si les gens veulent un système qui fonctionne comme Windows, ils utilisent le windows préinstallé de leur machine. Beaucoup de gens qui vont vers Linux y vont parce que le fonctionnement de windows ne leur convient pas. Donc SVP … arrêtez de le singer jusqu'à dans ses pires modes de fonctionnement SVP.
# Ne pas tout mettre dans un même sac
Posté par Renault (site web personnel) . Évalué à 10.
Si Flatpak et Snap ont des points communs, ils restent aussi radicalement différents. Et les Flatpak semblent avoir bien moins de soucis similaires à ce que tu cites ici. Donc mettre le tout dans un même panier bof.
Ensuite l'idée derrière Snap peut être bonne et l'avenir et avoir juste une implémentation pas fiable aujourd'hui, mais cela peut s'améliorer évidemment.
Mais le but n'est pas de reproduire Windows non plus. On notera aussi que de nombreux utilisateurs voulaient aussi des changement car le fonctionnement des paquets traditionnel a aussi ses limites, ne t'en déplaise cela ne convient pas toujours. Ce n'est pas pour rien que de nombreux développeurs fournissent leur paquets ainsi, cela évite les problèmes rencontrés avec la solution que tu chéries tant.
[^] # Re: Ne pas tout mettre dans un même sac
Posté par abriotde (site web personnel, Mastodon) . Évalué à 7.
Tu en dis trop ou pas assez. Le problème avec le système traditionnel tel les paquets deb, ce sont les conflits. Typiquement, la liste de journaux sur les environnements Python, est le coeur de cible. On a des soft qui tournent en Python2 et d'autres en Python3, des soft qui ont besoin de la lib XXX en version < 0.12.3 et d'autres qui la veulent en version > 1.23. Avec les paquets, on est obliger d'arbitrer puisqu'elles seront disponibles pour tous.
Avec Snap, on s'en fiche, il intègre tout dans son paquet. En plus, l'application sera fans un environnement plus ou moins contrôlé, à savoir avec des droits limités puisque derrière c'est un Docker. L'utilisateur hésite donc moins à l'installer.
Autant effectivement, cela permet d'intégrer tout et n'importe quoi. Autant cela présente à mes yeux 2 inconvénients majeurs :
1) L'installation des paquets est bien plus lourde à tous les niveau. Elle est plus lourde puisqu'elle duplique sa version des librairies, elle est donc plus lente à lancer puisqu'elle est isolé, elle est aussi plus lente à tourner et demande plus de RAM car il faut avoir plusieurs instance des même librairies de bases.
2) Comme les développeurs n'ont plus vraiment la pression de mettre à jours leurs dépendances pour faire tourner leur application sur Linux, ils le font moins (Du moins certains). Et puis ce n'est pas vraiment grave que la librairie comporte des failles de sécurité car elle est en environnement isolé…
Autrement dis, c'est un truc de fainéant, et le problème c'est que comme ça marche pas trop mal, ça n’incite pas à faire les choses plus proprement. De l'autres côté, comme ça simplifie la vie des mainteneurs, cela arrange tout le monde…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Ne pas tout mettre dans un même sac
Posté par Renault (site web personnel) . Évalué à 10.
Bah voyons, quel jugement de valeur.
Le problème ici c'est qu'il y a deux modèles qui ont des avantages et inconvénients chacun. Et aucun système n'est parfait, tout est affaire de compromis. Présenter cela comme un truc de fainéant c'est une mauvaise foi sur les inconvénients du système de paquet traditionnel.
Depuis longtemps il y a une demande des utilisateurs et des développeurs pour ajouter de la flexibilité, et c'est ce que l'on a aujourd'hui, tu peux techniquement profiter du meilleur des deux mondes selon tes propres besoins.
Passons en revue quand même les inconvénients des systèmes traditionnels.
Déjà comme chaque distribution est unique, avec son propre découpage des paquets, format de paquet, versions des bibliothèques, options de compilation du système, conventions d'installation (/usr/bin séparé de /bin ?), etc. c'est compliqué pour le développeur de fournir les paquets adéquats à ses utilisateurs facilement. Tu peux au final te retrouver avec des binaires pré-compilés en priant que ça passe, avec quelques paquets pour les distributions majeures quand le développeur est motivé. Pour le développeur c'est pénible, de même quand il reçoit des rapports de bogue car la distribution utilise des bibliothèques dans des versions trop vieilles et non testées par le développeur.
Ensuite on a vu l'argument ici assez fumeux que ce n'est pas au développeur de faire ça. Mais des logiciels confidentiels mais utiles il y en a des tas. Même Debian n'a pas la logithèque complète du Logiciel Libre. Donc la distribution pour ces projets est difficile et risque d'être fastidieuse pour les utilisateurs qui ont peut être autre chose à faire qu'à tout faire eux mêmes en priant que ça passe.
Puis le fameux mainteneur qui doit s'occuper de ça, faut encore qu'il existe. Empaqueter des paquets ce n'est pas une tâche triviale et il manque beaucoup de bras pour cette activité. Ce n'est pas pour rien que RHEL par exemple laisse tomber LibreOffice récemment ou n'a jamais pris en charge KDE officiellement. Trop de boulot. Chez Debian, Fedora, Ubuntu, etc. les besoins de bras sont là. Donc leur demander encore plus d'efforts pour avoir une logithèque complète ça me semble être une impasse et un comportement un peu égoïste. C'est facile de dire yakafocon mais bizarrement quand il faut aider la distribution il y a moins de monde.
Ensuite la distribution fait des choix assez rigides. Par exemple Fedora ne change pas de version majeure de LibreOffice sur une version de Fedora Linux donnée. C'est un choix, mais si j'ai envie / besoin de la dernière version car elle apporte quelque chose d'utile pour moi, ça peut être sympa d'avoir un moyen simple d'avoir la dernière version sans changer le reste.
Ou si j'ai envie de contribuer à Firefox, avoir la version nightly dans un moyen simple et standard sans avoir un vieux binaire abandonné dans mon
/home, c'est cool aussi si Mozilla fourni un moyen standard de l'obtenir sur n'importe quelle distribution. Et c'est bon pour eux aussi, plus d'utilisateurs pour moins d'efforts.Ou encore en équipe. Dans ma boîte chacun utilise sa distro. Quand on fait une LAN on a besoin d'utiliser la même version sinon ça ne fonctionne pas pour joueur ensemble. Avec Flatpak c'est trivial, avec chacun sa distro c'était plus simple de basculer sous Windows autrement… Cela peut s'appliquer par ailleurs à des outils de travail éventuellement.
Puis au moins il y a aussi l'isolation en standard avec des portails pour s'en extraire si besoin (du moins avec Flatpak). Mon boulot exige que j'utilise Skype ou Slack, leur installation est triviale et ils n'ont pas accès à tout mon système comme ça.
Et en plus Flatpak résout en parti la gourmandise en ressources et la maintenance des bibliothèques de base par l'usage de runtime.
Bref, le système traditionnel a ses avantages, c'est indéniable. Mais il faut arrêter de l'idéaliser et de croire que tout le monde est content avec ça. Flatpak et Snap apportent des fonctionnalités bienvenues et tout le monde est libre d'utiliser les deux modèles en parallèle. Le code est libre, les distros aussi, le modèle traditionnel ne disparaitra que si personne ne veut se farcir la délicate question de la maintenance associée.
[^] # Re: Ne pas tout mettre dans un même sac
Posté par autra . Évalué à 1.
Tu oublies un avantage majeur avec les snap/flatpack: une application packagée aujourd'hui marchera toujours dans 10 ans (puisqu'elle intègre ses dépendances). Essaie d'installer un deb pour jessie sur une bookworm pour voir ;-)
C'est le gros problème du système actuel : cela suppose que tous tes logiciels restent maintenu pour l'éternité.
[^] # Re: Ne pas tout mettre dans un même sac
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Peut-être… C'était aussi la promesse de Docker par exemple. Et tu découvres un jour qu'il y a du cgroups v1 et du v2 et que ça ne marche plus comment avant.
C'était aussi la promesse de Lxc par exemple. Et tu découvres un jour que systemd a une dépendance noyau et donc ton conteneur dépend un peu trop de l'hôte.
Donc ça continuera à marcher s'il n'y a pas de changement d'ABI dans le noyau, de périphériques qui ont changé complètement, d'architecture CPU nouvelle, de passage en IPv6 uniquement, de révolution XFree86/Xorg/Wayland trop rapide, etc., etc. Bref si ça ne change pas trop autour, ça pourra encore marcher. Et c'est toujours mieux en termes de pérennité qu'un paquet dynamique non maintenu dans une distribution, mais ça n'est pas non plus un totem d'immunité ou la solution ultime de l'informatique.
[^] # Re: Ne pas tout mettre dans un même sac
Posté par lym . Évalué à 3.
Ces systèmes sont quand même une manière de gérer des dépendances pas idéales et en effet pas sans rappeler windows (tout applicatif en embarque en fait l'essentiel, avec des quasi-doublons), voir Java (On a fini par voir quasiment tout applicatif Java un peu conséquent embarquer tout jusqu'à sa propre JVM dans les versions validées… avant de voir moins de Java!).
C'est pas idéal niveau stockage (volumes, temps de démarrage d'un applicatif…), mais aussi niveau mémoire et ce n'est pas ici comme le stockage qu'un pb de volume, mais aussi de sape de la gestion mémoire virtuelle qui peut moins bien jouer son rôle et tout derrière suit (caches…) avec des performances exécrables en pratique.
Cela peut certes rendre occasionnellement service, mais généraliser cela à la Ubuntu n'est clairement pas une bonne voie.
Dire qu'ils avaient en Bug N°1 de bouter Microsoft du PC: Non seulement ils ne l'ont pas fait après pourtant de bon débuts (la LTS 10.04 en fin de support avait été ma dernière Ubuntu, le délire ayant commencé par leur UI cornecul), mais ils vont finir par devenir pire que l'original, pourtant sans le handicap de l'historique de compatibilité binaire ascendante qui oblige Microsoft à avoir encore du code "dette technique" de l'époque DOS dans les Windows actuels!
Le problème snap&co, c'est que trop de développeurs ne travaillent plus avec le souci de minimiser les dépendances au maximum et d'en (bien) choisir (des stables/éprouvées) quand il en faut. Cela donne des situations tenant de l'alignement des planètes quasi impossible à assurer sur un système donné sans une forme de conteneurisation (dont on viole au passage le concept de base).
Ca me semble venir du web, son ttm faisant sauter sur le dernier framework à la mode et on s'en fout si dans 3/4 ans c'est devenu impossible à maintenir (avec les dépendances de dépendances de dépendances abandonnées): On facturera une refonte complète au client faite dans un mode identique, sorte de business perpétuel!
# Je te rejoins un peu la dessus :)
Posté par nekopep . Évalué à 10.
Bon de mon coté j'ai un peu joué avec ces derniers, snap, flatpack, appimage.
Snap -> Je n'aime pas, ca donne l'impression d'un sacré usine à gaz. Ca nouffe du giga opur 3 applis…
Flatpak -> Me paraissais plus simple, mais en fait le peu d'installation que j'ai essayé ne fonctionnaient pas bien.
La dernière blague en date, installation de pycharm-ce. Hop j'ouvre un projet en local, je déclare mon venv, j'installe 2 trois packages (hors pycham).
Je lance mon code en mode debug, impossible de le faire fonctionner alors qu'en ligne de commande ca passe :/. En fait flatpak générant un environnement isolé, pycharm utilisait un python du flatpak pour le venv alors qu'en ligne de commande ca utilisait le python de la distrib.
Bref… un sacré bazar pour pas grand chose :)
Le seul truc qui marche a peu prés pour moi ce sont les AppImage pour freecad, et le prusa-slicer. Là je n'ai pas eu trop de pépins (mais ce ne dois pas être aussi compliqué que les 2 derniers)
My 2 cents.
[^] # Re: Je te rejoins un peu la dessus :)
Posté par Okki (site web personnel, Mastodon) . Évalué à 1.
Le souci ne viendrait pas plutôt du fait qu'en ligne de commande, tu ne cherches pas à utiliser la même chose que le Flatpak ? Puisque effectivement, ça va s'exécuter dans un environnement séparé du reste du système, il faut faire de même en ligne de commande.
Faudrait voir plus précisément ce que t'as installé puis utilisé avec les paquets traditionnels puis en Flatpak, mais on peut déjà dire que ce n'est pas le Flatpak qui va alterner entre l'un et l'autre selon que tu l'utilises graphiquement ou en ligne de commande…
En ligne de commande, comme c'est chiant de devoir taper flatpak run com.jetbrains.PyCharm-Community tu peux créer des alias :
# ouaip
Posté par barmic 🦦 . Évalué à 10.
D'une part il faut distinguer ne pas comprendre de ne pas te tenir au courant. Rien dans deb ou rpm ne te préviennent et ma debian ne me dis rien d'elle même. Je sais comment ça fonctionne quand et comment il y a des mises à jour. Ensuite l'argument du windows… Personne sous linux ne fait les choses parce que ce serait fait ou parce que ça n'existe pas sur un autre OS, mais parce qu'ils sont convaincus que ça a de la valeur. Tu ne les contredira pas en disant que c'est comme windows.
Une seule distribution et ses quelques dérivées utilisent snap et je n'ai vu aucun mouvement allant vers une adoption plus large de ce mode de distribution.
C'est le propre des distributions de faire de la gestion de paquets et de leur mode de distribution et ça tombe bien il y en a pleins. Vois avec Canonical si tu est client chez eux, sinon sent-toi libre de changer de crèmerie. Ubuntu n'est pas une fatalité.
T'es gentils de citer à moitié mes tes griefs ne vont que vers l'un de ceux que tu cite.
Est-ce que tu crois 1s qu'il y a quelqu'un qui travaille en se satisfaisant de te pourrir la vie ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: ouaip
Posté par Astaoth . Évalué à -7. Dernière modification le 28 janvier 2024 à 11:21.
Franchement, parfois la question se pose. Quand on voit le nombre de bugs qu'on peut rencontrer en 15 min d'utilisation de Plasma ou le nombre d'utilisateurs qui n'arrivent pas à quitter Vi …
Emacs le fait depuis 30 ans.
# popup
Posté par vmagnin (site web personnel) . Évalué à 7. Dernière modification le 27 janvier 2024 à 22:26.
Au fait, quelqu'un sait-il comment désactiver les pop-ups qui apparaissent en bas à droite de l'écran à chaque fois qu'un snap doit être mis à jour dans Ubuntu ? C'est fou comment un petit truc comme ça peut devenir agaçant à la longue :-)
Et puis snap m'empêche d'imprimer normalement avec Zim car ça embrouille Firefox :
https://github.com/zim-desktop-wiki/zim-desktop-wiki/issues/2025
Depuis quelques mois, j'explore FreeBSD pour me changer les idées. Les dépôts semblent à peu près aussi fournis que chez Debian, et les versions très à jour comme dans une Fedora… Bon, je n'ai pas encore essayé de configurer mon imprimante, mais une chose à la fois.
[^] # Re: popup
Posté par p1ld7a . Évalué à 4.
J'ai utilisé FreeBSD avant de switcher vers NixOS… Meme si l'expérience FreeBSD fut bonne, NixOS est une merveille que je regrette de ne pas avoir utilisé plus tôt.
[^] # Re: popup
Posté par Jean-Baptiste Faure . Évalué à 9.
Supprimer snap ?
# change de distro :-)
Posté par BAud (site web personnel) . Évalué à 10. Dernière modification le 28 janvier 2024 à 00:01.
dans notre fablab, je garde Debian et Mageia, je tolère Ubuntu Studio, j'ai un peu de mal avec Manjaro, mais moins que toi :p
et oui AppImage ça juste marche, le reste bin…
# Chacun ses besoins, mais tous libre
Posté par pulsar89.5 . Évalué à 8. Dernière modification le 28 janvier 2024 à 00:42.
J'ai beaucoup de mal avec ce type de post. Tu te rends bien compte que si ces solutions existent, c'est pour répondre à un besoin ?
J'ai eu l'occasion de jouer avec snap pour LXD et ça juste marche depuis des années. Sur un environnement de bureau, je ne sais pas, j'utilise une distribution qui ne l'utilise pas par défaut. D'ailleurs en parlant de ça, si tu veux une base Ubuntu sans snap, il y a Linux Mint.
Concernant Flatpak, c'est juste parfait pour moi. Utilisateur Debian pour la bureautique, j'étais souvent frustré de devoir batailler pour installer certaines applications ou juste avoir la dernière version.
Voilà, donc tu peux être insatisfait d'une solution, mais rien ne t'oblige à l'utiliser.
[^] # Re: Chacun ses besoins, mais tous libre
Posté par p1ld7a . Évalué à 9.
Perso ce qui me dérange c'est la dimension marketing du Snap.
Ubuntu a créé ce format afin d'offrir une vitrine payante aux éditeurs de logiciels.
Ils commencent d'ailleurs a utiliser Snap par défaut pour certaines apps comme Firefox.
En plus de rendre le processus plus et pas écologique (aucune mise en commun des dépendances entre 2 Snap), ils se permettent de l'imposer comme étant la solution miracle.
Au boulot nous sommes obligés d'utiliser Ubuntu si on veut un laptop sous linux. Une des premières choses que je fais est de supprimer Snap et remplacer le dépôt Firefox… Et ça va déjà bp mieux.
Maintenant d'un point de vue perso, je suis un fidèle utilisateur de NixOS et je n'ai jamais eu besoin d'utiliser de Snap sur mes machines, heureusement.
[^] # Re: Chacun ses besoins, mais tous libre
Posté par barmic 🦦 . Évalué à 4.
Ça n'est qu'une question de perception. Debian se permet d'imposer deb comme solution miracle, RedHat se permet d'imposer rpm comme solution miracle, archlinux se permet d'imposer PKGBUILD comme solution miracle,… C'est normal que quand tu crée une distribution tu y place ce que tu veux. C'est même leur travail de faire ce genre de choix.
C'est curieux de reprocher à snap la place qu'il prend pour encenser nix pour qui l'espace disque utilisé est un vrai sujet.
Par contre, pourquoi tu n'utilise pas nix sur ubuntu ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Chacun ses besoins, mais tous libre
Posté par p1ld7a . Évalué à 1.
Nix prends plus de place car il stocke plusieurs générations de ton OS, mais pas que.
Il y a moyen de réduire considérablement l'espace disque utilisé en le configurant différemment.
L'utilisation de l'espace disque n'a jamais été un problème pour moi et je n'ai jamais du faire en sorte de changer ma config pour l'adapter en fonction de ma machine.
Sinon, concernant nix, je n'ai tout dis vu que ce n'est pas le sujet principal. Sinon, la première chose que je fais sur les laptops corporate est de supprimer Snap… Et puis d'installer nix.
[^] # Re: Chacun ses besoins, mais tous libre
Posté par lym . Évalué à 0.
Euh… Grosso modo les paquets qqsoit le format c'est une archive pour extraire les binaires nécessaires et générés pour s'interacer sans heurts avec le reste du système, boulot (aussi utile qu'ingrat) des mainteneurs.
Rien à voir avec une conteneurisation qui évite tout ce travail, qui est à la base ce qui explique qu'une distrib Linux et son applicatif tourne beaucoup mieux sur un même PC que la même chose sous Windows… et permet en fait de proposer tout ce que les mainteneurs se refusent à maintenir!
[^] # Pas tous libre
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Snap est privateur.
Ubuntu n'est plus un OS libre, mais un OS avec des composants libres. Comme Windows ou Macos.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas tous libre
Posté par barmic 🦦 . Évalué à -10.
Ça fait de belles phrases bien putaclick, mais c'est faux ou alors Debian est privateur aussi. C'est l'avis de certains, hein ? Mais bon ça n'est pas pour autant le sens commun. Crier au loup comme ça ne me semble moins être une façon de servir la cause du libre mais de ce servir du libre contre ta distribution détesté.
Beaucoup de gens ont adulés ubuntu pendant 10 ans en ne présentant qu'elle en se disant qu'une seule distribution ça simplifiait la venue d'utilisateurs et maintenant se retrouve le bec dans l'eau parce qu'ils s'imagine ubuntu comme étant en situation de monopole.
Snap est un détail dont les utilisateurs du libre se foutent et avec le quel ils ne seront jamais confrontés. C'est vraiment une tempête dans un verre d'eau.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas tous libre
Posté par Astaoth . Évalué à 4.
Bah apparemment, d'après certains par ici, fournir une stack logiciel libre avec un ou 2 composants proprio facultatif, c'est faire de l'openwashing (genre ici par exemple).
Emacs le fait depuis 30 ans.
[^] # Re: Pas tous libre
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Snap est au cœur d'Ubuntu et de la stratégie de Canonical. Le Snap Store est privateur, ce n'est pas une opinion, c'est bien sa licence: https://launchpad.net/snapstore-server
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas tous libre
Posté par barmic 🦦 . Évalué à -10.
Ça veut dire quoi ? Au cœur de toutes les distributions que j'ai utilisée il y avait linux.
Jouons au 7 différences :
et
Ce qui te permet de passer de l'un à l'autre c'est… ton opinion.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas tous libre
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Tu déploies des trésors de mauvaise foi pour ne pas voir le problème d'une distribution basée sur un dépôt/store d'applications non libre :-)
Ubuntu a rejoint le club des distributions dont le coeur est bien Linux, mais avec un "appstore" pas libre : Android, SteamOS, KaiOS, WebOS…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas tous libre
Posté par barmic 🦦 . Évalué à -4.
Je vais faire comme toi, je suis factuel le code ici est libre. Si ils ne respectent pas la GPLv3, il faut régler ça devant les tribunaux. Ubuntu est toujours basée sur Debian et est toujours basée sur deb. Elle met en avant snap, mais tu peux t'en séparer. Que ça plaise ou non perso je m'en fous. Je n'ai pas attendu snap pour quitter ubuntu qui n'a pas de valeur ajoutée pour moi par rapport à Debian.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas tous libre
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Tu pointes juste le service côté client et pas le serveur :-)
Le libre washing a de beaux jours devant lui.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas tous libre
Posté par barmic 🦦 . Évalué à -8.
Tant que tu tentera de mettre dans le « libre » autre chose que le libre ça se passera pas bien effectivement.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas tous libre
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
https://launchpad.net/snapstore-server#project-info
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas tous libre
Posté par barmic 🦦 . Évalué à -5.
Jouons au 7 différences :
et
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas tous libre
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Tu considères qu'un système qui ne peut fonctionner qu'avec un client et serveur est libre même si seul le client est libre ?
Et bien… non !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas tous libre
Posté par barmic 🦦 . Évalué à -2.
Je considère qu'un logiciel distribué sous une licence libre qui respect sa licence est libre. C'est pour ça qu'un driver de base de données Oracle ou SQL Serveur peut être libre. Ça ne fait débat que dans ton microcosme.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Someone is wrong on the internet
Posté par David Delassus (site web personnel) . Évalué à 10. Dernière modification le 28 janvier 2024 à 23:17.
Vous commencez à casser les pieds avec votre discussion de sourd.
Personne ne contredit que le client est libre. Mais le système qui englobe le client et le serveur ne l'est pas, car le serveur ne l'est pas.
Oracle n'est pas libre, même si il existe des clients oracle libres.
Snap, qui inclus Snap Store n'est pas libre, même si il existe des clients pour le Snap Store qui sont libres.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Someone is wrong on the internet
Posté par barmic 🦦 . Évalué à -10.
Ça tombe bien tu n'étais pas dans l'échange.
C'est quoi ce système ? Il a une licence ? Ça se licencie un système ?
Snap serveur n'est pas libre, mais les distributions qui l'utilisent peuvent l'être. Contrairement à ce qui est dis plus haut, Ubuntu qui ne serait pas pas libre parce qu'un composant "cœur" ne fait partie d'un "système" non libre :
Bref Ubuntu n'est pas libre que dans la tête de ceux qui pensent que tout ce qui est "mal" est non libre.
Contrairement à la caricature que tu présente la discussion n'est en aucun cas énervé. Elle ne te plaît pas, il faut apprendre à vivre avec. C'est une des très nombreux échanges ici, où on discute ce que c'est que le libre ou pas. Par exemple ici on invente un système et on lui donne une licence logiciel. On explique aussi que si tu a un client libre qui accède à un serveur propriétaire tu n'est pas libre.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Someone is wrong on the internet
Posté par Barnabé . Évalué à 10.
On est tous dans l'échange, en fait, vous n'êtes pas dans une discussion privée.
Et effectivement le Non-Si-Non-Si auquel nous assistons est un peu pénible.
[^] # Re: Pas tous libre
Posté par arnaudus . Évalué à 3.
Je ne suis pas sûr de comprendre ce que tu appelles un "système". Quand je me connecte avec un navigateur libre sur un site hébergé sur un serveur Windows, je ne peux pas être "plus libre" que ça, non? Le client et le protocole sont libres, de l'autre côté il y a un logiciel qui ne l'est pas, mais ce logiciel tourne sur un serveur qui ne m'appartient pas et sur lequel je n'ai pas de droits (enfin, disons pas plus de droits qu'un GAFAM a sur mon ordi, c'est d'ailleurs pour ça que j'estime avoir le droit de bloquer la pub ou les cookies).
Il me semble évident que pour des raisons politiques, chacun est libre de ne pas utiliser un service parce qu'il ne suit pas une série de règles de pureté qui va au-delà de la licence logicielle. Un logiciel libre peut déposer des cookies intrusifs, faire du tracking, de la reconnaissance faciale par la webcam, ou je ne sais pas quelle autre cochonnerie intrusive; ça ne l'empêche pas d'être libre, mais c'est un logiciel que je n'utiliserais pas. Un LL qui se connecte à un serveur privé sur lequel tourne des logiciels non-libres, on peut l'utiliser ou non, c'est une histoire de choix personnel qui n'a rien à voir avec le fait que le logiciel est libre.
[^] # Re: Pas tous libre
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Comparaison n'est pas raison: ton navigateur n'est pas lié à tel ou tel site.
Le client snap n'est utilisable qu'avec le serveur snap.
L'exemple de Barmic avec le driver Oracle est pertinent : un client Oracle avec une base de données Oracle, ça donne un système non libre. On a d'ailleurs souvent le cas avec des logiciels libres qui dépendent d'une base de données privatrice (mongodb par exemple).
Ce n'est pas juste une histoire de pureté libriste, de Bien et de Mal. Comme signalé dans un autre commentaire, ce caractère non libre a des conséquences très concrètes.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas tous libre
Posté par barmic 🦦 . Évalué à -2.
Je ne dis pas que ça n'est pas un problème je dis que c'est un dévoiement de la notion de libre ton "système" libre,… C'est une tentative d'utiliser la notion de libre pour quelque chose sur le quel ça ne s'applique pas. C'est assez commun et c'est utilisé à la fois pour ceux qui tentent de mettre en lumière un problème sans trouver d'autres vocabulaires, que par des gens qui se servent de l’ambigüité pour dire qu'ils sont open ou libre sans que ça n'apporte de liberté à leurs utilisateurs.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas tous libre
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Tu es tombé dans le piège
javade dépendance d'un logiciel libre à un logiciel privateur !https://www.gnu.org/philosophy/when-free-depends-on-nonfree.en.html
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas tous libre
Posté par flagos . Évalué à 2.
Vraie question: qu'est-ce qui empêche de modifier snap pour y ajouter les graines de la liberté ? Ca a déjà été tente ?
[^] # Re: Pas tous libre
Posté par Astaoth . Évalué à 2.
Ou alors qu'est-ce qui empêche de virer Snap d'Ubuntu et de l'utiliser juste avec ses dépôts ? Ca fait plus de 10 ans que je n'ai pas utilisé Ubuntu, j'ai surement raté 2-3 trucs, mais il me semble qu'ils ont toujours des dépôts et que ca reste une distribution Gnu/Linux/Systemd. Du coup le fonctionnement d'une Ubuntu n'est pas dépendante de la présence un gestionnaire de Snap.
Emacs le fait depuis 30 ans.
[^] # Re: Pas tous libre
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Il y a de plus en plus de logiciels qui disparaissent des dépôts de paquets deb d'Ubuntu, et qui sont remplacés par des Snaps. C'est le cas des navigateurs comme Firefox ou Chrome par exemple.
Techniquement, c'est un chouïa plus pervers : on trouve toujours un paquet pour ces logiciels, mais ce paquet est en fait une coquille vide, qui dépend de Snap, et qui a pour effet de faire installer le logiciel correspondant sous forme de Snap.
Bref, si on se limite aux logiciels vraiment disponibles sous forme de paquets deb, Ubuntu s'appauvrit progressivement.
[^] # Re: Pas tous libre
Posté par GG (site web personnel) . Évalué à 1.
Tu peux essayer avec une VM dans laquelle tu installes Ubuntu, puis avec leur superbe gestionnaire de paquet tu vires snap.
Peu après avoir validé la désinstallation de snap et consorts, la VM va crasher.
C'est beau la technologie Ubuntu (c'est de l'humour).
C'était mieux avant.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Pas tous libre
Posté par Jean-Baptiste Faure . Évalué à 4.
Comment expliques-tu que nous sommes nombreux à avoir supprimé snap sur ubuntu 20.04 et 22.04 et que nos installations continuent à fonctionner sans problème ?
Pour virer snap, il faut le faire proprement, en désinstallant les snaps préinstallés dans le bon ordre avant de désinstaller snapd. Tout ça est bien expliqué sur le forum ubuntu-fr.
[^] # Re: Pas tous libre
Posté par GG (site web personnel) . Évalué à 9.
parce que je m'attends à ce que le gestionnaire de paquet m'avertisse au préalable si ça va tout casser.
Ce genre de mécanisme existe pour les paquet .deb, pourquoi ça n'a pas été fait pour snapd? Je vous laisse avec vos conclusions, j'ai les miennes.
Je ne vais pas regarder les forums pour chaque paquets.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Pas tous libre
Posté par Astaoth . Évalué à 3.
J'ai pas ca sous Arch, FreeBSD ou même une Debian un peu ancienne, ce n'est pas une feature obligatoire d'un gestionnaire de paquets.
D'ailleurs sur des Debian 12, j'ai rencontré le cas où enlever un paquet propre de la distribution supprime la moitié de l'OS, sans avoir de gros message disant que ca va tout casser. Pourtant l'environnement en question est considéré comme un de ceux qui garantisse le plus la sécurité et la vie privée de l'utilisateur (si bien utilisé).
Emacs le fait depuis 30 ans.
[^] # Re: Pas tous libre
Posté par fearan . Évalué à 7.
C'est une blague? Comment les gens devinent que pour désinstaller X, faut virer d'autres éléments, dans un certain ordre? Sur toutes mes distributions lorsque je désinstalle des trucs, il désinstalle automatiquement les dépendances, et lorsque l'on se rends compte qu'un clique demande la supression de 513 paquet, on commence à se poser une question si c'est une bonne idée?
Quelle régression par rapport à avant.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Pas tous libre
Posté par Jean-Baptiste Faure . Évalué à 2.
Je ne défends pas snap, sinon je ne l'aurais pas supprimé sur mon PC. C'est une horreur, bien d'accord, mais on peut s'en débarrasser proprement sans rien casser. Je ne dis rien de plus.
Cela dit, je n'ai pas essayé de désinstaller snapd avant d'avoir désinstallé tous les snaps que j'avais, donc je ne sais pas si j'aurais eu une alerte. De plus je ne suis pas sûr que, du point de vue de APT, snapd puisse être une dépendance de chacun des snaps installés. Ne pas oublier que snapd n'est pas lui-même un snap.
[^] # Re: Pas tous libre
Posté par arnaudus . Évalué à 3.
Tu ne peux pas retirer aux devs le droit de déterminer quels paquets sont obligatoires pour l'intégrité de l'OS. Si tu retires le kernel ou systemd, tu vas avoir un message qui te dit "ne faites pas ça", et si tu le fais quand même, ça ne marche plus. Les devs n'ont pas l'obligation de mettre en place un système complexe de dépendances pour désinstaller "proprement" des paquets qu'ils considèrent comme indispensables pour faire tourner l'OS. Au pire, tu peux faire un rapport de bug et une proposition de patch pour rendre le truc désinstallable avec une gestion des dépendances différentes de celles proposée par défaut.
Évidemment, si tu ne peux pas désinstaller Gimp ou VLC sans tout péter, c'est que la distrib tient avec des bouts de ficelle, et tu peux légitimement affirmer ce que tu veux sur la qualité de cette distrib. Mais quand une distrib te dit "la distrib est basée sur tel et tel système", alors c'est quand même normal que tu ne puisses pas désinstaller ce système sans tout péter.
[^] # Re: Pas tous libre
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Je crois, quand tu remontes dans la discussion, qu’il dit justement n’avoir pas eu de message “ne faites pas ça”. Et il ne parle pas de GIMP ou VLC mais snapd qui lui a fait des frayeurs (et la solutions serait qu’il fallait d’abord virer les snaps) : dans ce cas, le patch est simple… (s’il y a des snaps, les retirer d’abord ou alors refuser+planter avec un message)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pas tous libre
Posté par barmic 🦦 . Évalué à 3.
Le grand manitou ne se permet pas de galvauder le libre pour autant, il parle de logiciels libres piégés.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas tous libre
Posté par Faya . Évalué à 4.
Admettons… Donc "Ubuntu est logiciel libre piég[é|eux]". Doit-on s'en satisfaire ? Surtout que ça s'éloigne de leur mission affichée :
"We work to the goal that every piece of software you could possibly need is available under a licence that gives you those freedoms." Pourquoi ne pas fournir le code du serveur sous licence libre ? Il ne fait pas partie de "every piece of software you could possibly need" ? Ça fait bien longtemps que je n'utilise plus cette distribution mais on peut tout de même relever l'incohérence surtout qu'elle reste parmi les plus populaires.
[^] # Re: Pas tous libre
Posté par barmic 🦦 . Évalué à 1.
Une partie non négligeable de mes commentaires consistent à dire qu'il faut se barrer de chez eux, hein ? Pousser des cris d'offrais comme s'ils avaient un monopole alors qu'il y a une miriade d'alternative, expliquer que oui mais au boulot on est obligé alors du coup la liberté des utilisateurs quand on force l'utilisateur à utiliser un logiciel ça me paraît être autrement plus problématique que leur truc qui ne fonctionne pas et qui est désactivable.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas tous libre
Posté par Marotte ⛧ . Évalué à 7. Dernière modification le 29 janvier 2024 à 21:07.
Surtout qu’un « serveur qui fait tourner des logiciels libres » ne présente aucune garantie, aucun droit de regard sur le paramétrage du logiciel en question.
Un « service » ne peut pas être libre. Donc un « système » (solution, logiciel, service, appelez-le comme voulvoule…) qui repose sur un composant dont le fonctionnement est à la discretion d’un tiers, ne peut pas être qualifié de libre.
Le code source de Gitlab est open-source, contrairement à celui de Github, pour autant on ne peut pas dire que gitlab.com soit libre.
En conséquence, que le code que le serveur fait tourner (du moins, prétend faire tourner) soit libre ou propriétaire, ne change pas grand chose quand à l’aspect libre ou non du service/système en question.
On compile tous nos logiciels libres sur des matériels dont le code bas niveau ne l’est pas…
[^] # Re: Pas tous libre
Posté par arnaudus . Évalué à 3. Dernière modification le 30 janvier 2024 à 09:54.
Avec la nuance pour snap qu'on sait que le serveur n'est pas libre et que le client est configuré pour ne se connecter qu'au serveur proprio. Je n'ai pas l'intention d'aller voir le code, mais je ne sais pas quel genre d'effort il faudrait pour bricoler le code GPL du client pour éventuellement aller se connecter à un serveur libre.
Mais sur le fond, complètement d'accord. Ce qui est important (et ce qu'on contrôle) est le code qui tourne sur sa machine. Ce qui tourne sur la machine des autres, c'est de la philosophie, on peut s'y intéresser ou non, mais ça n'est pas lié à la licence du code et aux libertés du logiciel libre.
[^] # Re: Pas tous libre
Posté par GNUtoo . Évalué à 1.
Une autre manière de voir les choses est de voir cette question de liberté du point de vue pratique: à ma connaissance toutes les forks D'Ubuntu qui veulent modifier les paquets pour une raison ou une autre (comme Trisquel et peut être la version Ubuntu de Mint aussi) n'ont pas essayé de re-créer un serveur snap. Après à l'époque ou ce genre de décisions ont été prises il n'y avait pas vraiment de serveur snap libre vraiment fonctionnel. Des considérations techniques ou éthiques (utilisations de resources VS écologie) peuvent aussi avoir fait partit des décisions.
Du coup la question ici est de savoir si de façon pratique c'est faisable d'utiliser kebe (https://github.com/freetocompute/kebe) qui à été mentionné dans ce thread. Si pour un fork ça prend moins de travail de repackager les snaps en deb, du coup l'intérèt du point de vue d'une distribution est limité.
A noter que même avec SNAP, si les logiciels distribués sont libres (comme VLC, Wesnoth, Libreoffice etc) ça reste sans doute plus simple de migrer à d'autres distributions avec les mêmes logiciels que si on utilise des logiciels pas libre à la base (par exemple avec Microsoft Office -> Libreoffice).
Il reste aussi le fait de pouvoir facilement distribuer un logiciel libre à pas mal de distributions différentes, et la la question est aussi de voir si on peut facilement changer l'URL du serveur snap et/ou comment facilement distribuer un client snap qui peut faire ça.
Après même sans ça ça peut valoir le coup car les compétences pour faire des snaps, les définitions de snaps, etc peuvent du coup être réutilisées facilement avec les versions libres, et des un client alternatifs voient le jour, ça pourrait être simple pour les distributions de migrer à ces clients.
Personnellement j'aimerais vraiment savoir s'il y'a des stores alternatifs qui sont en production car ça change la donne et ça permettrais de mettre à jour l'information sur ce sujet.
Après il y a aussi un autre problème de liberté: le store snap contient pas mal de logiciels pas libres, et en pratique, vu le contexte, je pense pas que ça aide le libre, au contraire. En plus je sait plus si c'est facile ou pas de filtrer les logiciels pas libre et quelle est vraiment la fiabilité de l'indication qui dit que c'est libre ou pas (si elle existe). Du coup ça peut compliquer les forks des repositories (notamment pour avoir des repositories 100% libres).
Un troisième problème est la manière de voir le problème de liberté des logiciels distribués. Par exemple il est possible de faire un logiciel libre qui installe des logiciels pas libres, ou qui dépend de services non libres, ou d'un composant non-libre qu'il télécharge automatiquement etc. Dans certains de ces cas la communauté du libre peut penser que le logiciel est libre tout en ayant en pratique des dépendances non libres qui piège les gens qui utilisent ce logiciel tout en freinant des réponses plus collectives car dans l'esprit collectif le logiciel est libre car les gens qui ne l'utilisent pas n'ont pas regardés de plus près.
Certains repositories prennent ce troisième aspect en considération comme ceux des distributions certifiés par la FSF (il y a une exceptions pour des licences comme cc-by-nd pour des données non fonctionnelles comme des graphiques de jeux), les repositories officiels de Emacs, les repository CRAN (même s'ils permettent quand même des licences non libres comme la licence Artistic V1 et sans doute une ou plusieurs licences creative commons).
[^] # Re: Pas tous libre
Posté par Astaoth . Évalué à 1.
Je ne sais pas trop. Nos distributions préférées sont dépendantes de leurs serveurs de dépôts. Rien n'indique que ce ne soient pas des Windows servers + IIS. Ca n'en fait pas pour autant des distributions non-libres.
De même, il y a un sacré nombre de projets libres dont le centre de distribution initial est uniquement Github, ce qui les rend dans une certaine mesure dépendant de cette plateforme. Est-ce que ca en fait des logiciels proprio du coup ?
Emacs le fait depuis 30 ans.
[^] # Re: Pas tous libre
Posté par Faya . Évalué à 8. Dernière modification le 30 janvier 2024 à 16:59.
Par contre elles permettent quasiment toutes de changer ce serveur et même de s'en faire un en local. C'est là la grosse différence. Tu ne peux pas te monter un serveur snap local. Quelqu'un a posté un lien vers ça mais ça n'a pas l'air bien vivant.
[^] # Re: Pas tous libre
Posté par Astaoth . Évalué à 3.
Les données des miroirs proviennent soit de d'autres miroirs, soit des dépôts officiels de la distribution. Dans le cas (improbable, certes) où les dépôts officiels tournent sous IIS, peu importe l'existence de d'autres miroirs, la distribution reste dépendante de serveurs proprio. Est-elle non libre dans ce cas ?
Emacs le fait depuis 30 ans.
[^] # Re: Pas tous libre
Posté par barmic 🦦 . Évalué à 1.
Non parce que même si elles le permettait pas ça resterait un logiciel libre. Chromium et vscodium sont libres.
Ce qui se passe quand tu as affaire à un service, c'est qu'à partir du moment où où tu ne contrôle pas la machine sur la quelle il tourne, tu es contraint de faire confiance.
Si tu t'intéresse aux libertés utilisateurs, tu dois t'intéresser aux données qui sont un angle mort du logiciel en tant que licence. L'intéropérabilité, la réversibilité, etc
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas tous libre
Posté par Astaoth . Évalué à 0.
Mais du coup, une distribution reste dépendante aux dépôts logiciels ou miroirs qui sont configurés dedans. Qui sont dans 99% des cas hors de portées des utilisateurs.
Pire encore, pour accéder à ces dépôts, les distributions sont dépendantes de serveurs DNS externes (même si on a son propre résolveur DNS local, il est soit récursif ou forwarder, donc transmet les requêtes à l'extérieur), aux infras de FAI, etc. Du coup il y a toujours une dépendance à des services hors de contrôle de l'utilisateur.
Je suis entièrement d'accord avec toi sur le fait que dans tout les cas, peut importe les licences, les services en dehors du contrôle de l'utilisateur, et c'est bien là un de mes propos. Cette dépendance ne rend pas les distributions moins libres, du coup pourquoi dans ce cas, cette intégration de Snap rend Ubuntu non-libre ?
Emacs le fait depuis 30 ans.
[^] # Re: Pas tous libre
Posté par barmic 🦦 . Évalué à 2.
C'est exactement ce que je dis. La licence du dépôt de snap ne rend pas Ubuntu pas libre.
C'est à la fois un vrai problème de vocabulaire où les gens ne savent pas dire que quelque chose pose problème autrement qu'en disant que c'est non libre. Même si ça n'a rien à voir.
Mais c'est aussi un problème du libre en tant que mouvement qui se satisfait du travail effectué il y a 35 ans autour du logiciel, mais qui ne questionne qu'à la marge la problématique de la liberté des utilisateurs dans un monde où les données ont pris une place prépondérante et où les logiciels deviennent des services.
Pour ce dernier point, il y a des réactions au cas par cas, mais pas de synthèse pour en tirer des règles comme ça a été fait avec les 4 libertés. Je n'ai personnellement aucun problème pour dire que la licence logiciel n'est pas forcément prépondérant pour la liberté des utilisateurs (ou dis autrement, on ne peut pas se contenter d'avoir un code libre pour que l'utilisateur soit respecté).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas tous libre
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
Un dépôt et un miroir c'est différent :-)
Pouvoir faire un miroir, c'est important pour des questions d'optimisation et de résilience.
Pouvoir avoir son propre serveur, ça permets d'avoir ses propres paquets, de fourchetter la distribution au besoin, par exemple si ladite distribution se mets à afficher des publicités ou si son éditeur l'arrête.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas tous libre
Posté par Astaoth . Évalué à 2.
Oui je vois, mais du coup avoir son propre dépôt n'enlève pas la dépendance aux dépôts de la distribution ;)
Emacs le fait depuis 30 ans.
[^] # Re: Pas tous libre
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Pour les paquets des distributions, c’est plus facile/simple/rapide de copier après avoir vérifier les signatures ; mais il est possible de tout recompiler soi-même dans son propre dépôt.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pas tous libre
Posté par Astaoth . Évalué à 2.
Sachant qu'une grosse partie des LL sont disponibles uniquement via Github, tu es du coup quand même dépendant d'un service propriétaire, même pour télécharger les tar.gz ou les codes sources. Est-ce que à cause de cette dépendance obligatoire à Github ces logiciels sont non-libres du coup ?
Emacs le fait depuis 30 ans.
[^] # Re: Pas tous libre
Posté par Marotte ⛧ . Évalué à 5. Dernière modification le 03 février 2024 à 22:13.
Bah non parce qu’à tout moment ils pourraient être hébergés ailleurs. Surtout avec Git, qui rend la chose triviale. Alors oui c’est sûr, les issues, la CI, qui sont lié à Github et pas purement Git, non. Mais le code source oui et c’est ce qui compte le plus. Et même pour la CI, ce qui aura été mis en place pour GitHub ne sera clairement pas à jeter totalement pour migrer ailleurs, même si en effet c’est du taf.
La plus « grosse » distribution GNU/Linux (ie: en terme d’ancienneté × CA annuel), est aujourd’hui dans les mains d’IBM, la grosse bleue… Une entreprise qui n’a pas hésité à récupérer sans vergogne le nom CentOS pour tenter d’appâter des clients sur un malentendu, je crois qu’il n’y a a pas d’expression plus adaptée pour décrire cette manœuvre d’
escroc habilemultinationale responsable financièrement.Et pour autant, rien ni personne n’aura pu empêcher la création de Alma Linux ou Rocky Linux à la seconde où CentOS a cessé d’être ce qu’elle était (en pratique à la sortie de RHEL/CentOS 8), à savoir une distribution downstream “bug for bug” de la RHEL.
Ceci pour devenir un appât à décideurs pressés, des décideurs qui même pour les moins pressés d’entre eux avaient juste un vague souvenir que leur ingé de l’époque Dédé, ce type bizarre mais néanmoins fort urbain, avait fait en sorte de faire tourner le logiciel MeuMeu sur Sentoèsse au lieu de Raidateentremachine, ce qui lui avait permis de présenter une économie de 36k/an au CODIR et susciter ainsi le respect des huiles les plus grasses…
[^] # Re: Pas tous libre
Posté par Astaoth . Évalué à 3.
Du coup c'est aussi le cas pour les snaps (du moins ceux de logiciels libres). Le code source étant libre, rien n'empêche de le récupérer, le build localement, générer un deb et l'installer avec un bon vieux dpkg. Et à tout moment, on peut virer l'intégration des snaps du système, et rajouter des dépôts pour avoir les .deb qu'on souhaite.
Avec ton explication sur en quoi dépendre de Github n'est pas un problème pour une distribution, je ne comprends pas en quoi l'intégration de snap dans Ubuntu en fait une distribution propriétaire. On est pas dans la situation d'un Windows update, qui est impossible à retirer de Windows (ou alors de facon non documenté), et distribuant des mises à jours obscures. Ca reste un composant qu'on peut retirer, la procédure est documenté officiellement, on peut toujours rajouter des dépôts customs, et les composants logiciels distribués ne sont pas obscures. On peut même toujours s'amuser à transformer son Ubuntu en Debian, il n'y a aucun verrouillage fait à ce niveau là (faut juste savoir utiliser apt/dpkg).
Emacs le fait depuis 30 ans.
[^] # Re: Pas tous libre
Posté par Faya . Évalué à 2.
DevNewton/Barmic ont fait le tour de la question "est-ce qu'Ubuntu est non-libre". Stallman dira qu'elle est libre mais "piégée".
Par contre je ne suis pas sûr que ces propos soient vrais concernant snap : "la procédure est documenté officiellement, on peut toujours rajouter des dépôts customs". La procédure est documentée sur divers sites mais pas chez Ubuntu à ma connaissance, donc pas officiellement. Et comme le serveur est non-libre, je ne crois pas non plus qu'on puisse en monter un "custom". Enfin pas encore. Et même si le client est libre, les url des serveurs de Canonical sont en dur dans le code. Donc on a un composant central dans la distro qui est libre mais fortement couplé à un logiciel non-libre (piégé donc) et qui ne permet pas, contrairement au fonctionnement habituel des gestionnaires de paquets, de l'utiliser avec son propre dépôt. Comme dit ailleurs :
[^] # Re: Pas tous libre
Posté par Astaoth . Évalué à 2.
Pour les dépôts customs, je parle de dépôts de .deb, pas de l'appstore snap. Tu peux toujours personnaliser ton /etc/apt/source.list.d, ca un dérivé de Debian. Tu peux d'ailleurs t'amuser à mettre les dépôts Debian et virer ceux de Canonical, t'amuser à réinstaller entièrement le système "in-place" et te retrouver avec un Debian à la place, c'est toujours techniquement possible.
Emacs le fait depuis 30 ans.
[^] # Re: Pas tous libre
Posté par Renault (site web personnel) . Évalué à 4.
Sachant que le travail qui a abouti à CentOS Stream a débuté avant qu'IBM n'entre en scène, c'est cocasse comme scénario.
Surtout qu'il y a aussi des bénéfices à ce changement notamment en terme d'ouverture du développement et des tests.
[^] # Re: Pas tous libre
Posté par barmic 🦦 . Évalué à 5.
Comme le montre le lien vers l'article de RMS plus haut il faut de toute manière être plus royaliste que le roi pour affirmer qu'un tel logiciel serait non libre.
Il faut arrêter de parler de libre/non libre pour des choses où ça n'a pas de sens. Ça empêche de s'intéresser correctement au sujet : les droits et les libertés des utilisateurs. Un service n'est pas libre. Il peut être propulsé par du logiciel libre, mais c'est loin d'être le seul souci et le point le plus important pour l'utilisateur.
Quelque soit la distribution, tu es contraint de faire confiance aux dépôts que tu utilise si tu ne les héberge pas toi-même. Tu ne peux pas vérifier grand sur leur fonctionnement (est-ce qu'ils conservent des méta données sur tes accès ? par exemple).
Parler de service libre et amalgamer ça avec la licence de logiciel ignore ce que l'on perds systématiquement quand on passe d'un logiciel qui s'exécute sur sa machine à un service que l'on accède sur une machine que l'on ne contrôle pas. Un logiciel a beau propulser un service, ce dernier est par nature très différents d'un logiciel de ce point de vu.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas tous libre
Posté par flan (site web personnel) . Évalué à 10.
Sans même me prononcer sur la licence, on ne peut pas avoir son propre dépôt ni même cloner l’officiel sur son propre réseau, ce qui est éliminatoire pour certains cas d’usage. Je trouve ça dommage :(
[^] # Re: Pas tous libre
Posté par shbrol . Évalué à 4.
Voila : un dépôt APT, je peux faire un mirroir sur mon propre réseau, il y a des outils pour ça, c'est prévu, c'est documenté. Avec Snap rien de tout cela, c'est une régression.
[^] # Re: Pas tous libre
Posté par Jean-Baptiste Faure . Évalué à 2.
Qu'est-ce qui empêche d'écrire la partie serveur pour construire son propre snapstore ? Snapd est libre, donc on sait comment il discute avec le serveur, donc on peut reproduire le serveur.
Cela dit je ne vois pas l'intérêt d'avoir son propre snapstore pour diffuser son logiciel en snap. Proposer des deb, comme Vivaldi par exemple, ça permet d'arroser Ubuntu et toutes ses variantes, y compris celles comme Mint qui refusent snap.
[^] # Re: Pas tous libre
Posté par devnewton 🍺 (site web personnel) . Évalué à 4. Dernière modification le 29 janvier 2024 à 14:33.
Rien (encore que je ne sais pas si Canonical serait coopératif avec une alternative libre), mais tout comme il a fallu des années pour avoir un java libre qui fonctionne, en attendant la situation actuelle est sapusaipalibre :-(
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas tous libre
Posté par David Delassus (site web personnel) . Évalué à 5. Dernière modification le 29 janvier 2024 à 14:38.
https://github.com/freetocompute/kebe
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Pas tous libre
Posté par flan (site web personnel) . Évalué à 3.
Bin si : snap ne peut pas être configuré pour pointer vers un autre serveur.
[^] # Re: Pas tous libre
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 01 février 2024 à 01:06.
Si puisque le client est libre et que tu peux le modifier.
[^] # Re: Pas tous libre
Posté par shbrol . Évalué à 0.
Et donc maintenir ton propre fork, parce que le patch ne sera jamais accepté upstream.
Brillant.
[^] # Re: Pas tous libre
Posté par barmic 🦦 . Évalué à 2.
Tu as un élément pour l'affirmer ou c'est ton imagination ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas tous libre
Posté par Psychofox (Mastodon) . Évalué à 3.
Notre propre flemme ou sens des priorités n'est pas le point déterminant pour savoir si du code est libre.
[^] # Re: Pas tous libre
Posté par Dring . Évalué à 3. Dernière modification le 02 février 2024 à 15:03.
J'ai l'impression que comme souvent, y'a un point de vocabulaire.
Quand on parle de Snap, on parle de l'écosystème, ou du client ?
Si on parle de l'écosystème, il n'est pas libre, puisque le serveur ne l'est pas et qu'il n'y a pas aujourd'hui d'alternative sérieuse (le repo GitHub indiqué ça et là n'a vu aucun commit sur 3 ans, et je n'ai entendu personne dire qu'il s'en servait).
Si on parle du client, il est libre puisqu'on a le code, et que la licence permet de le forker.
Maintenant, même si on avait le code source du pilote JDBC de Oracle, est-ce que pour autant on qualifierait "Oracle" de libre ? Même si Oracle publiait l'intégralité du protocole de sa base de données, avec une licence permissive autorisant les réimplémentations, commerciales ou non, est-ce qu'on qualifierait "Oracle" de libre ?
Ou on dirait "ben si c'est libre, il ne tient qu'à nous de réimplémenter la partie serveur ; on est juste des gros branleurs fainéants" ? J'ai un gros doute.
[^] # Re: Pas tous libre
Posté par barmic 🦦 . Évalué à 3.
Un écosystème n'a pas de licence, ça ne peux pas être libre.
C'est en ça que c'est une utilisation non pertinente de la notion de liberté logiciel.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas tous libre
Posté par Dring . Évalué à 2.
Ben c’est un peu la somme des composants, et de chaque licence applicable, qui va permettre de se prononcer.
Si je parle d’un système libre, on s’attend bien à ce que le kernel ET les logiciels rajoutés par dessus soient libres.
Si je parle d’un ordiphone libre je vais aussi regarder si les plans du matériel sont libres, si le microcode est libre.
La réponse n’est pas toujours évidente et peut évidemment être débattue, mais je pense qu’on a depuis longtemps collectivement décidé que si, on peut parler de libre pour un écosystème, une plateforme ou n’importe quoi d’autre qui est composé de plusieurs choses.
Après il faut s’entendre sur les frontières, sur ce qu’on inclus ou pas dans cet écosystème.
[^] # Re: Pas tous libre
Posté par barmic 🦦 . Évalué à 4.
Je ne suis pas d'accord. Libre a une signification. Si on la rend malléable, on ouvre la possibilité aux entreprises de faire du à peu près libre et de réutiliser le mot.
Tu parles de matériel pour le matériel on a pris soin de poser un nom et une définition sur ce qu'est l'Open Hardware.
Dire que ça n'a rien à voir avec la question de liberté n'est pas une négociation des problèmes. Il faut simplement correctement nommer les choses et prendre le temps d'évaluer les problèmes spécifiques. La licence du dépôt de snap n'est qu'un point parmi d'autres dans les problématiques qui sont soulevées et qui peuvent englober bien plus que snap.
Tu parles de se mettre d'accord, RMS lui même ne préfère pas prendre le risque de tordre le concept de libre pour cela. Du coup ce n'est pas un mot sur le quel "on" se serait mis d'accord, mais un groupe d'utilisateurs qui de leur côté ont choisi d'utiliser la notion pour autre chose que ce que c'est.
Le travail fait par RMS et la FSF sur la notion de libre a été primordial pour pouvoir correctement communiquer en créant des définitions claires qui permettent de savoir de quoi on parle précisément. Il n'y a pas de raison de ne pas le refaire si d'autres choses posent problèmes à la liberté des utilisateurs (comme ça a été fait pour le matériel).
Je passe peut-être pour le relou de service à discuter de sémantique mais on est de l'ordre de l'arbitraire sinon
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas tous libre
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 29 janvier 2024 à 16:12.
Flatpak est installable sur ubuntu (ou toute autre distro basée sur debian ou ubuntu) soit-dit en passant, tout comme snap est installable sur une fedora par exemple.
Au final on voit très bien que l'industrie semble privilégier flatpak et appimage au snap. Il n'y a que des applis cannonical qui ne sont distribuées que via snap. La partie est il me semble déjà perdue pour eux.
[^] # Re: Pas tous libre
Posté par barmic 🦦 . Évalué à 2.
Je suis mine de rien surpris qu'autant de logiciels sont disponibles en snap. Il n'est vraiment pas rare de le voir à côté des 2 autres.
Par contre effectivement si un logiciel est disponible en snap, il est disponible autrement alors que la contraposée n'est pas vraie.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas tous libre
Posté par EdLeH (site web personnel) . Évalué à 4.
Tu veux dire la réciproque.
[^] # Re: Pas tous libre
Posté par barmic 🦦 . Évalué à 2.
Effectivement
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas tous libre
Posté par flan (site web personnel) . Évalué à 5.
Tu peux certainement écrire ton propre serveur, mais tu ne peux pas configurer snap pour qu'il l'utilise.
Et le modèle actuel impose que ta machine soit connectée à internet pour la mettre à jour ou installer des logiciels. C'est tout simplement inacceptable dans certains cas.
# Qu'est-ce que tu attends pour virer snap ?
Posté par Jean-Baptiste Faure . Évalué à 8.
Je ne comprends pas pourquoi tu gardes un truc qui te pourrit la vie. Rien ne t'y oblige, il faut 3 minutes pour se débarrasser de snap. On trouve très facilement toutes les infos nécessaires sur le forum ubuntu-fr.
Pour ma part j'ai dû supprimer à nouveau snap lors du passage de 20.04 à 22.04 puisque la mise à niveau avait forcé la réinstallation de snap pour Firefox. Maintenant Firefox et Thunderbird sont installés directement dans ~/bin à partir des binaires fournis par Mozilla (je suis le seul utilisateur de la machine). Ça fonctionne sans problème et ils gèrent tous seuls leurs mises à jour.
[^] # Re: Qu'est-ce que tu attends pour virer snap ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 10.
Le problème est peut-être qu'on lui force la main ?
Non seulement ça veut passer en force mais en plus ça outrepasse sournoisement ton consentement comme les mises à jour fenêtre :(
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Qu'est-ce que tu attends pour virer snap ?
Posté par barmic 🦦 . Évalué à 4.
C'est probablement un problème plus grave que snap, mir ou la prochaine originalité d'ubuntu, non ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Qu'est-ce que tu attends pour virer snap ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Bien d’accord (et c’est un peu pour cela que je le mentionne, sans savoir si le journal utilise snap comme illustration de cette problématique ou si c’est juste de l’antisnap…) Après, même dans ce cas, on pourrait répondre que ce n’est pas grave parce-que l’on peut en arriver à bout… :/
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Qu'est-ce que tu attends pour virer snap ?
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 5.
Il y a une tripotée de distributions.Si celle-ci a de mauvaises manières, ce n'est pas difficile d'en changer !
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Qu'est-ce que tu attends pour virer snap ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Oui, aussi, tant que les autres distributions utilisant snap ne force pas Firefox en snap quand il désactive le truc (perso, ça fait un bail que je n’ai pas testé)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Qu'est-ce que tu attends pour virer snap ?
Posté par Jean-Baptiste Faure . Évalué à 3.
Ce n'est pas une histoire de consentement, la mise à niveau c'est juste l'installation de la version par défaut proposée par la distribution. J'avais désinstallé Firefox juste avant, il m'a remis le navigateur web par défaut, et dans Ubuntu 22.04, le navigateur web par défaut c'est Firefox en snap. S'il est question de consentement, c'est au moment du choix de la distribution.
Je trouve que Ubuntu qui cherche à promouvoir snap, ce n'est pas pire que Gnome qui m'a imposé l'installation d'evolution ou KDE qui m'imposerait Kmail alors que j'ai déjà Thunderbird.
Ce que j'aimerais, c'est une distribution qui me demanderait la liste des applications que je tiens à avoir et qui construirait le système strictement suffisant pour les faire fonctionner.
Si je réponds Thunderbird, Firefox, LibreOffice, gcc, pas besoin de me fourguer konqueror, kmail ou evolution. Après, si Gnome et KDE sont tellement monolithiques qu'enlever evolution ou kmail revient à tout enlever, c'est que Gnome et KDE ont un problème de conception ou que c'est fait exprès pour imposer leurs applications.
[^] # Re: Qu'est-ce que tu attends pour virer snap ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Je ne sais pas si cela a beaucoup changé, mais beaucoup de distributions proposaient une « installation avancée » qui te permettait de choisir certains paquet et retirer d’autres. C’est un poil plus long et plus chiant que quand tu choisi le bureau (DE) et la suite associée, mais plus gratifiant et tu as normalement gant à ta main.
Je ne sais pas si cela a changé (avec Plasma), mais il était bien possible de retirer Konqueror et Kmail tout en ayant installé KDE ; et il était possible de virer Evolution et d’autres tout en ayant choisi GNOME. Si tu as des besoins plus « avancés » il faut se taper le boulot du choix et ça peut se faire à la souris (c’est normalement loin l’époque où l’usage avancée passait presque forcément par la console.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Qu'est-ce que tu attends pour virer snap ?
Posté par Psychofox (Mastodon) . Évalué à 5.
La plupart des distributions proposent un installeur server ou netinstall pour lesquels tu choisis les paquets.
Et sur les rhel, fedora et dérivées tu peux généralement installer le desktop minimal de ton choix ou le desktop complet avec ses applis via
dnf group install.[^] # Re: Qu'est-ce que tu attends pour virer snap ?
Posté par Toufou (site web personnel) . Évalué à 1.
ou Windows qui imposerait IE ? :D On a vu le DoJ s’énerver pour moins que ça …
Je sais pas si le DoJ s'attaquerait au libre mais ça péterait : snap vs DoJ
c'est lundi tout est permis :)
# J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . Évalué à 10.
Du point de vue du développeur, si je veux distribuer mon application sous Windows, un ZIP ça suffit, mais idéalement je génère un installeur
*.msi.Pour Mac, je fais un
*.dmget basta.Pour Linux, je dois faire un
*.debpour chaque variante de Debian qui a décidé de nommer ses paquets différemment, un*.rpmpour chaque variante de RHEL, tester mon application sur chacune de ces distributions pour vérifier qu'elle est compatible avec les versions des libs présentes sur le système, etc.Ou alors, je ne distribue pas mon application sur Linux et tu te démerdes. A la limite je veux bien te filer un
*.tar.gzqui contient toutes les dépendances que tu va pouvoir extraire dans ton/opt.Ah, tiens, c'est plus ou moins ce que Snap et Flatpak font? Me fournir un environnement commun cross-distribution pour que je puisse distribuer mon application au plus grand nombre sans me soucier des millions de distributions Linux qui existent ? Bon ok, je veux bien faire un paquet Snap ou Flatpak en plus, mais c'est vraiment parce que je suis gentil hein.
Il y a 20 ans, les gens aimaient bien se plaindre que les développeurs d'applications ne distribuaient pas un port pour Linux.
Maintenant, les gens aiment se plaindre quand les développeurs le font mais pas avec leur solution favorite.
Je crois qu'en fait, les gens aiment juste se plaindre.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par Christie Poutrelle (site web personnel) . Évalué à 1.
Best comment ever.
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par Micromy (site web personnel) . Évalué à 7.
D'un côté je te comprends parfaitement : devoir passer du temps sur la création des packages de chaque distribution est un travail assez titanesque qu'un développeur seul ne peut assurer de manière exhaustive (sauf si c'est sa passion…).
De l'autre, pour beaucoup de logiciels bien implantés il me semblait que c'était plutôt les communautés des distributions qui se chargeaient du packaging, non?
D'autre part il existe une solution intermédiaire, Open Build Service, porté par OpenSuse. Ce n'est pas parfait, il faut, au moins pour les
.specdes RPM, rester très générique ou bien coller des exceptions à gogo, mais ça auto-construit des packages visant déjà un grand nombre des distributions basées sur des packages RPM ou DEB.[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . Évalué à 8. Dernière modification le 28 janvier 2024 à 14:35.
Oui mais ici, l'auteur du post accuse les développeurs de le forcer à utiliser Snap, quand il devrait accuser les mainteneurs des distributions de ne pas fournir de paquets.
Pardon, que dis-je. Il devrait plutôt respecter l'esprit du libre et faire le paquet lui même !
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par Charly.the.daemon . Évalué à 0.
J'avoue que, personnellement, me taper le boulot d'installation sur ma machine, ça peux sérieusement me casser les couilles, autant vous avez parfaitement raison quand à la non responsabilité du programmeur de me simplifier la vie si ce qu'il propose ne me convient pas 😅
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par devnewton 🍺 (site web personnel) . Évalué à 8.
Fait une appimage comme tous les devs beaux gosses qui sentent bon !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par flagos . Évalué à 6.
Je comprends pas la "hype" appimage. C'est juste un binaire que tu récupères sur internet, sans mise a jour, sans la sécurité de l'intermédiaire du repo.
C'est comme les .exe sur windows ce truc, c'est tellement le mal que comprends pas que ca puisse être sérieusement recommandé.
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . Évalué à 3.
Sur Windows, j'utilise Scoop
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Je ne sais pas quel est la sécurité apporté par "l'intermédiaire du repo", mais la mise à jour, c'est soit manuel, soit automatique
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 6.
Quand on voit le merdier que foutent les devs sous Fenêtre et Pomme… Savoir dév une appli est une chose, savoir l’intégrer proprement à un système est une autre chose qui ne s’improvise pas non plus.
Faux, archi faux. Contrairement aux systèmes fermés, on ne te demande pas de considérer « chaque variante de » mais de confier aux mainteneurs des distributions. Mais c’est trop dur, on veut refaire sa jungle façon Python (cf. dépêche récente sur le sujet.)
Sinon, au passage, il y en a qui se chargent de leur DEB/RPM en n’ayant qu’une seule variante générique ; et ce ne sont pas que de petits projets.
On n’est pas sorti de l’auberge si les gens qui disent aimer/défendre/faire du libre répandent de fausses informations.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Mais on ne te dit pas comment faire une appli qui soit "confiable" :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . Évalué à 5.
T'as des exemples concrets à donner ? Sous Windows, chacune de mes applications a son propre dossier dans lequel elle mes ses dépendances (le fameux
Program Filesou pour Scoop,$HOME/scoop/apps/<application>, ou pour Steam son dossiersteamapps).Je ne vois pas de quel merdier tu parles.
On ne parle pas d'intégration ici, mais de distribution. Parce que le problème d'intégration au système, il est autant présent sous Windows, Mac et les distributions Linux/BSD.
J'ai pas dit le contraire. Cependant les mainteneurs des distributions, ils ont que 2 bras et 24h dans une journée. Si ton application n'est pas populaire, tu peux courir pour que quelqu'un fasse le travail. Et si tu veux simplifier la vie de tes utilisateurs, tu vas donc devoir le faire toi même.
Mais comme c'est impossible de satisfaire tout le monde, tu va faire un paquet pour Ubuntu, un pour Fedora, et les autres vont devoir se démerder.
Le soucis que pose Snap et Flatpak, c'est qu'ils viennent s'ajouter au gestionnaire de paquets de la distribution (apt, yum, …). Cependant, il existe des distributions qui utilisent ces gestionnaires de paquets sans apt/yum/… Comme ElementaryOS en fait.
Quel est le problème ici ?
Comparer un gestionnaire de paquet qui embarque un runtime sur lequel les applications peuvent se reposer, peu importe la distribution, avec l'état de l'art de la gestion de paquet sous Python, c'est de la mauvaise foie. C'est comme comparer des patates et des tomates. C'est tout simplement pas la même chose, pas le même cas d'usage.
Montre les. Car déjà, rien qu'entre Debian et Ubuntu, les noms de paquets ne sont pas forcément les mêmes. Donc un DEB pour Debian ne va pas forcément fonctionner magiquement sous Ubuntu.
Il ne faut pas confondre "avis avec lequel je suis en désaccord" et "fausse information".
Aussi, je n'ai jamais dit aimer/défendre/faire du libre. Et je n'ai jamais dit le contraire non plus. Cela n'a rien à voir avec le débat. Et c'est qui "on" dans l'histoire ?
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Les noms peuvent varier quand c’est la distribution qui fait son packaging. C’est juste pour une meilleure factorisation (une distribution c’est une façon d’organiser et d’administrer le système, en plus du choix et du maintien des applis qui vont s’intégrer à cette philosophie.)
Mais quand tu fais toi même l’empaquetage, tu as ton découpage. Exemples
J’ai aussi eu le cas chez des clients où on faisait nos propres paquets. Et pour l’un où on avait clairement diverses version Ubuntu et Debian, on n’avait pas de variante pour chaque distribution. ;)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . Évalué à 2.
Pardonne mon ignorance mais, comment font-ils pour gérer les dépendances dont les noms diffèrent ?
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Je pense que le cas ne doit pas être si courant (en tout cas pour ce que j’ai constaté de ma petite expérience) : les noms des bibliothèques sont souvent les mêmes. Mais bonne question (ça doit arriver même si pas souvent, faut que je me renseigne.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
En mettant de côté les petits désagréments qui varient d’un programme à un autre, voici quelque chose de très sérieux qui fait couler assez d’encre numérique. https://news.ycombinator.com/item?id=38853058
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . Évalué à 3.
Le premier arbre de commentaire est à propos de
AppData,ProgramData,ProgramFiles, et le registre.Je considère ces dossiers comme l'équivalent Windows des dossier XDG.
Comme je l'ai dit, ces problèmes d'intégrations existent aussi sous Linux, pas mal d'applications ne respectent pas XDG et foutent tout et n'importe quoi dans le
$HOME.https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par Faya . Évalué à 5.
Objection !
«Connaissez-vous la “Pomate” ? Il s’agit d’un croisement naturel et sans OGM entre un plant de tomate et un plant de pomme de terre. En effet, la tomate (Solanum lycopersicum) ainsi que la pomme de terre (Solanum tuberosum) sont deux plantes de la même famille, les Solanacées. Il est donc tout à fait possible de créer un plant ou patates et tomates font racine commune !»
Ouais j'avais rien de plus intéressant à dire sur le sujet…
==>[][^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par madhatter (site web personnel) . Évalué à 1.
C'est intéressant, mais quel est l'intérêt ? Dommage que l'article ne dise rien à ce propos. Je suis curieux du coup.
There is no spoon...
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Avoir à la fois des tomates et des pommes de terre avec la même plante, évidemment.
Il y a un autre point commun entre les deux : un plant ne dure qu'une saison. Pour la tomate, c'est parce que c'est une plante annuelle : elle donne des fleurs, puis des fruits, puis finit par mourir. Pour la pomme de terre, c'est parce qu'on doit l'arracher pour récolter les tubercules.
Donc quitte à avoir une plante qui ne fera qu'une saison, autant qu'elle donne à la fois les deux, non ?
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Du coup on va se retrouver avec de la tomate dans les tartiflettes et raclettes ? Et si on veut faire des tomates farcis il faudra se farcir aussi la pomme ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par Krunch (site web personnel) . Évalué à 4.
Tu es au courant pour la fondue valaisanne ?
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Non, je connaissais pas ; je découvre par ton commentaire. Merci.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . Évalué à 4.
Deux de mes choses favorites dans la vie, réunie en un seul miracle ?
Merci.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 1.
On peut croiser la tomate avec la belladone pour faire une tomate milanaise. C'est très goûtu.
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par Nibel . Évalué à 4.
De l'intérêt de ArchLinux, AUR et des PKGBUILD.
N'importe qui peut faire ce travail et le rendre disponible sur la distribution. Un PKGBUILD est un fichier d'instruction relativement facile à écrire.
De nombreux paquets sur AUR sont issus de projets très peu populaires. Voir certains sont même utilisés uniquement par son mainteneur.
C'est la principale raison qui m'a fait passer à Arch à l'époque : une énorme disponibilité de paquets grâce à AUR.
Et clairement, en tant que joueur, je ne veux pas de container. Déjà parce que ça a tendance à ne pas fonctionner quand on a besoin de partager des process entre plusieurs applications (ou faut bidouiller) mais surtout parce que ça dégrade les performances en jeu. Et il n'est pas acceptable pour moi de sous-utiliser mon matériel.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Moi je veux bien
de la conteneurisationune sandbox sécurisée quand j'exécute un jeu, même au prix d'une perte de performance !Ce sont les seuls logiciels propriétaires que j'accepte d'utiliser, mais je n'ai aucune confiance dans les éditeurs pour ne pas faire n'importe quoi :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par Psychofox (Mastodon) . Évalué à 3.
C'est comme ça que les français sont décris dans le monde entier.
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par BAud (site web personnel) . Évalué à 2.
eh, faudrait pas oublier les bretons et les corses ! ;-)
bon ya aussi les parigos qui sont une classe à part :p
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par 桃白白 . Évalué à 1.
Et les dauphinois? On se plaint pas assez?
䨻
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 5.
vous êtes le gratin ;-p
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par Toufou (site web personnel) . Évalué à 6.
Et même qu'on pourrait imaginer des gens (appelons les des mainteneurs) qui s'amuseraient à prendre ça, découper en 200 fichiers ton /etc/monProg.conf (entre autres) et qui en ferait des paquets bien intégrés dans un ensemble qu'on appellerait une distribution.
Ah non c'est trop has been :)
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . Évalué à 2. Dernière modification le 29 janvier 2024 à 14:56.
Si tu lis tout les commentaires, tu verra que j'ai déjà évoqué cette idée de mainteneur qui créent le paquet pour leur distribution.
Tu verras aussi qu'il a été mentionné que ces derniers ne prendront le temps de le faire que pour les applications ayant déjà beaucoup d'utilisateurs. Tout le monde n'est pas Firefox ou vim.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par Toufou (site web personnel) . Évalué à 3. Dernière modification le 29 janvier 2024 à 15:01.
Du coup tout le monde n'a pas nécessairement besoin que ton soft soit distribué sur 50 plates formes différentes.
Donc le tgz ça le fait bien ou le bon vieux binaire non ? Plutôt qu'une dépendance à une usine a gaz et à un service à la politique étrange.
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . Évalué à 4.
Bah du coup on est d'accord. Tu répètes ce que j'ai dit.
En tant que développeur d'application qui n'a pas la popularité d'un Firefox ou vim, et donc personne d'autre que moi ne prendra le temps de faire les paquets, je vais pas me faire chier à distribuer sur 50 plateformes différentes et faire un tgz.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par Toufou (site web personnel) . Évalué à 2.
Oui j'ai bloqué sur le "je veux bien faire un paquet snap" et pas sur le "à la limite" préfixe… Ça m'apprendra à (bien) lire…
Mais au final je suis convaincu que le tgz c'est l'avenir car si tu fais du très bon boulot libre, ça s’empaquette tout seul sur toutes les plates formes.
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . Évalué à 4.
En plus, le tgz c'est déjà un paquet pour Slackware !
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par Toufou (site web personnel) . Évalué à 1.
Merde … démasqué
Bon spa vrai je suis devenu débianeux depuis 2003 ou 4 mais je ne renie pas mes origines ;)
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Tiens, c’est ce que fait deb : un tarball mais avec des bonus (les métadonnées et les scripts associés) et en demandant de se limiter à l’essentiel ;)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# s/snap/ubuntu
Posté par saltimbanque (site web personnel) . Évalué à 8.
En soi on peut décrier la techno snap, mais ton billet semble surtout critiquer ce que fait ta distro! Changements sous le capot, opacité…
Bref, il est grand temps de regarder ce qui se fait ailleurs. Par ex. Arch ne fait rien sans que l'utilisateur le demande et offre cependant une facilité d'usage surprenante. Pourquoi Ubuntu? Tu as peut être eu des raisons particulières?
# Défi
Posté par tisaac (Mastodon) . Évalué à 3.
Imagine moi avec un sourire en coin, l'œil taquin et néanmoins plein de bienveillance
Parce que tu vas nous faire croire que ce n'est pas le cas ?
Ah oui, c'est vrai. En même temps, comme ton avis semble être que tout changement emm***ent le monde…
mais bon, ce n'est pas grave, vu que
Allez, je te mets au défi d'écrire un journal avec au moins cinq changements positifs à tes yeux (au minimum qui n'emm***ent pas le monde) sur la dernière décennie dans le monde Linux
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Défi
Posté par octane . Évalué à 6.
(je parle pour moi, mais la question m'interpelle)
Bon allez, on va dire en vrac.
La stack non exécutable, ASLR/kASLR, les amélios de la glibc pour la détection des corruptions mémoires, les canairs.
Ou alors, l'autodétection du matériel à l'installation, le passage à rust, l'accélération 3D, la gestion du nouveau matos qui sort.
Ou encore l'utilisation de linux sur les smartphones, les supercalculateurs, l'embarqué.
Ah oui, et bien évidemment, systemd (HAHAHAHAHA, non).
En gros, ta question est quand même mal posée.. Quand tout se passe bien, les gens râlent moins. Quand il y a une friction, bin tu râles et c'est pas étonnant. Et souvent il y a un râlage plus gros quant tu penses qu'on t'impose le changement. Tu veux un gestionnaire de paquet? Bin y'a qu'a choisir. Tu veux un navigateur web, y'en a quinze millions. Une environnement de bureau? pareil! Un unix mais pas linux, bah vazy-mon-gars! Un autre système d'empaquetage que flatpak/snap? eh bah là, tu te rends compte que c'est compliqué de s'en passer (j'ai le même problème avec des softs sous docker). Tu as soit le choix de bouffer le gâteau, soit de tout faire toi même (oui, LL, sors toi les doigts du fiak, tout ça, je sais), et tout faire soi même, eh bin c'est long. Donc tu as deux solutions pénibles. Alors râler sur linuxfr ça détend.
[^] # Re: Défi
Posté par barmic 🦦 . Évalué à 0.
La majeure parti de ce dont tu parle ne consiste pas en des changements pour les utilisateurs donc parler de changements qui se sont bien passé me semble galvaudé.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Défi
Posté par octane . Évalué à 4.
euh, bin si (?)
ou alors passer de xfce4 à xfce-4.18, firefox 114 à 115, quand tu surfes, DNS (en udp) + HTTP (en TCP) sur de l'ipv4, à DoH (en TCP) et HTTPS (en quic) sur de l'ipv6, de debian 11 à debian 12, etc…
Y'a des changements, tout le temps. Et certains passent nickel. D'autres sont plus pénibles, c'est le sujet de ce journal. Et les changements qui sont imposés (ou qui paraissent l'être) sont encore plus pénibles.
[^] # Re: Défi
Posté par barmic 🦦 . Évalué à 1.
Qu'est-ce qui dans ASLR a impacté sensiblement (au sens où il a pu le ressentir) l'utilisateur ? Pareil pour la glibc ? Le passage en rust (qui reste encore très anecdotique) ?…
Je te met au défit de mettre quelqu'un sur firefox 90 et de lui faire trouver une différence avec la version 122 sans aller chercher le numéro de version (ou sans aller vérifier les change logs pour aller chercher le nouveau paramètre).
Si tu prend ceux que l'utilisateur ne voit pas c'est pas des changements pour lui. On ne peut pas résister à quelque chose que l'on ne connaît pas.
Ils le sont globalement tous. Même après 10 ans tu trouve encore des gens pour demander du support de python 2. Il y a un énorme effet boule de neige là dedans où s'il y a une forme de buzz contre un changement il va s'emplifier parce que tout le monde va y aller de son avis.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Ça dépend de l'usage
Posté par raspbeguy (site web personnel, Mastodon) . Évalué à 2.
Sur mon PC pro (coincé sous ubuntu) j'utilise Flatpak pour certains softs dont la version à jour est très différente de la version packagée sous Ubuntu (Dino, Element, etc…). Sur mon PC perso (Alpine donc avec musl au lieu de la glibc), uniquement pour les trucs closed source et qui nécessitent a fortiori la glibc (Steam). Tout le reste j'utilise les paquets de la distribution, et ce qui manque je le package moi-même.
Truc bien avec flatpak (et je ne vois pas de raisons que ça ne puisse pas être techniquement possible avec les paquets classiques, mais étrangement très peu de gestionnaires de paquets le proposent) c'est les installation au niveau utilisateur simple. Un utilisateur peut installer ce qu'il veut sans polluer le reste des utilisateurs.
Un gentil du net
[^] # Re: Ça dépend de l'usage
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Sous Android, il y a une distribution qui s'appelle Termux, qui utilise une version modifiée d'APT pour installer des trucs en tant qu'utilisateur.
[^] # Re: Ça dépend de l'usage
Posté par octane . Évalué à 4.
mais?
./configure --prefix=/home/chezmoi
# contre aussi, mais à contre-tendance de l'avenir
Posté par tkr . Évalué à 3.
je ne jure que par le gestionnaire de paquets par défaut de ma distro.
j'ai horreur de snap, et de flatpack, pourtant, ils ont l'air tellement en vogue :
et c'est pas comme si theregister passait chaque semaine dans la rubrique "liens" ;)
[^] # Re: contre aussi, mais à contre-tendance de l'avenir
Posté par David Delassus (site web personnel) . Évalué à 2.
ElementaryOS utilise Flatpak comme gestionnaire de paquet par défaut.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: contre aussi, mais à contre-tendance de l'avenir
Posté par Marotte ⛧ . Évalué à 3.
Il y a aussi cette approche : https://fedoraproject.org/coreos/ que je trouve plus intéressante, mais jamais testé.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.