Christophe a écrit 473 commentaires

  • [^] # Re: la goutte qui fait déborder mon vase

    Posté par  . En réponse au journal Comment je suis devenu un vacciné antivaxx.... Évalué à 10.

    Il faut quand même avoir de sacrées oeillères pour ne pas voir l'amélioration qu'a apporté le vaccin. Par où commencer ?

    • regarder les vagues pré-vaccin (avant l'été, par exemple Avril) et post-vaccin (après l'été, par exemple Août-Septembre): alors qu'on n'a même pas atteint une couverture vaccinale optimale, les hospitalisations sont déjà divisées par 2 ou 3
    • on oublie un peu l'ampleur de la vague actuelle: on 10 voire 20 fois plus de cas quotidiens que pour les vagues précédentes ! Omicron est heureusement un peu moins virulent, mais sans le vaccin on serait en confinement depuis longtemps.
    • on peut envisager un avenir moins morose: le Danemark tente le retour à une vie normale par exemple, chose absolument impensable sans le vaccin. Et oui, la 3ème dose y joue un rôle important, car elle une bien meilleure protection face à Omicron.

    Alors, non, personne n'a «remarqué» que la vaccination n'avait eu aucun effet sur l'épidémie dans les derniers mois, c'est juste une impression très biaisée.

    Pas de haine, mais juste une très grande lassitude.

  • [^] # Re: Un blog parmis tant d'autres

    Posté par  . En réponse au journal Quand le mainteneur de pkexec ignorait (ou pas) les failles potentielles. Évalué à 10.

    Sur la plupart des projets auxquels je contribue, il arrive assez régulièrement qu’un patch soit initialement ignoré, jusqu’à ce que son auteur envoie un second mail après une semaine ou deux pour dire un truc du genre « ping ! juste pour savoir si vous avez bien vu ce patch et le cas échéant ce que vous en pensez ? »

    Et après ces nombreuses contributions passées à la trappe par erreur, personne ne se dit que le process doit être amélioré ?

    C’est plus une question de disponibilités des mainteneurs qu’une question d’outil, à mon avis.

    Je ne suis pas de cet avis. Tu as deux problèmes distincts:

    • la quantité de problèmes qu'une équipe réduite pourra régler (besoin d'une relance pour pousser la priorité)
    • une visibilité de l'ensemble des problèmes (risque d'un oubli complet, besoin d'une relance pour simplement ne pas rater le patch)

    GitHub & co ne va pas régler le premier problème. Aucun process ne le pourra: quand il y a trop de boulot, il faut trier. Et encore, ce tri est bien facilité avec un système de tickets ! Donc même si la bande passante reste la même, elle est sûrement mieux utilisée.

    Par contre, le second problème est largement amélioré. Car un email, comme tu l'as dit, ça s'oublie ou se manque facilement. Le ticket, lui il reste là, dans la liste. Si des tickets plus récents sont créés puis résolus, il va redevenir plus visible.

    Pour moi il n'y a pas photo: un système de tickets est une énorme amélioration pour gérer les demandes.

  • # Un blog parmis tant d'autres

    Posté par  . En réponse au journal Quand le mainteneur de pkexec ignorait (ou pas) les failles potentielles. Évalué à 10.

    Manifestement, les mainteneurs de pkexec n'ont pas lu son blog. Et cela n'a rien de bien surprenant…

    C'est un peu dommage de se donner la peine de faire cette analyse, un billet de blog, un mail, et de ne pas se demander pourquoi il n'y a aucune réponse au mail. Mais c'est vrai que la mailing-list ne répond peut-être pas à tous les mails d'inconnus, à cause du spam…

    Fait amusant: aujourd'hui c'est via Twitter que cette information a réussi à être repérée. Et c'est vrai qu'une PR (ou MR pour Gitlab) est un peu plus visible et plus pratique !

  • [^] # Re: Méfions-nous des pourcentages...

    Posté par  . En réponse au lien Linux malware sees 35% growth during 2021 [principalement sur l'embarqué]. Évalué à 5.

    En fait, peut-être que si ?

    Lorsque tu passe de 10 à 30 alertes, et que ton voisin passe de 10 millions à 30 millions d'alertes, on peut se demander si on reste, dans l'absolu, dans un bruit de fond: les attaques augmentent en général, mais continuent de ne pas te cibler toi plus qu'avant.

    La question de savoir qui cause quoi (déploiement, robustesse, intérêt financier, méthode de remontée des problèmes, autre) reste entière. Mais ne pas se mettre des oeillères lorsqu'on analyse un problème (qui reste à définir d'ailleurs) c'est toujours bénéfique.

  • [^] # Re: Binaires statiques et conséquences

    Posté par  . En réponse au journal Une CVE dans le compilateur rust. Évalué à 5.

    j'ai du mal à voir où il pourrait faire un remove_dir_all

    oui, c'est justement une partie du problème… Comment identifier les impacts ?

  • # Binaires statiques et conséquences

    Posté par  . En réponse au journal Une CVE dans le compilateur rust. Évalué à 10.

    Bel exemple ici d'un inconvénient d'utiliser des binaires statiques (chose revenue à la mode avec Go et Rust): lorsqu'un bug est découvert dans une dépendance, il est très difficile de savoir ce qu'on doit mettre à jour.

    Alors pour les paquets d'une distribution Linux j'imagine que tout sera recompilé avec la nouvelle version de la bibliothèque standard, mais pour le reste (petits utilitaires compilés localement, situation hypothétique d'un binaire commercial qui n'est plus maintenu, etc) c'est un peu le flou artistique…

    Je trouve que c'est une saine piqûre de rappel de l'avantage d'avoir un livrable moins monolithique. En attendant, je crois qu'il ne me reste plus qu'à recompiler tous ces fameux petits utilitaires qui veulent remplacer les outils classiques (exa, fdupe, fd, ripgrep…)

  • [^] # Re: Changement de licence au passage

    Posté par  . En réponse au lien Rewriting the GNU Coreutils in Rust. Évalué à 4.

    On n'est pas dredi ? Tu es sûr ? :)

  • [^] # Re: Réaction de GitHub

    Posté par  . En réponse au lien Dev corrupts NPM libs 'colors' and 'faker' breaking thousands of apps. Évalué à 8.

    C'est la même boîte, mais ils ont (normalement…) des rôles différents. Mais ça peut expliquer en effet pourquoi ce genre de décision a été prise.

    Si GitHub lui rend l'accès à son compte, je pense que ses actions suivantes seront:
    1. sauvegarde de ses repos en local ou sur un Gitlab ou autre
    2. git push --force qui efface ses repos et les remplace par un README.

    Oui, ce serait une belle tuile. Et, oui, c'est tout à fait son droit. Il a demandé à ce qu'on forke son projet il y a déjà plus d'un an… L'écosystème NPM fait confiance à toute une pyramide de dépendances, faisant intervenir des milliers de personnes et d'entités, la plupart de parfaits inconnus. C'est extrêmement fragile par nature, on le voit régulièrement.

    Sinon c'est un peu facile aussi: le code est fourni sous licence libre, gratuitement, sans aucune garantie. Tout le monde tire dessus, personne ne veut s'en occuper (pas de fork depuis un an). Mais dès que le dev veut sonner la fin de la récré, hop on lui coupe son hébergement GitHub, qui n'a rien à voir ? Google va lui couper son mail, aussi ?

  • [^] # Re: Réaction de GitHub

    Posté par  . En réponse au lien Dev corrupts NPM libs 'colors' and 'faker' breaking thousands of apps. Évalué à 9. Dernière modification le 10 janvier 2022 à 13:47.

    Pour NPM je n'ai aucun problème avec leur réaction, qui correspond à leur rôle d'intégrateur.

    Mais GitHub ? De quelle chaîne de confiance on parle ? Ils ne sont là que pour fournir un dépôt de code, pas pour choisir si tel ou tel commit leur plaît ou non.

    Alors peut-être que GitHub, dans les conditions d'utilisation de 10km, ont une clause concernant du code "malicieux", mais ça reste tout à fait sujet à critique. Qu'est-ce qu'un code malicieux ??

    PS: au fait, l'auteur a averti que le logiciel ne serait plus maintenu à partir de novembre 2020. La chaîne de confiance auraît dû s'arrêter à ce moment là.

  • # Réaction de GitHub

    Posté par  . En réponse au lien Dev corrupts NPM libs 'colors' and 'faker' breaking thousands of apps. Évalué à 6.

    Autant la façon de faire du développeur me semble maladroite (le code est libre, ou pas ?), autant la réaction de GitHub est scandaleuse et inquiétante.

    En effet, si on en croit le développeur en question, GitHub s'est permis de susprendre son compte, car il aurait enfreint les termes du contrat… Alors qu'il n'a fait que modifier son propre code.

  • [^] # Re: Syntaxe du déclaratif et QML

    Posté par  . En réponse au lien SixtyFPS, a fresh new toolkit for graphical user interfaces. Évalué à 2. Dernière modification le 07 janvier 2022 à 20:38.

    Ok, je vois, merci pour les détails !

  • # Syntaxe du déclaratif et QML

    Posté par  . En réponse au lien SixtyFPS, a fresh new toolkit for graphical user interfaces. Évalué à 5.

    En voyant les exemples, je ne peux qu'être frappé par la similitude avec le language QML.

    Connaît-on les raisons pour lesquelles QML (ou un sous-ensemble de QML) n'a pas été directement utilisé ?

  • [^] # Re: Y'a deux sortes de sysadmins...

    Posté par  . En réponse au lien L'université de Kyoto perd 77 To de données de recherche à la suite d'une erreur de sauvegarde. Évalué à 5.

    Oui, j'ai remarqué aussi… D'ailleurs parfois on "glisse" et ça fait backspace + entrée; dans ton cas, ce serait double punition !

  • [^] # Re: Mediapart ?

    Posté par  . En réponse au lien Carte de la «presse pas pareille» (médias libres, indépendants, alternatifs…). Évalué à 8.

    Je vous trouve bien gentils avec cette carte: elle est tout simplement inutilisable. Impossible de chercher un nom, ou d'avoir la liste, légende illisible, et la plupart des logos sans lien ne sont pas lisibles.

    On n'a pas non plus accès à l'image d'origine, pourtant elle est probablement plus détaillée.

    Une mise en avant ratée pour cette «presse pas pareille», je trouve. J'espère qu'ils s'en apercevront et mettront à jour la page.

  • [^] # Re: Arte

    Posté par  . En réponse au lien Un épisode de 28 minute sur les GAFAM avec l'excellente Aurélie Jean !. Évalué à 7. Dernière modification le 02 janvier 2022 à 23:53.

    Bref, tu aides à centraliser un Internet qui l'est déjà bien trop. C'est le but des GAFAM: être l'intermédiaire par qui toute l'information passe.

    Utilisez le lien Arte !

  • [^] # Re: des liens

    Posté par  . En réponse au lien Vous aviez mis à jour log4j pour corriger log4shell ? Eh bien, il faut recommencer.. Évalué à 9.

    Ce n'est pas la même info: ici, c'est la correction de la faille qui introduit un nouveau problème.

    Il me semble tout a fait raisonnable de faire un lien dédié pour ça.

  • [^] # Re: facile ;)

    Posté par  . En réponse au message [Achète] Raspberry pi 4. Évalué à 2.

    J'avais acheté en août chez Elektor.fr, mais je viens de voir qu'ils sont en rupture de stock aussi…

  • [^] # Re: Le MOVE COBOL

    Posté par  . En réponse au journal Des concepteurs qui ont éteint trop tôt leur cerveau. Évalué à 8.

    Dans le même genre, mais en moins explicite encore, tu as l'assembleur intel:

    mov ax, bx

    Evidemment, un dev COBOL va tout de suite se méfier: c'est effectivement une copie. Par contre, ça copie bx dans ax !

  • [^] # Re: Sérieux ?

    Posté par  . En réponse au lien La Cnil perd patience et demande des chiffres sur l’efficacité du pass sanitaire. Évalué à 6.

    Le pass sanitaire a montré son utilisé cet été: on est passé en 2 mois de derniers de la classe à premiers de la classe. Durant l'été, il a aussi servi de limiteur de foule pour certains espaces communs.

    Aujourd'hui, son utilité devient plus contestable: 90% de la population éligible est vaccinée, donc l'utilité "jauge" du pass n'existe plus.

    Maintenant, il est utilisé de la même manière pour pousser la 3ème dose. Est-ce que c'est une utilisation légitime ? pas sûr.

    Est-ce que les Français seraient aujourd'hui aussi bien protégés par le vaccin sans l'introduction de ce pass ? Et bien c'est là le piège: impossible à prouver ! On sait juste qu'en juin/juillet, la prise de rendez-vous pour une 1ère dose chutait en flèche.

  • [^] # Re: Offre à vie pcloud

    Posté par  . En réponse au journal La sauvegarde dans les nuages. Évalué à 4.

    L'encryption proposée par rclone est faite fichier par fichier (le nom aussi peut être encrypté). Donc c'est mieux qu'un disque virtuel complètement crypté, et moins bien qu'une encryption bloc par bloc.

    Au quotidien, seuls les fichiers modifiés sont ré-envoyés, ce qui me convient bien.

  • [^] # Re: Offre à vie pcloud

    Posté par  . En réponse au journal La sauvegarde dans les nuages. Évalué à 3.

    Que ce soit un abonnement ou un forfait, de toutes façons, si la boîte coule c'est terminé pour la sauvegarde.

    Donc finalement, ici, on peut simplement espérer que pCloud survive au moins 3 ans, et ensuite ça devient de plus en plus intéressant financièrement pour le client.

    Perso j'ai également choisi cette offre: le risque est faible que pCloud coule à court terme, et il n'y a pas la question de ce qui arrive si le paiement cesse.

    Pour l'instant c'est satisfaisant, et pour les données sensible j'encrypte chez moi avec rclone.

  • [^] # Re: Comprends pas...

    Posté par  . En réponse au lien Des pass sanitaires européens au nom de Bob l’Éponge et d’Adolf Hitler :). Évalué à 3.

    Ou alors la clé privée a fuité ?

    C'est probablement le cas.

  • # Accord avec Whatsapp ?

    Posté par  . En réponse au journal Comme une impression de déjà vu…. Évalué à 6.

    Je me demande quand même à quel point ce pont vers Whatsapp est officiel.

    Il y a déjà eu des anecdotes, dans le passé, de gens qui ont vu leur compte Whatsapp suspendu pour utilisation non conforme au CLUF…

    En sait-on plus à ce sujet ? Est-ce que je m'inquiète pour rien ?

  • [^] # Re: Code un peu vieillissant

    Posté par  . En réponse au lien Peertransfer, un moyen (assez) simple de partager un fichier. Évalué à 2. Dernière modification le 03 octobre 2021 à 23:21.

    Juste un serveur avec un nom de domaine.

    Euh, non. Le serveur, c'est mon propre PC. Le nom de domaine, c'est le mien, mais j'ai aussi une ipv6 globale donc utilisable directement.

    EDIT: je réalise que tu ne voyais peut-être pas que je visais l'auto-hébergement; dans ce cas je comprends ta remarque.

  • # Code un peu vieillissant

    Posté par  . En réponse au lien Peertransfer, un moyen (assez) simple de partager un fichier. Évalué à 5. Dernière modification le 03 octobre 2021 à 10:49.

    Lorsque je suis tombé sur ce projet, je cherchais un moyen simple de partager directement un fichier avec un ami.
    J'avais deux besoins:
    - pas d'intermédiaire. Donc exit les mega, dropbox, upload sur un VPS, etc. En effet, maintenant que j'ai la fibre, un upload décent et qu'ipv6 existe, pourquoi s'embêter ?
    - simple pour celui qui reçoit: aucun prérequis, juste un lien. Il clique, ça télécharge, fini.

    Bien sûr, je ne voulais pas avoir à installer une usine à gaz pour faire quelque chose d'aussi trivial…
    Il existe bien sûr le simple serveur http python, mais il faut le lancer à chaque fois où il faut, et tout le dossier est forcément partagé.

    Je suis donc tombé sur les technos "WebRTC", dont Peertransfer est un exemple d'utilisation. C'est l'exemple le plus simple et compréhensible que j'ai trouvé, même si le dernier commit date un peu (Mars 2020).

    Si vous connaissez une alternative intéressante, n'hésitez pas à partager !