rogo a écrit 282 commentaires

Les gestionnaires de mots de passe, notamment ceux intégrés aux navigateurs, sont bien pratiques. D'ailleurs pass avec un dépôt Git cloné sur mes machines me convient très bien.

Oui mais si t'as pas ta machine à côté (ou si tu la perds ou on te la pique), t'es mal.

Non, justement. Tous mes comptes sont dans un dépôt Git chiffré, donc je peux perdre mes machines sans perdre mes authentifications. Et ces infos sont clonées partout où c'est utile.

Dans le gestionnaire de mdp du navigateur, je ne mets que les sites sans risque. Je peux ainsi m'authentifier sur Linuxfr avec un simple Ctrl-Entrée, tandis que j'utiliserai pass pour une banque. Donc si on me vole une machine, les dégâts seront limités.

À contrario, le système proposé ici est moins robuste. Si on vole un mobile avec un client XMPP, on peut ensuite s'authentifier en un clic ! C'est pour cela que l'authentification par SMS n'est utilisée qu'en second niveau, après l'authentification principale.

Merci pour cette réponse, c'était instructif. Du coup je suis allé lire la XEP mentionnée dans la dépêche pour mieux comprendre. Le principal handicap technique de Persona, c'était que le domaine de l'email devait gérer le protocole de Persona, sinon c'est Mozilla qui reprenait la main. Pour le processus décrit dans la dépêche, si j'ai bien compris, le domaine du jid n'a rien à faire ; la seule contrainte est que le serveur de départ puisse se connecter en HTTPS à une autorité de confiance qui joue le rôle d'intermédiaire (en étant un serveur XMPP avec ce composant). C'est ça ?

En pratique, ça ne me semble simple à utiliser pour le développeur que si on n'a pas à installer un serveur XMPP. Donc soit le projet gère déjà un tel serveur, soit il va confier l'authentification à un tiers si le besoin de sécurité n'est pas très élevé. Est-ce qu'il y a de serveurs prêts à l'emploi, qui soient de facto des "autorités de confiance" HTTP/XMPP ?

Reste à savoir si on veut dépendre des FB et autres G+ ou pas.

Heureusement qu'il n'y a pas que ça comme alternative, parce que je ne me suis jamais connecté à ces machins, et je m'en passe bien. Les gestionnaires de mots de passe, notamment ceux intégrés aux navigateurs, sont bien pratiques. D'ailleurs pass avec un dépôt Git cloné sur mes machines me convient très bien.

En lisant la description, j'ai tout de suite pensé à Persona, le système d'authentification proposé par Mozilla. Persona proposait que l'identification soit gérée par un compte email, alors qu'ici c'est un compte XMPP. Il y a eu beaucoup d'enthousiasme dans la communauté du libre, mais ça n'a pas décollé, et Mozilla abandonne complètement le projet à la fin de l'année.

Là, j'ai l'impression qu'on est dans une niche encore plus étroite. Autrement dit, un site devra en pratique ajouter ce système en parallèle de mécanisme plus larges. Même pour l'utilisateur client, il y a des inconvénients évidents : il faut avoir un client XMPP actif, et l'anonymat est plus faible qu'avec le couple mdp/email-jetable. Ça ne veut pas dire que ce protocole est inutile, mais même sur un site optimal pour lui comme linuxfr, je soupçonne que cette authentification serait adoptée par une minorité d'utilisateurs.

je ne me se soucie pas trop de savoir si IPv6 est bien configuré sur mes machines.

Si tu as parfois des comportements bizarre de tes machines, il faudra regarder du côté d'IPv6, parce qu'avoir un truc mal configuré mais actif, ça peut poser des problèmes de stabilité et de sécurité.

Un exemple : on avait un VPS dont le postfix essuyait parfois des refus. La plupart des emails partaient bien, mais de temps à autre, quelques uns nous étaient retournés. Quand on testait, tout allait bien. Un jour un refus a été motivé de façon plus claire, et on a compris que Postfix utilisait parfois IPv6. Or notre config, notamment DNS, était écrite pour de l'IPv4 seulement.

[…] a récemment substitué Scaleform pour OpenFL pour produire son dernier jeu vidéo mobile (John Madden) Une grand majorité […]

[…] a récemment substitué OpenFL à Scaleform pour produire son dernier jeu vidéo mobile, John Madden. Une grande majorité […]

• Substituer X à Y, c'est mettre X à la place de Y.
  Ce prince [Caligula] faisait transporter de la Grèce en Italie les plus parfaites statues des dieux, auxquelles on coupait la tête pour y substituer la sienne, [Diderot, Essai sur les règnes de Claude et de Néron. I, 5] in Littré, substituer.
• Il manque un point à la fin de la phrase.
• Le John Madden entre parenthèses, j'ai supposé que c'était le nom du jeu, mais sans certitude car la syntaxe indiquait le contraire. Une virgule suffit à l'apposer, et des guillemets ou l'italique permettent de signaler que l'on cite un titre. A contrario, les parenthèses sous-entendent un élément extérieur, par exemple la source de l'information.
• Accessoirement, il manque une virgule dans la phrase précédente, pour le bloc de gagnant à récompenses.

 
À part ça, la dépêche est excellente : une présentation succincte mais claire, avec un peu de contexte pratique et historique, et des pointeurs pour aller au-delà. Merci !

Un publi-reportage fournit rarement une information concrète, sans parler de sa fiabilité. Comme en plus le lien adjoint à la dépêche pointe vers le site commercial, il ne va pas être simple de trouver autre chose que du baratin peu crédible. Le modérateur a rajouté une phrase de contexte avec Wikipedia, mais ce n'est pas suffisant.

 Après avoir simplifié l'accès à GNU/Linux et avant d'y avoir implémenté des synthèses vocales de haut niveau, la société Hypra a résolu la question de l'OCR.

Quand je lis une rodomontade de ce genre, publiée sans filtre en première page, le site baisse d'un cran dans mon estime. Moralité : toute confiance en un site web doit être minimale, il faut juger de chaque information au cas par cas, en fonction de la source et des croisements possibles. À mes yeux, cette dépêche ne vaut rien.

Où as-tu vu que M. Le Pen défendait mes convictions ?

Je ne sais pas si tu caricatures sciemment ou si tu m'as compris de travers. Dans le doute je me résous à une explication de texte : le commentaire initial déniait à M. Rocard le titre « ami du logiciel libre. » C'est dans ce contexte qu'il faut lire ma phrase, où je faisais un parallèle entre « ami du LL » et une forme d'amitié individuelle.

Au niveau du logiciel libre, je ne connais pas les positions de M. Le Pen, mais comme elle n'a pas milité pour, contrairement à M. Rocard. Donc on ne peut pas dire qu'elle est une amie du logiciel libre.

Au niveau personnel, je peux lister des personnes que je ne connais pas mais pour qui j'ai de l'amitié, à cause de convictions communes et de traits intellectuels ou sentimentaux avec lesquels j'entre en résonance forte. Par exemple, Primo Lévi, Jorge Luis Borges ou Roni Brauman.

source ?

À ma connaissance, il a pris des positions systématiquement favorables au logiciel libre. Si tu penses que c'était par opportunisme et pas par conviction, il faudrait au minimum donner un argument.

Quelqu'un qui se rallie à mes arguments, me témoigne de la sympathie, et fait un effort pour défendre mes convictions, je veux bien le qualifier d'ami.

Tu penses vraiment qu'il avait un intérêt quelconque, dans sa carrière politique finissante, à froisser le puissant lobby de l'"Intellectual Property" en cajolant quelques libristes désargentés au point de ne financer qu'un billet aller simple pour aller le rencontrer à Strasbourg ? C'est sûr, le camp du logiciel libre a ramené des millions de voix à la liste PS aux élections européennes de 2004…

La raison me semble simple. On la voit faire une intervention visiblement critique du rapport, ce qui agace la rapporteuse, celle qui se disait harcelée par les soutiens du libre. Le commentaire, à ce moment, parle d'ailleurs des partisans du logiciel libre qui luttent contre cette loi.

Il y a peut-être des raisons secondaires, et notamment que c'est une belle jeune femme, et que dans un documentaire globalement pas bien finaud, ça souligne l'opposition entre les jolis gentils et les affreux méchants. Toutes mes excuses à Mme McCarty (rapporteuse favorable aux brevets logiciels).

Quant à l'identification, si vraiment tu y tiens, ça me semble difficile. Pour le peu qu'on entend derrière le commentaire, elle ne parle pas une langue romane. Avant de voir la vidéo, j'avais pensé à Ska Keller, une "verte" allemande favorable aux logiciels libres, mais ce n'est pas sa tête. Et bon courage pour trouver un plan des sièges de l'assemblée européenne de 1999-2004 !

Le lien LiteSpeed dans la dépêche pointe sur une page d'erreur, à remplacer sans doute par https://www.litespeedtech.com/products/litespeed-web-server/overview.

Par curiosité, je suis allé regarder les benchmarks réalisés par LiteSpeed, notamment pour du PHP. Ils annoncent des gains fantastiques : LiteSpeed + PHP-FPm serait 86% plus rapide que Nginx + PHP-FPM et 203% plus qu'Apache + PHP-FPM. Sauf qu'on n'a pas les détails permettant de reproduire ces mesures, et qu'on peut supposer que les configurations jouent beaucoup. Comme par hasard, les deux liens pour en savoir plus sont faux : le forum donne une page d'erreur, et l'archive des configs ne correspond pas à des serveurs PHP.

En cherchant d'autres comparaisons récentes, j'ai vu que certains donnent Nginx légèrement gagnant. Je doute qu'à configuration optimale un serveur puisse être 3 fois plus rapide que ses concurrents. Il semble d'ailleurs que la version non-libre de LiteSpeed utilise par défaut un cache des requêtes FastCGI, ce qui fausse les comparaisons à moins d'activer les équivalents dans Nginx et Apache.

Les processeurs AMD ont un équivalent du système ME d'Intel. Il est un peu moins intrusif puisqu'apparemment ce processeur ARM caché dans tous les CPU récents d'AMD n'a pas accès au réseau, contrairement à ce qu'Intel pratique.

Pour plus d'info sur chaque cas, lire la FAQ de GNU Libreboot.

À propos de MOSS/SOS, le projet de Mozilla à 500 000 $ pour financer la sécurité des logiciels libres, l'article mis en exergue est une simple reformulation de l'annonce officielle par un chargé de relation publique de la fondation.

Le second article, de zdnet, est plus complet, parce qu'il reprend l'interrogation de LWN sur le doublon avec le projet similaire de la fondation Linux, appelé CORE. Il mentionne un email d'explication de Mozilla qui n'est en fait que la traduction de leur wiki.

Pour le plaisir, je cite la magnifique langue de bois estampillée Mozilla qui explique le rôle de ce projet par rapport à CORE.

Focusing on more point-in-time solutions, the SOS Fund's audit and remediation methodology targets a different class of OSS projects with lower-hanging fruit security needs, using an open public-facing application form.

Focalisé sur des solutions plus localisées, l'audit et la méthodologie corrective du fond SOS visent une classe différente de projets en logiciel libre, avec des besoins de sécurité plus accessibles, via un formulaire de demande librement disponible.

Bref, ils se voient comme le CORE du pauvre, moins compétent mais plus accessible.

Au-delà de leur explication ampoulée, le simple fait qu'ils n'aient pas évoqué cette concurrence lors de l'annonce est inquiétant, comme s'ils n'avaient pas conscience de la situation. Et pourquoi ne pas s'être greffé à CORE, en lui ajoutant cette carte "petit projets faciles" plutôt que de créer une machinerie concurrente ?

Le langage shell utilisé est le même pour les deux cas. Du coup, je ne vois pas trop comment runit ferait moins bien que sysVinit?
Je reconnais n'avoir pas essayé, mais, ça ne marche pas de lancer les scripts de /etc/init.d par runit?

Comme quoi on peut avoir installé runit, le promouvoir comme alternative à systemd, vanter sa documentation… et ne pas avoir compris les principes de base de runit. Ses scripts de lancement doivent rester en premier plan, contrairement aux lancements de démons qu'on trouvent dans /etc/init.d/.

Du coup, vraiment, l'argument de la norme en faveur de systemd et contre runit il est pas terrible :)

Merci de ne pas déformer mes propos. Je disais que pour Runit les scripts shell ne suivaient pas la norme de SysVinit. Je n'ai pas comparé avec systemd et son format de configuration.

Mais si tu viens sur ce terrain, alors parlons de la magnifique norme pour lancer un démon avec SysVinit : chacun se démerde comme il peut avec son shell et les outils du bord. Et bien sûr, les outils standard dans le monde Debian (comme start-stop-daemon) ne sont pas présents chez Redhat. Runit a fait le choix de prendre en charge la démonisation, mais avec l'inconvénient de mal gérer les processus qui forkent. À comparer avec systemd qui s'accommode de tout, y compris les doubles forks. On peut le détester sur plein d'aspects, mais il faut reconnaître qu'il apporte aussi des progrès techniques par rapport à tous ses concurrents, et c'est pour ça qu'il s'est largement imposé.

Ça aurait sûrement marché, mais j'ai du mal à croire que des gens mettent des services comme apache2 dans leur inittab. Pour arrêter un service on change de runlevel?

Pour ma part, j'ai utilisé runit en production, pas juste sur une VM par curiosité. C'est un bon outil, mais j'ai basculé sans hésitation vers systemd quand Jessie est sortie.

D'abord, il faut rappeler que runit ne suit pas la norme SysVinit. Donc il faut se coltiner l'écriture de scripts en shell pour piloter le démarrage des services, en remplacement de ceux écrits dans /etc/init.d/. Debian ne les fournit pas et qu'il n'y a pas une grosse communauté autour de runit (admirez la litote ;-).

Mon besoin était de surveiller (monitoring) des services dont l'un n'avait pas de mode démon. Il n'écrivait même pas son PID dans un fichier. Ça a l'air tout bête, mais il n'y a guère d'outil pour surveiller un service de ce type, et le relancer en cas de crash ou de signal d'arrêt. C'est pour ça que j'avais opté pour runit.

Par contre, je me suis retrouvé avec le problème inverse : il fallait que les services soit lancés en premier plan, sans forker en tâche de fond. Et Runit n'utilise pas les cgroups, donc un service peut échapper à son gestionnaire — à sa décharge, les cgroups sont apparus bien après lui.

En pratique, je trouvais aussi que runit n'étais pas si simple que ça à administrer. Par exemple, je lançais autant que possible les processus avec des utilisateurs différents, pour des raisons de sécurité. Avec Runit, soit il faut activer un mécanisme global de déclaration dans les répertoires des utilisateurs, soit il faut jouer avec su dans les scripts shell des services. Autre exemple, la gestion des dépendances est vraiment très sommaire : c'est au script shell de tester si ses pré-requis sont là, et de quitter s'il manque quelque chose, ensuite runit essaie de le relancer plus tard.

Quant à la vitesse, oui runit est rapide, mais je doute qu'il le soit plus que systemd, notamment parce qu'il lance un nouveau shell pour chaque service. De toutes façons, quand une machine démarre en moins de 5 secondes, je ne vais pas faire la course pour quelques dixièmes.

J'ai du respect pour runit, un petit outil bien fait (hélas peu documenté), mais à mon avis il n'a pas la carrure pour être le gestionnaire de démarrage d'une grande distribution.

Ça ne me surprend pas plus que ça que ça soit réactif, un serveur web ce n'est pas spécialement lourd […] mais si on gardait un œil sur l'utilisation des ressources système, il est probable que la moyenne soit d'utiliser ~20% du CPU (au doigt mouillé) et que ça dépasse rarement les 3Gio de RAM (hors utilisations particulières type jeux/travail multimedia).

Je suppose que tu n'as jamais travaillé sur un serveur Moodle ? Parce que le doigt mouillé, c'est bien pour les avions en papier, mais c'est un peu limité pour diriger un airbus ;-)

En pratique, contrairement à ce que tu sous-entends, le facteur qui limite Moodle est généralement le CPU. C'est surprenant pour beaucoup, et c'est d'ailleurs en contradiction avec les docs du Wiki officiel de Moodle. Il faut dire que Moodle, c'est environ 2 millions de lignes de code PHP, sans parler du JavaScript où il paie depuis des années la dette technique de YUI. Le serveur web, Nginx, n'a guère de boulot, mais PHP-FPM sue sous le fardeau.

Pour une dizaine de personnes qui consultent des documents, donc sans connexions intensives, un RaspberryPi3 peut convenir, mais une centaine d'utilisateurs concurrents peut suffire à mettre à genoux une VM à 8 cœurs dans un Xeon. Certaines opérations sont très coûteuses en CPU, par exemple l'authentification locale ou la soumission d'un QCM (quiz). Alors, bien sûr, le CPU ne fait rien la plupart du temps, mais le jour où plusieurs classes passent des tests simultanés, il faut une bête de course pour tenir la charge.

Nos expériences divergent sur le tout JavaScript et les interfaces résultantes qui ont tendance à être plus faciles à appréhender par les utilisateurs. Il y a deux semaines, une amie, qui travaillait avec moi sur un Framapad, a réalisé que ses deux heures de travail de la veille n'avaient pas été enregistrées. Je vous laisse imaginer la crise. Depuis, on est passé sur du wiki, parce que là le serveur nous dit si nos modifications ont été enregistrées.

Plus généralement, JS est trop souvent un truc qui ne sert qu'à ajouter des gadgets clinquants en ralentissant la page. Des sites statiques par nature, comme ceux du NYTimes ou du Monde, sont bien plus réactifs quand on les débarrasse de ça. Et certaines pages toutes bêtes mettent 10 secondes à se charger alors qu'une page HTML+CSS serait instantanée. Alors d'accord, sans JS je perds les carrousels et le défilement des pages est géré nativement par mon navigateur web, mais j'y vois plutôt un avantage.

Quand je remplis un formulaire et que je touche "backspace" sans focus, je peux revenir à ma page, le navigateur a conservé ce que j'ai déjà saisi… sauf si la page est dynamique en JS.

Bref, mon problème n'est pas la sécurité, c'est que JavaScript implique souvent lourdeur et fragilité, et que c'est une tendance de fond du web. Et je rappelle que "Fourmilieres" a planté chez moi, même en activant le JavaScript.

Si je veux installer un logiciel sur un serveur, j'ai besoin de savoir quelles sont ses dépendances, et donc quelles technologies il utilise. Entre PHP/Symfony et Haskell/Yesod, il y a un gouffre. Et puis je préfère installer des trucs donc je comprends le code.

Ici, c'est du NodeJS. Pas de serveur web nécessaire. Et si JavaScript est désactivé dans le navigateur, on a une page intégralement blanche. Dans mon navigateur par défaut, certes vieux et plus maintenu mais malheureusement sans équivalent moderne, j'ai une erreur JavaScript fatale quand je veux créer un formulaire.

J'ai du mal à comprendre l'engouement pour ces développements "tout JS" par rapport au bon vieux principe client-serveur page par page du web, éventuellement mâtiné d'un peu d'asynchrone (AJAX-AJAJ). D'accord c'est amusant d'essayer de nouvelles techniques, mais qu'est-ce que c'est fragile, même au niveau de l'écosystème NodeJS.

À ma connaissance, l'état de l'art pour produire du code JavaScript à partir de Haskell est ghcjs. Comme son nom l'indique, la conversion se fait au niveau de l'API de GHC (Glascow Haskell Compiler, l'implémentation de référence du langage Haskell depuis bien longtemps, pour ceux qui ne connaîtraient pas l'écosystème de Haskell).

Il y a toutes sortes d'avantages par rapport aux méthodes qui tenaient la corde avant ghcjs, notamment haste et fay. L'un est que l'on écrit du code Haskell relativement classique, puisque la conversion en JS se fait à un niveau assez bas. Un autre est, paraît-il, la rapidité et la compatibilité. Mais je n'ai essayé que ghcjs.

Mon expérience est toutefois très limitée. J'avais essayé surtout par curiosité, et je n'avais pas été convaincu. J'avais l'impression de devoir écrire bien plus de code en Haskell que son équivalent JavaScript, avec des dizaines de modules et fonctions idoines à apprendre, pour un résultat (post-compilation) énorme et assez cryptique. En compensation, je bénéficiais des types algébriques et autres conforts fournis par Haskell. Pour être rentable, il aurait fallu avoir à écrire une grosse appli JS. C'était il y a un an, et ghcjs s'est sûrement amélioré. Pour voir à quoi ça ressemble, il y a les exemples officiels, notamment le helloworld (qui va bien au-delà de "hello, world!").

Certes, on peut abusivement dire « chiffre » pour « nombre  » mais j'y vois deux inconvénients :

• on passe pour un plouc incapable de différencier nombre et chiffre, goudron et route, ordinateur et Windows, web et internet ;
• on profane le repos éternel d'Émile Littré.

Après on ne s'étonne que les jeunes ne sachent plus lire les classiques ! Par exemple :
Aussi bien n'y suis fors que une ciffre donnant umbre et encombre, [Chastelain, Chron. des ducs de Bourg. II, 26]

;-)

Pour préciser la comparaison — d'autant plus que les liens sont temporairement déroutés car le site openhub est en maintenance — voici les données (openhub via le cache de Google) sur les 12 derniers mois :

• Qt5 a 133 % de commits en plus que Gtk+ (11444 contre 4900).
• Qt5 a 112 % de contributeurs en plus que Gtk+ (376 contre 177).
• Tous deux ont un nombre de contributeurs décroissant (perte de 15 % environ par rapport à l'année précédente).
• Sur le dernier mois, Gtk+ a été plus actif.

Mais concernant Thunderbird, le problème de technos pas très vivantes me semble aller au-delà : XUL est moribond, et on ne peut pas dire que Gtk2 soit fringuant. Sachant qu'en plus la migration vers Gtk3 est en cours, je comprends que les envies de contribuer soient reportées à plus tard.

C'est gentil de lui faire un business-plan, mais on ne crée pas toujours un logiciel pour faire carrière. Si son logiciel répond aux besoins des petites structures sans moyens — et sans compétences MARC ni z39.50 — et que quelques bénévoles en assurent le suivi, ça peut donner un projet beau et utile.

Il y a un 3eme SIGB libre : waterbear, qui se veut également (très) facile à prendre en mains aussi.

Je vais en page d'accueil de waterbear pour découvrir son fonctionnement. Je fuis les liens "découverte" et "documentation" qui ne parlent que de vidéos, et donc je clique sur le premier lien "inscription", pour voir à quoi ça ressemble. Réponse en HTTP 200 avec pour seul contenu :

Impossible de s�lectionner la DB

• erreur de DB,
• pas de gestion des erreurs côté serveur (Exceptions, etc),
• message brut, façon "vite fait mal fait, mais je reviendrai corriger ça plus tard",
• encodage Latin1 ! Pour un logiciel de compta, passe encore, mais pour gérer une bibliothèque, que fait-on pour l'œuvre de Fænelon ou les livres sur π ou la découverte du 日本語 ?

ReactOS n'est pas qu'un noyau NT libre. À moins que j'ai compris de travers la dépêche, ReactOS contient un noyau compatible avec NT, mais implémente aussi des surcouches applicatives.

Une bonne part de ce que veut ré-implémenter ReactOS est très bien documentée, même si cette documentation est destinée à des développeurs qui souhaitent utiliser les API de Windows dans leur programme, et non construire une implémentation alternative.

Certes, le noyau n'est pas officiellement documenté, puisqu'il n'est pas publié. Par contre, le code source des noyaux de Win200 et NT4 avait fuité en 2004. On peut supposer que cela a beaucoup allégé la charge de rétro-ingénierie sur cette partie.

La rédaction c'est un travail et une synchronisation au jour le jour pour comprendre l'optique retenue par les contributeurs :-)

Vu le smiley final, j'imagine que c'est du second degré. Parce que je me suis déjà un peu impliqué sur d'autres dépêches noyau, mais beaucoup sur celle-ci. De mémoire, mes modifs doivent être réparties sur au moins 5 jours différents et étalées sur plusieurs semaines. C'est justement parce que je m'étais investi que le manque de perspective m'agaçait. De l'optique dans le brouillard ;-)

Alors là, je suis très déçu, rediger-des-depeches-noyau est là […]

J'avais lu cette page sans en retirer grand chose ; ce sont des généralités, certes utiles, mais insuffisantes. La partie "Notes" est presque illisible — même en pensant à lire de bas en haut !

Un exemple pratique : quelqu'un avait rédigé dans cette dépêche plus de 20 paragraphes sur un sujet précis, dans une section sans mainteneur. J'ai mis une note pour signaler que ça me semblait déséquilibré. Une personne a acquiescé. Et ensuite ? J'ai attendu une semaine pour voir s'il y avait d'autres réactions, si possibles plus directives, avant de rédiger un paragraphe de remplacement, mais sans oser rien effacer. Une semaine plus tard, quelqu'un a fait le ménage.

Autre exemple : la liste des mainteneurs de sections, en fin de dépêche, est complètement bancale (section "IPC" fantôme, plusieurs sections non déclarées, etc). Je l'avais signalé dans la tribune, et demandé s'il y avait un usage établi, sans obtenir de réponse.

Jusqu'à la fin, je me suis attendu à ce que les sections Virtualisation et Cgroups soient rédigées. Mais, contrairement à Réseau et FS, elles en sont restées à l'état de traductions de message de commit, bien indigestes. Si j'avais su, j'aurais peut-être cherché à rendre ces passages plus présentables.

Comme le suggère eingousef ci-dessous, une prochaine fois je mettrai mes commentaires et mes questions directement dans le corps du document. Ça sera plus pratique et peut-être plus efficace que la tribune.

Je me sens un peu con de grignoter sur mes heures de sommeil pour ergoter là-dessus. On verra à l'usage, peut-être pour le 4.5.

C'est le chiffrement natif en ext4. Pas de cryptsetup/dm-crypt ou autre module dans le noyau. Ext4 sait faire ça depuis moins d'un an, cf (LWN) Ext4 encryption.

Pour plus d'info, voici le commit de Theodore Ts'o qui explique et corrige le bug. Ce même correctif est aussi dans le noyau 4.3.3.