cosmocat a écrit 2126 commentaires

On peut trouver des graphiques pour la comparaison des différentes drogues (qui semblent indiquer qu'il y a pas mal de drogues illicite qui sont moins nocives que l'alcool et le tabac):

https://en.wikipedia.org/wiki/File:Drug_danger_and_dependence-small.png

https://fr.m.wikipedia.org/wiki/Fichier:Graphe_montrant_l%27impact_n%C3%A9gatif_relatif_de_diff%C3%A9rentes_drogues_r%C3%A9cr%C3%A9atives_sur_l%27usager_et_sur_autrui.svg

https://www.bbc.com/news/uk-11660210

https://en.m.wikipedia.org/wiki/File:Rational_scale_to_assess_the_harm_of_drugs_%28mean_physical_harm_and_mean_dependence%29.svg

On peut aussi noter que 4 tomes de la série ont été nommés pour le prix Hugo ( de 2009 à 2012 https://fr.wikipedia.org/wiki/Prix_Hugo_de_la_meilleure_histoire_graphique ) donc plutôt un gage de qualité...

J'ai cru à un fake.
Mais il semble que ça existe vraiment et que le communiqué vient de leur site :facepalm:

...Invidious est encore disponible (mais pour combien de temps?):

https://yewtu.be/watch?v=vCU4xbHFb58

mais je déteste sa façon de les dire.

Peut être un indice sur sa présentation Github :

"My super-power is I hate programming, [...]"

( https://github.com/aurelienpierre )

https://yewtu.be/watch?v=j3HQSdVMUGw

https://m.youtube.com/watch?v=l44WKAtZLjI

En quelque sorte un double de https://linuxfr.org/users/anonyme/liens/introducing-incus-lxd-fork

https://bonpote.com/train-vs-avion-match-retour/

Apparemment, ça devrait être l'article d'accueil de Wikipedia ce vendredi...

C'est maintenant le cas.

https://mamot.fr/@Jules78120/110774273348356687

Apparemment, ça devrait être l'article d'accueil de Wikipedia ce vendredi...

Une source:
https://m.slashdot.org/story/416958

Mort d'un cancer du pancréas.

Il me semble que beaucoup de problèmes actuels sont liés au fait qu'on arrive pas à bien gérer les polices. Elles semblent avoir leur propre processus...

Un gars à passé 2 mois à réaliser un appareil photo dans blender pour pouvoir prendre des photos de ses modèles 3D
https://www.youtube.com/watch?v=YE9rEQAGpLw&t=8

Inutile mais impressionnant !

Surle sujet : https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLjhlXrk_5W2nJBDqDAMbhe8v8/mobilepresent?pli=1#slide=id.gde87dfbe27_0_43

ça va pas répondre à ta question mais ça va te donner quelques indices:
https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLjhlXrk_5W2nJBDqDAMbhe8v8/edit#slide=id.g99b14c4dfb_0_7

https://cloudinary.com/blog/contemplating-codec-comparisons#decoding_speed

https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs#computational_complexity

Une présentation assez intéressante de Jpeg-XL:
https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLjhlXrk_5W2nJBDqDAMbhe8v8/edit#slide=id.gae1d3c10a0_0_17

C'est une des killer feature pour le Web (avec le progressive decoding): jpeg-xl est capable de faire une conversion sans perte depuis un jpeg avec des gains de 20% (et donc on peut revenir vers le jpeg d'origine).

https://cloudinary.com/blog/legacy_and_transition_creating_a_new_universal_image_codec#legacy_friendly_jpeg_xl

Donc c'est un gros plus pour toutes les images existantes sur le web qu'il serait très facile à convertir sans perte de qualité.

Rappel: Une réponse à leur choix
https://cloudinary.com/blog/the-case-for-jpeg-xl

Espérons qu'ils y reviendront si tout le monde s'y met.

Après leur décision, des personnes appartenant à des "entreprises" telles que Adobe, Facebook, Shopify, The Guardian, FFmpeg, nvidia, Intel,... ont posté des commentaires sur le bug tracker de Chrome ( https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 ) qu'ils attendaient que le codec soit promu stable plutôt que retiré car ils voulaient l'utiliser.

Depuis, pas de réponse de la part de Google...
Apparemment, celui qui a pris la décision de retirer le support dans Chrome serait un des développeur de Webp.

Je ne connais la chronologie mais peut-être était-ce aussi car Webp2 était prévu mais Google a annoncé que Webp2 ne sera pas publié...

Mozilla a décidé d'être neutre sur le sujet :(

Apple a annoncé le support dans Safari donc on espère que ça va faire pencher la balance et accélérer l'adoption...

Liens annexes:
* Une discussion sur jpex-xl pour une gallery open-source sur Android(avec des infos)
* https://jpegxl.info/
* Progressive Jpeg-xl (impressionant)

Si tu aimes bien les images:

Comparaison des formats

Y'a un article maintenant sur le sujet: https://goodtech.info/toolinux-devient-goodtech-info/

🤞

Y'a un petit paragraphe intéressant à ce sujet dans cet article:

https://cloudinary.com/blog/the-case-for-jpeg-xl

En gros, son point de vue c'est que l'intégration était complète et finie. Et que la "maintenance et dette technique" évoqué par Google/Chrome, c'est juste augmenter le numéro de version de la dépendance de temps en temps...

(donc un peu ou beaucoup de mauvaise foi)

D'après ce tweet, c'est même pire, les 3 lignes seraient fermées depuis 3 ans donc à part la pub médiatique, la mesure n'aura aucun effet:

https://twitter.com/Lustublog/status/1661230572079808513

'ai pas trouvé la description du point dans la doc de git push, j'imagine que ça représente le "remote" local ?

Comme remote, on peut donner l'url d'un depot qui peut être un chemin local. Ici, on utilise le répertoire courant '.' comme "remote" et on fait donc un push dans notre propre dépot local pour mettre à jour une ref de branche avec le hash d'un commit.

Mon commentaire était pour indiquer qu'on peut détourner la commande 'push' pour modifier/mettre à jour une branche locale sans être obligé de faire un checkout (qui peut être pénible et lent si la branche courante a pas mal divergé) et que cette solution (que peu connaissent), qui peut être adaptée pour gérer ton 2ème cas, est beaucoup plus performante car l'update de la branche est instantané (seul le fetch et push final prennent du temps) et a moins de chance d'échouer (car on a pas à gérer les cas particuliers du checkout --changes local, merge conflicts,... --)

Note: la màj de master echoue si ce n'est pas un fast-forward (et c'est ce qu'on veut)