rogo a écrit 282 commentaires

Ce passage est une simple traduction de l'annonce sur la liste de diffusion du noyau (lkml) :

A number of miscellaneous fixes, the most significant of which are in
the ext4 encryption support. Anyone wishing to use the encryption
feature should backport all of the ext4 crypto patches up to 4.4 to
get fixes to a memory leak and file system corruption bug.

Bien entendu, le mot corruption est à prendre au sens premier de rupture, altération. Autrement dit, sur une partition ext4 chiffrée tournant sur un linux pre-4.4, il y a un risque que des fichiers soient endommagés.

J'ai regardé dans la distribution Debian si ces corrections avaient été rétro-porté dans les noyaux stable/testing, mais je n'ai rien vu dans le changelog.

Edit : dans la dépêche, le lien vers le "merge" ext4 est faux, il pointe vers le "merge" réseau.

Merci. J'ai créé et rédigé cette section "En bref".
Comme freem, j'utilise Linux quotidiennement, mais je ne suis pas développeur C et la quasi-totalité des évolutions du noyau me dépasse ; je me fiche royalement des messages de RC, et je ne comprends qu'une petite partie des notes techniques. C'est pour cela que j'ai voulu ajouter ce petit résumé. À titre personnel, ma lecture de la dépêche n'irait pas plus loin. Ce résumé est construit grâce au travail des autres, notamment l'annonce sur kernelnewbies filtrée et complétée selon mes goûts.

Mon ressenti de rédacteur (une douzaine de paragraphes) est très mitigé. D'un côté, c'est un travail intellectuel très plaisant. Par exemple, pour écrire la section "Gestion de la mémoire", j'ai lu les articles LWN, puis les échanges sur la liste de diffusion du noyau, et, une fois atteint un degré de compréhension suffisant, j'ai écrit ces deux paragraphes, en espérant que quelqu'un de plus compétent relirait. Pour "Sécurité", c'était plus superficiel, simplement à partir de l'annonce sur lkml.

Les aspects négatifs sont tout de même très pesants. On n'a aucune visibilité : quel degré de détail viser ? quels sujets traiter ? qui a fait quoi ? qu'est-ce qui a été relu ? qu'est-ce qui n'est un premier jet temporaire que l'auteur va compléter ? La tribune, une simple pile mono-ligne, est le seul outil de discussion et de planification. Un exemple frustrant : de longs messages de commits ont été copiés dans la dépêche ; ils y sont restés plusieurs semaines, certains contributeurs les ont traduits littéralement, et au final les traductions ont été jetées quand ces sections ont été rédigées. Quel gâchis ! En l'état, je comprends que les contributeurs soient rares.

Je n'ai rien de concret à proposer spontanément, mais j'imagine qu'on pourrait améliorer le système de rédaction de ces dépêches complexes, notamment sur les aspects techniques.

Il y a plein d'autres moteurs possibles pour la création de jeux HTML5. Une simple recherche donne une liste d'une vingtaine de game engines dont 15 sont libres.

Parmi ces alternatives, je connais un peu Phaser. Il a une bonne doc, plusieurs modèles de physique, et plein d'exemples libres que l'on peut essayer et modifier en ligne.

À la marge, il y a aussi les langages de découverte de la programmation, qui permettent de faire des jeux simples. Le plus célèbre est Scratch, mais je préfère son fork Snap. Blocky est aussi intéressant et qui fait le parallèle entre programmation visuelle et code source JS (l'exo de combat de canards est très amusant mais difficile !). Le but de tout ça est d'apprendre à programmer sans taper de code, mais on se sent vite à l'étroit.

Les principales différences que je vois entre Phaser et SuperPowers :

• Phaser a déjà une grosse communauté.
• SuperPowers a choisi le langage TypeScript qu'il compile en JS, alors que Phaser utilise directement JS.
• SuperPowers fournit un environnement complet : serveur node.js, appli compilée, IDE…

Personnellement, l'éditeur intégré à SuperPowers me semble trop limité pour être confortable (afficher la doc de la fonction surlignée ? aller à sa définition ? raccourcis pour changer de fichier ?). J'ai déjà un serveur web et des éditeurs de code installés sur mon PC, donc l'approche de Phaser me convient mieux. Elle me semble plus souple, et le moteur plus riche. Bien sûr, d'autres auront des opinions différentes, et mon expérience avec ces 2 joujous est trop limitée pour que mes convictions soient solides.

Par contre, d'un point de vue commercial, c'est un peu moins vendeur que d'annoncer qu'on a la dernière version de docker et qu'on a des conteneurs en dernière version pour faire fonctionner les dernières applications à la mode.

C'est vrai sur le plan commercial, mais moins net sur le plan technique, puiqu'on peut utiliser des nspawn+machinectl au lieu de Docker pour ses conteneurs. Et c'est là qu'intervient la montée de version de systemd : rien qu'avec la version 219, le changelog mentionne 15 modifications qui concernent nspawn. Par exemple, l'option --port pour qu'une application du conteneur soit publiée de façon transparente sur un port de l'hôte.

Sur l'aspect SQL, le mode de stockage des données est plutôt indépendant du problème. Sans être spécialiste en chiffrage, il me semble que le logiciel peut tout simplement stocker une signature de l'état de certaines données à un instant précis, ce qui permettra de détecter toute modification illégale. La signature peut faire intervenir une autorité tierce, pour éviter qu'on ne la modifie à sa guise.

Sur la certification des mises à jour, le texte semble suffisamment flou pour que cela soit tranché par la jurisprudence. À supposer que la justice française soit un jour saisie de la chose, il est probable que le juge raisonnera en bon père de famille. Ah, non, cette expression surannée a disparu du code civil l'année dernière.

Application écrite en 2004 sous RedHat 4 (de mémoire PHP 4.3, en tout cas PHP 5 n'existait pas encore),

Si en 2004 php5 existait.

La version 5.0.0 de PHP est sortie le 13 juillet 2004. Donc en février 2004, au début des développements, PHP5 n'avait pas d'existence officielle. Et les développeurs n'étaient pas assez "élitistes" pour savoir qu'à l'automne un PHP5 arriverait dans leur distribution avec plein d'incompatibilités.

Avant de contre-dire quelqu'un, c'est mieux de vérifier qu'on n'écrit pas une ânerie.

Application écrite en 2004 sous RedHat 4 (de mémoire PHP 4.3, en tout cas PHP 5 n'existait pas encore), à migrer sous RHEL7 (sortie en 2014, PHP 5.4). Ça fait 10 ans d'écart.

D'abord, je suis un peu surpris de cette véhémence un peu hors-sujet. Je justifiais le choix de compatibilité de PHP, et remarquais que le langage restait sale, rien de plus. Pas de diatribe contre PHP et ses utilisateurs, d'autant plus que je développe avec PHP.

Ensuite, la comparaison des langages de programmation avec les langages naturels me semble plus que douteuse. Quand on parle en français, on se fiche souvent que les mots soient parfois ambigus ou que la grammaire soit approximative. Une erreur de syntaxe n'empêche généralement pas un texte d'être compris. Quand une loi est ambigüe, c'est aux juges d'extrapoler. On attend plus de rigueur d'un langage compilé.

En pratique, il est possible que des codes écrits il y a 10 ans tournent sur du PHP7, mais si tu as déjà fait du portage d'applications PHP anciennes PHP4/PHP5.1 vers du PHP5.4, ça a dû te laisser de très mauvais souvenirs. Ma troisième — et, je l'espère, dernière — expérience là-dessus remonte à la semaine précédente, et c'est toujours aussi pénible. J'ai maudit les inventeurs de register_globals et magic_quotes chaque minute de ma journée.

PHP est bien souvent pratique et efficace, mais on ne peut nier qu'il a des défauts énormes. Une typo dans une variable ou une fonction, et c'est le risque de bug à l'exécution. Et même en typage strict, il faut faire une confiance limitée à la vérification des paramètres d'appel. J'aurais aimé que le code suivant déclenche une erreur, dans l'idéal dès la compilation :

declare(strict_types=1); // PHP 7, typage strict
function f() : int
{
    return 1;
}
echo f(5);  // Il y en a trop, je vous le mets quand même ?

Oui, PHP est un assemblage douteux et un langage incohérent, et ça ne risque pas de changer, c'est le piège de la compatibilité ascendante. S'ils n'avaient pas fait ce choix, cela aurait obligé les bibliothèques PHP à maintenir deux versions de leur code en parallèle, et l'adoption du typage strict n'aurait probablement eu aucun succès dans la communauté PHP. L'exemple de Python3, pas encore majoritaire dix ans après sa conception, leur a fait peur.

Un cas pratique pour être clair. J'ai un code qui utilise SwiftMailer pour les envois de mails. Si cette bibliothèque passait au typage strict et que je mettais à jour les dépendances de mon code, ça ne casserait rien dans la configuration actuelle. Sans ce typage strict à la demande, je risquerais d'avoir des erreurs à l'exécution un peu partout, avec beaucoup de travail pour migrer. Quand on lit des INT via du SQL, on récupère du texte, et il faudrait faire des typecast systématiques.

Ah, parce qu'il y a une version payante ? Ça me paraît être une caractéristique importante de la distribution. C'est un oubli de la dépêche.

J'avais déjà tiqué en lisant que le code source était disponible sur simple demande. Autrement dit, si vous mettez le pied dans l'entre-bâillement, on vous laissera peut-être entrer, mais la porte n'est pas ouverte à tous.

Désolé d'être grincheux, mais j'ai horreur des publi-reportages. Je n'ai rien contre l'auto-promotion, mais si l'information est sciemment biaisée ou incomplète sur des points critiques, ça me fout en rogne.

Le plus gros problème de la doc, c'est la feuille de style de Trac. Le titre en h4 est écrit au moins deux fois plus gros que celui en h3. Donc après avoir lu dans le lien ci-dessus la section "Debian" sur comment installer les dépendances sous Debian et précompiler, quand on est tout engourdi par un dimanche froid et pluvieux, il faut une inspiration miraculeuse pour aller chercher quelques pages plus loin s'il n'y aurait pas d'autres infos utiles. Là, enfin, on apprend comment récupérer les sources (c'est un peu tard), précompiler (itou) et compiler.

Sinon, je soupçonne que mon conflit APT était spécifique à mon hybridation testing/unstable que salit un Nvidia proprio (à défaut d'hibernation avec Nouveau).

Et mea culpa pour la configuration de l'IA !

J'ai compilé et essayé 0AD-19 hier. Au passage, leur doc de compilation est difficile à suivre car il y manque des informations, mais rien d'insurmontable.

J'avais joué il y a de cela quelques itérations, et le gain de performance est flagrant. Auparavant, cela ramait terriblement avec un grand nombre d'unités, et hier c'est resté fluide. C'est probablement la recherche de chemin qui apporte ce confort.

Le revers de la médaille, c'est que cette refonte est encore partielle, comme le signale la dépêche. Il arrive assez souvent qu'une ou deux unités se bloquent, avec des allers-retours sur 1 m. C'est plutôt agaçant, parce que je dois toujours surveiller l'exécution des ordres. Je suis allé regarder le code source (bien documenté, avec des schémas en ASCII-art), mais surtout par curiosité ; je me doutais qu'on ne corrige pas un algo de pathfinding en deux coups de cuillère à pot.

Pour le jeu solo, j'ai été vite découragé. Alors qu'auparavant je finissais par triompher, quitte à m'y reprendre à deux ou trois fois, je me suis fait rétamer sèchement quatre fois de suite. J'espère qu'ils prévoient de configurer l'IA avec des niveaux de difficulté.

Tout ça prouve que ce projet libre est actif, et ça fait chaud au cœur.

Je suis loin d'être convaincu.

D'abord s/foo/bar/g, ça parle à plein de gens, alors que la syntaxe alternative est trop exotique à mon goût. J'aurais compris qu'on abandonne le format vi pour le PCRE (c'est-à-dire "à la Perl"), mais j'ai plus de mal avec encore un nouveau format.

Ensuite, il m'arrive souvent de revenir modifier le pattern au fur et à mesure que j'écris le remplacement, surtout pour les regexs complexes. Sauf erreur, cela ne semble pas prévu avec Kakoune.
Idem pour rappeler un ancien substitute et le relancer, éventuellement après une retouche.

Le débit des serveurs dans l'académie n'y est pour rien, Moodle est vraiment lent. C'est une des rares applications web que je connaisse qui soit bridée par le processeur.

Par exemple, quand on simule 200 utilisateurs sur un scénario d'utilisation de QCM Moodle 2.9, le CPU (VM à 6 cœurs sur serveur Xeon E5-2660 v2) sature à l'authentification et à la soumission finale des QCM, pour un pic à seulement 1,2 Go de RAM utilisée. Les résultats précis dépendent fortement des paramètres de la simulation, mais on a beau jouer sur tous les paramètres applicatifs et systèmes, Moodle est lent, et ça ne s'améliore pas au fil des versions. Grosso modo, chaque CPU-core sert 20 requêtes par secondes pour les pages de complexité moyenne.

Autrement dit, Ubuntu adopterait le fonctionnement de la distribution dont elle dérive, Debian, avec testing et stable.

Comme Yth, j'ai Alsa sans PulseAudio (PC sous Debian testing). Il y a quelques années, il fallait configurer Dmix, mais ce n'est plus nécessaire : avec la config Alsa par défaut, le mixage fonctionne. Debian fait aussi un alsactl store automatique à l'extinction. Pas besoin de configurer quoi que ce soit pour le fonctionnement de base.

Par contre, le son en général reste une galère, surtout sous Linux, PulseAudio ou pas. Si je suspend ou hiberne mon PC alors que la carte son est active, le pilote plante : je dois tuer les processus utilisant la carte son, enlever puis remettre les modules noyau. Et quand je branche un DAC USB, je ne peux plus utiliser Chromium : de temps à autre il produit des bruits douloureux dans le casque du DAC, alors qu'il envoie le son normal dans la carte intégrée. Sur une dizaine de cartes son différentes et plusieurs PC, j'ai toujours eu des problèmes plus ou moins critiques.

Linux n'y est pour rien, mais on peut souvent mesurer l'activité du PC à partir des perturbations du son sur la carte son intégrée.

Merci pour le lien vers les différences entre la version libre et les autres. J'ai pu constater que presque toutes les fonctionnalités annoncées dans la dépêche n'étaient pas disponibles dans l'édition communautaire.

Pour les fonctionnalités promues par la dépêche :

• comptabilité améliorée : propriétaire
• un outil de signature électronique de contrats : propriétaire
• une gestion des abonnements : propriétaire
• un clone open source de slideshare et stackoverflow : pas mentionné (pas d'entrée "slide" dans la comparaison)
• une gestion des événements : libre
• une planification de projets : moitié libre, moitié propriétaire
• gestion de stock basée sur des lecteurs à code à barres : propriétaire

C'est la première fois que je vois ici une dépêche dont le seul but est de faire de la publicité pour un logiciel propriétaire. C'est une méprise ou c'est volontaire ?

Sur fr.libreOffice.org, la distinction entre LO4 stable et LO5 évolution est claire. Par contre, www.libreoffice.org affirme le contraire, et ne recommande aucune autre version que la 5.

LibreOffice Fresh is the stable version with the most recent features.
Users interested in taking advantage of our most innovative features should download and use our fresh version.

Donc "LO 5.0.2" est stable en anglais mais la traduction en français le fait planter ? Ou alors ils supposent que les francophones sont trop maladroits pour changer de version ?

Chuuut une certaine personne va t'entendre et va intégrer ça dans systemd…

L'automount de systemd fonctionne déjà très bien avec FUSE.

% tail -1 /etc/fstab
xxx@mon.serveur.local:/home/logindistant /home/loginlocal/mnt/monserveur fuse.sshfs noauto,x-systemd.automount,_netdev,user,idmap=user,transform_symlinks,identityfile=/home/loginlocal/.ssh/id_rsa,uid=1000,gid=1000,allow_other,reconnect 0 0


La dépêche s'interrompt abruptement sur le constat qu'Ogre3D 2.0 n'est pas adapté au projet OpenMW.

J'aurais apprécié que l'on signale que cette dépêche était une traduction partielle d'une annonce officielle. Pour les flemmards ou non anglophones, voici un résumé succinct de la suite :

• Toutes les fonctionnalités souhaitées par OpenMW sont dans OpenSceneGraph, ou dans des plugins. Ils ont même vérifié dans le code que les implémentations convenaient.
• OpenSceneGraph leur semble très performant.
• Avec Ogre3D, les utilisateurs pouvaient choisir entre un moteur OpenGL ou Direct3D, alors qu'OSG n'utilise que OpenGL. Mais les développeurs pensent que les performances seront équivalentes, et qu'ils éviteront ainsi certains des bugs actuels.
• La partie graphique représente 8% du code, bien cloisonnée, donc la migration est plutôt simple.
• OpenSceneGraph est peu utilisé dans le monde du jeu, sans doute parce qu'il vient du domaine de la simulation physique, mais il a suffisamment évolué pour concurrencer Ogre3D sur ses terres.

Une autre remarque sur la dépêche : « le passage vers OpenSceneGraph est en projet » est trompeur. J'ai cru qu'il était envisagé pour un futur proche, alors que c'est en cours de réalisation.

Je ne résiste pas à la tentation, au risque de passer pour un pédant maniaque…

Notamment sur les points-virgule et les points d'exclamation, n'est-ce pas ?
Notamment sur les points-virgule et les points d'exclamation, n'est-ce pas ?

Pourtant, linuxfr cherche visiblement à maintenir un bon niveau de typographie. La ligne citée a été corrigée grâce au bloc Caractères spéciaux à copier-coller, placé sous la zone de saisie.

À condition d'accepter que le graphe ne soit pas équivalent aux données brutes, je ne vois pas pourquoi ce serait impossible de tracer un graphique de qualité. Il suffit d'accepter de perdre de l'information pour gagner en clarté.

Par exemple, extraire les X affiliations ayant le plus de commits, puis grouper les autres en Y catégories (critère : moins de N commits par mois en moyenne), et tracer les X+Y courbes induites, avec une légende mentionnant toutes les affiliations dans chaque catégorie.

On peut même imaginer que le logiciel propose par défaut des valeurs de X et Y optimales selon des contraintes visuelles (X + Y < 8 ?) et de représentativité (maximiser la séparation entre les ensembles dans X et Y ?).

Je suis plutôt d'accord pour dire que le projet n'est pas clair en page d'accueil, au moins pour une page « grand public ». Sans bien comprendre le but du logiciel, il m'a tout de même semblé qu'il était destiné à ceux qui construisent une offre de transport, donc plus les municipalités que les péquins de mon genre. Si c'est bien ça, ils pourraient l'écrire clairement.

Par contre, leur passage technique me semble plus approprié que ce que tu proposes.

Au passage, «déployé en mode Saas» ça veut pas dire «en tant que Saas»? La première formule, bien qu'utilisée sur le site de Chouette, me semble incorrecte. Et surtout, c'est du marketing bullshit pour dire «c'est un service web».

Non. L'usage moderne est qu'un service web est une interface web prévue pour un usage automatisé, par exemple — attention, jargon abondant — une API REST+JSON ou SOAP que l'on peut utiliser dans des scripts externes, parfois à la volée depuis une autre page web (p. e. cross-domain XHR en JS pour afficher une carte Google dans un site quelconque).

« Déployé en mode Saas » veut dire qu'il existe une offre commerciale où l'on paye un prix d'utilisation sans gérer l'hébergement. J'aurais plutôt employé « disponible » que « déployé » mais je ne vois pas comment éviter l'acronyme sans une longue périphrase.

Je suis d'accord. Comme IDE, contrairement à ce que qu'affirme la dépêche, Atom est très limité et ne mérite guère ce titre. J'avais aussi tiqué sur l'allégation tout subjective qu'il « propose une auto-complétion relativement bien faite. »

À mon sens, un vrai IDE (il n'y a pas de définition officielle) est formé d'un éditeur de code, d'une intégration des outils annexes (compilation, déboggeur, tests automatiques, etc), et de complétions et navigations intelligentes (et affichage ciblé de documentation). Pour un langage objet, si je complète la propriété d'une variable, l'IDE doit utiliser sa classe pour me faire une proposition adéquate, et afficher aisément la doc associée à cette propriété. Eclipse et Netbeans sont des IDE libres qui peuvent très bien faire ça, non seulement pour du Java, mais même pour des langages faiblement typés comme PHP.

Malheureusement, les remèdes à base de ctags sont des pis-allers très limités. La complétion est "stupide". Naviguer vers la définition d'une méthode est souvent pénible, puisque chaque méthode homonyme (par exemple surchargée) est listée comme source possible. Et bien sûr, on n'a ni complétion ni documentation pour les fonctions du langage, sans parler des problèmes de désynchronisation de l'indexation.

Et non, Emacs ne sait pas naviguer intelligemment dans le code. En dehors d'Exuberant ctags, il y a CEDET (parser syntaxique en lisp) mais le projet est moribond et à peine utilisable, même si on se limite à du C. Le seul langage de programmation pour lequel j'ai vu une navigation et une complétion au point dans Vim/Emacs, c'est Haskell, grâce au fonctionnement client-serveur de Ghcmod qui fournit à la volée les informations à l'éditeur de code.

Pour ma part, j'avais vu ce même exposé sur le design web au précédentes RMLL, et j'étais franchement sceptique. D'ailleurs la moitié des essais en direct sur le public avaient été des échecs. De mémoire, il montrait rapidement une page, puis demandait à main levée ce qu'on avait vu, et ça ne correspondait pas toujours à ce qu'il attendait. Par exemple, son test avec échoué pour le sens de lecture gauche-droite qui ferait qu'on balaye l'écran sur toute la largeur jusqu'au bandeau vertical en bord de page : en pratique, j'ai l'impression que le cerveau s'adapte, et quand la page donne une impression de colonnes, l'œil reconnaît un bloc et ne va pas naturellement regarder à droite.

En 2014, le message principal de cette conf' était « toujours faire simple, comme OSX » et cela me donnait plutôt des boutons. Outre que OSX est parfois plus clinquant que simple, j'y vois un oubli — voire un mépris — des utilisateurs de l'application. Pour des applications métiers, les utilisateurs me réclament des pages complexes, et savent s'en servir. Dans d'autres cas, une approche simple peut suffire à condition que des fonctionnalités avancées soit accessibles par ailleurs. Tout est affaire d'adaptation au public visé et de compromis s'il est hétérogène. Au fond, ce message simpliste me semble aussi con que les bonnes intentions du principe de précaution de notre constitution ou que le sempiternel « tout faire pour sauver des vies ! » Alors pourquoi ne limite-t-on pas la vitesse sur route à 30 km/h partout ?