Stéphane Bortzmeyer a écrit 645 commentaires

Ou bien le très connu forum gemini://station.martinrue.com/. Il est donc parfaitement possible d'écrire avec Gemini (même si le but n'est effectivement pas de faire 100 % de ce que fait le Web, c'est même tout le contraire).

Des logiciels libres de supervision, il en existe des millions, et tous peuvent tester IMAP et SMTP (par exemple pour ceux qui ont l'API Nagios, il y a les monitoring plugins https://www.monitoring-plugins.org/doc/man/check_smtp.html et https://www.monitoring-plugins.org/doc/man/check_imap.html).

Je pensais à tous les projets dont je m'occupais (persos ou pros) et qui avaient une base SQLite.

Dont plusieurs chez moi :-)

Dans la rubrique « Les nouveautés du Wiki », les liens ne marchent pas. Je clique sur le titre ou la date mais rien ne se passe. Testé uniquement avec Firefox sur Debian.

Du côté des normes techniques, on peut regarder le travail DTN à l'IETF (et le protocole Licklider). RFC 4838 https://www.bortzmeyer.org/4838.html et suivants.

Non, c'est le problème de faire une citation en laissant entendre qu'elle vient de la Quadrature, ce qui n'est pas le cas.

Comme prévu, la discussion porte beaucoup plus sur le vaccin et sur le passe sanitaire que sur la Quadrature du Net.

Je voudrais quand même insister sur le fait que les bouts de phrase cités dans le journal original ne sont pas de la Quadrature mais sont des extraits d'une discussion sur la liste publique gérée par la Quadrature, mais où tout le monde peut s'inscrire et dire des connneries. (C'est pour cela que j'ai marqué le journal comme non pertinent.)

Corrigé à tort puisque RabbitMQ parle les deux protocoles (et quelques autres).

Le client QUIC n'est pas forcément au courant du changement d'adresse IP (qui peut se produire loin de lui, par exemple dans un routeur NAT). Et, justement, le principe du "Connection ID" de QUIC est qu'il sert à identifier une connexion (qui, en TCP, est identifiée par l'adresse IP), ce qui est bon pour les performances et la robustesse, mais mauvais pour la vie privée.

J'ai détaillé cette analyse dans un article.

Et, surtout, le moteur de recherche ne devient important qu'une fois qu'on a rentré beaucoup de données (et qu'il est alors trop tard). L'argument « personne ne me l'a demandé » se comprend mieux dans ce contexte : personne n'a encore mis suffisamment de données depuis suffisamment longtemps pour avoir été coincé par l'absence de moteur de recherche.
Notons que PosqtgreSQL a un excellent moteur de recherche dans ses champs textuels, ce qui fait que le coût de développement est limité.

En effet, cette affirmation comme quoi Ethernet aurait démarré en France me parait très fumeuse. L'article de CPU cité n'en parle pas. Comme on dit sur Wikipédia, « référence nécessaire ».

Le fait de gérer les frontières de message n'a pas en pratique convaincu tellement de monde. Sinon, SCTP n'a pas d'avantage suffisamment écrasant sur TCP. Mais il est dans le noyau Linux depuis un certain temps, donc vous pouvez l'utiliser.
Victime du filtrage massif fait par les opérateurs, il a en effet du mal à passer partout. Aujourd'hui, il est en général employé sur UDP (RFC 6951).

Utilisateur de Flus 1 et abonné à ce service, j'ai testé Flus 2 mais, pour l'instant, j'ai arrêté. Il y a en effet deux manques sérieux qui font que je n'ai pas envie de passer du temps à le remplir avec mes sites favoris :
- pas de moteur de recherche (alors qu'il me faut absolument pouvoir retrouver « cet article super de Machin qui parlait de MPLS il y a à peu près un an »
- pas d'exportation des données, donc on est pour l'instant prisonnier du service.

Il manque un ou deux mots dans la première phrase, ce qui la rend difficile à comprendre. Si l'idée était de dire qu'Ethernet a été inventé en France, il faut me prévenir, que je renforce mon bullshitomètre pour qu'il tienne le coup.

Hélas non.

La bonne solution est plutôt de ne pas tout concentrer dans quelques gros silos/sites.

Gitlab.com était touché aussi ? Le Gitlab que j'utilise (Framagit) marchait. Des tas de développeurs ont continué à bosser.

Et pour cause, l'Internet marchait https://www.bortzmeyer.org/panne-fastly-presentation.html

Une partie des défauts ne seront découverts qu'avec le temps (comme cela a été le cas pour TCP). Le retour d'expérience existe mais ne doutons pas qu'on verra des problèmes à l'usage quand il sera plus massif et plus distribué.

Un défaut possible, mais pas encore exploré, est la facilité de suivre un utilisateur donné au cours du temps, puisque les sessions peuvent être longues (et survivent aux changements d'adresses IP). QUIC protège mieux contre un surveillant extérieur mais moins bien contre l'extrémité (le serveur). En pratique, ce n'est sans doute pas un vrai problème car HTTP, notamment grâce aux cookies, transmet déjà largement assez pour le suivi de l'utilisateur (suivi qui, contrairement à QUIC, s'étend au-delà d'un seul serveur, grâce à Google Analytics et aux boutons de partage des GAFA). Par contre, si on développe un système tout nouveau et orienté vie privée, le client devra veiller à ne pas laisser les sessions QUIC durer trop longtemps et survivre aux changements d'adresses IP. Bref, QUIC sur Tor ne serait sans doute pas pertinent.

Oui, pour l'instant, QUIC n'est prévu que pour des ordinateurs classiques, pas pour des objets connectés (qui n'auraient de toute façon sans doute rien à faire des avantages de QUIC comme le parallélisme).

Utilisant UDP, il en reprends aussi les défauts. Je pense surtout au problème pour les attaques DoS.

Non, c'est faux. Beaucoup de gens ne connaissent de QUIC que le « il tourne sur UDP » et se disent « ah mon Dieu, ça va servir pour des attaques par réflexion ». Ce serait comme de dire de TCP qu'il permet des attaques par réflexion car il tourne sur IP, qui permet ces attaques.

QUIC, comme TCP, teste la réversibilité ("returnability") et ne peut donc pas servir pour des attaques par réflexion.

Pour le premier datagramme (pour lequel on n'a pas encore pu tester la réversibilité), QUIC limite le BAF (Bandwith Amplification Factor) à trois. C'est pour cela que le premier datagramme du client est souvent si gros (le RFC recommande 1 200 octets), afin d'être sûr que les certificats tiendront dans la réponse. Rappelons que TCP, sur Linux, a un PAF (Packet Amplification Factor) de 5 (oui, 5 datagrammes TCP sont envoyés en réponse au premier datagramme, pour lequel la réversibilité n'a pas été testée).

Déjà, FASP (le protocole derrière Aspera) est un truc privé, fermé et breveté.

Ensuite, faire passer davantage d'octets par seconde est facile si on ne tient pas compte des autres. Un protocole égoïste va toujours pouvoir faire mieux. Ce n'est pas grave si on a des liens dédiés mais QUIC est fait pour l'Internet ouvert.

UDT est abandonné, non ?

HPN-SSH utilise TCP, donc hérite des avantages et inconvénients de TCP. https://linuxfr.org/users/obsider/journaux/high-performance-ssh

Oui, les petits ruisseaux font une grande rivière.

En fait, c'est la faute d'Abba "I cross the stream \ I have a dream », ce qui est mieux que « Je traverse la rue \ Je trouve un boulot ».