freem a écrit 5019 commentaires

Je suis vraiment pas expert dans le domaine

Moi non plus, mais j'ai déjà exploité une injection SQL ou PHP (sur des sites spécialisés). J'ai déjà essayé d'exploiter un programme avec un bug mémoire: c'est pas la même.

Parce que linux, c'est un noyau.

La, les mecs font juste la même chose que GNU, 30 ans après, avec un langage tout frais (la ou le C avait déjà de la bouteille et essuyé des plâtres j'imagine), et ce, en vrac (déjà été dis mais peu importe).

À côté de ça, linux, c'était "juste" un noyau, Linus Torvalds ne s'est "pas fait chier", il a repris l'existant. Beaucoup.

Je pense que tout est dis ici: d'un côté, la réutilisation de l'existant, le pragmatisme, de l'autre, l'idéal théorie et le NIH.

Au fait, j'ai un scoop: les failles de sécurité les plus faciles à exploiter… c'est pas les buffer overflows, ce sont les injections de code et les déni de service (un jeune de 16 ans peut exploiter ce type de failles).
Et c'est pas côté kernel, mais userland. C'est bien d'avoir un noyau et des outils de ligne de commande en béton armé (contre les problèmes de mémoire uniquement je suppose, pas contre les bugs fonctionnels, qui sont bien plus délicats à repérer), mais ce qui est important pour un serveur ou une machine embarquée, ce sont les daemons. Pour une machine de bureau, c'est l'interface graphique qui marche pour de vrai, l'accès au web (d'ailleurs, netsurf qu'ils embarquent n'est pas codé en rust) qui supporte le bloat javascript, une suite bureautique et la performance (parce que le jeu vidéo fait aussi partie des usages importants).

Bref. On peut faire une distribution autour de linux en utilisant les outils gnu, le navigateur web de mozilla et le bureau KDE. C'est ça, la force des distros GNU/Linux: le bazar.

Ce nouvel OS aura: moins de développeurs que les devs des BSD (un langage moins répandu), moins d'outils (parce qu'il faut du spécifique rust à tous les coups) et pas de support matériel (parce que si c'était si facile, ça ne serait pas aussi galère sous linux, et si un µkernel étais la panacée, GNU/Debian/kHurd serait stable).

Zut, on est pas vendredi.

Pour contrebalancer un peu tout ça: je pense que c'est bien. J'aime énormément l'idée des µkernels perso, et si j'avais plus de motivation, je bricolerais bien avec hurd. En faire un en rust? Pourquoi pas.
Dommage de vouloir faire l'OS complet, par contre, mais bon, on a le droit de faire son «pet project» :)

y'a D sans doute […] pour remplacer du C ou C++

De ce que j'ai lu (pas grand chose, certes), le D semble très très fortement influencer ses utilisateurs pour utiliser le poubellier, ce qui est admis comme étant incompatible avec la performance (que ce soit de vitesse ou d'occupation mémoire, mais pour la vitesse d'écriture ça aide, probablement).

Des langages que tu cites et que je peux trouver facilement dans wikipedia fr, seul rust peut concurrencer C ou C++. Et il me semble pas que rust puisse embarquer du C aussi facilement que C++ (un simple #include bien souvent), alors qu'il s'agit probablement de la base de code la plus importante, et une des plus vieilles, avec donc pas mal de correctifs de bugs.

D'ailleurs, ce point est important: toutes les failles de sécurités ne sont pas liées à la mémoire, loin de la. Et c'est encore pire pour les bugs, alors que tout refaire (peu importe le langage cible), c'est aussi devoir reprendre tous les debugs, de 0.

Va falloir passer par des mails alors, parce que de mémoire linuxfr.org n'a pas de mécanisme de message privé.

Haha, j'adore l'idée de virer l'heure pour gagner quelques méga-octets de mémoire.

En fait, ce n'est pas «virer l'heure», mais virer un daemon qui garde la machine à l'heure via le protocole ntp.
Pour une machine non critique, le faire au démarrage (après le réseau bien sûr) puis une fois toutes les semaines est amplement suffisant, pas besoin que ça tourne en permanence.
Le plus amusant pour moi, c'est que le daemon contenu dans le paquet «ntp» de debian consomme… :

3340 76468 ntpd

la moitié de mémoire résidente, 25% de moins de mémoire virtuelle. C'est pas rien, et ça fait pas juste client, mais serveur aussi.
Mais il fallait que cette bouse (oui, je me permets maintenant de dire ce que j'en pense, j'ai été assez sympa avec ce machin pour remplir mon quota de neutralité pour plusieurs mois) de systemd réinvente la roue…
Il suffit de voir, dans ta liste:

5628 23352 /lib/systemd/systemd-udevd
6412 95148 /lib/systemd/systemd-timesyncd
7244 19552 /lib/systemd/systemd-logind
8140 40376 /lib/systemd/systemd-journald
9524 21260 /lib/systemd/systemd --user
10064 104032 /sbin/init

Donc, à peu près 47.8Mio de RSS.
Si je compare avec mon système, sur lequel je n'ai pas logind (pas l'utilité), ça fait du 40.6Mo pour ton système, et:

% ps -orss,vsz,comm -A | grep -e ntp -e syslog -e runit -e runsvdir -e runsv -e svlogd -e udev
  728   2152 runit
  736   2312 runsvdir
  740   2160 runsv
  740   2160 runsv
  668   2160 runsv
  732   2160 runsv
  744   2160 runsv
  736   2160 runsv
  736   2160 runsv
  740   2160 runsv
  744   2160 runsv
  680   2160 runsv
  740   2304 svlogd
  748   2304 svlogd
  744   2304 svlogd
 5180  22552 systemd-udevd
  672   2304 svlogd
  748   2304 svlogd
    4   2208 syslogd
  740   2304 svlogd
 3340  76468 ntpd

Soit: ps -orss,vsz,comm -A | grep -e ntp -e syslog -e runit -e runsvdir -e runsv -e svlogd -e udev | awk 'BEGIN{ printf "0" }{ printf "+%s",$1;}' | calc ==> 21640Ko, donc ~21.5Mo :)
C'est juste la moitié, et ce, sachant qu'il est possible de compiler runit statiquement, ce qui réduit de manière drastique la consommation mémoire (sur le build muslc de voidlinux, j'étais à 4Kio de RSS par instance de runsv et de svlogd).

Je pensais qu'il y aurait un applet busybox pour ntp, je me suis trompé, dommage, j'aurai pu descendre encore plus ce bloatware.
Par contre, ils parlent de ntpclient. N'ayant jamais utilisé, je ne saurais le recommander, mais je vais le mettre sur ma liste de trucs a tester :)

Je suis sûr qu'on me diras que 20Mo de gagné, c'est pas grand chose de nos jours, mais tu es aux 1ères loges pour constater que, parfois, ça compte :)
Je ferais peut-être un journal sur la construction d'une Debian économe en mémoire un de ces 4, en comparant le résultat avec la Debian par défaut, ça occupera le vendredi.

Tu sais, tu aurais pu aider. Je ne comprend pas pourquoi personne ne lui a dit d'ajouter le flag magique qui supprime tous les warnings: -Werror. Moi, quand j'ai des warnings et des bugs sur mon code et que j'utilise rm a.out; gcc -Werror -Wall -Wextra foo.c, ben j'ai plus de warnings ni d'exécutable buggué.

en général, j'utilise top et je dépatouille un peu

Top est plus que limité, par nature. Je m'en sers aussi, mais pour visualiser l'usage CPU instantané, quand je n'ai pas de serveur graphique. Sinon, j'utilise xosview combiné à ps -opcpu,pid,comm -A.
Mais pour analyser l'usage mémoire, je trouve ps plus pertinent: pas besoin que ça bouge tout le temps, au contraire, il faut pouvoir se concentrer et analyser les lignes.
À chaque outil son usage.

j'ai remplacé mpd par mopidy, mais c'est vraiment similaire

Nope. nopenopenope!

59156 1205724 /usr/bin/python3 /usr/bin/mopidy

Et chez moi:

35920 658788 mpd --no-daemon /home/berenger/.config/mpd/mpd.conf --stderr

Donc, mopidy bouffe presque le double de mémoire, résidente ou pas.

Ceci mis à part, j'ai l'impression de voir une machine qui est faite pour un usage normal ici, pas pour un serveur de ficher et jukebox. Et clairement, une machine dont l'install par défaut n'intègre pas vraiment les outils ensembles…

Ce que je vais lister est ce qui, à mon avis, est optimisable, mais ça reste mon avis, par rapport a ce que j'ai compris de ton usage, et je suis quelqu'un qui déteste le bloat, quitte a utiliser un environnement minimal… qui s'adapte extrêmement bien à des petites machines, pour le coup :)

Faible impacts (moins de 5meg potentiellement récupéré par changement, mais quand on chercher le moindre meg…):

• ssh-agent, c'est pour que le client ssh se souvienne de tes clés. Ta machine est censée être le serveur, non?
• agetty est lourd (pour un getty). Il peut être remplacé avantageusement par mingetty, ngetty, fgetty, et d'autres;
• cron? Si tu utilises systemd, c'est inutile: systemd en embarque une implémentation de mémoire;
• dbus et toute sa clique, c'est des dépendances de gtk, on peut s'en passer en vrai, mais je recommanderais pas à un débutant (parce que c'est se faire chier pour pas grand chose);
• geoclue.. démo? Ça à l'air d'être pour que ta machine sache ou elle est, genre, GPS? Pour un serveur?
• rsyslogd? Alors que tu utilises systemd-journald? J'en vois pas l'utilité, ou alors c'est que systemd-journald est pas foutu de faire son job correctement: j'aimerai pouvoir le dire, mais j'en doute fort;

Catégorie suivante, impacts non négligeables:

• alsactl, permets de gérer des paramètres avancés, plusieurs cartes son. Comme tu veux, mais moi je dis: inutile;
• cups, 8Mo + 11Mo, sert à l'impression;
• GVFS, 11Mo, sert à monter automatiquement les périphériques et à les afficher dans ton gestionnaire de fichiers, si je ne m'abuse;
• menu-cache, mets en cache des fichiers .desktop… euh, soit, mais tu as vraiment tant d'applications que ça? Non parce qu'il bouffe plus de 5Mio, et un seul fichier .desktop pèse quoi… 4Kio (parce que 4Ko c'est la taille d'une page mémoire)? Le noyau rentrerai plus de 1000 fichiers .desktop dans cet espace mémoire. Pour moi, c'est du bloat;
• dhclient: tu pourrais utiliser par exemple udhcpc. Chez moi, ce dernier à une empreinte RSS de 4ko. Contre plus de 5Mo chez toi, pour le même rôle, sauf si tu as des besoins avancés de ce côté, mais je vois pas, perso (pas encore eu de problème avec, dans mes usages, pendant plusieurs années);
• at-spi-bus-launcher: composants d'accessibilité de gnome. Ça dépend vraiment de toi, ici, peut-être est-ce nécessaire. Si ça n'est pas le cas, c'est 6Mo;
• systemd-timesyncd: 6Mo pour un client ntp? Wow. Vive systemd. Sinon, est-ce critique que ta machine soit mise à l'heure en permanence? Ce genre de trucs sont surtout utiles pour des machines qui gèrent de l'authentification, par exemple dans un LAN qui utilise kerberos;
• lightdm. Gestionnaire d'affichage léger, à plus de 13Mo. J'ai pas la même définition de léger, mais soit. N'empêche, je suis persuadé que, par exemple, xdm est plus léger. De toute façon, ces outils sont d'une utilité douteuse: une session qui lance startx quand démarrée sur un TTY, c'est nettement plus léger (0Mo). Tu peux te renseigner sur le sujet ici par exemple;
• ModemManager? Tu as une puce LTE dans cette machine? Enfin, même si c'est le cas, il y a bien, bien plus léger, puisqu'on est restreint sur les ressources (ici: ~10Mo);
• colord: ~14Mo, tu règles vraiment finement les couleurs de l'écran sur cette machine?
• PA sert à gérer le son par application, je ne vois pas l'intérêt (dans ce que j'ai compris de ton usage, hein). Il consomme plus que je pensais d'ailleurs: ~24Mo;
• clipit, ~37Mo, pour gérer… euh… le presse papier? Sur un (rôle de) serveur?
• wicd, ~40Mo, sert a gérer les connections réseau, c'est pratique quand tu en changes souvent, mais si la machine est censée rester toujours sur le même réseau, c'est totalement inutile;
• le bluetooth, blueman donc, ~50Mo, tu en as déjà parlé;

Bon, je vais m'arrêter la, c'est déjà beaucoup.
Je pense que tu peux récupérer pas loin de 150Mo facilement sur ta machine, sans perte de confort.
Si tu pousses «l'optimisation», tu peux peut-être récupérer plus de 300Mo de mémoire résidente. Ces nombres me paraissent excessifs, j'avoue… mais je me base sur ton log :)

Si tu cherches des pistes d'économie, le mieux, c'est de commencer par mesurer.
Perso, pour avoir une idée de ce qui pèse lourd sur ma machine, j'utilise la commande suivante:

ps -orss,vsz,args -A --sort=rss

Elle indique, pour chaque processus de ta machine, sa mémoire résidente, c'est à dire, ce qui est effectivement en mémoire, la mémoire "réservée" (c'est plus subtil que ça, certes) et la ligne de commande exécutée, le tout trié par occupation mémoire résidente.

Maintenant que tu peux mesurer par toi-même, place au laïus:
Je n'aime pas systemd, que je considère gourmand, oui, mais surtout parce que c'est un logiciel critique et pourtant il n'est pas "stable", au sens que de nouvelles fonctionnalités sont ajoutées en permanence. Entres autres.
Maintenant, il est très probable que, sur 1Gio de RAM, ça ne soit pas ici que tu récupéreras le plus de mémoire, et comme il est intégré par défaut dans (la plupart des) les distros, tu as moins de risques de problèmes, plus de facilité a te faire aider en l'utilisant.
C'est important, et je ne te recommande pas de changer d'init (de framework système, je devrais dire en vrai).
Sans être particulièrement complexe pour des machines simples, mieux vaut être à l'aise avec son système avant de jouer avec ça.
Pour info, j'utilise personnellement runit-init, mais ça nécessite que je fasse mes scripts moi-même, puisque pas très bien supporté par debian. Pas de souci, j'ai l'habitude.
Runit a un coût par processus surveillé qui est supérieur à systemd (entres autres parce que lié dynamiquement, c'est la faute a debian ça, mais peu importe). Selon mes calculs, par contre, il faudrait beaucoup de daemons pour que ça soit plus lourd que systemd: ~30 avec le build de debian, plusieurs centaines avec un build mieux foutu. C'est de l'ordre des centaines de kilo-octets ici. Tu as plusieurs millions de kilo-octets de ram avec ton giga.

Pulse-audio par contre est un meilleur candidat je pense: il sert surtout (a ce que je sais) a permettre de gérer le son par application: pour une machine qui sert de jukebox, 0 intérêt.

Ensuite, dans ton bureau, tu as sûrement pleins d'applications installées pour rien, les nettoyer va virer de l'espace disque seulement, la plupart du temps, mais dans certains cas, ces logiciels vont démarrer tout seuls, pour diverses raisons. Gain probable ici, plus pertinent que changer systemd ou PA.

Debian installe, de mémoire, automatiquement un serveur de mails, par exemple. Je doute que tu en aies l'intérêt, et, oui, il est démarré automatiquement. En fait, Debian installe par défaut les paquets "recommandés". Ce sont des dépendances optionnelles qui peuvent potentiellement apporter une fonctionnalité. Si tu connais l'usage que tu veux faire de ta machine, tu peux sûrement en virer beaucoup.

Si vraiment tu veux réduire l'usage RAM, tu peux aussi cesser d'utiliser un gestionnaire de session graphique: il te faudra juste démarrer la session graphique à la main, ou ajouter dans ton .profile un truc de ce goût: if [ "/dev/tty1" = $(tty) ] then; exec startx; fi, qui fera que ta session graphique se lancera automatiquement quand tu te log sur le 1er terminal.

Une machine de 1gig de ram devrais pas, au démarrage et en console, consommer plus de 40megs de ram, je pense. Sur une VMs minimaliste, j'ai 22megs, mais bon, y'a rien de rien (juste 6 tty, même pas de réseau), donc bon.
Ajouter un bureau léger tel que LXDE devrais tenir largement en dessous de 100megs de ram, donc si ta RAM est vraiment le problème (ce dont je doute) tu dois avoir bien des merdes lancées… ce qui inclue évidemment un navigateur web. Ces machins (enfin, firefox, chromium, ses clones, et ceux basés sur webkit) sont des gouffres, et on peut rien y faire. Firefox bouffe moins que chromium cela dis, me semble avoir mesuré y'a quelques mois, et il devrais tenir dans 1 gig. Si pas trop d'onglets, profil neuf (vide), et sites légers.

Je peux essayer d'aider, si tu colles la sortie du ps que j'ai indiqué en début de message.

Peut-être une piste ici.
À lire avec un peu de contexte, vu que ce n'est pas le 1er billet de la personne sur le sujet (je crois que c'est le 2nd, il en mentionne un autre, j'avais lu tout ça mais ça fait quelques temps)

mpd est un daemon qui peut soit prendre ses commandes sur un «socket UNIX» (man 7 unix) soit sur des sockets plus classiques, c'est à dire TCP/IP.

Dans le 2nd cas, si tu fais écouter mpd sur une interface réseau réelle (autre que "lo") ou sur une IP réelle (autre que localhost, 127.0.0.1, etc) il te sera possible de le piloter de n'importe quelle machine de ton réseau local.
À noter que l'IP "0.0.0.0" indique "toutes les IP".

Bref, si LXDE ne sert qu'a piloter mpd, tu serais gagnant a simplement piloter mpd de l'extérieur, que ce soit via ario, ncmpc, ncmpcpp, mpc ou autre.
Ça ne réduirait probablement pas le temps de boot de mpd, cela dis, temps de boot qui me surprend, d'ailleurs, j'ai toujours vu mpd démarrer très vite, avant même que les instances d'agetty ne soient lancées, et ce, y compris sur ma vieille machine que je voulais pendant un temps utiliser comme jukebox: vieux pentium mono-coeur cadencé à 700MHz, disques pATA entre 80 et 40 gig, récupéré avec 64Mo de ram, boosté depuis a la quantité faramineuse de 196Mo, bref, moins performant qu'un beaglebone black, et pas qu'un peu. Ne parlons même pas des raspberry pi :)

Ce que je soupçonne, c'est que ton système d'initialisation ne démarre pas mpd avant que les interfaces réseau, et donc l'acquisition d'IP via DHCP (alors que mpd n'a pas besoin du réseau pour fonctionner, surtout dans ton cas). Il y a fort a parier que tu utilises systemd, sur lequel je ne peux pas t'aider, mais tu devrais jeter un oeil. Pour moi, dès lors que le kernel est chargé, mpd devrais être capable de démarrer en moins de 30s, même sur du vieux matos.
Autre piste, si le problème est la performance de la machine: passer les daemons moins importants en démarrage après mpd. Hum… j'y pense, tu as peut-être aussi pulse audio. Ça n'est pas grand chose, mais vu la machine, il peut être intéressant de ne pas l'installer, si tu t'en sers juste de jukebox et de serveur de fichiers. Il est possible après tout que mpd attende après PA si ce dernier est présent…

Par contre ils se sont trompé de terme, je pense, parce que pour moi, c'est pas des pijul qu'on entre par l'anu.

Je suis déçu, mon troll a fait long feu, pas beaucoup de réponses. Ça marchera mieux un autre jour :D
Même la note est encore positive. Décidément, j'ai tout raté!

Plus sérieusement, je pense que LaTeX nécessite un apprentissage initial plus long pour faire des trucs simples, c'est clairement moins ergonome, moins intuitif, et en ce sens, je pense que les logiciels de traitement de texte sont nécessaires.

Cela dis, je préfère personnellement utiliser LaTeX non pas pour faire mon élite (je suis loin d'en être) ni parce que je suis un scientifique (j'en suis pas un), mais du fait que je peux utiliser mes outils habituels pour gérer le source du document: git, vim, grep, etc.

Autre chose que j'apprécie avec LaTeX, c'est qu'il me débarrasse presque complètement de la tentation de bricoler la forme, du coup, je me concentre sur le contenu, je vais plus vite, et même si c'est plus spartiate (j'ai pas de couleurs à la fin, par exemple) moi ça me conviens bien plus.

Le point bonus, c'est la taille finale (en octets) du source et le fait de pouvoir en générer même sur de très petites machines peu performantes.

Par contre, je n'irai pas recommander LaTeX à un utilisateur qui a juste besoin d'un document pas trop moche rapidement.

ça me semble problématique, mais je ne suis pas un expert

Le TOFU à ses inconvénients: si le site est frauduleux dès le début, on peut pas protéger. Si le site est un squat de domaine, idem.
Ceci dit, une faille dans la chaîne des CA, et c'est tous les maillons descendants qui sont cassés, on a déjà vu le cas, et pas qu'une fois.

En plus de ça, que risque-t-on?
Avec gemini, pas de cookies, pour commencer.
Et l'idée, c'est d'avoir des sites gemini simples, pas de cross-domain, pas de contenu qui s'exécute au hasard (dans l'esprit, hein, parce que je doute que ça soit impossible de le faire, me souviens plus)… contrairement au web.

Je pense personnellement que les chaînes de sécurités des CA sont d'une utilité plus que douteuse dans le cas d'un site type blog, ou le but est juste de communiquer sur un sujet qui intéresse l'auteur, ou qui permets le téléchargement d'un fichier.
Il n'y a pas de login, pas (besoin) de cookie, pas de langage turing-complet embarqué dans le document…

Pour ce qui est du typo-squatting… au final, le système de CA ne l'empêche pas non plus, il suffit de voir tous ces gestionnaires de paquets pour language de programmation qui se font exploiter.

Bref, sauf pour des sites sensibles, qui servent a interagir (type linuxfr), je ne vois pas trop l'intérêt des chaînes de certificats. Et même dans ce cas précis, je ne suis pas entièrement convaincu.
Bon, certes, dans le cas de ma banque, avoir un certificat qui soit validé par une autorité supérieure en laquelle j'ai confiance est un plus.
Mais justement… puis-je avoir confiance dans l'autorité certificatrice de ma banque? Ça serait mon gouvernement, peut-être (et encore, on pourrait arguer que certains gouvernements de certaines nations ne sont pas nécessairement dignes de confiance).
En l'occurrence, il s'agit de «Sectigo Limited». Tout semble indiquer une entreprise des USA, alors, la confiance, comment dire…

Fusion c est vers le liquide… de solide à gazeux, c'est la sublimation.

Autres points, sur les disques mecanique, l'accès aux données est légèrement plus rapide en début de plateau. Donc, mettre les données fréquemment accedees dés sur une partition proche du début de disque peut aider.
Il faut aussi penser à la fragmentation, si il y a beaucoup de fichier de grosse taille, les mettre sur un ds ayant une taille de cluster plus importante peut aider.

Côté logiciels, ne pas installer automatiquement les paquets recommandés par debian va aider, et, pour les utilisateurs plus avancés, jouer avec le démarrage auto des démons(écrire avec une tablette est vraiment horrible, désolé pour les mauvais termes et autres).
Il est aussi possible d'exposer le socket de mpd de sorte à le piloter d'une autre machine.

Tout ça ne sera pas forcemment perceptible, mais cummule cadevrais gagner un peu.

Parce que LaTeX, étant du texte pur et dur, se prête au versionning (CVS, SVN, SCCS, mercurial, bazaar, git, fossil…), ne casse pas son interface entre les versions, et se prête donc merveilleusement à l'amélioration continue, contrairement aux usines à gaz logiciels de traitement de texte WYSIWYG.

Du coup, oui, je dirais que c'est bien le logiciel qui est en cause.

Bon vendredi :)

Que des sites issues de vox.com ou facebook ne marchent pas parfaitement avec netsurf, ben, on s'en fout un peu non?

Perso, je constate déjà que même linuxfr.org ou lwn.net ne marchent pas avec dillo, et de mémoire pas non plus avec netsurf-gtk (de mémoire, parce que je le trouve pas dans aptitude, je creuserai plus tard).
Ce ne sont pas des sites qui sont a franchement parler bourrés de JS et autres cochonneries, pourtant. Non, c'est juste cet horrible CSS.

Et il y a tout de même QtWebEngine et WebkitGTK en libre donc on n'est pas obligé non plus de revenir au TeleType.

En même temps, tous les moteurs de rendu actuels sont libres. C'est pas le souci.

Autre mécanisme que j'appréciais beaucoup, mais plus récent je suppose: les rings. Par contre j'imagine qu'il fallait embarquer une page d'un autre site, ça pourrais en faire tiquer certains de nos jours.

Encore un autre mécanisme, plus récent encore: les flux RSS/Atom, je m'en sers personnellement surtout pour les BDs, via un pluging claws-mail, mais il faut reconnaître que claws n'est pas adapté à ça, du coup je pense que j'utiliserais plus avec un outil plus structuré.

C'est un réseau a part.

Gemini n'est pas un réseau mais un protocole réseau doublé d'un format de fichier.
Le web n'est pas non plus un réseau, mais un ensemble de protocoles doublé d'un ensemble de formats de fichiers.

Facebook n'est pas non plus un réseau, mais un site web, sur lequel peuvent éventuellement se construire ce que l'on appelle des réseaux sociaux, c'est à dire entre personnes.

Je pourrais très bien décider d'héberger un serveur HTTP et héberger uniquement des fichiers de texte brut. Ça ne serait pas le web, les navigateurs standards seraient à chier dessus parce qu'ils considèrent que l'interface graphique est le boulot du site web. Pour moi, ces logiciels que sont firefox, chromium et safari ne sont même pas dignes du titre de "navigateur", ce sont au mieux de (mauvais, très mauvais même) outils de téléchargement et de rendu de "documents HTML5", ce qui est la seule chose qu'ils arrivent à peu près à faire correctement.

Certains sites web bâtissent des réseaux, c'est vrai. Au travers notamment des «rings», mais c'est un peu un truc du passé, ça.

on peut toujours faire des choses très bien avec du HTML, HTTP, CSS voire JavaScript,

On peut pas faire un client correct supportant ces techno, de nos jours.
C'est ça que ces projets (enfin, surtout gemini) essaient de résoudre: avoir des specs claire, implémentables aisément, et pas réservées à google, apple et mozilla.

Enfin, si tu dis qu'on peut, vas-y, je suis curieux de voir le résultat (les gens de netsurf essaient depuis des années, ils avancent, mais ils en bavent, et sont très loin de supporter correctement les "specs" de html5).

Hormis utiliser du PXE mais c'est une autre histoire pour un débutant !

Et même du PXE c'est pas forcément possible, le firmware est un BIOS, ça supporte pas forcément le PXE… ça dépend de la carte réseau, et si elle supporte pas, il faut jouer avec des disquettes, de ce que j'ai lu… mais j'admets ne jamais avoir fiat de PXE avec du matos aussi vieux: j'ai essayé (avec du plus pourri, en fait: CPU mono-coeur 700MHz, ~192Mo de ram, MAIS 200Gio (ou 240?) de disque dur :p (ben oui, j'y ai collé mes 3 vieux PATA qui marchent encore: 2 de 80, et l'autre peut-être 40 je sais plus).

Pour en revenir au sujet, moi je collerai une Debian avec le bureau LXDE, mais par contre le web on oublie (pas internet, hein, juste le web: les mails avec claws ne poserons pas de souci, les webradios via vlc ou mpd non plus, irc j'en parle pas, etc etc). 512Mio de ram, c'est bien trop peu pour le web bourré de cochonneries.
Enfin, certains sites sont p'tet utilisables, via des trucs rustiques comme linx ou, un peu mieux, netsurf ou dillo, mais faut pas rêver, ça sera juste les sites qui restent utilisables sans JS, et ça sera pas joli (les CSS sont pas forcément super bien supportées: plus le site utilise des merdes «modernes», plus tu peux oublier…).

[edit]
Bon, ok, solid, en fait, ça a juste l'air d'un gros bloatware aussi. Ce qui a l'air du site officiel mets 3 plombes a charger avec la co pourrie que je me tape depuis quelques temps (déménagement à la cambrousse, initié pile avant le 2nd confinement…), à savoir 130Ko/s le vent dans le dos.
Pour comparaison, les pages gopher sont quasi instantannées, et pèse moins de 1meg.
Sans lien plus pertinent, je dirais donc: Solid? Dans la poubelle grise.

Et j'ai lu les specs d'ailleurs. L'un des trucs qui m'ont marqué, c'est le fait que ça spécifie explicitement une dépendance a un protocole de chiffrement.
Ce qui est triste, parce qu'il n'y a aucune raison de faire ça, et je pense même que ça risque de bloquer l'évolutivité à plus ou moins court terme, la ou les gens qui fournissent des fichiers via http, s ou pas s, peuvent juste exposer un serveur http sur un port, et un proxy pour le chiffrement sur un autre port qui appelle le 1er (c'est ce que j'ai sur mon serveur: darkhttpd sur lo::8080, hitch sur lo::8443 qui redirige sur lo::8080, et des règles iptables qui redirigent comme il faut les ports par défaut).
Bref, pour du minimalisme, c'est raté de mon point de vue.

Je suis aussi sur un IRC ou ça aime causer de ce genre de trucs, et je suis pas le seul a avoir relevé ce point, même si ça veut rien dire.
Il y avait d'autres points que j'ai relevé, mais je me souviens plus.
Au final, je ne vois pas l'intérêt. De mon point de vue, c'est bien moins chiant d'exposer un serveur http qui laisse le client explorer l'arborescence et faire sa propre interface.
En aucun cas, un client http ne se doit d'être un client web, et tous les clients web que je connais sont loin d'avoir les fonctionnalités que j'attendrai d'un navigateur: je suis obligé d'utiliser les liens fournis par un document pour pouvoir trouver les autres ressources, je ne peux donc pas naviguer, et encore moins explorer, mais soyons honnêtes: c'est pas la faute de http si les gens ne s'en servent (quasi) que pour exposer des fichiers html (qui sont le vrai problème pour moi) et des scripts cgi.

Pour rappel: HTTP veut dire «HyperText Transfer Protocol». Et non «Hyper bloaTed Transfer Protocol». Au final, c'est le même problème qu'il y a eu (qui se calme, il me semble) avec XML: utilisé pour tout et surtout pour n'importe quoi, sans exploiter les vraies fonctionnalités. Encore que, XML au moins a encore un standard et des specs claires, qui ne changent pas selon le vent, lui.

Cela dis, je m'en vais creuser autour de ton autre machin, on sait jamais.

PS: pour gopher, il existe dooble qui est un navigateur web tout en supportant gopher. C'est un peu moins inconfortable que les clients de type cgo (par exemple) ou les proxy web, mais on y voit, justement, les limitations d'un protocole couplé à un format de fichier (ce qu'est en réalité gopher, tout comme gemini) «minimaliste».

Moui… de la ou je suis, je suis a ~8Km de la 1ère ville de taille acceptable. Comptes un aller-retour: 16km. Pour faire les courses "quotidiennes".
À cette distance, si t'as une pause repas assez longue (1H ou plus) et que tu bosses dans cette ville, ben tu rentres chez toi pour manger (pas écolo et plus cher que la gamelle, mais bien plus agréable). Hop, 32km.
En pratique, les gens vont souvent faire 20 minutes de route pour bosser, au moins. On estime dans mon coin les moyennes de vitesse à 50Km/h sur un trajet, donc a peu près 17km minimum pour aller bosser. Et le retour… 34km.
C'est du pifomètre, certes, basé sur mon expérience et celle des mes proches.

Aller voir un frangin ou un pote, tu ajoutes encore vite fait 10 bornes. Et bien d'autres usages, en admettant faire tout dans un cercle inférieur à 8Km de rayon, ce qui est loin d'être gagné.

Maintenant, il faudrait aussi définir ce que tu appelles rare: une fois par semaine, c'est rare ou pas, pour toi?

surtout quand on n'est pas dans une grande ville qui donne accès à transports en commun

Même certaines grandes villes ne donnent accès a des transports en commun à intervalles assez rapprochés (moins d'une heure) qu'a certaines zones. Tout en ayant un tarif également assez élevé du ticket, avec en prime ce gros foutage de gueule qu'est le télé-paiement (quand ça marche, ça coûte plus cher que le ticket unitaire!).
Rouen, c'est de toi que je parle (j'ai connu d'autre villes ou ces problèmes étaient moins vrai voire absent, la région parisienne notamment, mais aussi Caen, et peut-être d'autres, je sais plus).