Salut Journal,
Ça fait longtemps, hein ? Mais dis-moi, c'est quoi ce bordel ? Je m'absente 5 ans et je retrouve les distributions Ubuntu sans dessus dessous.
M'étant lassé de MacOS notamment à cause du foutoir qu'est l'installation de logiciels, heureux d'enfin retrouver apt-get, je découvre que, en fait, les distribs Linux sont devenus un foutoir sans nom.
Alors, certes, apt-get existe encore, mais il est régulièrement inaccessible car packagekit ou inattended-upgrade ont un lock. Certains logiciels n'apparaissent pas dans apt-get mais bien dans l'appstore graphique que j'ai compris être Snap (et qui, d'après un post sur le blog de Linux Mint, est un truc ultra fermé réservé à Ubuntu).
Le Snap en question semble être un truc de goret qui rend l'output de df illisible.
Je réalise que les devs GNOME, eux, développent un truc appelé Flatpak. J'ai tenté d'en installé un (pour avoir la dernière version de Geary), sans succès.
Bref, c'est le gros bordel. J'ai même eu le témpoignage d'utilisateurs qui avaient deux voire trois versions différentes du même logiciel sans comprendre comment ni pourquoi.
Comme je suis sous Regolith-Linux (une version de Ubuntu avec i3 et quelques composants GNOME par défaut), j'aimerais tout simplement virer Snap.
Sauf que…
J'ai plein de Snap installés par défaut pour les outils GNOME, les thèmes GTk et certains trucs appelés « core ». Du coup, je ne suis pas sûr des paquets deb que je devrais réinstaller après avoir viré snap ni même si cela fonctionnera vu que les versions sont peut-être complètement différentes.
Bref, comment tu fais, cher journal ? Oui, je sais, tu passes à Debian. Mais vu que Regolith ne fonctionne pas encore avec Debian, j'aimerais pour le moment éviter ça. Et je pense que le dev Regolith serait pas contre le fait de virer Snap de son install par défaut si on lui explique comment.
# Flatpak c'est bien
Posté par Christie Poutrelle (site web personnel) . Évalué à 8.
Ouais, mais c'est bien d'avoir une alternative pour installer un peu arbitrairement des paquets qui ne sont pas dans ta distro.
Perso j'utilise flatpak pour quelques applis, et c'est franchement pas mal ! Mis à part le cache qu'il faut vider à la main de temps en temps (ça peut monter à quelques gigas assez vite).
[^] # Re: Flatpak c'est bien
Posté par Anonyme . Évalué à 5.
J’utilise Flatpak depuis que j’ai lu le journal Canonical refait cavalier seul et annonce une nouvelle boutique logicielle centrée sur Snap et j’en suis plutôt content.
[^] # Re: Flatpak c'est bien
Posté par zurvan . Évalué à 3.
Idem, je n'ai pas trop compris le coup de gueule de Ploum. Pour ma part j'utilise LinuxMint, qui bien que dérivé d'Ubuntu, n'est pas centré sur Snap, du coup je pense que j'ai encore accès à apt-get pour la totalité des logiciels (utilisables sous Debian), et ça me convient bien comme ça.
Par contre, pour certains logiciels multimédia, il n'était pas toujours évident d'avoir la dernière version, ou une version de développement à jour.
Plutôt que de galérer (parfois), à tout compiler soi-même, quel plaisir d'avoir accès à des versions Flatpak, qui permettent d'utiliser immédiatement un logiciel fonctionnel.
Peut-être que flatpak ne fonctionne pas bien sur ubuntu vanilla (je ne vois pas trop pourquoi), mais sur linux mint 19 je n'ai eu aucun problème sur tous les flatpak téléchargés. En général je les copie dans /opt et créé un raccourci vers le bureau. Je peux comme ça utiliser les dernières versions de LMMS, Musescore, Krita…
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Flatpak c'est bien
Posté par zurvan . Évalué à 5.
j'ai dit une bêtise (que je ne peux pas corriger), c'est Appimage que j'ai utilisé, pas flatpak… du coup je présume que flatpak fonctionne un peu comme snap.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
# Bien d'accord !
Posté par redo_fr . Évalué à 10.
Je trouve aussi que ça (re)devient le foutoir, tous ces "installeurs" -_-'
Ça s'était un peu calmé ces derniers temps, encore des guerres de chapelle…
Personnellement, je les utilise aussi peu que possible et j'essaye toujours, (dans la mesure du possible !) de passer par les dépôts de la distribution.
Je pense que tout dépend de l'usage que l'on en a. En ce qui me concerne, fort peu de logiciels dont j'ai besoin nécessitent de passer par 'snap' ou 'flatpak', donc, comme le dit le type tombant du 50ème étage : "Pour l'instant, tout va bien…" :-)
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: Bien d'accord !
Posté par Christie Poutrelle (site web personnel) . Évalué à 2.
Je t'ai pertinenté parce que la dernière phrase m'a bien fait rire :)
Mais plus sérieusement, avoir une gestion de paquets compartimentée, indépendante de la distro, ça a pas mal d'avantages:
Après c'est pas magique, il y a aussi plein d'inconvénients (beaucoup sont techniques, j'imagine). Mais finalement, pour l'utilisateur final, si une solution émerge et dépasse les autres: avoir un store graphique sympa, et pouvoir installer plein de trucs sans connaître les base de l'utilisation de la ligne de commande d'APT ou autre Yum, et avoir en même temps un semblant de sécurité et l'assurance qu'un logiciel moisi ne va pas pourrir son appareil, c'est plutôt bien.
[^] # Re: Bien d'accord !
Posté par redo_fr . Évalué à 2.
Moi, ça me rappelle les horreurs des DLLs dans tous les sens…
Comme je le disais précédemment, je n'utilise pas snap et pourtant, c'est déjà le foutoir dans le répertoire :
Je ne suis pas descendu dans les sous-répertoires, mais tu retrouves toute l'arborescence système :
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: Bien d'accord !
Posté par Christie Poutrelle (site web personnel) . Évalué à 1.
Encore une fois un commentaire de quelqu'un qui rejette en bloc ce qu'il ne comprend pas, c'est une réaction de réactionnaire.
La structure des répertoire est entièrement gérée par l'outil (flatpak ou autre) et tient compte d'un très grand nombre de contraintes (partage des fichiers similaires, gestion de quoi appartient à qui, etc…) et ne répond pas à une structure logique écrite par un humain, mais dicté par une réflexion technique et codifiée.
Ce n'est pas parce que tu ne comprends pas ou n'est pas d'accord avec cette codification que ce n'est pas bien.
Si ça fonctionne et que tu ne constate pas de bugs, c'est que les gens qui ont écrit les algorithmes qui déterminent cette structure ne se sont pas trompés. Que tu le comprenne ou pas, ça correspond à une logique réfléchie et structurée pour laquelle ce n'est pas ton rôle de s’inquiéter.
[^] # Re: Bien d'accord !
Posté par freem . Évalué à 10.
Est-ce une réaction de réactionnaire de chercher a tendre vers un système que l'on est capable de dépanner, de maintenir, de modifier soi-même?
Parce qu'une des raisons qui font que je n'ai pas encore étudié systemd en détails, justement, c'est que je le trouve complexe, alors que j'ai l'impression (est-elle justifiée? C'est pas sûr) de pouvoir faire la même chose avec des outils plus simples, dont je suis même capable de comprendre le source (j'ai encore lu le source de
svaujourd'hui, me suis d'ailleurs demandé si c'était du C K&R…) chose utile quand un comportement n'est pas ou est mal documenté (un logiciel trop documenté s'expose au problème qu'il faut lire trop de trucs pour le juste mettre en place, l'équilibre n'est pas simple).J'ai parlé de systemd ici, mais la même chose peut s'appliquer a bien des technologies, et il est possible que ces nouveaux systèmes de paquets y aient leur place.
J'ai aussi parlé de tendre vers, parce que je suis conscient que ce n'est pas possible de comprendre la totalité de son système (le kernel linux m'est obscur, et même si je comprenait 100% des binaires de mon système, il resterait les firmwares, le code verilog/whatever qui programme un CPU s'il est en fait un FPGA, puis l'électronique… bref).
[^] # Re: Bien d'accord !
Posté par redo_fr . Évalué à 10. Dernière modification le 16 octobre 2019 à 21:49.
Avec 20 ans de métier spécialisé sur UNIX puis Linux, je pense maîtriser un peu les archi système… Fais un peu attention à qui tu t'adresses quand tu fais ce genre de remarques…
Je considère effectivement que c'est "pourri", si on a inventé les bibliothèques partagées, c'est justement pour éviter ces horreurs.
Je n'ai pas demandé à avoir snap installé sur mon système, ça c'est fait sans mon consentement. Résultat, je me retrouve avec des lib en double/triple/whatever qui me "bouffe" des giga de disque.
Ben je trouve pas que ce soit un progrès et non, je ne suis pas d'accord et j'ai le droit de le dire : TU trouves peut-être ça bien mais pas moi, n'impose pas TON point de vue aux autres, ou argumente plus sérieusement au lieu d'attaques "ad hominem".
Je me moque que ce soit géré ou pas par l'appli, je veux savoir exactement ce qui est installé sur mon système, par mes soins, et j'ai légitimement le droit de m'inquiéter de ce qui est installé sur ma machine, on est pas chez Apple.
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: Bien d'accord !
Posté par Renault (site web personnel) . Évalué à 10.
Il faut arrêter de croire que l'opinion qu'il a exprimé est personnel. Il évoque un vrai problème qui est aussi vieux que la notion de paquets sous Linux.
Il y a deux cas d'usages qui sont assez contradictoires et qui sont légitimes.
D'un côté le fonctionnement avec des dépôts, qui est assez élégant, cohérent et offre de nombreuses sources de mutualisation. Mais c'est peu flexible pour l'utilisateur qui veut un truc hors dépôt et nécessite beaucoup de travail pour s'assurer que la bibliothèque commune entre tous ces composants fonctionnent avec une version identique. Outre le travail de packaging en lui même qui reste une activité laborieuse et peu sexy.
De l'autre le fonctionnement des applications qui fournissent tout le nécessaire avec ou non possibilité d'une base commune (ce que Flatpak propose pour limiter la duplication des bibliothèques de base). Mais comme ces applications sont autonomes, ils sont très flexibles pour l'utilisateur qui peut installer la version qu'il veut, voire plusieurs en parallèle et qu'il est totalement indépendant du cycle de sa distribution. Pour le développeur de l'application c'est aussi plus facile de le distribuer à tout le monde sans prise de tête.
Bref, Flatpak / Snap / Autres répondent à de vrais besoins et ne sont pas le ressort d'opinion strictement personnelles tant ce besoin a été mainte fois exprimé depuis très longtemps. Nous avons seulement maintenant l'émergence de solutions matures pour le combler, tant mieux non ?
Après tout, tout le monde ne va pas migrer vers cela, au pire tu fondes ta distribution traditionnelle et voilà. Cela ne retire pas cette possibilité.
Ce genre de remarques (car c'est assez récurrent de lire ce type de propos) me fait croire que la notion même de distribution n'est pas comprise.
Une distribution, son rôle est justement de dire quelle application est fournie par défaut, quelle expérience utilisateur est souhaitée ou mise en avant, quelles sont les limites, des choix d'architecture ou techniques diverses, etc.
Donc oui en installant une distribution tu acceptes les choix qu'elle a fait pour toi, pour te simplifier la vie mais aussi aussi pour simplifier sa propre maintenance. Car si à l'installation d'une distribution tu dois valider la libc de référence, le système d'init utilisé, la pile audio par défaut, le noyau (bah oui, BSD existe aussi !), le shell par défaut, etc. tu vas perdre un temps immense et il est peu probable que le résultat soit stable car c'est difficile à maintenir. Puis honnêtement, ce serait indigeste, d'autant plus que nous ne sommes pas omniscients.
Fedora, Ubuntu, Debian, Suse, ArchLinux, Gentoo, etc. ont fait des choix à ce sujet très différents et ont donc leur raison d'être. Ubuntu et Fedora misent pour leur futur sur Flatpak et Snap pour différentes raisons. Pourquoi pas, c'est leur but de prendre ce genre de décisions. Si cela ne te plaît pas, soit tu t'adaptes (en supprimant manuellement après l'installation), soit tu prends une autre distribution qui est plus en phase avec tes envies. Les distributions ne te doivent rien de particulier, ils peuvent écouter tes remarques mais aussi ne pas en tenir compte.
[^] # Re: Bien d'accord !
Posté par zurvan . Évalué à 8. Dernière modification le 17 octobre 2019 à 09:32.
bah, mauvais système, changer de système hein ! Si tu es un sysadmin expérimenté, pourquoi n'utilises-tu pas plutôt Debian ? (ce n'est pas du sarcasme, juste une vraie question)
Linux Mint n'a pas Snap par défaut, du coup je n'ai pas de /snap chez moi.
La première fois que j'ai été confronté à Snap, c'était sur un boîtier nextcloud que j'avais commandé (disque dur + boîtier + ubuntu sur carte sd pour gérer l'ensemble), ça m'avait apparu assez opaque effectivement et compliqué en cas de plantage, et j'ai depuis réinstallé un système plus simple qui fonctionne toujours maintenant.
Je ne connais pas flatpak, par contre AppImage est complètement différent, il faut plus voir ça comme les .dmg chez Apple, c'est juste une application avec la plupart des bibliothèques intégrées dedans. Quand j'ai installé l'AppImage de Krita, ça m'a mis tout ce dont j'avais besoin sans installer les dépendances de KDE sur mon système.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Bien d'accord !
Posté par mahikeulbody . Évalué à 8. Dernière modification le 17 octobre 2019 à 10:41.
Je ne suis pas sûr de comprendre cette phrase tellement ça me semble gros : tu voudrais que ceux qui produisent une distribution te demandent ton consentement avant chacune de leur décision* ???
* Sachant qu'en principe ils publient des notes de version/mise à jour pour t'informer.
[^] # Re: Bien d'accord !
Posté par redo_fr . Évalué à 1.
Non, bien sûr :-)
Ce que je voulais dire par là c'est que ça a fait partie d'une mise à jour globale de ma distribution sans que je la vois passer.
Je suis c'est vrai, fautif sur ce point car j'aurais du consulter le changelog, ce que je n'ai pas pris le temps de faire.
Mais je trouve dommage d'imposer des installations "par défaut" avec cet outil alors qu'il existe un outil "standard" pour le faire (apt dans mon cas). Ça me donne vraiment l'impression que les responsables de la distribution veulent s'affranchir du circuit "normal" de validation, et je pense qu'au final, on va avoir à nouveau une fragmentation de l'écosystème.
Ce n'est pas forcément un mal, la diversité, bien au contraire, mais je trouve que c'est un manque de respect pour les mainteneurs : "
Les mecs, vous bossez pas assez vite, là, nous on est pressé, alors on va se passer de vos services".
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: Bien d'accord !
Posté par liberforce (site web personnel) . Évalué à 10. Dernière modification le 18 octobre 2019 à 11:54.
Expérience et compétence sont deux choses différentes.
Et cela a fonctionné, jusqu'à un certain point.
Voici un scénario typique:
Par conséquent, l'utilisateur est mécontent car:
De plus, les développeurs d'applications sont mécontents, car:
Enfin, le mainteneur est mécontent car:
Flatpack et Snap ont été créées pour résoudre ces problèmes:
Alors oui, ça prend plus de place sur le disque, mais tu n'es pas obligé d'installer toutes tes applications avec des systèmes de conteneurs de ce type. Toutefois, quand tu as besoin d'un logiciel non fourni par ta distribution, ça change la vie. Si tu suis le développement de certains logiciels en particulier, tu peux utiliser la version stable de ta distribution, et par dessus un Flatpak/Snap de la poignée de ces applications dont tu veux absolument la dernière version stable (si tu veux les dernières fonctionnalités), ou nightly (si tu veux tester au fil de l'eau et remonter des bugs dès qu'il apparaissent).
On s'oriente de plus en plus vers un système de base construit avec des packages pour ce qui est des composant système, avec au dessus des runtimes intermédiaires, et des applications contenairisées au-dessus.
Tu peux jeter un coup d'oeil à Fedora Silverblue ou à EndlessOS pour avoir un aperçu de ce futur pas si lointain.
Je doute qu'on t'ai mis le couteau sous la gorge. Tu as à un moment donné accepté le contrat de licence utilisateur à l'installation de ta distribution qui justement permet cela. Soit tu as directement installé une vesion utilisant snap, soit tu as donné ton consentement explicite autorisant les mises à jour et as migré vers une version utilisant snap.
Tout à fait. Mais l'espace disque est bon marché de nos jours, et bien que partager les ressources offre de meilleurs performances (accès cache, etc.), parfois cela est moins prioritaire qu'avoir une application qui fonctionne, ou avoir la dernière version d'application sans avoir à attendre 1 an. Tu n'es pas non plus obligé d'installer toutes tes applications de cette manière: on te donne le choix d'utiliser la version de ta distribution ou la version en conteneur.
En effet, même si Flatpak ou Snap est sur ton système, tu n'es pas obligé de l'utiliser.
[^] # Re: Bien d'accord !
Posté par BAud (site web personnel) . Évalué à 3.
c'est aussi ce qui fait que Mageia existe et fait :-)
bref, spa facile :/
La solution de facilité de l'espace disque vs une bonne séparation entre espace système / espace utilisateur est un problème topologique qui n'a pour l'instant pas de solution simple àmha.
docker, snap, flatplak sont pour moi des solutions transitoires qui prennent le problème d'un autre côté, vivement que la solution converge :-)
[^] # Re: Bien d'accord !
Posté par damaki . Évalué à 4.
Et de manière générale, ça répond à un vrai besoin en entreprise : gérer plein de versions d'applications sans instancier 20 VMs parce qu'il n'y a qu'une seule version de l'appli dispo dans la distro bidule.
C'est un besoin auquel Docker répond d'ailleurs en partie.
[^] # pas d'accord !
Posté par eric gerbier (site web personnel) . Évalué à 10.
Pour un administrateur, c'est une horreur : plus moyen d'avoir simplement la liste des logiciels installés, et donc une catastrophe au niveau sécurité : comment maintenir facilement à jour l'ordinateur ?
Pour moi, c'est un retour arrière comme au temps des tar.gz !
[^] # Re: pas d'accord !
Posté par gnumdk (site web personnel) . Évalué à 6.
Je déploie beaucoup d'applications via puppet et flatpak, en quoi tu ne peux plus avoir la liste des logiciels installés?
[^] # Re: pas d'accord !
Posté par ploum (site web personnel, Mastodon) . Évalué à 5.
c'est toujours possible mais c'est plus dur car tu dois vérifier ce qui est installé via apt, flatpak, snap. Et tu es toujours à la merci d'un gestionnaire de paquet que tu ne connais pas qui installerait des trucs en douce. Donc, oui, ça complique le travail d'administration pour le geek moyen comme moi qui veut savoir ce qu'il y'a sur sa machine (n'ayant pas suivi le bouzin, j'étais persuadé que snap était juste un format de repository qui installait ensuite via apt. C'est quand je me suis excité pour trouver un paquet que je savais installé sur ma machine et que j'ai fais, pour une autre raison, un df, que j'ai compris l'histoire.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: pas d'accord !
Posté par eric gerbier (site web personnel) . Évalué à 2.
Je veux une commande (rpm, apt , machintruc …) qui me remonte tous les logiciels installés avec leur version, quel que soit le mode d'installation.
[^] # Re: pas d'accord !
Posté par Christie Poutrelle (site web personnel) . Évalué à 8. Dernière modification le 16 octobre 2019 à 17:45.
Le but est complètement inverse à ce que tu dis, au contraire ça renforce la sécurité. Et comme le dit le commentaire juste en dessous du tiens, tous ces stores permettent de lister et gérer ce qui est installé.
Ça permet même d'avoir un système de base complètement readonly, ce qui est plutôt un gros plus pour la sécurité des postes de travail.
Les tar.gz tu les décompressais tous au même endroit, avec les shared libraries mélangées, un tar malencontreux qui remplaçait les fichiers d'un autre, etc… Avec des applis containerisées et des dépendances bien gérées, un outil comme flatpak permet justement d'éviter tous les pièges d'antan.
[^] # Re: pas d'accord !
Posté par eric gerbier (site web personnel) . Évalué à 5.
Je pense qu'il y a un problème d'échelle : autant ces outils me semble utilisable à titre personnel, autant à titre professionnel ( je gère un parc de plusieurs centaines de machines sous linux ), ça me parait dangereux, tant qu'il n'y aura pas d'outil d'administration global.
Par exemple, j'ai besoin que mon outil d'inventaire de parc remonte tous les logiciels installés.
[^] # Re: pas d'accord !
Posté par damaki . Évalué à 3.
Ça ressemble plutôt au nirvana pour les sysadmins.
C'est juste super relou de devoir toujours construire des paquets custom ou des installs pourries à la main depuis les sources, sans mise à jour facile. Alors faut pas se mentir, ça permet aussi d'avoir PHP 5.x installé jusqu'à la fin des temps sur un serveur, mais ça n'est pas la faute des snaps. Parce que oui, dans la vraie vie, on peut avoir besoin de Tomcat 6 ou 7 tournant sur la JVM 8 un serveur en Debian Buster. Déjà que l'OS soit à jour et que l'appli pourrie en question puisse être isolée du vrai filesystem, c'est un gros progrès.
[^] # Re: Bien d'accord !
Posté par Astaoth . Évalué à 4. Dernière modification le 16 octobre 2019 à 19:15.
Tu veux dire que ca permet en gros de séparer les applications du système, avec les applications qui ont leurs propres bibliothèques embarquées. Ca permet aussi du coup au développeurs de logiciels de se contenter de faire qu'un paquet de son truc, et de le distribuer directement, ou via des sites de téléchargements.
En fait, ca permet de faire un peu comme sous Windows quoi. A se demander pourquoi Microsoft est en train de développer son dépôt logiciel pour justement garder les dit logiciels à jours dans les dernières versions et éviter de devoir télécharger son appli depuis un site proposant un installeur foireux avec 50 cacas logiciels ajoutés en même temps au passage.
Vous m'excuserez de ne pas être convaincu et de préférer conserver l'installation de mes logiciels avec les paquets maintenus par ma distribution ;)
Dire qu'Ubuntu est censée être une distribution pour débutant facile et simple à prendre en main, et qu'à côté, Arch a la réputation d'être instable et de pouvoir se casser avec une simple mise à jour …
Emacs le fait depuis 30 ans.
[^] # Re: Bien d'accord !
Posté par Psychofox (Mastodon) . Évalué à 2.
tu confonds flatpak/snap et tarball.
Les flatpaks/snaps restent des packages avec une boite à outil quu te permet de les mettre à jour facilement.
La différence c'est qu'ils sont gérés indépendemment des distribs.
Après pour moi ça n'a d'intérêt que si ces paquets sont bien maintenus, et pas par des inconnus complets. Je ne me verrais pas installer un flatpak qui n'a pas été préparé par le projet upstream (tout comme je n'irais pas démarrer une image de container non gérée et maintenue activement par l'upstream.
[^] # Re: Bien d'accord !
Posté par freem . Évalué à 5.
Je pense que tu mets le doigt exactement ou est le problème: la maintenance.
Les distros stable type debian, doivent patcher les softs pour qu'ils soient compatibles entre eux et donc mériter la réputation de stabilité. La volonté de fourguer le dernier soft tout frais, ben, c'est pas compatible.
D'un côté, on veux un système a jour, a la pointe, et d'un autre on veut un système stable. C'est pas possible. Il faut des compromis, et je pense que le fait de pouvoir installer un soft pour un user est pas mal. C'est ce que proposent ces formats, mais du coup, je pense qu'en effet ils repartent en arrière en ignorant totalement la notion de système. Bon, j'ai un peu peu bu, je peux pas argumenter correctement, je peux vous laisser construire sur cette notion de format compromis (dans le sens "entre deux extrêmes" pas dans le sens "troué").
Perso, je pense qu'il serait plus efficace de recoder les outils type dpkg pour qu'ils soient utilisables sans etre root. Ca implique de retravailler l'archi systeme, de manièere autrement plus utile que merger /usr et / pour les bin & /sbin (qui en auraient pu être fusionnés avant en plus, m'enfin).
En tout cas, a la vôtre. et pardon pour les fautes de français. Le reste des fautes, je dirais ça a tête repôsés
[^] # Re: Bien d'accord !
Posté par Renault (site web personnel) . Évalué à 7.
Notons qu'une partie du problème vient du fait que tous les logiciels partagent des composants en commun avec une version fixée. La plupart des logiciels de ton système utilisent par exemple glibc qui a une version unique. Pourtant ces logiciels ont été développés et testés probablement avec des versions différentes les uns des autres. Les distributions en général doivent donc corriger ces écarts de compatibilités évidentes et corriger les problèmes que cela implique aussi.
C'est une des limites du modèle traditionnelle d'une distribution, qui est très gourmande aussi en travail humain pas forcément passionnant.
Pas du tout, au contraire même.
Une distribution classique pure dépôt à l'ancienne justement mélange tout. Firefox par exemple installé via les dépôts fait parti du système. Rien ne le différencie du reste. Mêmes répertoires d'installations, mêmes droits nécessaires pour l'installer ou le désinstaller, mêmes conséquences en cas de failles, même difficulté pour obtenir une version différente que celle proposée, etc.
Oui bien sûr, proposer Firefox par ce biais offre des avantages aussi, je ne le nie pas. Mais le choix Flatpak / Snap n'est pas absurde et cela répond aussi à de vrais besoins. Enfin on peut utiliser par exemple une distribution comme Ubuntu 18.04 LTS mais avoir en même temps son logiciel préféré à la dernière version (GIMP, Firefox, LibreOffice ou autres) car on en a besoin pour une fonctionnalité précise sans remettre en cause le reste qu'on apprécie. C'est aussi un confort et une flexibilité immense.
Nous avons affaire ici à des besoins qui nécessitent des solutions diverses et antagonistes sur le fond. Croire que seul un modèle (type dépôt) peut répondre à tout le monde de manière satisfaisante est une erreur. Du coup, pourquoi critiquer le fait que certains poussent pour des modèles différents ? Le modèle traditionnel ne peut pas disparaître : le code de tous ces logiciels sont libres, on pourra toujours créer une distribution à l'ancienne à la main.
[^] # Re: Bien d'accord !
Posté par freem . Évalué à 2.
Je suis d'accord, même bien bourré…. en soit, une distro devrais pas être l'autorité absolue. Chaque user devrais pouvoir installer un soft.
Enfin, s'il est permis par le ldap. Et quelle distro intègrre ça? Aucune. Windows le fait depuis au moins 10 ans, sorry. Je veux faire une distro pour ça, mais, c'est un bordel de fou, il me faudra au moins 2 voire 3 mois pour piger comment ça marche, les bases!
A la base, j'avais estimé a 2 semaines, mes chevillles sont encore un peu enflées, on dirait
[^] # Re: Bien d'accord !
Posté par eric gerbier (site web personnel) . Évalué à 0.
non !
un user ne devrait pas voir le droit d'installer un soft
c'est le role d'un admin (root)
Imagine si en entreprise tout le monde peut installer n'importe quoi …
[^] # Re: Bien d'accord !
Posté par AnthonyRabine (site web personnel) . Évalué à 1.
Mmh bizarre, je vois mal demander à un admin l'autorisation d'installer un logiciel quand on bosse en r&d. Je n'ai jamais travaillé dans de telles entreprises.
[^] # Re: Bien d'accord !
Posté par barmic 🦦 . Évalué à 5.
La boîte qui ne me laisse pas admin de ma machine, elle ne va pas me voir longtemps…
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Bien d'accord !
Posté par YBoy360 (site web personnel) . Évalué à 1. Dernière modification le 20 octobre 2019 à 14:07.
les 2 sont possible mon capitaine : on peut restreindre l'installation de Flatpak à l'utilisateur root, ou pas.
Maintenant aujourd'hui, les admin s'occupent de plein de choses (faire marcher les applications métier entre autres), et l'ordinateur pro est aussi utilisé dans le cadre privé. Vouloir restreindre l'installation de programme à l'admin va être frustrant… Nous installons tous les PC, et rien n'est installé par l'utilisateur final mais je ne pense pas que cela rende le réseau tellement plus sûr. Tout le monde cède irréversiblement vers les WeeChat, Skype et autres. Il faut des solutions qui contiennent ces applications.
Certes, il y a des failles, mais elle sont bien plus difficile à mettre en oeuvre, et bien peu sont finalement exploitées. Après il y a Meltdown et Spectre, mais le code exploitant ces failles est détectable facilement statiquement ou pendant leur exécution. Malgré des millions d'application, les stores restent relativement sûr.
Dans un autre genre : Est-il simple aujourd'hui d'acheter un Wifi en entreprise qui n'accède qu'a internet (et pas au réseau local) ? Rien que ça, c'est déjà une gageure et c'est une porte bien grande ouverte aux problèmes de sécurité.
[^] # Re: Bien d'accord !
Posté par freem . Évalué à 3.
Pardon, j'ai répondu qu'a une partie.
Le reste sera pas mieux, mais, tu m'as répondu, c'est de mon devoir de faire de meme.
C'est aussi ce qui fait leur robustesse.
Il est vrai que le travail manuel est énorme, mais c'est justement a mes yeux une des raisons majeures de confiance. Que l'on est en droit d'accorder a du privé, mais je préfère croire des passionnés. En vrai, ces gens m'ont permis d'apprendre a me méfier d'eux, au point de lire le code C de presque tout.
Pour faire ça, il faut sélectionner des logiciels simples a lire, et connaître son OS. Je sais sélectionnner, mais je maitrise encore mal mon OS, c'est pour ça que j'aime mon job: je peux galoper après des cerveaux si précis, avec un recul en plus, que, jamais je pourrais les rejoindre: soit je reste derrière, soit je les dépasserai. Si j'arrive a grimper leurs épaules.
[^] # Re: Bien d'accord !
Posté par ZeroHeure (site web personnel) . Évalué à 3.
Génial !
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Bien d'accord !
Posté par Olivier . Évalué à 2.
C’est pourtant ce que Windows offre. Mon système est à jour. Mes applis sont à jour. C’est stable. Je peux avoir plusieurs versions du même soft sans prise de tête interminable.
La dernière fois que j’ai voulu compiler LibreOffice sur Linux, il fallait installer GCC7, et GCC7 voulait désinstaller quasiment tous les paquets de mon bureau. Génial… Il a fallu que j’installe une autre distro.
C’est vraiment pénible ce sac de nœuds sans fin des dépendances. Sans compter les packageurs qui font n’importe quoi avec les dépendances requises par les logiciels.
[^] # Re: Bien d'accord !
Posté par Kerro . Évalué à 4.
Autant le reste je suis d'accord, autant ça ce n'est pas gagné.
[^] # Re: Bien d'accord !
Posté par Olivier . Évalué à 3.
Beaucoup de logiciels existent en version portable. C’est très fréquent.
Et il y a aussi https://portableapps.com/.
À chaque fois que j’ai cherché une appli en version portable, je l’ai trouvée.
C’est comme ça que je fait cohabiter pas mal de versions de LibreOffice.
[^] # Re: Bien d'accord !
Posté par BAud (site web personnel) . Évalué à 3.
ça ne fonctionne que sous windows, pas mac OSX, pas *BSD ni aucune distro Linux ; ça reste un peu limité :/
mais oui, c'est utile pour survivre en environnement hostile :-)
mon préféré : git-bash qui me redonne un vrai terminal utilisable :D
[^] # Re: Bien d'accord !
Posté par Astaoth . Évalué à 2.
Donc t'es en train de dire que Flatpak va utiliser mes bibliothèques partagées ? Qu'on pourra en installer que depuis des dépôts officiels, avec clefs de validation des paquets, comme les paquets logiciels classiques des distros et que ca ne sera pas possible de les mettre en téléchargement depuis n'importe quel site ? Qu'il sera impossible de repackager un Flatpak pour lui inclure des trucs du genre Avast pour Linux ou un popup publicitaire ?
Emacs le fait depuis 30 ans.
[^] # Re: Bien d'accord !
Posté par freem . Évalué à 1.
Pardone la poche que je suis, mais, tel que je lis, il dit juste:
On a une nouvelle techno qui ne garanti rien mais permets à l'utilisateur de faire de la merde et d'installer des virus vu que le bin n'est jamais vérifié.
MAIS LE PUTAIN DE BON POINT QUI ÉCRASE TOUT MAUVAIS SYMPTOME, C'EST QUE LE TRUC EST A JOUR… j'ai mis assez de caps lock la? J'ai un doute….
[^] # Re: Bien d'accord !
Posté par Renault (site web personnel) . Évalué à 7.
Tu devrais arrêter de troller en étant bourré, franchement…
Tout d'abord Flatpak (je ne parle pas des autres) apporte une isolation du processus pour limiter les possibilités de nuisance au maximum. C'est sans doute plus sûr de se servir de Flatpak que d'utiliser un logiciel mal codé mais fourni par ta distribution.
Ensuite, on oublie qu'il y a des technos type PPA, Copr, etc. pour installer des dépôts tiers pour installer des trucs que sa distribution ne fournie pas. Ces dépôts sont non sûrs également, pourtant il ne semble pas que leur existence soit remise en question.
Enfin, rien n'empêche de distribuer les Flatpak au sein d'un dépôt. Ta distribution pourrait même en avoir une ! C'est d'ailleurs ce que fait Flathub, et Fedora projette de le faire aussi à terme. Ce qui permet de gérer les mises à jour, mais aussi de n'installer que les Flatpak de confiance, etc.
[^] # Re: Bien d'accord !
Posté par aiolos . Évalué à 5.
Ben pour le coup, les PPA, j'ai toujours trouvé que c'était une horreur absolue : chaque PPA que tu installes, tu dois lui faire une confiance presque absolue. Le truc a le pouvoir de te remplacer des binaires dans ton système sans que tu ais un vrai contrôle. Et y'a un milliard de PPA mal maintenu, pas un mec pas bien identifié qui sont recommandés sur un demi million de forums…
Franchement, je pense que ce truc devrait disparaitre !
[^] # Re: Bien d'accord !
Posté par barmic 🦦 . Évalué à 1.
C'est une question d'implémentation si c'est le cas (je ne sais pas, je n'utilise pas). Avec un peu de pinning, ça n'arrivera pas. Ils pourront toujours installer un paquet que tu n'a pas dans ta distribution, mais c'est justement ce qui leur est demandé.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Bien d'accord !
Posté par Astaoth . Évalué à 1. Dernière modification le 17 octobre 2019 à 20:11.
Il s'avère que les moyens d'isolations sont moins étanches qu'on peut le croire. Les seules isolations que je n'ai pas encore vu se faire percer sont à minima de l'ordre de la VM (coucou Qubes OS). De plus, l'isolation ne protège pas contre les ajouts de popups publicitaires par exemple, de bout de code de télémétrie, etc. En fait, l'isolation n'est pas un processus magique rendant d'un coup un logiciel saint, mais plutôt une sécurité (pouvant être percée) pour éviter que le dit logiciel n'ait accès à tout. Cependant, le dit logiciel peut toujours faire sa vie.
Je n'ai pas entendu parler d'une telle technologie dans la quinzaine de distribution que j'utilise, ou que j'ai utilisé. Généralement lorsqu'on cherche la façon d'ajouter un dépôt, on a le droit sur le wiki de la distro (si elle est généraliste) les dangers d'ajouter un dépôt externe Mais bon, j'ai besoin de faire ce genre de chose qu'en entreprise, pour des logiciels déjà éprouvés, qui proposent des dépôts séparés pour des versions de bibliothèques (mais s'intégrant sans conflits).
Bon aller, je vais arrêter de faire le malin et bien accepter que tu parles d'un truc dispo que sous une seule distribution, dont régulièrement les choix technologiques sont remis en question (Mir, upstart, Unity, les PPA et d'autres). Bah justement, au cours de ces 10 dernières années, j'ai entendu pas mal de monde râler sur le fonctionnement des PPA et sur leur existence même.
Par contre, jamais entendu parler de Copr ou autre, ca doit être des trucs pas très répandus.
Mes distributions préférées n'ont pas de dépôts Flatpak. Mais bon, si chaque distribution se met à gérer et maintenir son propre dépôt Flatpak, ca revient un peu à avoir des dépôts logiciels classiques, juste qu'on pourra utiliser ceux des autres distributions plus facilement (si il n'y a pas une incompatibilité qui apparaisse, par exemple avec une nouvelle version ou avec un fork, ca ne sera pas la première fois).
Emacs le fait depuis 30 ans.
[^] # Re: Bien d'accord !
Posté par claudex . Évalué à 5.
Pourtant, ça se fait régulièrement percé, rien qu'avec meltdown. Mais aussi avec des failles spécifiques.
https://www.cvedetails.com/cve/CVE-2018-19966/
https://www.cvedetails.com/cve/CVE-2017-15597/
https://www.cvedetails.com/cve/CVE-2019-17346/
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3456
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14821
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10901
https://www.cvedetails.com/cve/CVE-2019-5519/
https://www.cvedetails.com/cve/CVE-2019-5518/
https://www.cvedetails.com/cve/CVE-2017-4924/
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Bien d'accord !
Posté par Astaoth . Évalué à 2.
Awi tiens, j'avais oublié celle là.
Et c'est pas parce que je ne les vois pas percé que ca n'arrive pas x). La seule isolation qu'on connaisse d'à peu prêt sûr, c'est une machine physique complètement isolée des autres (et avec quelques particularités matériels spécifiques).
Bon sinon, pour ceux qui moinssent, j'aimerais bien continuer la discussion avec vous, je suis ouvert à vos opinions :).
Emacs le fait depuis 30 ans.
[^] # Re: Bien d'accord !
Posté par Anonyme . Évalué à 2.
Ouais, enfin Metldown ça compte pas, ça touche absolument tout.
[^] # Re: Bien d'accord !
Posté par Renault (site web personnel) . Évalué à 6.
Personne n'a dit que l'isolation des processus étaient une sécurité parfaite. Il y a des trous ou des limites, on le sait. Mais entre ne pas avoir d'isolation du tout et en avoir une qui présente des limites ou failles, le second restera toujours préférable au premier.
Oui, et ? Ta distribution non plus ne te protège pas là dessus. Les mainteneurs ne sont pas des auditeurs de code ou de projets, ils peuvent passer à côté de tas de choses qu'ils jugeraient inacceptables. Et ils peuvent laisser aussi volontairement les éléments de télémétries car cela a aussi un intérêt. Genre la version de Firefox proposée par toutes les grandes distributions Linux dispose d'éléments de télémétrie. Est-ce choquant ? Non.
Puis si tu n'aimes pas la pub ajoutée par l'éditeur du Flatpak, soit tu trouves un autre fournisseur qui ne l'ajoute pas. Soit, parce que le code est libre, tu le fais toi même.
C'est juste le PPA de Fedora, une broutille quoi. Et je précise que l'infrastructure Copr est maintenu par Fedora elle même : elle fournie de quoi créer facilement des dépôts personnels pour ajouter ou tester des paquets qui ne font pas sens dans les dépôts officiels.
Tu es d'assez mauvaise foi en ignorant l'usage massif de petits dépôts personnels pour contourner les limites des dépôts à l'ancienne maintenus par les distributions.
Et ? je dis juste qu'une distribution peut le faire ou que quiconque peut le faire. Flathub le fait par exemple. Cela permet de résoudre la critique récurrente quant à l'absence de dépôts : ici tu as un tiers de confiance qui gère / ajoute des paquets sous certaines conditions, tu peux facilement avoir accès à tous les programmes qu'il propose et la mise à jour est automatique et centralisé. De quoi réduire l'écart entre les deux mondes.
Le but n'est pas que chaque distribution le fasse, mais que cela est une possibilité. Qui n'est en tout cas pas plus contraignante que la situation actuelle.
Et cela a aussi de l'intérêt. Si un utilisateur d'Ubuntu veut la version de LibreOffice plus récente proposée par Fedora, il pourra facilement le faire. Si un utilisateur de Fedora veut une version plus stable de Firefox proposée par Debian (ESR + correctifs perso), il pourrait le faire aussi facilement. Cela découple en fait la base du système et les applications haut niveau. Cette flexibilité est très intéressante que ce soit en contexte professionnelle comme personnelle.
Il suffit de parcourir les forums des différentes distros pour voir que les utilisateurs cherchent toujours de contourner les dépôts officiels pour faire à la Windows. Et pour des raisons légitimes. Donc pourquoi rejeter toutes les solutions qui permettent de les satisfaire ? Leur besoin n'est pas légitime ?
D'autant que Flatpak ou Snap ne remet pas en question la possibilité de faire une distribution comme aujourd'hui. Le code de tous les projets restent libres, faire des paquets comme aujourd'hui sera toujours possible même si Flatpak et Snap s'imposent.
[^] # Re: Bien d'accord !
Posté par Astaoth . Évalué à 2.
Rien à voir avec mon propos, je ne parle pas d'audit de l'application mais de vecteurs de distribution de logiciels.
Les paquets présents dans mes distributions habituels ont reçu une validation pour l'intégration aux dépôts. Ca implique donc de vérifier que le logiciel ne balance pas 50 popup à l'utilisation (sinon il dégage) ou n'installe pas d'autres logiciel en même temps (sinon il dégage). Ce qu'un Flatpak distribué par un site random n'assure pas du tout en fait.
Pour ce qui est de la télémétrie de Firefox, elle est désactivable. Pareil pour la télémétrie de la distribution si il y en a. Par contre, un Flatpak distribué par un site random peut avoir une partie de télémétrie ajouté par le dit site sans que l'utilisateur en soit averti ni qu'elle soit désactivable. Certes un logiciel peut le faire, alors autant ne pas multiplier les vecteurs d'ajout d'outils de télémétries.
Autrement dans mon propos, je ne parle pas de la fiabilité du logiciel installé, que ce soit un Flatpak ou un paquet logiciel de la distribution le problème reste le même, mais de la fiabilité du media d'installation. J'ai bien plus confiance dans un paquet logiciel fourni par les dépôts officiels de ma distribution que dans un Flatpak distribué par n'importe quel site au hasard trouvé sur le web. Tu me diras que j'ai qu'à passer par un site "sérieux" de Flatpak (j'en connais aucun, j'utilise pas ce format), mais c'est la réponse trop facile à faire, je reste un utilisateur averti. Par contre pour un utilisateur non averti qui a fait le choix de ne pas utiliser Windows ou d'utiliser Linux pour diverses raisons pas forcément techniques, il y a un risque loin d'être négligeable de tomber sur un site ayant repackagé les Flatpaks de façon malveillante. Les dépôts officiels d'une distribution servent justement entre autre à fournir des logiciels empackagés d'une façon honnête et non malveillante. Un site lié à aucune distribution fourni des Flatpaks dans le but qu'il souhaite, tout comme les sites de logiciels pour Windows le font.
Ou alors parce que je suis libre de mes choix je vais voir ailleurs. À un moment faut voir ce que vous voulez aussi. Avec ce genre de remarque, faut pas s'étonner qu'on dépasse pas les 5% de parts de marchés, toutes distributions confondues, dans la partie grand publique.
Autrement, ca serait avec plaisir que j'accepterai tes dons pour pouvoir suivre une formation me permettant de "faire moi même". Je les attends même avec impatience.
J'utilise Fedora au boulot, jamais entendu parlé de Copr. C'est toujours bon à connaître pour la culture, si jamais un des utilisateurs (plutôt des devs) que j'ai aidé à passer sous Fedora me pose la question.
Que ca soit sous ArchLinux (et ses dérivés), Debian (et ses dérivés), FreeBSD (et ses dérivés), Fedora, CentOS ou Gentoo (et Sabayon), je n'ai jamais eu besoin d'utiliser de petit dépôt persos en fait. Les seuls dépôts externes que j'ai ajouté sont ceux proposés par des éditeurs d'applis serveurs, pour CentOS. Et pourtant sur mon ordi perso (actuellement sur Arch c'est il est passé sous pleins d'autres distros) je joue aux JV, je fais de la photo, je joue avec mes systèmes, j'utilise du hardware exotique (lecteur de smartcard, hardware de gaming, interface neurale), bref j'ai un rapport avec mes OS assez large d'une façon générale. Mais ca vient peut-être du fait que j'ai pas hésité à changer de distribution pour aller vers celle qui me plaisait le plus et collait le plus à mes usages. Après tout, on ne va pas sur une Debian Stable si on souhaite avoir les dernières versions des logiciels.
Tu vas me dire que oui, je suis un utilisateur averti, je fais de mon cas une généralité, blablabla. Si tu veux on peut étendre ce propos à mon entourage composé de devs qui ne connaissent rien au fonctionnement d'un OS, mais aussi de néophytes, de gens qui l'utilisent au travail mais sans forcément volonté de leur part, de gens qui ont voulu quitter Windows par lassitude, de gens pas forcément jeune dans ce dernier cas. Bah en fait, ils n'ont pas besoin non plus d'utiliser de dépôts persos à partir du moment où la distribution de base est bien choisie.
Tout à fait, n'importe qui peut faire un dépôt de Flatpak, dans des buts divers et variés. Comme la distribution massive d'un logiciel en plus intégré dans tout les Flatpaks proposés, de adware, ou d'outils de télémétries. Cf plus haut dans ce commentaire.
Quand on parle de découpler la partie système et applicative, j'ai très fortement envie de dire pour faire un peu comme sous FreeBSD quoi ;). Mais je m'en abstiendrais parce que clairement la séparation entre les deux est bien plus importante, ca serait plutôt comme ce que permet de faire Windows ou MacOS X (la dernière fois que je m'en suis servi date un peu cela dit).
Cette séparation est tout à fait louable, à partir du moment où l'utilisateur a un gestionnaire de Flatpak pour les garder à jour. Sinon on arrive dans une situation similaire à Windows ou MacOS, qui est un peu un des points les plus importants en sécurité informatique : la non installation des mises à jours de sécurités des applications.
Par contre, présenter deux gestionnaires de paquets à un utilisateur non averti est un excellent moyen de le perdre. C'est comme ca qu'on se retrouve avec, par exemple, deux versions de LibreOffice différentes installés, que l'utilisateur pense avoir installé une version plus récente avec un Flatpak mais se retrouve à ouvrir ses documents avec la version de sa distribution, et finalement se retrouve à porter un jugement négatif sur LibreOffice, sa distribution, voir l'écosystème GNU/Linux en général dans le pire des cas.
D'ailleurs ca me fait penser à une question un peu biscornue : est-ce qu'un programme installé en Flatpak peut se lancer directement en ligne de commande comme un programme installé par le gestionnaire de paquet, et si oui, comment ca se passe quand les deux versions sont présentes ?
Emacs le fait depuis 30 ans.
[^] # Re: Bien d'accord !
Posté par barmic 🦦 . Évalué à 1.
Je n'ai jamais vu de chartes des paquets d'une distribution linux. Si tu en as une sous la main, ça m'intéresse. On peut considérer la définition du logiciel libre selon Debian, mais ça me paraît assez loin de ce dont tu parle.
Tu amalgame une techno avec son usage. FP peut travailler sans dépôt, c'est potentiellement gênant effectivement. Ça fait perdurer des usages dangereux comme on l'a déjà aujourd'hui (en particulier via
curl ... | sh). Mais il donne la possibilité de faire de la distribution logiciel hors distribution linux. Tu peux voir la fondation Apache créer le sien par exemple pareil pour gnu. Les innombrables projets qui créent leur propre dépôt debian (mongo, docker, chrome,…) peuvent faire un travail plus universel et ne pas laisser sur le carreau les utilisateurs de distributions trop exotiques. Enfin ça peut être utile pour des choses comme debian-multimédia.La multitude de gestionnaire de paquets elle est d'abord du fait des distributions linux qui chacune se sent obligée de montrer qu'elle est différente. Ensuite là il y a une solution concerté qui a une chance et vocation à remplacer toutes les méthodes à l'arrache que l'on a aujourd'hui.
FP ne fait pas le café, il ne fait pas revenir l'être aimé, il est juste une proposition pour passer d'une situation pourrie à un peu moins mieux.
Et mon dieu, c'est clair qu'il n'est pas parfait…
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Bien d'accord !
Posté par Astaoth . Évalué à 2.
Je n'ai jamais parlé de charte, mais de paquets qui dégagent si on constate des fonctionnements clairement malveillant. Ca arrive régulièrement, suffit de suivre un peu les évolutions des dépôts.
En fonction de la distribution il n'y a d'ailleurs pas forcément besoin de charte, ca peut se faire mécaniquement. Par exemple pour Arch, l'installation des nouveaux programmes, non-vérifiés par les mainteneurs de paquets, passe par AUR. Dans AUR, il existe un système de vote et de commentaires de paquets.
Pour Debian, avant qu'un paquet se retrouve dans Stable, il doit satisfaire différents critères de stabilités. Autrement, il aura du mal à passer de Sid à Unstable, et de Unstable à Stable.
Pour Red Hat et ses dérivés, les dépôts sont maintenus par Red Hat qui a tout intérêt à avoir des paquets cleans si ils ne souhaitent pas perdre de PdM.
Non, à la base je fais juste remarquer que Flatpak permet exactement les mêmes dérives que les sites d'installations de logiciels Windows. Après on me vend de la sécurité, je fais remarquer que cette dite sécurité ne pare en rien les dérives en question, ce à quoi on me fait remarquer que la sécurité n'est pas l'objet de Flatpak, que si je veux mieux j'ai qu'à faire et que je fais des amalgame. Faudrait choisir un peu, hein :)
Non, les gestionnaires de paquets ne sont pas des solutions à l'arrache (dire ca c'est un peu insulter les devs des distributions en fait) et Flatpak n'a pas à vocation de les remplacer (en particulier pour la partie système).
Pour le reste, j'ai déjà donné mon opinion plus haut, flemme de me répéter.
Emacs le fait depuis 30 ans.
[^] # Re: Bien d'accord !
Posté par barmic 🦦 . Évalué à 1.
Je n'insulte personne, j'affirme qu'un gestionnaire de paquets avec gestion des dépendances ça n'a rien de triviale. On revois éternellement de nouvelles personnes arriver en expliquant que ce qu'ils font c'est plus simples alors qu'ils ont surtout réimplémenter les bugs corrigés il y a longtemps chez leurs prédécesseurs. Critiquer leur travaux ce n'est pas les insulter ou alors je pourrais te répondre que ces gens qui pensent réimplémenter des gestionnaires de paquets en quelques semaines insultent leurs prédécesseurs.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Bien d'accord !
Posté par Faya . Évalué à 2.
C'est vrai. Et c'est pour ça qu'il faut faire avec flatpack comme tu ferais sous Windows : ne prendre le paquet que sur le site de l'éditeur du logiciel. Tu constateras qu'il faut faire plus ou moins la même chose avec AUR : lire attentivement le PKGBUILD et t'assurer, notamment, que la source est correcte. Car les paquets ne sont pas gérés pas l'équipe de Arch (et il y a eu des cas de paquets vérolés). Et tu passes par un outil tiers (pas par Pacman, pas par le gestionnaire de paquets de la distribution) pour installer ton logiciel.
Bref, sur la sécurité, flatpack n'est pas si différente de AUR… Charge à l'utilisateur de vérifier ce qu'il installe.
[^] # Re: Bien d'accord !
Posté par Astaoth . Évalué à 3. Dernière modification le 22 octobre 2019 à 20:30.
Tu noteras que pour AUR, ce point là est très bien expliqué sur le wiki de Arch. Il est aussi largement envisageable de s'en passer.
A côté, un peu partout, il y a des petits messages disant également que Arch n'est pas une distro pour débutants, contrairement à Flatpak qui est vendu comme la solution miracle à tout le monde. Tu vois le problème qui se pose.
Pour la culture, je viens de regarder rapidos de ce que j'ai qui vient de AUR. Dedans, on y retrouve :
- des programmes proprios (AUR, FlatPak ou autre, le problème reste un peu le même là)
- des pilotes proprios d'imprimantes (idem du coup)
- des versions expérimentales de certains paquets disponible normalement dans les dépôts(wine-staging en fait)
- des outils que je pourrais avoir via le dépôt de Blackarch maintenant (du coup faudrait que je le fasse)
Sous Arch, quand un utilisateur râle sur un truc qu'il a cassé salement lui-même alors que ca aurait pu être évité, il avait qu'à RTFM avant : c'est un peu le principe de cette distro.
Par contre, quand t'auras la moitié des utilisateurs qui vont débarquer sur les forums en disant que Linux c'est de la merde parce qu'un Flatpak installé a tout cassé, et que du coup ils retournent sous Windows, faudra pas se plaindre de voir les PdM passer de 5% à 2%.
Encore une fois, faut voir ce que vous voulez : un OS pour tout utilisateur, et essayer de se faire une ptite place de 3eme OS d'ordi de bureau pour être un minimum supporté et pris en compte, ou être un OS élitiste utilisé que par 3 nerds dans un garage (mais dans ce cas, Flatpak n'est finalement plus vraiment nécessaire).
Emacs le fait depuis 30 ans.
[^] # Re: Bien d'accord !
Posté par barmic 🦦 . Évalué à 1.
Ça n'est pas possible si j'ai bien compris. Tout au plus il peut avoir quelques logiciels qui interagissent avec ce flatpak qui vont fonctionner bizarrement.
Moi perso je ne veux rien, je laisse les gens qui font faire. Je ne vois pas pourquoi avoir une ambition quelconque si c'était le cas au lieu de répondre à des commentaires sur un sites d'aigris je contribuerais. Ta question n'a pas de sens pour des gens qui ne sont pas aux commandes d'une distribution. Nous, quidam de linuxfr, nous pouvons vociférer autant que l'on veut ça n'a pas vocation à être « volonté de la communauté linux ».
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Bien d'accord !
Posté par Astaoth . Évalué à 2.
Oh, en effet, tu peux imaginer que c'était une discussion au bar du coin sur un article du canard local :)
Emacs le fait depuis 30 ans.
[^] # Re: Bien d'accord !
Posté par Faya . Évalué à 2.
Alors :
Ils peuvent déjà tout casser. C'est la (mauvaise) mode aux "curl | sh" mais ceux qui sont susceptibles de taper ça sont généralement des dev donc ils vérifient. Les utilisateurs lambdas vont faire comme toujours : utiliser le programme fournit par la distro. Ici c'est de ça dont parle Ploum : sa distro lui donne des paquets snap. Mais le lambda ne saura même pas si c'est deb snap ou flomp. Il clique dans l'interface, ça installe. Donc pas plus de danger qu'avant, c'est la distribution qui gère.
Je ne pense pas que Linux soit déjà à 5% mais dans tous les cas, tu FUD. Je ne vois pas ce qui permet de penser que ça va faire fuire ceux qui vont se contenter de passer par l'outil fournit par la distro. Les autres savent ce qu'ils font
Personnellement, je ne veux rien à part un système qui marche. Ça fait longtemps que j'ai arrêté le prosélytisme. Je n'ai jamais utilisé flatpack/snap/autres parce que je n'en ai pas besoin. Si un jour ça arrive, je saurai gérer. Je m'adapte.
[^] # Re: Bien d'accord !
Posté par Astaoth . Évalué à 2.
J'ai la très vague sensation que cette discussion commence à prendre une tournure sacrment stérile. Ce qui suit n'est que pour le plaisir rhétorique.
Me semblait qu'on parlait d'utilisateurs plutôt débutants, pour qui ouvrir un term pour installer un programme c'est plus compliqué qu'un marathon. Donc des utilisateurs qui ne font pas trop ce genre de choses en fait.
Non, je ne pense pas.
Un système qui marche, c’est un OS capable d'exploiter le matériel. Pour que celui-ci puisse être exploité, faut des pilotes. Pour ca, faut que les industriel aient un minimum d'intérêt pour le faire. Je te laisse comparer avec les années 2000 ou FreeBSD pour voir où je veux en venir.
Emacs le fait depuis 30 ans.
[^] # Re: Bien d'accord !
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 17 octobre 2019 à 09:27.
Je pense que tu aurais du aller te coucher et arrêter de boire.
Ce n'est pas la présence de flatpak ou pas qui permet ou empêche l'utilisateur à faire de la merde. Rien n'empêche d'installer un bin sans flatpak, il n'y a que le noexec qui permet d'empêcher ça et encore ça n'a une efficacité que limité puisque ça ne peut rien contre un langage interprété déjà présent sur le système.
Du coup il est où le problème ?
De plus ont fait souvent tout un patacaisse sur le boulot de mainteneur. Alors oui il est important il suit et backporte des patchs pour assurer les maj de sécurité en essayant de rien casser mais combien de mainteneurs font un réel audit de sécurité de ces projets upstream avec étude en détail du code, pen testing et fuzzing ?
[^] # Re: Bien d'accord !
Posté par eric gerbier (site web personnel) . Évalué à 1.
Parce que tu crois vraiment que ceux qui font les paquets snap/flatpack font mieux que les mainteneurs des distributions ?
Moi, j'ai un (GROS) doute.
[^] # Re: Bien d'accord !
Posté par Psychofox (Mastodon) . Évalué à 2.
Parfois oui, parfois l'upstream peut paraître moins goret en mettant à jour toute l'appli au lieu de partir d'une version plus ancienne pour lui appliquer 'n' patches de sécurités à la louche.
Et puis tu veux qu'on ressorte le cas openssl/debian ?
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Snap, Flatpak, Packagekit : c'est quoi ce bordel ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 16 octobre 2019 à 12:08.
dès que Regolith fonctionnera sous Debian, je compte bien y passer. j'espère d'ailleurs que cela me permettra de formatter correctement mon disque (avec toutes les histoires LLVM, je m'y retrouve plus, moi qui voulait simplement une partition / et une /home)
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Snap, Flatpak, Packagekit : c'est quoi ce bordel ?
Posté par Siméon Marijon . Évalué à 1.
et juste pour info, qu'est ce qui fait que Regolith ne marche pas sous debian ?
Parce que vu de ma fenêtre c'est "juste" une session custom de gnome-fallback qui remplace le gestionnaire de fenêtre gnome par i3. Aurais-je louper des incompatibilités ?
Je suis interessé parce que je reçois bientot mon Pinebook pro => distrib par défault = Debian
[^] # Re: Snap, Flatpak, Packagekit : c'est quoi ce bordel ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 4.
Je ne sais pas trop, c'est le main dev qui m'a dit que ça ne fonctionnait pas ( https://github.com/regolith-linux/regolith-desktop/issues/32 )
Je serais curieux de savoir si ça peut être réglé.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Snap, Flatpak, Packagekit : c'est quoi ce bordel ?
Posté par YBoy360 (site web personnel) . Évalué à 1.
je crois que tu voulais sans doute dire LVM à la place de LLVM. Il faut vraiment utiliser un fork pour utiliser i3 sous Ubuntu ou j'ai mal compris ?
Concernant Regolith, il semble que l'on puisse l'installer via pip ou anaconda, qu'est-ce qui empêche d'installer ça sur une Debian ou une Ubuntu classique ? Si il n'y a pas de dépendance native, ça devrait passer sans problèmes..
[^] # Re: Snap, Flatpak, Packagekit : c'est quoi ce bordel ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Regolith est un fork de I3 + une version modifiée de gnome-flashback.
Du coup, c'est un peu fragile et le dev utilise Ubuntu et met à jour via un PPA. Visiblement, ça ne fonctionne pas encore ailleurs que sous une Ubuntu (voir https://github.com/regolith-linux/regolith-desktop/issues/32 )
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Snap, Flatpak, Packagekit : c'est quoi ce bordel ?
Posté par BAud (site web personnel) . Évalué à 2.
si tu utilises un PPA, c'est que tu es déjà prêt à l'installer de manière native, comme proposé par YBoy360…
cf. https://github.com/regolith-linux/regolith-desktop/blob/master/build.sh
[^] # Re: Snap, Flatpak, Packagekit : c'est quoi ce bordel ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 3.
J'ai trouvé comment virer Snap : https://askubuntu.com/questions/1039411/how-can-i-replace-snap-application-such-as-gnome-calculator-with-a-deb/1039434#1039434
Maintenant, on va voir si ça pose des problèmes à terme.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Snap, Flatpak, Packagekit : c'est quoi ce bordel ?
Posté par matteli . Évalué à 1.
Pour info upstart, mir et unity ne sont plus utilisés sur les dernières versions d'ubuntu.
Quant à snap, il suffit de l'enlever.
J'ai trouvé blender 2.80 seulement en snap pas en flatpak.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Snap, Flatpak, Packagekit : c'est quoi ce bordel ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
quand à enlever Snap, c'est ce que j'ai fait mais j'avais un peu peur en voyant des paquets "core" et "gnome" et "gtk-theme-common". Puis j'ai réalisé que le gnome était 3.28 et je me suis dit que j'allais tester.
Mais faut avouer que c'est un peu effrayant.
Mes livres CC By-SA : https://ploum.net/livres.html
# PackageKit est hors sujet
Posté par David Demelier (site web personnel) . Évalué à 9. Dernière modification le 16 octobre 2019 à 13:22.
Snap et Flatpak sont effectivement plus ou moins équivalent, par contre PackageKit n'a rien à voir et est là depuis des lustres. Il permet d'abstraire la gestion des paquets via une interface commune. En bref en utilisant packagekit tu peux installer des paquets sans savoir si c'est dnf, apt, pacman derrière… En général packagekit était utilisé par quelques interfaces graphiques comme GNOME PackageKit. Seul problème, il est considéré comme obsolète par son propre mainteneur en plus d'être foutrement buggé.
git is great because linus did it, mercurial is better because he didn't
# témpoignage
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 5.
J'espère que ce témoignage empoignant n'était pas trop agressif ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
# Ça aurait pu être bien
Posté par kna . Évalué à 5.
Si tout le monde s'était mis d'accord sur un format entre Flatpak, Snap, AppImage (je ne connais pas assez les différences entre chaque, mettons Flatpak pour l'exemple), et si les distributions avaient gardé simplement leur gestionnaire de paquets habituels :
[^] # Re: Ça aurait pu être bien
Posté par mahikeulbody . Évalué à 4.
Oui bien sûr, mais apparemment ce n'est pas juste se mettre d'accord sur un format, c'est aussi se mettre d'accord sur des fonctionnalités (bac à sable, sécurité, partage ou non de librairies, etc…).
[^] # Re: Ça aurait pu être bien
Posté par freem . Évalué à 3.
AppImage ne fournit aucune sécurité, et n'est a ma connaissance pas géré par dépôts, juste l'utilisateur télécharge le fichier d'origine, le chmod, et l'exécute.
Les autres semblent essayer de fournir des sécurités.
J'ai lu plusieurs fois sur linuxfr que les autres ont aussi l'avantage du téléchargement incrémental, contrairement a appimage, mais les auteurs de ces commentaires n'ont jamais du essayer d'utiliser l'appimage de redeclipse2, sinon ils sauraient que c'est faux.
Pour le reste, je n'en sais pas pas plus, je n'ai jamais testé fapfap/snap (désolé, pas pu résister), et jamais analysé un binaire AppImage, donc…
# La solution
Posté par CrEv (site web personnel) . Évalué à 3.
Ben MacOS + homebrew, what else?
Mais sinon tu peux utiliser homebrew sous linux.
[^] # Re: La solution
Posté par bunam . Évalué à 1.
Sans oublier https://www.macports.org aussi ;)
[^] # Re: La solution
Posté par CrEv (site web personnel) . Évalué à 1.
jamais eu besoin :/
# Bof
Posté par raphj . Évalué à 6.
Je suis resté sous GNU/Linux tout ce temps, et apparemment c’est un peu comme Facebook : c’est omniprésent mais je suis jusqu’à maintenant complètement passé à côté. Malgré tout, ma vie se déroule sans soucis majeur.
Snap est apparu dans Ubuntu quand je l’utilisais encore. Il suffisait de le désinstaller et de continuer sa vie. Aujourd'hui, je me rends compte que des trucs liés à Gnome sont installés par défaut sur un système Live que j'ai utilisé dans une VM ce weekend. Ce serait probablement une mauvaise idée de désinstaller ça aveuglément.
Mais entre-temps, je suis passé par Debian et openSUSE, et là, c’est du apt/dpkg et du zypper/rpm pur et tout fonctionne comme ça a toujours fonctionné. Je marche en sifflotant à côté d’un champ de bataille et je le sais mais je ne m’en rend pas vraiment compte…
Le plus gros défaut de Snap pour moi n’est pas technique : à ma connaissance, la séparation logiciels libres / non-libre n’est pas clair, du coup, ça ne m’intéresse pas trop.
Une solution pour distribuer un logiciel sur n’importe quel distribution GNU/Linux sans difficulté me paraît pourtant souhaitable.
[^] # Re: Bof
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 4.
Un peu pareil. En restant sur la même Gentoo ces douze dernières années, probablement grâce à la fois au système de mise à jour continue et à la liberté que me laissent les codes employés je n'ai jamais vu débouler ces technologies chez moi. Ouf, vu l'âge de ma bécane.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
# pas obligatoire
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 16 octobre 2019 à 15:34.
Packagekit n'est qu'une couche d'abstraction, perso ça ne me gène pas.
Pour les autres ben si tu n'en veux pas tu peux t'en passer. Perso je trouve les snaps bien utiles pour des trucs bien précis, dans mon cas kubernetes et ses outils, pour le reste je ne l'utilise pas.
Ces outils de packaging (j'ajouterais nix à la liste) ont aussi beaucoup de sens dans une distro immutable (fedora silverblue/atomic) avec une séparation claire système/userland.
[^] # Re: pas obligatoire
Posté par Guillaum (site web personnel) . Évalué à 2.
Pour le coup, nix a aussi du sens dans une distro mutable puisque le boulot de nix c'est de te faire un environnent reproductible quel que soit la distro dans laquelle tu es.
# ça vient de qui ?
Posté par ZeroHeure (site web personnel) . Évalué à 2.
Vérifie si ça vient de Regolith-Linux : certaines dérivées de distro installent tout plein de choses via Flatpak ou Snap ou Appimage ou … parce que les petits gars ne savent pas empaqueter. Dans ton cas, une dérivée d'Ubuntu un peu minimaliste avec le paquet Regolith devrait aboutir à une intallation propro.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: ça vient de qui ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 4.
Après recherches, c'est clairement Ubuntu qui package certains outils GNOME via Snap et, allez savoir pourquoi, des libraires GNOME 3.28 (!). J'ai tout supprimé sans observer le moindre problème. On dirait qu'à chaque release d'Ubuntu, y'a un peu plus de paquets via Snap et non via apt.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: ça vient de qui ?
Posté par Psychofox (Mastodon) . Évalué à 6.
Oui c'est la politique ubuntu depuis quelques années déjà mais ça tout le monde est au courant. Si ça te dérange je ne comprends pas bien pourquoi tu as choisis d'utiliser ubuntu ou une de ses variantes.
# brute
Posté par Ruminant . Évalué à 2.
Perso j’ai désinstallé snapd et supprimé le répertoire dans lequel j’avais encore des traces de ce truc, et éventuellement j’ai réinstallé la calculatrice gnome…
J’utilise Ubuntu avec i3 (pas la version regolith par contre mais c’est "pareil" pour notre problème), et tout va très bien depuis.
# Découverte de flatpak
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Je tente de créer un paquet flatpak pour Newton Adventure, mais:
Bref ça va être encore une énorme et gigantesque galère de créer un paquet.
Et après on s'étonne que les jeunes développeurs tombent dans la drogue et le curl|sh.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Découverte de flatpak
Posté par gnumdk (site web personnel) . Évalué à -1.
Faire un flatpak, c'est aussi simple que de faire un paquet sous ArchLinux (voir encore plus simple dans certains cas).
Tu as pas du beaucoup lire la doc pour demander cela…
[^] # Re: Découverte de flatpak
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Pas trouvé…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Découverte de flatpak
Posté par devnewton 🍺 (site web personnel) . Évalué à 4. Dernière modification le 17 octobre 2019 à 11:42.
Pour préciser mon problème, dans Docker j'ai l'instruction ADD pour ajouter des fichiers. Je ne comprends comment cela fonctionne avec flatpak, j'ai essayé une source de type "dir", mais ça semble ne rien faire. Je ne sais pas où vont mes fichiers…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Découverte de flatpak
Posté par Jérôme Flesch (site web personnel) . Évalué à 4. Dernière modification le 17 octobre 2019 à 12:23.
J'ai eut le même genre de problèmes avec Paperwork. Heureusement pour moi, Mathieu Jourdan avait fait un début de Flatpak qui réglait le problème de l'installation des paquets Python. De mon coté, j'ai pu me concentrer sur les problèmes de fichiers de données spécifiques à la langue de l'utilisateur et sur le problème de l'accès aux scanners.
Pour Maven, je pense que tu peux t'en sortir comme Mathieu Jourdan avait fait pour Python:
- Compiler et installer Maven comme faisant partie du build Flatpak
- Utiliser un mini Makefile bidon pour construire les builds suivants avec Maven
C'est effectivement difficile, mais Flatpak offre ensuite plusieurs avantages:
- Tu as une liste quasi-exhaustive des dépendances de ton programme.
- Tes utilisateurs peuvent tester la dernière version de ton programme quelque-soit leur distribution.
- Tes utilisateurs peuvent te faire des rapports de bugs indépendamment des 25000 versions des dépendances disponibles dans les diverses distributions.
- Tu peux faire de l'intégration continue en mettant à jour ton dépôt Flatpak automatiquement.
[^] # Re: Découverte de flatpak
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Je ne comprends toujours pas comment ajouter un dossier. Une source de type "dir" ne fonctionne pas du tout.
Par contre une source de type "git" fait bien un checkout \o/
Une de type "file" avec une url vers un tar.gz aussi \o/
Cool je vais pouvoir télécharger mes sources, le tar.gz de Maven et compiler le tout !
Ah zut tiens, flatpack-builder ne propage pas http_proxy donc impossible pour Maven de télécharger les dépendances.
Bon flatpak est pas près pour les entreprises…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Découverte de flatpak
Posté par Jérôme Flesch (site web personnel) . Évalué à 4.
Flatpak-builder bloque volontairement le réseau pendant les builds de chaque composant. L'objectif est de s'assurer que la liste des dépendances est complète et que le build reste 100% reproduisible. C'est notamment pour éviter que des dépendances soient téléchargées pendant le build.
Par exemple, lors de l'installation d'un module Python avec pip, si une dépendances n'est pas sur le système, pip va essayer de la télécharger. Et par défaut, il va tenter de télécharger la dernière version. Or ce pourrait ne pas être la même entre 2 tentatives de build différentes. Donc il faut que les dépendances soient installées avant explicitement (y compris les dépendances des dépendances, etc).
[^] # Re: Découverte de flatpak
Posté par devnewton 🍺 (site web personnel) . Évalué à 5. Dernière modification le 20 octobre 2019 à 01:43.
Pas terrible:
La seule solution que je vois, c'est de construire un fat jar avec toutes les dépendances, voire embarquer la jvm au cas où celle flatpak ne fonctionne pas (maven se plaignait de ne pas voir un vrai jdk).
Mais du coup quel est l'intérêt de flatpak si le seul moyen de travailler avec c'est de tout embarquer dans un énorme et gigantesque binaire?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Découverte de flatpak
Posté par YBoy360 (site web personnel) . Évalué à 4. Dernière modification le 20 octobre 2019 à 13:36.
il n'y a pratiquement aucun intérêt à utiliser Flatpak pour une application Java (ni le gestionnaire de paquet de la distribution d'ailleurs), sauf à vouloir proposer d'isoler l'application, (qui est quand même l'un des gros avantage de Flatpak). Java est assez indépendant des binaires de la distribution, dispose d'une bonne stabilité binaire, et propose des gestionnaires de dépendances qui fonctionnent par application et même par dépendance (les dépendances peuvent utiliser de multiple version d'une même dépendance).
Par contre pour les applications Python, ça permet de les isoler du système de la volatilité de pip et autres. Il est très facile de casser une distribution ou un build avec pip.
J'aime bien Python (on est dimanche, mais bon), par contre rien que pour Qt, entre PyQt[45], PySide, PySide2, le tout en Python2 ou Python3, installé via pip, conda, ou le package de la distro, le tout global à la distro, qui n'utilise pas la même version de gcc ni de Qt que pip et conda, on est très loin de la simplicité du monde Java pour la gestion des dépendances.
# Tu en as oublié un gros
Posté par Benjamin Henrion (site web personnel) . Évalué à 2.
Tu as oublié Docker dans la liste, et LXD aussi.
Enfin la dernière fois que j'ai essayé LXD, je ne suis même pas arrivé à tourner un container de base.
En fait c'est tellement compliqué de faire un package pour Debian (ya tjs pas de PPA :-) qui soit dans la distro, et je ne parle pas des 6 mois pour être Debian Developer.
Je comprends que la majorité de fasse plus de paquets, mais des images Docker.
[^] # Re: Tu en as oublié un gros
Posté par freem . Évalué à 5.
Pas moi, si ton objectif est juste d'installer ton blob sur une bécane.
Si tu veux être un paquet Debian officiel, il faut suivre une tétrachiée de règles, un format fixe qui garantit tout plein de truc, et… mais en fait, on s'en fout.
Le but d'un dev, c'est de distribuer son application. Pour la distribuer sur Debian, le plus simple, c'est de filer un paquet Debian binaire, proprio-style, pas un paquet source qui permets… euh… de se prendre la tête?
Et un paquet binaire de Debian, ça se construit hyper facilement, promis. Allez, j'explique, s'pas bien long après tout:
Il faut lancer la commande
dpkg-deb -b $TARGET, $TARGET étant une arbo constituée, de mémoire, ainsi:DEBIAN/control: fichier qui permets d'avoir le nom du paquet, sa version, ses descriptions courtes/longues, la homepage, etc… dans un format que même un enfant de 10 pourrait comprendre. C'est le seul fichier obligatoire;DEBIAN/md5sumscontiens les somme de contrôle md5 (on peut aussi utiliser SHA512 je pense). C'est basiquement la sortie demd5sumsavec quelques arguments…DEBIAN/post-inst(en gros) script lancé après chaque dépaquetageDEBIAN/pre-inst(en gros) script lancé avant chaque dépaquetageDEBIAN/post-rm(en gros) script lancé après chaque suppréssionDEBIAN/pre-rm(en gros) script lancé avant chaque suppréssionVraiment, pourquoi viser l'officiel? C'est le job des mainteneurs, les paquets source Debian ont des patchs justement pour ça: l'intégrer aux changements systèmes de Debian.
Rien n'empêcherait de faire un paquet avec un binaire lié statiquement qui s'installe dans /usr/local ou /opt…
[^] # Re: Tu en as oublié un gros
Posté par Anonyme . Évalué à 4.
D’autres exemples :
[^] # Re: Tu en as oublié un gros
Posté par freem . Évalué à 3.
le traité empirique est nettement plus compliqué que ce que moi je fais pour construire un deb…
Je commence a croire que c'est le manque de doc sur le format binaire qui est le problème de debian.
Je cite, et vous m'excuserez des fautes, je suis hors d'état de conduire, et je ne devrais pas poster sur l'autoroute de l'information… mais je compte sur votre magnanimité, donc:
c'est pas une citation exacte, j'ai viré la poncutaition et divers mots de jonction.
Bref, seul control est vital. Je connaissais même pas l'existance de compat, en vrai. On se fait une dépêche en mode coop sur comment faire un deb proprio/freestyle propre, un jour? Je pense que ça permettrait d'aider a perdre cette réput injustifiée du format deb…
Le changelog, c'est d'un pénible a maintenir… on sent que debian est née avant les DVCS, mais, pour être honnête, je ne connais aucun outil capable de gérer C ou C++ qui sache compiler en prenanant en compte facilement le versionning a base de hash. Dur sujet, faut dire. Mais même les tags sont absents… et un admin noob comme moi a pu pondre un script (de merde, je tenterais unjour de faire mieux, et de le publier d'abord sur le temps libre, puis de l'utiliser au taf, en ayant soin dans ce cas d'utiliser GPL) qui peut récup les tag+commit hash d'un dépôt pour générer un numéro de version.
Le changelog, en soit, c'est plus dur, y'a une notion de politique: est-ce destiné a l'utilisateur, ou a l'admin, ou au contributeur? Pas facile.
Je croyais que ça devait pas générer un deb source? Ce truc est useless dans le cas d'un deb binaire.
Le ficher rules, c'est en gros un makefile de ce que j'ai compris (confirmé par la 1ère ligne, en fait).
purée, c'est ça, la ceinture blanche? J'ai pas un tiers des connaissances requises, et pourtant, promis, je peux te générer un .deb a partir d'un binaire proprio en moins de de 15 minutes…
Je crois que la complexité, ça s'acquiert quand on cherche a faire du propre, du bien intégré et universel.
Ce qu'on repproche a debian, justement, c'est de vouloir faire trop universel, et le pire c'est que ça marche pas: Debian reste, malgré les efforts (qu'il faut saluer) une distro GNU/linux. Les ports BSD ou non-GNU officiels semblent a l'état de bêta-test, et je suis gentil.
Merci d'arrêter de balancer des rocquettes dans les pattes de cette distro. A la base, c'est censé être une distro geek friendly, pas user-friendly, et il reste des traces, très claires: je peux installer un paquet avec juste du shell unix, et je peux installer un système en mode archlinux, la stabilité en plus.
J'ai parfois l'impression que les "nouveaux geeks" se contentent de lire 1 seul tutoriel, et se proclament maîtres de la techno en question, en ignorant tout de l'histoire et du fonctionnement interne…. le pire, c'est que ces gens semblent se croire aptes a critiquer des choses que peu d'entre nous seraient capables de recreer, même avec l'exemple sous le nez! Ou alors, je suis totalement idiot…. ça me choquerais pas, d'ailleurs, en soit.
[^] # Re: Tu en as oublié un gros
Posté par kna . Évalué à 3.
J'avais fait un journal (je partais pas d'un truc proprio mais le principe est le même)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tu en as oublié un gros
Posté par ploum (site web personnel, Mastodon) . Évalué à 3.
C'est un peu le point essentiel de apt/deb : c'est un enfer à packager (il y'a quelques années, j'ai tenté de m'y mettre, j'ai vite compris que je n'avais pas les neurones pour ce genre de travail) mais, pour un utilisateur, quel bonheur ! J'arrive à me dépétrer de n'importe quelle situation même avec les paquets deb les plus pourris.
Et, ce petit traité empirique est effectivement une horreur. Quand j'ai vu ce qu'il appelle "ceinture blanche", j'ai laissé tomber (une fois de plus).
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tu en as oublié un gros
Posté par Benjamin Henrion (site web personnel) . Évalué à 1.
DEB et RPM supportent nativement les tarballs+md5sums, pas les repos GIT.
Une fonctionnalité que j'adorais de Gentoo était le 9999 pour compiler le HEAD du GIT.
Pour DEB, je n'ai trouvé rien d'autre que Jenkins-Debian-Glue qui snapshotait le GIT et produisait un tarball, qui ensuite pouvait etre réutilisé par la chaîne DEB.
Mais quelle galère pour faire la même chose.
[^] # Re: Tu en as oublié un gros
Posté par Anonyme . Évalué à 2.
https://wiki.debian.org/PackagingWithGit
# debootstrap est ton ami
Posté par freem . Évalué à 6.
Salut.
Si tu considères (comme moi) que l'installateur de Debian installe trop de merdes par défaut, tu peux utiliser (c)debootstrap (l'un ou l'autre, peu importe).
Je préviens, c'est une méthode d'installation très "low level", faut connaître son système un minimum, mais bon, on est sur linuxfr ici, ça devrais donc aller.
Pour détailler un peu plus, quand j'installe une Debian maintenant, je commence par booter le CD en mode "dépannage" ou whatever. Je réponds vite fait à la chiée de questions dont on devrait se foutre royalement dans ce mode (domaine, nom de la machine, ce genre de choses) ainsi qu'a celles utiles (config réseau, sur quelle partition me chrooter ou juste me chrooter dans le contexte de l'installateur) en prenant soin de chrooter dans le contexte de l'installateur.
De là, je fais un p'tit
fdisk, histoire de préparer mon disque dur (bon, certes, c'est chiant pour le boot UEFI vu qu'il faut bricoler l'UUID de la partoche de boot, du coup j'ai tendance a booter en mode legacy la 1ère fois, et corriger ça ensuite), que j'enchaîne avec quelquesmkfsbien sentis. Étape finale: monter la future "/", y créer les dossiers qui vont bien (dans mon cas, /boot/EFI, /var, /home, et le jour ou je serais motivé pour que mon système boot en read-only, probablement le /usr) et y monter les partitions.Un petit
debootstrap --variant=minbase buster /targetplus tard, le système réellement minimal est prêt.fini de préparer le
chroot /target, ou j'invoque l'installation des paquets qui me permettrons d'avoir un système autonome:apt-get install --no-install-recommends linux-image-amd64 syslinux syslinux-efi syslinux-common busybox vim aptitude runit-init sudo.L'oeil averti notera que je me permets du confort inutile avec vim, sudo et aptitude, j'aurai pu me passer du 1er puisqu'un close
viest embarqué dans busybox, les autres… bon, bref.Il notera également l'absence de grub, car je préfère et de très loin syslinux, malgré le fait de devoir copier manuellement (oh mon dieu, une copie manuelle!) les fichiers /initrd et /vmlinuz dans la partition de boot. Je pourrais sûrement installer un hook dans dpkg, mais je n'ai jamais cherché comment faire.
Pour finir, le troll averti notera l'absence de systemd, remplacé par syslinux, Debian 10 mettant à disposition un paquet syslinux-init qui permets de l'utiliser comme système d'init.
Création d'un user qui fait partie de quelques groupes (sudo ici):
useradd -m -G sudo user -s /bin/bash, modification des passwords de user et root viapasswdouchpasswd(bien utile pour les scripts, le 2nd) et il me sera possible de me loguer.Création d'un fichier syslinux.cfg, installation du boot loader et copie des kernel/initrd:
Reste plus qu'à créer quelques fichiers systèmes: /etc/fstab et /etc/hostname et configurer le système est bootable.
Bon, je vais être honnête:
m'enfin, chez moi, ça marche. Si avec ça, t'as encore des cochonneries installées, faut vraiment penser à changer de distro.
[^] # Re: debootstrap est ton ami
Posté par ZeroHeure (site web personnel) . Évalué à 5.
fait une distro ;-)
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: debootstrap est ton ami
Posté par freem . Évalué à 3. Dernière modification le 16 octobre 2019 à 19:32.
Ça ne serait pas un projet inintéressant (j'y pense, en vrai), mais je pense que je manque de connaissances, d'expérience en gestion système. Il y a aussi des points qui me semblent mal branlés, mais probable que je ne comprenne juste pas la raison derrière.
Notamment:
sv check $DAEMONferme le descripteur de fichier 2 (stdout) avant d'exécuter$SVDIR/$DAEMON/check. Du coup, si le fichiercheckécrit quelque chose dans stdout, le script plante, ce qui fait croire que le daemon n'est pas fonctionnel… dans mon cas, c'était un tunnel ssh inversé, ce qui mène a un reset du tunnel (le daemon était un watchdog codé à la va-vite) entraînant une sur-consommation de données (parce qu'une liaison ssh, ça bouffe un max a établir, et je n'ai pas étudié IPSEC, donc les VPN, pour ça que je suis parti sur cette solution: je suis dev moi, pas admin);Bref, j'ai encore un peu de chemin a faire avant de m'attaquer à un truc aussi complet que la création d'une distro. Enfin, si je veux qu'elle apporte vraiment quelque chose.
Parce que je pense qu'il y a de la place pour de nouvelles distro: je verrai bien une distro qui ait un coeur stable et soit relativement simple a installer, comme Debian, mais axée codeurs (que ce soit du C, du python, du java, du bash ou autre). Si on pouvait avoir du dpkg qui marche sans être root, on pourrait du coup intégrer des dépôts "contrib" pour le code "à l'arrache", pas officiellement supportés, comme ce que fait archlinux.
Si c'est juste forker Debian pour refourguer des paquets debian mais avec juste la sélection par défaut et le fond d'écran officiel qui change, je pense sincèrement que c'est pas la peine. Il y a déjà bien assez de variantes de Mint ou d'Ubuntu comme ça.
[edit]
Ah, j'oubliais, je ne sais toujours pas utiliser docker, SElinux ou AppArmor, les cgroups… qui sont pourtant dans l'air du temps. Donc, vraiment, vraiment beaucoup de chemin à faire :)
[^] # Re: debootstrap est ton ami
Posté par ZeroHeure (site web personnel) . Évalué à 2. Dernière modification le 17 octobre 2019 à 12:44.
Bien sûr, je disais ça pour rire, comme celui qui annonce la n-ième distro. Des minimalistes il y en a déjà, il vaut mieux participer. Et comme tu le sous-entend, c'est un énorme travail, presque impossible à faire seul. Tu peux faire une preuve de concept, pour réorienter une minimaliste qui ne te correspond pas tout à fait. D'ailleurs, Tiny Core est un peu conçue pour ça.
J'ajoute un test de Tiny Core par LWN.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# Mwai
Posté par gnumdk (site web personnel) . Évalué à -2.
Ok, retourne sous MacOS, tu as perdu la main…
[^] # Re: Mwai
Posté par freem . Évalué à 5.
Faut reconnaître que c'est dommage de la perdre avec un système de paquet nommé
fapfapflatpack.Je suis déjà dehors :)
# Quelques infos sur Snap (et Flatpak)
Posté par pieq . Évalué à 1.
Salut Ploum !
Avant d'aller plus loin, sache qu'Ubuntu est toujours basée sur les repos Debian, donc tous les logiciels qui sont dispos dans ces repos sont dispos sur Ubuntu :)
Un des buts des snap et autres flatpak, c'est de simplifier la mise à jour des logiciels sur les distributions Linux. Aujourdhui, si tu as réussi à pousser ton super logiciel
foobarbuzzen version 1.0 dans les repos Debian, il va falloir attendre un paquet de temps avant qu'il soit dispo sur Debian stable ou dans Ubuntu, sans compter qu'il ne sera jamais disponible sur Fedora, RHEL, Arch Linux, etc. Si, en cours de route, tu as publié une version 1.1, voire 2.0, le processus pour publier cette mise à jour est contraignant et chronophage, et il peut s'écouler des mois avant que tes utilisateurs puissent y avoir accès, en fonction de la distribution qu'ils utilisent.Les PPA d'Ubuntu essaient de limiter cette attente, mais c'est galère à utiliser pour le commun des mortels, il faut quand même avoir une certaine confiance dans les gens qui créent ces PPA, et surtout on peut y mettre n'importe quoi, et potentiellement casser un système.
Si tout cela t'intéresse, je pourrais écrire un petit article à ce sujet. (enfin, surtout à propos de snap que je connais bien mieux que flatpak)
Justement, non. Le but affiché de snap est de faire en sorte que les développeurs/mainteneurs n'aient à packager leur application qu'une fois, et qu'elle soit ensuite disponible sur un paquet de distributions. Je te renvoie à la documentation de Snap et notamment sa page qui liste les distributions compatibles.
Une application installée en tant que snap n'est autre qu'une mini-partition au format squashfs. Un petit
alias df="df -x squashfs"bien placé, et hop ! plus de problème avecdf;)Si tu parles du snap core (ou core18), il s'agit, en gros, d'une base qui est utilisée par tous les logiciels qui sont empaquetés au format snap.
Il faut voir si c'est judicieux sur le long terme. Chromium est disponible au format snap, par exemple (lire l'article d'Alan Pope à ce sujet). Cela permet à l'équipe en charge du desktop Ubuntu de n'avoir à empaqueter qu'une seule version de Chromium qui est disponible sur beaucoup de versions d'Ubuntu différentes (toutes les LTS, même les plus anciennes, et toutes les versions intermédiaires encore supportées). Mine de rien, ça réduit considérablement leur travail d'empaquetage et de test.
# flatpak c'est nul
Posté par devnewton 🍺 (site web personnel) . Évalué à 9. Dernière modification le 30 octobre 2019 à 12:12.
Après de nombreux tâtonnements en suivant la doc pas terrible et la quasi absence d'infos pour les applis Java/Maven (un scandale vu le nombre d'applis utilisant ces technos), j'ai réussi à faire mon paquet avec Flatpak.
Je le teste sur une Ubuntu: super ça marche !
Je le teste sur la dernière Fedora:
L'argument n°1 de Flatpak était pourtant:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.