barmic 🦦 a écrit 5975 commentaires

J'aime bien Rust, mais justement, quand on écrit un OS, on tape pas souvent le unsafe ?

Pas autant qu'on ne pourrait l'imaginer je pense. Ça va concerner les drivers, le bootstrap du noyaux, quelques interfaçages pas niveau (pour les IRQ j'imagine), mais il reste un tas de choses à faire comme le scheduling, le mappage mémoire, la pile IP,…

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

C'est pas faux. J'entends souvent ça pour la résilience, mais c'est vrai. Par contre j'ai pas encore tout lu sur le sujet mais le tout est URL fait plutôt peur pour la sécurité.

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

GNU a passé 7 ans à reconstruire un userland de 83 à 90 et en 90 ils se sont attaqué au dernier morceau qui leur manqué pour avoir un OS. La démarche est largement moins éparpillée. 30 ans après on peut les juger, mais avoir des concepts novateurs n'est pas déconnant pour se démarquer. L'équipe limité dont tu parle a commit des petites choses tel que qu'emacs ou gcc. Ils n'ont pas démarré de but en blanc tout un OS en commençant par les parties les plus compliquées.

Redox ne s attaque pas à Linux mais a OpenBSD ils ne cherchent pas a avoir tous les pilotes mais a avoir un os sécurisé.

Ça n'est pas mis en avant. A part si on fait du rust signifie ça ce qui n'est évidement pas le cas. C'est dis dans leurs objectifs, mais il y ai aussi dis qu'ils veulent être une alternative à linux. Ce qui est dommage je trouve dans cet optique, c'est que :

• en tant que développeur, ils ne mettent pas en avant un design qui ferait qu'ils sont plus sécurisé, c'est juste rust. Mais rust ne fais pas tout et je paris plus sur les archi logiciel découpées d'OpenBSD que sur rust
• d'un point de vu de gestion de projet, c'est la gestion des failles de sécurité qui est importante, la question n'est pas de savoir s'ils ont ou pas de failles, mais qu'est-ce qu'il se passera quand il y en aura (temps de réaction, mailing list,…) je n'ai rien vu à ce sujet sur le site, mais s'ils veulent attirer les boites qui veulent de la sécurité c'est le plus important

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

Mais je suis vraiment curieux de voir ce que ça donne, si on voit réellement rejaillir les avantages annoncés du langage sur le produit fini.

Tu peux regarder la liste des CVE liées à des buffers overflows. Hors unsafe ça fait parti des classes d'erreurs qui sont impossibles (avec d'autres comme les races conditions, les danglings pointers,…).

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

Ça me fait toujours très peur de voir des projets s'attaquer à un projet complexe et trouver le moyen de s'éparpiller sur un paquet de sujets. Pour des projets comme Haiku ça s'explique car c'est un écosystème qui existait déjà et qu'ils cherchent à maintenir. De plus l'ambition n'est pas de remplacer linux.

Il faut combien de temps pour stabiliser btrfs ou zfs ? Se lancer dans un autre FS, c'est s'acheter des soucis. Je n'ai aucun doute que c'est fait avec toute la bonne volonté du monde, qu'avec un couplage de dingue ils peuvent faire un truc super efficace, mais rester un peu concentré sur avoir un noyau me paraît de loin plus important.

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

Alors je ne jouerai pas avec ton script par flemme de lister pleins d'url. Par contre je viens de vérifier et asyncio et single core donc pour utiliser tout la puissance de ta machine il faut effectivement toi même créer un thread pour chaque cpu et chacun lance des requêtes. Ça devrait être mieux.

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

Pour java le terme inférence me semble un peu galvaudé. C'est plus comme ne pas déclarer 2 fois le type d'une variable. Si une variable est initialisée à sa déclaration, il est possible d'utiliser le mot var à la place du type pour choisir le type de la partie droite.

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

Jusqu'à présent, la plupart des banques proposent un boîtier qui sert de second moyen d'authentification.

Juste un token RSA ? Ça ne me semble pas compatible avec DSP2.

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

Je te rejoins. Je n'ai pas le temps de tester le code, mais j'ajoueterais :

• quel est l'impact de BeautifulSoup dans ton thread ?
• tu fais uniquement 3 requêtes ? Tu as combien de core ? Si tu parallélise avec un nombre inférieur ou égale à ton nombre de core tu n'a pas de context switch. Même si tu n'a qu'un seul core tu n'a que 3 context switch
• je suis pas sûr de voir de lissage dans ton test, même si en soit ça doit plus impacter les threads systèmes

J'ai vite fais trouvé un bench qui fait exactement ce test mais sur qui montre plus l'évolution en fonction du nombre de requêtes, jusqu'à 10 url les threads sont meilleurs (contrairement à toi il utilise un pool de threads pour ne pas exploser son CPU et éviter de payer de trop le coût de création des threads). Tu peux trouver le lien ici : A better way for asynchronous programming: asyncio over multi-threading.

est-ce que si on implémente intelligemment les green threads sur plusieurs threads systèmes (éventuellement, en fixant ces threads sur des cœurs), on peut gagner en perf (en utilisant X green threads sur N cœurs versus X threads systèmes sur N cœurs) ?

C'est précisément ce que fait go par exemple.

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

Mais tu pars du postulat qu'il n'y a pas de context switching dans les green thread ce qui me semble tout à fait erroné.

Je n'ai pas était très précis, quand je parle de context switch, j'entends celui qui est le plus classique, qui s'appuie sur une interruption, implique de vider le core du CPU ainsi que d'autres choses comme le TLB. Les greens threads sont coopératifs, ils impliquent beaucoup moins de choses, on en nettoie pas le core (seuls quelques registres sont changé), ni le noyau¹, ce qui en fait une opération drastiquement plus performante.

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

Bref, l'utilisation de l'e-mail comme identifiant soit-disant indispensable est très galvaudé, normalement on aurait juste à le mettre à jour auprès de nos contacts qu'on connaît, et un nombre limité d'institutions — comme on faisait avant quand on changeait d'adresse physique… — et ça irait très bien.

Tu t'intéresse à ce qui pourrait être alors que je m’efforce de décrire l'existant. On a une fonctionnalité d'internet acentrée, mais l'usage en fait quelque chose de plutôt centralisé et laisse la porte ouvertes à des problèmes liés aux monopoles. Ce n'est pas la faute de l'email, on ne va pas interdire email, mais il y a tout de même le problème.

Alors comme avec fearan au-dessus, je pense que tu as mal compris (ou j'ai mal expliqué) mon point de vue : certaines choses se prêtent naturellement au monopole, et ne peuvent qu'y mener. Je pense que c'est le cas avec la « recherche » au sens d'outil utilisé par l'humanité pour répondre à toute question généraliste. Il ne peut pas exister de « concurrence » de l'oracle universel.

Tout usage se prête naturellement au monopole. Quand tu n'a pas l'expertise et que tu n'a pas d'intérêt particulier, tu es facilement enclin à aider un monopole. Comme le montre l'e-mail, c'est l'usage qui crée le monopole (ou la situation de quasi-monopole) ce n'est pas intrinsèque.

Mais dans le domaine dont on parle, ça n'a pas vraiment de sens.

C'est quasiment la définition des GAFAM. Si ça n'a pas de sens ici, je ne vois pas où ça aurait du sens.

C'est ce que tu affirme, mais ça n'est pas établi.

Peut-être faudrait-il que j'étoffe mon argumentaire, mais j'y réfléchis et j'ai débattu depuis plusieurs années (pas en grand comité, certes), et je n'ai jamais vu de contre-argument réellement pertinent.

Il existe plusieurs tentatives de créer des moteurs de recherches généralistes fédérés. Pourquoi les interdire ?

Le but ça n'est pas d'interdire les tentatives de choses plus « éthiques », c'est de dire que de toutes façons, elles sont vouées à l'échec. Le but c'est d'interdire Google ou tout autre qui pourra le remplacer (mais je pense qu'au niveau où ils sont, c'est in-rattrapable ; cf. déjà l'analyse d'Assange d'il y a 10 ans déjà).

Je ne comprends pas le but n'est pas d'interdire, mais comme il vont se planter, interdisons les (parce qu'interdire les moteurs de recherche ça interdit de fait YaCy ou seeks) ? Avant la création de wikipedia il y a eu plusieurs tentatives qui fur des échecs, quels sont les arguments qui permettent de dire que ce sera toujours un échec ? Tu base se savoir sur quelque chose de solide ou juste sur la volonté de détruire google ?

Google peut très bien se faire tronçonner comme ce fut le cas d'AT&T.

Mais en plus de ça, c'est très dommageable d'interdire l'échec. C'est en expérimentant qu'on découvre.

Je ne sais pas trop quels biais tu évoques, mais oui parfois c'est fait « par réflexe », sans penser aux inconvénients différents que ça va amener.

• on voit généralement la centralisation qui nous intéresse
• comme tu le dis on veut du décentralisé sans se rendre compte de ce que ça signifie
• on ne s'intéresse pas aux usages qui font le gros d'une centralisation

En soit on s'inquiète des centralisations qui ont du succès sans se rendre compte que ce qui est décentralisé peine à avoir du succès (il tend vers une centralisation). C'est plus simple à l'usage et les utilisateurs adorent ça, c'est normal d'ailleurs. Si on avait yahoo, bing, google, baidu et yandex qui avaient chacun 20% requêtes de recherche, tu ne pourrais pas dire les moteurs de recherche c'est nécessairement mal.

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

Apparemment si Why are new versions of Manjaro being released?

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

Sans doute mais tu commences par "je ne suis pas d'accord" pour au final complété quelque chose et corriger quelques détails.

Je ne suis pas d'accord pour dire que si on a pas d'implémentation asynchrone de bout en bout, on lance des threads systèmes ou des process. En aucune manière, même pas une solution du pauvre. Ça adresse des problématiques différentes. Je pense que c'est quand même dis clairement dans mes 2 commentaires.

Je ne vois pas en quoi ça améliore le context switching.

Tu ne déclenche pas de contexte switch en passant d'un green thread à un autre (ils sont coopératifs). Je pense que c'est ce qu'entends wikipedia par thread activation. Donc tu l'évite tout simplement. Si tu implémente le switch entre green thread par des contexte switch OS ce sont des threads systèmes.

D'après https://en.wikipedia.org/wiki/Green_threads#Performance, c'est même l'inverse et ça me parait logique vu que c'est une couche d’abstraction en plus et que ça ne tiens pas en compte du matériel (mono CPU et pas de prise en compte du multi-threading physique)

Ce que dit wikipedia c'est qu'un process qui tiens 25 green thread qui se fait prempt va prempt les 15greens threads seront préemptés… C'est assez logique. C'est pour ça que les implémentations actuels traduisent toutes tes opérations en asynchrones. Je le disais peut être pas de la même façon dans mon premier commentaire.

Pour ce qui est des IO, en terme de débit les api synchrones sont meilleures. Mais pour la latence quand tu reçois un paquet de requêtes c'est la latence qui t'intéresse plus que le débit.

Après, entre la définition (d'ailleurs chaque langage a un peu son nom a lui), l'implémentation (pareil, très fluctuent) et ce que ça fait réellement.

A part la réimplémentation ou non des appels synchrones, je n'ai pas vu tant de différence.

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

Bref, y'a plein de raisons pour moi (duck-typing compris) pour ne pas le classer dans les typages fort.

Tu mélange "trouver des inconvénients à un typage" ou "ne pas aimer un typage" et "typage faible". C'est un mélange sémantique.

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

J'ai testé la transpilation de Rust (qui est loin d'être du duck-typing) en js (ou webassembly) et ça marche plutôt bien.

Ça tout le monde le fait. Compiler d'un langage à un autre c'est simple. C'est l'interfaçage qui est compliqué. Comment utilise-tu une bibliothèque js ?

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

T'as un peu redis la même chose, non (peut-être mieux je te l'accorde) ?

Je voulais signifier que les threads/processus et les greens threads (tel qu'ils sont implémenté maintenant) résolvent 2 problèmes différentes :

• le premier sert à utiliser toute la puissance des CPU
• le second les greens threads et tout ce qui est IO asynchrones sert à réduire le latence

Un vielle exemple de l'impact que peux avoir le scheduling et qui fait un peu ressentir la différence c'est le vieux patch du noyau. On ne touche pas à l'usage CPU, ni au temps d'exécution, mais on a plus de latence.

La commutation de contexte est surtout pénalisante quand celle-ci est lente donc les threads sont pour le coup bien moins handicapant que les processus. (qui en plus différent d'un OS à l'autre)

Je suis pas persuadé que ça face une différence perceptible et quelques soit l'OS ça demande de passer en espace noyau et nettoyer le core sur lequel il s'exécute.

Tu as l'air de suggérer que les green threads n'auraient pas ce genre de soucis. (commutation de contexte)
Ça me parait tout à fait infondé et je suis curieux d'avoir des sources sur les propos avancés.

C'est la définition des greens threads donc je sais pas trop quoi dire. T'a l'air de ne pas trop te fier à wikipedia, donc je te laisse choisir la source qui te plaira. Je serais curieux de connaitre une source qui n'explique pas que c'est des threads en espace utilisateur. Après le fait de l'implémenter par de l'asynchrone "caché" n'est pas obligatoire, mais sans ça ça n'a pas vraiment d'intérêt. C'est pour ça que java a jeter sa vielle implémentation il y a un paquet de temps, mais qu'ils y réfléchissent de nouveau.

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

En quoi trouves-tu que le duck-typing soit pertinent pour TypeScript ?

Pour s'interfacer avec un langage à prototype comme l'est javascript, ça me semble être la meilleure solution.

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

Tout à fait. De plus :

voir de faire du duck typing

Non python ne fais pas du duck typing quand ça l'arrange, il fait toujours du duck typing, c'est à dire qu'il ne fait pas un typage nominal, mais structurel¹ et qu'il calcul ce typage au runtime. En python une variable est du bon type si et seulement si elle possède la propriété ou la méthode utilisée et pas si la type de l'objet est du même nom qu'attendu.

La force ou la faiblesse d'un typage c'est ça capacité à caster. Quasiment tous les langages ont un cast à un endroit (par exemple pour pouvoir affecter 1 à un entier, un long, un double), mais certains en font plus et en font de l'implicite.

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

Tu as tout à fais raison, pour le fonctionnement, je me suis trompé par contre.

Je pense que les coûts sont assez similaires.

Suivre une série de pointeurs dans un arbre balancé et faire une série d'appels systèmes pour lister le contenu des répertoires puis supprimer chaque fichier n'a sans doute pas le même coût.

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

et ça ne protège que si l'attaquant ne connaît pas le matériel autorisé parce qu'il peut tout à fait mentir au système

Ça ne doit pas être trop compliqué de simplement répliqué l'identifiant que tu as du coté clavier.

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

Et lui de te répondre que tu tu as une attaque matériel, wayland ne fera rien pour toi.

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

De ce que j'ai compris DSP2 n'est pas compatible avec ce genre de token rsa. Le principe est d'avoir un lien plus fort. Ta banque ne te file pas seulement un code mais aussi à quoi il va servir.

cf: https://www.certeurope.fr/blog/dsp2-et-authentification-forte-que-prevoit-la-directive-europeenne/ article 97 paragraphe 2

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

En ce qui concerne l'identifiant — l'adresse e-mail —, qui était peut-être plus ce dont tu parlais, je dirais qu'il reste la possibilité d'avoir son propre domaine même si c'est difficilement transposable au grand public. Cependant, ce dernier est plus habitué à accepter des changements d'adresse de la part de ses correspondants, je pense, même si c'est un obstacle valable que tu fais bien de mentionner.

Ce sont d'énorme obstacle. Si tu ne change pas régulièrement d'adresses c'est très difficile de retrouver partout où tu l'a utilisé, le faire changer partout où c'est possible, maintenir une redirection pendant un certains temps.

Nan mais ce procès je l'ai suivi et vécu dans ma jeunesse

Vécu ?

Le résultat est nul puisque ça n'a pas fait décoller les alternatives comme Firefox, mais c'est Google Chrome qui l'a remplacé avec ses propres abus : API web utilisée par FF dirigées par Google, notamment contre les bloqueurs de pub ; bientôt plus de login Google sur les browsers dérivés (d'un côté, tant mieux, bien fait pour leur gueule), etc.

C'est un autre problème et je ne dis pas que les lois sur les monopoles ne devraient pas changer.

En démocratie on interdit les choses qui peuvent détruire la démocratie, c'est un fait. Pour moi, Facebook et Google détruisent la démocratie, et je pèse mes mots. Je ne veux pas interdire tout initiative privée, ni l'exploitation commerciale, ni impliquer la férule de l'État… je parle juste d'arrêter les choses qui font dérailler la société.

Mais ça ne marchera jamais. C'est une démarche qui est parfaitement vaine. Déjà elle est nécessairement en retard. Tu tente d'exprimer après coup ce qui a posé problème pour l'interdire, alors que le monopole est la cause racine, c'est une question qui est étudié depuis des décénies et on peut arriver à les empêcher. Ça marche particulièrement pour les entreprises physiques. On va pas s'étonner d'avoir plus de recul là dessus que sur le fonctionnement d'internet (et je ne parle pas du fonctionnement technique, mais de l'économie et la sociologie d'internet).

je parle juste d'arrêter les choses qui font dérailler la société.

Genre les monopoles ?

Et je veux bien croire qu'Huxley a dépeint un monde plus proche de ce qu'on voit en général aujourd'hui, mais les mesures proposées dont j'entends parler en ce moment-même pour palier la crise actuelle me rappellent quand même les méthodes décrites par Orwell…

Bien sûr. Mais pour chaque cas que tu as en tête et qui généralement fait réagir, combien est-ce qu'il y en a qui utilisent plus la méthode Huxley (d'autant que certaines perdures depuis des dizaines d'années) ? Je ne dis pas que l'autoritarisme est impossible, mais qu'il est très faibles, limité dans le temps et l'espace là où les méthode décrites par Huxley fonctionne sur la quasi totalité do globe depuis des dizaines d'années.

je reçois quand même un texto d'une machine qui me dicte ma conduite, je ne peux plus voir la plupart des être humains proches que je voyais avant ou alors ils ont tous des réactions soupçonneuses… bref.

Je vais prendre bien soin d'ignorer ostenssiblement ce passage.

Mais en tous cas, il reste qu'un moteur de réponse à tout sur tous les sujets ne peut pas être « fédéré », comme un réseau social global généraliste.

C'est ce que tu affirme, mais ça n'est pas établi. Il existe plusieurs tentatives de créer des moteurs de recherches généralistes fédérés. Pourquoi les interdire ?

Après je suis toujours septiques de la recherche de toujours tout le temps vouloir du fédéré/acentré/décentralisé. Ça cache systématiquement d'énormes biais.

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

Il me semble qu'il fut y un temps jadis où il était imaginé qu'il remplace gecko. Dans tous les cas au moins par moi :-)

Il va devenir le hurd des moteurs html ?

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

Le contrôle d'une population par la peur et le totalitarisme a des limites, pleins de limites. Alors que contrôler une population par ses besoins,en construisant ses envies, on en a des exemples tous les jours. C'est bien plus insidieux et on peut facilement se laisser aller au confort que ça procure.

C'est une discussion assez classique, tu trouveras pleins de choses sur internet. Perso j'aime bien "Se distraire à en mourir" de Neil Postman.

Ça n'enlève rien à 1984, c'est juste de l'agiter comme un épouvantail qui m'a fait réagir.

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