PNG filtre l'image pour ne garder que les contours des aplats unis (en gros) et laisser le rester en noir. Ensuite il fait une bête compression deflate. L'image devrait donc prendre plus de place avec les lignes qu'avec des aplats colorés. La postérisation devrait aider dans ce cas.
QOI fait un peu la même chose mais dans une fenêtre glissante qui rend les répétitions d'une même couleur moins coûteuses. Il opère linéairement, un pixel n'est pas relié à son voisin de la ligne supérieur (alors que c'est le cas pour PNG).
On pourrait imaginer une variante de QOI qui passe en nuance de gris (1 octet) régulièrement sur une proportion donnée des lignes, et en couleurs (3 octets) sur le reste des lignes. La compression sera moins bonne aux transitions entre les modes de couleurs mais l'image sera plus légère dans les lignes grises.
Par rapport à la grille, peut-être stocker l'image en nuances de gris, et stocker la grille de couleurs sous forme d'une liste de polygones formés par des points (avec une couleur associée à chaque polygone), puis générer la grille et la superposer à l'image côté client.
Sinon il existe Yoga Image Optimizer qui est libre et qui optimise les images avec perte dans plein de formats y compris JPEG et WebP.
L'étude ne conclut pas que les humains sont moins bons que les IA pour résoudre un captcha, mais que ce soit vrai ou faux aujourd'hui, ce sera sûrement bientôt vrai.
Ce qui m'inquiète avec l'obsolescence du captcha, c'est que le moyen le plus simple pour se protéger du spam sera l'identification via un service centralisé, avec vérification forte (par exemple biométrie, papiers d'identité, appli sur le smartphone). Les utilisateurs actuels du captcha seront encouragés par les fournisseurs de captcha à passer au nouveau système, qui sera quasiment imperceptible pour leurs internautes qui sont déjà habitués des GAFAM.
Un système d'identification décentralisé, respectueux de la vie privée, non censurable, qui n'encourage pas les discriminations (il ne faudrait pas exclure les sans-papiers, migrants, opposants politiques…), reposant sur de la cryptographie moderne et respectant des principes de sécurité de base… pour quoi faire ?
Et pourquoi pas une future "Loi pour la Cyberintégrité de la vie Civico-digitale" (soyons fous), qui rendrait obligatoire l'utilisation de tels systèmes. (toute ressemblance avec la loi sur l'identification obligatoire pour accéder aux sites pornos serait fortuite)
Refuser d'utiliser ces systèmes exposerait les serveurs à du spam et les utilisateurs à ne plus avoir accès à nombre de services. (on y est presque, avec Web Environment Integrity et les autres DRM)
En attendant il reste agréable de résoudre les captchas de Google avec une IA de reconnaissance vocale de Google. (cf. l'extension Buster pour Firefox, qui marche plutôt bien)
Je n'ai testé Manjaro que sur Pinephone. Au début avec le bureau Plasma (KDE) préinstallé, mais il était trop lent, instable, et causait une surchauffe permanente.
Après avoir testé Postmarket OS avec SXMO (trop galère et plante tout le temps), j'ai réinstallé Manjaro avec Phosh (GNOME), parce que je suis habitué à Arch et que j'aime beaucoup pacman. C'est suffisamment fluide si on ne lui en demande pas trop, ça plante encore de temps en temps, ce qui semble encore inévitable sur Pinephone (donc ce n'est probablement pas la faute de l'équipe Manjaro ARM, seulement que l'écosystème de pilotes est encore trop jeune, que les fabricants ne doivent pas être coopératifs, et que les environnements de bureau et les interfaces graphiques n'étaient pas conçus pour téléphone au départ).
Par contre les dépôts sont très peu souvent mis à jour, et certaines mises à jour créent de nouveaux plantages qui ne sont pas corrigés. (par exemple je ne peux plus fermer ni changer de fenêtre, sinon ça plante) Et si par ignorance on utilise pacman au lieu de pamac, ça casse tout. Il manque aussi quelques paquets qui sont disponibles dans d'autres distros.
Ça devrait les empêcher d'être utilisés dans pas mal de systèmes liberticides, mais ce n'est pas suffisant : par exemple des appareils privateurs (TV, routeur, voiture…) fabriqués et distribués par des groupes capitalistes incluent souvent des logiciels sous GPL.
Et ça ne me plaît pas. Le problème est qu'on est trop coincés sur la définition de "libre", au point de protéger un peu trop la liberté d'être liberticide. Je pense que la (A)GPL pourrait être forkée pour corriger ça. Cependant les clauses risquent d'être assez vagues (comme ces BSD avec clause antimilitaire), contournables ou trop restrictives, incompatibles avec les autres licences libres, peut-être illégales, antistratégiques (menant à l'isolement plutôt qu'attirant des acteurs commerciaux vers le libre)…
Quelqu'un a une piste, y a-t-il des travaux sur le sujet (sur les plans juridiques, stratégiques, techniques) ?
En Rust on gère la mémoire aussi précisément qu'en C, mais avec (presque) autant d'aisance qu'avec un GC, sans le runtime du GC, et sans le risque de faire des bêtises.
Il est impossible de prouver que le code exécuté par le serveur est libre et publié. La même critique pourrait être faite pour tous les services web du monde du libre (Linuxfr, Wikipédia, etc). L'AGPL interdirait de modifier le code du serveur en secret, mais elle ne permettrait toujours pas de savoir si le code a été modifié.
L'important est que les données accessibles soient libres, c'est-à-dire le contenu et l'interface web. Pour cette dernière, il faut soit faire confiance à l'administrateur du serveur, soit avoir un module du navigateur qui vérifie l'intégrité du code (si ça existe) soit utiliser un client installé (ça existe pour GNU/Linux, Windows et Android).
L'arbre NTFS ne contient que debug et write qui est activé.
J'utilise QEMU pour l'émulation, c'est possible de débrancher/rebrancher à chaud une image disque?
Après avoir installé curses ça compile bien, mais dans la config de busybox il n'y a que FEATURE_VOLUMEID_NTFS en rapport avec NTFS, et il était déjà activé.
Dans celle de Linux NTFS write support était déjà activé mais pas NTFS debugging support donc je l'ai activé.
Mais maintenant /dev/sda n'existe plus du tout et fdisk -l ne dit absolument rien.
/dev/sda et /dev/sda1 existent bien, et fdisk reconnaît /dev/sda1 comme une partition de boot HPFS/NTFS de 8Go, de ce côté là ça marche.
Je vais essayer de recompiler avec menuconfig alors.
Je n'ai plus la clef d'installation de Debian, est-ce qu'il n'y aurait pas plutôt une solution sans l'installateur? Toutes mes clés USB sont déjà utilisées…
Ou est-ce qu'il est possible de faire ça depuis un quelconque live USB Linux?
# L'article en question
Posté par tuxmain (site web personnel) . En réponse au lien Alzheimer : les anti-vaccins en PLS ? :-). Évalué à 2.
Lien de l'article scientifique en accès ouvert : https://content.iospress.com/articles/journal-of-alzheimers-disease/jad220361
Les deux méta-analyses antérieures que j'ai trouvées concluent aussi à un bénéfice de la vaccination contre la maladie d'Alzheimer :
- https://pubmed.ncbi.nlm.nih.gov/26825097/
- https://pubmed.ncbi.nlm.nih.gov/31195946/
# PNG et QOI
Posté par tuxmain (site web personnel) . En réponse au journal Du format et de la taille des images. Évalué à 2.
PNG filtre l'image pour ne garder que les contours des aplats unis (en gros) et laisser le rester en noir. Ensuite il fait une bête compression deflate. L'image devrait donc prendre plus de place avec les lignes qu'avec des aplats colorés. La postérisation devrait aider dans ce cas.
QOI fait un peu la même chose mais dans une fenêtre glissante qui rend les répétitions d'une même couleur moins coûteuses. Il opère linéairement, un pixel n'est pas relié à son voisin de la ligne supérieur (alors que c'est le cas pour PNG).
On pourrait imaginer une variante de QOI qui passe en nuance de gris (1 octet) régulièrement sur une proportion donnée des lignes, et en couleurs (3 octets) sur le reste des lignes. La compression sera moins bonne aux transitions entre les modes de couleurs mais l'image sera plus légère dans les lignes grises.
Par rapport à la grille, peut-être stocker l'image en nuances de gris, et stocker la grille de couleurs sous forme d'une liste de polygones formés par des points (avec une couleur associée à chaque polygone), puis générer la grille et la superposer à l'image côté client.
Sinon il existe Yoga Image Optimizer qui est libre et qui optimise les images avec perte dans plein de formats y compris JPEG et WebP.
# Le monde post-captcha
Posté par tuxmain (site web personnel) . En réponse au lien Great news! Humans are now slower and perform worse at solving Captchas than machine-learning bots!. Évalué à 10.
L'étude ne conclut pas que les humains sont moins bons que les IA pour résoudre un captcha, mais que ce soit vrai ou faux aujourd'hui, ce sera sûrement bientôt vrai.
Ce qui m'inquiète avec l'obsolescence du captcha, c'est que le moyen le plus simple pour se protéger du spam sera l'identification via un service centralisé, avec vérification forte (par exemple biométrie, papiers d'identité, appli sur le smartphone). Les utilisateurs actuels du captcha seront encouragés par les fournisseurs de captcha à passer au nouveau système, qui sera quasiment imperceptible pour leurs internautes qui sont déjà habitués des GAFAM.
Un système d'identification décentralisé, respectueux de la vie privée, non censurable, qui n'encourage pas les discriminations (il ne faudrait pas exclure les sans-papiers, migrants, opposants politiques…), reposant sur de la cryptographie moderne et respectant des principes de sécurité de base… pour quoi faire ?
Et pourquoi pas une future "Loi pour la Cyberintégrité de la vie Civico-digitale" (soyons fous), qui rendrait obligatoire l'utilisation de tels systèmes. (toute ressemblance avec la loi sur l'identification obligatoire pour accéder aux sites pornos serait fortuite)
Refuser d'utiliser ces systèmes exposerait les serveurs à du spam et les utilisateurs à ne plus avoir accès à nombre de services. (on y est presque, avec Web Environment Integrity et les autres DRM)
En attendant il reste agréable de résoudre les captchas de Google avec une IA de reconnaissance vocale de Google. (cf. l'extension Buster pour Firefox, qui marche plutôt bien)
# Petit retour d'expérience de Manjaro sur Pinephone
Posté par tuxmain (site web personnel) . En réponse au journal ManjaroARM se fait épingler par Asahi Linux. Évalué à 5.
Je n'ai testé Manjaro que sur Pinephone. Au début avec le bureau Plasma (KDE) préinstallé, mais il était trop lent, instable, et causait une surchauffe permanente.
Après avoir testé Postmarket OS avec SXMO (trop galère et plante tout le temps), j'ai réinstallé Manjaro avec Phosh (GNOME), parce que je suis habitué à Arch et que j'aime beaucoup pacman. C'est suffisamment fluide si on ne lui en demande pas trop, ça plante encore de temps en temps, ce qui semble encore inévitable sur Pinephone (donc ce n'est probablement pas la faute de l'équipe Manjaro ARM, seulement que l'écosystème de pilotes est encore trop jeune, que les fabricants ne doivent pas être coopératifs, et que les environnements de bureau et les interfaces graphiques n'étaient pas conçus pour téléphone au départ).
Par contre les dépôts sont très peu souvent mis à jour, et certaines mises à jour créent de nouveaux plantages qui ne sont pas corrigés. (par exemple je ne peux plus fermer ni changer de fenêtre, sinon ça plante) Et si par ignorance on utilise pacman au lieu de pamac, ça casse tout. Il manque aussi quelques paquets qui sont disponibles dans d'autres distros.
# Clauses anticapitalistes, antimilitaires, etc.
Posté par tuxmain (site web personnel) . En réponse au journal Tout le monde (ou plutôt, trop de gens) semble se foutre des licences en 2022. Évalué à 2.
J'utilise la GNU AGPLv3 pour tous mes projets.
Ça devrait les empêcher d'être utilisés dans pas mal de systèmes liberticides, mais ce n'est pas suffisant : par exemple des appareils privateurs (TV, routeur, voiture…) fabriqués et distribués par des groupes capitalistes incluent souvent des logiciels sous GPL.
Et ça ne me plaît pas. Le problème est qu'on est trop coincés sur la définition de "libre", au point de protéger un peu trop la liberté d'être liberticide. Je pense que la (A)GPL pourrait être forkée pour corriger ça. Cependant les clauses risquent d'être assez vagues (comme ces BSD avec clause antimilitaire), contournables ou trop restrictives, incompatibles avec les autres licences libres, peut-être illégales, antistratégiques (menant à l'isolement plutôt qu'attirant des acteurs commerciaux vers le libre)…
Quelqu'un a une piste, y a-t-il des travaux sur le sujet (sur les plans juridiques, stratégiques, techniques) ?
# Sécurité de la mémoire sans C ni GC
Posté par tuxmain (site web personnel) . En réponse au journal Performances et GC : détruisons les mythes. Évalué à 5.
En Rust on gère la mémoire aussi précisément qu'en C, mais avec (presque) autant d'aisance qu'avec un GC, sans le runtime du GC, et sans le risque de faire des bêtises.
[^] # Re: A démontrer
Posté par tuxmain (site web personnel) . En réponse à la dépêche Ğ1formation : une plate-forme libre pour des formations monétarisées en Ğ1 . Évalué à 2.
Il est impossible de prouver que le code exécuté par le serveur est libre et publié. La même critique pourrait être faite pour tous les services web du monde du libre (Linuxfr, Wikipédia, etc). L'AGPL interdirait de modifier le code du serveur en secret, mais elle ne permettrait toujours pas de savoir si le code a été modifié.
L'important est que les données accessibles soient libres, c'est-à-dire le contenu et l'interface web. Pour cette dernière, il faut soit faire confiance à l'administrateur du serveur, soit avoir un module du navigateur qui vérifie l'intégrité du code (si ça existe) soit utiliser un client installé (ça existe pour GNU/Linux, Windows et Android).
[^] # Re: Bonsoir
Posté par tuxmain (site web personnel) . En réponse au message Compiler un live Linux minimal avec support NTFS. Évalué à 1.
L'arbre NTFS ne contient que debug et write qui est activé.
J'utilise QEMU pour l'émulation, c'est possible de débrancher/rebrancher à chaud une image disque?
[^] # Re: Bonsoir
Posté par tuxmain (site web personnel) . En réponse au message Compiler un live Linux minimal avec support NTFS. Évalué à 1.
Après avoir installé curses ça compile bien, mais dans la config de busybox il n'y a que
FEATURE_VOLUMEID_NTFSen rapport avec NTFS, et il était déjà activé.Dans celle de Linux
NTFS write supportétait déjà activé mais pasNTFS debugging supportdonc je l'ai activé.Mais maintenant
/dev/sdan'existe plus du tout etfdisk -lne dit absolument rien.[^] # Re: Bonsoir
Posté par tuxmain (site web personnel) . En réponse au message Compiler un live Linux minimal avec support NTFS. Évalué à 1.
J'ai une erreur en compilant busybox avec menuconfig:
Et la même chose pour linux:
[^] # Re: Bonsoir
Posté par tuxmain (site web personnel) . En réponse au message Compiler un live Linux minimal avec support NTFS. Évalué à 1.
/dev/sda et /dev/sda1 existent bien, et fdisk reconnaît /dev/sda1 comme une partition de boot HPFS/NTFS de 8Go, de ce côté là ça marche.
Je vais essayer de recompiler avec menuconfig alors.
[^] # Re: debian-installer to the rescue
Posté par tuxmain (site web personnel) . En réponse au message grub error: `symbol_efi_secure_boot' not found. Évalué à 1.
Je n'ai plus la clef d'installation de Debian, est-ce qu'il n'y aurait pas plutôt une solution sans l'installateur? Toutes mes clés USB sont déjà utilisées…
Ou est-ce qu'il est possible de faire ça depuis un quelconque live USB Linux?