Obsidian a écrit 5299 commentaires

Mais l'envie de jouer avec des pilotes est malgré tout assez forte :p

En fait, sans surprise, je me reconnais beaucoup de mon parcours de développeur dans tes propos, et effectivement, avoir un bon prétexte pour étudier une certaine partie d'une technologie, est généralement le meilleur moyen de s'y mettre, tant au niveau de la motivation que du support de travail.

Quant à la maintenance, le code à déjà au moins 2 ans, mais cumule à la fois les défauts de jeunesse et une dette technique impressionnante.

Pourtant, deux ans, ce n'est pas grand chose. :)

Faire du vrai nettoyage, voire du refactoring, et même in fine un plan de transition douce d'une techno à l'autre sans interruption de service sont des projets extrêmement intéressants en eux-mêmes, surtout avec des outils comme Git (une fois qu'on le maîtrise bien). À condition d'arriver à le faire admettre, comme on en parlait ailleurs. C'est toujours pénible quand on a un chef qui nous dit qu'on a pas le temps de tout ré-écrire quand on est face à une bouse infâme et qui donne ensuite l'ordre exact inverse une fois qu'on a fini d'appréhender la chose.

Enfin, on m'a un peu expliquer les antécédents donc je peux comprendre, mais je n'ai pas trop envie de travailler avec un code aussi inutilement complexe, sachant qu'en plus je vais être le seul à intervenir dessus, théoriquement.

Que tu le nettoies ou que tu le refasses entièrement, profites-en pour le documenter. C'est une bonne occasion de le faire parce que tu ne seras pas poussé aux fesses pour sortir en temps et en heure un produit qui n'existe pas encore. Et tant qu'à faire, essaie de faire quelque chose qui soit auto-généré, donc soit du Doxygen, soit une page de référence interactive à la manière de celle d'Apache.

Je le dis d'expérience parce que pour avoir travaillé sur un gros projet interne à une compagnie, il m'a fallu beaucoup de temps pour m'approprier la chose et une fois cela fait, je n'avais plus le temps de documenter mes propres contributions. Pourtant, le leader initial du projet a eu le bon goût (parce qu'on lui a demandé) d'écrire un gros document dans un traitement de texte (écrit comme un livre, donc) pour présenter la chose. C'était bien, mais c'était assez rébarbatif à lire, c'était un cours presque déjà obsolète étant donné la rapidité des cycles de développement, et surtout : ce n'était de fait pas un « manuel », quelque chose qu'on pourrait directement ouvrir à la bonne page quand on travaille sur un point particulier du projet.

Le QWERTY c'était une bonne idée mais la prochaine fois, vérifie quand même que :

– CAPS LOCK n'est pas enfoncée ;
– NUM LOCK, elle, l'est bien (si tu as l'habitude d'utiliser le pavé numérique).

9 fois sur 10, c'est à cause de ça. :)

Effectivement.

Bon, comme on l'a dit, on développe un pilote pour un produit dès lors que ce produit réalise à sa manière une tâche qui est déjà connue et identifiée dans ses grandes lignes par l'utilisateur et/ou le système d'exploitation. Par exemple, si l'une de tes cartes était une imprimante, ça vaudrait le coup de l'associer à l'existant pour pouvoir automatiquement profiter des facilités de composition et de mise en page.

Accessoirement, toutes les fonctionnalités sont dans un seul binaire, très difficile à maintenir, raison pour laquelle je me suis dit que déplacer le code lié au hard dans des pilotes serait une piste intéressante, pour débloater un peu le bouzin (qui n'est, bien sûr, absolument pas documenté).

Ça reste une bonne idée en soi. C'est juste que ces modules ne seraient pas forcément des pilotes.

Tu peux déjà faire un distingo entre le côté matériel, de bas niveau, et le haut de la pile, c'est-à-dire son exploitation par l'utilisateur. Comment fonctionne globalement cette application à l'écran ? Est-ce qu'il y a juste un menu du style « 1. … 2. … 3. … 4. … 5. … » qui se contente de basculer vers une application distincte à chaque fois, ou est-ce que l'on a, par exemple, un tableau de bord qui serait toujours présent ?

Tu peux aussi t'inspirer d'OBD2 (le protocole de la prise diagnostic des voitures) qui, d'un côté, spécifie le protocole lui-même et, de l'autre, une quantité impressionnante de codes produits et des réponses qu'ils peuvent envoyer, sachant que chaque véhicule n'implémente qu'un petit sous-ensemble de cette liste (correspondant aux équipements réellement embarqués dans le véhicule). Et ensuite, tu regardes si, à chaque fois, tu peux inscrire une carte donnée dans ce cadre.

M'enfin cela ne reste que des pistes de réflexion. Il n'y a rien de pire qu'un standard écrit à l'arrache au départ et qu'il faut ensuite maintenir par compatibilité pendant des décennies (sans exagérer).

les diverses cartes à piloter me semblent avoir une interface trop hétéroclite du coup.

Là, par contre, ça peut être intéressant de développer une couche d'abstraction au-dessus de tout ça.

Normalement, le C doit reproduire fidèlement ce qui se trouve entre deux guillemets " " dans ton programme. Si ça ne fonctionne pas, c'est que soit tu utilises un compilateur VRAIMENT trop vieux, soit (ce qui est beaucoup plus probable) tu utilises un éditeur de texte qui ne travaille pas en UTF-8 par défaut, voire qui choisit de ne pas le faire pour le type de fichier que tu édites (ici un *.c) parce qu'il est configuré pour utiliser un autre charset par défaut pour ce type de listing.

Du coup, la séquence doit bien être encodée dans ton programme, mais pas en UTF-8, si bien que lorsque ton application la restitue dans un terminal qui, lui, en attend, ça ne donne plus rien.

Avec quoi développes-tu ?

En fait, l'avantage, c'est 99,9% de la chose passeraient par une simple CSS. Nul besoin de scripts ou d'extensions particulières. Donc aucun ralentissement. Et si l'on veut quand même des animations flashy, CSS3 permet déjà d'en faire énormément avec transition et transform.

Ce qui est bien, c'est que sur DLFP, les utilisateurs sont traditionnellement incités à le faire et il existe des facilités pour mettre facilement en place ses créations avec le lien changer de style, à gauche dans la boîte principale.

Ça se fait avec vBulletin aussi. Un commentaire rapidement modifié ne laisse aucune trace (je ne saurais dire si cela tient compte du fait qu'il y ait ou non des réponses), sinon la date de dernière modification est ajoutée, et cliquer dessus donne accès à l'historique et au différentiel des changements (à la Wikipédia).

Les journaux, ici, sont surtout des « journaux de bord » ou des « journaux intimes (sauf qu'ils ne sont pas intimes) » et se traduisent en anglais par « log », soit en fait « blog » puisqu'ils sont sur le web.

Les journaux sont donc en fait les blogs personnels des membres, sauf que les derniers billets sont référencés par un lien qui se trouve directement dans la barre de haut de page, et cela marche parce que le public de linuxfr.org est en grande partie composé d'habitués de longue date.

De la même façon, les dépêches seraient des « news », mais ici, on est bien sur linux fr.org ;)

Les principales différences sont que d'une part, tout le monde peut participer à la rédaction d'une dépêche, qui généralement rédigée à plusieurs dans l'espace de rédaction alors qu'un blog est privé par nature, et que d'autre part, un journal soumis est immédiatement publié (comme un commentaire), alors qu'une dépêche est soumise à approbation finale de la modération. De fait, les dépêches sont en fait publiées en page d'accueil au nom du site (même si elles sont quand même créditées à leur auteur), alors que les billets de blog, d'un point de vue moral, n'engagent que leur auteur.

Évidemment, d'un point de vue légal, les unes et les autres doivent être modérés de la même façon et, de toutes façons, on rend toujours crédit à l'auteur d'un papier, quel qu'il soit. Mais c'est comparable aux articles d'un journal papier écrits par les membres de sa rédaction, par rapport aux petites annonces qui sont publiées dans ses pages.

Enfin, dans cet esprit, une dépêche se soit d'avoir un intérêt pour tout le lectorat du site, alors qu'un billet de blog journal, lui, peut parler de tout ce qui intéresse son auteur, tant que cela ne devient pas du spam caractérisé et qu'il n'y a pas flood.

Comme il est très difficile de produire en continu des dépêches valides sur l'actualité sur un site communautaire et sans avoir de chroniqueur attitré, alors les journaux sont ici mis en évidence car on a la chance qu'ils soient de bonne qualité par rapport à certains autres sites (et ce, parce que les gens ont l'habitude de les utiliser de longue date). Un billet de blog particulièrement intéressant et bien écrit peut ensuite, éventuellement, être promue en dépêche.

J'ajoute également, comme dit plus haut (et parce que mon commentaire qui a HUIT minutes ne peut plus être édité) que j'ai écrit un site web entier en PHP (+ PostGreSQL) et implémentant un forum organisé en arbre (comme celui de DLFP) avec possibilité d'édition et messages privés.

Ce n'est pas un exploit en soi, mais ça répond à ta question, dans le sens où je l'ai déjà écrit. C'est juste que ce n'est pas en Ruby. :)

J'ai oublié de dire, pour ceux que cela intéresse, qu'on peut aussi soit mettre en ligne soit carrément uploader ce bout de CSS en bas de cette page : https://linuxfr.org/stylesheet/modifier

Il suffit de copier-coller le bloc présenté et de le faire précéder de la déclaration « @import url("//linuxfr.org/assets/application.css"); » présentée sur ladite page.

Mais après si toi tu tiens aux MPs et tu n'as absolument pas envie de montrer une adresse email que d'autres personnes risqueraient de connaître déjà, n'hésite pas à ouvrir un ticket de suivi et/ou à envoyer un patch.

Je fréquente linuxfr.org depuis 1999. J'ai déjà ouvert quelques tickets qui ont fini par être implémentés, dont le [^], évoqué dans un autre commentaire, et qui est en place depuis Templeet.

J'ai contribué en postant une ou deux dépêches, j'ai fait un certain nombre de traductions dans les dépêches noyau, et j'avais proposé les CSS Nightgrey et Springtime en leur temps, toujours sous Templeet (la dernière m'a demandé environ 80 heures de travail, à l'époque. Les CSS éponymes actuelles ne sont pas les mêmes et ont été écrites par d'autres personnes).

Pour le patch MP, tu as tout-à-fait raison en soi et la seule raison pour laquelle ce n'est pas encore proposé, c'est que je ne connais RIEN au Ruby. Il y a des moments où on ne peut plus courir tous les lièvres à la fois. Je suis principalement codeur C, et j'ai pourtant déjà fait pas mal de web.

Par contre, et c'est une vraie question, puisque tu utilises cet argument pour conclure ce fil, peux-tu nous indiquer si tu as déjà toi-même contribué au site (autrement que par les commentaires, ce qui est déjà beaucoup) et si oui, dans quelle mesure ?

C'est une solution qui ajoute de la complexité : je n'ai pas envie d'être obligé de vérifier l'historique des messages avant d'y répondre, c'est ingérable.

À l'usage, pour utiliser cela sur les autres sites aussi, je confirme que c'est très utile. La variable d'ajustement pourrait aussi être le délai de grâce. Sur certains sites, ce délai est de trois jours. C'est très pratique pour relire ses commentaires à tête reposée et sous un autre angle. Je pense que ce n'est qu'après 24 heures de délai au moins (et une bonne nuit de sommeil) qu'on peut vraiment reconsidérer ses propos avec l'œil d'un « lecteur » et non d'un « relecteur ».

Quel pourcentage de messages ont "besoin" d'être édités ? A comparer avec la complexité engendrée.

Paradoxalement, c'est justement le fait que ce pourcentage soit faible qui va rendre la chose gérable (et d'un autre côté, si tout le monde sollicitait en permanence les modérateurs pour modifier tous les messages du site, alors ça justifierait aussi la mise en place de cette facilité).

Personnellement, j'ai aussi implémenté cette fonction dans le micro site web que j'ai fait pour l'association de mon quartier (avec les messages privés dont je parle dans un autre commentaire). Je fais cela « à la Git », c'est-à-dire que je remplace entièrement un commentaire par un autre même si la modification est minime, ce qui veut dire qu'en ce sens, l'opération n'est pas différente de poster un nouveau commentaire. Et comme mon éditeur est naturellement fait pour faire une prévisualisation (qui elle, n'est pas remise en cause), alors je n'ai besoin de pratiquement aucun code supplémentaire pour reprendre un commentaire existant.

Dans un premier lieu, seule la date de dernière édition est discrètement signalée dans une note en bas du commentaire, et le fait que l'opération soit courante mais pas fréquente fait que cela attire automatiquement l'œil du lecteur quand c'est le cas. Ensuite, les anciens commentaires sont toujours dans la base. Ils sont juste déréférencés parce que le dernier en date remplace toujours le précédent. Donc, au point de vue code, ça ne pose aucun problème.

Ensuite, il me suffit d'une simple table à deux colonnes pour faire un chaînage parent→enfant pour remonter l'historique des modifications. Ça resterait déjà tout-à-fait exploitable si la totalité des commentaires des 15 dernières années avaient un CV long comme le bras (cas des pages Wikipédia, par exemple), mais sur un forum des discussions. Ça va effectivement concerner peut-être 3 à 5 pourcent des commentaires, dont la majorité n'auront qu'une seule modification.

Donc en résumé — POUR l'AVOIR FAIT — je confirme que c'est relativement facile. :)

Un argument que j'aime bien : ne pas avoir de possibilité d'édition incite à réfléchir correctement. Je trouve que ça donne des discussions qui sont de meilleur niveau.

Mouais mais non. Ça, ça n'est vrai que jusqu'à un certain niveau. Ensuite, au bout d'un moment, ça fatigue l'utilisateur, surtout quand il s'agit d'une régression. Prévenir les gens pour qu'ils ne fassent pas de faux pas, c'est une bonne chose, s'arranger pour que, techniquement, ils ne puissent pas en faire, c'est encore mieux.

Oui mais quand on soumet une CSS, on peut en fait ajouter le fichier de la fonte elle-même aux ressources, au même titre que les images associées. On peut donc, a priori, utiliser n'importe quelle fonte, même si elle très exotique. En principe, elle n'est chargée qu'une seule fois par le navigateur. Si, en plus, elle est déjà sur la distrib', c'est tout bénéf' pour le lecteur.

C'est vrai qu'il y a beaucoup de choses sympa dans les Google Fonts et que ça permet de décorer un peu le web. Celle-ci est belle, en effet, et je crois que je vais la garder sous le coude. Cela dit, elle est assez proche (au moins sur un rendu papier) de Libération, qui est déjà largement répandue sur les distribs. J'ai aussi un faible pour Linux Libertine, que j'avais impliquée dans Springtime sous Templeet, juste avant le passage à Ruby.

C'est noté. Merci pour les indications !

(Et on n'a pas besoin de révéler une "adresse personnelle", on donne l'adresse qu'on veut. Je peux me créer une boîte mail 'gasche-linuxfr@…' chez n'importe quel fournisseur email et l'utiliser.

C'est exactement cela qui est rédhibitoire pour moi. Je gère déjà sept adresses e-mail un peu partout et même avec un client dédié, aller créer une adresse PAR forum pour bénéficier des MP, ce n'est pas acceptable. Surtout à la volée !

Je ne comprends pas que tout le monde trouve normal de s'exprimer publiquement mais à une personne donnée dans un fil de discussion (via les réponses) et de ne pas pouvoir faire un aparté quand on a une information confidentielle à transmettre.

Surtout que ce n'est pas du tout mutuellement exclusif : quand il y a des MP, il y généralement moyen d'être également prévenu par e-mail – si on le souhaite – et il y a un bouton pour les exporter. Même moi qui ait écrit un serveur complètement from scratch (sur du PHP/PostgreSQL) parce que notre hébergement est trop petit pour y coller quoi que ce soit de sérieux, j'ai mis en place cette fonctionnalité. Pour une population de 60 personnes environ.

Ça existe absolument partout et ça fonctionnait très bien ici aussi.

D'ailleurs, puisqu'on en parle, est-ce qu'il y a possibilité de joindre des ressources annexes aux CSS alternatives que l'on soumettrait (images, fontes…) et si oui, dans quel dossier faudrait-il les mettre du côté du code (pour ceux qui passent par les pull requests) et via quelle URL seraient-elle accessibles ensuite ? (nécessaire pour la CSS elle-même).

Je n'ai pas de début de solution, mais je trouve ça vraiment "chiant"…

Et pourtant, il y a une : c'est le bouton [^] qu'il y a dans le titre de chaque commentaire et qui sert à remonter au commentaire parent (tu peux ensuite utiliser le bouton Back pour revenir à ce que tu lisais). C'est d'ailleurs une suggestion faite dans le suivi il doit y avoir presque une dizaine d'années et qui avait déjà été implémentée du temps de Templeet.

Par contre, la CSS mériterait d'être retravaillée parce que la simple barre verticale à gauche du paragraphe cité est un peu faiblarde. Personnellement, et pas plus tard que ce soir, j'ai ajouté ce qui suit dans « ~/.mozilla/firefox//chrome/userContent.css » :

@-moz-document url-prefix(https://linuxfr.org/)
{

div#comments div.content blockquote
{
    background-color:       #d0d0d0;
    border:                 solid 0px transparent;
    border-left:            solid 2px #b0b0b0;
    color:                  #303030;
    font-size:              90%;
    padding:                0.8em !important;
    margin:                 1em 5em 1em 0 !important;
    box-shadow:             0.5em 0.5em 0.5em #a0a0a0;
}

div#comments div.content blockquote p:first-child
{
    margin-top:     0 !important;
    padding-top:    0 !important;
}

div#comments div.content code
{
    color:              #e0e0e0;
    background-color:   black;
    font-family:        "Monospace Regular","monospace","fixed";
    font-size:          100% !important;
}

div#comments div.content blockquote p:last-child
{
    margin-bottom:  0 !important;
    padding-bottom: 0 !important;
}

}

Ça met un fond gris au bloc cité, ça lui ajoute une ombre et ça réduit légèrement la taille relative de la fonte. Rien que ça, ça facilite beaucoup la lecture des dialogues.

La question ne se pose pas vraiment en ces termes. Quand on a voulu se débarrasser de templeet, j'ai pris la décision de partir sur un développement spécifique plutôt que des logiciels libres existants en 2008 et je pense que c'était le bon choix. J'avais également l'espoir à l'époque que cette base de code spécifique puisse être utilisée par d'autres sites, mais ça ne s'est pas concrétisé.

C'est-à-dire que c'était également les motivations de Templeet, lorsque DLFP a abandonné DaCode. Et Templeet était lui aussi un logiciel libre (et même documenté !), pour les mêmes raisons.

De l'autre côté, vouloir migrer même vers des outils existants demande un travail très conséquent pour juste arriver au même niveau. Je ne pense pas que l'on ait les ressources pour réussir un tel chantier. Et si on les avait, ça serait sûrement plus efficace de faire évoluer progressivement l'existant que de se lancer dans un gros chantier qui va forcément prendre du temps et dont l'issue est plus incertaine.

Ça c'est vrai aussi, c'est un plan de migration, et c'est intéressant entre autre pour éviter les régressions […] à condition d'arriver à le faire admettre aux décideurs et aux développeurs de l'équipe au moment où c'est nécessaire.

Mais bon. C'est un peu comme refaire sa maison. C'est très excitant au départ, arrivé à mi-chantier, on se demande pourquoi on s'est embarqué là-dedans et à la fin, il est presque temps de recommencer. En général, on le fait une fois, rarement une deuxième.

Du coup, les années passant, il est probable que si tu transmets à ton tour, un jour, le bébé à une autre équipe, cela marque le début d'un nouveau cycle et que celle-ci en profite pour réécrire une nouvelle fois DLFP en exploitant les technologies du moment.

Ce serait donc un « minimum », si l'on peut dire, surtout dans la mesure où cela existait ici avant et que ça existe également partout ailleurs.

Et à partir du moment où on a un formulaire permettant de relayer instantanément un message vers l'adresse e-mail (conservée confidentielle) d'un membre, et que d'autre part, on a tout un système de conservation des messages publics (les commentaires des discussions), alors il ne manque vraiment pas grand chose pour implémenter un vrai système de messages privés.

Surtout que les MP basés sur l'e-mail déclarée d'un membre implique que l'expéditeur ait lui aussi une adresse valide qui sera automatiquement utilisée comme adresse expéditrice, ou à tout le moins en tant que Reply-To.

Et justement, comme cela implique d'utiliser le nom de domaine de l'hébergeur de l'adresse e-mail, cela nécessite en fait d'envoyer le premier mail en tant que noreply@linuxfr.org ou quelque chose d'assimilé. Il est largement plus sympa d'avoir des MP pour communiquer des infos confidentielles entre membres d'un même site sans avoir à révéler son adresse personnelle.

Salut,

Voila, j'aimerai vos avis du coup, quand et pourquoi implementer des pilotes,

Concevoir puis implémenter des pilotes de périphériques est en soi une chose assez stimulante. C'est aussi une bonne occasion de plonger dans le code de bas niveau, voire carrément la programmation noyau et, en plus, les objectifs à atteindre sont relativement bien délimités : il s'agit en gros d'honorer une API (généralement déjà existante) dans sa totalité, pour permettre ensuite à des applications non spécifiquement écrites pour de pouvoir exploiter ton matériel à travers lesdits pilotes.

La première question est donc : qu'est-ce que tu pilotes, fût-ce via une liaison RS/232 ou 485 ? Il y des chances pour que ce soit en atelier, donc peut-être des machines outils… Et là encore, ça n'a d'intérêt que si ton pilote permet d'adapter l'utilisation du matériel à quelque chose de générique, ou à la limite à un niveau d'utilisation simplifié. Ça peut être intéressant également si tu as une grande gamme de matériels différents mais censés être, in fine, exploités de la même façon par l'utilisateur.

Par contre, si tu exploites du matériel spécifique dans un seul cas d'utilisation avec un logiciel dédié exclusivement, ça ne sert à rien d'intercaler un pilote entre les deux.

et user-space ou kernel-space?

À priori user space quand même, surtout si c'est au travers d'une liaison RS/232 qui, elle, est déjà bien prise en charge par le kernel. Non seulement la programmation peut être un cauchemar à déboguer (si ton pilote plante, c'est tout le système qui s'écrase. Ça ne se finira pas en simple segfault…) mais en plus, il faudra faire des appels internes pour aller revendiquer temporairement l'interface qui est faite pour être appelée via des appels système utilisateur normaux. Ça compliquerait un développement qui est censé être facilité quand il fait en user space.

En fait on peut modifier ses messages, mais le délai de grâce est un peu être un peu trop court :

Autre chose qui existait jadis et qu'il serait agréable de récupérer : les messages privés.

C'est-à-dire qu'ils partagent beaucoup de technologies sous la forme de bibliothèques communes, et le dépôt des profils utilisateurs est plus ou moins organisé de la même façon dans les deux cas.

Jette-y quand même un œil pour voir si tu vois des fichiers « *.corrupt ». Tu devrais déjà y récupérer pas mal d'informations sans trop de difficulté.

D'une manière générale, j'ai connu ces deux dernières années un certain nombre de bugs avec Firefox dont qui ont toujours été très difficiles à isoler, jusqu'à ce que je m'aperçoive qu'ils étaient parfois carrément structurels. Il semble que quand un profil utilisateur commence à être vraiment vieux et que l'on fasse un gros usage des ressources, par exemple quand on a beaucoup de bookmarks, ce profil finisse par se corrompre. Voici les principaux bugs que j'ai personnellement observés :

• Corruption des bases SQLite : Firefox a décidé de s'appuyer dessus depuis un moment et c'est une très bonne idée en soi, sauf qu'à intervalles aléatoires mais globalement réguliers quand même, tous mes bookmarks disparaissaient ! Un tour dans ~/.mozilla/firefox/ me montre que j'obtenais alors trois fichiers :

• places.sqlite

• places.sqlite.corrupt

• places.sqlite.bak

Donc, autrement dit, la base avait crashé à l'ouverture et sqlite a eu le bon goût de la copier quand même dans « corrupt » avant d'en reconstruire une autre. Le fait de fermer Firefox, de supprimer le *.bak et le fichier normal, de renommer la base « corrupt » vers la base originale et de relancer le navigateur faisait rentrer les choses dans l'ordre, si bien que le crash à l'ouverture était totalement aléatoire. J'ai même fini par m'écrire un script « mozbook » exprès pour archiver proprement chaque base plantée et faire l'opération ci-dessus à chaque fois.

J'ai une fois essayé d'exporter puis réimporter mes bookmarks en soupçonnant une corruption de données quelque part, mais le problème était réapparu quelque temps plus tard. Ça a fini par s'arranger au bout de quelques versions, mais je mets ça également sur le fait d'une mise à jour de SQLite proprement dit.

• Disparition des cookies : beaucoup plus rare, mais exactement le même problème.

Plus récemment : impossibilité de saisir des accents circonflexes ainsi qu'un ou deux autres caractères spéciaux. Cela n'affectait que Firefox. Une recherche sur le web m'avait renvoyé vers quelques billets épars, qui signalaient la même chose, mais qui étaient parfois vieux de six ans. Ça semble être un bug latent que personne n'a réussi à identifier : le fait de détruire mon profil, d'en reconstruire un autre et d'y réimporter mes données personnelles (dont mes bookmarks) a fait disparaître le problème.

C'est autre chose que la Free Software Song !