cosmocat a écrit 2091 commentaires

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

Y'avait eu une présentation du portage (aidé par au moins une personne de KDE si je me souviens bien) au FOSDEM et donc y'a une vidéo sur le sujet:
https://www.youtube.com/watch?v=SJZIL0uCnt8

Je me souviens de pas grand chose sauf que le dev kde disait qu'il fallait faire comprendre à Linus que c'était pas trop grave si des bouts de codes de l'interface graphique était pas optimisé en terme de performance car il trouvait cela inacceptable.

Au niveau de la migration gtk/qt, le résumé de la video:

As subsurface evolved from a Gtk Application to a Qt one, cutting a quarter of the codebase while still gaining new functionalities, a new development tproposal was done: "How do we get this desktop based application and run it on mobile, on a unified codebase?"

La commodité sera notre perte.
J'avais lu un article parfait sur le sujet mais n'ai jamais réussi à le retrouver. En voici donc d'autres sur le sujet qui sont pas trop mal (en anglais) :

https://theminimalistvegan.com/convenience-culture/

https://medium.com/the-point-of-view/convenience-is-killing-us-all-a34ecf0f8591

https://www.theinertia.com/environment/how-convenience-is-ruining-the-planet-an-underlying-truth-of-the-modern-world/

Les anglophones semblent avoir une expression pour expliquer le problème 'convenience culture' qui cherche à rendre tout plus pratique dans tous les domaines et donc on commence à peine à percevoir tous les effets négatifs…

Je préfère également largement une Progressive Web Apps (PWA) au lieu d'une application mais un truc qui m'énerve c'est qu'avec Firefox (sur Android) tu ne peux pas avoir une icône dans le tiroir d'applications (comme une application normale).

En cherchant un peu, j'ai vu que cette limitation n'existe pas avec Chrome (que je ne veux pas utiliser pour d'étranges raisons…..)

PS: surtout que les PWA ça évite de renforcer le monopole des marchés d'applications et ça permet de mutualiser les coûts (1 appli pour toutes les plates-formes). Par contre Apple traîne les pieds, y'a moins d'API et pas de monetisation…

Merci.

Ouais, avec la réponse complexe sur les manettes j'ai pas réussi à comprendre quelle manette est en photo finalement… (Il faudrait peut-être une légende)

J'ai survolé la dépêche. J'ai rien compris. Mais c'est beau.

Que j'aurais aimé que les banques construisent un système de paiement sur internet basé sur les virements avec un identifiant de compte 'public' n'acceptant que des transactions de type credit…

De suite, toute cette classe de fraude ne serait pas possible…