Glandos a écrit 1364 commentaires

Mais laissez-moi rire… Les politiques qui hurlent à la liberté d'expression, alors qu'ils ont laissé une entreprise privée s'accaparer le monopole de la diffusion de l'information.

C'est privé, c'est tant pis.

Machines need to be fuelled by data generated by humans (i.e., use cases) while trying to solve their problems. The uncertainty of our world makes infinite the number of problems humans have to handle. So machines must wait for humans to perceive the problems, generate data, train the machines, and finally solve problems.

Alors l'article est mieux que cette synthèse, puisque son auteur a même organisé un examen où il fallait utiliser ChatGPT.

Mais je trouve que sa conclusion explique très bien ce que fait ChatGPT : expliquer les problèmes déjà connus.

Via https://fr.wikipedia.org/wiki/Bulbe_copulateur#/media/Fichier:Thaida_chepu_male,_palp_morphology_cropped.jpg

L'article en parle et… tape un peu dessus, en parlant de revue « amateur ». Et de failles inhérentes au protocole.

Merci !

As a result, the Snap store now integrates with other areas of the Canonical infrastructure. So the Snap store isn’t a single thing. It’s not like this one piece of software that you can easily decouple from the rest of the machinery that powers the infrastructure at Canonical. So we can’t just pull it apart and separate it and say, “Here you go, here’s the open source Snap store.”

Bon, ça me va mieux. Mais c'est vrai que les justifications de Snap au dessus ne sont pas très convaincantes :
- Le point unique de rencontre, c'est plus facile. C'est vrai, mais c'est bien quand on peut changer le défaut. La flexibilité, c'est la base d'une distribution Linux.
- Self-contained, c'est bien quand la distribution change de version majeure. Oui, ben du coup, Snap, c'est une distribution dans une autre. Un Docker quoi… Alors pourquoi pas NixOS ?

Est-ce qu'il y a déjà eu une communication sur ce choix ?

Les clients commerciaux de Canonical s'en foutent probablement, mais pas les utilisateurs, qui ont choisi cette distribution pour le compromis libre-qui-marche-quand-même. Mais avec Snap, c'est complètement parti en cacahuète.

Personnellement, je ne comprends pas le choix de la licence. Même si c'était ouvert, ça serait probablement compliqué de lancer son magasin alternatif, alors… pourquoi ?

Je ne connaissais pas, mais c'est également bardé de pub. Et ça ne respecte pas le RGPD, puisqu'il n'est pas aussi facile de refuser le profilage que de l'accepter.

Ahah, MétéoFrance. La blague de la visualisation qui ne veut rien montrer. J'ai un écran 1920×1200 (donc c'est très haut) et voilà ce que ça donne :

via https://meteofrance.com/previsions-meteo-france/toulouse/31000

Si on prend une autre agence gouvernementale d'un pays très riche, comme la Norvège, on a :

via https://www.yr.no/en/forecast/graph/2-2972315/France/Languedoc-Roussillon-Midi-Pyr%C3%A9n%C3%A9es/Upper%20Garonne/Toulouse

Oh, et le site de Yr est responsive, en PWA. Donc pas d'appli, y a juste à dire à son navigateur mobile « d’installer » le site sur son écran d'accueil, ça marche nickel.

Y a quand même un défaut, c'est que le modèle météo pour le sud de la Loire est moyennement fiable. Et c'est que en nynorsk, bokmål ou anglais. Je peux pas vraiment leur en vouloir…

Donc des fois, je vais sur MeteoFrance, pour avoir des prévisions fiables à plus de 7 jours, mais c'est pénible : y a même pas d'URL qui pointe directement vers les prévisions à 7 ou 15 jours, il faut cliquer, lien Javascript. Les mecs, quoi, oh ! Ah, et petite cerise sur le gâteau, il n'y a aucune différence entre 7 et 15 jours par défaut. Il faut faire défiler horizontalement. Sur mon écran de 1920 pixels, le site affiche des bordures blanches de 780 pixels (max-width du conteneur principal à 1140 pixels). Je pense que le but est de rendre le site Web légèrement inutilisable.

Je ne serais pas surpris aussi que ce soit dans le cahier des charges pour une (bonne) raison, comme l'accessibilité, ou le standard X.Y.Z, mais que personne n'a fait le rapprochement avec la découverte de ces fonctionnalités.

Ou alors, des gens veulent que ça disparaisse du prochain cahier des charges, avec l'argument : « Vous voyez bien que personne ne l'utilise ! ».

Mais bon, j'ai toujours du mal à être semi-conspirationniste comme ça.

Je ne sais pas si on peut les considérer comme des réseaux sociaux, mais en soi, WhatsApp et Signal sont des réseaux app-only. Ça ne marche pas sans application.

C'est pas tout à fait vrai, techniquement, pour Signal. Des clients alternatifs existent. Mais ils ne sont que tolérés.

EDIT: Voilà, je devrais lire l'article en entier, et pas en diagonale :

Incidentally, and tangentially relatedly, Signal is not a messaging program but rather is a sketchy-as-fuck growth-at-any-cost social network. Fuck Signal too.

J'irais pas jusque là dans mon extrémisme, mais voilà, c'est dit.

https://www.plus.transformation.gouv.fr/experiences/3181461_suivi-des-actualites-par-flux-rssatom

Plus une demande par le formulaire de contact. Je n'ai reçu aucune réponse.

Ouais, c'est mis en avant dans https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c198 mais franchement, le support natif, c'est obligatoire. WASM, c'est bien, mais pour un truc vraiment utilisé, vaut mieux du natif.

Oui, ça paie mieux les failles sur les appareils personnels, justement parce qu'ils sont… personnels. Ciblés.

Avec une telle faille, les États peuvent faire dans la finesse. Une faille sous Linux, c'est sympa, mais t'as pas forcément tout, par rapport à la faille iOS qui permet de transformer le téléphone de tel ou tel dissident en espion de ses activités. Et ça, c'est plus cher.

Oui, c'est très bien zstd, c'est rapide et suffisamment efficace. LZMA fait mieux, mais au prix de beaucoup plus de CPU.

Je reprochais, comme l'a deviné mon VDD, le manque de documentation :)

Utilisateur de longue date de borg (après l'arrêt de obnam), j'avais étudié restic, mais franchement, sans la compression, c'était pas top.

Là, ça parle de compression et… c'est tout. Ça dit juste qu'on peut mettre des niveaux de compression. D'accord, mais ça utilise quoi comme algorithme de compression ?

Même la pull request n'en parle pas. J'ai dû aller lire le code pour avoir la réponse : c'est du zstd.

Bon, je vais continuer à utiliser borg :)

Afin de vérifier votre identité et sécuriser votre achat de formation, nous vous invitons à suivre la procédure suivante. Ce contrôle d’identité effectué manuellement par nos services nécessite un temps de traitement d’environ quatre semaines.

Quatre semaines. Plus le temps d'envoi du recommandé, etc.

Ohoh, bien joué pour la procédure. C'est littéralement un non choix.

4 semaines d'attente, un courrier recommandé à recevoir, pour valider un achat.

Attention, ça pique :

Un smartphone Jolla, ça va pas. Un OS libre, ça va pas non plus. Bref, pour La Poste, le pré-requis, c'est de s'enchaîner.

Après la création de Gitea Ltd., un groupe de contributeurs a été déçu de la tournure des choses et considère le transfert de propriété comme hostile, tout du moins au regard de la gouvernance.
Ils ont donc fait une lettre ouverte : https://gitea-open-letter.coding.social/ Elle est resté lettre morte.

Ils sont donc parti pour faire un soft fork. Et donc changement de nom.

Ça vient de l'esperanto Forĝejo, ça se prononce forgéio pour les francophones.

La suite… est en cours sur https://codeberg.org/Forgejo

Je valide, ça marche chez moi. Bon, je sais pas pourquoi, j'attendais que offpunk me trouve un flux RSS sur https://www.service-public.fr/particuliers/actualites mais non, il a bel et bien disparu avec le nouveau site.

Va falloir que je me coltine un scrapeur pour RSS-bridge. J'ai comme pas du tout envie.

Welcome to Offpunk!
Type `help` to get the list of available command.
- is not a valid URL to go
ON> go https://www.service-public.fr/
ERROR4: <class 'requests.exceptions.SSLError'> : HTTPSConnectionPool(host='www.service-public.fr', port=443): Max retries exceeded with url: / (Caused by SSLError(SSLError(1, '[SSL: DH_KEY_TOO_SMALL] dh key too small (_ssl.c:997)')))

HTTPSConnectionPool(host='www.service-public.fr', port=443): Max retries exceeded with url: / (Caused by SSLError(SSLError(1, '[SSL: DH_KEY_TOO_SMALL] dh key too small (_ssl.c:997)')))

C'est pas vraiment offpunk le problème là, évidemment. Dans cURL, ça marche.

Mais mince quoi, un DH_KEY_TOO_SMALL c'est quoi le principe ? Le site vient d'être refait, il a pas besoin de marcher sous IE6/WinXP ou encore Opera/Wii…

Apparemment, ça fait 10 ans que Facebook/Meta développe son client/serveur de gestion de code source, initialement à partir de Mercurial.

J'y ai vu un but double :
- Les performances en dépôt monolithique (monorepo)
- Simplifier le travail quotidien chez Facebook

Sur le deuxième point, je sais pas, mais sur le premier… Microsoft a eu une meilleur stratégie : https://devblogs.microsoft.com/devops/introducing-scalar/

Scalar est distribué avec Git, point barre. En tout cas, Facebook est suffisamment gros pour maintenir son truc tout seul.

Le bon release manager, il voit du code, il fait une release, et c'est une bonne release tu vois ?

Le bon lecteur LinuxFR, il fait un commentaire, et c'est bon commentaire.