benoar a écrit 4229 commentaires

On aura bien sûr corrigé l'appel à function1 qui devait bien sûr s'écrire self.function1.

Ha, je me demandais si j'étais le seul à trouver ça illisible…

Le but est de passer en paramètre une variable qui serait globale autrement. Alors j'entends des voix dans le fond de la salle, notamment le mot « singleton », mais c'est une fausse bonne idée et n'est qu'une classe unique cachant une variable à portée globale.

Et c'est quoi ton problème avec les variables globales ? Si c'est un paramètre qui doit être utilisé partout, une variable globale est tout à fait indiquée. Si c'est un paramètre spécifique à une « chose » particulière, qui sera réutilisée pour cette « chose », et bien… fait de l'objet ! Ça sert à ça…

    class Recurrent(object):
        def __init__(self, arg_r):
            self.arg_r = arg_r
        def function1(self, arg1, arg2):
            print(self.arg_r)
            # …
        def function2(self, arg1, arg2):
            self.function1(arg1, arg2)

    chose = Recurrent(42)
    chose.function2(1, 2)

Et sache que singleton n'est pas une formule magique qui résout tous les problèmes. (j'ai l'impression des fois que les designs patterns ça fait plus de mal que de bien)

Je dirais qu'il y a un malentendu à cause du (mauvais) titre de l'article de patrick_g : ce dernier parle effectivement de mémoire flash dans son article, et pas vraiment de SSD. Par contre, les posts de Sylvain et de Yao parlent effectivement de SSD.

En ce qui concerne les FS orientés SSD, certains parlent du fait qu'on n'a plus besoin de scheduler, mais ça n'est pas la seule différence : l'option ssd (voire ssd_spread) de btrfs change la manière dont le FS alloue les blocs. Je pense qu'aujourd'hui, même s'il manque encore un peu de maturité, btrfs est le meilleur FS pour SSD. L'histoire de :

Note that -o ssd will not enable TRIM/discard.

c'est juste pour dire que ça n'implique pas l'activation tu TRIM, mais btrfs sait bien sûr l'activer quand un SSD est utilisé.

Je ne connais pas de périphérique grand public qui offre un accès à la mémoire flash directement, ce qui est sans doute la raison pour laquelle on entend peu parler de ces FS.

Les interfaces mtd telles qu'utilisées par le kernel actuellement ne sont de toutes façons pas faites pour le grand public. L'accès direct à la Flash se démocratisera plus quand on verra des périphériques NVM Express arriver.

Très sympa comme mémento, merci. Je ne me suis pas encore complètement mis aux spécificités de la version 3, donc ça peut être très utile.

Quelques petites remarques :

• J'aurais plutôt utilisé enumerate() pour le parcours de liste avec index ; je vois qu'il est quand même mentionné juste à côté, donc c'est juste un détail
• La section sur le formatage des chaînes pourrait peut-être avoir des exemples un peu plus « complexes », plutôt que simplement des explications des différentes options ? (je trouve les précédents exemples bien pratiques)
• La différenciation (nouvelle) de str et bytes n'est pas abordée : c'est pour éviter de mettre trop de choses dans ce mémento ?

si un attaquant arrive à deviner le protocole d'authentification utilisé par le serveur, il peut se faire passer pour n'importe qui

Je ne vois pas trop le rapport entre « se faire passer pour n'importe qui » et arriver à ouvrir une connexion TCP en devinant le bon numéro de séquence.

De plus il peut également inonder de paquets ACK le serveur pour tenter de créer une connexion.

Ça ne fera pas plus de mal qu'un syn-flood avec syn-cookie niveau charge, et après, pour arriver à ouvrir une connexion, c'est pareil que d'arriver à deviner les numéros de séquence de manière « classique » : c'est considéré comme assez difficile.

Et enfin, un serveur utilisant des syncookies ne pourra pas effectuer un filtrage de paquets ACK, ce qui peut permettre éventuellement à un attaquant de passer à travers un pare-feu qui filtre les paquets SYN de demande de connexion.

Ça c'est simplement faux.

Bref, c'est un peu n'importe quoi cet article. Et de toutes façons il me semble que les syn-cookies sont activés par défaut depuis un bout de temps.

Bon, j'ai trouvé ça http://entertainment.slashdot.org/story/11/09/12/1534213/eu-extends-music-copyright-to-70-years qui dit que c'est passé de 50 à 70 ans récemment en fait, mais Wikipédia parle de 70 ans depuis 1993… Je ne comprends pas trop. Par contre http://en.wikipedia.org/wiki/European_Union_95_year_recording_copyright_extension_proposal explique peut-être ma confusion avec 90 ans.

Je croyais qu'il avait récemment était augmenté à 90 ans et de manière rétroactive bien sûr.

Je ne crois pas. En tout cas ce n'est pas ce que dit Wikipédia.

Bah c'est étrange mais moi aussi je croyais avoir vu passer au parlement européen, il y a moins de 6 mois, dans un beau silence des grands médias, une extension à 90 ans. Mais je fais des recherches et je ne trouve quasiment rien là-dessus. Vu qu'on est deux, je ne pense pas complètement avoir rêvé, mais quelqu'un d'autre pourrait-il confirmer/infirmer ?

Pour FDN, c'est dégroupage partiel uniquement, effectivement. Par contre on a eu un retour de quelqu'un qui a pris une ligne fixe SFR « normale » (je ne savais même pas qu'ils vendaient ça) et qui a pu prendre un abonnement FDN dessus sans problème. Et on couvre bien sûr toute la France.

En ce qui concerne la couverture, de toutes façons, tu n'auras pas vraiment de différence que tu sois chez FDN, OVH, ou SFR : les deux premiers utilisent en gros le réseau du troisième… Ya Orange qui couvre parfois un peu « mieux », mais aucun « alternatif » n'aura de meilleure couverture en ADSL que SFR ou Orange.

Dictionnaire! Le translateur ne dépend pas du protocole, il a un dictionnaire qui l'alimente.

Traduction, dictionnaire, fourni avec… oui, tu viens bien de réinventer la compression style gzip ou autre. Sauf qu'en plus, les algorithmes de compression « standard » sont généralistes.

Après, je vais être gentil, j'ai découvert récemment que les mecs qui font vraiment attention au moindre bit, dans le domaine des microcontrôleurs, ont adapté du HTTP version très simple et « compressée », ça s'appelle CoAP (Constrained Application Protocol) http://tools.ietf.org/html/draft-ietf-core-coap-09

Tu peux pointer le commentaire ? En quoi ça te convient pas ?

https://linuxfr.org/nodes/94082/comments/1349431
https://linuxfr.org/nodes/94082/comments/1349403

C'est mieux que tes longues sessions ssh… Tu peux récupérer ta session de partout au lieu de juste ton laptop avec lequel tu es partis.

Effectivement, c'est un avantage de screen/tmux. Mais personnellement, je n'ai, dans mon cas, qu'une machine, que j'utilise tout le temps. J'ai rarement besoin de ce cas d'usage. Comme quoi, on a tous des usages différents.

Ce qu'il dit c'est qu'un mec qui abuse volontairement tu lui shoots tout voir tu lui bloque l'accès. Un mec qui à un truc qui déconne, tu lui buttes son processus, tu le préviens et tu reviens à la solution 1 si ça recommence trop souvent.

Effectivement.

Si SSH te laisse traîner des shells, tu peux pas vraiment blâmer les utilisateurs. Tu te rappels pas forcément qu'une cnx à déconnée et ils ont pas que ça a faire que de tout vérifier.

Effectivement, c'est reulou à faire à la main. On pourrait imaginer un keepalive à une semaine, ça pourrait être raisonnable et nettoyer automatiquement les sessions « fantômes ».

C'est un peu comme imaginer que le système puisse ne pas nettoyer la mémoire quand un process crash et qu'on doivent le faire à la main.

Oui, sur des systèmes de grande envergure, il faut trouver un système automatique. L'avantage avec les processus, c'est qu'on peut détecter quand ils crashent, et il y a l'oom-killer en cas de dérapage. Pour les sockets tcp, une période d'inactivité d'une semaine me semble pas mal.

Donc : fait des benchs, dans diverses situations, et va le dire aux mainteneurs, ce sera plus utile que de pleurer sur LinuxFr.

Ça serait bien effectivement de « faire des benchs », mais ça n'est pas évident de tester une situation qui est un ensemble de facteurs très divers (qualité du réseau, gestion des serveurs, comportement des utilisateurs,…). Mais une étude sur une sorte d'échantillon pourrait être sympa.

En attendant, ça a été choisi pas pour rien.

Bah justement, je me demande. En regardant le CVS d'OpenSSH, je vois que cette option est active par défaut depuis le début (premier commit de Théo). Ça se trouve, personne ne s'est vraiment posé la question. Et personne ne l'a vraiment testé en conditions réelles, dans les personnes que je connais.

A partir du moment où tu racontes des conneries sur les utilisateurs (tu crois qu'ils vont bien se comporter parce que tu le demandes?),

Ah oui, c'est vrai, tous les utilisateurs sont des cons, j'avais oublié.

forcément on ne peut que rire à ton "ça ne va pas tuer sa machine" qui n'a aucune crédibilité avec la phrase qui démontre que tu crois toujours que les bisounours existent.

Bah riez si vous voulez, mais c'est clair que c'est pas avec des réactions comme ça qu'on essayera d'améliorer notre environnement de travail.

ce qu'on comprends pas c'est l'intérêt d'un screen sur une machine proxy qui garde up une connexion ssh du proxy vers le serveur au lieu d'un screen directement sur le serveur… donc du coup argumenter pour dire non pas screen car j'ai pas de machine qui peut me servir de proxy est ridicule.

Je n'utilise pas cet argument pour dire pas screen, c'est encore une incompréhension. J'ai trouvé cette solution non idéale, point, ce thread parlait de ça uniquement.

Utilises screen sur le serveur directement et yabasta problème résolu

En ce qui concerne cette utilisation, j'ai déjà répondu plus haut que ça n'était pas une utilisation optimale pour moi.

oui dans le meilleur des mondes, ta connexion ne couperait pas… mais ici c'est pas le meilleur des mondes, c'est le vrai monde et dans le vrai monde, y a screen et c'est caisse.

Le but de ce journal est justement de discuter de comment faire pour y tendre, vers ce monde meilleur. Car je pense que cette option de keepalive n'est pas si bonne qu'elle en a l'air.

J'espère que c'est plus clair.

je sais bien mais au moins je n'ai pas à trier parmi les connexions tcp ouvertes par tous les comptes.

Je ne suis pas sûr d'avoir bien compris ta réponse, mais je parlais justement du fais que le kill était également la solution au cas où tu te retrouves avec des sessions tcp en grand nombres qui te bouffent des ressources, puisque c'est l'inconvénient qu'on essayait de mitiger dans le cas où on n'active pas le keepalive. L'abus de connexions tcp se corrige donc de la même manière que l'abus de ressources CPU/mémoire, et se traite aussi facilement ! C'est pas beau, ça ?

Donc, je ne vois pas en quoi désactiver le keepalive poserait plus de problèmes dans la gestion des cas de congestion que l'abus « classique » d'autres types de ressources. C'est là où je voulais en venir.

2H comme spécifié par la RFC.

Ah, pardon, merci de l'info. J'avais l'impression que c'était plus court, et j'avais 300s dans la tête pour je ne sais quelle raison. Mais ça le fait effectivement en général pour des temps d'absence assez longs.

Oui. Des laptops qui freezent, j'en vois 4x par jour. Sans compter les autres problèmes.

Et qui freezent avec des connexions ssh ouvertes ? C'est du windows, ou pas ? Ça mettrait tant de sessions fantômes que ça qu'un keepalive à une semaine ne serait pas assez ?

Fréquence aléatoire. Ca peut arriver très fréquemment quand tu as un switch qui déconne, une carte réseau defectueuse etc.

Et ça te coupe des sessions tcp si souvent que ça ? C'est des switchs qui font firewall statefull ? La carte réseau défectueuse ça arrive vraiment très fréquemment ? Comme j'ai déjà dit, je n'ai pas travaillé dans de très gros environnements, mais que ce problème ce conjugue avec des sessions ssh qui passaient par là à ce moment, de manière assez récurrente, ça me paraît tellement pas assez probable pour que ça soit un problème d'envergure. Mais je dois peut-être me tromper.

Quand ca arrive ca peut donner 12 heures de coupure sur Amazon S3 à cause d'un bit flip dans un gossip protocol…

C'est quoi cette histoire ?

Je pense que tu as deux problèmes. Tu considères que les cas d'erreurs sont suffisamment rare pour être ignorés, ne sont pas graves et que les utilisateurs préfèrent réparer les erreurs.

Effectivement, je considère, peut-être à tort, qu'ils sont assez rares pour être ignorés. Que ça soit aux utilisateurs de le réparer, on peut envisager de mettre une sort de keepalive à une semaine (je ne sais pas si c'est réaliste avec un mécanisme de keepalive ; peut-être envisager un système de nettoyage de socket inactives pendant une semaine) afin d'automatiser ça. Mais responsabiliser les utilisateurs, c'est déjà pas mal : tu leurs dis déjà de fermer leur session web correctement, pourquoi pas la même chose avec ssh ? (remarquons au passage que c'est le même problème : ça fait chier les utilisateurs qui ont des sessions http qu'ils veulent faire durer longtemps, quand un site te déco après X minutes d'inactivité)

Et d'autre part tu sembles supposer que les choix fait par TCP sont applicables aux couches du dessus.

Bah, ssh est quand même pour moi vachement lié à tcp, je pense que c'est normal qu'il « subisse » ses choix.

TCP n'offre que le sous ensemble commun nécéssaire à tout les protocoles de couche supérieur. Le keep-alive est vraiment un truc litigieux, qui est d'ailleurs dans une RFC annexe. Ca a été inclus car détecter les pannes est un besoin très courant mais le faire au niveau TCP est assez moisi.

Effectivement. Mais même niveau au-dessus, je ne suis pas fan.

Merci pour ce commentaire constructif en tous cas.

Non pas moi, jamais. Relis tout le journal, 10 fois s'il le faut… Et puis reviens t'excuser ensuite.

Alors, je n'avais effectivement pas vu ce comportement de ta part jusqu'à ce message (« me les briser ») qui m'a passablement énervé, vu le ton, alors j'ai utilisé le « on » sans discerner ; excuse-moi pour ça. Mais…

Pardon ? Tu veux faire un concours de mauvaise foi ou quoi ? On te dis que t'as pas besoin de machine dédiée pour utiliser screen contrairement à ce que tu as écris et tu nous dis qu'on est à coté de la plaque ? Dis t'as bien pris tes pilules ou quoi ?

Je ne sais pas combien de fois il faut que tu relises le message de Michaël, à l'origine de ma réponse, pour que tu comprennes. Que tu insistes sans chercher à comprendre me fait dire que tu as une idée toute faite sur mon cas et que ça ne sert à rien de continuer.

Je n'ai ABSOLUMENT pas vu la moindre critique constructive venant de ta part dans ce journal.

Ah bah forcément, on ne doit vraiment pas se comprendre alors.

Moi, je trouve cela trop long, comme quoi et ca me gonfle régulièrement de me trouver avec des shells bloqués à cause d'une connexion ssh bloquée,

Intéressant. As-tu déjà essayé de diagnostiquer pourquoi ça déconne ? Ça serait intéressant de trouver la source du problème, je trouve, plutôt que d'avoir à trouver un workaround. Parce que je suppose que ça t'embêtes d'avoir à modifier cet intervalle sur les serveurs sur lesquels tu te trouves, non ? Quoique dans ton cas, tu pourrais aussi le raccourcir niveau client, déjà.

et je viens pas faire chier mon monde sur linuxfr pour dire que les devs d'openssh sont des boulets…

Heu… Déjà, je n'ai jamais dit que c'était des boulets (déjà précisé dans un autre commentaire), et ensuite, je vais « faire chier mon monde sur linuxfr » ? Qu'est-ce que j'ai fait de mal pour t'énerver ainsi ? J'ai émis des critique sur le choix par défaut d'un soft, afin de lancer le débat… j'ai le droit, non ?

Parce que effectivement, parfois ca le fait de voir la session repartir toute seule après reconnexion…

Je ne suis pas sûr de comprendre : tu parles dans le cas avec keepalive ?

Donc un juste milieu me semble correct….

Le problème, comme je l'ai déjà dit, c'est que normalement, tcp devrait très bien s'accommoder des problèmes de réseau « classiques ». Et que pour les problèmes dûs à des réseaux mal configurés, ça serait bien d'essayer de corriger le réseau, plutôt. D'où ma suggestion plus haut de voir ce qui ne va pas. Car avec ce workaround, le problème, c'est qu'il n'y a pas vraiment de « juste milieu » : effectivement, si tu considères qu'une machine doit répondre tout le temps aux sollicitations (ce que je n'aime pas comme supposition), autant mettre l'intervalle de keepalive à 5 secondes, comme ça tu vois direct quand ça déconne.

Franchement je suis resté très correct avec toi jusqu'ici mais la vérité m'obliges à te le dire: tu commences à nous les briser menu !!!

Hein ? On me prend de haut, j'essaye d'argumenter calmement, je te dis quand tu es à côté de la plaque (relis le commentaire auquel je réponds !), et ça n'est pas correct ?

Demandes à ton admin de monter le MaxSessions à 10000 (il est à 10 par défaut t'es au courant?)

Ça n'est pas le problème. Je n'ai jamais parlé d'exhaustion de session.

ou de mettre ton keepalive dans un Match User

Ça serait bien en effet.

mais arrêtes un peu de geindre à propos d'un des tous meilleurs outils libres du moment qui permet de faire exactement ce dont tu te plains depuis des heures.

Alors, ssh est un très bon outil, et j'en conviens totalement, mais je ne devrais surtout pas le critiquer ?…

Oui. Par contre t'as développé et gérés combien de systèmes au dessus de TCP en prod ? Tu serais surpris de ce qu'il se passe dans la vraie vie.

Je n'ai effectivement pas l'expérience des très gros systèmes avec des milliers de gens dessus. Je sais bien qu'il arrive des choses étranges dans la vraie vie. On essaye de se protéger comme on peut. Mais killer une session qui ne répond pas après 5 minutes (timeout par défaut, il me semble), c'est vraiment court.

Cf mon autre message. Tout les laptops sous linux qui ont une mise en veille pourrie et qui crash au resume ? Tout les laptops qui arrivent à cours de batterie ? Toutes les coupures de courant ? Avec des VM je suis sur qu'il y a des choses intéressantes aussi.

Bien sûr que ce genre de problème arrive, j'en suis tout à fait conscient. Mais est-ce assez courant pour que ça mérite d'avoir un paramètre par défaut dans un soft comme ssh ? Si ça l'est, ça m'inquiète beaucoup sur l'état de certaines machines ou certains réseaux. Il faut essayer d'y remédier. Si c'est exceptionnel, traiter ces cas par des mécanismes plus doux (genre une sorte de keepalive d'une semaine par exemple) serait beaucoup plus intelligent.

La théorie te dit ok, la pratique te montre que des corruptions de segment alors que le checksum est valide ca arrive. La couche réseau n'est qu'une base pour monter un service. C'est un boulon.

Et ça arrive avec quelle occurrence ? Est-ce que tous les protocoles réimplémentent des checksums au-dessus ? Est-ce que ça les rend tout pourris ? Et à partir de quel niveau tu fais confiance au protocole ?…

Parce que c'est plus facile pour un admin de faire un su - benoar -c "kill -9 -1" si tu commences à le faire chier à pomper ses ressources plutôt qu'à aller fouiller dans les sessions tcp lesquelles sont légitimes et lesquelles il peut killer de façon safe.

Heu… Tu sais qu'avec ton kill (qui ne va pas distinguer les processus « légitimes » non plus…) tu vas également tuer toutes les connexions TCP associées à mon compte ? Tu vas donc exactement arriver au résultat que tu voulais, sans besoin de keepalive.

Tu n'as pas l'air d'arriver à comprendre que la couche transport et la couche application ne sont pas la même chose. Entrée numéro 1 du Fallacies of Distributed Computing: The network is reliable.

Je suis d'accord qu'il y a un choix à faire sur où tu fais la persistance. Le choix de tcp me conforte dans le fait qu'on veut le faire à ce niveau, même si on abuse beaucoup de ce protocole aujourd'hui.

Par contre, dire que comme le réseau n'est pas fiable ça va foirer est faux_ : justement, tcp est _fait pour supporter les pertes de paquets, et sans keepalive, on peut très bien s'accommoder de pertes temporaires de réseau. La connexion reprendra bien comme il faut quand le réseau aura été réparé.

C'est étrange comme vous utilisez le keepalive comme un moyen de se parer des problèmes du réseau alors que justement, tcp est fait pour ça !

Non:
- une machine qui crash
- Un arrêt brutal

C'est les cas que j'ai cité. J'ose espérer qu'ils sont rares.

• Un câble réseau débranché

TCP s'en accommodera très bien.

• Réinitialisation de la table d'état d'un firewall statefull et va tout dropper
• Un laptop qui passe en veille et ne reprendra jamais l'IP qu'il avait

Ça c'est les signes d'un réseau pourri. C'est ici qu'il faudrait agir pour résoudre les problèmes. Alors après, bisounours, toussa, mais ça pourrait améliorer beaucoup de choses de régler ce genre de problème.

Y'a la théorie et la pratique. C'est pour ca qu'on implémente des système qui au minimum survivent aux erreurs et au mieux supportent les pannes byzantines.

Mais je suis tout à fait d'accord. Et ssh sans keepalive se démerde très bien comme ça !
Après, si tu changes de réseau ou si un firewall statefull a merdé au milieu, ta session bloque, tu le remarques, tu coupes. Mais dans le premier cas c'est la faute de l'utilisateur, dans le deuxième c'est le signe d'un réseau pourri.

Et la mise en veille, manifestement. Ou alors je ne comprends vraiment plus pourquoi tu râles.

Et bien non, justement. À la mise en veille, ton OS garde bien sûr l'état actuel de ses connexions TCP. Quand tu vas le réveiller, et que tu réutiliseras tes connexions, elles vont soit reprendre (sans keepalive, normalement le serveur en face les aura gardé), soit se prendre un timeout parce que le serveur en face a eu un problème.

Désolé, mais moi, ca m'arrive de débrancher le cable réseau puis de fermer les 10 onglets de mon terminal… Donc, pas envie de laisser des connexions fantomes tous les jours sur mes serveurs…

Est-ce que l'ordre des étapes est volontaire ou non ? Si ça l'est, tu pourrais peut-être en changer ? Si tu fermes tes 10 onglets, même à la barbare, et que ton câble est branché, pas de problème, elles seront bien fermées.

Si ça ne l'est pas… Je trouve que c'est une utilisation étrange. Par exemple, pourquoi dois-tu fermer tous tes onglets ? Tu rebootes souvent ta machine ? Je trouve ça tellement peu pratique… (et je ne dois pas être le seul, la veille est l'option par défaut dans Gnome 3… bon OK, je sens que je n'ai pas choisi le bon argument…)

C'est juste logique…

Bah, je ne trouve pas. À priori, je suis plutôt minoritaire sur ce thread, mais j'espère que les utilisations pourront évoluer. Je pense que le choix historique de TCP est dû au fait qu'à l'époque, les machines étaient tout le temps connectées, et allumées, et qu'on n'éteignait rarement une machine à l'arrache. Certes, ça a évolué, mais ça ne me paraît pas aberrant aujourd'hui que la gestion de l'état des connexions tcp soit « persistante » à travers l'utilisation de la mise en veille, par exemple.

C'est une protection contre les leaks involontaires. Quand tu es en utilisation interactive tu veux que quand y'a un problème, ca garbage automatiquement, pas devoir revenir tuer tes shells, et les admins ne veulent pas non plus avoir à gérer ca.

Oui, mais ça ta machine le fait aussi normalement si tu ne l'éteins pas comme un barbare. Tu peux tuer tous tes processus, c'est ton OS qui fermera tranquillement tes sessions tcp. Les piles tcp sont quand même vachement bien pensées pour ça !

Faut vraiment vivre à bisounours land pour penser que les utilisateurs reviennent tuer les processus quand une session interactive foire et qu'ils ont envi de s'amuser à retrouver les processus.

Mais c'est quoi une session interactive qui foire ?! Le seul cas que je vois, c'est le plantage de l'OS (même pas du programme !), ou le redémarrage alors qu'on est déconnecté du réseau. Ça arrive si souvent que ça ?

Bien sur que si ton client SSH se termine avec un 255 comme exit value que se soit avec le TCP keepalive (bon la on est sur un temps de ~2h) ou le server alive.

Le keepalive TCP est actif par défaut, pas le server alive. C'est la conf utilisée partout. Du coup je suis un peu emmerdé.

Oui c'est facile à dire quand le choix est pertinent et qu'en plus on peut le modifier.

J'ai lancé ce journal pour discuter de la pertinence de ce choix. Je n'ai pour l'instant pas été très convaincu des arguments pour justifier ce choix.

Après, oui, il est modifiable, mais c'est comme tout : c'est très facile d'envoyer balader quelqu'un en lui disant qu'il peut faire autrement. Les choix par défaut sont une composante essentielle du fonctionnement global d'une technologie. Je trouve que ce choix par défaut est dommage car il pénalise les gens qui utilisent toutes les possibilités du réseau.