barmic 🦦 a écrit 5211 commentaires

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

Finalement, je trouve plus efficace d'utiliser mon historique

Je trouve l'historique de firefox presque inutilisable personnellement. Sa seule raison d'être c'est pour aller plus vite sur des sites que je connais déjà. C'est à dire un remplaçant automatisé des onglets. Je n'ai peut être pas trouvé mais chez moi Ctrl+h et j'ai mon historique organisé par temps (très grosse maille, j'ai aujourd'hui, hier, cette semaine,… donc impossible de voir ce que j'ai cherché lundi soir) et un champ de recherche qui met une patate à toute l'organisation temporelle et me liste des liens dont un grand nombre sont des pages de recherche sur le même sujet.

Or c'est banal à dire, on voudrait confier à l'ordinateur le soin de gérer notre mémoire tout en se trouvant un peu comme dans une grande bibliothèque universitaire obligé de se rappeler tout ce qu'elle contient.

Une partie des avancées informatiques viennent précisément de ça : on laisse prend un ensemble très organique et on laisse l'ordinateur digérer ça pour nous. C'est pour ça que les moteurs de recherche ont surpassé les arborescence de lien. Permettre une navigation efficace au sein de ton usage du web n'est pas de la science fiction. Ça demande « juste » pas mal de motivation, de travail et du temps.

Edit : bon ça a l'air d'être ce que propose memex cité plus haut. Je vais voir ce que ça donne à l'usage. Ça n'a pas l'air libre et ça utilise un service à eux.

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

Je n'ai vu aucune interdiction.

C'est l'inverse (du moins dans toutes les législation dont j'ai entendu parler), il faut que les droits soient explicitement donnés.

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

hors règles automatiques

Chez moi ça fait quasiment tout le boulot.

Au lieu de ranger l'url dans un container, tu la ranges dans un profil avec l'icone "Envoyer vers"

Donc elle est ouverte avec le mauvais profile. Si l'objectif c'est aussi de se prémunir des fuite de données (ce qui me semble être quand même le cas vu le découpage), c'est problématique.

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

Ça me fait penser à feu-tab group :(

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

Mais tu dois faire la gestion à la main de tes url, te rappeler quelle url va où et ne pas te planter dans tes manip'. Ensuite si tu récupère plus de mémoire c'est aussi parce que tu en consomme plus avec ta méthode ;)

contournement aux fuites mémoire

Je n'ai jamais rencontré ça. Ce qu'il peut y avoir c'est des sites qui produisent des fuites mémoire (certaines pages de jenkins par exemple) et il vaut à mon avis mieux tracker ces pages là. about:performance est pas mal pour ça.

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

Et au cas où ça intéresse quelqu'un j'ai créé un p'tit user script pour changer les unités de volume de données des tableaux.

// ==UserScript==
// @name         TarsnapHumanReadable
// @namespace    http://tampermonkey.net/
// @version      0.1
// @description  Tarsnap Human Readable
// @author       barmic
// @match        https://www.tarsnap.com/*
// @grant        none
// ==/UserScript==

(function() {
    'use strict';

    function convert(value) {
        const units = ['o', 'Kio', 'Mio', 'Gio', 'Tio'];
        const values = value.split(" ");
        if (!values || values.length !== 2 || values[1] !== 'bytes') {
            return value;
        }
        var bValue = values[0];
        var unitIdx = 0;
        while (bValue >= 1000) { // I prefer read "0.97 Gio" instead of "1000 Mio"
            bValue = bValue / 1024;
            unitIdx += 1;
        }
        return bValue.toFixed(2) + ' ' + units[unitIdx];
    }

    for(let num of document.querySelectorAll("td")) {
        num.textContent = convert(num.textContent);
    }
})();

C'est un peu fait à la truelle mais ça fonctionne bien.

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

Si je me souviens bien grammalecte utilise des expressions rationnelles, non ?

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

Un onglet c est une page qu'on va lire la tout de suite
Les services types Walabag c'est la pile d'articles a lire
Les favoris sont des sauvegardes. Si tu as autant d'onglets alors ce n'est plus une pile à lire, mais des sauvegardes.

Je personnellement, j'ai revu considérable ma façon d'envisager tout ça depuis que j'ai configuré mon IDE pour ne plus avoir d'onglets. J'ai le fichier ouvert (ou 2 quand je split mon éditeur), un accès rapide à ceux que j'ai précédemment ouvert et une recherche dans tout ce qui existe. Je n'ai donc plus de tab management. Évidement la problématique est bien différentes entre un ensemble de fichiers existant sur disque et l'ensemble du web, mais pour moi :

• il ne devrait pas y avoir de différence notable entre onglet déchargé, historique et signés (un signé est un lien sur le quel tu as mis un ou plusieurs mot clef)
• je dois pouvoir mettre en place une hiérarchie assez simple :
  1. onglet épinglé
  2. onglet vivant
  3. tout ce qui est cité au point précédent
  4. recherche sur un moteur de recherche

Les 2 premiers sont vivants, ils exécutent du JS. Le point 3 demande à avoir un excellent moyen d'accès. Ce qu'aujourd'hui je n'ai pas dans firefox… Évidement de la recherche multi-critères (et filtrage des résultats) mais aussi autant d'intelligence que possible (reconnaitre la notion de site ou à minima de nom de domaine, extraire de la sémantique - exemple savoir qu'un lien est une recherche sur un moteur de recherche connu avec tel et tel mot clef -). Si j'avais ça, personnellement, je n'aurais pas besoin des onglets autres que ceux qui sont épinglés (allé disons qu'il faut aussi garder en mémoire les ressources des quelques dernières pages visité).

C'est trop compliqué à spécifier, c'est pas mal de travail à implémenter par contre. Mais pour le moment je peine dès que je dois chercher dans l'historique ça n'aide pas du tout.

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