Oh là là 😢, LEA Linux, le *grand* guide que tout le monde a consulté pour débuter tout Linux.

zram ou zswap ? Cet article est très en faveur de zswap.

Règles générales:
- N'utilisez jamais simultanément zram et zswap.
- Si vous avez du swap disque, n'utilisez pas zram en complément. À partir du moment où vous avez du swap disque, zswap est préférable.
- D'une manière générale, zswap se comportent mieux quand il y a beaucoup de pression sur la RAM.

Voir si zswap est actif : cat /sys/module/zswap/parameters/enabled
(renvoie Y ou 1 si actif)

L'activer au prochain redémarrage :
1) éditer le fichier /etc/default/grub
2) dans la ligne GRUB_CMDLINE_LINUX_DEFAULT ajouter le paramètre : zswap.enabled=1
3) sudo update-grub

Une remarque tout à fait pertinente que je me permet de recopier ici :

"On continue avec les stéréotypes de l’UX autour de logiciel libre : « Linux c’est tout en ligne de commande » et « la ligne de commande c’est pas bien ».
Comment sait-on que c’est un stéréotype ? En 2026, simplement parce que les agents conversationnels sont considérés par *les mêmes personnes* comme une bonne UX.
Or, un chatbot n’est jamais qu’une forme dégradée de ligne de commande : moindre répétabilité, plus de place à l’ambiguïté, etc.
Donc, si une interface fondée sur un langage est une bonne UX, alors la ligne de commande ne peut pas être pire qu’un chatbot. Et si ce n’est pas le cas, alors le chatbot ne peut pas être une bonne UX.
Un raisonnement similaire s’applique pour l’idée que les interfaces graphiques seraient nécessairement plus simples. Car en effet, qui pourrait accepter l’assertion qu’il est plus simple de trouver l’adresse de sa carte réseau dans l’UI graphique de Windows que de taper ̀ipconfig̀ dans un terminal ?
C’est d’ailleurs une des sources du premier stéréotype : il est beaucoup plus facile de dire à un utilisateur qui veut régler son problème sans le comprendre de copier/coller ça dans un terminal, que de lui faire suivre la longue série de clics permettant de trouver le truc au fin-fond des paramètres.
Au final, c’est juste un compromis découvrabilité/puissance différent. Méfiez-vous des stéréotypes. "

Sous le coude, à tester : une dictée vocale pour Linux 100% offline.

Je vais être franc : Même si je ne suis pas fan de la distribution Arch Linux, il faut admettre que leur wiki est vraiment d'excellente qualité. 👌🏻

18 ans après la sortie d'Android (basé sur Linux), Google se décide à nous rendre le terminal.

CLAP.

CLAP.

CLAP.

Haha je me reconnais tellement là dedans : "À 40 ans, un utilisateur Linux cesse d’essayer d’installer Arch sur un grille-pain juste pour prouver qu’il en est capable. Il finit par opter pour Debian Stable ou Mint, car il réalise qu’il n’a plus la « capacité mentale » de passer 6 heures à configurer des choses ou à réparer des systèmes défectueux juste pour consulter ses e-mails ou regarder Netflix."

La "Linux Foundation" n'est plus qu'un conglomérat de corporations qui ne sont là que pour utiliser Linux et les Logiciels Libres à leur bénéfice.

Tiens cette API système Linux est intéressante pour que les développeurs d'application restreignent d'eux-même leurs applications. Ce qui peut s'avérer salutaire en cas de faille de sécurité. Par exemple, une application - à son démarrage - peut déclarer au système:
- j'accède à /home/user en lecture seule.
- j'accès à /tmp en lecture/écriture.
- j'ouvre le port 2222

Le système lui donnera accès à ça, et uniquement à ça pour la durée de son fonctionnement. L'application ne peut alors plus étendre ses droits.
Tout processus forké depuis l'application aura les mêmes restrictions (ou des droits encore moindres), mais ne pourra pas les augmenter.

Ainsi si une faille de sécurité est exploitée dans le logiciel, il ne pourra aller faire trop de dommage. Par exemple si un logiciel se restreint à son répertoire de configuration, il ne pourra pas aller lire ~/.ssh ou aller modifier ~/.bashrc.

Par rapport à SELinux ou AppArmor, l'API est plus simple à utiliser et surtout elle ne nécessite pas d'intervention/activation de la part de l'administrateur.
L'API landlock est disponible depuis le noyau 5.13 et peut donc être naturellement intégrée à n'importe quelle application.

Y'a pas que moi qui le dis.

Ça commence à se voir (et pas qu'une seule fois) que Linux permet d'avoir de meilleures performances que Windows dans les jeux.
Des tests avaient déjà été effectués sur une console portable Legion.
Ce genre de test se fait souvent sur les consoles portables, parce qu'elles ont moins de puissance que les PC, ce qui rend les différences plus visibles, mais croyez bien que c'est la même chose sur PC.

Je confirme ce pourcentage.
Ça fait des années que je joue sous Linux, même aux jeux Windows, que ce soit dans Steam ou hors de Steam.

NVidia casse quand même les couilles en refusant d'ouvrir les sources de leur pilote (au contraire d'AMD), ce qui aiderait énormément Linux.
Du coup, ce sont des développeurs chez RedHat qui essaient de développer un pilote Libre pour les cartes NVidia (le seul pilote qui existait - Nouveau - n'était pas fameux).

NVidia essaie quand même d'aider en fournissant des documentations confidentielles au développeur en question chez RedHat.
C'est pas extraordinaire, mais c'est déjà ça.

Je pense que mes prochaines cartes graphiques seront des AMD.
(D'autant que NVidia commence à ne plus supporter ses anciennes cartes dans son pilote privateur.)

(Après, actuellement je ne me plains pas : Ma NVidia RTX3070 fonctionne à merveille sous Linux avec le pilote propriétaire NVidia. Tous les jeux, même les derniers jeux Windows sortis.)

Chouette chouette chouette. Il a l'air très bien ce nouveau modèle.
Par contre c'est la charnière de l'écran qui m'inquiète.

(Article complet : https://app.wallabag.it/share/68c3efa58aaa22.08885241)

J'avais déjà vu passer nnn, un gestionnaire de fichiers pour le terminal qui a l'air super balaise.
Il faudra que je prenne le temps de m'y intéresser.
Merci à https://shaarli.zoemp.be/shaare/wn38FA pour le rappel !

Sous le coude: un outils TUI (en terminal) pour gérer les services systemd.
(via https://shaarli.zoemp.be/shaare/vWUA7Q)

Intéressant comme technique pour faire du RCE (Remode Code Execution): Un fichier dont le nom contient un script shell.
Un simple for f in *; echo “$f” dans le répertoire contenant le fichier déclenche l'exécution.

Source : https://www.trellix.com/blogs/research/the-silent-fileless-threat-of-vshell/

Une astuce avec LVM pour utiliser un SSD comme cache d'un HDD.

Je crois qu'on ne peut plus dire - comme j'ai parfois entendu - que btrfs n'est pas "mûr" et pas assez fiable pour être utilisé en production : Facebook s'en sers massivement.

Un graaaaaannnd guide de sécurisation de Linux (plutôt orientée Debian)

ClearLinux arrêté, CentOS qui en prend un coup dans l'aile... moi je vous dis si vous voulez de la stabilité et de la pérennité, il vaut mieux regarder du côté de Debian.

Merde merde merde. C'est le truc auquel on avait échappé jusque là et que je craignais de voir arriver : Des packages malveillants dans les distributions Linux (Juste Arch pour le moment, et les dépôts AUR, c'est à dire des dépôts pas approuvés par Arch).
Je pense que nous n'en sommes qu'au début 🙁

Sous le coude : Un article plutôt pro-systemd, avec des arguments.

Contexte : La gestion des processus, services et du démarrage du système sous Linux a été massivement mis sous la coupe du logiciel systemd dans beaucoup de distributions Linux.
Or sur le principe, systemd est totalement contraire à la philosophie de Linux qui est "un programme qui ne fait qu'une chose, mais qui la fait bien".
systemd essaie au contraire de vraiment tout faire dans le système, du montage des disques à la résolution DNS en passant par la synchronisation NTP de l'horloge. Ça lui a beaucoup été reproché, et dans certains cercles systemd est profondément haït.
Mais il a aussi ses bons côtés.

Décidément l'histoire de bcachefs n'est pas un long fleuve tranquille.