freem a écrit 5059 commentaires

Bleeping Computer souligne que LockBit n'avait pour autant jamais répondu à ses questions quant au fait qu'il ne s'en était pas moins attaqué au Centre Hospitalier Sud Francilien (CHSF) de Corbeil-Essonnes

Mais il est vrai qu'ils prétendent, selon l'article, ne pas s'en prendre aux hôpitaux ou la vie des gens pourrait être mise en jeu.
Après, on parle de gens qui pratiquent le racket quand même.

Probablement, puisque je ne suis plus dev :D (mais je commence a me demander si je vais y retourner donc…)

De manière générale je privilégierais aussi l'usage de dialog sauf vraie bonne raison, pour info, mais je pense que choose peut être valide dans un certain nombre de projets, du fait que dialog reste quand même pas le truc le plus léger du monde (surtout si on inclue ncurses) et ça peut compter.

J'ai souvenir d'avoir écrit un script shell qui exécutait des requêtes SQL dans mariadb pour récupérer les valeurs qui peuplaient des listes, et permettre la configuration de cette même DB. Même s'il est vrai que je n'avais pas vu (ou mal compris plus probablement) l'option --stdout je me souviens que le code était assez horrible à écrire (mais je n'ai pas de regret, cet outil a vraiment aidé le tech qui intervenait sur les machines).

Ce que tu montres est d'ailleurs assez symptomatique: ton contenu est statique, hard-codé, et pourtant ça sent déjà le souffre, avec ces redirections (qui sont inutiles du coup) et des valeurs de taille "aléatoires".

De manière générale, je pense que dialog gagnerait a recevoir un gros coup de jeune. Et si on pouvais au passage avoir plusieurs backends hé bien ça ne serait pas plus mal (un backend printf/scanf permettrait d'automatiser des tests, des backends X11/wayland/framebuffer permettrait d'avoir un truc acceptable pour des utilisateurs et non juste pour une personne qui fait la config ou le déploiement d'un logiciel…). Mais bon, yaka fokon. En attendant, dialog fonctionne pour les cas complexes, même si des gens préfèreront choose pour des cas plus simples.

Pour reprendre ton exemple, à priori cela donnerait:

INPUT=$(choose -cr "Entrée 1" "Entrée 2" "Entrée 3" )
echo -e "\nValeur retournée : '$INPUT'"

La différence est claire, je pense. Reste qu'a vue de nez, choose ne supporte pas les tags, qui sont quand même bien pratiques, parce que ça permets d'associer un truc facile à comparer dans le code avec un texte facile à lire pour l'utilisateur final.

Voir ici et le message parent la

Un script shell de moins de 400 lignes contre ~24KLoC de vieux C (1994 quand même) serait plus complexe à maintenir?
Je ne crois pas.
Personnellement, choose je peux relire et comprendre complètement le code en moins de 2H, dialog me prendra probablement plusieurs jours.
Il est aussi à mon avis bien plus aisé d'apprendre le bourne shell que le C, même si l'on peu regretter qu'il y ait très peu d'outils d'analyse statique qui tiennent la route en shell (je n'en connais aucun que je considère bon, tous ceux que j'ai utilisés sortaient plus de faux positifs qu'autre chose), comparé au C.

Pour comprendre dialog, il faut aussi comprendre ncurses, qui a le "bon goût" (erk) d'user de macro pour tout et n'importe quoi si ma mémoire ne me trompe pas. Je ne parierai pas non plus sur la résilience de cette lib quand le processus se mange un signal…

Dans un vrai projet genre embarqué, on pourrais aussi citer le poids. 7.68Kio pour choose contre ~250Kio pour dialog (sans les libs), ce n'est pas rien. A titre de comparaison, busybox pèse 1.1Meg, c'est à dire ~4 fois plus, mais c'est un environnement complet, qui est possiblement capable de faire fonctionner choose (je n'ai pas lu le code de choose, donc je ne sais pas).
Et, oui, ce genre de choses signifie encore quelque chose. Il reste des µcontrolleurs ou l'espace de stockage est limité.

Maintenant, pour faire un installateur ou un outil de diag pour un technicien capable de se ssh dans un système, si j'ai la place, je vais clairement préférer dialog, de ce que j'ai compris c'est quand même nettement plus puissant.

Ca fait quelques années déjà que l'on rencontre le terme "portable" à la fois pour la portabilité inter-OS et pour la "transportabilité".
Le sens change selon le contexte, je pense.

Un code source portable, c'est un code source qu'il est aisé de porter à un nouvel OS.
D'ailleurs, dans bien des cas on devrais parler de code source portés puisque souvent le travail de portage est déjà fait (exemples: firefox, claws-mail, code::blocks) pour l'OS cible (la plupart du temps: windows, GNU/Linux - et j'utilise GNU/ ici afin d'exclure android qui est pour moi un OS différent et dont je ne connais pas assez la situation - MacOS.

Alors qu'une application, un binaire portable, c'est effectivement un programme que l'on peut emporter avec soit et qui n'impactera pas l'hôte. Il pourra fonctionner sans installation sur une machine différente.
Dans le cas de windows, portableapps est probablement le repo actuel ou on les trouve le plus, pour les applications windows.
Pour les applications linux, on retrouve principalement les appimages, encore que celles-ci laissent des traces sur le système hôte, donc ça ne correspond pas tout à fait. Snap et flatpack ne correspondent pas, par contre, ces mécanismes requièrent une installation à ma connaissance. L'autre solution est d'utiliser des binaires liés statiquement, mais ici encore ils vont impacter le $HOME, donc ça ne colle pas exactement. En fait je ne crois pas que ça existe, probablement parce que le besoin est moindre: il n'y a pas beaucoup de postes utilisateurs linux après tout.

Ce type d'application est extrêmement utile par exemple pour pouvoir bénéficier d'un programme sans avoir besoin de l'installer, donc sans avoir besoin des droits admin ou que ça soit packagé dans SCCM. Autrement dit: pour contourner les sécurités et les lourdeurs administratives des grosses boîtes.
Une autre utilité est typiquement d'avoir des logiciels d'analyse système sur une clé, genre hijackthisfork (successeur d'hijackthis, trouvé récemment), wireshark… de prise de contrôle à distance (putty), ou simplement un éditeur de texte qui tienne la route (non parce que notepad hein…) même quand on n'est pas sur sa machine (dépannage, squat pour une raison X ou Y).

Evidemment, ça a son côté négatif en terme de sécurité: tel un marin qui a une femme dans tous les ports, une clé usb qui visite trop de ports risque de propager des saloperies…
Mais avec un OS aussi arriéré que windows (notepad, cmd.exe, powershell, l'outil de recherche de fichier… l'utilisabilité est franchement limitée, comparé à notepad++, conemu, bash…) il n'y a pas tant que ça le choix.

On dirait bien que ça fonctionne, en effet. Je suppose que je n'avais pas prêté assez attention à ceci:

If you use this option, dialog attempts to reopen the terminal so it can write to the display.

qui est basiquement ce que le bout de C que j'ai mis plus haut fait.

En terme de complexité, ce serait se prendre la tête pour pas grand chose. Choose ne pèse même pas 1KLoC, dialog, en revanche… je ne serai pas surpris qu'il atteigne plusieurs 10aines de KLoC.

Je doute qu'il y ait plus de dépendances…

dialog:

• debianutils (ça m'a l'air nouveau ça, j'en avais pas souvenir)
• libc6
• libncursesw6
• libtinfo6

Pas de dépendances supplémentaires si on descend dans l'arbre (tout ça ne dépend que de libc6 et de libtinfo6).

whiptail:

• libc6
• libnewt0.52
• libpopt0
• libslang2

Donc, à priori, même nombre de dépendances… sauf que debianutils, concrètement, je me demande ce que ça fait la, ce ne sont que des scripts shell. A vue de nez, c'est utilisé par l'installation, mais du coup, pourquoi ce n'est pas utilisé par whiptail? Je n'en sais rien. Qui plus est, je pense que c'est "récent", mais ma mémoire me trompe peut-être.

Honnêtement, ce n'est pas énorme, c'est juste "une" dépendance, mais si on prend sur un système standard, il est hyper probable que libtinfo6 et libncursesw6 soient déjà installés, puisque requis par d'autres outils fréquemment utilisés. C'est beaucoup moins le cas des outils slang.
Selon aptitude:

• libtinfo6 est requis (je prend pas les pre-depends, la flemme) par 622 paquets
• libncursesw6 par 176
• libpopt0 par 95
• libslang2 par 36

libtinfo6 est requis par bash, qui n'est pas optionnel sur debian. libncursesw6 par aptitude, alsa-utils, fdisk, powertop, procps, entres autres, qui sont des outils particulièrement courants.
Libpopt0 est requis par samba-libs, qui n'est installé pour aucune raison valable sur mes systèmes (non, vraiment, aucune valable: mpd et mpv peuvent supporter SBM, donc c'est actif dans debian, mais c'est tout. C'est d'ailleurs un truc qu'il faut que je fasse, me compiler mpd, mpv, sdl pour ne pas dépendre de ça, parce que ça tire pas mal de dépendances dont je n'ai pas l'usage, mais qui sont sûrement très utiles pour d'autres). libslang2 n'a même pas cette "chance" d'être requis par un composant "inutile" (dans mon cas d'usage).

Après, il est évident que ça ne change pas grand chose, concrètement on parle de 232Kio décompressés pour libpopt et 1670Kio décompressés pour libslang, de nos jours c'est négligeable (environ 2meg, une paille).
D'un point de vue accessibilité et i18n, whiptail gagne probablement compte tenu de la dépendance optionnelle (recommandation) à libfribidi (support des scripts qui s'écrivent de droite à gauche).

Malgré tout, il s'agit d'un élément que je prend en compte: j'essaie de garder les choses gérables, et multiplier les dépendances a faible valeur ajoutée pour mon usage n'est pas quelque chose qui m'aide a aller lire les changelog. Et puis ça m'amuse d'avoir un système entièrement fonctionnel tout en connaissant quasi par coeur la liste des paquets installés :) c'est une vieille manie que je tiens de l'époque ou j'utilisais windows et connaissais par coeur les processus et services qui tournaient sur ma machine.
Ca ne sert pas à grand chose (ça m'a bien permis de dégommer ou un deux malwares, mais franchement, ça reste peu pertinent) mais c'est comme ça :)

Le programme lui-même, plus petit,

Effectivement, et la différence est de taille: 72.7k pour whiptail, contre 1251 pour dialog (archives debian décompressées), dialog lui-même pesant ses 248K contre 27K pour whiptail.
La doc de dialog se limite aussi à une page de man, de mémoire, mais celle-ci est, toujours de mémoire, nettement plus claire que celle de whiptail. Mais je suis peut-être biaisé.

Essaies avec dialog, tu vas bien rire. Ce que fais ton code, c'est que le rendu ncurses sera capturé par ta variable, rendant de facto dialog complètement inutile.

La solution serait plutôt ceci:

#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

int main()
{
  int fd = open( ttyname( STDIN_FILENO ), O_RDWR );
  fprintf( "ceci ne sera pas capturé mais affiché\n" );
  printf( "ceci sera capturé, ou affiché si pas de capture\n" );
}

C'est le seul moyen à ma connaissance d'implémenter un dialog qui ne souffrirait pas du problème que j'ai décrit, c'est à dire qu'il reste possible de capturer la sortie sans rendre caduc le rendu.

Oui, les analogies sont toujours foireuses de toutes façon

Tu noteras que je l'ai dit explicitement :D

xfce prend 1g, gnome 1.3g, donc je suis parti sur 1/1.3, ce qui donne environ 0.77 :)

Exactement ce que j'allais demander!

Techniquement, dialog a moins de dépendances que whiptail, les deux sont en terminal. Il existe aussi une variante de dialog en gtk, zenity, que je n'ai pas regardé. Il y avait xdialog dans le passé, mais je crois que ce n'est plus maintenu depuis longtemps: dommage, ça aurait été pas mal de pouvoir utiliser les mêmes commandes pour avoir du ncurses ou du graphique.

Pour ma part, je trouve dialog pas génial, mais ça reste ce que j'ai trouvé de mieux, et la doc est raisonnablement claire. Non pas que j'ai cherché très loin, certes, mais whiptail me semble plus obscur pour ce qui est de la doc, et j'aime limiter les dépendances de mon système. Quant aux alternatives graphiques, le problème est que je travaille pas mal dans des terminaux, et que ce type de script est bien pratique via ssh (sans serveur xorg sur la machine distante), du coup je n'ai pas regardé plus que ça.

Pour les curieux, ce que je reproche à dialog c'est:

• l'utilisation de STDERR pour récupérer le résultat, donc on ne peux pas faire INPUT=$(dialog foobar), il faut passer par un fichier temporaire qu'il faut ensuite lire. Techniquement (en C), il est possible de faire autrement, mais pour ça il faudrait que dialog n'utilise pas STDOUT/STDIN, mais plutôt interagisse directement avec le terminal dans lequel il tourne. Ce n'est pas bien compliqué, et ça marche de nos jours (j'ai un PoC pour ça, je n'ai jamais fini le programme complet par contre), mais je ne sais pas si ça ne fonctionne que "depuis peu" ou si c'était déjà faisable il y a 20 ans. Le problème est peut-être lié à ncurses, pas sûr (je ne suis pas fan du tout de cette lib).
• il est impossible de construire des boîtes de dialogue composite, à ma connaissance. C'est à dire d'afficher par exemple une checkbox avec un champ d'entrée. Ceci dit, ce type de fonctionnalité n'est pas utile dans le cas de ce que semble avoir besoin l'auteur du journal.

Outre ces deux points, dialog fait largement le job, et est probablement packagé voire installé par défaut sur pas mal de distributions.

Que l'on soit clair, toutes les données sur le disque seront perdues avec ce que je vais décrire (des connaisseurs sauraient les récupérer, cependant, ce n'est pas un effacement sécurisé du tout).
Autre point important, il faut vérifier que le PC est capable de démarrer sur du partitionnement de type GPT. Une machine de 10 ans d'âge ne devrais avoir aucun problème avec ça, cependant: toutes les machines utilisant un UEFI en sont capable, et cela fait bien 10 ans qu'UEFI est standard je pense.

Comme toutes les données seront perdues, cela implique qu'il faut les sauvegarder sur un autre périphérique, qu'il est possible de débrancher physiquement. C'est important. J'insiste. Débrancher le périphérique de stockage est important, en cas d'erreur de manipulation ça évite les drames.

Il existe des manières plus propres de faire, mais celle-ci devrais quand même résoudre le problème.

Dans un terminal ouvert par l'utilisateur root ou dans une session de sudo -i, tapper la commande echo 'label: gpt' | sfdisk $TARGET_DISK.
Ceci va supprimer toutes les partitions présentes sur le disque et s'assurer qu'il aura un partitionnement de type GPT, ainsi une nouvelle installation ne trouvera pas de trace des anciennes et fera comme si elle est sur un système neuf, et grub n'essaiera pas le hack dégueulasse qui consiste à utiliser de l'espace non partitionné pour stocker des informations (comportement sur le système de partitionnement MBR).

Il faudra ensuite installer la distribution voulue, évidemment.

En golfant je peux compacter à 37 caractères cette solution. C'est "mieux", mais clairement moins lisible et toujours plus de 2 fois plus long que la solution shell trouvée: /+/{c+=i?0:1;i=1}/-$/{i=0}END{print c}. En plus, ça fait quand même pas mal de présupposés, genre, un et un seul '+' ou '-' par ligne, toujours en dernier caractère. Vu l'énoncé, ça me semble acceptable ceci dit.

Chez moi, ça ne semble pas fonctionner du tout avec GNU awk?

L'une des erreurs évidentes est que end doit être END, mais même ainsi cela donne 0.5. Je rate peut-être une subtilité ceci dit.

Pas bête! uniq -f2|grep + -c ça nous mets sur 18 caractères. La, ça deviens difficile de faire mieux je pense.

En pur awk, j'aurai fait: awk '/+{mathjax} / { if(inc==0)++count;inc=1 } /-/{inc=0} END{print count}' mais c'est hyper verbeux (61 caractères, compactable un peu, mais toujours plus de 2 fois plus long que le shell), shell gagne haut la main vu la simplicité du traitement. Je ne sais pas s'il y a plus propre.

A noter qu'il semble y avoir un bug dans le rendu de linuxfr, donc, voici en moins compact:

/+$/ {
if( inc == 0 )
  ++count;
inc=1
}

/-$/ {
  inc=0
}
END {
  print count
}

Plus court: uniq -f2|grep +|wc -l pour 21 caractères et un processus en moins (ça compte quand il y a beaucoup de données, il paraît ;))! Manifestement, uniq ne fournit aucun moyen de changer le type de séparateur de champs (espaces et tabulations), même via la variable IFS, je viens de l'apprendre et j'en suis déçu.

Je dirais que twitter est célèbre pour justement ses limitations techniques artificielles qui empêchent de développer une idée, un message.
C'est donc un peu le contraire de linuxfr, ou les gens sont globalement plutôt encouragés à écrire correctement (correcteur orthographique, pas de limitation de taille, possibilité de promotion de journal en dépêche, …) tout comme de nombreux autres forums même ceux liés à des "frivolités" (je me souviens d'une personne qui avait appris à écrire français correctement à force d'être modéré… quand je l'avais connu, son illettrisme était ce à quoi on pouvait le reconnaître. J'ai quitté travian quelques années, y suis revenu, il m'a reparlé, je ne l'ai pas reconnu vu qu'il écrivait correctement, et du coup il m'a expliqué que c'est grâce aux reproches constants et à la modération qu'il s'est forcé à apprendre à écrire correctement).

Donc, rien que techniquement: twitter décourage les échanges d'idées structurées via des moyens techniques, contrairement aux forums permettant de retrouver facilement les sujets qui vont intéresser le lecteur, et qui encouragent via divers outils l'écriture correcte, avec une vraie mise en forme et parfois des correcteurs orthographiques (comme ici, ou l'on est encouragés à relire avant de valider).

Ensuite, je pense qu'il y a aussi une culture sur chaque réseau social (chaque forum étant un réseau social, au sens originel de l'expression, je pense). Cette culture est définie je pense par la question qu'un réseau social ait un domaine précis (logiciel, libre ou non, macos, windows, couture, mécanique, un ou plusieurs jeux vidéo, et que sais-je encore) et la modération qui est faite. De la, la communauté va s'adapter, ou le réseau mourir.
Twitter et les "réseaux sociaux" tel que facebook n'ont typiquement pas de domaine précis, au lieu de ça les gens vont se créer leurs propres cercles, qui ne seront que peu ou pas modérés.
De ce point de vue, je trouve qu'on est plutôt loin des PMU en fait: ceux-ci attirent une clientèle bien précise (parieurs, sportifs ou non) contrairement à l'idée commune qu'ils sont peuplés de piliers de comptoirs.
Dans les autres débits de boisson, on peut aussi avoir des discothèques (ou je ne mets jamais les pieds, je ne peux donc pas vraiment en parler), les pubs, les bars à bière, vins, ou coktails, etc. Chacun ayant un ou plusieurs modérateurs plus ou moins efficaces, infiniment (bon, ok, pas infiniment, juste plusieurs ordres de grandeur, probablement plusieurs dizaines d'ordres de grandeur!) plus nombreux que les modérateurs sur twitter ou les réseaux sociaux.
Dans chaque établissement, il y a aussi une ambiance qui est créé, par la musique qui passe, par l'éclairage, la décoration, la taille du comptoir, le comportement des serveurs…

Je trouve du coup l'analogie vraiment foireuse.
Les réseaux sociaux ne sont pas des PMU, ce sont des places des marché. Des lieux ou il y a un vacarme assourdissant, ou le commerçant qui gueule le plus fort aura le plus de clients, ou les clients peuvent choisir quel commerçant aller voir une fois sur place, et pour faire dans les lieux communs dépassés, la ou les rombières vont colporter tous les racontars.
La seule modération faite sur un marché, c'est par la police, et je n'ai pas encore vu de marché ou la police soit vraiment présente: comme pour un réseau social!
Alors qu'un forum (ou un débit de boisson) est un endroit ou l'on va en sachant déjà ou l'on va. On peut évidemment en sortir quand on n'aime pas l'endroit ou si on a autre chose à faire, mais voila, dans ce cas, on en sort. Et on ne retrouvera probablement pas la même clientèle ailleurs. Et des débits de boisson avec leur modérateurs dédiés (videurs) j'en ai vu.
Plus que quelques uns. Quand il n'y en a pas, le patron est bien souvent peu enclin a ce qu'un client foute la merde et fasse fuir sa clientèle, j'en ai aussi déjà vu gérer des clients manu militari. Comme le ferait l'admin d'un forum.

Ca doit faire un sacré sapin de noel à la fin, pas sûr que d'avoir autant de couleurs soit une bonne idée (au bout d'un moment, ça appelle la confusion entre couleurs, non?).

Personnellement, je préfère régler mon compilateur pour actionner le maximum de warning et les corriger, hors, le cas des shadow variables déclenche un warning. Je n'utilise également pas d'IDE, ce qui me permets d'éditer le code de n'importe quel logiciel sur mon PC en un temps record (tous les IDE que j'ai utilisés par le passé, probablement pas loin d'une dizaine, étaient lents à se lancer comparé à vim. Je n'ai jamais utilisé emacs, je ne sais donc pas pour cet OS, mais j'ai lu que son éditeur de code était pas génial).

Il y a aussi le cas des revues de code, notamment via l'outil de github, qui à ma connaissance ne supporte pas ce genre de fonctionnalité.

Bon, après, je suppose que c'est une question de goût.

Au passage, par curiosité je viens d'aller revoir rapidement la page de wikipedia sur cette notation. Du coup, je suis en désaccord avec tous ceux qui veulent sa suppression, parce que:

Hungarian notation is an identifier naming convention in computer programming, in which the name of a variable or function indicates its intention or kind, and in some dialects its type. The original Hungarian notation uses intention or kind in its naming convention

Autrement dit, le but n'est pas seulement en rapport avec le type mais avec l'intention ou le type. Quant à la portée, elle est gérée initialement via la casse du 1er caractère non lié à la notation (given name comme ils disent).
Je note ici que l'article utilise le terme "kind" et non "type", ce qui est "expliqué" peu après:

As the Microsoft Windows division adopted the naming convention, they used the actual data type for naming, and this convention became widely spread through the Windows API; this is sometimes called Systems Hungarian notation.

En fait, ajouter le type (int, float, pointer, …) dans le nommage n'est pas la notation hongroise, mais la notation hongroise système (je l'apprend, perso, comme quoi ça fait pas de mal d'aller fouiller parfois).

Exemples que j'ai trouvés pertinents dans la page wikipedia:

Apps Hungarian notation strives to encode the logical data type rather than the physical data type; in this way, it gives a hint as to what the variable's purpose is, or what it represents.

• rwPosition : variable represents a row ("rw");
• usName : variable represents an unsafe string ("us"), which needs to be "sanitized" before it is used (e.g. see code injection and cross-site scripting for examples of attacks that can be caused by using raw user input)
• szName : variable is a zero-terminated string ("sz"); this was one of Simonyi's original suggested prefixes.

Je ne doute pas qu'un outil d'analyse statique soit capable de détecter ce type d'information, mais je trouve personnellement la méthode de la notation hongroise bien plus simple et plus élégante que de faire des distinguo par couleur et autres. Et l'analyse statique, ça a un coût, tout le monde n'a pas une bête de course pour coder, notamment parce que ce n'est pas souvent si utile que ça (et pourtant je code en C++ hein), sauf pour des gros projets qui embarquent énormément de dépendances complexes dans chaque unité de compilation (utilisateurs de boost, je vous regarde).

Dans la liste des avantages défendus par ceux qui en sont adeptes, on retrouve d'ailleurs quelques-uns de ceux que j'ai cités: la lisibilité du code en dehors d'un IDE ("This is useful when looking at the code outside an integrated development environment — like on a code review or printout" j'avoue ne pas avoir osé parler d'imprimer le code, mais j'y avais bel et bien pensé, ça m'arrive de temps en temps d'utiliser le papier, même si c'est super rare), ainsi que le problème de la collision des noms ("Applying Hungarian notation in a narrower way, such as applying only for member variables, helps avoid naming collision").

Au final, on pourrait dire qu'utiliser par exemple "mDistance" pour distance en mètres (ou mt pour meters, je sais pas. Le problème après c'est d'établir une convention quand ça à un intérêt de par l'usage assez répandu, sinon on ajoute juste des emmerdes), c'est de la notation hongroise, et il me semble avoir lu que c'est quelque chose qui manque souvent ;)

Sauf que ça me fait une belle jambe de savoir en lisant « m_fDistance » que c'est un float et une variable membre de la structure qui le contient

Autant je suis d'accord qu'indiquer le type (int, float, char, str…) dans le nom est peu utile (voire est une gêne), autant je trouve qu'avoir des conventions qui permettent de connaître la portée d'une variable est utile, ça permets d'éviter d'avoir plusieurs variables donc le label est strictement identique, ce qui peut arriver quand on utilise des variables non-locales (extern ou static, peu importe).

Si tu n'utilises pas d'applications d'un autre DE, tu n'as pas de surcout, ni d'economie en effet: le poids est juste celui de ton DE.
Et je doute qu'entre 1.3g (gnome) et 1g (xfce) a installer sur ma machine si j'en installais un il n'y aurais pas de difference.
La difference est faible, etonnamment, bien plus que par le passe. Soit xfce a grossi, soit gnome a minci, ou les deux. Dans tous les cas, ca va en direction de "gnome n'est pas si lourd" (mais pas "ne pese pas plus lourd", c'est quand meme une bonne difference, 25%).
Evidemment, l'espace disque utilise est une mauvaise metrique pour jauger de la ram utilisee par une suite logicielle, je ne ferai pas l'affront d'expliquer pourquoi. De la meme facon que ne citer que la ram pour arguer de la legerete.
Le cpu et la reactivite (la charge quoi) ca compte.

La reactivite a froid est importante aussi, parce qu'un ordinateur, quand on ne s'en sert pas, c'est bien de l'eteindre. Il y a bien l'hibernation, mais justement, le temps de dumper la ram sur le disque dur, parfois mecanique, n'est pas forcement negligeable, j'ai deja vu une mise en hibernation etre plus lente qu'un cycle complet de reboot, sans parler des problemes que ca peut apporter (reseau ou gpu qui deconnent au reveil) qui sont probablement lies a des bugs firmware quand ca arrive, mais il n'empeche que ca arrive (de moins en moins, j espere. Je n'essaie plus perso, mais mon cas est probablement specifique).

L'usage ram n'est de nos jours plus une metrique si simple a mesurer, d'ailleurs: s'il est simple de mesurer la ram utilisee par le cpu, mesurer celle utilisee par le gpu ne l'est pas (en tout cas je ne connais pas l'outil pour le faire simplement), et gnome, de memoire, a pas mal travaille a utiliser celle-ci. Hors,une fois la texture envoyee au gpu, il n'y a plus trop d'interet (la pupart du temps) a la garder accessible par le cpu.
Cela peut etre une piste pour expliquer que la difference n'apparaisse pas dans des outils tels que free.
Je ne sais pas ce qu'il en pour xfce, sur l'usage de l'acceleration materielle pour le rendu graphique.

N'importe quel commentaire qui decrit l'intention d'une ligne de code avec des expressions mathematiques pointues ou d'arithmetique binaire me semble qualifier pour les commentaires non verbeux utile. Parce que ces choses sont generalement obscures (plus que le langage natif en tout cas), meme a ceux qui decalent et masquent courramment des bits, et j'imagine que c'est la meme pour les matheux, voire une formule un peu evoluee ne dois pas necessairement leur dire a quoi elle sert.

Autre type de commentaire court et utile: les patchs d'historique et certains trucs a cause d'une regle metier qu'il faut modifier en vitesse. Quand tu as une vieille base de code pas forcement bien codee (donc souvent peu ou pas documentee) ou juste un n+1 qui demande un truc sorti de derriere les fagots pour hier, parfois il est bon d'expliquer l'interet d'une ligne qui semble triviale, stupide ou inutile au 1er abord.

Ca me surprend, mais pourquoi pas. Qu'en est-il de la RAM GPU par contre? De l'espace disque aussi, qui a un impact direct sur le temps de demarrage d'un systeme, pour ceux qui eteignent leurs pc plutot que les laisser en veille (gestes eco &co)?