Glandos a écrit 1216 commentaires

Apparemment, c'est un peu contesté : https://www.lemonde.fr/international/article/2021/07/16/trump-poutine-et-le-scoop-du-guardian_6088418_3210.html

Enfin, les gens ont l'air de dire que c'est peut-être trafiqué.

Plusieurs experts ont cependant appelé à la prudence. « Pour une fuite de cette importance, nous avons besoin de quelques détails » sur sa provenance, a réagi le chercheur Thomas Rid, l’un des premiers à avoir alerté contre une attaque russe lors de l’élection de 2016. « C’est beaucoup trop pratique et ça empeste l’opération de désinformation », a réagi Chris Krebs, l’ancien directeur national américain de la cybersécurité.

Certains ont cru repérer des fautes d’orthographe ou lexicales dans le texte en russe, signes d’une manipulation. Le journaliste Glenn Greenwald, lui-même un ancien du Guardian, où il a sorti les révélations d’Edward Snowden, a même mis en doute la crédibilité de Luke Harding, rappelant qu’il avait affirmé à tort, en novembre 2018, que Paul Manafort, l’ancien directeur de campagne de M. Trump, avait rencontré Julian Assange à l’ambassade équatorienne à Londres.

Oui, mais moi, je vois surtout le côté « ordinateur » plutôt que « console ». J'ai une Nintendo Switch, c'est pas libre, tant pis. Là, c'est un ordinateur IBM-PC compatible !

Donc en fait, on peut probablement mettre ce qu'on veut dessus. Gog aussi ?

D’ailleurs, les passagers seront informés à leur montée dans le bus et pourront s’opposer à cette collecte de données.

Qu'est-ce qu'on rigole. Donc à chaque montée dans le bus, le passager aura le temps de comprendre ce qu'on lui demande et de donner son consentement éclairé ? Bon, la qualité de service du transport va être drôlement impactée.

Ensuite, si un passager refuse, comment … l'identifier ? On arrête la collecte pour tout son trajet ? Mais quand est-ce qu'on sait qu'il est descendu ? Le chauffeur ? Raaa, que de questions :)

Attention, il a utilisé l'option -m qui compresse un peu plus.

Mais moi, ce qui m'étonne, c'est qu'il me semblait avoir déjà passé zopfli sur cette image :/ Bon, mon avatar sur LinuxFR est vieux, j'ai dû découvrir cet outil après, va savoir…

L’objectif est de mettre à disposition de données riches, fiables, précises, standardisées, bien documentées et librement accessibles pour une connaissance 3D fine, et homogène du sol topographique, du sur-sol artificiel (bâtiments, ponts) et de la végétation.

C'est un peu caché au milieu, mais c'est une nouvelle que j'accueille avec bienveillance.

Sinon, il y a aussi la carte du chantier sur https://macarte.ign.fr/carte/322ea69dab4c7e5afabc6ec7043b5994/acquisitionslidarhd

J'ai une fonction fish qui fait ça :

function mozjpeg_all --description 'Re-encode multiple images using mozjpeg, preserving all markers'
    printf "%s\x00" $argv | xargs --null --max-args=1 --max-procs=3 -I'{}' /home/user/Dev/mozjpeg/build/jpegtran -copy all -outfile 'moz-{}' '{}'
end

Ça se transforme aisément en shell POSIX. Par contre, j'ai un avertissement de xargs qui me dit que je l'utilise mal, mais euh… ça marche.

Ah oui, c'est le jpegtran de mozjpeg. En général, ça économise 5 à 7 %. Sans perte par rapport à l'original.

Quand on rentre dans ce monde là, c'est compliqué. J'ai dû me forcer à y plonger pour une sombre histoire de Pixel Aspect Ratio et Display Aspect Ratio. C'est bien la guerre des maths. Ça ne reste que des règles de trois, mais c'est dur ne pas s'y perdre.

J'étais un peu sceptique, notamment face aux potentiels brevets, qui minent HEIF par exemple.

Ce long article semble dire que c'est pas le cas : https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs

Et surtout : la vitesse d'encodage de JPEG XL est bonne. Ce qui n'est évidemment pas du tout le cas de HEIF et AVIF. Le principal avantage de ces derniers restent la qualité à basse quantité de données. Ça parle des mini-animations, mais c'est évident que les codecs vidéos font mieux : c'est leur job.

Voir la discussion sur https://linuxfr.org/users/antistress/liens/le-nouveau-format-d-applications-pour-android-les-enferme-dans-le-google-play

Si ça pouvait envoyer les restrictions de AAB en enfer, ça serait bien. Mais voilà, je suis sceptique sur l'issue de ce combat.

une perquisition au siège de Doctolib, à Levallois-Perret.

Cette ville me dit quelque chose… Boah, c'est bon, je déconne ;)

J'ai plutôt envie de dire : enfin. C'est devenu difficile d'échapper à Doctolib aujourd'hui, en tant que patient. J'essaie, parce que je ne souhaite pas être contacté par SMS pour les rappels, et c'est obligatoire chez eux.

Enfin, pour être juste et honnête, ce n'est pas parce qu'une entreprise domine le marché qu'elle a franchi les règles. Si ça se trouve, l'enquête montrera que Doctolib a simplement fait mieux que les autres.

Ma compagne a acheté un Fairphone 3+ directement équipé de e/OS/. Ça marche. L'affichage de la note des rapports de Exodus Privacy dans le magasin d'application est très sympa.

OK, alors je découvre (horrifié) cette nouvelle…
D'après l'article lié :

In fact, App Bundles require that apps should be no bigger than 150MB.
[…]
For apps that need more than 150MB, App Bundles introduce a new feature to replace OBBs called Play Asset Delivery.
Play Asset Delivery also comes with the benefit of security since the assets are stored in and downloaded from Google Play rather than some CDN hosting provided arranged by developers on their own.

Je comprends totalement le besoin. C'est clair que télécharger une grosse application pour ne pas avoir à se servir de tout, c'est nul. Mais pourquoi avoir mis l'obligation de maximum 150 Mo ? Et si les gens veulent faire plus ?

Google prend de très gros risques à faire ça. Ça ne peut pas ne pas attirer le régulateur. Je comprends pas ce qui leur passe par la tête.

Ou alors, c'est un coup de bluff. Ça passe ou ça casse (et les contraintes se relâchent). Après tout, Google a une cote en or, ils peuvent se permettre se genre d'expérience…

Qu'on pouvait faire du RAII en C avec cleanup :

#include <stdlib.h>



#define autofree __attribute__(cleanup(free))



const size_t scratchpad_size = 500000;



void some_function(void) {

    autofree char *scratchpad = calloc(1, scratchpad_size);



    memset(scratchpad, 'A', scratchpad_size);

}

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/

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 ;)

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 !

Voilà, exemple sur mon avatar en JPEG :

.rw-r--r-- 34k adrien 2021-06-17 23:06 avatar-fleur2-guetzli.JPG
.rw-r-xr-- 38k adrien 2021-06-17 23:05 avatar-fleur2.JPG
.rw-r--r-- 32k adrien 2021-06-17 23:07 moz-avatar-fleur2-guetzli.JPG

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.

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.

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é.

l'effort

On parle de cliquer sur un lien quand même… On est vraiment devenu flemmard à ce point-là ?