dguihal a écrit 1031 commentaires

La n'est pas la question je sais gérer des droits et des groupes sur un Windows merci.

Ce que je te dis, c'est qu'une installe windows de base telle qu'on la trouve sur un PC du commerce (cad celle utilisée par la majorité des gens) donne les droits d'admin par défaut au compte par défaut que tout le monde utilise.

Donc après dire "Windows n'a jamais permis a un utilisateur simple d'installer qqe chose sur le systeme en global" c'est vrai dans l'absolu, mais complètement a coté de la plaque de ce qui se passe dans la vie réelle

vim ou emacs même avec plein de plugins/scripts/extensions dedans sont très loin d'offrir les fonctionnalités d'un eclipse.

Après que tu t'en contente très bien pour toi.

Pour ma part y'a une semaine ou deux j'ai eu l'occasion de mettre les mains dans un vista de base fourni avec un laptop Compaq et la sécuritén' était pas meilleure :

Tu dl n'importe quel intalleur de programme
Tu double clique dessus
Vista te demande si tu veux bien faire l'installe
Vista te re-demande si tu veux bien faire l'installe (pourquoi ? On sait pas)
Vista installe le soft.

Jamais vu passer une demande de mot de passe ou quoi que ce soit s'en rapprochant.

Bref comme Fedora mais en pire (ben oui pour la signature on te dis juste que c'est pas signé, mais tu clique OK et basta on continue)

Tu parles de la série des NT parce qu'a ma connaissance des windows y'a a eu d'autres et pas vraiment sécurisés eux (3.X, 95, 98, ME)

Eclipse, NetBeans
GanttProject
Tomcat/JBoss
ArgoUML
BlueJ
OBM
JEdit
SoapUI
Squirrel SQL
Jmeter
ldapbrowser
jxplorer

Regarde sur freshmeat :

Programming languages
Java : 5496 projets
C# : 80 projets

Y'a pas photo

Oui enfin je connais pas la situation en entreprise mais je me dis qu'avec un framework si parfait et sexy, selon les dires des mono-istes, et avec tellement d'utilisateurs, toujours selon leur dires, il y ait aussi peu d'applications tournant sous cet environnement ...

Il est pas développeur mais Lead Architect, nuance

1 - Pour être juste tu devrais détailler la pelleté d'headers HTTP que tu as "omis" de mentionner et qui n'existent pas en FTP.

2 - Maintenant refais le même scénario dans le cas de la mise à jour d'une distib représentant environ une dizaine de paquet, pas sur qu'en HTTP ce soit plus efficace.

Maintenant un test rapide qui vaut ce qui vaut :
FTP : http://www.ietf.org/rfc/rfc959.txt 69 pages (c'est marqué en bas)
HTTP : http://www.ietf.org/rfc/rfc2616.txt 176 pages (c'est marqué en bas aussi)

Alors oui FTP est simple et oui il est rapide, moyennant un cout initial un peu plus élevé (et encore je vais mesurer ce soir chez moi les volumes transitant pour un transfert simple mais c'est même pas sûr).

Pas d'accord, le mode PASV est justement là pour résoudre le problème de NAT client, je te rappelle que dans ce cas c'est le client qui initie les 2 connexions, je vois pas comment ça poserait problème à un NAT. Là ou il pose problème c'est sur un FW/DNAT/LB coté serveur.

Quelques secondes pour ouvrir une connexion FTP ? T'as un problème quelque part quand même. Le protocole est ultra simple et bien qu'il impose l'ouverture de 2 connexions TCP (et encore je suis pas sur que la connexion data soit ouverte dès le début) plusieurs secondes pour ça me parait aberrant

Si je cherche un peu, je trouve :
http://www.google.com/support/forum/p/Chrome/thread?tid=57b3(...)

Donc je dirai Chrome

et en cherchant encore :
http://forum.macbidouille.com/index.php?showtopic=84933

Et donc j'ajouterai safari.

Ca ira ?

Non (cf Firewall, NAT, Ca casse pas mal la simplicité)

Le mode PASV est la pour ça. De plus le protocole est implémenté largement coté client et serveur, donc les détails d'implémentation tu t'en contrefous, par contre a l'utilisation, mettre en place un serveur ftp pour usage de plateforme ou a la maison, voire même public c'est simple.


Non dans 99.999% des cas (celui d'un download de fichier unique), FTP a 2-3 fois plus d'overhead que HTTP (compte les connexion TCP, la couche IP...). Dire que FTP consomme moins de BP/CPU, c'est un peu rigolo...

Je te rappelle, même si je te l'accorde c'est parti est troll, qu'on parlait d'un gestionnaire de paquet. Donc bien qu'il arrive qu'on ne télécharge qu'un seul fichier, il est très courant d'en télécharger plusieurs voire plusieurs dizaines, et là HTTP avec sa pelleté d'headers est très loin d'être optimal.

Moi je pense que si les admins ont mis une surcouche HTTP c'est :

- Pour les fainéants qui veulent pas quitter leur navigateur pour ouvrir un client ftp
- Pour tous ceux qui ont un proxy HTTP entre le PC du boulot / de la FAC / ... et internet

Merci je connais, maintenant quel est l'intérêt ?

C'est ce que j'essaye d'expliquer depuis le début de ce TROLL thread. FTP permet de faire du transfert de fichier de manière simple, pratique (même si y'a 2 sockets TCP et que ca fais chier les firewall) et avec peu d'overhead, alors pourquoi s'en passer ?

Dans le contexte "bureautique" y'a peu de firewall, on trouve plutot un proxy HTTP dans le contexte d'entreprise ou un gros NAT avec la BOX, NAT facilement gérable avec le mode PASV.

Dans un contexte serveur pur, j'ai plus vu (je ne travaille pas en prod), de NFS / Samba / CFT / rsync pour le transfert / synchronisation de fichiers.

Et moi quand je mets à jour ma distrib je pense au miroirs publics en me disant que récupérer 20 paquets par FTP ca coute moins cher en ressources qu'en HTTP, et que je n'ai pas encore vu de miroirs webdav.

Pour te recadrer un peu, je ne cherche pas a prouver la supériorité absolue du FTP, ce qui serait absolument idiot.
Je m'oppose simplement a ceux qui trouvent que ce protocole est complètement a la ramasse sur tous les tableaux.

Oui FTP a des avantages que HTTP n'a pas, c'est ce que je tenais a rappeler, l'inverse est également vrai vu que les protocoles ont été créés dans des buts différents.
Oui FTP pourrait être partout remplacé par HTTP/DAV ou SFTP ou autre c'est comme dire qu'on pourrait mettre des vis partout a la place de clous, c'est idiot et chaque outil a ses avantages comme ses inconvénients.

Mea coulpa j'ai extrapolé trop vite, et chez debian c'est pareil.
Mais si l'on regarde la plupart des noms de serveur, on se retrouve avec énormément de serveurs ftp.qqchose.com et pas www.qqchose.com . C'est certainement pas par hasard

Je parlais de connexion FTP, effectivement y'a deux connexion TCP

donc 3 paquets TCP sans data de + ( 3 * 60 octets)
PASV 4 octets ....

Mais ce cout est identique que tu transfere 1 ou 10 fichiers contrairement a HTTP

Tu fais comment pour lister un répertoire en HTTP ?
Un indice :
http://ftp.debian.org/ et regarde le volume des données utiles par rapport au bruit du HTML. Et je te fait grace des headers

Non mais ça ne change rien au fait qu'HTTP n'apporte rien par rapport a son surcout BP/CPU dans ce cas

Y'a plein de cas d'utilisation ou tu te fous de la sécurité en lecture (miroir public typiquement)
Et la l'overhead BP/CPU du sftp n'apporte strictement rien si ce n'est des couts en achat de matos / BP.

Si tu regardes les miroirs public de la plupart des distibs y'a beaucoup plus de ftp que de http. Ce n'est certainement pas un hasard. Exemple fedora :
http://mirrors.fedoraproject.org/publiclist

w3m et lynx sont incomparablement moins pratique qu'un lftp ou ncftp ou ... pour les transferts de fichier.

- Pas d'autocompletion
- Pas de multi-get ou multi-post
- Pseudo interface graphique a la place d'une simple ligne de commande
- Pas scripting (oui on peut scripter ftp/lftp)
- commande mirror ?

Pour la puissance CPU et la BP ca reste du gaspillage d'argent, de ressources, d'électricité pour apporter quoi ? Rien dans ce cas.

Oui Debian et Fedora et les autres utilisent HTTP :
http://ftp.fr.debian.org/debian/ (Tiens y'a ftp dedans l'url, ce serait-il pas un mirroir ftp avec une interface http posée dessus ?)

Et pour fedora c'est moins clair, mais si on regarde ici : http://mirrors.fedoraproject.org/publiclist y'a plus de liens en ftp qu'en http. C'est que le HTTP doit être mieux certainement .....

Il a quand même le mérite d'exister

Y'a pas de header dans ftp, une fois la connexion ouverte, y'a juste ta commande qui passe dans le flux de commande
donc comparer

get toto/ttiti/kldskfs/.../lkjdfksf

et
GET /toto/ttiti/kldskfs/.../lkjdfksf HTTP 1.1
Accept : ........
...
...
...
...
...
cookie : ...

+ Header de réponse

c'est franchement osé.

Tu veux me faire croire que partant de 0 (c'est a dire ne connaissant pas l'adresse exacte de la spécif HTTP sur le site du w3c), tu as mis 12 secondes pour trouver que HTTP 1.1 c'est la rfc 2616 et que le byte range c'est a la section 14 paragraphe 35 ?

Soit tu es un bot, soit tu trolle (mais bon Linuce n'est pas connu pour ça :) ), soit tu mens.

Enfin merci pour le lien quand même.

Pour info j'avais fini par chercher moi-même sur google pour trouver ceci : http://www.lassosoft.com/Documentation/TotW/index.lasso?9233

- pour la récupération de fichiers, FTP peut avantageusement être remplacé par HTTP ;

Pas d'accord, le jour ou X est planté à cause d'un paquet foireux, c'est bien pratique de pouvoir sortir lftp pour récupérer des fichiers dans un dépôt distant.

- pour l'envoi de fichiers, FTP ne peut pas être simplement remplacé par HTTP, mais ça tombe bien, il peut avantageusement être remplacé par SFTP, à la place ;

FTP à un meilleur ratio de Bande Passant utilisée / Bande Passante Utile
FTP est nettement moins consommateur de CPU de SFTP (le chiffrement ça coute du CPU)

- bref, d'une façon générale, FTP est inutile sauf si on tient à se fabriquer des ennuis.

Le jour ou tu veux monter un dépôt ouvert a tout le monde (genre un miroir de distribution) tu prends le protocole le moins couteux en BP / CPU et là FTP est nettement devant les autres.

Bof les framework c'est rarement standard

De plus tu peux complètement te passer de X avec un bon packaging, et oui Qt depuis la version 4.0 est modulaire et seuls QtGui et QtWebKit dépendent de X.

Donc quand on ne sait pas de quoi on parle on se renseigne

Je suis très curieux de connaitre la manière de commencer un téléchargement à une position arbitraire avec HTTP ? Ceci est une vrai question.

Et non un hack en PHP / JSP / brainfuck / ... n'est pas recevable, en pur HTTP.