barmic 🦦 a écrit 5744 commentaires

Pas cohérent! Tu dis que la perf n'est pas important pour ensuite dire que 1 des 2 points importants est la perf.

Benchmark et performance sont 2 choses très différentes. Un benchmark est une mesure de performance dans un contexte donné. Ce contexte est hyper important, si tu t'intéresse à la performance. Et c'est potentiellement compliqué de connaître le contexte dans le quel a était conçu un benchmark. Mais surtout je ne dis pas qu'il faut connaître la notion de perf de toutes les bibliothèques, une bibliothèque peut ne pas parler de performance dans sa description, si c'est ce qui t'intéresse tu sais que ce n'est pas la priorité du projet, si leur objectif c'est d'avoir une certaine forme d'API ou un maximum de sécurité ou je ne sais quoi c'est ce qui devrait ressortir d'une description.

Bref non je ne vois pas où est l'incohérence.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il existe un dépôt signal-slot-benchmarks sur GitHub regroupant une trentaine de bibliothèques au sein d'un benchmark global permettant d'avoir un point de comparaison des performances des unes et des autres. C'est un bon point de départ.

Un benchmark est rarement un bon point d'entrée je trouve et le reste de ton journal montre en partie pourquoi. Pour moi ce qui est important c'est moins de connaitre la performance (déjà qu'est-ce que l'on met derrière la performance ?), mais la philosophie derrière.

Ta bibliothèque est bidirectionnelle orientée jeu avec 2 aspects importants : possibilité de modifier dynamiquement et à haute fréquence les connexions signal/slot et le mono-threading pour ne pas payer le coût du thread-safe par défaut.

Ce genre de petites descriptions sont pour moi bien plus intéressantes car elles donnent une bonne idée de à quoi s'attendre en terme de fonctionnalité et en terme de performance. Ça limite aussi les usages à contre-emploi.

Par exemple, iscool::signals garantit que les fonctions soient appelées dans l'ordre dans lequel elles ont été inscrites. C'est juste un choix d'implémentation (sur lequel nous comptions dans nos jeux) mais pas une qualité intrinsèque d'un système de signaux et de slots.

Tu as regardé si c'était l'ordre inverse (comme une pile) ou stable ? Et surtout il me semble qu'il y a un corollaire à ça : l'ordre des exécutions contraint la réduction des données en retour. S'il n'est pas prédictible la réduction que tu applique aux retours de tes signaux doit être commutatif.

bs2, ics, jls, lfs, lss, mws, nes, nod, nss, psg, vdk et wnk permettent de savoir si un signal a au moins un slot. Les autres ne le permettent pas.

Je me doute que ça répond à un besoin, mais je vois ça comme un anti-pattern. Pour moi le signal-slot est là pour avoir un découplage entre le signal et le slot. Sinon autant utiliser des callbacks. Mais je dirais aussi la même chose pour le retour des signaux.

J'aurais pensé que les signal/slot est un pattern unidirectionnel qui permet à un « bout de code » de signaler 0, 1 ou plus d'autres fonctions. Il par rapport à l'appel direct de méthode, il permet un dispatch dynamique et par rapport aux callback, il permet principalement une simplification (le slot n'a pas à gérer ses clients) ce qui apporte un meilleur découplage.

Mais c'est ma vision probablement biaisée et ma lecture du pattern observable.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu personnalise et prend ton expérience pour une généralité. Surtout tu considère que l'humain doit avoir une logique froide et que si ça n'est pas le cas, il n'a qu'à le devenir que ça n'est pas ton problème. Très bien personne n'a dit que ça devait devenir ton problème. Mais d'autres au lieu d'affirmer des logiques froides s'intéressent à ce que les autres ressentent et tentent des choses pour améliorer leur ressenti. Je vois pas pourquoi juger dans tous les sens comme tu le fait (tu arrive en plus de ça à t'en prendre aux gens qui jugent si j'ai bien compris).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Finalement pourquoi bash n'accepte pas :

url="`{mathjax} {`{article}}"

Je ne sais pas j'étais très content de voir mon zsh pouvait faire :

foo=(titi toto tata); echo "${${foo[1]}//t/v}"
vivi

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il y a deux aspects compliqués : le redémarrage à chaud et les communications inter-process.

Je n'ai rien lu à ce sujet (je chercherais plus tard), mais je suis surpris que le typage structural ne puisse pas fournir de solution. Je présume que le problème vient du fait qu'ils ne sont pas en mesure que le type d'une référence pointe vers un type toujours valide, mais si c'était vraiment ça le problème remplacer un typage nominal par un typage structural devrait être possible.

Du coup ça me rend curieux :)

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Si une personne se dit « je ne participe pas à Debian car il n'y a pas assez d'amateurs de brocolis dans ce projet », pour ce sujet elle s'identifie au groupe des gens qui aiment les brocolis (ou à leurs défenseurs) plutôt qu'au groupe des gens qui ont envie de participer à Debian.
Depuis quand on participe à Debian en fonction de ses goûts culinaires ?

Je ne crois pas que ce soit la démarche. Si tu n'a que des mangeurs de viande qui font une activité X, si tu n'es pas un mangeur de viande, ça ne te viendra pas à l'idée de faire cette activité X. J'ai vu différent retour dans ce sens là, des gens qui se sont mis à faire quelque chose parce qu'ils avaient un avatar au quel se représenter.

Quant au fait de se sentir mangeur de viande, ça peut être une volonté de ta part ou ça peut venir de certaine stigmatisation. On se charge de te rappeler régulièrement que tu n'es pas mangeur de viande. On te dis pas que c'est mal, on essaie pas de te dire ce que tu dois faire, mais bon on en fait des blagues (qui sont drôles) et qui du coup participe à te créer ton identité.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

On peut même penser que les fichiers du registre puissent être mis en miroir sur de nombreux sites : l'utilisateur répartirait le téléchargement des fichiers sur plusieurs sites ce qui aurait l'avantage de répartir la charge tout en réduisant les risques de pistage.

Tu peut même aller plus loin et mettre en place une DHT avec une signature des index.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

J'ai de très bon souvenir avec mumble qui marchait extrêmement bien. J'avais espoir de m'en resservir avec le confinement, mais des solutions permettant de faire de la vidéo lui ont était préférées autour de moi.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Avant, Linuxfr s'appellait DLFP.

Et à l'époque on se foutait de la gueule des aigris qui dénoncent grave en affirmant que c'était mieux à vent.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Une… mauvaise pratique, de montrer mon code a tous, anonymement?

Il n'a pas remis en question le fait que tu publie du code. Il dit juste que selon lui il faut que ça arrive dans /usr/local/bin sinon c'est pas HFS.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Bah c'est une mauvaise pratique, tu peux éventuellement le faire pour ton shell courant, mais de manière global (pour une utilisation dans un script) c'est pas une bonne idée.
Par exemple, si tu cré un fichier "test" exécutable dans ton home, et que tu exécute un script qui utilise la commande test, il va exec ton test a la place et potentiellement faire n’importe-quoi.

Ton commentaire semble montrer que tu n'a pas compris sa remarque. Il ne parle pas de mettre le répertoire courant dans son ${PATH}, mais un dossier particulier. C'est une technique très classique et très utilisée (avoir un ${HOME}/bin qui est ajouté dans ${PATH}).

Le problème que tu décris n'existe que si le dossier en question est ajouté en première position ce qui est rarement fait.

Et généralement on a pas besoin de commande retry, en dehors d'une utilisation pour téster/débuguer. Si t'as une commande qui peux échouer pour de bonne raison, elle doit très certainement avoir une option "retry", "timeout", "wait" ou quelque chose comme ça.

Tu considère comme général ta propre vision, mais elle n'est ni unique, ni une généralité. Une logique plus unix serait de laisser les nouvelles tentatives à la charge d'un autre outil. D'où l'existence de la commande timeout dans les coreutils.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Euh… Je comprends qu'ils puisse avoir un ton qui ne te convient pas, mais c'est toute de même une critique constructive. Je ne sais pas trop pourquoi tu le prends à parti comme ça. Il a pris le temps de revoir ton code et d'en exprimer une critique. C'est un comportement précieux dans le libre. Parce que le libre ce n'est pas que du code, c'est aussi de la remonté de bug, de la relecture, du tris de bug, de l'écriture de documentation, du packaging,…

Il n'a pas remis en cause ton droit d'avoir écris ton code et de l'avoir partagé. Le fait qu'il ai pris le temps de relire et de rédiger remarques montre justement une certaine considération.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Merci de ne pas répondre au tac au tac et de réfléchir avant

Le journal est un troll qui a était écris à la va vite. Parce que le plus important c'est de dire à la face du monde que systemd c'est pas bien. Vu la qualité du journal, je ne vois pas pourquoi il mériterais beaucoup plus que des réponses « au tac au tac ».

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Perso, j'ai me suis créé un user script pour filtrer les tags que je ne veux pas voir. C'est assez trivial et ce serait améliorable :

// ==UserScript==
// @name         DLFTags
// @namespace    DLFTags
// @version      0.1
// @author       You
// @match        https://linuxfr.org/*
// @grant        none
// @run-at       document-body
// ==/UserScript==
(function() {
    'use strict';
    let tags = new Set(['python','linux','debian']);
    for(let article of document.querySelectorAll("article")) {
      for(let tag of article.querySelectorAll("a[rel=tag]")) {
        if (tags.has(tag.textContent)) {
            article.style.display = 'none';
            break;
        }
      }
    }
})();

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il n'a pas dis le contraire.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Merci pour ton journal

Si l'on suppose que chaque identifiant tient sur 128 bits, qu'un nouvel identifiant éphémère est utilisé toutes les 15 minutes, cela représente jusqu'à ~21 Ko de données à conserver par malade. […] Par exemple sur les 14 derniers jours, il y a eu plus de 400 000 nouveaux cas diagnostiqués aux Etats-Unis, la taille correspondante du registre des identifiants éphémères pourrait atteindre (si tout le monde utilisait une application de traçage) 8 Go pour 14 jours, soit une base journalière de l'ordre de 600 Mo.

Je n'ai pas bien suivi ton calcul (j'arrive pas à retomber sur tes chiffres). Mais stocker ses identifiants peut être plus efficace. Tu stocke les identifiants dans un arbre binaire. Ça te donne un arbre binaire de profondeur 128. Selon comment on veut gérer le truc on peut partitionner par préfixe (tu peut avoir 16 partitions qui auront chacun un préfixe de 4bits) et/ou éliminer des branches (tous les qui ont un préfixe donné sont considéré comme dangereux).

Ça permet aussi d'avoir un parcourt assez efficace.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

grub > Advanced options pourra probablement t'aider ;)

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Un exemple de ces raisons : des experts judiciaires américains ont utilisé OpenPGP pour signer des images de disque dur, qui sont conservées dans les archives du système judiciaire US. Les plus anciennes de ces signatures n’utilisent même pas SHA-1, mais MD-5. Aucun expert n’est chaud pour demander que ces signatures soient refaites avec des algorithmes plus modernes, parce que cela pourrait entraîner la remise en question de toutes les affaires judiciaires où des signatures MD-5 ont été utilisées quelque part dans la chaîne de préservation des preuves…

Merci pour l'exemple. C'est intéressant. Je pense tout de même que le problème est que dans des cas de sécurité sur de longue période comme cela, il faudrait prévoir le maintiens de la sécurité. Comme on doit maintenir des sauvegarde (s'assurer que les disque de sauvegarde ne sont pas mort, qu'ils restent lisibles,…), il faut maintenir encore plus activement la sécurité. Ici l'absence de procédure mise en place correctement nuit gravement à la sécurité de ses données. S'ils subissent une intrusion garantir que les signatures sont intouchées sera compliqué…

Bref, tout ça pour dire que la balance entre sécurité, utilisabilité et interopérabilité est délicate. Les développeurs OpenPGP ont généralement tendance, lorsqu’il faut arbitrer entre ces notions, à favoriser l’interopérabilité tant que la sécurité n’est pas irrémédiablement compromise, et à mon sens ils ont raison.

Je pense que c'est compliqué. Le curseur de sécurité n'est pas évident à envisager et n'est pas forcément linéaire. En plus de ça chacun dans son contexte et de sa subjectivité a envi d'avoir un curseur positionner différemment.

L’alternative, c’est un système non-interopérable dans le genre de Signal, où les développeurs peuvent certes ne faire aucune concession sur la sécurité mais au prix d’un fonctionnement en vase clos qui lie les utilisateurs à un seul fournisseur.

Je connais mal OpenPGP, mais il doit être possible d'avoir un certain niveau par défaut et de réactiver des algo sur demande (c'est peut être ce qui est fait) ou de modulariser et d'avoir des paquets -ugly comme le fait gstreamer ou encore de n'accepter que de lire ces algo.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Une implémentation d’OpenPGP de 2020 doit être capable de lire des e-mails vieux de dix ans ou plus, sauf à mécontenter beaucoup de monde.

Je ne remet pas en cause ce que tu dis, je me doute qu'ils ont pleins de plaintes. Mais c'est débile comme argument. Si tes mails sont si vitaux une fois reçu tu peux les déchiffrer et les rechiffrer avec l'algo de ton choix. La signature de l'émissaire ? La bonne affaire, elle était importante au moment de la réception. Tu peux ressigner toi à toi de te faire confiance que tu n'a pas altéré le message qui t'était destiné. Aujourd'hui ou dans X années, tu ne pourra de toute manière plus faire confiance en cette signature.

Encore une fois le tu représente ici celui qui joue sur une argument somme toute assez léger pour affaiblir un outil qui'il semble lui-même choisi pour sa solidité.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je ne suis pas un grand connaisseur du C et ça fait longtemps que je n'ai pas pratiqué.
Mais lire du code c'est toujours amusant :)

int run_cmd( unsigned int time, unsigned int tsleep, char** cmd )
{
    sleep( tsleep );
    int status;
    switch( fork() )
    {
        case 0:
            alarm( time );
            execvp( *cmd, cmd );
        case -1:
            CHECK_ERR();
            break;
        default:
            break;
    }
    pid_t child = wait( &status );
    return child != -1 ? WEXITSTATUS( status ) : -1;
}

Il y a pleins de subtilité dans ce petit bout code. Faut voir que execvp() ne retourne jamais sauf en cas d'erreur où il positionne errno. Donc la macro CHECK_ERR(), va gérer les cas d'erreur de fork() (ce qui est évident) ou de execvp()` (ce qui est déjà plus subtile).

La gestion du fils est hors du switch alors que sémantiquement elle devrait être dans le default (amha). Et on a du coup un truc qui est de genre :

swicth(fork()) {
  case 0: // child
  case -1: // error
  default: // root process
}

Bien sûr ce n'est qu'un avis personnel qui est là pour ouvrir une discussion :)

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

[…]il faudrait des outils en ligne de commande (et non dépendants de ressources web externes) pour intégrer ça en CI ou dans les tests hors CI.

Ça c'est simple, mais ce n'est pas suffisant. Comment tu énumère les pages ? Quand tu ne fais pas de sites statiques ton code ne représente que des templates. Il faut les exécuter. Les paramètres de ces templates peut casser la validation (exemple ici sur linuxfr, si tu ne met pas de texte alternatif aux images).

Je passe toujours mon code par un maximum de linter[…]

Il faut aussi garder en tête que l'analyse statique de code est un outil limité. Il possède des biais, génère des faux positifs et faux négatifs. Il n'est pas forcément complet. Ce n'est pas une fin en soit. Se concentrer sur des métriques comme cela peut facilement amener à des abus.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Le vrai souci ce n'est pas de ne pas pouvoir afficher des caractères autres que quelques uns de l'alphabet latin ? Parce que ça va poser un problème aussi si tu a un fichier avec un caractère hors ASCII, si tu affiche quoi que ce soit qui depuis le réseau (via curl par exemple).

Je ne milite pas pour utiliser l'ensemble d'unicode pour écrire du code. Mais si tu te place dans un mode aussi compliqué que possible pour nous montrer que oui quand on se crée un environnement d'il y a plus de X années, on a les problèmes qu'on avait il y a X années tu enfonce des portes ouvertes. C'est un argument assez faible. Pleins de choses n'existait pas à l'époque de potato, ça n'est pas pour ça qu'il faut s'en passer.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C'est assez clivant, généralement mais personnellement je m'en fou que ce soit en anglais ou autre chose. Il faut que ça ai du sens. Définir un ubiquitus langage pousse souvent à utiliser la langue des utilisateurs.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Par contre on est d'accord : en soi du code en français, on s'en fiche, d'autant que ce qui compte c'est que la machine comprenne les instructions…

Mais moi je suis pas d'accord :) Pour moi on écrit du code pour qu'il soit lu par d'autres développeurs (ou sois-même dans le future).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Au-delà, sur le choix de Rust, à la différence d'un projet qui aurait été en Java par exemple, il n'y a pas besoin d'avoir une plateforme logicielle sous-jacente lourde. L'emprise mémoire pour la gestion de Robert est très faible.

Tu utilise des pool d'objets/structures pour éviter la fragmentation mémoire ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll