Glandos a écrit 1433 commentaires

https://nitter.fdn.fr/MattAudibert/status/1589619954764349441#m

Dernière question en suspens: s'agit-il d'une atteinte au droit de ne pas s'auto incriminer ?
Pour le Conseil constitutionnel et la Cour de cassation ce n'est pas le cas.
La CEDH est saisie.

A priori, les gens du milieu ne sont pas sûrs et certains.

Je rajouterai que les syndicats allemands sont "réalistes", font grève pour acter un énorme différent et non pas pour commencer une négociation, et qu'ils ont le soutien des salariés.

Si j'ai bien compris ce que m'ont dit mes collègues Allemands, les syndicats ne peuvent pas représenter (et défendre) des salariés qui ne leurs sont pas affiliés.
Résultat : la grande majorité des employés est syndiquée. Et quelque part, ça force les gens à croire, s'investir, et comprendre les actions de leur syndicat. Et ça contraint le syndicat à être ce qu'il devrait être : une instance de représentation des employés.

J'ai pas beaucoup d'expérience, mais dans ma boîte, les syndicats parlent souvent pour eux-mêmes, pour faire du bruit. OK, ils défendent le statut des employés, y a plein de bons cas d'école aussi, mais malgré tout, ça reste une lutte entre la direction et les syndicats. C'est fatigant.

Pour ceux qui, comme moi, pensaient que le droit de ne pas s'incriminer était incompatible avec ce délit, et bien c'est faux.

Si j'ai bien compris l'en-tête de cet article : https://www.dalloz-actualite.fr/essentiel/droit-de-ne-pas-s-auto-incriminer-un-droit-aux-contours-flous c'était déjà jugé en 2009.

Et pour le droit suisse, on a https://www.penalex.ch/jurisprudence/droit-de-ne-pas-sauto-incriminer-vs-mesures-de-contrainte/ qui conclut :

On retient en substance de cet arrêt que le droit de ne pas s’auto-incriminer ne vaut que pour des moyens de preuve qui n’existent pas encore au moment où la contrainte est exercée (dépositions futures, déterminations à venir, …). En revanche, il est admissible de mettre en oeuvre des mesures de contrainte, même à l’encontre de personnes pouvant se prévaloir du droit à ne pas s’auto-incriminer, lorsqu’il s’agit de collecter des moyens de preuve qui existaient déjà avant que la contrainte soit exercée.

Donc je dirais, au pif, de ne pas le faire sans avoir d'avocat d'abord. Mais il va surement dire qu'il faut le faire :)

Dans How VCs work > 3. Credential verification

It obtains the Subject and Issuer public keys from a Verifiable Data Registry.

Voilà. En effet, il faut faire confiance à un registre centralisé. Donc oui, ça ne semble qu'un joli emballage de ce qui se fait déjà.

Après, c'est auth0, c'est leur cœur de métier :)

Alors, suite à mon journal sur JPEG-XL, je suis tombé sur une comparaison des formats sur https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg

Attention, c'est écrit par les gens qui font JPEG-XL. Donc oui, ils prêchent quand même pour leur paroisse, mais la comparaison me semble honnête.

Et les limitations m'ont l'air franchement bloquantes. Surtout sur les dimensions. Mince quoi.

On digresse, mais oui, j'ai pas compris Wikipédia. Ceci dit, je ne l'ai pas activé justement.
Et pour les instances pas disponibles… Oui, c'est pareil, j'ai mis une instance Nitter (pour Twitter) et une instance Piped (pour YouTube), parce que sinon, c'est très chiant.

Allez, je peux officiellement lever mon rideau : ça sent la mauvaise foi.

La réponse sur le suivi de ticket par un membre de l'équipe Chromium : https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84

We will be removing the JPEG XL code and flag from Chromium for the following reasons:
- Experimental flags and code should not remain indefinitely
- 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
- By removing the flag and the code in M110, it reduces the maintenance burden and allows us to focus on improving existing formats in Chrome

Sachant que pour avoir expérimenté AVIF, c'est très bien, mais le temps de décodage est visiblement lent sur une page. Et y a pas de décodage progressif. Et pour faire des grosses images (plus de 8193×4320), c'est de la mosaïque, avec des effets de bords (voir https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg#limitations).

Je sais que Jon Sneyers défend sa soupe. C'est juste normal. Mais je dois avouer qu'il le fait de manière posée et objective, autrement dit : « professionnelle ». Il a d'ailleurs répondu dans le ticket : https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c101

Le temps d'encodage pourrait ne pas être un argument (on encode qu'une seule fois), mais même ça, ça donne l'avantage à JPEG-XL.

Il y a peut-être un **vrai* problème à JPEG-XL, mais il ne semble pas technique : brevet, conflit d'intérêt, produit concurrent, etc.

Le client Nitter de FDN est ton ami : https://nitter.fdn.fr/jonsneyers

Et LibRedirect fait ça tout seul : https://addons.mozilla.org/fr/firefox/addon/libredirect/

OK, ça a l'air… euh… mieux ?

Mais là, bon, les inconvénients me semblent simplement énormes :

• Pas de délégation. Donc les gens à qui je fais confiance (ma conjointe, mes enfants) doivent utiliser mon appareil. Rien à voir avec une organisation Bitwarden (et des mots de passe généré à 40 caractères) ou équivalent.
• L'implémentation a l'air incroyablement complexe à faire. Évidemment, y aura des bibliothèques, mais ça a l'air pire que OAuth :)
• Comment on fait pour être « anonyme » ? C'est sûrement possible, mais j'ai pas compris.

Je sais pas s'ils ont choisi. C'est un fork de Gogs, qui était sous licence MIT.

Bah, c'est pas parce que des exemples nombreux de foirages existent que Gitea va suivre la même route. Par contre, autant gagner de l'argent avec du support ou de l'hébergement, ça me va, autant :

An enhanced enterprise version

Là je sens que ça va mal finir… Ça va finir par mettre des fonctionnalités de manière arbitraire dans une version payante :( Enfin, j'espère être pessimiste, tout simplement.

Moi j'ai un problème conceptuel avec Snap.

Quand j'ai besoin de recompiler un paquet Debian pour faire un petit changement, je peux. C'est pas facile, d'ailleurs, je le fais pas souvent, mais je peux. Le système ne râle pas quand je l'installe. Apparemment, avec snap, les paquets doivent être signés, donc il faut rajouter --dangerous.

Et si je veux distribuer des paquets snap à d'autres personnes, et qu'ils puissent avoir des mises-à-jour, il n'est pas possible de passer par autre chose que le magasin centralisé de Canonical. C'est de la perte de liberté contre un peu de sécurité. Les magasins centralisés existent déjà (packages.debian.org est centralisé, je lui fais confiance), mais si je veux, je peux faire confiance à quelqu'un d'autre. Pas avec snap, c'est donc une sorte de privation.

C'est pas vraiment le cas d'utilisation de tous les logiciels là non plus.

Et puis, je comprends pas un truc. L'article parlant du choix de Go vs C/C++ date … d'avril 2022 : https://stackoverflow.blog/2022/04/04/comparing-go-vs-c-in-embedded-applications/
Et 9 mois plus tard, on réécrit tout dans un autre langage ? Ou alors l'article original n'est paru que longtemps après le choix de Go ?

Bon, le titre du lien (sur LinuxFR) est un peu aguicheur-mensonger, non ? ;)

Sinon, je suis impressionné par le travail de Bellingcat. L'article est trop long pour que j'aie pris le temps de le lire, mais y a du gros déballage.

Et en même temps… c'est si facile de trouver des infos sur les gens comme ça ? Ça ne cessera de me surprendre :)

Allez, je peux pas dire que j'apprécie franchement la forme de la vidéo, qui reprend certains code du FUD. C'est dommage, mais je ne suis pas un communiquant, donc je ne peux pas faire mieux.

Par contre, je peux diffuser Tournesol, vu que sa vidéo y est déjà https://tournesol.app/entities/yt:IVqXKP91L4E Et plutôt bien référencée.

Car oui, je suis déjà un convaincu. J'ai passé tellement de temps à désactiver l'auto-apprentissage de mon smartphone « offert » par le boulot que je ne comprends pas que ça soit actif par défaut.

Hé ben c'est vachement bien fait.

J'ai très souvent la déception de découvrir des graphiques que je pourrais mieux réaliser avec une vue dans Grafana, mais là… non je crois pas. C'est fait par région, par type d'énergie, par date, c'est sympa.

En parlant de support, j'avoue avoir du mal avec la demande de support de version d'OS que plus personne ne maintient, donc sans doute bien troué, donc pas à conseiller pour une app bancaire.

Certes. Mais quand tu n'as pas le choix de mettre à jour ton OS parce que le vendeur ne veut pas le faire, c'est un problème que tu ne peux pas résoudre.

Ça me paraît un pré-requis très contraignant. OK, Android 10 est sorti il y a 3 ans (septembre 2019 d'après Wikipédia). Mais il me semble que les appareils ne sont pas mis à jour tout de suite. Et encore moins supportés, parfois même par du matériel sorti en 2019. Trois ans, c'est un peu que dalle…

Surtout qu'on parle de banques. Qui demandent un mot de passe de longueur fixe avec un jeu de caractères de longueur 10.

Personne ne fait aucun lien, j'imagine que c'est https://fr.wikipedia.org/wiki/Site_Reliability_Engineering ?

Personnellement, je découvre le terme.

Ça faisait tellement longtemps que j'ai plus touché à la configuration que j'avais oublié…
De fait, c'est une option : Configuration > Articles > Grouper par flux: Regroupe les flux multiples selon le flux d’origine

Démo vidéo, valable 1 mois : https://dl.antipoul.fr/f.php?h=05W2eu_O&p=1

Oui, j'ai dû moi-même participer au bordel sur la démo :) Pour ce qui est de la densité, j'avoue avoir été de mauvaise foi, c'est facilement réglable. D'ailleurs, sur TT-RSS, j'ai moi-même fait un peu de CSS.

Pour l'affichage regroupé par source, je trouve que, pour moi (j'insiste, ce n'est pas le besoin de tout le monde), j'ai besoin de voir tous les titres disponibles, regroupés par sources. Quand je lis des titres, je suis dans une certaine « configuration mentale » parmi :
- titres internationaux / politiques
- blog bd fun
- sites informatiques
- nouveautés logicielles

Si c'est mélangé, je dois plus me concentrer. Et si je dois cliquer sur chacune des catégorie, je me fais mal aux mains. Je suis chiant. Et puis bon, y a plusieurs logiciels qui existent, tous ne peuvent pas remplir les besoins de tout le monde :)

C'est vrai, c'est mieux. Bon, ça m'affiche « que » 9 titres, parce que y a l'entête global, le résumé de chaque titre (moi je veux QUE le titre, j'aime bien condenser).

Et puis surtout, les sources sont mélangées. Je sais pas pourquoi, je dois être bizarre, j'aime bien lire par source, mais les voir toutes sur la même page. Et ne pas avoir à cliquer sur chacune des catégories, une par une. Là, c'est juste trié par date, sans regroupement possible. Ou alors j'ai mal vu ?

Ça tombe bien, ils ont l'air de te rendre la pareille : https://freshrss.github.io/FreshRSS/en/users/03_Main_view.html#partial-update ;)

Je suis utilisateur de TT-RSS depuis… je sais pas, mais longtemps.

J'ai regardé toutes les alternatives Web, parce que je n'ai pas de smartphones, donc pas d'application (et quand bien même, un lecteur de flux RSS, c'est fait pour le Web, ça devrait marcher dans un navigateur, même mobile, au pire PWA, bref, je m'égare).

J'ai cherché plusieurs fois à quitter TT-RSS, notamment parce que… et bien le développeur principal n’est pas très sympa. Et je reste poli.

Mais finalement, aucun lecteur ne fait la vue combinée : une vue qui n'affiche que les titres, regroupés par origine, puis trié par date dans chaque groupe. Là ce que je vois dans FreshRSS, c'est une vue avec le contenu complet, qui oblige à faire défiler la page pour lire tout.

Ma routine à moi, c'est lire les titres en diagonale d'une source, si un titre m'intéresse, je clique dessus, ça l'ouvre, sinon, je clique sur « Tout marquer comme lu » (de la source), et paf, c'est fini. Et sur une seule page, je peux afficher 32 titres (je viens de compter) répartis dans 8 catégories.

S'il faut passer son temps à martyriser la molette de la souris, je suis pas chaud :)

Je comprends mieux pourquoi ça utilise encore XMLHttpRequest au lieu de fetch qui est supporté depuis au moins 5 ans partout.

Bon, ça change rien pour les sites qui veulent un peu d'interactivité, mais j'avoue, quitte à mettre du moderne léger, Svelte ferait plutôt bien le job non ? Ou alors faut forcément passer par la case packer/transpiler ?