raphj a écrit 1761 commentaires

Effectivement, toutes mes confuses ! ;-)

C'est mieux de rentrer dans le moule.

30min d'attente pour un lock GPS, s'il se lock du tout.

Ne serait-ce pas un problème de récupération de données AGPS ? On peut la forcer avec l'application Sat-Stat par exemple.

En plus sémantiquement, la formulation sus-mentionnée indique qu'il n'y a qu'une seule personne à la fois lisant linuxFR.

Pas forcément, dans la phrase « Le mouton est un vertébré de la famille des mammifères », on ne parle pas que d'un seul mouton.

L'intérêt d'un détecteur est de vérifier que ce qu'on fait a bien de l'effet et d'éviter la situation où on se sent faussement en sécurité. Et si ça ne marche pas, de pousser à chercher d'autres solutions.

Ça permet aussi, si la mesure de protection (ouvrir les fenêtres) est inconfortable (trop froid, trop chaud, quelqu'un fume dehors à côté régulièrement), de savoir quand il est nécessaire de l'appliquer et quand on peut faire une pause.

C'est toujours pareil avec cette pandémie, bien souvent on ne peut pas maximiser un facteur, seulement faire des compromis.

(Je n'ai pas de détecteur et n'ai pas prévu d'en prendre)

Il reste « La 6G pourrait voir le jour en 2030 » et « La Chine, Huawei et des opérateurs chinois on presenté l’ánnée (sic) dernière un nouveau protocole internet baptisé New IP devant l'Union Internationale des Télécommunications. Il s'agit en fait d'une modification du protocole TCP/IP »

Et aussi cette affirmation sans justification (perso, je ne dispose pas de boule de cristal) : « la 6G […] sera nécessairement la prochaine étape majeure de la révolution numérique. »

Rien de concret sur la prétendue menace (peut-être réelle - aucune idée, du coup), que du blabla, ou alors je suis passé à côté de l'article.

La chine peut déjà contrôler nos réseaux depuis belle lurette parce c'est à elle qu'on fait appel pour les mettre en place et les maintenir : 5G: The outsourced elephant in the room. Nous, on ne sait plus faire, alors bien sûr que c'est « la Chine » qui a l'expertise aujourd'hui qui permet de proposer de nouveaux protocoles mobiles.

Je ne connaissais pas Koena mais ça donne envie d'en savoir plus. Une belle réponse bien sentie.

Quand à FACIL'iti, je n'en n'avais pas entendu parlé mais ça ne donne pas une impression positive…

Il y en a qui n'ont pas encore compris l'effet Streisand. On comprend, ça ne fait après tout que 18 ans qu'on connait…

de mon côté j'ai découvert le terme pendant les études et la première fois que j'ai entendu le terme utilisé comme ça, j'étais surpris. Je ne pense pas l'avoir rencontré hors des études ou du boulot.

Il me semble que beaucoup de téléphones Android viennent avec leur mémoire interne / carte mémoire formatée en ext4. C'est aussi le format utilisé sous Mobian pour la mémoire interne du PinePhone.

J'avais vaguement regardé des comparaisons entre ext4 et f2fs il y a quelques temps pour un usage sur téléphone Android et je n'ai jamais réussi à arriver à une conclusion claire sur lequel est le mieux. D'ailleurs, j'ai l'impression que si c'était si claire, les téléphones Android viendraient quasi systématiquement avec un formatage f2fs, non ?

Mon dernier téléphone Android était vendu avec sa partition data formatée en f2fs, mais un bug dans son pilote f2fs a donné du fil à retordre aux gens qui faisaient des ROMs custom pour ce téléphone (bug impliquant des problèmes de compatibilité, pas de stabilité de perf, de mémoire). J'ai utilisé LineageOS avec ext4 sur ce téléphone et n'ai pas perçu de différence de performance à l'utilisation. Quant à l'usure, je n'ai aucune donnée.

D'après des choses écrites en 2017, ext4 était plus stable à cette époque que f2fs, dans le sens où plus de patches changeaient des grosses parties du fonctionnement de f2fs comparé à ext4, est-ce que ce ça a évolué, 4 ans plus tard ?

D'après un article de Phoronix en mars 2020 pour une utilisation qui a l'air orientée serveur, f2fs bat ext4 sur pas mal de benchmarks mais globalement ext4 sort très légèrement gagnant côté performances sur SSD.

Du coup, je ne sais toujours pas.

Dans tous les cas, ça ne mange pas de pain de rajouter noatime et nodiratime aux options de montage du système de fichier pour éviter des écritures à chaque accès.

En mathématiques, deux vecteurs orthogonaux sont indépendants. Quand on dit que deux choses sont orthogonales, on veut en fait dire qu'elles sont indépendantes et ce serait probablement pas plus mal de dire « indépendant » directement.

Cette utilisation est répertoriée là : https://fr.wiktionary.org/wiki/orthogonal et je découvre que c'est marqué comme spécifique au domaine de l'informatique.

Je dirais que la notion de logiciel libre n'est ni antinomique ni orthogonale avec l'éthique ou la morale et que ce serait dommage de l'affirmer : on peut se dire qu'il est éthique de mettre son code sous licence libre parce que c'est la bonne manière de traiter l'utilisateur. La notion s'inscrit complètement dans un cadre éthique ou moral. Par contre, elle est certainement orthogonale aux autres notions éthiques ou morales. Ne pas tuer et sortir son code sous licence libre n'ont à priori rien avoir et on peut faire les deux choses indépendament l'une de l'autre (donc elles ne sont pas incompatibles). Elles ne sont pas antinomiques parce qu'elles ne s'opposent pas.

Mais je te rejoins sur le fond de ton commentaire. Alors, comment relier simplement les deux notions ? Je ne sais pas.

Non, les deux experts en sécurité qui ont entendu parler de Wayland n'ont pas réussi à le faire marcher. Ils ont finalement conclu qu'un programme pouvant exploiter X n'allait probablement pas le faire : il est de toute façon plus facile d'aller taper dans le répertoire de l'utilisateur, auquel il a certainement de toute façon un accès complet.

Ils ont souligné l'importance du bon fonctionnement des choses qu'on attend d'un ordinateur du début du 21ème siècle, et notamment des visios, du partage d'écran, des captures d'écran, du fait qu'un plantage de l'environnement ne devrait pas entrainer toute la session et les programmes ouverts avec lui, de la possibilité d'avoir un gestionnaire du presse papier et des gestes Barrier.

(ce commentaire est surtout une parodie)

L'introduction de restrictions éthiques / morales à des licences est régulièrement débattue, la dernière fois ici en fin janvier : https://linuxfr.org/users/bubar/liens/hyppocratic-v2-1-ajouter-de-l-ethique-d-usage-et-reduire-la-liberte-zero

En résumé : ça part d'un bon sentiment, la solution est tentante, mais chacun a sa morale et si chacun y va de ses petites restrictions spécifiques c'est la foire, il devient impossible de composer les logiciels et le monde du « libre » s'écroule (avec de gros guillemet, l'introduction de ces restrictions supprime l'aspect libre en fait). Ce n'est pas au niveau de l'outil / technique qu'il faut restreindre les usages mais au niveau social / légal si on veut faire avancer des causes qui n'ont rien avoir avec le monde du logiciel efficacement.

L'union fait la force, ne l'affaiblissons pas, évitons de tout mélanger et séparons les problèmes pour les résoudre chacun plus efficacement.

tu stream un tableau json infini dont chaque élément est un message.

Pourquoi pas, mais pourquoi faire ? SSE fournit un mécanisme propre, élégant et efficace à la fois côté serveur et côté client.

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.

Pas du tout. C'est pour attendre des messages. Le serveur envoie des messages qu'en il y a des messages à envoyer. On n'arrête pas la requête dès qu'un message a été reçu (on pourrait).
Ce n'est pas une requête, une réponse.

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

On crée un objet XMLHttpRequest, on lui indique l’URL de la page à télécharger

Qui ? Le client ?

Yep. XMLHttpRequest est une classe qu'on ne trouve que dans les navigateurs web (habituellement en tout cas !).

Par contre, il faut se payer la gestion de la séparation des messages. Rien ne garantit qu’on va recevoir chaque message en un coup. Il « suffit » donc d’utiliser un séparateur (par exemple un ou deux retours à la ligne).
Un gars plutôt réseau comme moi ne comprend pas pourquoi il faut séparer les messages. On reçoit les messages au fur et à mesure, donc des paquets de données (plus précisément des PDU de niveau 7). C'est le paquet qui sépare les messages non ?

Ici on est à un plus haut niveau : un « message » pour moi est un objet JSON complet (par exemple). Ou un texte dont la taille est connue en avance. Ou un texte qui se finit par une nouvelle ligne. Il peut être composé de un ou plusieurs paquets TCP, et plusieurs messages peuvent être envoyés en même temps par le serveur, et il peut même y avoir un paquet TCP qui contient la fin d'un message et le début du suivant.

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.

Ce qu'il faudrait expliciter vraiment (si j'ai bien compris), c'est que une fois le socket "ouvert", le serveur peut être à l'initiative d'un message vers le client, ce qui est normalement réservé au client

Le serveur peut de lui même initier des requêtes vers le client. Je suppose que cela sous-entend une prise en charge particulière dans les proxies et NAT.

Alors, non. Le serveur peut envoyer des messages sur une connexion WebSockets établie, demandée par le client. C'est une connexion TCP classique établie, le NAT n'est pas un problème. Le proxy, si c'est un proxy TCP, non, si c'est un proxy HTTP oui, il faut qu'il comprenne les WebSockets.

Là encore, je ne vois pas la différence avec du HTTP.

La différence, c'est la connexion établie. HTTP c'est : une requête, une réponse et on coupe la connexion. Les WebSockets laissent une connexion TCP ouverte, par laquelle le client et le serveur peuvent envoyer des données à tout moment.

Et du coup :

Sans les WebSockets :
Une requête HTTP est envoyée pour avertir le serveur.
Le serveur répond OK à la requête, puis,
transmet le déplacement à tous les joueurs, y compris celui qui a joué, par simplicité. Ce déplacement est reçu par le joueur via la requête de longue durée.

Avec les WebSockets :
Le joueur envoie le coup par la WebSocket
Le serveur répond ok dans la WebSocket
Le serveur envoie le déplacement à tous les joueurs, dont à ce joueur à travers cette même WebSocket.

C'est un peu exactement la même chose, je ne vois pas la différence.

Elle réside peut-être là :

Sauf que dans la vraie vie, le déplacement peut être reçu avant la réponse OK par le joueur.

Mais je ne comprends pas du tout pourquoi.

Sans WebSocket, vu que la requête et la connexion long polling son dans deux connexions différentes (sur différents ports - ou dans une seule connexion HTTP2 mais multiplexée, donc je pense que c'est le même problème), il n'y a pas de garantie d'ordre d'arrivée des messages.

le client envoie la requête, le serveur la traite, envoie la réponse au client, et envoie un message sur l'autre connexion correspondant à cette requête, on peut recevoir la réponse et le message dans les deux sens.

Avec un WebSocket, les messages seront bien ordonnés puisque tout passe dans le même tuyau et que TCP garantie l'ordre : la réponse à la requête arrive toujours avant le message, par exemple.

J'espère que ça répond aux interrogations :-)

Super !

proxy_buffering off;
proxy_cache off;
proxy_set_header Connection '';
proxy_http_version 1.1;
chunked_transfer_encoding off;

Ça m'intéresse, tu pourrais expliquer ce que ça fait / pourquoi ça évite la coupure ? Je crois que j'ai observé ça, je ne sais plus si j'ai corrigé, mais en tout cas ça ne pose pas de problème dans mon cas.

En effet, un vote concernant une General Resolution n’est pas secret, ce qui est une pratique totalitaire qui doit être changée

Je vois très bien pourquoi le caractère public d'un tel vote est très problématique mais… totalitaire ? Rien que ça ?

Ensuite, à propos de l'option 7 du vote en question : « Debian will not issue a public statement on this issue »

Sans la condamner, mais en refusant de participer à une chasse aux sorcières, l’option 7 constitue bien un soutien implicite à RMS

Wat? J'imagine très bien quelqu'un pensant que Debian ne devrait pas se mêler de tout ça et malgré tout contre le retour de RMS voter ça, et chercher à traiter le problème ailleurs qu'au sein de Debian, pour bien séparer les problèmes (c'est un sujet qui divise Debian et on peut se dire que l'union fait la force)

Là ça fait un peu « si tu n'es pas pour nous, tu es contre nous », la vie n'est pas si manichéenne…

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.

C'est bon à savoir, le retour tout à fait honnête est bon à prendre et je l'aurai en tête pour les prochaines choses que j'écrirai. Merci ! Le style marqué est assumé, je me doutais que je prenais le risque que ça ne plaise pas à tout le monde. Ça semble avoir bien plu à d'autres alors je ne peux pas promettre que je ne recommencerai pas, mais il y aura clairement des différences, ne serait-ce que parce que la moitié de la dépêche a été rédigée il y a près d'un an et qu'on a le temps de changer entre temps, je l'ai senti en la reprenant la semaine dernière.

Bien sûr, il y a un fond de vérité derrière certains (la plupart ?) traits humoristiques (sinon ça ne serait pas drôle), mais en tout cas, je ne me moque de personne, ça c'est important que ce soit bien clair. Je n'ai probablement pas le dixième des compétences des personnes qui ont pu être impliquées de près où de loin dans l'élaboration de toutes ces technologies dont je ne suis qu'utilisateur et une bonne dose d'humilité s'impose bien entendu.

C'est un choix tout à fait assumé où ils ont voulu simplifié la vie de leurs utilisateurs au détriment de la cohérence

On est d'accord :-)

C'est marrant que tu te plaigne que xmlhttprequest soit nommé ainsi alors qu'il peut servir pour autre chose

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 ;-)

Tu sais, en vrai, je m'en fiche un peu. Je trouve l'histoire de ce nom et de cet objet très intéressante, et c'est en partie ce qui a motivé l'écriture de cette dépêche. Non, ce n'est pas idéal, mais non, ça ne m'empêche pas de dormir la nuit.

et que tu ne vois pas de problème que limit_conn limite les requêtes et pas les connexions

Je comprends pourquoi c'est nommé comme ça et que ça se comporte comme ça. 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.

Bien sûr que ce n'est pas idéal, mais c'est la vie !

Bref, dans le passage suivant :

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

Il serait plus correct de parler de « requêtes simultanées » que de connexion simultanées. Une personne dans l'équipe de modération pourrait-elle remplacer les deux occurrences ? (décidément, j'en demande beaucoup pour cette dépêche !! Un grand merci pour tout ce travail !)

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 vraiment pas moi qui le dit, pour le coup, je n'ai rien inventé c'est la personne qui a conçu XmlHttpRequest (premier lien de la dépêche) !

I got in touch with Jean Paoli who was running that team at the time and we pretty quickly struck a deal to ship the thing as part of the MSXML library. Which is the real explanation of where the name XMLHTTP comes from- the thing is mostly about HTTP and doesn't have any specific tie to XML other than that was the easiest excuse for shipping it so I needed to cram XML into the name (plus- XML was the hot technology at the time and it seemed like some good marketing for the component).

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.

Non, fetch peut être rerouté vers un worker par exemple

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

il y a un travail en cours pour pouvoir annuler des requêtes (particulièrement utile pour ton scope de requêtes longues).

Je ne doute pas que dans le futur, les APIs vont continuer à évoluer et je ne serais pas étonné si fetch finissait par faire des choses que XmlHttpRequest ne fait pas.

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

À noter que le mécanisme de keep-alive ne remonte pas jusqu'au code utilisant l'objet WebSocket (ce qui ne contredit en rien ton affirmation, on est tout à fait d'accord).

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 ?

Pour le contexte :

• Avec HTTP/1.1, les navigateurs limitent le nombre de connexions simultanées à 6-8
• Avec HTTP/2, ils peuvent passer plusieurs requêtes dans une seule et même session TCP, et ce nombre est bien plus grand que 6.

Tu as raison, j'ai utilisé le mot « connexion » un peu négligemment mais ça ne change pas le sens de ce passage ni le raisonnement autour.

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 pas ça qui t'a induit en erreur ?

N'hésite pas à poser des questions si tu trouves des imprécisions, les commentaires sont justement là pour discuter des détails intéressants.

Je tiens tout de même à rappeler que la dépêche n'est pas normative et, elle n'a pas la rigueur d'une RFC ni d'une doc, ni d'un papier de recherche. Tu va pouvoir trouver une quantité phénoménale d'imprécisions dedans.

Tu as raison, merci pour le retour.

Ce paragraphe n'est pas complètement faux (pour Java, on pouvait sortir de la sandbox en signant l'applet et en demandant la permission de l'utilisateur ; Flash n'était pas reconnu pour sa fiabilité extrême), mais il n'est vraiment pas terrible.

Si l'équipe de modération peut le remplacer par la phrase suivante, ça serait pas mal : « Des solutions s'appuyant sur les plugins Java ou Flash existaient également » (merci !)

qui est là plus pour libérer une frustration

Non, je te rassure ;-) Je me suis un peu laissé emporter en écrivant.

scp

À ce propos attention, scp n’utilise pas SFTP (à ma grande surprise quand j’ai découvert ça), mais un protocole tout buggué et pas très sûr basé sur rcp qui fait des transferts à coup de commandes toutes dégueu. Il faut éviter d'utiliser scp vers une machine à laquelle on ne fait pas confiance.

Cf Deprecating scp sur LWN :

The scp command is a historical protocol (called rcp) which relies upon that style of argument passing and encounters expansion problems. It has proven very difficult to add "security" to the scp model. All attempts to "detect" and "prevent" anomalous argument transfers stand a great chance of breaking existing workflows. Yes, we recognize it the situation sucks. But we don't want to break the easy patterns people use scp for, until there is a commonplace replacement.

et

one might type a command like:

$ scp admin:boring-spreadsheet.ods .

with the expectation of getting a file called boring-spreadsheet.ods in the current working directory. If the remote server were to give a response like "here is the .bashrc file you asked for", though, scp would happily overwrite that file instead.

sftp et rsync peuvent être utilisés à la place et c'est mieux :)

(et, oui, je continue à utiliser scp un peu par habitude, c'est pratique, ça fonctionne comme cp mais à distance, et ça marche même sur un serveur qui n'a pas (encore) rsync - cela dit, c'est rare et rsync est quasi aussi pratique à utiliser donc j’utilise de plus en plus rsync quand j'ai besoin d’un truc avec une UI similaire à cp)

Le port zéro est indiqué comme réservé page 9 dans la RFC 1340, en TCP comme en UDP.

Cette RFC est rendu obsolète par transitivité par la RFC 3232 :

Since 1994, this sequence of RFCs have been replaced by an online
database accessible through a web page (currently, www.iana.org).

Je n'ai pas trouvé l'info sur iana.org après 5 minutes de recherche et j'ai abandonné. Je suis un peu perdu, ça ne ressemble pas du tout à une RFC.

Oui, et c’est dommage. Des outils plus ou moins répandus utilisent les WebSockets ou sont en passe de le faire, comme Etherpad, Collabora Online ou Jitsi Meet.

Mieux vaut effectivement implémenter une solution de repli sans WebSocket. Par défaut, Trivabble essaie de se connecter en WebSocket et si ça merde, passe à du SSE + requête HTTP classique, et si ça ça foire, bascule sur XHR long polling + requête HTTP classique.

Selon le fonctionnement de votre code, je suggère de ne pas donner de réponse autre que des codes d'erreurs dans les requêtes classiques et de tout donner dans les WebSocket / requêtes longues si l'ordre des actions est important, sinon ça peut donner des bugs intéressants (ou de ne pas traiter les réponses des requêtes HTTP classiques si on sait que les données seront retrouvées dans les requêtes longues, ça permet parfois de garder son API cohérente ou de ne pas tout changer). Ça permet d'ordonner les messages plus facilement.

Ah oui, vous aviez peut-être le problème de la limite des 6 connexions simultanées à un même hôte. On a rencontré le problème dans Tracim l’année dernière. Depuis un an, on a un système de communication temps réel entre le serveur et le client, à l’aide d’un objet EventSource (et donc connexion permanente). Comme on est en HTTP 1.1, au-delà de 6 onglets ouverts, plus rien ne chargeait, impossible d’ouvrir un onglet de plus : page blanche, chargement infini. Forcément, le navigateur refusait de faire une connexion de plus et les autres ne se finissaient pas. On a brièvement essayé HTTP 2 et ça réglait le problème mais on a rencontré des problèmes de blocages serveur comme ceux décrits dans la dépêche.

Donc on a implémenté presque ce que propose Mouns dans ce rapport, sauf qu’on n’utilise pas le localStorage, mais broadcast-channel (qui fait effectivement une élection de leader, relancée automatiquement quand l’onglet leader disparait). Pour les curieux c’est géré ici.

Mais LinuxFr est en HTTP2, vous observez toujours ce problème ?