barmic 🦦 a écrit 5976 commentaires

Je ne suis pas d'accord avec lui. Tu ne peux pas garantir malgré toute la bonne volonté du monde que tu ne sera sujet à une injection.

L'enjeu est bien plus grand que ce qu'il semble dire ("ça ne sert à rien parce que sur 8 bits d'entropie on sait pas ce que ça donne"), laisser à Google une position dominante dans :

• le tracking
• la vente de pub
• la mesure de la performance des pubs

Est un énorme problème, ça n'est pas même pas une question de libre ou de déontologie même pour des problèmes de marché ça ne peut pas fonctionner.

On ne peut pas face à cela juste avoir une position résignée. Ça me fait penser au paradoxe de Newcombe que j'ai découvert récemment.

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

C'est vraiment ce qu'on fait avec les Server-Sent Events.

C'est l'association long polling <=> multiplexage de message serveur qui n'est pas systématique. Tu peux faire du long polling pour un usage transitoire à fin de ne recevoir qu'un seul message.

Je ne remet pas en cause ton usage. C'est juste que j'ai dû relire plusieurs fois pour comprendre alors que j'en ai déjà fais.

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

La fonction onreadystatechange de l'objet XMLHttpRequest peut être appelée n'importe quand, quand le navigateur le décide. Mettons que le serveur envoie deux « messages » en même temps. Il peut y avoir du buffering, on peut recevoir une partie du premier, puis sa fin et tout le deuxième message en entier, ou recevoir le tout en trois fois… Bref, il faut analyser le flux au fil de l'eau et trouver les messages dedans. Je ne sais pas si c'est plus clair dit comme ça.

C'est un truc que j'ai eu du mal à comprendre : quand tu parle de requêtes longues, tu parle en fait de multiplexer des requêtes.

Pour moi une requête longue et l'utilisation de long polling c'est surtout le fait que le serveur ne réponde pas au client tant qu'il n'a pas lui même la réponse. Il y a des méthodes pour limiter les risques de timeout en générant du trafic tcp, mais on reste sur une requête → une réponse.

Avec ce genre de multiplexage, je pense qu'il est intéressant d'éviter de recréer la roue et d'utiliser des méthodes plus éprouvé qu'au doigt mouiller. Le SEND de stomp par exemple est fait pour ça ou à minima un format fait pour être streamé comme yaml avec la séparation en document. Je n'ai jamais trop essayé, mais je me demande même si les bibliothèques json orientée streaming ne peuvent pas faire un truc sympas pour ça (tu stream un tableau json infini dont chaque élément est un message.

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

Pour ça il est possible d'utiliser dpkg-divert qui est fais pour ça. Ça ne garanti pas que ça ne va pas finir par casser quelque chose, mais c'est la méthode. Les quelques rares fois où je m'en suis servi c'est pour faire du wrapping ou pour des paquets qui ne venaient pas des dépots debian.

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

J'ai créé une entrée dans le suivi pour le mettre en place : https://linuxfr.org/suivi/desactiver-floc-sur-linuxfr

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

Bref ils ont tenté de faire un navigateur internet ;)

Eh oui. On parle d'une époque où les usages restaient à faire. Difficile de prévoir à l'époque comment internet allait être utilisé.

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

Je ne l'ai pas retrouvé moi non plus. J4avais entendu ça dans un podcast, mais j'ai dû me fourvoyer.

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

Ce que tu décris me fait penser aux militaire. On cherche à ce qu'ils soient dans un état d'esprit particulier. Une acceptation forte de la hiérarchie bien sûr et j'imagine cet esprit corps. J'imagine que ça a été mis en place aussi par crainte du coup d'État.

Je trouve triste (sincèrement) de penser que c'est l'esprit corps qui protège la corporation alors que c'est l'inverse… Combien faudra il d'exemples pour que ça rentre dans les meurs ?

J'ai l'impression mais ça n'est qu'une impression que le changement va se faire par la tête. Le politique est plus sensible à la pression sociale que le policier et il y a des cas médiatisés où il est très difficile, même pour les spécialistes de la langue de bois, de dire qu'il n'y a pas de problème.

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

Le point principal étant "la suite elastic n'est désormais uniquement disponible sous des licences non libres."

Ils ont annoncé redistribuer le code en apache avec un délai. C'est ce qu'on retrouve avec l'open core de gitlab par exemple.

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

Amazon ne peux se payer le luxe d'avoir à négocier avec un partenaire qui peux via sa licence l’empêcher de proposer telle ou telle offre, donc il n'ont pas le choix que forker.

D'autres cloud ont des partenariats avec elastic et ça n'a pas l'air de les tuer. Je vois pas en quoi c'est du luxe.

Par contre ça va être intéressant à voir sur qui va avoir le plus de contributeurs: est-ce qu'un projet principalement hébergé chez Amazon va attirer des dev, plus qu'un code ouvert mais pas open source.

J'ai beaucoup de mal à imaginer amazon savoir gérer un projet communautaire. Je ne les ai jamais vu ailleurs que dans leur propre écosystème.

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

Il n’y a aucune raison de faire entrer de force ces fonctionnalités dans un logiciel sans rapport, le navigateur Web.

L'usage. Tu as une vision de ce qu'est un monde parfait pour toi, mais c'était l'époque des gens qui doivent installer des codex sur leurs machines et à qui il manque toujours le bon. C'est un concept très abstrait pour l'utilisateur et qui peut facilement mener à l'installation du « pack de codec 2000 ++ qu'il est trop bien mon pack promis on est des gentils ». Au final les gens utilisaient flash, ça apportait un standard de fait, l'intégration était propre (avec si je ne m'abuse gestion du bitrate en fonction du débit etc streamer une vidéo ce n'est pas tout à fait la même chose que la télécharger et la jouer) et ça permettais quelques fioritures comme les liens placés en overlay de la vidéo (très utilisé sur youtube).

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

Je n'ai fait que citer 2 exemples qui prouve que la démocratie ce n'est pas FORCEMENT le meilleur système. Je n'ai pas généralisé.

Oui mais tu les a mentionné c'est que tu y voyais un lien avec la création d'une distribution ?

L'arrivée de systemd dans debian a vu naitre nombre de soucis de compatibilité

Je n'en ai pas rencontré mais je ne doute pas.

des packagers vers Devuan, pendant plusieurs mois nombre de paquets ont changé de mainteneur attitrés

J'ai surtout vu des paquets passer d'un mainteneur à une équipe. Ce qui est privilégié chez Debian depuis plusieurs années pour un tas de bonnes raisons.

Le projet est un élément crucial, tout le reste autour c'est du sucre.

La gouvernance d'un projet fais parti de celui-ci. La manière dont les décisions sont prises c'est évidement d'une importance majeure. Je ne vois pas où est le débat.

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

Mais leur système fonctionne : la preuve, ils ont pris la bonne décision en envoyant bouler ceux qui ne codent pas mais qui passent leur temps à dire aux autres comment agir. :)

Tu parle des DPL là ?

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

Ils ont même créé let's encrypt ces gens qui ne devraient pas s'intéresser au coté serveur. Je ne me souviens avoir vu beaucoup de monde se plaindre qu'ils sortaient de leur platebande à ce moment là.

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

Et j'ai oublié

Python sans Guido : qui commence à introduire des fonctionnalités non-cohérente avec le reste de l'écosystème

Debra et Ian Murdok ont quitté le projet il y a 25 ans, c'est tout de même une belle pérennité non ?

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

Je rajouterai même que (sans troll)

Si ce n'est pas du troll c'est un problème de connaissance. Linux et python sont très collégial avec des RFC (on parle beaucoup actuellement de celle pour intégrer rust dans le noyau) et des PEP. Ces projets ne sont d'ailleurs pas exemptes de très gros flameware ce qui a d'ailleurs fini par pousser Guido à ne plus vouloir être à la tête du projet. Quelqu'un qui est là pour trancher chez Debian ça existe c'est le DPL, son boulot c'est de trancher quand toutes les actions standards n'ont pas permis de converger vers un choix.

Dans une cuisine, tu n'as qu'un seul chef qui donne les ordres.
Dans un navire, tu n'as qu'un seul capitaine qui donne les ordres.

Et donc il faut que ce soit le cas partout ?

Debian qui sort une version tout les 15 ans

(j'assume qu'il ne s'agit pas de troll) Debian sort une version sort une version tous les 2 ans environs et maintiens la version précédente pendant un an. Le rythme de sortie n'est pas dicté que par la vitesse. Proposer un support de 3 ans avec une fréquence de sortie plus régulière demande à maintenir plus de version en parallèle (et plus longtemps - là il n'y a qu'un an tous les 2 ans où ils maintiennent 2 distributions -).

lors de l'arrivée désastreuse de systemd dans la distro a fait partir une grosse partie des packagers historique (laissant les inexpérimentés)

Grosse comment ? Seuls les inexpérimentés sont resté ? Tu as quelque chose qui appuis ça ?

[…] la démocratie c'est pas forcément le meilleur système.

C'est ton avis, il n'est pas partagé par les contributeurs à Debian, mais rien oblige à suivre Debian. Note toute de même que la gouvernance d'un projet, en particulier quand le projet se veut communautaire, est un élément crucial.

Je ne comprends pas ces critiques, l'exemple de Debian ici et de la FSF me semble aller complètement en faveur de Debian.

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

Quand je vois les protocoles de gestion Debian, j'ai l'impression d'avoir affaire à un véritable gouvernement.

Tu dis ça parce qu'ils ont une constitution ? :)

Tant de blablas, de procédures, de votes juste pour savoir si Debian est pour ou contre le retour de RMS.

C'est super important. La gouvernance d'un projet ce n'est pas anodin, les utilisateurs de CentOS peuvent en témoigner. Avoir un projet qui dure dans le temps (28 ans) sans un leader fixe comme peuvent l'être RMS ou Linus, c'est compliqué.

Pour le cas présent on a beaucoup parlé de la représentativité d'une signature comme celle de framasoft par exemple ou justement du manque de clarté à la FSF. Ici on voit comment c'est d'être limpide.

Je pense que l'organisation de Debian est intrinsèque, ça fait parti de sa nature et les gens qui y contribue veulent un projet avec ce niveau de démocratie.

Si tout ce temps était passé à développer à la place on aurait des bureaux encore plus stables, non ?

D'une part je ne suis pas sûr qu'il faille sur estimer le temps passé sur cette affaire, c'est pas forcément du temps pris sur du développement (au sens large), mais peut être pris sur d'autres troll dans d'autres channels/forum/irc. Et avoir des décisions plus unilatéral ne réduisent pas forcément la discussion (on le voit avec la FSF). Pour le coup vu les prémisses et le résultat si Debian avait adopté la position de son DPL, ça aurait beaucoup fait parler sans limite de temps. Là le vote sonne la fin de la récrée tout le monde se pli au vote, on commente vite fait et on passe à autre chose.

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

Reste plus qu'à avoir du réseau en montagne.

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

T'es entrain de dire que tu ne trouve pas d'autres moyens que ftp pour partager des fichiers ? Depuis megaupload combien de services ce sont montés à héberger sois-même ou a acheter, limité dans le temps ou pas, pour des volumes plus ou moins important,… Le premier qui me vient en tête c'est hubic 25Gio gratuit faut juste créer un compte. Il y a quelque chose que je ne comprends pas ?

---

C'était un peu la solution de facilité le FTP du coup

Leur gestionnaire de fichier gère très probablement FTP, hein ?

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

J'ai l'impression que tu perçois le ton se voulant humoristique de cette dépêche comme de la plainte, et ça doit franchement rendre sa lecture frustrante ;-)

Non c'est plutôt insupportable. D'une je trouve que la forme rend le fond cryptique et d'autres part oui j'y vois beaucoup de plaintes. Le fait qu'il y en ai des tartines et que ça n'est jamais véritablement désamorcé en fait pour moi une série de critiques sous un verni de moquerie.

Mais je ne l'aborde que parce que tu l'aborde, c'est mon ressenti et mon point de vu. Je ne te le reproche pas.

Nginx a été conçu au début des années 2000, on n'était loin d'imaginer HTTP2 à ce moment là et bien sûr qu'il y a des défauts comme ça.

Alors non ça n'est pas un argument recevable. Ils ont modifié l'implémentation de cette directive pour qu'elle s'applique en ayant conscience de la couche application ce qui n'était pas nécessaire avant. Ça n'est pas lié à la dette technique. C'est un choix tout à fait assumé où ils ont voulu simplifié la vie de leurs utilisateurs au détriment de la cohérence. C'est leur choix, je le trouve regrettable et je suis content de ne pas avoir eu affaire à lui quand j'ai eu des vrais contraintes de connexions sans contraintes de requêtes.

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

J'ajoute le lien de Florent Gallaire qui est intéressant :

https://fgallaire.flext.net/debian-et-rms-richard-stallman-la-montagne-a-accouche-dune-souris/

Il y fait mention de problème lié au fait que le vote est publique.

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

XMLHttpRequest est anterieur de plusieurs années à json

D'accord, mais tu n'étais pas obligé de transmettre du XML avec. Tu pouvais transmettre des données plain text, des scripts javascript… bref, l'objet n'a rien de spécifique à XML et en programmation on a quand même pas mal l'habitude de séparer les probèmes…

Ce n'est pas en opposition avec ce que je dis.

Le long polling c'est un peu plus subtile que ça. Il faut utiliser xhr, mais en gérant le timeout et en gérant une boucle.

C'est décrit dans la dépêche… qui reste une dépêche, pas une doc.

Ok effectivement. Je n'avais pas bien suivi.

Je ne sais pas précisément ce que tu entends par là mais sur cette page : https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest

Note: This feature is available in Web Workers.

Donc si tu dis que fetch est utilisable dans un worker, ce n'est pas un contre exemple d'un truc que fetch peut faire et pas XMLHttpRequest

et juste en dessous ils parlent des services workers. C'est ce qui sert à gérer des applications offline entre autre.

Le passage de la doc de Nginx n'a rien de surprenant : il avertit simplement que le paramètre dont il est question n'a pas exactement le même sens en HTTP 1.1 qu'en HTTP 2, justement pour qu'il ait « le même effet intuitif ». Ils font le même amalgame que moi (mais avec rigueur).

C'est marrant que tu te plaigne que xmlhttprequest soit nommé ainsi alors qu'il peut servir pour autre chose et que tu ne vois pas de problème que limit_conn limite les requêtes et pas les connexions… Pour le coup perso j'ai des problématiques où une connexion et une requête ça n'est pas du tout la même chose, je suis bien content de ne pas reposer sur lui pour le coup parce que du coup je vois pas comment distinguer les 2.

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

On voit d'un coté beaucoup de gens se plaindre ici même pour dire que le web c'est trop compliqué qu'il faut passer à gopher gemini (voir qu'il faut du web out of browser) et de l'autre quand une fonctionnalité est désactivé c'est la fin du monde.

Bref on entend surtout des gens gueuler et a force de tenter de se faire entendre pour tout et n'importe quoi, il ne faut pas être surpris de ne pas être écouté

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

D'autres remarques :

Et puisqu’il faut un terme branché pour désigner tout ce mécanisme de mettre à jour la page avec des nouvelles données sans recharger la page en entier (truc de fou à l’époque !), le concept d’AJAX est né (Asynchronous JavaScript And XML - hé hé oui, on ne se débarrasse pas de XML comme ça, même dans le terme répandu, même quand XML n’est pas du tout impliqué. Parce que si des gens font bien transiter du XML de temps en temps, bien souvent, on utilise du JSON. Bien joué, Alex !).

XMLHttpRequest est anterieur de plusieurs années à json. Json a même était créé du fait de la popularité de XMLHttpRequest. Quand il a était implémenté par les navigateurs c'est bien du xml qui transité car c'était le seul format normalisé.

On peut lancer des requêtes pour envoyer des données au serveur, mais on peut aussi envoyer une requête de longue durée (long polling) et lire les données qui arrivent au fur et à mesure.

Le long polling c'est un peu plus subtile que ça. Il faut utiliser xhr, mais en gérant le timeout et en gérant une boucle. Tu tombe instantanément dans un callback hell avec xhr là où les promesses ou async/await vont être bien plus confortable à utiliser.

Mais le principe reste le même et tout ce que peut faire fetch peut être fait avec XMLHttpRequest[…]

Non, fetch peut être rerouté vers un worker par exemple, il y a un travail en cours pour pouvoir annuler des requêtes (particulièrement utile pour ton scope de requêtes longues).

une sorte de keep-alive, quoi - et non, je ne sais pas pourquoi le keep-alive de TCP ne suffisait pas

Le keep-alive ne remonte pas jusqu'à l'application, il est global, il est de 2h généralement,…

De plus, les navigateurs, en HTTP 1.1, se limitent avec leur configuration par défaut à 6 connexions simultanées vers chaque hôte. Ce n’est pas le cas en HTTP 2, et donc peuvent surcharger plus facilement un serveur si celui-ci ne gère pas bien les connexions simultanées.

Je n'ai pas les moyens de le tester, mais je ne trouve rien qui va dans ce sens et ça m'étonne beaucoup. HTTP2 est là pour réduire le nombre de connexions pas l'augmenter. Qu'ils arrêtent de limiter le nombre de requêtes, ça ne m'étonnerait pas, mais le nombre de connexion ?

Je vois dans la doc de nginx des choses surprenantes comme :

In HTTP/2 and SPDY, each concurrent request is considered a separate connection.

Documentation de la directive limit_conn

C'est pas ça qui t'a induit en erreur ?

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

Je comprends la réaction de libreforce. Si ssh n'avait pas eu ce succès, on aurait un port réservé pour rien, mais je pense qu'on se formalise beaucoup aujourd'hui. Si tu regarde la liste des ports réservés, il y a pas mal de réservations qui sont inutiles (le plus connu c'est le port 666 pour doom, mais il y en a des dizaines d'autres).

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