raphj a écrit 1448 commentaires

il y a gens, avec lequel les adjectifs sont féminins si avant, masculins si après.

Des gens heureux. De bonnes gens.

Même si ça passe par imposer faute de pouvoir convaincre?

Oui et non. Concernant les citoyen·ne·s, idéalement il faudrait que les gens soient conscients de l'importance de la chose. Déjà pour qu'ils connaissant les bénéfices qu'ils peuvent en tirer, et aussi pour que ces droits ne se perdent pas. En même temps on ne peut pas demander à tout le monde d'être sensible à tous les aspects de tous les domaines. Peut-être qu'avec une présentation des enjeux autour de l'informatique tôt dans l'éducation ça pourrait le faire parce qu'il se trouve que l'informatique c'est assez omniprésent, mais bon. Concernant les boites qui font du logiciel, évidemment si on ne les pousse pas à faire du libre pour les utilisateurs finaux ça ne changera jamais. Mais ma perspective, elle est du point de vue du citoyen, pas de la boite qui produit du logiciel. Je m'intéresse aux droits du premier, pas de cette dernière. Il se trouve que je bosse moi-même pour une boite rentable qui vit du logiciel libre donc j'ai la chance d'être cohérent à ce point (mais je reconnais que c'est en partie de la chance - en partie parce que j'ai essayé fort aussi, faut pas déconner non plus :-P).

Je pense que ça devrait être dans la loi mais ça demande d'autres changements en profondeur. Peut-être déjà des subventions publiques comme celles que le gouvernement allemand attribue actuellement à différents projets libres pour constituer un socle numérique souverain et libre : https://www.dataport.de/about-phoenix/

Et du coup, savoir quel business model va gagner si on ne contraint rien, ça ne m'intéresse pas non plus. La question est : est-ce qu'on veut garantir que les citoyens aient ces libertés ? Si oui, et que c'est imposé par la loi, je suis sûr que des business seront possibles / vont s'adapter. Ça va suivre. Pas sans souffrance évidemment, ce serait une petite révolution.

À noter que la majorité des postes de dev, c'est en fait de la presta pour des boites il me semble, et qu'il n'y a pas de raison que ce genre activité soit touchée : ici les utilisateurs finaux ce sont les boites et elles payent pour obtenir du code dans les conditions qu'elles établissent. Éventuellement on peut "protéger" ces clients pour leurs garantir que le code qu'elle reçoive est libre, mais je ne crois pas que ça change grand chose.

Donc vraiment ça n'affecterait "que" les boites qui souhaitaient "enfermer" leurs utilisateurs pour une raison ou une autre. Et c'est "seulement" une partie du monde informatique.

un droit du citoyen

Je pense que ça devrait l'être justement, tout comme les chargeurs standards, ou comme la réparabilité. Avec les enjeux de vie privée, le code devrait être auditable publiquement, ou du moins l'utilisateur devrait pouvoir faire auditer son code, (faire) vérifier que les binaires correspondent aux sources et (faire) construire les binaires à partir des sources ; en principe ce point demande à la fois plus et moins que le libre (plus, parce que ça demande du reproducible build ou un autre mécanisme garantissant ces choses). Et aussi pouvoir (faire) modifier son logiciel selon ses besoin sans dépendre du fournisseur initial - en bref, d'être maitre·sse de ses outils comme cela l'a été pendant longtemps et comme ça l'est encore pour beaucoup de choses hors du monde de l'informatique.

je m'arrêterai de répondre même si c'est intéressant intellectuellement

Ça roule ! Je comprends.

les insultes "ces merdes", qui est bien dommage car casse un peu l'idée que ça serait objectif

Oui. En même temps j'assume (et je ne suis pas spécialement objectif même si j'essaie d'avancer des arguments rationnels, j'ai des opinions relativement tranchées). Ils vendent du matériel, ils n'auraient rien à perdre à libérer ce code. Sauf s'ils veulent ne pas risquer de se faire poursuivre en justice pour des questions de brevet, mais en fait tout le monde fait ça donc la source du problème c'est que le système des brevets est tout pété. Et je n'ai pas de trop de sympathie pour la protection de l'IP non plus. En tant que civilisation on devrait être capable de coopérer et de ne pas tout voir comme de la compétition. Mais là aussi on vie peut-être dans un monde à réformer de ce point de vue.

Et rappelons que le non libre n'enlève rien à personne, tu es toujours libre de refuser pour toi

Je pense comprendre ton point de vue (le code proprio est un truc qui existe simplement, tu n'es pas obligé d'utiliser si tu ne veux pas l'utiliser). Mais je ne suis pas d'accord avec toi là dessus.

Une personne qui vie dans un pays occidental aujourd'hui est quasi obligée d'utiliser du code non libre, à commencer par ces firmwares non libres. Et sinon, la tonne de JavaScript non libre qui traîne partout. Sinon, elle est exclue de la société au moins à un certain degré. Il y a une pelleté de démarches administratives ou de choses de la vie ou autres qui demandent maintenant d'avoir un ordinateur ou un smartphone, de plus en plus en tout cas. C'est de plus en plus difficile en tout cas d'y échapper. Et même si on peut s'en passer, on ne devrait forcer personne à un tel niveau d'inconfort. De fait, on est un peu forcé à exécuter du code non libre aujourd'hui. Il n'y a pas vraiment le choix. Personne qui n'est pas expert·e aujourd'hui peut éviter du code non libre même par conviction. On peut ne pas être versé·e dans l'informatique et utiliser GNU/Linux au quotidien, mais on ne peut pas éviter le code non libre. Ce choix n'existe pas.

Or, mon opinion est que les libertés garanties par le logiciel libre devraient être des droits fondamentaux (utiliser, étudier, modifier, redistribuer). Aujourd'hui, rien n'oblige les dev à fournir leur programmes à leurs utilisateurs et utilisatrices en libre. Y compris pour les services de l'état. On pourrait dire que les gens qui y tiennent devraient faire l'effort de trouver des solutions, mais pour l'instant ces solutions n'existent pas. Le compromis est quasi inévitable, et dans tous les cas demande énormément d'effort.

Tu as le droit de penser qu'on a pas besoin que ces libertés soient garanties, ou même que ce n'est pas souhaitable. Mais si on pense ça, c'est évident qu'on souhaite que ça aille dans ce sens, et qu'on considère l'obligation d'utiliser des firmwares non libres comme non souhaitable et qu'on veuille (militer pour, travailler pour) s'en débarrasser.

On pourra me demander "et le hardware alors ? Ça ne te dérange pas de l'utiliser quand il n'est pas open" ? Et là ma réponse est que mais oui, j'aimerais qu'on me fournisse les schémas du hardware que j'achète, en fait ! mais là, la situation est encore plus difficile que le logiciel libre, il n'y a plus ou moins aucun choix en open hardware.

De plus, si je peux raisonnablement modifier un logiciel avec du matériel que j'ai chez moi et du temps, je ne peux pas raisonnablement pas le faire pour une puce wifi / bluetooth ou un CPU. Je n'ai pas de salle blanche et tout le reste de l'infrastructure qui me permettrait d'adapter et produire un CPU chez moi. Et on peut y aller par étape. On peut déjà s'occuper du logiciel pour commencer. C'est la partie "facile".

Pour finir, j'aime bien vivre mes opinions pour moi (incarner le changement qu'on veut voir arriver), mais je souhaiterais que mes idéaux soient accessibles au reste du monde. Les solutions collectives, plus qu'individuelles, m'intéressent particulièrement.

Avec plaisir. C'est compliqué, je ne suis pas totalement fixé perso :-)

Dans tous les cas, indépendamment de Debian, je pense qu'il faut continuer à militer / agir contre les firmwares non libres, faire de la pédagogie, etc. En tout cas ne pas oublier le problème.

Je pense que déjà, le message de confirmation de l'installateur Debian permet de se souvenir du problème quand on l'installe…

En fait, c'est un recul et un progrès en même temps je pense. L'installateur contiendra effectivement les firmwares non-free (donc c'est pénible si tu voulais éviter de les télécharger) mais :

1. les firmwares seront désormais dans une section séparée des dépôts non-free-firmware, et plus non-free. Donc, quand tu veux les firmwares non-free mais pas le reste des paquets non-free, c'est gagnant.
2. l'installateur continuera à te demander si tu veux les installer ou non avant quoi que ce soit.

Je sympathise avec ce choix de 2011 de ne pas inclure les firmwares non-free par défaut pour forcer les constructeurs à libérer leurs firmwares (et j'aimais bien cette décision), mais force est de constater que 12 ans plus tard, la situation n'a fait que s'empirer : il y a des firmwares non-libres pour tout, le matériel qui fonctionne avec seulement des firmwares libres est vieillissant (pas de carte wiki AC ou plus récent, ça s'arrête à N), y compris les CPU avec leurs microcodes complètement obscures à mette à jour et il vaut probablement mieux le faire de toute façon. La liberté a régressé malgré Debian. Et donc en pratique, pour installer Debian, soit tu t'embêtais à télécharger l'image non officielle contenant les firmwares non-libre, soit tu t'embêtais à les télécharger et cette "barrière" n'a probablement pas plus convaincu les gens que ça, voire ça a été source de frustration. Si tu as du matériel qui ne fonctionne qu'avec des firmwares libres, tu es déjà convaincu.

De mon côté, ça pourrait m'encourager à plus facilement recommander Debian en ces jours où Ubuntu c'est pas mal chaotique avec Snap et autres trucs. Elle sera plus facile à installer, et elle reste une distribution qui sépare bien les choses, et elle devient aussi à ma connaissance la seule distribution qui permet d'opter pour les firmwares non-libres et pas pour tout l'ensemble complet non-free.

Au pire, il y a toujours PureOS qui est une Debian sans toutes ces merdes.

Du coup, aujourd'hui on a un bon choix pour recommander :

• Debian aux gens qui ont du matériel avec firmwares non libres et qui ne s'en passeront pas (par exemple, ils ne rachèteront pas de matériel équivalent avec firmware libre)
• PureOS ou Debian en refusant l'installation des firmwares non libres aux autres.

openSUSE Tumbleweed permet de tester un KDE à jour et bien intégré. Mais ce n'est pas Debian, et ça peut faire beaucoup de choses nouvelles à tester d'un coup. C'est chercher à avoir un nouveau KDE sur une Debian classique qui m'a mené à openSUSE Tumbleweed, à la base c'est plutôt Debian que je connais mieux. Je me suis dit que quitte à vouloir un KDE récent et à ne pas trouver de solution correcte sous Debian, une rolling release avec quand même des dépôts de bases bien fournis et relativement stable était une solution intuitive au problème. Clairement moins stable que Debian stable, mais c'est surtout parce que Debian stable, c'est Stable ®™.

KDE Neon ce n'était pas la panacée quand je l'avais essayée il y a des années, il y avait notamment des conflits de paquets, mais il y a de grandes chances que ça soit mieux maintenant, et que ça soit le choix tout naturel pour essayer un KDE récent pour quelqu'un venant de Debian. Il faut accepter d'être de retour sur Ubuntu (perso je ne veux plus y toucher, avec leur sale habitude de remplacer les paquets deb qui marchent bien par un snap tout cassé et tout lent), potentiellement pénible quand on est passé à Debian, mais bon, ça peut marcher.

Il est important de noter que, de par le manque de CI/CD permettant de déployer automatiquement une nouvelle version du code, chaque mise en production est, dans ce type d’entreprise, un processus majoritairement manuel avec les risques inhérents que cela implique, à savoir les erreurs humaines.

Je suis d'accord, il faut un peu de CI/CD pour les mises en production, ça permet d'automatiser les erreurs et les accélérer à toute vitesse, au lieu de les introduire manuellement, ce qui est assez épuisant surtout un vendredi.

D'ailleurs, n'oubliez pas de mettre en production manuellement votre système de CI/CD un autre jour que le vendredi.

nextcloud (pour les contacts + agenda)

Oui, avec DAVx⁵.

kdeconnect

Excellent aussi pour plein de choses, d'ailleurs je viens de le recommander à un pote qui m'a demandé d'installer Linux sur un vieil ordi.

(pour qui a la flemme de cliquer)

… et je confirme, ça peut faciliter grandement les choses.

Et scrcpy est assez pratique aussi pour d'autres trucs, notamment pour taper des SMS avec son ordinateur, avec l'interface du téléphone.

Le Nokia 7230.

(j'ai aussi un Pinephone Pro qui ne me sert pas encore de téléphone, mais ça dépanne pour le QR Code qu'il faut occasionnellement faire scanner, et pour lire / écouter des trucs au lit sans gêner personne. J'ai utilisé un PinePhone pendant un an mais il a eu des soucis matériels, probablement à cause d'une énorme pluie qu'il a subi. Le PinePhone Pro n'est pas prêt pour une utilisation téléphone, et puis maintenant je me suis réhabitué au Nokia et surtout à sa robustesse et sa fiabilité sans faille)

un bug sur un lineageos qui l'empeche de recevoir les mms correctement

Décidément, c'était déjà un peu rock 'n' roll pour ça quand je l'utilisais

qksms existe aussi sur lineageos

Oui oui, je n'ai quasiment pas utilisé Android stock (sauf les 2 semaines qu'il fallait attendre sur mon modèle pour déverrouiller le bootloader…), que du LineageOS ou équivalent.

Très bonne vidéo en effet.

Un gros manque (voire une fausse information) quand même sur la question de la consommation énergétique. Si afficher du noir est plus facile pour un écran OLED et consomme moins, c'est faux pour n'importe quel autre écran LCD : l'écran doit compenser le rétro-éclairage et faire plus d'effort pour le cacher que pour afficher du blanc. Donc ça consomme plus pour afficher du noir quand il est allumé !
Et comme les écran OLED son minoritaires pour les écrans d'ordinateur, et loin d'être les seuls pour les téléphones, ça aurait été bien de le mentionner.

D'autant que la production des écrans OLED est très coûteuse environnementalement, parce qu'il y a des taux d'échecs plus grands à la production (en tout cas c'était vrai il y a 3-4 ans, je ne me suis pas renseigné plus que ça sur ce sujet plus récemment)

Je n'ai pas un avis très tranché sur le sujet, mais quand j'utilisais Android, j'utilisais l'application QKSMS sur F-Droid qui était très bien. Sinon l'application par défaut de LineageOS était pas trop mal non plus.

J'ai pas vu / j'ai oublié :-/

Pas de problème :-)

Il y a des exécutables fournis là apparemment : https://kate-editor.org/get-it/

Je crois l'avoir lancé une fois sur un Mac mais je ne suis plus très sûr. Je sais que KDE travaille à faire fonctionner leurs softs sur Mac.

Tiens, cette question me dit quelque chose, je crois qu'elle est sortie il n'y a pas trop trop longtemps ici sur LinuxFr :-)

Kate a tout ça (mais j'ai pas tout testé, notamment les trucs de reformatage / formatage à la saisie, je n'en ai jamais ressentis le besoin au delà de "indenter après une accolade ou des deux-points et cesser à la fermeture du bloc").

Y compris les fonctionnalités IDEesques grâce à sa prise en charge de LSP, mais ce n'est pas parfait, faut mettre un peu les mains dans le cambouis pour faire marcher ça (il faut aller chercher les serveurs LSP des différents langages que tu utilises toi-même et adapter la configuration de Kate en conséquence). Je confirme que ça marche bien pour JavaScript, Java, PHP, C et C++, je ne fais pas trop de Python en ce moment mais je suppose que ça se fait bien aussi.

J'ai utiliser VSCodium un temps mais il n'y a rien à faire, ma mémoire musculaire (bien ancrée depuis 2008…) et la légèreté de Kate me font revenir à cet éditeur que je trouve par ailleurs très plaisant, en plus des questions d'open core et côté fourre-tout d'extensions qui me plaisent moyen. Je l'ouvre à l'occasion pour des besoins spécifiques, mais ce n'est pas arrivé depuis près d'un an.

Finalement je fais vraiment beaucoup de chose depuis le terminal…

Bah c'est pareil pour chatGPT

Mais c'est là où on n'est fondamentalement pas d'accord. Pour moi, les processus impliqués dans l'apprentissage d'un être humain ne sont pas du tout comparables aux algos qu'on appelle "apprentissage" pour une IA. Même terme, mais il ne faut pas s'y méprendre, ce n'est pas du tout la même chose.

Fondamentalement, je me trompe peut-être et tu as peut-être d'accord. Mais force est de constater qu'on est beaucoup à penser comme toi beaucoup à penser comme moi.

Du coup, comment on fait ? Pour moi : j'attends que le système légal apporte une réponse à ce questionnement. Et éventuellement on réfléchit au problème, on fait du lobby pour que les choses bouge dans le sens qu'on veut.

mais auraient-il fait une erreur aussi grossière?

Ils font le pari qu'ils peuvent utiliser les closes de fair use. Leur service légal semble avoir atteint la conclusion que c'est jouable comme ça (au mois risque acceptable). À tort où à raison, encore une fois.

Bon, on doit être plus de 2 à y accéder en même temps et ça a du mal à charger, alors si vous êtes pressé·e, il y a la page du Wiktionaire qui, en prime, ne se contente pas d'abuser des arguments d'autorité du style « tous les spécialistes s’accordent » [Qui ?][Spécialistes dans quel domaine ?][Source ?] sans citer de source, mais qui donne effectivement quelques d'exemples d'utilisation dans la nature qui valident par l'usage le "son" possessif dans cette expression (mais qui n'invalide pas l'interprétation son / sound, pourquoi pas ?)

https://fr.wiktionary.org/wiki/battre_son_plein

(oui, parce que l'avis torché de quelques croûtons de l'académie française pas spécialistes en langue et cooptés, j'y accorde presque autant d'importance qu'à ma chaussette qui pourra elle certainement avoir une utilité, après recyclage)

Oups, pardon, je l'ai encore fait ?

[] <===

Je trouve cet argumentaire généré assez consensuel.

Il "s'est gardé" de générer un argument plus dans la controverse, du style « ChatGPT s'appuie sur un large corpus de texte en ligne dont les auteurs et autrices n'ont pas donné leur accord explicite pour cette utilisation. Sans parler de l'aspect discutable de la démarche d'un point de vue éthique, un flou légal existe autour de l'entraînement de modèles de traitement automatique tels que ChatGPT en s'appuyant sur le fair use, rendant potentiellement les textes générés inexploitables légalement. Cette utilisation n'a pas encore été testée dans des tribunaux et n'est pour l'instant pas clairement autorisée par les lois sur les droits d'auteurs, et est principalement basée sur un pari audacieux. »

Il dit cp /dev/null mais je pense que totof2000 a lancé une commande de la forme

cp fichier /dev/null

Et du coup, ça remplace /dev/null par une copie du fichier donné en premier paramètre de cp. Et du coup /dev/null devient un fichier normal comme les autre, au lieu du fichier périphérique spécial "trou noir" qu'on connait.

Il n'y a pas d'erreur de syntaxe, parce que /dev/null est un nom de fichier tout à fait valide.

J'imagine qu'on pourrait distribuer des patchs de ce code

Souvent, les patchs style diff / git contiennent les morceaux originaux à changer, je me demande à quel point ça empêche ou non de le faire. Ou alors il faudrait un système de patch qui donne les coordonnées précises du code à changer, mais alors là aussi il faut faire attention à ce que le code fourni ne soit pas trop dérivé… Peut-être que si les patchs sont assez petits, ça passe…

Bref, je ne sais pas.

ce que tu dis, c'est comme dire que c'est nul qu'on soit pas encore tous passé à IPv6.

Non, parce que le standard omniprésent, c'est déjà l'UTF-8 (pas comme IP où le standard omniprésent, c'est encore IPv4)…

Mais c'est vrai que c'est con qu'on dépende encore d'IPv6, moi ça me coûte 1€ par mois pour avoir une adresse IPv4 sur mon serveur… :-)

Donc faut arrêter de faire en sorte que son logiciel fonctionne avec IPv4 parce que c'est le passé

Non, mon souhait c'est qu'un truc qui produit du texte le fasse en utf-8 ou utf-32. Celui qui le lit peut continuer à comprendre ISO-machin-truc ou windows-chose-bidule. Mais oui, je crois vraiment que les mécanismes de détection automatique de charset risquent de baisser les motivation de réparer le problème que ça résout à la source. Devrait-on alors arrêter de faire de la détection automatique de charset ? Non, ne ne pense pas non plus.

ou que Wayland est le futur, donc faut arrêtez de faire en sorte que nos logiciels marche avec X11

Bof, j'utilise toujours X11, de moins en moins convaincu par Wayland xD
Mais bon, peut-être que ça va bientôt marcher…

tu auras bien du mal à me convaincre (et "convaincre" uchardet) que c'est un décodage pertinent

Mais je ne devrais avoir personne à convaincre de quoi que ce soit : si je saisis un texte, il devrait ressortir tel quel. Je m'en fiche de savoir que tu penses que le contenu ne soit pas pertinent. Mon argument, c'est que la détection de charset, c'est bien, si on ne peut pas faire autrement (et évidemment que dans le monde imparfait dans lequel on vit, c'est souvent le cas - je m'en servirai volontiers en cas de besoin.)

Ahahah. Je suis pas du tout frustré par la situation

Je parlais des gens qui on fait ftfy.

Par ailleurs je suis assez d'accord avec tout ce que tu dis. Et ce que fait uchardet et les outils similaires, c'est ultra utile dans le contexte du monde pas idéal dans lequel on est. C'est super que des gens comme toi bossent dessus. Évidemment. Faut pas prendre mon message comme une attaque. Si on est dans une situation cassée, ok, on va utiliser ce qu'on peut pour retrouver le contenu original vraisemblable avec des stats et des heuristiques. Mais c'est important de reconnaitre et documenter les limitations, même si on ne peut rien faire de mieux.

Juste que ça devrait être du dernier recours. À chaque fois qu'on en a besoin, c'est qu'il y a un bug quelque part (mauvais passage de l'information du charset utilisé).

Super, merci pour cette dépêche et ce travail remarquable. Tu multiplies les contributions utiles décidément.

J'ai longtemps eu du mal à ne pas avoir l'impression que "chardet" est une erreur de frappe sur "charset", avec le S qui est juste à côté du D en qwerty / azerty. Bref.

Et c’est ainsi que Mozilla a décidé de ré-écrire un nouveau projet en Rust. Dans leur article, ils citent uchardet (sans le nommer autrement qu’un « fork non-Mozilla » avec un lien vers la page d’uchardet)

Ça vaut peut-être le coup de leur signaler. C'est une formulation maladroite et malheureuse, et je ne pense pas que ça soit malicieux.

et le fait qu’il est bien plus complet maintenant qu’il ne l’était à l’époque, mais qu’il manque encore des fonctionnalités. Ils ont donc préféré ré-implémenter du début (une logique qui m’interpelle)

En tout cas je vois un intérêt de travailler en Rust. S'il y a bien une brique logicielle qu'il est intéressant d'avoir en Rust dans un navigateur web, c'est une détection de caractère, avec probablement plein de fichiers d'entrée tout pétés avec des failles de sécurités plus facilement évitables dans ce langage.

Notons qu’idéalement, vous devriez même retirer tout texte structurel qui pourrait interférer avec la détection (j’en reparlerai dans la section sur les principes de détection. Par exemple pour retirer les tags HTML sur une seule ligne:

$ curl https://www-archive.mozilla.org/projects/intl/universalcharsetdetection | sed 's/<[^>]*>//g' | uchardet

(il manque une parenthèse fermante dans le texte)

Ça nécessite que sed lui-même se débrouille suffisamment bien pour détecter le charset xD. Heureusement, en général, les caractères spéciaux XML (< et >) sont toujours codés de la même manière, compatible avec l'UTF-8 que sed attend probablement. Sauf en UTF-16, UTF-32, UCS-2 ou des trucs comme ça, auquel cas sed ne va juste rien transformer, et uchardet sera probablement capable de reconnaître le bon charset correctement. Donc si ça se trouve, ça fonctionne tout le temps, mais pour des raisons un peu plus intéressante que ce qu'on pourrait penser initialement.

Et du coup, la détection de langage dont tu parles, c'est des langages naturels comme le français, des langages informatiques comme l'HTML, ou les deux ?

Mais leur argument de base est faux: si, de nos jours, on sait globalement très bien et très efficacement détecter le codage de flux de textes donc le codage d'origine est inconnu

La détection de charset est très utile, mais ça devrait être du dernier recours quand tout à échoué. Ça marche très bien, mais ce n'est pas parfait.

Qu'est-ce qu'il se passe si je voulais vraiment écrire « ½uf » ? Les outils de détection automatiques risquent d'altérer mon texte. C'est peu probable, mon texte sera probablement plus gros et d'autres éléments permettront de désambiguïser, mais il vaut mieux que le charset soit fourni avec le texte dans le format qui le contient ou dans les métadonnées de transfert, qu'il soit correct et qu'il ne soit pas perdu.

Aussi, c'est triste que ça ne fasse pas 20 ans qu'on n'ait pas bougé à UTF-8 ou UTF-32 par défaut pour tout ce qui est écrit dans un alphabet latin (voir tout, tout court). Parce que bon, finalement, les problèmes d'encodage, ça vient principalement du fait que certains systèmes s'obstinent à pondre du windows-1252 ou du windows-1256, parfois à le déclarer comme du ISO-8859-15 ou inversement. Avec les fichiers de sous-titres justement, il y en a encore plein avec des soucis d'encodage, même de films et séries récentes. On voit encore passer plein de mails en windows-xxx, pour peu qu'ils aient été produits avec des outils MS. Cette négligence nous coûte de la complexité et les détecteurs de charset ont en effet encore de beaux jours devant eux. Je comprends bien qu'il y a des enjeux de rétrocompatibilité, mais il y a un moment où faut décider de corriger les choses, fournir des outils de compatibilité et arrêter les bêtises.

Je comprends la frustration : si ces outils n'existaient pas, peut-être que les logiciels qui produisent du contenu s'assureraient peut-être de standardiser sur un sous-ensemble utile de charset ( distinguables entre eux par le fait que les caractères de l'un sont illégaux dans l'autre) au lieu de laisser tout le monde se débrouiller avec des formats tous pétés.

Je ne suis pas expert et je ne sais pas si une loi interdit d'envoyer des intervenants à une adresse qui ne t'appartient pas sans le consentement des personnes occupant cet endroit (c'est quand même une sorte de nuisance, j'espère que oui), mais j'imagine bien les gendarmes pas très contents venir toquer à ta porte pour te remonter les bretelles, sans forcément te condamner formellement. S'il y a bien des gens à l'aise pour remonter des bretelles, c'est certainement eux / elles.

Je ne serais pas joueur perso.

Une idée fun, mais ça me parait risqué, c'est peut-être bien toi que les gendarmes vont finir par aller chercher.