barmic 🦦 a écrit 5783 commentaires

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

Tu as déjà configuré un firewall pour du ftps ?

Vraiment ça fait une grosse dizaine d'années que vous cumulez de la dette technique et que tout le monde fuit ce protocole. Il y a un moment où ça casse.

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

Java et flash avaient leurs sandbox, potentiellement meilleures que celle du navigateur au moment de leur arrivés. C'est le passage d'une sandbox à l'autre qui posait beaucoup de problèmes.

Je ne comprends pas bien ce premier paragraphe qui est là plus pour libérer une frustration que pour apporter de l'information. Ça se pleins de faire des choses dans un navigateur puis de faire des choses à côté du navigateur par exemple.

C'est loin de la ligne éditoriale plus neutre que je préfère en dépêche, mais ça doit être mon opinion personnelle.

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

Je ne comprends pas. Firefox n'a jamais pu faire d'upload ftp donc tu créé un compte mais tu devais passer par autre chose au final pour le partage.

Et encore une fois :

Ce qui est dommage c'est de pas passer au ftpS :/

ftps est au moins aussi cramé que ftp.

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

À ce propos attention, scp n’utilise pas SFTP (à ma grande surprise quand j’ai découvert ça)

Le lien que tu donne indique que c'est entrain de changer.

As it turns out, Jakub Jelen is working on such a thing; it is an scp command that uses the sftp protocol under the hood.

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

Récemment c'est l'histoire du port 22 que j'ai lu (The story of getting SSH port 22).

En particulier Tatu Ylonen (concepteur de SSH) a choisi 22 car il voulait remplacer telnet (port 23) et ftp (port 21) et quand il a demandé l'obtention de à l'IANA a reçu un mail surprenant de simplicité :

Date: Mon, 10 Jul 1995 15:35:33 -0700
From: jkrey@ISI.EDU
To: ylo@cs.hut.fi
Subject: Re: request for port number
Cc: iana@ISI.EDU

Tatu, We have assigned port number 22 to ssh, with you as the point of contact.  Joyce

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

SSHFS est un vrai système de fichiers en réseau ;)

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

Et je sais pas si on aurait eu le kernel dans le même état sans la GPL v2. Fondamentalement, le fait de faire un fork proprio est coûteux sur le long terme donc la GPL ne fait que forcer une coopération qui serait sans doute arrivé naturellement.

Je ne sais sincèrement pas. Linux ne s'est pas fait en un jour. Avant qu'il passe le point d'équilibre de ne plus être forkable (ce qui est intéressant comme concept pour un fleuron du libre), il n'aurait peut-être pas connu ce succès.

De la même manière j'ai vu des gens dire que gcc, sa licence et sa non modularité ne servent à rien vu comme llvm est un succès. llvm n'aurait peut-être pas vu le jour qui gcc n'avait pas été un succès et que chaque plate-forme venait avec son compilateur, sans chercher l'interopérabilité avec gcc.

Ce sont 2 logiciels qui ont fait émerger un bien commun, mais rien ne le garantit au départ et il y a pleins d'exemples qui montrent que ça n'est pas simple (ni juste une histoire de licence).

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

C'est Mozilla qui développe le support de ces plugins

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

• sftp (et bien sftp commencez pas à acheter des appliances impossible à mettre à jour qui ne savent faire que du scp)
• nfs
• cifs
• bittorrentsync
• syncthings

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

Le truc qui empire les problèmes de firewall. Ça fais quand même une bonne dizaine d'années que l'on connait les problèmes de FTP et qu'on a de multiples alternatives

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

Il faut continuer à maintenir flash parce que tu va encore trouver des gens qui s'en servent par exemple ?

Mozilla particierait-il à l'obsolescence programmée ?

C'est ton fabriquant ou ton vendeur qui ne fait pas de support ça n'a rien à avoir. Surtout que bon filezilla existe toujours.

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

La pertinence et les problèmes des protocoles qu'ils prennent en charge ? Oui évidement.

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

Le transfert ASCII peut changer le fichier que tu distribue.

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

Une fois je lui ai demandé si elle avait besoin d'un Windows et elle m'a répondu 'Non, pas besoin, Ubuntu c'est bien'. (quelque part ça m'a fait plaisir).

Tu l'a pas trollé « ubuntu c'est pour les noob. slackware c'est pour les vrais »

comme ça il comprendra qu'un logiciel non libre n'est pas donné en général

Ou il fera l'association libre as a free beer.

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

Le problème, c'est qu'il n'y a pas vraiment de remplaçant dans le navigateur, pour se partager facilement des fichiers. http(s), l'upload est compliqué.

Firefox n'a jamais permis de faire un upload FTP, il y a des extensions qui l'ont fait (je ne sais pas si ça existe encore) qui avait leur propre implémentation du protocole.

Donc :

Alors on fait quoi ?

Je dirais comme jusqu'à présent.

Si ce qui t'embête ce que tu cherche c'est à présenter un dossier tous les serveurs web font ça très bien.

Sinon il reste webdav qui a le bon goût d'être supporté par les explorers ms-windows. Bin oui, il faut que ça tourne sur le parc, tout ça.

Si c'est pour une question de gestion de parc (pas ouvert sur internet) tu as l'embaras du choix :

• webdav
• nfs
• cifs
• seafile/bittorrentsync/…

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

Firefox a tendance à supprimer des fonctions utiles

Comme flash et les applets java par exemple ? Et ils n'ont jamais implémenté les activX, ces gredins !

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

Tout le monde veut la mort de FTP c'est un protocole obsolète. Ce n'est pas qu'une question de sécurité.

On peut avoir envie de partager des documents publiquement, sans que la confidentialité ne soit un problème.

On peut dire la même chose pour http, mais ne pas vérifier l'identité du serveur ça rend transparent le fait que tu le visite et ça permet de man in the middle (wikipedia a des données publiques pour autant si je peux placer mon serveur devant pour fournir des fausses information ça pose un problème par exemple).

En plus c'est un mauvais protocole pour la distribution. Son unique intérêt sur https à ce niveau là c'est de permettre l'envoi de données, mais je suis pas certain que les navigateurs aient un jour implémenté l'envoi.

C'est un protocole très difficile à administrer, son mode passif/actif le rend très couteux pour les firewall par exemple. Sa gestion de l'encodage peut aussi poser problème.

Il existe différents protocoles qui marchent bien mieux (en fonction du sftp, bittoren, https,…).

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

La même qui fait accepter des jeux propriétaires alors qu'on refuse des systèmes d'exploitation propriétaire : les concessions.

Pour le coup ce que ça apporte :

• un cloisonnement fort, tu es sur une appliance
• un besoin de SAV minimaliste

Arpès tu peux aller plus loin et installer des jeux propriétaires sur une console dont l'OS est libre mais ça marche surtout quand on est fan de retrogaming et j'ai l'impression que c'est rare de commencer les jeux vidéos par là.

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