J'ai hésité à le mettre dans la section des Liens. Mais c'est clairement dit : le vote électronique n'est pas transparent. En plus de coûter de l'argent.
ImageOptim […] fera le travail en "devinant" les bonnes options.
Ou plutôt en brute-forçant non ? Enfin, c'est mon hypothèse, c'est souvent comme ça que font tous les encodeurs avec pertes d'images, que ce soit des images fixes ou vidéos :)
J'ai essayé Lepton aussi, mais le gros inconvénient est qu'il faut un décompresseur quelque part. Et personne n'en a. Ça prend pas mal de temps CPU à la compression et décompression, et le résultat en terme de taille est équivalent à du WebP, qui est largement répandu. Et à ce prix-là, on peut même partir sur du AVIF ;)
Le premier, c'est avec guetzli, le deuxième c'est l'original, le troisième, c'est mozjpeg après guetzli. C'est pas un exemple probant, mais j'avais remarqué que c'est quand même mieux :)
Oui, BPG, c'est du HEVC (donc H.265) intra-frame dans un conteneur. C'est assez efficace, mais c'est le HEIF, qui fait la même chose qui a été retenu et popularisé. Surtout par Apple, parce que c'est pas vraiment supporté non plus.
Sinon, le principe a été retenu pour AV1, qui est un codec vidéo, et dont on a extrait AVIF, qui utilise les algorithmes de codage intra-frame, sensé être plus performant que HEVC.
Mais c'est quand même très coûteux en décodage, comparé à du JPEG ou du PNG, surtout parce que ce sont des formats qui possèdent des routines d'accélération par les GPU, au contraire de AVIF (HEIF devrait pouvoir être accéléré aujourd'hui, mais je ne sais pas si c'est pris en charge). Ce point pourrait évoluer avec le temps. Et puis ça dépend du besoin… Pour afficher un logo d'un site Web, ça a besoin d'être rapide : c'est le temps de transfert plus décodage qui compte. et pas juste le temps de transfert.
Rejoindre WebP ? Je demande à voir. À tester facilement sur https://squoosh.app/
Mais j'allais dire ça : j'ai déjà testé guetzli et franchement… Ben ça fait mieux que MozJPEG, mais pour un coup démesurément plus grand.
Donc je proposerais, pour les gens qui n'ont pas peur du compromis, de mettre MozJPEG en complément de guetzli. En plus, MozJPEG produit exactement les mêmes pixels (en optimisant les tables de Huffman uniquement), contrairement à guetzli, qui rend l'image équivalente, mais qui change les couleurs.
Et si j'ai bonne mémoire, j'ai même eu des surprises : guetzli n'applique pas les optimisations de MozJPEG. Donc, passer MozJPEG après guetzli a du sens. C'est juste une étape de plus (mais rapide).
Pour les PNG, c'est clair que zopfli fait du très bon travail. J'ai pas mal utilisé optipng avant ça, mais rien à faire : zopfli est un peu plus long, mais pas tant que ça, et bien meilleur.
Non, les images compressées se décodent aussi vite. Voire plus vite, puisqu'elles sont plus petites. Mais en général, ça ne se voit pas sur les machines d'aujourd'hui.
La solution, c'est d'abord de fermer la piste et l'aérodrome, et ensuite de construire. Je suis désolé, mais là, ça me fait penser à ces communes vendéennes après le passage de Xynthia. Qui était un drame bien plus grand, par son nombre de victimes, et par le fait que c'est la Nature, et qu'il faut s'y accommoder.
Oui, je sais, et c'est ce qui me désole finalement, parce qu'on est arrivé à une situation des débuts de la télévision : un seul fournisseur. Alors certes, les contenus sont infiniment plus diversifiés, mais avec l'opacité de l'algorithme de proposition, c'est quand même bien biaisé.
J'ai depuis très longtemps un salon XMPP disponible sur https://antipoul.fr/ que des anonymes peuvent rejoindre. Je ne suis pas souvent connecté, mais suffit de rentrer un pseudonyme, et c'est tout.
Je suis personnellement devenu utilisateur de Matrix, mais je garde quand même ce serveur XMPP, que j'auto-héberge sans souci avec Prosody.
Très bon exemple, en effet. J'ai un ami qui préfère justement largement faire son pain, alors que moi, c'est l'inverse. Je considère justement que c'est plus efficace de confier cette tâche à une seule personne, qui dispose de moyens plus efficaces de faire du pain pour plusieurs. Et c'est meilleur.
Donc oui, l'artisan maçon peut probablement auto-hébergé son site Web, mais c'est long et pas très efficace, donc il achète le service.
Mais là, on parle pas de l'artisan du coin, on parle du premier employeur de France ;)
Je ne comprends toujours pas cette position, qui consiste à acheter un service quand on peut se le fabriquer soi-même.
Et dans l'informatique, c'est pire : on va l'acheter, et personne ne va en profiter, alors qu'avec l'Open Source, c'est possible de capitaliser le travail.
Mais non, l'État pense que c'est pas possible de faire un truc Open Source soi-même, auxquels (soyons fous !) les citoyens pourraient contribuer. C'est fou comme idée.
Ça dépend de l'architecture… Si c'est de la répartition par DNS avec split horizon régional (parce que bon, l’anycast, c'est quand même pas facile), c'est plus résilient.
C'est un format connu, qui possède les mêmes défauts que ceux cités : trop d'informations personnelles sont dedans.
En fait, je dirais que le principal défaut est qu'on dit pas aux gens ce qu'il y a dedans, et qu'ils vont le montrer à tout le monde sans en être conscient.
La plateforme, oui, mais le GPU, y a pas photo. OK, les GPU intégré d'Intel marchent avec des pilotes libres, mais les GPU intégré d'AMD (pour comparer ce qui l'est) sont bien, bien meilleurs.
J'ai l'impression qu'il n'y a pas beaucoup plus de gens qui cherchent des failles de sécurité, donc forcément, ils concentrent leurs temps de travail sur un domaine et pas un autre.
Les failles logicielles ne sont pas aussi retentissantes également. Parce qu'elles touchent un seul logiciel en particulier. Et puis, plus personne ne parle des failles immédiatement exploitées (0-day) dans Windows, parce que bon, c'est évident. Des trucs comme Heartbleed ont fait la une parce que quand même, ça touchait tout le monde.
Et puis des failles de sécurité logicielles, il y en a toujours plein, et des marrantes, il suffit de voir tout ce qu'il y a sur les « objets connectés » : caméras, imprimantes, etc.
Mais les failles matérielles sont très singulières (enfin, plus tellement maintenant…) parce qu'elles ne dépendent pas du matériel, et que tous les logiciels qui tournent dessus doivent les prendre en compte. C'est pas facile à corriger :)
Et bien si avec tout ce travail de documentation sur QUIC (la version sur le blog est bien longue et multiple), il y a fort à parier que QUIC est populaire.
Après, va falloir que ça s'installe… Déjà, ce n'est pas facilement disponible en tant que serveur. Heureusement, les clients populaires le supporte.
Et enfin… Faut que le pare-feu de ma boîte accepte de faire passer l'UDP. C'est pas gagné.
Mais, mais, c'est censé donné quoi si tu déposes directement des fichiers comme ça dans ton arborescence Git distant ?
Et bien justement, rrsync fait une sorte de chroot. Donc c'est moi qui lui dit où vont se mettre les fichiers. Sur le serveur, il n'y a que des répertoires de git bare finissant en .git. Donc j'ai mis un répertoire à côté (nommé intelligemment rsync_files) dans lequel tout va se mettre, sans se mélanger.
Et sinon, est-ce que Git-FS n'aurait pas été une option ?
J'ai regardé Git-LFS, mais… voilà, j'ai plein de souci. Pas avec Git-LFS, non, mais avec le reste. Ce serveur est en SLES11, avec un openssl trop vieux, et le Git-LFS (du Gitea en conteneur LXC dans un Proxmox) est trop récent, le HTTPS passe pas. Oui, c'est bête. Oui, c'est sur la liste des choses à faire…
Si ce n'est pas dans l'arborescence d'un dépôt et pas de lien avec Git, pourquoi ne pas utiliser un compte idoine.
Si, justement, c'est en rapport. C'est parce que mon projet utilise yarn et sa gestion de paquets hors-ligne (les paquets en .tar.gz sont gardés quelque part pour pouvoir être utilisé par la plateforme de compilation qui n'a pas accès à Internet). Ça s'accumule avec le temps. Au début, je l'avais mis dans le dépôt git directement. Mais voilà, à force de faire les mises à jour, le dépôt git fait 400 Mo, pour 4 Mo de code utile. Donc j'ai cherché une autre solution, sachant que je n'ai pas besoin de l'historique.
# Résumé par Projet Arcadie
Posté par Glandos . En réponse au journal Vote par ordinateurs de vote / machines à voter en France, depuis 2017. Évalué à 7.
http://blog.projetarcadie.com/content/le-vote-electronique
J'ai hésité à le mettre dans la section des Liens. Mais c'est clairement dit : le vote électronique n'est pas transparent. En plus de coûter de l'argent.
https://xkcd.com/2030/
[^] # Re: Par rapport à la concurrence ?
Posté par Glandos . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 2.
Ou plutôt en brute-forçant non ? Enfin, c'est mon hypothèse, c'est souvent comme ça que font tous les encodeurs avec pertes d'images, que ce soit des images fixes ou vidéos :)
[^] # Re: Lepton
Posté par Glandos . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 3.
J'ai essayé Lepton aussi, mais le gros inconvénient est qu'il faut un décompresseur quelque part. Et personne n'en a. Ça prend pas mal de temps CPU à la compression et décompression, et le résultat en terme de taille est équivalent à du WebP, qui est largement répandu. Et à ce prix-là, on peut même partir sur du AVIF ;)
[^] # Re: Par rapport à la concurrence ?
Posté par Glandos . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 2.
J'ai l'impression qu'il utilise pngquant mentionné sur https://imageoptim.com/versions.html
Ça a l'air d'être avec perte du coup, mais c'est à vérifier !
[^] # Re: Par rapport à la concurrence ?
Posté par Glandos . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 3.
Voilà, exemple sur mon avatar en JPEG :
Le premier, c'est avec guetzli, le deuxième c'est l'original, le troisième, c'est mozjpeg après guetzli. C'est pas un exemple probant, mais j'avais remarqué que c'est quand même mieux :)
[^] # Re: As tu essayé avec BPG?
Posté par Glandos . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 4.
Oui, BPG, c'est du HEVC (donc H.265) intra-frame dans un conteneur. C'est assez efficace, mais c'est le HEIF, qui fait la même chose qui a été retenu et popularisé. Surtout par Apple, parce que c'est pas vraiment supporté non plus.
Sinon, le principe a été retenu pour AV1, qui est un codec vidéo, et dont on a extrait AVIF, qui utilise les algorithmes de codage intra-frame, sensé être plus performant que HEVC.
Mais c'est quand même très coûteux en décodage, comparé à du JPEG ou du PNG, surtout parce que ce sont des formats qui possèdent des routines d'accélération par les GPU, au contraire de AVIF (HEIF devrait pouvoir être accéléré aujourd'hui, mais je ne sais pas si c'est pris en charge). Ce point pourrait évoluer avec le temps. Et puis ça dépend du besoin… Pour afficher un logo d'un site Web, ça a besoin d'être rapide : c'est le temps de transfert plus décodage qui compte. et pas juste le temps de transfert.
[^] # Re: Par rapport à la concurrence ?
Posté par Glandos . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 8.
Rejoindre WebP ? Je demande à voir. À tester facilement sur https://squoosh.app/
Mais j'allais dire ça : j'ai déjà testé guetzli et franchement… Ben ça fait mieux que MozJPEG, mais pour un coup démesurément plus grand.
Donc je proposerais, pour les gens qui n'ont pas peur du compromis, de mettre MozJPEG en complément de guetzli. En plus, MozJPEG produit exactement les mêmes pixels (en optimisant les tables de Huffman uniquement), contrairement à guetzli, qui rend l'image équivalente, mais qui change les couleurs.
Et si j'ai bonne mémoire, j'ai même eu des surprises : guetzli n'applique pas les optimisations de MozJPEG. Donc, passer MozJPEG après guetzli a du sens. C'est juste une étape de plus (mais rapide).
Pour les PNG, c'est clair que zopfli fait du très bon travail. J'ai pas mal utilisé optipng avant ça, mais rien à faire : zopfli est un peu plus long, mais pas tant que ça, et bien meilleur.
[^] # Re: Coût du décodage ?
Posté par Glandos . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 8.
Non, les images compressées se décodent aussi vite. Voire plus vite, puisqu'elles sont plus petites. Mais en général, ça ne se voit pas sur les machines d'aujourd'hui.
[^] # Re: Dilème facile à résoudre
Posté par Glandos . En réponse au journal [HS] Ils étaient trois. Évalué à 8.
Moi je suis d'accord.
Mais.
La solution, c'est d'abord de fermer la piste et l'aérodrome, et ensuite de construire. Je suis désolé, mais là, ça me fait penser à ces communes vendéennes après le passage de Xynthia. Qui était un drame bien plus grand, par son nombre de victimes, et par le fait que c'est la Nature, et qu'il faut s'y accommoder.
[^] # Re: La bonne stratégie
Posté par Glandos . En réponse au journal PeerTube ← pot de miel sur Youtube (Sea Dragon TRS-80 + audio-description). Évalué à 4.
Oui, je sais, et c'est ce qui me désole finalement, parce qu'on est arrivé à une situation des débuts de la télévision : un seul fournisseur. Alors certes, les contenus sont infiniment plus diversifiés, mais avec l'opacité de l'algorithme de proposition, c'est quand même bien biaisé.
[^] # Re: La bonne stratégie
Posté par Glandos . En réponse au journal PeerTube ← pot de miel sur Youtube (Sea Dragon TRS-80 + audio-description). Évalué à 4.
On parle de cliquer sur un lien quand même… On est vraiment devenu flemmard à ce point-là ?
[^] # Re: Ça manque de détails
Posté par Glandos . En réponse au lien C'est officiel: la FSF et le projet GNU déménagent leurs canaux IRC sur Libera.Chat. Évalué à 2.
J'ai depuis très longtemps un salon XMPP disponible sur https://antipoul.fr/ que des anonymes peuvent rejoindre. Je ne suis pas souvent connecté, mais suffit de rentrer un pseudonyme, et c'est tout.
Je suis personnellement devenu utilisateur de Matrix, mais je garde quand même ce serveur XMPP, que j'auto-héberge sans souci avec Prosody.
[^] # Re: Incompréhension
Posté par Glandos . En réponse au lien Doctolib, données de santé et États-Unis/Amazon. Évalué à 3.
Très bon exemple, en effet. J'ai un ami qui préfère justement largement faire son pain, alors que moi, c'est l'inverse. Je considère justement que c'est plus efficace de confier cette tâche à une seule personne, qui dispose de moyens plus efficaces de faire du pain pour plusieurs. Et c'est meilleur.
Donc oui, l'artisan maçon peut probablement auto-hébergé son site Web, mais c'est long et pas très efficace, donc il achète le service.
Mais là, on parle pas de l'artisan du coin, on parle du premier employeur de France ;)
# Incompréhension
Posté par Glandos . En réponse au lien Doctolib, données de santé et États-Unis/Amazon. Évalué à 8.
Je ne comprends toujours pas cette position, qui consiste à acheter un service quand on peut se le fabriquer soi-même.
Et dans l'informatique, c'est pire : on va l'acheter, et personne ne va en profiter, alors qu'avec l'Open Source, c'est possible de capitaliser le travail.
Mais non, l'État pense que c'est pas possible de faire un truc Open Source soi-même, auxquels (soyons fous !) les citoyens pourraient contribuer. C'est fou comme idée.
# Go with Rust
Posté par Glandos . En réponse au journal gb3: mincir sa tribune pour la plage. Évalué à 5.
Je plussoie. Attention, il mettre de l'inox A4 en métallique, parce que le milieu marin, ça fait vraiment rouiller.
[^] # Re: What?
Posté par Glandos . En réponse au journal Gitlab, Github & Stackoverflow sont inaccessibles simultanément. Évalué à 4. Dernière modification le 08 juin 2021 à 21:10.
Ça dépend de l'architecture… Si c'est de la répartition par DNS avec split horizon régional (parce que bon, l’anycast, c'est quand même pas facile), c'est plus résilient.
Sinon, y a Decentraleyes, mais ça fait pas tout.
[^] # Re: vaccin, donnée médicale?
Posté par Glandos . En réponse au lien Pass sanitaire : la poudre aux yeux du pseudonymat, des données médicales en clair. Évalué à 6.
Les Européens, je ne sais pas, mais les Canadiens, si.
C'est un format connu, qui possède les mêmes défauts que ceux cités : trop d'informations personnelles sont dedans.
En fait, je dirais que le principal défaut est qu'on dit pas aux gens ce qu'il y a dedans, et qu'ils vont le montrer à tout le monde sans en être conscient.
[^] # Re: Avantages d'une licence libre
Posté par Glandos . En réponse au journal Les différences entre la littérature et le code pour les licences libres. Évalué à 3.
D'ailleurs… On pourrait bien placer ces 70 ans après la mort de l'auteur dans les discussions…
[^] # Re: Ironie
Posté par Glandos . En réponse au journal De Intel/Nvidia à AMD.. Évalué à 8.
La plateforme, oui, mais le GPU, y a pas photo. OK, les GPU intégré d'Intel marchent avec des pilotes libres, mais les GPU intégré d'AMD (pour comparer ce qui l'est) sont bien, bien meilleurs.
[^] # Re: IRC toujours première messagerie sur le net?
Posté par Glandos . En réponse au lien Liste des projets et canaux qui quittent Freenode… et des quelques irréductibles qui y restent.. Évalué à 4.
C'est pas IRCv3 qui est sensé gérer les horloges ?
Bon, OK, pour le déploiement et l'adoption, on repassera…
[^] # Re: Les failles matériel
Posté par Glandos . En réponse au lien Faille de sécu Rowhammer. Évalué à 4. Dernière modification le 30 mai 2021 à 18:19.
Est-ce qu'il n'y a pas un biais ici ?
J'ai l'impression qu'il n'y a pas beaucoup plus de gens qui cherchent des failles de sécurité, donc forcément, ils concentrent leurs temps de travail sur un domaine et pas un autre.
Les failles logicielles ne sont pas aussi retentissantes également. Parce qu'elles touchent un seul logiciel en particulier. Et puis, plus personne ne parle des failles immédiatement exploitées (0-day) dans Windows, parce que bon, c'est évident. Des trucs comme Heartbleed ont fait la une parce que quand même, ça touchait tout le monde.
Et puis des failles de sécurité logicielles, il y en a toujours plein, et des marrantes, il suffit de voir tout ce qu'il y a sur les « objets connectés » : caméras, imprimantes, etc.
Mais les failles matérielles sont très singulières (enfin, plus tellement maintenant…) parce qu'elles ne dépendent pas du matériel, et que tous les logiciels qui tournent dessus doivent les prendre en compte. C'est pas facile à corriger :)
# Belle rédaction
Posté par Glandos . En réponse à la dépêche Le protocole QUIC désormais normalisé. Évalué à 10.
Et bien si avec tout ce travail de documentation sur QUIC (la version sur le blog est bien longue et multiple), il y a fort à parier que QUIC est populaire.
Après, va falloir que ça s'installe… Déjà, ce n'est pas facilement disponible en tant que serveur. Heureusement, les clients populaires le supporte.
Et enfin… Faut que le pare-feu de ma boîte accepte de faire passer l'UDP. C'est pas gagné.
[^] # Re: Il existe un marché de l'occasion pour les serveurs
Posté par Glandos . En réponse au lien Comment diviser par 7 le coût de ses serveurs ….. ou presque. Évalué à 10.
Bref, une logique de destruction des ressources primaires.
[^] # Re: wow
Posté par Glandos . En réponse au lien Les GAFAM échappent au RGPD, la CNIL complice. Évalué à 7.
Voilà. Faut pas être grand clerc pour voir qu'il n'y a pas de respect de la loi : il est où le bouton « Refuser » ?
[^] # Re: intéressant…
Posté par Glandos . En réponse au journal Restreindre rsync avec git-shell. Évalué à 3.
Et bien justement, rrsync fait une sorte de chroot. Donc c'est moi qui lui dit où vont se mettre les fichiers. Sur le serveur, il n'y a que des répertoires de git bare finissant en
.git. Donc j'ai mis un répertoire à côté (nommé intelligemmentrsync_files) dans lequel tout va se mettre, sans se mélanger.J'ai regardé Git-LFS, mais… voilà, j'ai plein de souci. Pas avec Git-LFS, non, mais avec le reste. Ce serveur est en SLES11, avec un openssl trop vieux, et le Git-LFS (du Gitea en conteneur LXC dans un Proxmox) est trop récent, le HTTPS passe pas. Oui, c'est bête. Oui, c'est sur la liste des choses à faire…
Si, justement, c'est en rapport. C'est parce que mon projet utilise
yarnet sa gestion de paquets hors-ligne (les paquets en.tar.gzsont gardés quelque part pour pouvoir être utilisé par la plateforme de compilation qui n'a pas accès à Internet). Ça s'accumule avec le temps. Au début, je l'avais mis dans le dépôt git directement. Mais voilà, à force de faire les mises à jour, le dépôt git fait 400 Mo, pour 4 Mo de code utile. Donc j'ai cherché une autre solution, sachant que je n'ai pas besoin de l'historique.