freem a écrit 5059 commentaires

• d'abord la taille des binaires qui va augmenter

Dans quelle mesure? Est-ce significatif par rapport au système?
Si je prend, par exemple, busybox de debian, le binaire statique pèse 1.9 megs.
Celui de la version dynamique pèse ~700 kilos.

Si j'ajoute le poids des libs:

• /lib/x86_64-linux-gnu/libresolv-2.28.s 91K
• /lib/x86_64-linux-gnu/ld-2.28.so 162K
• /lib/x86_64-linux-gnu/libc-2.28.so 1.8M

Comme tu peux le voir, oui, dans le cas de la gblic ça va être pertinent, parce qu'elle est utilisée par l'ensemble du système. D'ailleurs, la plupart des appimage n'embarqueront pas de libc.
Par contre pour des libs peu usitées, je ne suis pas certain que ça soit si rentable que ça.

La conso de mémoire, par contre: dynamique:

% ps -orss,vsz,args $(pidof busybox )    
  RSS    VSZ COMMAND
 2260   3156 busybox sh

Statique:

% ps -orss,vsz,args $(pidof busybox )
RSS VSZ COMMAND
4 2212 busybox sh


Donc, plus gros, oui, mais ou? Sur le disque ou en mémoire? Lequel est le plus important?

et surtout en cas de faille de sécurité sur une lib (au hasard la libc), il faut recompiler tout le système

Non, juste relinker.
A ma connaissance, il n'existe que des distros qui filent soit les sources, soit les binaires finaux. Rien n'empêcherais en théorie une distro de filer les objets, et de juste faire le link à l'install.
Bien sûr, ça me semble très compliqué à réaliser, mais au niveau perfs, ça permettrait justement de ne link dynamique qu'a partir d'un certain nombre d'utilisations, voire en fonction de la fréquence d'usage.

Et question sécurité, pour le coup, l'avantage du link statique, c'est qu'on ne peux pas injecter de code avec un simple "export LD_PRELOAD=foobar" (ce qui est pratique pour le debug!).
De même, le bug de ta lib ne sera pas forcément dans tous les binaires, justement, contrairement au link dynamique.

D'ailleurs, le link statique est, il me semble, le chemin pris par go et rust, qui ont le vent en poupe ces derniers temps.

Bref, je pense que les deux approches sont valides, chacune brille a son niveau.
Les arguments que tu cites, même valides, ne sont que partiels (poids? En ram le static bouffe moins. Sécurité? Plus compliqué d'injecter du code, surface d'attaque réduite).

Il serait possible de mettre un capteur à l'extérieur aussi, et donc de faire le comparatif (par l'électronique, j'entend)?
Cette logique est de toute façon valable dès lors que l'on cherche à savoir s'il faut faire circuler un flux entre 2 zones pour améliorer la qualité de l'une (au détriment de l'autre): si on ne s'assure pas que la zone avec laquelle on échange est mieux, on risque évidemment de réduire la qualité de la «zone utile».

Enfin, forcément, ça ne serait pas beaucoup mieux puisque la pollution, ce n'est pas nécessairement du CO2, de même que le CO2 n'a rien à voir avec le taux .

Bonne remarque.

Ce que je voulais dire, c'est que la grande majorité de l'ecosysteme du C, du C++, me semble (oui, je mets de l'eau dans mon vin) oublier que le lien statique existe. On ne se pose quasi plus la question: le dynamique à plus de possibilités, donc autant l'utiliser.
Moi, j'ai un peu de mal avec ça,même si je sais que parfois c'est nécessaire, je pense que pour la majorité des applications que, moi, j'ai, ce serait plus efficace sur la perf et ferai utiliser du matos plus vieux.

Note: l'heure. Desolé :)

D'accord, donc tu mets des mots ensemble sans comprendre que le rendu final peut être insultant? Mince, je t'avais surestimé. Désolé. Je recommencerais pas.

AppImage, c'est comme un docker

Pas vraiment, c'est beaucoup moins évolué. AppImage, c'est simplement une image disque (nécessite fuse) qui contiens, comme tu l'indiques ensuite, d'une part le binaire, et d'autre part une partie des ressources dont le binaire à besoin, ce qui implique généralement une partie des bibliothèques partagées.

Bon, c'est plus qu'une image disque, puisque ça s'exécute, donc il y a une sorte de "bootloader", qui va également indiquer ou sont les libs à l'intérieur (on ne peux pas compter sur le ld de la distrib pour ça, l'organisation est probablement différente entre le côté "natif" et le côté "embarqué").

Autre point de différence par rapport à docker: pas de gestion de namespace, de cgroups et autres, sauf si c'est fait par l'appimage elle-même (peu probable), c'est donc "moins sécurisé". D'un autre côté, c'est aussi nettement plus simple techniquement et portable, ce qui a des avantages non-négligeables.

Le logiciel de ta distribution, lui pourra utiliser les bibliothèques prechargées par un autre logiciel si c'est le cas, sinon devra aussi charger les bibliothques nécessaires.

C'est valable également pour une partie des libs de l'appimage, celle-ci se reposant partiellement sur le système.

C'est d'ailleurs un point que j'ai tendance a reprocher tout en connaissant une partie de la réponse: pourquoi ne pas juste lier statiquement les libs partagées? Ça mènerait à une amélioration des performances après tout. Bon, la réponse, c'set que les écosystèmes C et C++ sont tellement partis dans le délire du link dynamique depuis tellement longtemps que lier en statique est bien souvent méga pénible et expose a des tonnes d'emmerdes.

Pour ce qui est de la performance, on pourrait avoir de meilleurs performances avec une appimage comparé à une installation système, sur un disque dur mécanique, du au fait que les données de l'appimage seront plus groupée, donc moins de déplacement de la tête de lecture.
Plus trop d'actualité, et l'impact est assez mineur (appimage sert surtout pour des applications de bureau à ma connaissance). Le reste, le travail de ld, ben… ça c'est totalement aléatoire: si le dev à lié en statique le binaire dans l'appimage (pourquoi pas, après tout? ça permets d'avoir les données à côté et le fichier est simple a "installer" et exécuter: chmod +x $foo && ./$foo) alors il y a fort à parier que les performances soient plus élevée. Mais la distro aussi pourrait lier en statique.
Il y a aussi, bien sûr, de nombreux autres facteurs: options de compilation, compilateur utilisé, différence de version des libs chargées par l'un ou l'autre… tout peut impacter la performance, donc on peut pas chiffre.

Tu devrais apprendre à lire, et à réfléchir avant d'essayer d'insulter.

ça c'est la faute du BIOS, non ? C'est à lui de gérer les claviers dans ce mode.

Pas que.
De l'UEFI, de grub, de lilo, de syslinux, aussi. Et de l'USB, potentiellement, ou du clavier même?
En fait, comme toi, je sais pas, je sais pas a quoi ressemble le code derrière, je sais juste que c'est aléatoire selon le clavier, la machine et la pile logicielle.
Je ne doute pas beaucoup que PS/2 notamment est plus simple technologiquement, même si je n'ai pas de preuve ni de certitude (déjà, point de hub, mais du point à point?)

C'est beau, la théorie. Dans la pratique, on va te dire que le matos marche, alors que les composteurs sont souvent aléatoirement en panne, et quand ils marchent il faut retourner le billet dans les 20 sens différents… Oui, 20 sens différents, pour un billet qui n'en a que 4.

Et tu crois qu'il se passe quoi, si je refuse de filer date de naissance, numéro de téléphone, et autres info douteuses aux automates de la gare du Havre qui ne te laissent pas prendre connaissance de tes droits, quand tu vas causer avec le contrôleur? Lui il en a rien foutre, de ta vie privée et de tes droits, il veut juste passer en speed dans le train prendre son café. Sinon, il passerait aussi quand le train est bondé à cause du train précédent annulé…

Je cite:

Ok on a des sites plein de JS qui mettent plusieurs secondes à char­ger mais c’est à compa­rer à avant où la moindre page quasi vide se char­geait en plus de temps que ça.

Avant, le délai était énormément lié au temps de transfert. Forcément, avec une liaison 56K… mais ça, c'est lié au réseau.
De nos jours, les sites sont lents, mais il arrive souvent que le problème soit le CPU, et ça, ben, c'est lié au site.

C’est la même chose côté compa­ti­bi­lité.

Ok aujourd’­hui on a parfois des choses qui ne passent qu’a­vec Chrome mais avant c’était tout le web qui était dans une guerre de tran­chée.

Ouai. Aujourd'hui, c'est apple vs google vs mozilla, principalement.
Avant, c'était microsoft vs netscape (mozilla).
Ah… oups en fait?

Aujourd’­hui je ne me pose quasi­ment plus la ques­tion du navi­ga­teur. Je sais que ça va fonc­tion­ner.

Chez moi ça marche (tm). Ben chez moi ça marche pas, marque de merde! Certains sites marchent sous FF, d'autres sous chrome, la plupart sur les deux.

Ce n’était pas non plus plus utili­sable.

Les exemples mis en avant sont valides, pour le coup. Mais j'ai quand même un contre-exemple: ouvrir un lien dans un nouvel onglet. Plus possible: le lien, c'est du JS.

On s’est amélioré sur tous les points, sans excep­tion. Le pire d’aujourd’­hui est objec­ti­ve­ment souvent meilleur que le meilleur de l’époque.

hum… pour de simples sites web, sans vidéo, on est obligés de migrer l'infra vers la fibre ou la 5g, a cause de l'abus d'images (bien souvent qui n'apportent strictement rien).
Ce n'est pas un progrès. Ce n'est, certes, pas lié au web en soit, mais à son usage par les développeurs…

En fait une partie des appli­ca­tions web

Je crois que le problème, il est la. Ici. Sur le mot applications. On a voulu faire du web un système d'exploitation, littéralement. Je doute fort que ça soit adapté par exemple aux blogs.
L'accumulation de technos et autres hacks fait qu'il est impossible d'écrire un client propre et 100% fonctionnel (dillo, netsurf essaient, mais rien que les CSS cassent de partout, JS n'est pas supporté) alors que le web se voulait décentralisé (hyper-liens) on se retrouve avec une poignée de moteurs de rendu développés de façon hyper centralisée.
Les développeurs de site, eux, utilisent la plupart du temps des frameworks pour masquer le bordel et les problèmes de compat, ce qui ne risque pas de rendre la chose plus légère…

C’est juste que les compro­mis et les équi­libres ne pointent pas si souvent que ça dans cette direc­tion.

Bien d'accord. Et c'est peut-être un des problèmes, justement.

Prétendre faire un nouveau web qui force­rait ce choix ne serait pas une avan­cée, ce serait une forte régres­sion.

Non. Ce serait une avancée.
Parce que le «nouveau web» serait spécialisé et meilleur dans son domaine. Tout comme le web actuel est spécialisé dans les applications interactives, rendant la création d'un blog sous-optimale. Le web d'avant permettait à un ado de faire son propre site web en 3 coups de cuillères à pot.
Aujourd'hui, c'est difficilement faisable sans utiliser une pile logicielle extrêmement lourde, pour un rendu final potentiellement identique (parce que bon, le classique titre+menu-a-gauche+contenu, ça reste plutôt efficace).

Ce n'est pas si surprenant… personnellement, je ne pense pas que «les développeurs web» en aient quoique ce soit à cirer du côté système ou de la maintenance. On parle du web la, la pile de technologies qui:

• est si mouvante que même Debian met à jour Firefox tous les 3 mois (ou un truc du genre) rompant de ce fait la promesse d'un système stable.
• est si complexe que seuls 3 groupes, dont 2 ont une base de code ayant la même origine, sont encore capables de développer un moteur de rendu «standard»
• pour être moderne se doit d'utiliser JS pour un stupide lien de type ancre (dans la même page). En fait, pour n'importe quel type de lien… exécuter du script au lieu d'utiliser le mécanisme standard, parce que seul le web mérite d'utiliser les ressources systèmes!

J'avais l'impression que tu ciblais juste les devs, mais dans tes examples ce ne sont pas nécessairement des devs qui sont impliqués?

Ça pourrait aussi être, tout simplement, du thrashing.
Pas simple de diagnostiquer ça sans avoir un outil de monitoring qui tourne constamment… perso j'utilise xosview, mais je ne doute pas qu'il en existe une chiée.
Avec un disque dur mécanique, on peut aussi utiliser… ses oreilles :) mais bon, de nos jours c'est plus trop d'actualité.

Bref, en gros, si quelques applis ont des fuites mémoire, ça peut vite pousser au thrashing, et la, reboot obligé (parce que l'oom-killer du kernel fait très, très mal son job de ce côté).
Pour contrer ça, j'ai appris récemment l'existence d'un outil nommé earlyoom, un oomkiller qui interviens avant le kernel, et surtout, avant que tout parte en couilles. Je ne sais pas ce qu'il vaut par contre, perso je me contente de désactiver l'overcommit (mais je connais les symptômes et je sais désactiver, je ne conseille pas de l'utiliser sans un minimum de connaissances système).

plus personnes ne comprend ce qu'il se passe

Je ne suis pas entièrement d'accord… je pense que certains comprennent. Notamment ceux qui ont acquis les bases avant d'apprendre l'info à l'école.

Je dis ça, parce qu'une phrase bien précise m'a braqué contre mes profs lors de mon BTS IRIS: "le client rachètera de la RAM".
IRIS, ça voulait dire: Informatique et Réseaux pour l'Industrie et les Services techniques hein, donc la perf et le vieux hard auraient du être omniprésents dans le principe au moins… c'était en 2000 et des bananes, C99 était déjà sorti depuis plusieurs années, et on nous enseignait encore int au lieu de int32_t: ben oui, on peut racheter de la ram, ça coûte moins chez qu'une minute d'un dev (sauf que c'est pas juste la ram, mais aussi la sram, sans parler des problèmes de compat entre les archis…).

Bon, en vrai, je les avais déjà grillés… 1er mois de cours, le prof avait sorti un truc genre "la solution opti, c'est if( foo == true ){ ... } else if( foo == false ) { ... }"… et quand j'ai pointé du doigt le problème (supposé, parce que le compilo… mais bref) "mais on s'en fout" fut la réponse (et non pas un argument logique type: le compilo optimise).
J'étais très (et je suis encore) content d'avoir commencé l'apprentissage du code comme un sauvage, 3-4 avant les «études supérieures»…

Je ne sais pas, cependant, s'il est aussi facile de trouver des ressources de qualité sur le net pour apprendre à coder… à l'époque (ou j'ai commencé), google était petit, les livres d'or courants, et le multi-coeur ou linux inconnus du grand public (moi-même ai appris au sujet du LL plus d'un an après avoir appris les bases du code)

Tu oublies le bouton turbo qui, en fait, underclock le CPU :)

Ah ça … les ptits jeunes savent pas la chance qu'ils ont avec :

les claviers USB

Sauf que les claviers USB marchent pas si bien avec le noyal dont le nom de ce site est tiré… je me retrouve de temps en temps, via cette blagueuse de debian, a être sous initramfs (ouai, je bricole mon boot parfois, quand je toupine) et la… ha ben non, le clavier usb, il marche pas…

Je n'avais pas les compétences à l'époque pour juger, mais les claviers PS/2 ou 232 qui marchent pas pour aller au "mode sans échec" ou autres joyeusetés du même des goût, j'ai pas souvenir.

Idem pour "Office". Si c'est pour taper une lettre, pourquoi pas

.

Et payer 10€ de frais d'émission à bord du train, de mémoire?

Le sumo est trop gros, passera pas.

Sinon, les bons outils de gestion réseau permettent de surcharger ça en théorie. Je parle de théorie parce que jamais utilisé, mais ça permets d'éviter 1) d'installer un nouvel outil 2) d'être indépendant du DHCP utilisé (le wifi, c'est pour bouger…)

Et pour les flemmards:

Ils sont disponibles aux adresses IPv4 et IPv6 suivantes :

ns0.fdn.fr : 80.67.169.12 ou 2001:910:800::12
ns1.fdn.fr : 80.67.169.40 ou 2001:910:800::40

Je te suggère d'utiliser un outil comme ncdu (console), baobab (gtk3, donc plutôt gnome), pour analyser l'espace disque de ta partition racine… ceci dit, si je mets en parallèle ce que j'ai lu avec ton df -h, je dirais que tu as abusé des installations par snap. Je parie que ce sont les environnements de ces logiciels qui te bouffent toute la place.

PS: tout ça n'a rien à voir avec C++, mais alors vraiment rien. Je ne sais pas ce que tu connais de C++ ou de la programmation en général, mais pour remplir ne serait-ce que 1 giga octet avec un binaire exécutable ou un code source C++, il va te falloir beaucoup de temps… si tu compiles toi-même par contre, oui, les fichiers intermédiaires peuvent être lourds, mais si tu compiles toi-même, tu dois savoir qu'il faut nettoyer les fichiers objets, sauf si tu comptes patcher toi-même (et vu ton discours, je doute que ça soit ton cas, sans vouloir te vexer)

Finalement, les liens sont utiles. Parce que s'il fallait faire un bookmark pour chaque service supprimé de google, il y aurait plus d'articles sur google que sur linux, ici :D (oui, oui, je sais, c'est pas bien les hyperboles de bon lundi)

"Tu n'es pas un pur libriste Gilet_sans_manches, nous te condamnons à l'éxile. La sanction est irrévocable!(ta ta taaaaa!!!)"

Je serais mal placé pour reprocher ça, vu que j'utilise moi-même plusieurs logiciels non libres sans le moindre complexe:

• vivaldi
• virtualbox
• un firefox supportant les DRMs (à vérifier, ça remarque)
• quelques VMs avec windows
• pilotes WiFi
• une chiée de firmwares
• parfois les pilotes NVidia de mes vieilles 8400GS

Bref, je serais vraiment mal placé pour reprocher a quelqu'un l'usage de logiciels non libre. Et encore, je n'ai pas abordé la chiée de services web, parce qu'au final, à ma connaissance, le code derrière duckduckgo, notamment, n'est pas libre.

Mon point se posais uniquement sur l'absence de critique réelle (une opinion n'est pas une critique) dans les messages que je lis et qui vantent la pertinence de google vs ddg.

… mais 4 ko c'est beaucoup pour 2 octets de données.

Non, c'est juste la taille d'une page, d'un bloc, d'un cluster. Ça peut se modifier dans le FS soit pour avoir des blocs plus grands (permets de réduire la fragmentation -utile sur disque mécanique!- et diminue l'espace disque consommé par les inodes) ou pour avoir des blocs plus petits (permets de réduire le gâchis d'espace, mais augmente la fragmentation et la zone réservées aux inodes).

Bon, ok, pour voir ça, il faut utiliser le commutateur -s de ls, par exemple.

Ça va la tétracapilectomie?

Mieux que la vasectomie, je dirais.

Plus sérieusement, c'est bien pour ça que je te demande des exemples, parce que justement, je n'ai pas la même expérience que toi. Et peut-être que le problème viens aussi du fait que ce que toi, tu appelles non-pertinent l'est pour moi, et vice versa.