Ubuntu, snap et frugalité

a marqué ce sujet comme résolu.

Bonsoir,

Sur Ubuntu 18.10 (si je me trompe pas), j’ai notamment Chromium et Spotify installés via snap.

Régulièrement ma machine quasi-freeze car la RAM est pleine (16 GB quand même..) et ça commence à swapper sévère.

Pourtant mon utilisation est vraiment limitée, un chromium avec une dizaine d’onglets, un spotify, un VSCode et c’est à peu près tout. De temps en temps l’interface Steam.

Honnêtement vu l’utilisation, si on retourne dix ou quinze ans en arrière, y’en a pour 500 mb de RAM à peine. Un PC de bureautique à 150 balles devrait suffire à faire ce que je fais. Or ce que j’ai c’est un PC gamer bien bourrin qui vaut plus de 1000 balles et qui a moins de 2 ans, et après 20 onglets et 1h de spotify il est en PLS absolue.

Comment ça se fait que chromium, avec un seul onglet, lance 9 processes principaux, avec une mémoire résidente totale de 1.5 GB ? Comment ça se fait qu’avec juste :

  • 1 chromium avec 1 onglet
  • 1 terminator
  • 1 keepass
  • 1 vs codium
  • 1 libre office calc presque vide

Je suis déjà à 4 GB utilisés sur 16, 180 processes principaux et … 580 threads !?

WTF ?

Et régulièrement aussi je constate que les applications installées via snap, chromium et spotify, ont des dizaines et des dizaines de threads résiduels que je dois kill après avoir complètement fermé l’app ?

Plus personne sait coder ou quoi ? C’est quoi cette utilisation délirante des ressources ? C’est quoi cette multiplication sans limite des threads ? C’est quoi ces fuites de mémoire et de threads morts par paquets de 30 ?

Est-ce que vous êtes au courant de bugs dans ces apps, dans snap ? Ou est-ce que tout le monde code juste avec le cul depuis quelques années ? Genre Spotify et Steam je suis sûr déjà que leur UI c’est juste un webkit avec un énorme framework JS et rendu HTML, qui spawn un renderer, un machin, un truc, et que ça prend 1 GB de RAM juste pour afficher la vue d’accueil… Mais bon, est-ce que vous avez des alternatives, ou des bugs connus qui permettraient d’expliquer tout ça ?

Bonne soirée ^^

+1 -1

Yep, deal with it.

C’est un totalement un exemple de la loi de Wirth.

Personne n’y échape. J’ai un PC minimaliste, 500MB pour juste le système de base. 700MB juste pour Firefox. Je compense avec beaucoup de RAM et tout autant de swap sur un SSD. Mais des applications comme libreoffice ne prennent rien en RAM (~120MB).

+1 -0

Snap, je ne connais pas. Mais je suppose que c’est à peu près la même histoire que Google Chrome.

Chrome part du principe que de la RAM inutilisée ce sont des ressources gâchées. De plus, il a un besoin énorme de mémoire pour pouvoir garantir une isolation des processus ainsi qu’une communication inter-processus. Chaque onglet est indépendant des autres. Un dernier point est le cache qui prend beaucoup de place mais qui potentiellement réduit le nombre de requêtes à effectuer et donc accélère le chargement des sites.

+0 -0
  • fuites mémoire dans Chromium
Society

Il se peut que ça ne soit pas des fuites de mémoire mais des pages qui s’alourdissent en les laissant ouvertes. J’ai remarqué ça avec discordapp.com et messenger.com (avec le Task Manager intégrée à Firefox, qui permet de voir la consommation par onglet/extension).

Edit, le sujet me fait penser à ça (une tribune a été faite à ce sujet je crois, mais c’est plus simple pour moi de retrouver le lien original).

Genre Spotify et Steam je suis sûr déjà que leur UI c’est juste un webkit avec un énorme framework JS et rendu HTML

Oui, c’est exactement ça.
S’ils n’ont pas fermé l’API, il existe des clients alternatifs pour Spotify. Dont certains en console (super légers, donc). Mais je ne sais pas s’ils sont aussi stables que l’application ««« native »»» officielle, en revanche. À essayer, éventuellement.

Pour Chromium, tu peux éventuellement le fermer quand tu n’en a plus besoin histoire que Linux se charge de libérer la mémoire qui a fuité, au cas où ça serait le cas. Pour FF, ça serait la même chose je pense.

Sinon, t’es à combien de jours d’uptime ?

C’est un totalement un exemple de la loi de Wirth.

ache

J’ai de grosses réserves sur les "lois" type loi de wirth, et autres "c’était mieux avant". Les gens ne codaient pas mieux avant, il y avait des bugs des crashs et des failles de sécurité partout, c’était pire qu’aujourd’hui, et les gens ne codaient pas la même chose.

Aujourd’hui, on veut des rendus graphiques jolis, qui impliquent de gros volumes d’assets graphiques et un appel au GPU dès qu’on veut dessiner quelque chose, on ne veut plus avoir à gérer les versions des libs et on recopie les libs avec chaque programme (parce que c’est ça, Ubuntu Snap), on veut des recommandations à chaque caractère qu’on écrit (autrement dit, des softs qui font un accès en base de donnée à chaque caractère qu’on tape, et on va mettre la BDD en RAM pour que ce soit rapide) et enfin, on veut utiliser des processeurs multi-cœurs. Ce dernier point veut dire que le programme doit être écrit de façon à ce que chaque traitement soit géré indépendamment. Au niveau OS, ça veut dire un thread par traitement, qu’on fait spawn avant le traitement parce que faire spawn le thread au moment du traitement ça prendrait du temps, alors que l’empreinte mémoire d’un thread est négligeable sur un PC aujourd’hui.

Si vous êtes vraiment prêt à utiliser les softs avec les niveaux de feature d’il y a 15 ans, utilisez gvim, links et consorts. Ca marche nickel dans un système avec 22MB de mémoire non volatile (bon, vim, pas gvim, j’ai pas weston dans un rootfs de cette taille).

+1 -0

J’ai aussi ce problème, et ça me désespère de l’informatique au plus haut point. Mon téléphone, un Xperia Z2 qui a un Snapdragon 801 et 3Go de RAM, est aussi rapide que mon Thinkpad X250 pour un usage équivalent. Pourtant il fait tourner beaucoup plus de mouchards et d’applis inutiles en arrière-plan.

Vous pensez que ça peut encore se trouver des logiciels vraiment minimalistes ?

+0 -0

C’est un totalement un exemple de la loi de Wirth.

ache

J’ai de grosses réserves sur les "lois" type loi de wirth, et autres "c’était mieux avant". Les gens ne codaient pas mieux avant, il y avait des bugs des crashs et des failles de sécurité partout, c’était pire qu’aujourd’hui, et les gens ne codaient pas la même chose.

Aujourd’hui, on veut des rendus graphiques jolis, qui impliquent de gros volumes d’assets graphiques et un appel au GPU dès qu’on veut dessiner quelque chose, on ne veut plus avoir à gérer les versions des libs et on recopie les libs avec chaque programme (parce que c’est ça, Ubuntu Snap), on veut des recommandations à chaque caractère qu’on écrit (autrement dit, des softs qui font un accès en base de donnée à chaque caractère qu’on tape, et on va mettre la BDD en RAM pour que ce soit rapide) et enfin, on veut utiliser des processeurs multi-cœurs. Ce dernier point veut dire que le programme doit être écrit de façon à ce que chaque traitement soit géré indépendamment. Au niveau OS, ça veut dire un thread par traitement, qu’on fait spawn avant le traitement parce que faire spawn le thread au moment du traitement ça prendrait du temps, alors que l’empreinte mémoire d’un thread est négligeable sur un PC aujourd’hui.

Si vous êtes vraiment prêt à utiliser les softs avec les niveaux de feature d’il y a 15 ans, utilisez gvim, links et consorts. Ca marche nickel dans un système avec 22MB de mémoire non volatile (bon, vim, pas gvim, j’ai pas weston dans un rootfs de cette taille).

Jacen

Le problème c’est que moi je veux juste éditer des fichiers texte, voir des pages web et écouter de la musique. Je n’ai pas plus d’exigences au niveau des features qu’il y a 15 ans. Je me fiche de l’auto-complétion, je la désactive à chaque fois. Mais les logiciels consomment un max de ressources pour préparer un milliard de trucs dont je n’ai pas besoin. Il y a 15 ans sur une bécane dix fois moins puissante je faisais la même chose avec Notepad++, Firefox et Vlc. Ca prenait 100 MB de RAM et ça faisait exactement pareil.

Vous pensez que ça peut encore se trouver des logiciels vraiment minimalistes ?

rezemika

Les logiciels de Suckless, peut-être : http://suckless.org/

sgble

C’est un comble, vu le thème, que leur site prenne dix secondes à charger alors que vu la tronche du site il doit pas peser plus de 10 KB. :D

+0 -0

Le problème c’est que moi je veux juste éditer des fichiers texte, voir des pages web et écouter de la musique. Je n’ai pas plus d’exigences au niveau des features qu’il y a 15 ans. Je me fiche de l’auto-complétion, je la désactive à chaque fois. Mais les logiciels consomment un max de ressources pour préparer un milliard de trucs dont je n’ai pas besoin. Il y a 15 ans sur une bécane dix fois moins puissante je faisais la même chose avec Notepad++, Firefox et Vlc. Ca prenait 100 MB de RAM et ça faisait exactement pareil.

Installe dwm, neovim, firefox vlc et crée toi ta propre config minimaliste.

C’est un comble, vu le thème, que leur site prenne dix secondes à charger alors que vu la tronche du site il doit pas peser plus de 10 KB. :D

Society

16Ko, mais ça prend moins d’un dixième de seconde à charger chez moi.

+0 -0

Le problème c’est que moi je veux juste éditer des fichiers texte, voir des pages web et écouter de la musique. Je n’ai pas plus d’exigences au niveau des features qu’il y a 15 ans. Je me fiche de l’auto-complétion, je la désactive à chaque fois. Mais les logiciels consomment un max de ressources pour préparer un milliard de trucs dont je n’ai pas besoin. Il y a 15 ans sur une bécane dix fois moins puissante je faisais la même chose avec Notepad++, Firefox et Vlc. Ca prenait 100 MB de RAM et ça faisait exactement pareil.

Installe dwm, neovim, firefox vlc et crée toi ta propre config minimaliste.

C’est un comble, vu le thème, que leur site prenne dix secondes à charger alors que vu la tronche du site il doit pas peser plus de 10 KB. :D

Society

16Ko, mais ça prend moins d’un dixième de seconde à charger chez moi.

ache

Mais ce que je trouve dingue c’est de devoir en arriver là, malgré la puissance de ma machine et la simplicité de mon usage. Il doit y avoir un problème quelque part, ça ne peut pas être que par loi de Wright. Je soupçonne vraiment Snap de faire de la merde déjà, parce que c’est avec ces applications que j’ai le plus de problèmes.

+0 -0

Je soupçonne vraiment Snap de faire de la merde déjà, parce que c’est avec ces applications que j’ai le plus de problèmes.

Society

Pourquoi utilises-tu Snap ?

Edit, le sujet me fait penser à ça (une tribune a été faite à ce sujet je crois, mais c’est plus simple pour moi de retrouver le lien original).

tleb

Lien vers le billet commenté (où j’ai exprimé mon point de vue par ailleurs)

Renault

Une autre approche, mieux ?

Une autre approche, mieux ?

Je n’aime pas ce genre d’articles car ils ont de bonnes critiques mais qu’ils généralisent soit trop ou en oubliant aussi certains avantages. Il faut savoir aussi prendre du recul et mettre en balance ce qu’on a gagné.

C’est facile de dire que les logiciels sont lourds pour faire globalement la même chose qu’avant. Mais les logiciels d’aujourd’hui sont en général plus fiables, plus portables, plus jolies graphiquement, parfois plus simples d’utilisation, ont de la cryptographie pour protéger les données sensibles, le code derrière est probablement plus lisible et exploitable, etc. Oui, cela a un coût en terme de complexité (beaucoup de couches intermédiaires) ou de lourdeur. Mais il ne faut pas oublier le gain obtenu malgré tout.

Cela ne retire pas que oui il y a des logiciels mal conçus et inutilement lourdingues. Mais je ne crois pas que cela soit spécifique à notre époque (c’était vrai avant aussi) ni que cela soit de nature à remettre en cause que des logiciels grossissent légitiment.

+1 -0

Je soupçonne vraiment Snap de faire de la merde déjà, parce que c’est avec ces applications que j’ai le plus de problèmes.

Society

Pourquoi utilises-tu Snap ?

Si je dis pas de conneries, j’ai simplement installé ces applications via la logithèque. J’ai supposé que comme Snap est mis en avant par Ubuntu comme une alternative avantageuse aux paquets et que c’est la méthode qui a été utilisée par la logithèque, c’est la meilleure. Mais effectivement je n’ai pas creusé plus le sujet.

Une autre approche, mieux ?

Je n’aime pas ce genre d’articles car ils ont de bonnes critiques mais qu’ils généralisent soit trop ou en oubliant aussi certains avantages. Il faut savoir aussi prendre du recul et mettre en balance ce qu’on a gagné.

C’est facile de dire que les logiciels sont lourds pour faire globalement la même chose qu’avant. Mais les logiciels d’aujourd’hui sont en général plus fiables, plus portables, plus jolies graphiquement, parfois plus simples d’utilisation, ont de la cryptographie pour protéger les données sensibles, le code derrière est probablement plus lisible et exploitable, etc. Oui, cela a un coût en terme de complexité (beaucoup de couches intermédiaires) ou de lourdeur. Mais il ne faut pas oublier le gain obtenu malgré tout.

Cela ne retire pas que oui il y a des logiciels mal conçus et inutilement lourdingues. Mais je ne crois pas que cela soit spécifique à notre époque (c’était vrai avant aussi) ni que cela soit de nature à remettre en cause que des logiciels grossissent légitiment.

Renault

Tout à fait, mais j’ai quand même l’impression que d’une le curseur a glissé du user-friendly vers le developer-friendly, et que de deux les différents aspects que tu évoques sont dans une certaine mesure antagonistes mais aussi dans une certaine mesure orthogonaux, et on néglige souvent les performances, alors qu’elles pourraient dans bien des cas être améliorées sans dégrader significativement les autres aspects, simplement car les utilisateurs se contentent d’un certain niveau de performances et qu’on considère donc inutile ou pas rentable d’aller plus loin.

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte