freem a écrit 4920 commentaires

A vérifier, mais je crois que les vieilles salopes ont une licence libre sur leurs albums, ce qui semble corroboré par wikipedia:

Le "combo" a toujours refusé d'être inscrit à la SACEM, toute sa musique est en téléchargement libre sur le web et est libre de droit.

Il faudrait quand même vérifier sur jamendo, peut-être sur les fichiers d'il y a longtemps (à l'époque ou ce site n'était pas ce qu'il est devenu), parce que les archives à télécharger sur le site officiel n'ont pas de licence, et sont donc de ce fait non libres.

Je dois avoir d'autres trucs dans ce style, mais effectivement ce n'est pas la norme, la norme étant plutôt de l'ordre du -NC.

Je suis bien d'accord, il y a un sérieux problème de ce point de vue, et ça ne se limite pas à la "musique d'écoute": le problème est plutôt très très criant dans les jeux vidéos libres.
Par exemple si on prend unvanquished ou red-eclipse, tout est sous licence libre. Super. Mais trouver les modèles, qu'ils soient faits avec blender, maya, autocad ou peu importe quoi, est hyper compliqué, la plupart du temps ils sont "perdus".
C'est dommage, parce que ça permettrais de facilement régénérer les modèles compilés pour un format plus efficace, augmenter ou diminuer le nombre de vertexes ou d'os pour optimiser en faveur du temps de rendu ou de l'esthétique, ou, tout simplement, hé bien, de faire une oeuvre dérivée, ce qui est un peu l'un des principaux intérêts.

Et c'est d'ailleurs super chiant, surtout sur un tél ou cliquer sur le titre est une gageure, alors qu'il y a des commentaires très intéressants à des scores du genre -1 ou -2, parce que le commentaire est encore jeune et que personne n'a pus le pertinenter depuis ceux qui l'ont trouvé non pertinent.
Sans parler du fait que ça force a se logguer. Perso je navigue le plus souvent sans me connecter, et je n'aime pas que mes sessions web survivent à ma session informatique.
D'ailleurs, on dit "pertinent" mais je pense qu'un grand nombre de votes sont en réalité plus proche du "d'accord (ou pas)".

Ce type de commentaire par exemple, ça donne pas trop envie d’aller plus loin quand on découvre LinuxFr.

Par contre je suis d'accord que les commentaires qui ont des scores à -10 n'ont que rarement ce score sans raison.

Bon en gros, l'article dit: la virtualisation encourage les gens à avoir un bout d'internet à eux, et ça consomme.

Bon. En soit, ça semble logique. Sauf que, l'alternative, en supposant que les "bout d'internet à soit" ont réellement un intérêt, c'est que chacun ait sa machine perso. On ne me fera pas croire que ça serait plus écolo…

Un autre passage parle de la sur-utilisation de la RAM. Ah, ça, ça me parle, p'tet que ça va aborder un truc pertinent?
Ben non. Les solutions abordées, c'est de dédupliquer… Une vraie solution, mais qui casserait énormément de logiciels dont la totalité des navigateurs internets ainsi qu'ASAN et certaines techno de sandboxing (enfin, sur un serveur osef, mais bon, y'a pas que les serveurs qui sont impactés par le problème) ça serait de désactiver l'overcommit, qui est une fonctionnalité qui permets à un logiciel d'allouer plus de ressources qu'il n'en existe réellement.
En quoi ça serait une solution? Tout simplement parce que ça rappellerait aux développeurs que non, ils ne doivent pas faire comme les économistes qui croient que les ressources sont infinies (« Celui qui croit que la croissance peut être infinie dans un monde fini est soit un fou, soit un économiste. » Kenneth Boulding).
Oui, gérer les ressources matérielle, c'est du boulot. Celui des devs.

Je ne parle pas des langages interprétés qui sont ré-optimisés à chaque démarrage de la machine, de chaque machine qui les fait tourner (comparé à un programme compilé qui lui ne sera optimisé que lors de la livraison) ni des programmes compilés (plus ou moins mal codés) qui requièrent de tout recompiler au moindre changement dans un header. Ni, d'ailleurs, des systèmes de build qui sont incapables de remarquer que la seule chose qui a changé dans un fichier, c'est un commentaire ou un espace (encore que… dans certains langages, les espaces sont des éléments de syntaxe après tout…).

Bref, avant de taper sur les data-centres qui sont une conséquence (avoir un serveur chez soi, allumé H24, ça coûte cher, donc on mutualise dans des DC qui eux vont essayer de réduire les coûts d'entretien au maximum, notamment grâce à l'usage de machines virtuelles), je pense qu'il faudrait commencer par regarder la racine du problème, que l'on peut constater ainsi: il y a 20 ans, on pouvait utiliser des tableurs et des logiciels de traitement de texte sur des bécannes qui avaient moins de 200 megs de ram, un seul coeur de calcul cadencé à une vitesse de moins d'un giga hertz. De nos jours, pour le même usage il nous faut au moins 4Gio et 2 coeurs à 2GHz.
Certaines personnes, il paraît, utilisent ces logiciels à fond, et ont donc besoin de toutes les fonctionnalités offertes.
Je ne sais pas où elles se cachent par contre, moi j'en ai pas encore vu. Et vous?

Le rapport avec les data-centres? Il y a 5 ans, j'aurai dit: aucun. De nos jours… ben, ces suites bureautiques… elles tournent dans des navigateurs web. Donc le coeur est sur un serveur. Dans un DC.

Dans le cas de xonotic, dire qu'on ne trouve pas de sources secondaire est un peu abusé quand même.

Une bête recherche google… sur mon PC de taf… alors que normalement, partout, j'utilise ddg hein, donc c'est pas que l'algo me connaît… même si on ressent la p'tite bulle fr, ce qui est mon but d'origine en vrai donne ceci:

1. xonotic.org
2. fr.wikipedia.org
3. framalibre.org
4. ginjfo.com je sais pas ce qu'est ce truc, c'est le 1er pour l'instant
5. clublic.com
6. robinson-special-jeux.franceserv.com 2nd inconnu
7. urlab.be 3ème inconnu

Donc, on a quand même sur la 1ère page google (c'est à dire le moteur le plus utilisé me semble) 2 références externes, qui sont assez connues pour être décrites par fr.wp quand même, et donc être des sources secondaires?
A vue de nez, la page wikipedia de xonotic n'est plutôt pas mal foutue, et on y trouve 43 références, dont 13 ne semblent pas avoir été injectées en réaction à cette mesure et au bruit autour.

Alors c'est peut-être le petit bout de la lorgnette comme tu dis, mais j'ai quand même bien l'impression qu'il y a de l'excès de zèle couplé avec une grosse flemme de vérifier dans l'air.

Définition d'une source secondaire:

Les sources secondaires sont des documents dans lesquels les auteurs ont réalisé une analyse, une synthèse, une explication ou une évaluation d'un sujet sur base des sources primaires à leur disposition. Ces documents sont utilisables dans Wikipédia lorsqu'ils sont publiés et sont l'œuvre de spécialistes reconnus. Dans les meilleurs cas, ils sont aussi relus et objets de critiques.

Les documents ci-dessous sont des exemples de sources secondaires, dans la mesure où ils sont des travaux d'analyse ou de synthèse commentant des sources primaires, et ne se bornent pas à relayer des sources primaires (ou, a contrario, à exposer des travaux originaux) :

• des livres ;
• des biographies ;
• des monographies écrites par des spécialistes du sujet ;
• des conférences données par des spécialistes du sujet ;
• des articles de journaux, revues ou magazines, ou sites internet de qualité, qui résument une ou plusieurs sources primaires ou secondaires, fournissant un état des lieux des connaissances sur un sujet comme les méta-analyses.

Pour parler de « sources secondaires », il faut bien entendu que toutes ces sources traitent du sujet, et non qu'elles aient été écrites par lui, puisqu'il ne s'agirait alors que de sources primaires.

Alors, je pense quand même que framalibre est acceptable en tant qu'expert du logiciel libre, et même si le § est plutôt court, ça colle à la définition d'une synthèse.
Quant à l'article sur clubic… il est plutôt détaillé, et même s'il ne me viendrai pas à l'idée de les qualifier d'experts, wikipedia le définit comme ce site grand-public d'actualité high tech et numérique [...] l'actualité des nouvelles technologies, des tests de produits [...] et services (logiciels [...]

Tout ça, vraiment, sans me fouler… enfin, si, je me suis forcé à utiliser google.fr…

Et c'est exactement ce qui est reproché ici: les gens qui veulent supprimer ça n'ont pas cherché, pas fait le boulot pour lequel ils se sont proposés.

Après, pour des gens qui aiment le jeu vidéo (et des experts connaîtrons forcément), une recherche simple sur "let's play xonotic" va également donner des résultats concrets. J'ai 3 vidéo sur l'encart de ddg:

• la 1ère date de 8 ans, et à 6.1K vues
• la 2nde date d'un an, avec 26K vues
• la 3ème… euh, accès limité? bref

Donc, vraiment, il y a bien un problème avec cette demande de suppression pour cause de sujet pas assez connu, et ce n'est pas le sujet lui-même…

Moi j'utilise encore beaucoup wikipedia fr: quand je veux traduire un terme, je cherche sa page en français, je passe à la version anglaise, et paf, ça fait des chocapic traductions!

Sinon pour le reste, je suis bien obligé de dire que je n'utilise la version FR quasiment que quand je suis trop bourré ou fatigué pour aller voir la version anglaise, ce qui est assez compliqué parce que dans ces états la généralement j'ai de toute façon du mal à utiliser un PC…

J'étais intrigué, j'ai été voir (très très) vite fait:

• jq est un outil pour manipuler du JSon en ligne de commande ou via scripts shell. Bon, lui, je le connaissais déjà.
• yq semble être le pendant YAML de jq
• fq sert sur les données binaires, donc, pas sur du json, yaml, html?
• mediainfo semble être un outil pour récupérer les infos de fichiers audio-vidéos, comme le nom le suggère.

Du coup, à vue de nez, tous ces outils sont en fait complémentaires, et non pas des alternatives l'un à l'autre.
Je me trompe quelque part?

PS: merci pour le partage

Ce n'est pas comme si ce journal parlait tant que ça des endroits ou l'on peut trouver de la musique libre non plus.

• LinuxFR: pas franchement le sujet. Et je ne serais pas surpris que la plupart des contenu musicaux référencés ici par des dépêches, journaux, liens, entrées de forum ou commentaires ne soient pas libres.
• linuxMAO: idem. Le but c'est juste de promouvoir des outils libres pour créer de la musique, et pas nécessairement de la musique libre. Le forum pointé est assez "clair" sur ça d'ailleurs: sur le "comment bien poster", nulle part il n'est précisé qu'indiquer la licence, ça serait bien.
• libre à vous: celui-ci à l'air pertinent et à fond dans le sujet à vue de nez.
• auboutdufil: à l'air pertinent, à vue de nez, je vais faire confiance à l'auteur de la dépêche. Mais même pas 200 titres, c'est peu. Je comprend que ça représente pas mal de travaille, hein, la n'est pas mon propos (il faut trouver les pistes, et les filtrer notamment par licences).
• Ziklibrenbib: comme tu le relèves, le fait que la musique libre ne soit pas obligatoire n'est pas génial.

Pour ce qui est de dogmazic, il est clair que leur fonction de recherche n'est absolument pas pratique. Il faut faire une "recherche avancée" puis, pour chaque licence non libre, ajouter une règle. Ce qui est particulièrement pénible vu que pour les CC, c'est une règle par licence, ce qui fait environ 4 lignes pour chaque combo (sauf CC-0). Je ne parle pas du fait de devoir connaître les autres licences.

Edit: en relisant le titre, je m'aperçois aussi que j'ai pu mal comprendre. J'ai originellement compris que c'était des pistes pour découvrir de la musique libre, le résultat, les pistes, les chansons, mais peut-être qu'il fallait comprendre que ça implique aussi les moyens de la produire? Je ne sais pas.
Dans tous les cas, je pense que opengameart aurait aussi pu être cité, notamment parce que la recherche par licence y est nettement plus simple que sur dogmazic, et… ils ont aussi de la musique, après tout, même si orientée jeux vidéo.

Vu depuis derrière le proxy de ma boîte, je ne vois aucune pub gênante. Juste un carré grisé sur la gauche. Je ne sais pas quel type de pub c'est, mais clairement ça ne m'a pas l'air trop malfaisant, et il faut bien qu'ils se fassent un peu de beurre.

Après, il est toujours possible de compiler, bien sûr, mais c'est plutôt fastidieux. Juste packager un programme est peut-être moins chiant, et à vue de nez ils donnent toutes les infos pour le faire, par contre.

Je n'aime pas trop la conclusion (enfin, juste la partie « contourner les sécurités »)

Ce n'est pas agréable à lire ou à écrire, mais ça reste une réalité.
Sous windows, de très nombreux programmes ne peuvent s'installer sans avoir accès au registre général, donc, il faut des droits admin, qui sont pour des raisons évidentes interdites aux utilisateurs normaux.
Il y a aussi des cas ou le système va essayer de bloquer au maximum l'installation par exemple de jeux vidéo.
On peut aussi citer le cas des one-drive et autres trucs de synchro qui vont silencieusement effacer les fichiers exécutables (clairement, ça sent la mesure de sécurité pour moi) et donc on utilise une clé USB pour les trimballer (du coup, contournement).

Du coup il y a le double usage: installer un outil qui est pratique et monte la productivité, et installer des logiciels dont ce n'est pas le but. Il est aussi possible d'installer ainsi des logiciels qui vont être malveillants ou avoir des failles de sécurité parce que pas à jour, mais ça évite de devoir justifier le besoin d'une application X ou Y.

Je pense que l'usage, en dehors des cas type "je me ballade souvent d'un PC à l'autre" est vraiment lié au contournement de règles, que ces règles soient pertinentes ou pas n'empêche pas qu'elles sont des règles, et souvent faites avec l'argument sécuritaire (et derrière les clés usb sont montées avec la possibilité d'exécuter des programmes… étrange, mais bon, peut-être que windows ne permets pas de monter en noexec?).

Ce n'est pas le but mais hélas le risque …dans les deux sens : j'aimerais bien, comme beaucoup je pense, que le système hôte n'écrive rien sur ma clé et donc qu'elle chope des saloperies…

Ce serait génial ça. Et dire que ce genre de mécanisme existait avec les disquettes ou les cartes SD je crois… bien que j'imagine que c'était purement de l'ordre de la convention, je ne vois pas comment ces petits caches pourraient avoir un impact quelconque.

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.