xoddark a écrit 116 commentaires

  • # Le résultat ne m'a pas étonné du tout

    Posté par  . En réponse au lien ifstream vs posix (le résultat va vous étonner). Évalué à 3.

    Le cas testé ici ne correspond pas au cas d'usage auquel les outils C++ utilisé ici sont pertinent. Les
    Et vu que le contenu de lien n'essaye pas du tout de comprendre ou d'apporter des pistes de réflexion, même pas un petit questionnement, ba c'est pas super intéressant.

    Par exemple, dans les tests des fonctions C une pré-allocation de la string de destination est faite une fois et de la bonne taille avant de la remplir avec le contenu du fichier. Chose qui n'est pas faite dans les cas d'utilisation des stream C++.
    Dans les version C++, il y a sûrement de multiple réallocation de la string … ce qui est beaucoup plus coûteux qu'une première allocation d'une taille suffisante.

    Pour mieux comparer, il faudrait également faire des préallocation à la bonne taille de la string de destination.

  • [^] # Re: Enfumage

    Posté par  . En réponse au journal GitHub supprime les issues et pull requests de comptes russes suspendus ... puis les restaure. Évalué à 1.

    Oui c'est sans doute un problème de terminologie.

    Je dirais qu'effectivement Git est un système de version distribué. Cette fonctionnalité permet à ses utilisateurs de travailler de façon décentralisée.

    Mais au final c'est l'organisation de travail qui est décentralisé ou pas, mais pas Git.

  • [^] # Re: Enfumage

    Posté par  . En réponse au journal GitHub supprime les issues et pull requests de comptes russes suspendus ... puis les restaure. Évalué à 4. Dernière modification le 22 avril 2022 à 16:01.

    Je ne suis pas expert de l’écosystème des crypto-monnaies (Bitcoin ou autre), donc il y aura sûrement des approximations et/ou inexactitudes.

    Je dirais que dire que Bitcoin est décentralisé n'a pas de sens, comme dire que Git est décentralisé. Git et Bitcoin sont des outils (voir ensemble d'outils) qui permette de travailler ou de gérer des transactions de manière décentralisée.

    Pour l'histoire de l'équivalence, je dirais que l'ont peu considérer que l'équivalent de Bitcoin dans l’écosystème git est le dépôt git du kernel linux. C'est avec lui que tout à commencer, il contient tout l'historique des commits (au moins depuis les débuts avec Git), il permet à un grand nombre de personne de travailler ensemble sur un dépôt commun.

    Git est un outil permettant un travail coopératif décentralisé, comme la blockchain est un outil permettant une gestion décentralisée de transaction. Mais dans les deux cas, au final il y a une synchronisation (centralisation ?) dans une base de donnée (dépôt git vs blockchain) même si celle-ci peut-être dupliqué.

    Pour le cas de GitHub, l'équivalence cotée crypto serais une plateforme d'échange (ex: Coinbase). L'une comme l'autre recrée un point de centralisation, au moins pour tout ce qui n'est pas dans la base de donnée elle-même (dépôt git ou blockchain).

    ça te semble plus clair ?

    PS: Il y aurait moyen de faire encore plus détaillé, avec plus de comparaison, mais ça demanderais plus du temps pour faire ça bien ^

  • [^] # Re: Boîtier sésame

    Posté par  . En réponse au journal BPCE et les paiements avec authentification à deux facteurs. Évalué à 4.

    J'ai également un boîtier pour mon compte perso au crédit coopératif créé il y a 7/8 ans je dirais. Pendant une période je l'avais avec moi tous les jours pour aller au travail, et il n'a pas trop aimé et fini par ne plus fonctionner.
    J'en ai demandé un nouveau il y a 1 an ou moins, et on m'en a envoyé un sans poser de question.

    Comme d'autre, j'aime bien le principe, reste la problématique de l'avoir avec soi ou pas, si on veut pouvoir valider des commandes en ligne quand on est pas chez soi.

  • [^] # Re: Kamoulox !

    Posté par  . En réponse au journal Golang, oops you did it again. Évalué à 3.

    Je suis en phase d'apprentissage de Rust, et ce système est nouveau pour moi.
    Mais de cette expérience encore fraiche, je dirais que cette façon de rassembler les données valide et d'erreur permet de plus facilement et proprement séparer le code logique du code de gestion d'erreurs.

  • [^] # Re: Ca pue le scam

    Posté par  . En réponse au lien la "biobattery" technologie du futur ?. Évalué à 3.

    Reste à trouver comment signaler à OkPal/Ulule, et voir comment ils réagissent.
    J'ai cherché un bouton signaler, mais je n'en ai pas trouvé :(

  • [^] # Re: arnaque ?

    Posté par  . En réponse au lien la "biobattery" technologie du futur ?. Évalué à 0.

    Ils proposent de les rencontrer sur Paris, qui à envie de tenter de "les" rencontrer ?
    😁

  • # arnaque ?

    Posté par  . En réponse au lien la "biobattery" technologie du futur ?. Évalué à 10. Dernière modification le 18 février 2022 à 13:11.

    Euh ça sens l'arnaque à plein nez quand même.

    • des promesses et aucune information technique
    • aucune information sur qui est dérrière
    • site internet vide sans mention légale, sans information sur le propriétaire
    • site internet minuscule mais avec quand même des liens cassé vers lui même.
    • OkPal semble être pour collecter de l'argent entre particulier, pas pour un financement participatif "public".

    Reste le lien linked-in que je n'ai pas pu utiliser, car je n'ai pas de compte linked-in.

  • # Déçu

    Posté par  . En réponse au lien Le bitcoin vu par Jean-Paul Delahaye. Évalué à 4.

    J'ai été déçu par la lecture de l'article, il s'agit en fait seulement d'une critique de la preuve d'enjeux.
    Avec le titre je m'attendais à une critique plus complète, il y a tellement à dire.

  • # C'est ma "grande" déception au sujet d'AMD

    Posté par  . En réponse à la dépêche OpenCL sous Linux : l’état des pilotes AMD est désormais pire que ce qu’il était à l’époque de fglrx. Évalué à 9.

    Je m'intéresse au développement des pilotes libre AMD depuis l'annonce du développement officiel de pilote libre (2009 je crois). J'ai suivi les progrès, les difficultés, les essaie …
    Et aujourd'hui on à la confirmation que c'était vraiment une stratégie de long terme et que ça à payer … sauf coté OpenCL.
    Et étant utilisateur régulier de Darktable (entre autres) c'est un sujet de déception pour moi. J'avais suivi avec espoir les débuts de Clover pour ensuite me retrouver frustré par l'arrêt de sont développement.

    Globalement, je dirais qu'OpenCL est une technologie assez "mal aimée", et donc c'est assez difficile d'avoir des personnes/financement pour du développement de driver libre.

    Bravo pour tes efforts, j'espère que ça aidera à recréer une émulsion autour de cette technologie.
    Il n'y aurait pas une programmeuse, un programmeur débutant qui serais intéressé par travailler sur Clover pendant le Google summer of Code (ou autre initiative de ce genre) ?
    Avec de meilleurs drivers, il serait plus facile d'avoir plus d'application à l'utiliser.

  • # Post original

    Posté par  . En réponse au lien In defense of NIR within Mesa driver stack - phoronix. Évalué à 2.

  • # Vive l'informatique d'aujourd'hui ...

    Posté par  . En réponse au lien Elyse, l'appli mobile pour choisir le candidat à la présidentiel va devenir open source. Évalué à 5. Dernière modification le 18 janvier 2022 à 20:47.

  • [^] # Re: Tu dois pas produire grand chose

    Posté par  . En réponse au journal De l'art d'être indépendant des dépendances. Évalué à 10.

    Le reproche que je fais est de ne pas effectuer la vérification a minima et balancer en prod à l'aveugle

    Ce n'est pas le point que j'avais le plus retenu à la lecture de ton journal.

    Ta pratique que tu expliques ne semble pas applicable dans plein de projet. Je pense que ça aurait été judicieux de contextualiser sur le type de projet sur lequel tu l'appliques.

  • # D'un extrême à l'autre ?

    Posté par  . En réponse au journal De l'art d'être indépendant des dépendances. Évalué à 10.

    Est-ce que parce que faire une confiance aveugle aux gestionnaires de packages est sans doute pas une bonne idée que les rejeter en block et faire à la main est la meilleure chose à faire ?
    J'ai l'impression que ce que tu présentes est juste l’extrême inverse.

    Gérer les dépendances d'un projet ce n'est pas trivial et demande un apprentissage (quelle que soit la méthode).
    Donc le faire à la main me semble pas très accessible à des débutants, et comporte aussi ses risques. Comme ne pas mettre à jour les dépendances, y compris contre les problèmes de sécurité.

    Concernant semver, dans quelle pratique c'est un échec ? Pour qui ?
    Car prendre l'exemple de Firefox et Chrome qui s'en sont passé ne me semble pas très pertinent.
    Déjà parce que ce sont des cas très particuliers. Ce sont des applications "finales" qui ne sont pas utilisés par d'autre programme. Ce qui est très différent des librairies qui s'incorpore dans d'autres programmes.
    Ensuite si pour eux ça doit être plus simple, je ne suis pas certain que les entreprises qui surveillent les déploiements d'application soient ravies d'avoir les nouvelles fonctionnalités mêlés aux corrections de bug/failles.

  • [^] # Re: En train

    Posté par  . En réponse au lien Un épisode de 28 minute sur les GAFAM avec l'excellente Aurélie Jean !. Évalué à 3.

    Je suis plutôt du même avis.
    Par exemple, je trouve qu'il manque des échanges sur la structure fermée de réseaux, sur les problématiques d'interopérabilité.
    Ce sont des angles important du débat et qui conditionne plein de choses, comme le modèle économique (de ses structures) et la concurrence (dont il est question).

  • [^] # Re: Pourquoi ?

    Posté par  . En réponse au lien Remplacer ChromeOS par Linux sur un Dell 3189 (prévoir un tournevis). Évalué à 8.

    Pourquoi ? je dirais pas exemple :
    - parce certaine qu'une personne peut obtenir un chomebook sans l'avoir acheté ?
    - parce qu'un utilisateur peut changer d'avis ?
    - parce qu'un utilisateur peut découvrir linux après avoir acheté le chromebook ?
    - ou même juste par désir de hacking ?

  • [^] # Re: manque de précisions

    Posté par  . En réponse au journal Brother et la sécurité. Évalué à 8.

    Cool si tu arrive a utiliser ton imprimante avec le driver libre.
    De mon coté, j'utilise Fedora et quand je branche l'imprimante (en USB) elle est détecté et un driver s'installe et se configure automatiquement (un driver libre je suppose), mais je n'ai jamais réussi a faire fonctionner mon imprimante avec (DCP-J315W) et je ne savais pas ou aller regarder pour essayer d'isoler un peu le problème.
    Il faudrait que je prenne contact avec les développeur des pilotes libre pour soir s'il y aurait moyen d'améliorer la situation.

    Par contre j'arrive à la faire fonctionner en installant les pilotes propriétaires Brother pour linux.

    Et je confirme j'ai été très déçu du support français. Je les aient contacté pour un problème d'initialisation du scanner … qui empêchait d'imprimer 🙃. Leur seule réponse à été : envoyez nous l'imprimante (a vos frais) au support à Paris et on vous fera un devis de réparation (probablement plus chez que "la valeur" de l'imprimante).

    Au final j'ai trouvé une boutique près de chez moi qui fait de la réparation. Il n'ont pas trouvé la pièce, mais m'ont conseillé de chercher le même modèle sur le bon coin, et de récupérer et changer le bloc scanner. Ce que j'ai pu faire pour 20€ frais de port compris, et elle est reparti pour un tour.

  • [^] # Re: format automatique

    Posté par  . En réponse au journal Quelles seraient les meilleures règles de formatage de code ?. Évalué à 1.

    Euh, justement git à une fonctionnalité qui permet de réécrire l'historique d'un dépôt sans avoir à gérer ce genre de problématique à la main :
    filter-branch
    Bon du coup, à priori maintenant l'outil git-filter-repo est conseillé à la place.

    Mais bien sur, ça va compliquer les choses pour des personnes qui auraient des commits externe au dépôt. Mais c'est pas insurmontable, si c'est fait une fois pour repartir sur des bases plus propre c'est une possibilité qui existe.

    PS: et si c'est juste pour un ancien commit, rebase -i est bien pratique aussi.
    Avec les mêmes problématiques de changement de hash, qui peuvent poser problème dans certain cas, et pas dans d'autres, Si l'on sait ce qu'on fait ça peut-être très pratique.

  • [^] # Re: Estimation à la louche

    Posté par  . En réponse au lien Il y aurait plus d'un trillion de bases de données SQLite en utilisation active. Évalué à 1.

    C'est sans doute une base par minutes, pour plusieurs images. Donc plusieurs images par base 😀

  • [^] # Re: format automatique

    Posté par  . En réponse au journal Quelles seraient les meilleures règles de formatage de code ?. Évalué à 2.

    Avec git tu peux réécrire chaque commit de l’historique pour repartir sur une base propre. Mais par contre ça va modifier chaque hash de commit, etc. Donc si tu as des données externe qui référence ses hash, ba tu perds le lien.
    Donc ça peut se faire une fois pour repartir “propre” à un moment clé. Mais c’est pas sans impact.

  • [^] # Re: Pas con

    Posté par  . En réponse au journal Quelles seraient les meilleures règles de formatage de code ?. Évalué à 1.

    Oui, je pencherais pour un outil dédié qui comprendrais le code et serais capable de le mettre en forme seulement pour affichage et/ou avant traitement pour les outils qui en aurais besoin.

    Mais j’aurais gardé les retours à la ligne dans les versions minifiées. La majorité des outils (ex: git/diff/patch) ont leur traitement basé sur les lignes.
    Faire évoluer ça, serais encore une étape supplémentaire, et nécessiterait de nouvelles idées.

  • [^] # Re: Pourquoi ?

    Posté par  . En réponse au journal Merci LinuxFr. Évalué à 1.

    Que savez-vous de moi pour me mettre dans une case de « chantres de la "liberté" ».

    Je trouve la dernière phrase du commentaire cité plutôt pertinentes :

    Si le fait qu’un sujet de société - qui enflamme tout le monde partout - ne fait pas VOTRE unanimité sur un site dont le thème est COMPLÈTEMENT autre chose, alors que ceux qui veulent partir partent, et embarquent toute leur intolérance avec eux.

    Mais par contre je ne vois pas ce qui vous fait considérer l’ensemble du commentaire comme de la contradiction.
    Surtout quand il est présenté comme « la seule et unique qui soit pertinente ».

  • [^] # Re: EditorConfig

    Posté par  . En réponse au journal Quelles seraient les meilleures règles de formatage de code ?. Évalué à 1.

    j'avais du voir passer des fichier .editorconfig dans des projets, mais sans avoir pris le temps de regarder et sans connaître le site. Je note merci

  • [^] # Re: Si y a modo dans le coin...

    Posté par  . En réponse au journal Quelles seraient les meilleures règles de formatage de code ?. Évalué à 1.

    Oups, désolé, effectivement si quelqu’un peut corriger.

    Merci

  • [^] # Re: au fond, la forme

    Posté par  . En réponse au journal Quelles seraient les meilleures règles de formatage de code ?. Évalué à 1.

    Ah oui, je m’étais dit que je parle de séparation fond et forme.
    C’est reconnu comme une bonne pratique pour les programmes, pourquoi ça ne le serait pas pour le code ?
    Mais j’ai oublié quand j'ai écrit le journal.

    Du coup ça me fait penser à l'expression :
    “Les cordonniers sont toujours les plus mal chaussés.”
    😀