Bonjour à tous,
J'ai passé quelques temps ce week end sur un soucis que je rencontre avec chromium depuis la mise à jour de la distribution de mon ordinateur portable sous KDE Neon vers la 20.04. La distribution est basée sur Ubuntu.
Le soucis était lié à la consommation mémoire du navigateur, avec mon environnement de travail et seulement quelques onglets ouverts le système utilisait rapidement plus que les 8Go de RAM disponibles.
Suspectant fortement le passage au format snap du package j'ai décidé de tenter l'installation du package natif de la Debian stable et je dois dire que cela change tout, je reste sous les 5Go d'occupation de la RAM avec le même environnement de travail et un navigateur avec de nombreux onglets ouverts.
Donc si vous constatez une consommation mémoire particulièrement élevée après mise à jour d'une Ubuntu en utilisant chromium, vous pouvez creuser de ce coté, c'est loin d'être négligeable comme écart et on peut facilement passer d'un système performant à une machine qui swap pour ce "détail".
La procédure utilisée : https://www.linuxtricks.fr/wiki/ubuntu-installer-chromium-de-debian-au-lieu-du-snap
# Très intéressant...
Posté par redo_fr . Évalué à 5.
Merci pour ce journal qui m'a aussi permis de résoudre un problème avec chromium, très différent du tien…
Depuis que j'ai migré vers la 20.04, chromium ne fonctionnait plus du tout (il n'arrivait plus à résoudre les adresses DNS…). Aucun problème avec d'autres navigateurs (FF -> OK, chrome -> OK,…). J'avais abandonné l'idée de comprendre, faute de temps…
Ton astuce m'a permis de refaire fonctionner chromium, c'est donc le paquet 'snap' qui a un problème avec mes DNS…
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
# KDE neon consomme 5gio de RAM ?
Posté par Joalland . Évalué à 3.
Quel est ton environnement de travail ? J'hésitais à l'installer mais là ça me refroidit un peu.
[^] # Re: KDE neon consomme 5gio de RAM ?
Posté par bubar🦥 (site web personnel) . Évalué à 4.
Yo land<
Il me semble qu'il faut voir la conso en ram du bureau en ratio de la ram disponible, avec un seuil minimal.
J'observe aujourd'hui la même chose avec gnome3 d'ailleurs.
Pour Plasma / KDE l'astuce est de désinstaller kmail/kontact/akonadi.
(sur Fedora ça se fait très bien sans tout désinstaller, l'arbre des deps le permet quasi nickel, il y a juste besoin de remettre 3 4 libs une fois la désinstall faite)
Sans akonadi, KDE consomme 300M de ram ! (et se lance / est prêt en moins de 2 secondes chrono) sur un petit pc genre atom d'il y a 5 ans avec 2go de ram en tout.
300M :-)
[^] # Re: KDE neon consomme 5gio de RAM ?
Posté par Chris K. . Évalué à 4.
Ce que j’appelle mon environnement de travail ici c'est les logiciels que j'utilise pour bosser et ils sont loin d'être légers : un IDE Java, une base de données orientée graph, un serveur web, … Ce n'est pas la faute de Neon/Ubuntu c'est la même sur ma station de travail fixe sous Debian. Si j'en parle dans le journal c'est simplement que je ne peux pas raisonnablement passer mon temps à les arrêter et les relancer pour éviter de swapper.
L'environnement de base KDE sur Neon est assez rapide et léger. Là j'ai fermé mes logiciels pro et je suis à moins de 1.5Go de RAM utilisée avec 4 onglets actuellement ouverts dans chromium dont une vidéo Youtube.
# Snap a bannir
Posté par ff9097 . Évalué à 10.
Ce format est de toute façon a bannir tellement c'est merdique.
En plus c'est complètement centralisé sans possibilité d'héberger des dépôts alternatifs. Un alter-ego des magasins d'applications mobiles.
Linux Mint l'a banni et build le paquet chromium eux-mêmes. https://blog.linuxmint.com/?p=3978
[^] # Re: Snap a bannir
Posté par Chris K. . Évalué à 5.
Oui je partais sans a-priori sur le format je ne le connaissais pas et ne l'avais jamais utilisé avant la mise à jour.
Pour packager un petit jeu ou diffuser une petite application avec une faible base d'utilisateurs pourquoi pas. Pour un truc aussi central qu'un navigateur web effectivement il faut constater que ce n'est pas du tout adapté, il est bien plus léger et réactif installé depuis le package natif.
[^] # Re: Snap a bannir
Posté par Colin Pitrat (site web personnel) . Évalué à 8.
Pour ça je préfère AppImage personnellement
[^] # Re: Snap a bannir
Posté par Cyprien (site web personnel) . Évalué à 6.
Je suis en train de rédiger une dépêche sur Manjaro et j'ai justement un petit article sur Snap et Flatpack : https://linuxfr.org/redaction/news/bien-debuter-avec-manjaro-linux#toc-flatpak-et-snap.
Ca vous dérangerait d'y jeter un œil pour voir si je ne dis pas trop d'âneries ? (Je pense qu'il ne faut pas trop rentrer dans les détails pour ne pas perdre les utilisateurs débutants, c'est un peu le but de la dépêche).
[^] # Re: Snap a bannir
Posté par saltimbanque (site web personnel) . Évalué à 4.
Je pense que tu devrais rentrer un peu dans le détail. Là c'est trop succint à mon goût. Content de voir un avertissement sur AUR, car c'est trop souvent promu comme un énooooooorme bibliothèque de paquets alors que la fiabilité n'a rien à voir.
[^] # Re: Snap a bannir
Posté par Sausad . Évalué à 2.
Du point de vue d'un utilisateur consommateur (ma principale voire unique participation au libre est de le promouvoir), pas d'un mainteneur de serveur critique, AUR fait quand même particulièrement bien le job.
Il est rare que j'entende parler d'un logiciel et que je ne puisse pas le tester rapidement via ce biais, sur mon ordi perso.
Oui, cela présente des risques, mais rien n'empêche d'aller regarder le paquet, regarder s'il est à jour et tester.
Venant de gentoo, ce sont des overlays en plus puissant.
Donc effectivement, ce n'est pas forcément à conseiller à un novice en lui disant qu'il peut tout tester avec sans crainte, mais en regardant un peu ce qu'il en est, si le logiciel souhaité n'appelle pas trop de dépendances également dans AUR, c'est quand même d'un confort très appréciable.
Je vais encore rentrer dans le cliché des Archusers prosélytes… Mais j'ai l'impression que c'est le cas avec toutes les distributions :)
[^] # Re: Snap a bannir
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Ah tiens, je me suis déjà fait la réflexion que c'est similaire aux overlays, mais sans plus. Peux-tu, pour ma culture, détailler un peu en quoi c'est plus puissant ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Snap a bannir
Posté par Sausad . Évalué à 1.
Hum, je ne sais pas si le terme de puissant est bien choisi.
Et ma réflexion ne porte que sur le côté pratique pour l'utilisateur, pas sur l'aspect technique.
De ce que j'en comprends, un paquet aur ressemble à ce qui est utilisé sur les overlays du point du script qui permet l'installation. Donc la "puissance" est là équivalente.
Mais, un peu comme les dépôts ppa pour Ubuntu, les overlays sont hébergés/construits par des contributeurs, pour leurs besoins propres et accessibles à tout un chacun ensuite.
Pour AUR, cela a le mérite d'être centralisé et géré à partir du même domaine que toute la distribution.
Cela peut apparaître futile comme réflexion, mais cela avait joué dans mon choix de me diriger vers Archlinux : le site principal, le wiki, les forums, les paquets et AUR, tout est sur le même domaine, avec une même charte graphique et présente donc une cohérence d'ensemble et l'assurance de trouver une information en cas de problème à partir d'un seul et même site et d'une seule et même communauté. Et je trouve cette cohérence de bon aloi.
C'est cette centralisation qui pour moi présente plus de "puissance" : l'utilisateur ne se pose pas la question de trouver un overlay qui pourrait avoir ce programme qui semble intéressant, il le cherche sur aur et le trouve ou non.
Ensuite, il existe les Unofficial user repository, qui reprennent cette notion d'overlay/ppa.
[^] # Re: Snap a bannir
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Merci beaucoup pour le retour ; je comprends mieux ton point de vue
:-)“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Snap a bannir
Posté par BAud (site web personnel) . Évalué à 2.
ce n'est pas pour rien que je suis souvent en Cauldron (la version de dév de Mageia)
[^] # Re: Snap a bannir
Posté par AlexTérieur . Évalué à 0. Dernière modification le 16 novembre 2020 à 12:37.
Snap et Flatpak des magasins d'applications ? Non !!! Ce sont avant tout des méthodes d'empaquetage des applications avec les dépendances compilées en "statique", ou en environnement sandboxé. Pas des stores.
[^] # Re: Snap a bannir
Posté par Matthieu Moy (site web personnel) . Évalué à 7.
Bah quand même, quand tu vas sur https://snapcraft.io/ et que tu lis « The app store for Linux », avec des sections « Some snaps you may like », « Official snaps from major publishers », ça ressemble beaucoup à un magasin d'application.
[^] # Re: Snap a bannir
Posté par AlexTérieur . Évalué à -1. Dernière modification le 16 novembre 2020 à 14:07.
C'est peut-être donné à l'orientation du Snap, mais à la base ce ne sont pas des stores (je me répète…) dans leur principe de fonctionnement… Ca c'est Canonical qui a voulu reprendre les codes Android et maintenant Windows, en créant une centralisation des Snaps tel un "store" en croyant que cela les aiderait à se faire une pub… vu les critiques sur Snap, apparemment, c'est râpé…
[^] # Re: Snap a bannir
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Le principe de Store revient peut être à une distribution dans une distribution, ce qui n'est pas top pour l'espace disque. Mais cela permet surtout d'avoir des logiciels à jour sans avoir besoin de réinstaller la machine et de prendre un risque pour ses données perso.
"La première sécurité est la liberté"
[^] # Re: Snap a bannir
Posté par Cyprien (site web personnel) . Évalué à 2.
Ok, je vais reformuler… Je vais dire un truc du genre : "Le but est d'imiter un magasin d'application comme le play store".
[^] # Re: Snap a bannir
Posté par pamputt . Évalué à 5.
NextInpact avait publié un comparatif entre Snap, Flatpak et Appimahe en juin dernier. A lire ou relire pour ceux et celles qui ne connaissent pas trop ces nouveaux formats.
[^] # Re: Snap a bannir
Posté par Mimoza . Évalué à 7.
Je dirais que pour certains cas d'usage ça peux être utile.
Si tu veux utiliser 1 fois 1 logiciel assez complexe a installer, un coup de Snap est tout de même pratique. Si ça permet d'éviter d'installer 45 dépendances et de bidouiller quelques fichier de conf, pourquoi pas.
Il faut le voir comme un docker du logiciel bureautique.
Après il faut accepter que le snap pèse 3 fois le poids du logiciel et que point de vue RAM c'est un ogre.
[^] # Re: Snap a bannir
Posté par Boa Treize (site web personnel) . Évalué à 5.
Le docker du logiciel bureautique, il y en a d'autres qui le font (AppImage, Flatpack) avec moins de problèmes.
Snap en particulier ne permet pas vraiment de contrôler les mises à jour (encore pire que le Play Store) au mieux tu peux te cantonner à un canal "stable" si le créateur du snap l'a prévu. Mais les mises à jour se feront, pas forcément quand tu veux…
[^] # Re: Snap a bannir
Posté par ff9097 . Évalué à 5.
Le principe est complètement légitime, l'implémentation est pourrie. Flatpak est bien meilleur
[^] # Re: Snap a bannir
Posté par devnewton 🍺 (site web personnel) . Évalué à 4. Dernière modification le 16 novembre 2020 à 23:51.
Flatpak a évolué depuis https://linuxfr.org/nodes/118997/comments/1795082 ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Snap a bannir
Posté par ff9097 . Évalué à -1.
Je ne suis qu'utilisateur et pas empaqueteur donc je ne sais pas. Mais en tant qu'utilisateur ça fonctionne très bien
[^] # Re: Snap a bannir
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 17 novembre 2020 à 14:25.
Évidemment que Flatpak a évolué depuis l'an dernier, c'est un projet en plein essor. Mais j'imagine que la question que tu poses est plutôt "Aurais-je les mêmes ennuis si je retente de faire un flatpak aujourd'hui ?". À cela, je ne peux que t'apporter quelques éléments de réponse en me basant sur ce que j'ai compris de tes griefs :
Et de toute façon, Flatpak reste préférable à Snap pour les raisons évoquées ici.
[^] # Re: Snap a bannir
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Et par rapport à Appimage ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Snap a bannir
Posté par claudex . Évalué à 5.
Il permet la mise à jour (via flathub ou ton repo dédié), ce que ne gère pas du tout appimage à ma connaissance.
« 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: Snap a bannir
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Il y a de quoi faire en sorte qu'une appimage se mette toute seule à jour.
Sinon il y a un catalogue et des applications qui l'utilisent pour faire les mises à jour.
Exemple: une application de bureau et une ligne de commande.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Snap a bannir
Posté par ff9097 . Évalué à 1.
Avec Flatpak l'intégration au système est parfaite, avec sandbox, avec support upgrade/downgrade
[^] # Re: Snap a bannir
Posté par Yth (Mastodon) . Évalué à 6.
Arf, ma première expérience avec Flatpack c'était pour Mindustry.
Au final, ça marche parce que je suis allé chercher le mindustry.jar de 47Mo au milieu des.. Je sais pas, 1,5Go de trucs installés ?
Et hop, java -jar mindustry.jar et ça roule !
Bref, je réessaierai un autre jour, un autre Flatpack, peut-être…
[^] # Re: Snap a bannir
Posté par nud . Évalué à 2.
Le flatpak de Mindustry en lui-même fait 216 MB.
Il utilise cependant le runtime "org.freedesktop.Platform" qui fait 695 MB mais qui est utilisé par virtuellement tous les flatpaks.
Une fois que tu as installé le runtime les apps suivantes deviennent moins coûteuses en espace disque.
[^] # Re: Snap a bannir
Posté par Yth (Mastodon) . Évalué à 6.
Oh mais je comprends tout à fait l'idée, et je n'ai pas d'a priori contre !
Je me disais même : ben c'est tout emballé, tout est inclus dedans, ça va tourner au poil, ça m'évite d'essayer d'avoir un JDK 14 pour compiler le bidule.
Et tout le bouzin snap s'installe, ça télécharge, ça installe et tout. Tout cet espace, après tout, si ça fonctionne, le prochain en prendra moins, et j'ai plein de place sur ma partition système.
Mais au moment de démarrer Mindustry, j'ai une erreur SDL et ça plante.
J'ai farfouillé un peu, vu qu'au bout du compte Mindustry était superbement empaqueté dans un unique .jar et que le flatpack passe par un script shell qui fait "java -jar mindustry.jar", alors je me dis que je peux le tenter en direct, après tout, j'ai toutes les dépendances sur ma machine !
Et là ça marche directement sans poser de questions…
J'ai tout viré et gardé uniquement le mindustry.jar et tout tourne au poil.
Bon, j'ai totalement perdu l'option de mise à jour, et pour changer de version, il faudra que je réinstalle tout le flatpack et que j'aille rechercher le nouveau mindustry.jar, donc ce n'est pas durable comme solution, et il n'y a pas de sandbox ni rien, mais bon, ça tourne, je joue :)
Donc je me demande où ils se sont plantés pour que « l'intégration au système est parfaite » sonne aussi faux dans mon cas.
Mais je t'avoue que je n'ai pas l'énergie d'essayer de comprendre là…
[^] # Re: Snap a bannir
Posté par barmic 🦦 . Évalué à 4.
J'ai 9 applications installées (8 de flathub) et j'ai…
J'm'en fou j'ai de la place, mais l'argument de la mutualisation pour moi il n'est que théorique.
J'aime aussi pas mal flatpak qui me dis que gnome 3.26 c'est tout pourri et que je devrais en parler aux dev, sans m'indiquer les dépendances (et puis bon ce genre de conteneurisation sert aussi un peu à ça).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Snap a bannir
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 2.
J'imagine que tu fais allusion à ce bug ? Apparemment il a été corrigé hier.
(à titre personnel, je serais curieux de savoir quelles applis de ton installation utilisent quels runtimes, parce que tout ça pour 9 applis seulement, ça me paraît beaucoup)
[^] # Re: Snap a bannir
Posté par barmic 🦦 . Évalué à 3.
C'est pas un secret
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Snap a bannir
Posté par Renault (site web personnel) . Évalué à 3.
Après c'est aussi le prix à payer pour que chaque application fonctionne quelle que soit ta distribution. ;)
Par ailleurs, il est fort probable que tu as des runtime rendus inutiles par les mises à jour des applications. Flatpak par défaut ne supprime pas les runtime quand ils deviennent inutiles (au cas où que tu installes une application qui en aurait besoin).
Personnellement dans ma procédure de mise à jour j'ai la commande :
Je suis sûr que tu as des runtimes qui seront désinstallés après ça.
[^] # Re: Snap a bannir
Posté par barmic 🦦 . Évalué à 3.
Merci j'ai perdu 1 version de gnome (il ne m'en reste que 3) et une version de KDE. Pratique d'indiquer ce qui est toujours utilisé ou non quand on demande la liste ou qu'on met à jour ⸮
Non, il y a d'autres choix possibles ton faux dilemme ne marche pas avec moi.
Tu peux avoir des parties plus petites et composables pour réduire ce qui est complètement inutile (mon wireshark n'a pas besoin de tout le KDE platform).
Tu peux faire du spécifique à la appimage.
Ce sont des choix (est-ce qu'il vaut mieux avoir 4 fois le même Qt ou un runtime de 1Gio). Ils sont fait en imaginant l'utilisation à voir comment ce sera utilisé. Je ne dis pas que flatpack est mauvais juste que la réutilisation c'est une chimère (particulièrement parce que ça sert entre autre à pouvoir varier les environnement comme là où j'ai un KDE et plusieurs versions de gnome). Entre autre parce que si tu utilise flatpak pour installer 25 applications qui demandent la même version de gnome, c'est peut être que tu avais juste besoin d'une distribution avec cette version de gnome.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Snap a bannir
Posté par Renault (site web personnel) . Évalué à 4. Dernière modification le 20 novembre 2020 à 15:43.
Ce n'est pas un faux dilemme dans le sens où la question du packaging a des problématiques et des critères de décisions qui n'a pas une solution optimale sur tous les critères. Tu dois faire des choix, privilégier certains critères au détriment d'autres. C'est de ingénierie classique.
Mais tout ça est possible avec Flatpak justement.
Tout le monde peut écrire son runtime (et donc découper autrement), tout le monde peut faire son Flatpak qui contient toutes ses dépendances à l'intérieur. Mais ça a aussi des inconvénients et c'est pour ça que les Flatpak que tu télécharges n'ont pas choisi cette voie.
Plus tu découpes les runtime, plus la maintenance est complexe, or les gens qui maintiennent ces runtime n'ont pas un temps infini. D'autant qu'ils sont maintenus principalement pour leur écosystèmes respectifs (GNOME et KDE) où donc la majorité des applications qui en dépendent vont en tirer pleinement partis. Puis tu perds en réutilisation s'il y a 20 000 runtimes différents qui permettent d'utiliser Qt 5.15 et que chaque application en utilise un différent.
Ensuite si chaque Flatpak embarque toutes ses dépendances à la AppImage, tu perds les bénéfices liés au runtime en terme de maintenance (dont de sécurité) et en mutualisation de ressources.
Mais bref, Flatpak autorise les comportements que tu décris, mais ceux qui les ont fait ont manifestement choisi de le faire autrement. Et ce n'est pas un mal en soit.
Ou si je veux avoir la dernière version de GNOME mais garder d'autres composants un peu plus ancien, je fais comment ? Ce n'est pas si simple.
Et tu passes outre les autres avantages de Flatpak : bac à sable, portails, etc.
[^] # Re: Snap a bannir
Posté par barmic 🦦 . Évalué à 2.
Ce n'est pas ce que disais.
Tout à fait et je crois que l'une des applications que j'ai est parti dans cette direction.
Encore une fois ? Il y a un large éventail de choix entre faire des runtimes d'1Gio et en faire des millions de 200Kio. AMHA le curseur n'est pas optimal, même pour la maintenance. Je pense que séparer à minima les toolkit et des environnements de bureau ne serait pas déconnant je suis pas convaincu que la plupart des app que j'ai installé utilisent des spécificité de l'un ou l'autre.
Encore une fois je pense que c'est un leurre. À part les hypothèses de concevoir des distributions entièrement basé dessus (ce qui n'est pas une bonne idée à mon avis) je doute que les gens installent 20 000 applications différentes avec. Se coupler avec une distribution et au détriment de tous les autres utilisateurs c'est un peu ce qui est reproché à snap.
Et en regroupant de trop aussi. Parce que tous les composants ne sont pas gérés par les même équipes, ni avec les même temps de cycles,…
Je n'ai fais que donner mon avis.
Tu installe la dernière version de gnome et les quelques autres composants via flatpak. C'est bien plus logique et à l'usage ce sera bien plus simple.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Snap a bannir
Posté par Renault (site web personnel) . Évalué à 4.
Et sans oublier le système de portails aussi.
[^] # Re: Snap a bannir
Posté par groumly . Évalué à 10.
Peut on utiliser 1000 fois 1000 logiciels? Tu veux un chewing gum?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Chromium de Linux Mint
Posté par Arthur Accroc . Évalué à 5. Dernière modification le 18 novembre 2020 à 18:37.
Du coup, si on considère en plus que Chromium n’est plus à jour sur Debian, mieux vaudrait prendre la version de Linux Mint. Surtout si on utilise une Ubuntu LTS, sur laquelle est basée Linux Mint.
En reprenant la procédure décrite dans le lien en fin du journal, j’arrive à ça (je ne sais pas trop s’il vaut mieux choisir la première version de Mint basée sur la 20.04 ou la dernière ; là, c’est la dernière) :
/etc/apt/sources.list.d/mint-for-nosnaps.list :
/etc/apt/preferences.d/mint-for-nosnaps :
Par contre
linuxmint-keyringne semble plus disponible sous Ubuntu. Je n’ai pas trouvé mieux que de le récupérer directement sur Linux Mint, ce qui n’est pas idéal du point de vue de la sécurité, surtout venant d’un site pas en https…« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Snap a bannir
Posté par zurvan . Évalué à 3. Dernière modification le 19 novembre 2020 à 09:36.
merci beaucoup pour cette information !
J'ai besoin de chromium (j'ai besoin de jitsi mais firefox, qui reste mon navigateur par défaut, plante lorsque j'essaye de l'utiliser avec jitsi, en particulier avec le partage d'écran), et suite à la mise à jour vers linux mint 20, j'ai vu que le paquet chromium était uniquement disponible en snap, à l'époque.
Vu les déconvenues que j'ai eu avec snap dans le passé, j'ai préféré installer chrome qui est fourni en .deb
Je pourrais donc maintenant installer chromium également.
Et je suis heureux de ne pas avoir installé chromium via snap si en plus des embêtements habituels liés à snap, c'est pour avoir des soucis supplémentaires de performance !
Au niveau de snap, il y a sans doute de bonnes idées, mais je trouve que globalement "l'expérience utilisateur" avec est assez catastrophique : certains programmes sont prévus pour n'écrire que dans le répertoire utilisateur "par sécurité", ce qui empêche notamment de les utiliser dans le dossier /tmp, exemple des déconvenues et du temps perdu à cause de ce truc : https://github.com/mikehaertl/php-pdftk/issues/150
Il est possible de modifier le comportement par défaut via des commandes cryptiques et compliquées. Ce n'était pas possible de réaliser une interface graphique pour gérer les droits et les permissions supplémentaires ? Et niveau sécurité, perso je peux comprendre les enjeux de ne pas péter tout l'OS, mais j'accorde plus d'importance à ce qui se trouve dans mon /home que dans /tmp
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Snap a bannir
Posté par ted (site web personnel) . Évalué à 4.
Si tu as besoin de Jitsi, tu peux utiliser la version codée avec Electron qui fonctionne bien:
https://github.com/jitsi/jitsi-meet-electron
Il y a juste à exécuter un Appimage pour s'en servir!
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: Snap a bannir
Posté par zurvan . Évalué à 2.
ah c'est intéressant ça, merci pour cette information !
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
# Chromium et Chromium par Debian ?
Posté par anubis . Évalué à 2.
Chromium c'est peut-être mieux que Chrome car libre, mais ça reste bourré de services Google activés par défaut.
Dans mes souvenirs, la version de Chromium dans Debian est plus proche de https://github.com/Eloston/ungoogled-chromium (limitant les fuites par défaut vers Google) que la version mainstream, mais je ne retrouve pas la source.
aussi sur le salon xmpp:linuxfr@chat.jabberfr.org?join
[^] # Re: Chromium et Chromium par Debian ?
Posté par Anonyme . Évalué à 1.
La version de Chromium dans Debian est surtout plus à jour depuis un moment (même au niveau des failles de sécurité).
Franchement, je préférerai que Debian drop Chromium complètement, ça éviterait de se casser la tête avec ce spyware.
[^] # Re: Chromium et Chromium par Debian ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 5.
Ça reviendrait à demander aux développeurs Web d'installer Chrome (la version de Google) pour pouvoir tester leurs productions sur ce navigateur.
La connaissance libre : https://zestedesavoir.com
# Commentaire du mardredi
Posté par Maclag . Évalué à 10.
Sinon installe la version de Mozilla. Elle a fait beaucoup de progrès récemment.
# quid de Nix ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
J'ai vu les échanges autour de Snap et Flatpack et je-ne-sais-plus. Puis une petite parenthèse sur les AUR et les overlays. Du coup, j'en suis arrivé à me demander s'il y a des usagers de Nix dans la salle, et si ce n'est pas une meilleure alternative.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: quid de Nix ?
Posté par tisaac (Mastodon) . Évalué à 2.
Tu peux aller voir les contributions de Nokomprendo ainsi que le dernier lien qu'il a posté.
Pas toujours simple à comprendre mais très intéressant.
Surtout, ne pas tout prendre au sérieux !
[^] # Re: quid de Nix ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Il faut le pratiquer pour le comprendre
:-)et je m'y suis mis récemment;-)Merci pour la référence ; j'ai d'ailleurs trouvé un journal qui va dans le sens de ma question : users/nokomprendo-3/journaux/flatpak-et-nix
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: quid de Nix ?
Posté par nokomprendo (site web personnel) . Évalué à 2.
Normalement, on peut utiliser Nix sur n'importe quelle distribution mais il y a un réglage de libGL à faire pour les applis graphiques. Je ne connais pas bien ce cas d'usage mais ça doit se résumer à :
nix-env -iA nixpkgs.chromium)[^] # Re: quid de Nix ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
c'est AppImage dont je ne me souvenais plus au moment de la rédaction (et j'ai eu la flemme de rechercher et d'éditer mon commentaire pendant la période permise ; toutes mes excuses)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: quid de Nix ?
Posté par barmic 🦦 . Évalué à 2.
Nix ne répond pas tout à fait à la même problématique.
Il y a plusieurs problématiques différentes:
Et les différentes solutions se basent sur une façon d'imaginer les choses.
nix, guix et pkgsrc permet surtout d'installer des logiciels sans impact sur le reste du système. Cela apporte des choses en plus et nixos pousse ça à tous l'ensemble du système. Mais on est sur un modèle à dépôt. Tu fais inclure ton logiciel dans le dépôt et il est dispo (tu peux fournir un script nix pour faire l'installation, mais c'est pas l'usage nominal).
snap et flatpack se concentre sur le sandboxing. L'idée c'est qu'un logiciel n'accède pas à tout tes fichiers par exemple. C'est très pratique pour des logiciels propriétaires. Moi par exemple j'ai besoin de teams pour travailler, mais je préfère qu'il soit dans une sandbox. Les 2 fonctionnent sur la base de dépôt, mais flatpack, mais en avant le fait que chacun peut créer un dépôt et donne la possibilité d'installer un fichier unique. En ça il vient aussi sur les cas d'usage des PPA par exemple.
appimage c'est vraiment un fichier que tu prend, tu lance, ça marche. Pas d'autres question, c'est très très pratique, même s'il n'a pas certaines bonnes propriétés qu'on les autres (il n'y a rien pour savoir/simplifier la mise à jour, l'utilisateur doit gérer ces fichiers les mettre dans son
$PATH, etc).Après il y en a eu un paquet des solutions 0install, klik, runz,… sachant que AUR, les PPA et probablement d'autres solutions spécifiques à des distributions se rapproches de ses solutions.
Il est vraiment difficile de ne pas y voir une xkcd #927, avant c'était la galère, il fallait packager pour deb, rpm, tarbal,… maintenant il y a appimage, flatpack, snap, nix,… et tu peux continuer à packager pour les classiques
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: quid de Nix ?
Posté par nokomprendo (site web personnel) . Évalué à 2.
Que veux-tu dire par "Tu fais inclure ton logiciel dans le dépôt" ?
Pour moi, Nix est, justement, très pratique pour packager soi-même des projets : https://linuxfr.org/news/gestion-de-paquets-et-devops-avec-nix-tour-d-horizon-sur-un-cas-concret#toc-construire-et-installer-le-paquet-duprojet
D'ailleurs, nixpkgs n'est pas uniquement une logithèque mais avant tout un ensemble de fonctions pour construire des logiciels. Par exemple, en lançant automatiquement des commandes autotools, cmake, python/pip, etc.
[^] # Re: quid de Nix ?
Posté par barmic 🦦 . Évalué à 2.
Tu as peut être évité de lire la parenthèse? Ça ne me paraît pas être le cas nominal. La page d'accueil présente immédiatement le nombre de paquet du dépôt, la page de features n'en parle pas et mentionne différentes commandes s'appuyant sur le dépôt,…
C'est tout à fait possible de le faire, mais je n'ai pas encore vu quelqu'un fournir de script nix hors du dépôt et d'exemples.
J'ai l'impression que c'est utilisé par les utilisateurs eux-même (tu dérive un paquet ou tu en crée un et tu l'utilise ou le lance sur l'ensemble de tes machines). Je n'ai pas vu d'upstream le faire, mais je peux me tromper.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: quid de Nix ?
Posté par nokomprendo (site web personnel) . Évalué à 2.
Nix est peu connu donc on ne risque pas de voir, par exemple, vscode fournir un script Nix. Mais dans la communauté Nix, il est assez courant de proposer des scripts/paquets en dehors de nixpkgs : home-manager, cachix, nixGL, nur…
https://github.com/nix-community/home-manager#home-manager-using-nix
https://github.com/cachix/cachix#installation
https://github.com/guibou/nixGL#installation
https://github.com/nix-community/NUR#installation
[^] # Re: quid de Nix ?
Posté par barmic 🦦 . Évalué à 2.
Ce n'est pas non plus mis en avant.
Alors NUR pas vraiment et c'est assez logique, c'est juste une conf de nix et pas une installation de logiciel, mais oui c'est assez logique qu'ils s'en servent.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: quid de Nix ?
Posté par nokomprendo (site web personnel) . Évalué à 2.
Oui mais non. NUR demande effectivement une étape de configuration mais après tu fais bien des installations hors nixpkgs (ou du moins sur un nixpkgs augmenté), par exemple :
Et pour en revenir au "cas nominal" de Nix, je pense que justement c'est plus de gérer nos propres environnements de développement que d'installer un logiciel de nixpkgs. D'ailleurs, la page de doc du site aborde très souvent les "developer environments" (https://nixos.org/learn.html).
[^] # Re: quid de Nix ?
Posté par barmic 🦦 . Évalué à 2.
Non c'est juste un paquet qui est sur nur et qui sert à vérifier qu'il est bien installé (et ce n'est pas un paquet comme on l'entends ailleurs car il ne fais qu'un hello world en nix sans ajouter de fichiers).
Tout à fait et je pense qu'il est très pratique pour ça quand on a des dépendances qui sont intriquées avec le système (en js c'est osef par exemple).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: quid de Nix ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 22 novembre 2020 à 23:58.
De ce que j'avais compris (mais je peux me tromper), le dépôt est une facilité de plus mais que Nix pourrait s'en passer… L'idée est surtout de réutiliser un une installation qui a les caractéristiques demandées, si elle existe, sinon de la construire ; un peu comme on fait avec AUR (Arch et dérivés) ou les Overlays (Gentoo et dérivés) avec l'isolation en plus. C'est justement une autre discussion dessus qui m'a fait poser la question de savoir si Nix est envisageable…
Ici le bac à sable est il comparable à un conteneur ? (i.e. Docker ou LXC par exemple) ou similaire (chroot ou jail) ? Ou est-ce comparable à un à une machine virtuelle ? (à la Java par exemple)
Je pose la question parce-que je n'utilise pas et que je n'ai jamais pris le temps d'aller chercher les spécifications et le code sous-jacent.
Ah… On est quand même sur un modèle à dépôt(s) aussi…
En gros c'est comme un binaire qui embarque le maximum statiquement ? (genre un exécutable produit par Go par exemple)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.