barmic 🦦 a écrit 5782 commentaires

Mais si ton appli est capable d'avoir des infos, pourquoi elle freeze ? Quand l'appli freeze, c'est qu'elle est en attente sans en savoir plus. Que veux-tu dire à l'utilisateur qui permettra à lui de changer la situation, quand tu es en attente d'une machine à l'autre bout du réseau ?

Ok en fait on ne s'est pas compris.

Le freeze c'est le fait qu'une interface graphique ne réponde plus.

Tu peux très bien organiser ton code pour que le fil d'exécution qui gère l'interface ne fasse que la gestion de l'UI et interactions avec le gros du logiciel. C'est l'architecture qui était généralisée sur BeOS (d'où le commentaire plus bas). C'est ça qui est reproché.

Mon point de vue c'est de vous demander de pousser la réflexion plus loin que la première étape qui est le feedback visuel, en se demandant ce que ça va changer à l'issue de la tâche qu'est en train d'effectuer l'utilisateur.

Déjà avoir systématiquement ce retour ce serait énorme. C'est ce feedback qui permet à l'utilisateur de mieux comprendre ce qui se passe et pourquoi des choses prennent du temps. Et ça lui permet de faire des choix plus éclairé que ce que son imagination va donner.

Ensuite la logique voudrait que tu ne puisse pas modifier un traitement en cours, uniquement l'annuler. Mais c'est un pas bien plus compliqué à mettre en place.

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

Bref, l'idée n'est pas de donner des leçons ou d'arriver avec mes gros sabots

alors que plus haut :

N'as tu pas une petite liste dans un coin des technos/logiciels bien mauvais que tout le monde utilise?
Démontrant ainsi que la popularité n'a rien à voir avec la qualité?

Tu n'a pas l'air d'être particulièrement intéressé parce que je t'explique jugeant que je prends pour exemple de mauvais logiciels sous seul prétexte qu'ils ne suivent pas tes préceptes.

Les choses ne te plaisent pas tant pis pour toi. Ton objectif semble ne pas être d'échanger, mais de te plaindre en multipliant simplement les exemples sans liens (autre que d'être des logiciels) et d'en tirer des conclusions aussi intéressantes que « tout le monde il est méchant, ils ne comprennent pas ce que je leur explique ». Je ne serais pas ton client plus longtemps. Passe un bon week-end.

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

C'est écrit donc c'est vrai?

J'ai pris Redis car c'est LA référence¹ du domaine et qu'il est massivement utilisé. Ils ont considéré que le gain en performance ne valait pas les autres avantages. Il existe des alternatives à redis, qui font des choix différents. Mais force est de constater qu'il reste une place pour redis, malgré l'API ASCII et pendant longtemps l'absence de cluster.

Personne n'est donc plus "au courant" que par exemple le nombre 2 milliards, transféré en ascii va prendre 10 octets, et en binaire seulement 4 octets?
Et que dire du temps CPU pour convertir l'ascii ?

Ce que disent les mainteneur de redis, c'est que ce n'est pas la seule chose qu'il faut regarder et qu'ils sont prêt à payer ce coût face à d'autres avantages. On parle d'un projet qui fonctionne et qui fonctionne très bien depuis longtemps. Il a des challengers qui ont des protocoles binaires, mais ça n'a semble t'il pas suffit à le détrôner. Je veux bien te proposer d'aller en discuter avec eux, mais si tu viens avec tes gros sabots comme ici je doute que tu sois bien accueilli…

Je ne vois pas l’intérêt de Redis pour un seul serveur, une librairie faisant le même boulot, ne suffirait-elle pas?

Intéresse toi au modèle d'exécution de PHP ou des (fast)CGI par exemple. Quand tu fais spawn un process par requête (ou que tu fais un pool de thread) ça va coincer. Si tu n'a pas ou si tu ne veux pas manipuler des threads toi-même comme avec node ça peut être intéressant.

A moins que l'on considère que l'appel d'une fonction est "comparable" à l'appel d'un service réseau.

Ce n'est pas l'appel d'une fonction, c'est un IPC que tu dois utiliser donc tu a ton coût de sérialisation quoi qu'il arrive (sauf éventuellement si tu utilise des threads et pas de process, mais tu as toute la protection à fin d'être thread-safe à gérer. Plus un autre pour nettoyer tes données. Les caches sous forme de bibliothèques ça existe, mais c'est des contextes différents.

Bref, ce que fais Redis en réseau peut très bien être fait par une l'utilisation d'une librairie pour les besoins que tu précises (optimisation pour les gros volumes, fragmentation, …) sans requérir un service.

Ça dépend du contexte. Mon po objectif c'est de te montrer qu'il y a pleins de contexte différents qui amènent à des solutions différentes et donc des solutions différentes. L'exemple de redis n'est là que parce que c'est un exemple réel qui coche toutes tes cases tout en ayant sa place et ses utilisateurs.

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

Et donc, le REPL. Y'a des langages évolués qui émergent, mais aucun n'a un si bon REPL, voir aucun REPL du tout. Le temps écriture -> test -> validation -> je recommence est bien plus rapide et fun avec un REPL.

C'est joueur de dire ça quand il y a ipython en face :)

J'ai dans ma todo list à aller voir du coté de clojure. « Bouh c'est pas bien c'est sur la jvm ! » Moi je m'en sert au quotidien et j'en suis bien content de cette jvm. Clojure a d'intéressant pour moi qu'il a une alternative que je trouve très cool aux fluent API : les transducers. On garde la composabilité, mais on inverse l'application. Le traitement composite est une élément de première classe qui peut être nommé et même composé pour enfin s'appliquer sur de la donnée. Ça évite les compositions fluent qui deviennent lourdingue à cause de leur taille

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

Désolé de la digression, mais t'es tombé pile sur un truc qui m'énerve.

Pourquoi poster un commentaire énervé à 1h du mat' ? (si tu es dans la tz de Paris)

Alors pour le partage réseau, déjà, est-ce que c'est un partage abstrait par le VFS ou alors une API spécifique à Nautilus (ou une lib qu'il utilise spécifiquement) qui lui permet de savoir que c'est un partage réseau ? Dans le premier cas, ça obligerait à complexifier le cas pour tous les accès même locaux, et ça causerait sûrement plein de problèmes de consommation et complexification supplémentaire pour uniquement ce problème particulier. Dans le second, il y a effectivement peut-être des choses à faire, mais il faut essayer de comprendre le besoin : le réseau ajoute intrinsèquement des latences, alors combien de temps il faut attendre avant de dire qu'il est « en carafe » ? Est-ce une erreur transitoire ou permanante (et on démonde le partage) ?

Dans le premier cas ça permet aussi de gérer les disques qui ont des erreurs (physique, mal branchés, autre). C'est une I/O ça peut planter tenter de ne gérer que les cas que tu imagine c'est généralement en oublier un énorme paquet. Et en terme de complexité ça n'est pas forcément si incroyable que ça. Du moins ça peut l'être si ton design a était prévu pour.

Certes, pouvoir fermer la fenêtre devrait être une option accessible, mais si je peux me permettre le tirage de cheveu, la question de l'informatique a toujours été de cacher les modalités, et là donc la modalité du « je suis dans un dossier du partage réseau », que tu la recrées en fermant la fenêtre et en allant en rouvrir une autre pour aller au même endroit et te reprendre la même erreur… quel intérêt ? « Attendre que ça revienne » peut être une solution également valable ! Ça me fait penser à ceux qui rechargent leurs pages pour régler leur problèmes : TCP a été inventé (dans les années 70 !) pour réessayer à votre place, sans que vous ayez besoin de le faire vous-même ! (vous n'êtes pas des machines ! Bien que les devs prennent souvent leurs utilisateurs pour des automates débiles)

Si tu freeze ton application, flinguer ton application est la seule option qui reste à ton utilisateur. Si non tu pourrais lui expliquer ce que tu es entrain de faire, ce qui plante, lui donner des billes pour savoir si c'est transitoire ou non…

Corrigeons d'abord ces conneries afin d'avoir un réseau plus fiable, après on aura moins de problème avec les GUI.

Donc au lieu de faire en sorte que les UI restent réactives donnent des info à leur utilisateurs, il faut qu'ils investiguent eux-même d'où vient ton freeze, qu'ils regardent toutes les I/O de leur machine et potentiellement de leur réseau et corrigent le problème. Tant pis si tu es sur un wifi publique ou si ta connexion est mauvaise (réseau mobile hors jolies 4 ou 5G ou alors ligne physique mais en défaut sur le moment) ?

Les développeurs d'intellij sont entrain de bosser là dessus comme ils l'ont dis au début de l'année (IntelliJ Platform Roadmap for 2020).

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

De ce que je comprend maintenant ton système n'a d'utilité que si il est au centre d'une architecture multi-serveurs (sinon pourquoi ne pas avoir une hashmap/un graphe directement dans l'appli, plus simple et plus rapide). Donc réservé aux gros déploiements.

Redis est massivement utilisé pour un seul serveur (au pif il est préconisé pour l'installation de nextcloud) et il utilise un protocole texte (la doc. Vouloir donner beaucoup de contraintes à ce logiciel pour mettre en défaut ses choix ce n'est pas très aimable je trouve.

sinon pourquoi ne pas avoir une hashmap/un graphe directement dans l'appli, plus simple et plus rapide

Les map de ton langage ne sont pas forcément très fortes pour gérer de gros volumes dans le temps (avec des stratégies pour limiter la fragmentation par exemple), elle ne fournie pas d'expiration, tu peut vouloir accéder à ses données dans ton serveur et dans un p'tit utilitaire installé sur ton serveur par exemple,…

Quand on a ce genre d'architecture, on cherche l'optimum, car perdre 5% de performances c'est payé quelques serveurs de plus pour "rien".

Ce n'est probablement pas le usecase de robert comme ce n'est que difficilement le usecase de redis (le mode cluster - pas master/slave - n'est arrivé que récemment et sans ça ta montée en charge est fortement contrainte).

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

Donc généralement tu va utiliser un type prédéfini qui possède potentiellement des trucs dont tu n'a pas besoin.

Je vois pas trop à quoi tu fais référence ici.

Si tu prends mon exemple et que historiquement tu fais les choses ainsi :

1. Tu crée LinuxFr
2. Tu crée hello()
3. Tu crée AppleFr

Le paramètre que tu aura défini pour hello() sera probablement plutôt LinuxFr que l'interface minimal dont tu as besoin car c'est fastidieux de n'exprimer son typage que par les préconditions minimales aux quelles tu dépend. C'est la force des langages dynamiques, c'est totalement gratuit. Et c'est l'une des forces des langages dynamiques.

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

Merci d'avoir fais la recherche :) Je vais tout de même essayer de varier un peu plus mon vocabulaire.

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

C'est un argument qui se défend, plutôt du côté ressenti humain subjectif (frustration) que technique.

J'ai parlé de frustration, mais aussi d'homogénéité par exemple. Ce qui est moins subjectif.

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

Il n'y a pas de cast explicite, mais dans l'abstrait (peu importe l'implémentation) on peut voir ça comme un cast d'un type implicite qui contiendrait tous les objets (d'un point de vue statique on ne sait en général rien sur le type de l'objet contenu dans une variable, donc interface{}), vers le sous-type des objets qui ont une méthode foo (implicitement défini en Ruby) afin d'appliquer la méthode, avec exception runtime si ce cast échoue (le contenu de la variable, c'est-à-dire l'objet caché derrière interface{}, n'est pas d'un type compatible).

Tu m'a faits douter, mais non le code équivalent en go de ce que j'ai posté plus haut :

package main

import (
    "fmt"
)

type LinuxFr struct {
}

func (c *LinuxFr) foo() string {
  return "linux"
}

func (c *LinuxFr) bar() string {
  return "bar"
}

type AppleFr struct {
}

func (c *AppleFr) foo() string {
  return "ios"
}

func hello(a interface{}) string {
  return a.foo()
}

func main() {
    fmt.Println(hello(LinuxFr{}))
    fmt.Println(hello(AppleFr{}))
}

Ça ne compile pas.

./prog.go:26:11: a.foo undefined (type interface {} is interface with no methods)

Go demande à ce que tu indique le type. Tu dois donc définir une interface avec tout ce dont tu as besoin de dans. C'est tout à fait possible et facile dans mon exemple, mais bien plus complexe dans des cas réels. Donc généralement tu va utiliser un type prédéfini qui possède potentiellement des trucs dont tu n'a pas besoin.

C'est loin d'être identique dans la logique comme dans le comportement.

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

Information que tu n'as pas statiquement à la base dans un langage à typage dynamique, donc impossible à perdre.

C'est mon point : il est bien plus frustrant de perdre quelque chose que l'on a que de ne pas l'avoir.

Dans les langages dynamiques il y a des casts aussi, ils sont juste implicites et partout, ce qui apporte plus d'ergonomie et de flexibilité (moins de contraintes comme tu dis), mais aussi justement moins d'info quand on se plante, voire des erreurs silencieuses (cast inattendu mais valide).

Et bien non. Si je prends ce code là :

class LinuxFr
    def foo()
        return "linux"
    end
    def bar()
        return "bar"
    end
end
class AppleFr
    def foo()
        return "MacOS"
    end
end

def MyFnc(site)
    puts site.foo()
end

MyFnc(LinuxFr.new)
MyFnc(AppleFr.new)

MyFnc() ne cast pas, elle n'a pas besoin de typage nominal. Il faut juste que l'objet qu'on lui passe en paramètre se comporte comme elle l'attends. En go il va falloir que tu explicite cet attendu dans une interface. Quand c'est simple et limité pas de problème quand ça devient plus complexe ça devient plus pratique de réutiliser l'interface initial mais tu a perdu l'intérêt de ton typage dynamique.

J'achète pas trop non plus l'argument manichéen qu'il faudrait être 100% statique ou 100% dynamique

Ce n'est pas mon point. Mon point c'est que le champs où dans les langages statiquement typés (globalement), on se place dans un contexte où l'on pète les informations de types (interface{} en go, Object en java, void* en C et C++,…) on se trouve dans un cadre où le langage que tu as choisi perds une partie de ses fonctionnalités et tu entre pas forcément clairement dans un paradigme différent. C'est un cas où on fait bien plus d'erreur car on ne manipule plus le langage de la même façon où on a l'habitude.

Il n'y a pas de manichéisme là dedans. Une approche différente, que je suis entrain de faire d'ailleurs c'est les intégrations de langage. Si tu met du groovy dans du java, du lua dans du C++ ou du C++ dans du python, tu aussi un changement de paradigme, mais il est bien plus évident à appréhender.

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

Une vision plus positive de la même chose serait : si on veut vraiment filter ou any en Go, on peut du moment qu'on accepte que cette partie du code ait les mêmes garanties qu'en Ruby :-)

Oui mais :

1. c'est très frustrant pour le développeur de perdre l'information de type juste à cause du système de type. Une fonction foo(interface{}) interface{} qui renvoie systématiquement le même type que ce qu'elle a reçu, tu es obligé de gérer des cas que tu sais inutiles juste parce que le typage n'est pas propagé
2. Go n'est pas Ruby. Un langage globalement typé dynamiquement te pousse à tout le temps vivre avec ce genre de choses. C'est prévu par le langage¹ et tu as une homogénéité sur l'ensemble de ton code. Là tu crée une section de ton code qui n'a plus le même typage. C'est un piège plus vicieux.

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

Tu as parfaitement compris mon point :)

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

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