raphj a écrit 1745 commentaires

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.

Maintenant, je décroche et je ne dis rien du tout. Pas de bruit de respiration.

En général, ça raccroche tout seul et ça ne rappelle pas. Et j'ai de moins en moins d'appels (aucun sur ces derniers mois).

Mon hypothèse, c'est que les appels sont lancés de manière asynchrone et qu'on est mis en relation avec un opérateur ou une opératrice quand on décroche. Un robot détecte si ce n'est pas un numéro foireux (fax, numéro sans téléphone, autre machine). S'il n'y a pas de son après avoir décroché, le robot décide que ce n'est pas un bon numéro, raccroche et mets le numéro dans une liste de numéros à ne plus appeler.

Je ne sais pas si cette hypothèse est vraie mais pour l'instant ça m'a réussi. J'aime beaucoup mieux comme ça, je n'ai pas à vivre ce moment où je dis non à un humain, ce que je n'aime pas du tout faire, et en plus je suis de moins en moins embêté.

En tout cas pour le moment. Si on est beaucoup à faire ça, peut-être que les entreprises qui démarchent vont s'adapter…

Ça marche bien aussi parce que quand quelqu'un vous appelle pour un motif légitime, la personne a le réflexe de dire "Allô ?" et donc vous savez que ce n'est pas du démarchage et ce n'est pas trop bizarre socialement parce que des moments où la voix n'arrive pas tout de suite à cause de problèmes techniques, ça arrive tout le temps et ça peut même ne pas se remarquer du tout.

Courage Olivier !

Grammalecte est un projet fantastique et très utile, mais rien ne t'oblige à travailler dessus si tu n'en a pas la force actuellement. Tu ne dois rien à personne. Ce serait presque l'inverse. Il n'y a pas de raison de te sentir coupable de quoi que ce soit.

En tout cas, aujourd'hui, on a un logiciel qui fonctionne très bien tel quel. Rien n'est urgent.

Et aussi, bon rétablissement ! Vas-y aussi cool que possible. J'espère que tu trouveras des solutions à tes soucis.

Plein d'ondes positives à toi.

Et si finalement tu décides de t'éloigner un peu du projet, il y aura probablement des gens pour reprendre la main, au moins en partie. Ça serait cool si tu pouvais nous en dire plus sur l'amélioration majeure que tu évoques, quand le temps, l'énergie et l'envie t'en prendra. Pour l'intérêt technique pur, et aussi si on doit continuer sur ta lancée.

Merci Olivier.

C'est Damien :-)