Cette information me laisse un peu pantois quand on sait que la proposition a été faite le 1er avril et que l'on sait que fedora est très lié à Gnome (à travers RedHat)
Pourtant la proposition a l'air plutôt bien argumentée (disclamer: j'ai pas tout lu en détails)
Mais malgré tous les efforts que RedHat met dans Gnome et autres financement, j'avais cru comprendre que Plasma est peut-être globalement plus utilisé globalement (d’ailleurs, on a quelques chiffres "plutôt" fiables sur le sujet --même si je sais qu'avec l'open-source, c'est assez compliqué de savoir…--?)
En ce qui concerne la compression avec perte (lossy) de webp, si l'on en juge par la phrase:
When Google first introduced WebP, it outperformed libjpeg-turbo in terms of compression density, as can be seen in the plot above. But Mozilla was not impressed, and they created their own JPEG encoder, mozjpeg, which is slower than libjpeg-turbo but offers better compression results. And indeed, we can see that mozjpeg is actually more Pareto-efficient than WebP (for this corpus, at this quality point).
et le fait que Google a utilisé une vieille (mauvaise?) métrique pour évaluer la qualité de WebP et qui fausse les résultats, si on applique les 2 raisons avancées par Google pour virer jxl de Chrome (cf https://www.phoronix.com/news/Chrome-Dropping-JPEG-XL-Reasons):
There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL
The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default
on arrive à la conclusion que:
sûrement que webp lossy n'aurait jamais dû être un format inclus dans les navigateurs.
Surtout quand on voit le support de ce format loin d'être universel longtemps après son introduction.
Le format jxl, vu toutes les fonctionnalités offertes et l'adoption, pourrait être le format universel pour quasiment tous les usages pour tourner la pages des nombreux formats plus ou moins bon actuellement utilisés.
Seulement il y a la décision de Google/Chrome qui met un gros caillou dans l'engrenage :(
J'ai lu plusieurs fois quelqu'un parlant de Auxio. J'ai essayé plusieurs fois et je comprend vraiment pas l'ergonomie du truc où alors y'a un bug car j'ai jamais réussi à lui faire découvrir la musique stockée sur le support de stockage (avec les nombreux autres lecteurs, j'ai pas de problème…)
Un prix Nobel avait évalué dans une étude que le bonheur augmentait jusqu'à un salaire max d'environ 75k€/an.
On peut donc imaginer, en prenant assez large, qu'une personne ayant gagné 10M€ soit un peu plus l'équivalent de cette somme sur une grosse espérance de vie de 100ans ne devrait pas gagner plus et que donc on pourrait légiférer pour qu'une personne ne gagne pas plus sur l'ensemble de sa vie.
Quitte à partager un lien, je préfère que ce soit un lien invidious (comme ça ceux qui veulent vraiment aller sur YouTube peuvent y aller facilement et pour les autres, on ne les obligent pas à être pisté et à voir de la publicité) : https://invidious.hostux.net/watch?v=o_9Y_F3f_NA
Peut-être serait-il bien de rajouter le lien vers "Hunger Games" ( https://hunger.openfoodfacts.org/ ), là ou c'est évoqué (mieux) ou avec les autres liens…
Je voulais poster ce lien mais avec un titre plutôt similaire à "jxl 0.10 : Google tend l'autre joue".
Lecture très intéressante et on y apprend plein de trucs assez intéressants (je conseille fortement la lecture) :
* v0.10 ameliore la vitesse d'encodage et réduit l'utilisation mémoire (surtout en sans perte)
* confirmation que jxl est le meilleur format dans tous les cas (sauf 1 cas d'utilisation de niche pour avif) en vitesse, compression et fonctionnalités.
* Google pour vendre son avantage du webp vente un gain vis à vis du jpeg mais n'a pas utilisé le meilleur encodeur pour la comparaison et utilise aussi une métrique dépréciée qui fausse l'interprétation.
* un nouvel encodeur "jpegli" a été écrit en utilisant des avancées de jxl qui produit des jpeg de plus petite taille que webp.
Mon ressenti du seul point négatif de jxl: difficile de déterminer les bons paramètres d'encodage suivant l'utilisation cible.
Si on veut parler d'efficacité c'est dvorak et bépo qu'il faut aller regarder
Apparemment il y a mieux: "Ergo‑L est meilleur que Bépo pour le Français, meilleur que Dvorak pour l’Anglais et meilleur que Qwerty pour la programmation !" https://ergol.org/
Moi, j'ai eu quelques soucis ;)
Il y a 2 façons de faire la caractère ^ sur un clavier azerty.
J'avais l'habitude de le faire d'une des 2 façons et j'ai appris à la faire de l'autre façon (altgr+9) car la 1ère façon (+espace) faisait freezer complètement (impossible de récupérer) ma machine lors du login pour une session KDE il y a quelques années. Je ne sais pas si c'est toujours le cas.
Vu que tu rajoutes un sel qui peut être déduit du site cela n'apporte aucune sécurité supplémentaire.
Oui et non ;)
Le but d'un sel est d'invalider le plus possible l'usage de rainbow table (valeurs déjà pré-calculées par l'attaquant avant de vouloir s'attaquer au craquage de ton mot de passe)
Que la valeur du sel soit connue n’empêche pas que cela invalide un bonne partie des valeurs de ces rainbows tables.
Et plus les valeurs de sels sont grandes et aléatoires, plus ça a de chance d'invalider une partie de ces rainbow tables.
C'est pourquoi outre le domaine du site web, je conseille très fortement, comme il ne peut pas générer un sel aléatoire car c'est l'opposé du but recherché par son outils, de quand même concaténer un sel constant assez long (plus il est long, mieux c'est).
Si il peut le conserver secret, c'est mieux, bien évidemment mais default il peut être publique.
Et je peux ajouter (car j'ai été suis un contributeurs de UniquePasswordBuilder. Coucou Grégory !) que sha256 est plutôt un mauvais choix pour hasher un mot de passe car cette fonction est plutôt optimisée pour utiliser le moins de ressources possibles (mémoire et cpu) et n'est pas idéale contre le brute force.
C'est pourquoi on a ajouté le support de argon2 qui lui est spécifiquement fait pour être lent et nécessiter pas mal de mémoire.
# Étrange
Posté par cosmocat . En réponse au lien Joshua Strobl propose à Fedora de remplacer GNOME par Plasma par défaut. Évalué à 3 (+1/-0).
Cette information me laisse un peu pantois quand on sait que la proposition a été faite le 1er avril et que l'on sait que fedora est très lié à Gnome (à travers RedHat)
Pourtant la proposition a l'air plutôt bien argumentée (disclamer: j'ai pas tout lu en détails)
Mais malgré tous les efforts que RedHat met dans Gnome et autres financement, j'avais cru comprendre que Plasma est peut-être globalement plus utilisé globalement (d’ailleurs, on a quelques chiffres "plutôt" fiables sur le sujet --même si je sais qu'avec l'open-source, c'est assez compliqué de savoir…--?)
En tout cas, ça fait un peu de pub à Plasma et ça a le mérite de lancer une discussion (troll? 88 commentaires sur Phoronix sur le sujet à cette heur ci: https://www.phoronix.com/news/Fedora-Change-KDE-Default-Prop )
[^] # Re: Rappel
Posté par cosmocat . En réponse au lien Google's Jpegli Offers ~35% Compression Improvement For High Quality JPEGs. Évalué à 6 (+4/-0).
En ce qui concerne la compression avec perte (lossy) de webp, si l'on en juge par la phrase:
et le fait que Google a utilisé une vieille (mauvaise?) métrique pour évaluer la qualité de WebP et qui fausse les résultats, si on applique les 2 raisons avancées par Google pour virer jxl de Chrome (cf https://www.phoronix.com/news/Chrome-Dropping-JPEG-XL-Reasons):
on arrive à la conclusion que:
sûrement que webp lossy n'aurait jamais dû être un format inclus dans les navigateurs.
Surtout quand on voit le support de ce format loin d'être universel longtemps après son introduction.
Le format jxl, vu toutes les fonctionnalités offertes et l'adoption, pourrait être le format universel pour quasiment tous les usages pour tourner la pages des nombreux formats plus ou moins bon actuellement utilisés.
Seulement il y a la décision de Google/Chrome qui met un gros caillou dans l'engrenage :(
# Rappel
Posté par cosmocat . En réponse au lien Google's Jpegli Offers ~35% Compression Improvement For High Quality JPEGs. Évalué à 5 (+3/-0).
Encoder jpegli qui faisait parti des codecs comparés dans cet article sur jxl:
https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front#the_lossy_pareto_front
[^] # Re: VLC pour Android n'a pas été mis à jour depuis des mois, tout court
Posté par cosmocat . En réponse au lien Why VLC for Android has not been updated in months on the Play Store - N. POMEPUY, via sebsauvage. Évalué à 2 (+0/-0).
Quand j'ajoute le répertoire contenant tous les sous-repertoires ayant des fichiers musicaux, après validation il me dit "no music found".
Et j'ai bien vérifié que l'application à accès au stockage…
Et quand j'essaie le mode 'exclure' il trouve quelques fichiers mais aucun de ce répertoire.
Je ne vois pas de fichier '.nomedia' qui pourrait causer le problème.
Pour essayer de comprendre, j'ai copié un fichier en dehors de ce répertoire (le répertoire 'Music' d'Android) et le fichier est détecté.
Donc l'application a un problème avec ce répertoire spécifiquement fait pour mettre la musique 🤯🤔
[^] # Re: VLC pour Android n'a pas été mis à jour depuis des mois, tout court
Posté par cosmocat . En réponse au lien Why VLC for Android has not been updated in months on the Play Store - N. POMEPUY, via sebsauvage. Évalué à 3 (+1/-0).
J'ai lu plusieurs fois quelqu'un parlant de Auxio. J'ai essayé plusieurs fois et je comprend vraiment pas l'ergonomie du truc où alors y'a un bug car j'ai jamais réussi à lui faire découvrir la musique stockée sur le support de stockage (avec les nombreux autres lecteurs, j'ai pas de problème…)
# Sur Mastodon
Posté par cosmocat . En réponse au lien Massive mapillary takeout for panoramax. Évalué à 3 (+1/-0).
Le même appel fait sur Mastodon (si vous trouvez plus facile d'y donner les informations demandées):
https://mastodon.cipherbliss.com/@tykayn/112122715721729214
# Bonheur et salaire max
Posté par cosmocat . En réponse au lien Ça représente quoi, « un milliard d'euros » 💶.....🤔. Évalué à 8 (+6/-0).
Un prix Nobel avait évalué dans une étude que le bonheur augmentait jusqu'à un salaire max d'environ 75k€/an.
On peut donc imaginer, en prenant assez large, qu'une personne ayant gagné 10M€ soit un peu plus l'équivalent de cette somme sur une grosse espérance de vie de 100ans ne devrait pas gagner plus et que donc on pourrait légiférer pour qu'une personne ne gagne pas plus sur l'ensemble de sa vie.
Qu'elle aille en profiter ensuite !
[^] # Re: Pourquoi fournir un lien sur LinkedIn ?
Posté par cosmocat . En réponse au lien Ça représente quoi, « un milliard d'euros » 💶.....🤔. Évalué à 2 (+1/-1).
Je me demande même si ce lien ne serait pas mieux: https://redirect.invidious.io/watch?v=o_9Y_F3f_NA
[^] # Re: Pourquoi fournir un lien sur LinkedIn ?
Posté par cosmocat . En réponse au lien Ça représente quoi, « un milliard d'euros » 💶.....🤔. Évalué à 4 (+4/-2).
Quitte à partager un lien, je préfère que ce soit un lien invidious (comme ça ceux qui veulent vraiment aller sur YouTube peuvent y aller facilement et pour les autres, on ne les obligent pas à être pisté et à voir de la publicité) : https://invidious.hostux.net/watch?v=o_9Y_F3f_NA
[^] # Re: À n'y rien comprendre
Posté par cosmocat . En réponse au lien JPEG XL and the Pareto Front. Évalué à 3 (+1/-0).
Créé par l'équipe jxl de Google et disponible avec les binaires de jxl
[^] # Re: Merci et qualité des ingrédients
Posté par cosmocat . En réponse à la dépêche Open Food Facts : récit d’un contributeur. Évalué à 3 (+1/-0).
Un article sur le nutriscore que j'ai trouvé interressant: https://www.liberation.fr/forums/les-lobbies-utilisent-les-memes-strategies-avec-lalcool-la-securite-routiere-ou-le-tabac-20240306_BMJI74ELYZHEBNGWY4DSWO7JMA/
[^] # Re: Je vais les tester bientôt j'imagine.
Posté par cosmocat . En réponse à la dépêche Version 4.0 pour GCompris. Évalué à 2 (+0/-0).
Merci pour le bug de la v4 que tu as fixé rapidement!
[^] # Re: Excellente dépêche.
Posté par cosmocat . En réponse à la dépêche Open Food Facts : récit d’un contributeur. Évalué à 4 (+2/-0).
Et peut-être la précision: "killiweb" c'est yuka ou pas?
# Excellente dépêche.
Posté par cosmocat . En réponse à la dépêche Open Food Facts : récit d’un contributeur. Évalué à 7 (+5/-0). Dernière modification le 07 mars 2024 à 13:06.
Merci pour cette excellente dépêche.
Peut-être serait-il bien de rajouter le lien vers "Hunger Games" ( https://hunger.openfoodfacts.org/ ), là ou c'est évoqué (mieux) ou avec les autres liens…
# Ubuntu
Posté par cosmocat . En réponse au lien JPEG XL and the Pareto Front. Évalué à 5 (+3/-0).
Sujet un peu lié : Ubuntu 24.04 LTS ne supportera pas jxl par défaut 😕
https://www.phoronix.com/news/Ubuntu-24.04-No-JPEG-XL
[^] # Re: À n'y rien comprendre
Posté par cosmocat . En réponse au lien JPEG XL and the Pareto Front. Évalué à 6 (+4/-0).
Je voulais poster ce lien mais avec un titre plutôt similaire à "jxl 0.10 : Google tend l'autre joue".
Lecture très intéressante et on y apprend plein de trucs assez intéressants (je conseille fortement la lecture) :
* v0.10 ameliore la vitesse d'encodage et réduit l'utilisation mémoire (surtout en sans perte)
* confirmation que jxl est le meilleur format dans tous les cas (sauf 1 cas d'utilisation de niche pour avif) en vitesse, compression et fonctionnalités.
* Google pour vendre son avantage du webp vente un gain vis à vis du jpeg mais n'a pas utilisé le meilleur encodeur pour la comparaison et utilise aussi une métrique dépréciée qui fausse l'interprétation.
* un nouvel encodeur "jpegli" a été écrit en utilisant des avancées de jxl qui produit des jpeg de plus petite taille que webp.
Mon ressenti du seul point négatif de jxl: difficile de déterminer les bons paramètres d'encodage suivant l'utilisation cible.
[^] # Re: Mon expérience
Posté par cosmocat . En réponse au journal JPEG XL ne fait pas consensus au sein de l'union des vendeurs de navigateurs. Évalué à 4 (+2/-0).
Le version 0.10 juste sortie est donc pour to:
https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front
# ça ressemble un peu...
Posté par cosmocat . En réponse au lien « Serving my blog posts as Linux manual pages ». Évalué à 3 (+1/-0).
au but du protocole Gemini et son format le "Gemtext" (syntax markdown un peu simplifiée).
# Juste pour être exhaustif
Posté par cosmocat . En réponse au journal Générer des images vectorielles procédurales avec des technologies des années 2000. Évalué à 4 (+2/-0).
…car pas sûr que ça convienne mais tu n'as pas cité Mermaid pour générer des SVGs:
https://github.com/mermaid-js/mermaid
http://mermaid.js.org/#/
Qui doit pouvoir être utilisé en ligne de commande:
https://github.com/mermaid-js/mermaid-cli
[^] # Re: Caractère spécial
Posté par cosmocat . En réponse au journal Mon gestionnaire de mots de passe, en 50 lignes de HTML. Évalué à 2 (+0/-0).
Apparemment il y a mieux: "Ergo‑L est meilleur que Bépo pour le Français, meilleur que Dvorak pour l’Anglais et meilleur que Qwerty pour la programmation !"
https://ergol.org/
[^] # Re: Il a fait chaises bien et d'autres...
Posté par cosmocat . En réponse au lien Alain Dorval, voix emblématique de Rocky et Rambo, bronsonisé. Évalué à 2 (+0/-0).
Oui, tapé sur un smartphone, et je m'en suis aperçu qu'après la fin du délais de possibilité de modification…
# Il a fait chaises bien et d'autres...
Posté par cosmocat . En réponse au lien Alain Dorval, voix emblématique de Rocky et Rambo, bronsonisé. Évalué à 0 (+0/-2).
Il est le père d'Aurore Bergé.
[^] # Re: Caractère spécial
Posté par cosmocat . En réponse au journal Mon gestionnaire de mots de passe, en 50 lignes de HTML. Évalué à 2 (+0/-0).
Moi, j'ai eu quelques soucis ;)
Il y a 2 façons de faire la caractère ^ sur un clavier azerty.
J'avais l'habitude de le faire d'une des 2 façons et j'ai appris à la faire de l'autre façon (altgr+9) car la 1ère façon (+espace) faisait freezer complètement (impossible de récupérer) ma machine lors du login pour une session KDE il y a quelques années. Je ne sais pas si c'est toujours le cas.
[^] # Re: C'est alléchant mais
Posté par cosmocat . En réponse au journal Mon gestionnaire de mots de passe, en 50 lignes de HTML. Évalué à 7 (+6/-1).
Oui et non ;)
Le but d'un sel est d'invalider le plus possible l'usage de rainbow table (valeurs déjà pré-calculées par l'attaquant avant de vouloir s'attaquer au craquage de ton mot de passe)
Que la valeur du sel soit connue n’empêche pas que cela invalide un bonne partie des valeurs de ces rainbows tables.
Et plus les valeurs de sels sont grandes et aléatoires, plus ça a de chance d'invalider une partie de ces rainbow tables.
C'est pourquoi outre le domaine du site web, je conseille très fortement, comme il ne peut pas générer un sel aléatoire car c'est l'opposé du but recherché par son outils, de quand même concaténer un sel constant assez long (plus il est long, mieux c'est).
Si il peut le conserver secret, c'est mieux, bien évidemment mais default il peut être publique.
[^] # Re: Bonne idée !
Posté par cosmocat . En réponse au journal Mon gestionnaire de mots de passe, en 50 lignes de HTML. Évalué à 7 (+5/-0).
Et je peux ajouter (car j'ai été suis un contributeurs de UniquePasswordBuilder. Coucou Grégory !) que sha256 est plutôt un mauvais choix pour hasher un mot de passe car cette fonction est plutôt optimisée pour utiliser le moins de ressources possibles (mémoire et cpu) et n'est pas idéale contre le brute force.
C'est pourquoi on a ajouté le support de argon2 qui lui est spécifiquement fait pour être lent et nécessiter pas mal de mémoire.