cosmocat a écrit 2098 commentaires

…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:

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)

Si je comprend bien ta fonction gitmaster(), c'est pour synchroniser la branche master/main sur laquelle tu ne travaille pas (bonne pratique importante pour le code suivant) avec upstream.

Si cela est le cas, tu peux le faire sans faire un checkout (et donc de façon plus pratique):

# Fetch from upstream
git fetch upstream
# get hash of upstream/master
hash="$(git rev-parse upstream/master)"
# update 'master' without doing a checkout
git push . "$hash:refs/heads/master"
# push to origin
git push origin master

Toi, t'as pas testé le nouvel environnement de bureau qui vient de sortir.

Y'en a presque plus de nouveaux que de lib Javascripts….

Avec mes recherches, j’ai découvert que Linus avait contribué à ce logiciel.

Il l'a surtout créé lors d'un temps-mort en 2011 dans le développement du noyau.

A bit of Subsurface history

In fall of 2011, when a forced lull in kernel development gave him an opportunity to start on a new endeavor, Linus Torvalds decided to tackle his frustration with the lack of decent divelog software on Linux.

Par contre, je ne me rappelle pas à quoi ce temps mort était dû…