Glandos a écrit 1364 commentaires

  • [^] # Re: Réfutation? Ou absolution...

    Posté par  . En réponse au lien A Rebuttal to Scaling Mastodon is Impossible. Évalué à 6.

    Se demander pourquoi ce qqun n'a pas mis autant ou moins dans Mastodon.

    Je suis pas expert financier. Mais c'est certainement pas pour la qualité technique de Twitter :)

  • [^] # Re: Switch @ ~

    Posté par  . En réponse au journal Un switch beaucoup trop à l'écoute .... Évalué à 3.

    Je plussoie ce genre de solutions.
    Un switch basique, c'est très bien. Quand on veut faire du managé, chez soit, finalement, un vrai ordinateur avec l'OS qu'on veut c'est mieux.

  • [^] # Re: Implémentation dans Linux ?

    Posté par  . En réponse au lien Éloge de Plan 9, par Drew DeVault. Évalué à 2.

    l'exemple donné me fait un retour en « Error 400 (Bad Request)!!1 » sur google.com

    J'avais la même chose, mais des fois, on a la flemme de l'écrire… C'était pas hyper pertinent non plus.

    fd=$(comm -13 <(ls /proc/$$/fd | sort) <(seq 255 | sort) | sort -g | head -1)
    

    OK. J'ai appris un truc (surtout comm).

    Par contre, ça en fait des forks:
    - 2 sous-shell pour les arguments de comm
    - 7 processus lancés pour avoir le fd
    - 2 builtin (eval + exec) et 2 processus pour le duo requête-réponse. Mais ça change pas trop d'avant.

    On va s'abstenir de lancer des perf stat là-dessus je crois :) En attendant io_uring_spawn en tout cas.

  • [^] # Re: Quand on croit aimer l'open source, mais qu'en fait on aime l'argent

    Posté par  . En réponse au lien mold linker pourrait changer de licence pour une licence non open-source. Évalué à 9.

    La vraie critique pour moi n'est pas sur le dév qui a pêché par excès de naïveté. Mais je m'accrocherais sur un autre passage :

    If they need to buy a license, that's fine, that's part of their usual business. But supporting (or giving money away to) "free" software is almost impossible. It raises too many questions at every level of management. What is the accounting item it should be categorized to? Is there any legal implication? Who can approve it in the first place? And last but not least, why do they have to do it if it's available for free?

    Je l'ai vu dans ma boîte. Tout le management achète des logiciels de merde (coucou McAffee), parce que justement, c'est payant. Y a une facture. Et ça, ça rentre dans le processus. Faire un don ça rentre pas.

    Pourtant, je suis sûr d'un truc : si ma boîte prend un virus à cause d'une faille dans McAffee, elle pourra pas en tirer un rond. Pas plus que si elle avait donné des sous à ClamAV.

    Évidemment, pour mold, il faudrait :
    - qu'il monte une boîte
    - qu'il fasse des relations commerciales pour négocier des contrats avec des fonctionnalités à intégrer en open source
    - d'autres trucs chiant d'entrepreneurs

    L'argent qui tombe tout seul, c'est un peu un rêve. Oui, parfois, je l'ai aussi.

  • [^] # Re: Implémentation dans Linux ?

    Posté par  . En réponse au lien Éloge de Plan 9, par Drew DeVault. Évalué à 3.

    Pour Hurd, mettons, mais c'est pas réaliste de booter sur un Hurd aujourd'hui…

    Ce que bash propose, c'est… pas top. Déjà, c'est que dans Bash. Si j'ai envie de le faire en Python ou en C, je vais pas lancer un bash. Ensuite, il faut choisir soi-même un numéro de descripteur de fichier, bon courage pour éviter les conflits.
    Enfin, la syntaxe à base de 3<> et de cat <&3 est particulièrement pas simple. Peut-être parce que justement, tout devrait être stocké dans une variable, dès l'ouverture du flux bidirectionnel ?

  • # Implémentation dans Linux ?

    Posté par  . En réponse au lien Éloge de Plan 9, par Drew DeVault. Évalué à 7.

    Plan 9 is much more Unix in its approach: you open /net/tcp/clone to reserve a connection, and read the connection ID from it. Then you open /net/tcp/n/ctl and write “connect 127.0.0.1!80” to it, where “n” is that connection ID. Now you can open /net/tcp/n/data and that file is a full-duplex stream. No magic syscalls, and you can trivially implement it in a shell script.

    J'avais connaissance de ça, mais je me suis toujours demandé… pourquoi personne n'avait tenté de faire un module noyau (ou espace utilisateur ?) qui fait la même chose dans Linux ? Au moins pour tenter.

    Ça existe ?

  • [^] # Re: Droit au silence / ne pas s'incriminer

    Posté par  . En réponse au journal code de déverrouillage d'un smartphone : la justice persiste, et signe. Évalué à 3.

    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.

  • [^] # Re: Tentatives d'explication

    Posté par  . En réponse au journal Pourquoi cette passion française pour les ESN?. Évalué à 10.

    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.

  • # Droit au silence / ne pas s'incriminer

    Posté par  . En réponse au journal code de déverrouillage d'un smartphone : la justice persiste, et signe. Évalué à 6.

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

  • [^] # Re: intérêt

    Posté par  . En réponse au lien Les justificatifs vérifiables : le futur des passes identitaires / sanitaires / sociaux ?. Évalué à 4.

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

  • # Grosses limitations de HEIF / AVIF

    Posté par  . En réponse au journal Digikam et HEIF. Évalué à 5.

    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.

  • [^] # Re: Je savais même pas qu'il était né, moi...

    Posté par  . En réponse au journal Vie et mort (?) de JPEG-XL. Évalué à 3.

    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.

  • # Ça sent la mauvaise foi

    Posté par  . En réponse au journal Vie et mort (?) de JPEG-XL. Évalué à 6. Dernière modification le 31 octobre 2022 à 08:26.

    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.

  • [^] # Re: Je savais même pas qu'il était né, moi...

    Posté par  . En réponse au journal Vie et mort (?) de JPEG-XL. Évalué à 3.

    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/

  • # Complexité énorme

    Posté par  . En réponse au lien Passkeys as a tool for user retention. Évalué à 2.

    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.
  • [^] # Re: "decentralized autonomous organization" ?

    Posté par  . En réponse au lien Open source sustainment and the future of Gitea . Évalué à 2.

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

  • [^] # Re: "decentralized autonomous organization" ?

    Posté par  . En réponse au lien Open source sustainment and the future of Gitea . Évalué à 4.

    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.

  • [^] # Re: "decentralized autonomous organization" ?

    Posté par  . En réponse au lien Open source sustainment and the future of Gitea . Évalué à 6.

    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.

  • [^] # Re: Pas vraiment un abandon

    Posté par  . En réponse au lien Mender abandonne le Go pour faire du C++. Évalué à 5.

    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 ?

  • # Gros travail

    Posté par  . En réponse au lien Les "télétravailleurs" derrière les attaques de missile russe en Ukraine. Évalué à 4.

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

  • # On participe ?

    Posté par  . En réponse au lien Google a empoisonné la communauté scientifique, qui amplifie maintenant sa désinformation. Évalué à 5.

    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.

  • # Bravo

    Posté par  . En réponse au lien énergies électriques / courbes de prévisions et de consommations ; sources de production.. Évalué à 7.

    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.

  • [^] # Re: Android 10 ?

    Posté par  . En réponse au journal BPCE : une seule application pour tout le groupe. Évalué à 3.

    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.

  • # Android 10 ?

    Posté par  . En réponse au journal BPCE : une seule application pour tout le groupe. Évalué à 5.

    Ç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.

  • # SRE ?

    Posté par  . En réponse au lien Comment construire un logiciel comme un SRE . Évalué à 8.

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

    Personnellement, je découvre le terme.