Cela fait quelques temps que je n'ai plus fait de journaux, et cette fois-ci, ce ne sera pas un journal élogieux sur un projet sujet à troll que j'aime particulièrement.
Aujourd'hui, je vais vous proposer le fruit de plusieurs mois de travail, le tout présenté correctement, je l'espère, et Libre, bien entendu.
Le gestionnaire de paquetages Setup
Comme annoncé dans ce journal, je travaille depuis quelques temps sur un gestionnaire de paquets. Le but, au lieu de récupérer l'existant, est de se baser sur du propre.
Le gestionnaire de paquet est quasiment utilisable (il installe des paquets), mais est encore loin d'être fini. Il propose néanmoins déjà quelques fonctionnalités normales ou intéressantes que voici :
- Gestion des dépôts multiples de logiciels, de plusieurs types (distants et locaux pour le moment, mais bientôt sur CD/DVD, etc). Le FTP est géré
- Résolution des dépendances avec le système par branches décrit dans mon journal (lien plus haut), et qui marche
- Installation des paquets
- Signature des métadonnées du dépôt avec une clef GPG, somme de contrôle SHA1 pour tous les fichiers téléchargés
- Toute petite infrastructure de messages entre les paquets et l'utilisateur. Au menu pour ce week-end : gestion complète de tout ça sous forme de questions stockées dans un fichier XML, à la manière de debconf
- Affichage de plein d'informations, localisées dans la langue de l'utilisateur (pour le moment juste le français et un tout petit peu d'anglais)
Ça, tous les gestionnaires de paquets le font plus ou moins. La différence, c'est que Setup fait ça en moins de 4000 lignes, bibliothèque de gestion des paquetages et front-end console compris. Le tout est relativement léger, bien que pas encore optimisé.
Ainsi, on a une base propre et simple sur laquelle construire l'avenir des gestionnaires de paquets. La méthodologie est la même que celle utilisée par KDE : tout refaire, mais suffisamment bien pour que les modifications soient plus faciles à faire, et ainsi pouvoir amener des choses intéressantes.
Setup est codé en C++ et utilise Qt. Pourquoi ce bloat ? Parce que Qt (dont le module GUI n'est pas utilisé) factorise suffisamment le code pour permettre de créer un Setup léger de 4000 lignes, et comporte des modules très intéressantes :
- QtCore pour la base et plein d'autres choses. Une table de hash avec Qt, c'est du bonheur. Parser un fichier de configuration, c'est super simple. Gérer des options, un jeu d'enfant, etc
- QtNetwork, qui permet, en ne dépendant ni de GNOME ni de KDE, de permettre à l'utilisateur d'utiliser des dépôts HTTP, FTP, NFS, et tout ce que QtNetwork peut gérer (il est prévu pour une future version de Qt de baser QtNetwork sur GVFS ou KIO, suivant le DE utilisé en dessous. Que du bon)
- QtScript, qui permet de scripter Setup. Pour le moment, seul la "pesée" des branches peut être contrôlé. Ainsi, on peut en modifiant un script choisir si on préfère télécharger le moins, installer uniquement des paquets stables, etc. Sachant que c'est du script ECMAScript, la syntaxe est suffisemment riche pour permettre un équivalent du APT Pinning, etc
- QtXml, pour lire les métadonnées (descriptions, mais aussi icône, changelog, etc)
Le résultat est disponible en téléchargement, et tester Setup est expliqué en détail sur le site flambant neuf de Logram. Normalement, ça marche, j'ai testé. S'il y a des erreurs, signalez-les moi. Si vous sortez des sentiers battus, il se pourrait que quelque-chose ne marche pas (la mise à jour de la BDD après installation est encore quelque peu fragile, la suppression n'est pas gérée).
Et comme pas mal d'entre vous m'avez posé pas mal de questions sur le fonctionnement de Setup, j'ai pensé à vous, et rédigé une documentation complète sur le fonctionnement interne de Setup et de sa base de donnée. C'est, je crois, le seul qui existe en français.
Travail collaboratif d'un projet dans un environnement de rêve
Pour ceux qui suivent un peu l'histoire de Logram, l'environnement de bureau et distribution que je développe, vous avez pu remarquer que le site a changé.
En effet, cela fait depuis 3 ou 4 mois que je code cette nouvelle version, en parallèle à Setup. Logram dispose maintenant d'un site aux fonctionnalités de pointe, intégrées au sein d'un même environnement :
- Un forum plus que convenable avec modération, sondages, gestion du lu/non-lu, abonnement aux sujets, permissions, etc
- Un wiki correct et suffisant, avec historique des pages, droits, protection, privatisation (ok, les moules n'aiment pas ce mot), etc. Il ne vaut pas MediaWiki (utilisé par Wikipédia), mais c'est correct pour l'utilisation qu'on en fait
- Un webSVN basique mais permettant de directement montrer aux gens du code. Ainsi, ça encourage les membres à participer, du fait qu'ils voient les modifications de code en direct
- Un système de demandes permettant de gérer les bugs, les demandes de code, les idées, et tout ce qu'on veut, avec gestion des sous-demandes, demandes liées, importance, assignation, fichiers liés, et des dizaines d'autres détails qui rendent la vie agréable
- Un espace de téléchargement basique permettant de vite télécharger un truc
- La gestion des paquets de Setup est intégrée au site. C'est comme packages.debian.org, mais en mieux intégré au reste, et avec un design plus "frais"
- Un système de messagerie privée à plusieurs participants
- Un système d'envoi de fichiers avec gestion des dossiers et des quotas
- Un système de gestion des nouvelles, publiques ou privées (équivalent Linuxfr : dépêches ou journaux), avec validation, modération, gestion du workflow (ici on peut éditer un journal en ligne, on peut aussi le dé-publier, et gérer ça comme un blog)
Pourquoi je me permet de faire de la pub pour mon site !? Et bien, c'est simple : il est disponible pour tout le monde sous GNU GPL, avec quelques fichiers dans le domaine public (templates), et quelques fichiers en CC-By-Sa (images, design, icônes Oxygen réutilisées).
De plus, ce site est intéressant du fait qu'il ne suit pas les conventions. En effet, il est développé en Python et utilise le framework Django. Du côté serveur, ce n'est pas Apache mais Nginx qui tourne, largement plus rapide (on peut servir 20 pages par secondes sur la page d'accueil, alors que Apache en WSGI ne dépasse pas 6 pages par secondes, sur le même serveur hardware).
Le code est librement téléchargeable, et consultable dans notre WebSVN. Des rapports de bugs ont déjà été remplis, la méthode pour tester est détaillée (besoin de Django, MySQL, et quelques dépendances), et normalement ça marche.
Django découpe suffisamment en modules pour permettre de remplacer la gestion des paquets de Logram par n'importe quelle autre gestion. Le but de cette ouverture est de permettre aux autres distributions, ou aux autres projets, de bénéficier d'une forge de qualité intégrant de bons outils (par exemple, un forum correct, introuvable sur les autres forges). L'administration est encore un peu compliquée, mais le projet est jeune. C'est vraiment un truc que j'ai développé pour les autres avant de le faire pour moi, le fait que Logram l'utilise est un simple "bonus".
Si un projet Libre, de préférence francophone (parce qu'on n'a pas encore totalement fini le support multi-lingue), genre Wormux, a besoin d'un site web, j'espère que cette version conviendra. Si vous avez des demandes, je suis à l'écoute. Par contre, je ne pourrai pas aider pour le support, je n'ai malheureusement pas le temps. Il faudra un peu se débrouiller (mais normalement, le code est pris en main en une journée)
Bonne découverte.
# FTP
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Quel intérêt ? Quel avantage présente FTP par rapport à HTTP ? Les inconvénients, on les connaît : les sessions sont plus lentes à établir et ça utilise deux flux – l'enfer pour les pare-feux –.
[^] # Re: FTP
Posté par Anonyme . Évalué à -2.
Personnellement, il me viendrait même pas à l'esprit de faire transiter mes sources autrement que par FTP ou un gestionnaire de version (GIT par exemple).
[^] # Re: FTP
Posté par Zenitram (site web personnel) . Évalué à 8.
Tu prends le message précédent, tu lis les inconvénients donnés au FTP, et hop tu as les avantage de HTTP par déduction, s'est-il pas beau?
Plus sérieusement, HTTP est tellement plus simple pour faire du transfert de fichier que FTP (qui malgré son nom, ne rend pas le transfert de fichier simple) que quand on réfléchi à implémenter, on voit rapidement qu'il faut plus de temps pour FTP, et quand on teste FTP a grande échelle on s'aperçoit que c'est une horreur sans nom (firewall, NAT etc...)
Mais ici, pour bâcher un peu tout le monde, pourquoi ne pas proposer FTP en plus de HTTP? Qui peut le plus peut le moins, et Qt offre une manière transparente de gérer les 2 protocoles.
[^] # Re: FTP
Posté par kursus_hc . Évalué à 4.
[^] # Re: FTP
Posté par Elfir3 . Évalué à 3.
[^] # Re: FTP
Posté par Étienne . Évalué à 7.
[^] # Re: FTP
Posté par Le Pnume . Évalué à 6.
[^] # Re: FTP
Posté par steckdenis (site web personnel) . Évalué à 4.
[^] # Re: FTP
Posté par Zenitram (site web personnel) . Évalué à 1.
[^] # Re: FTP
Posté par Anonyme . Évalué à 1.
d'aprés http://tools.ietf.org/html/rfc959 cela date un petit peu certe ! Sinon pour faire une Qos sur un serveur il me semble que c'est plus facile si tu as du ftp et du http, sinon faut se palucher les exeptions en fonctions du repertoire d'accés plutot que du protocol amha.
[^] # Re: FTP
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Bref, qu'aujourd'hui, on n'a pas besoin de FTP, sauf si on tient à se fabriquer des ennuis.
[^] # Re: FTP
Posté par briaeros007 . Évalué à 3.
Mais pour récupérer un document c'est clair que http est bien plus adapté que ftp.
[^] # Re: FTP
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: FTP
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Le seul cas que je connaisse ou FTP est la seule solution, c'est l'envoi de fichiers de façon anonyme. Mais c'est quand même très rare, comme utilisation.
[^] # Re: FTP
Posté par briaeros007 . Évalué à 1.
Mais là on parlait de ftp vs http, pas de ftp vs sftp.
[^] # Re: FTP
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
- pour la récupération de fichiers, FTP peut avantageusement être remplacé par HTTP ;
- 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 ;
- bref, d'une façon générale, FTP est inutile sauf si on tient à se fabriquer des ennuis.
[^] # Re: FTP
Posté par dguihal . Évalué à 3.
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.
[^] # Re: FTP
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
[^] # Re: FTP
Posté par dguihal . Évalué à 3.
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
[^] # Re: FTP
Posté par zebra3 . Évalué à 3.
Ça tombe bien, ça marche aussi avec HTTP. J'ai déjà dû récupérer des paquets sans dépôt, ça se fait très bien avec w3m et HTTP, visuellement en plus.
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)
C'est pas comme si on n'avait pas de la puissance à revendre dans nos processeurs actuels. Il y a même des puces conçues pour le chiffrement.
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.
Il faudra que tu ailles l'expliquer aux mainteneurs Debian et Fedora qui utilisent HTTP. Ça doit être des gros boulets.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: FTP
Posté par dguihal . Évalué à 2.
- 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 .....
[^] # Re: FTP
Posté par Zenitram (site web personnel) . Évalué à 3.
Il y a plus de lien FTP que HTTP? Problème de mathématique? Ou inversion de nom de protocoles?
284 HTTP vs 238 FTP.
[^] # Re: FTP
Posté par dguihal . Évalué à 2.
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
[^] # Re: FTP
Posté par Zenitram (site web personnel) . Évalué à 3.
C'est effectivement certainement pas un hasard si les uploaders (0.001% des utilisateurs) utilisent FTP pour l'upload mais que les admins ont mis une surcouche HTTP pour les downloaders (99.999% des autres utilisateurs) pour le download.
Arrête, tu t'enfonces... FTP est bien pour l'upload, mais reste pourri pour le download, quoique tu cherches à inventer quand on te met le nez dedans.
[^] # Re: FTP
Posté par dguihal . Évalué à 2.
- 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
[^] # Re: FTP
Posté par zebra3 . Évalué à 2.
Cite moi un navigateur moderne qui ne gère pas le FTP.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: FTP
Posté par dguihal . Évalué à 3.
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 ?
[^] # Re: FTP
Posté par Anonyme . Évalué à 1.
[^] # Re: FTP
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: FTP
Posté par Anonyme . Évalué à 1.
[^] # Re: FTP
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: FTP
Posté par Anonyme . Évalué à 1.
Ouai non, ça me faisait bizarre d'entendre : « FTP passe ton MDP en clair » et que la seule alternative qui vienne c'est SFTP quoi…
[^] # Re: FTP
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Avec FTPS, tu peux chiffrer les deux canaux ou seulement l'un des deux. Donc tu peux chiffer le canal de controle ou passe le mot de passe et le login mais pas le canal de données. C'est très intéressant.
Je connais des boites qui sont a 100% pour de la sécurité, HTTPS partout... et qui t'envoi pas mail des documents top secret !
Bref, FTPS, permet de résoudre le problème du mot de passe en clair tout en profitant de la bande passante du FTP ou effectivement, très souvent, on n'a pas besoin de chiffrement.
Dernier exemple, je dois rapatrier 600Go de données non archi secrete de l'IDRIS sur une de mes machines, je reste a 100% sur le réseau Renater. Le FTPS avec le seul chiffrement du canal de contrôle est une solution intéressante.
[^] # Re: FTP
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: FTP
Posté par dguihal . Évalué à 2.
[^] # Re: FTP
Posté par Zenitram (site web personnel) . Évalué à 2.
Surcout que tu n'arrives pas à prouver, les exemples que tu donnes étant en faveur de HTTP... Mais bon, si tu veux absolument croire qu'un protocole qui ouvre deux ports est moins consommateur qu'un protocole qui ouvre un port... (sans parler de la simplicité de mise en œuvre, firewall, NAT... non, c'est vrai quoi, HTTP n'apporte rien, sauf des avantages que tu refuses de lire)
[^] # Re: FTP
Posté par dguihal . Évalué à 3.
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.
[^] # Re: FTP
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Quelqu'un utilise le WebDav sur un vrai serveur de fichier, avec une utilisation normale ?
[^] # Re: FTP
Posté par Jean B . Évalué à 1.
Et sur le papier ce protocole a l'avantage d'être supporté nativement par tous les bureaux grand publique, en pratique tous les gens ayant développé un serveur WebDAV te le diront leur implémentation comprend autant de hacks pour être compatible avec les divers clients que de code propre à la spec.
[^] # Re: FTP
Posté par zerkman (site web personnel) . Évalué à 2.
En es-tu bien sûr ? J'ai pourtant l'impression que HTTP est un des protocoles de transfert où l'overhead est quasi négligeable. À part les headers de quelques centaines d'octets, tout le reste c'est les données brutes transférées à peu de choses près.
[^] # Re: FTP
Posté par dguihal . Évalué à 2.
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é.
[^] # Re: FTP
Posté par Zenitram (site web personnel) . Évalué à 3.
Tu peux me dire comment tu fais du FTP avec une connexion, ça m'interesse.
Je ne sais pas faire avec moins de 2.
Et entre la fourniture de PASV, 2 init TCP, et j'en passe, l'overhead FTP est énorme par rapport à HTTP... Ne parlons même pas du temps de réponse avec ces commandes et ouvertures de port séquentielles
FTP, c'est pourri pour un transfert de fichier public!
[^] # Re: FTP
Posté par dguihal . Évalué à 2.
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
[^] # Re: FTP
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: FTP
Posté par dguihal . Évalué à 2.
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.
[^] # Re: FTP
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
En même temps ce n'est pas nécessaire. Ton gestionnaire de paquets sait précisément ce qu'il doit télécharger, et n'a absolument pas besoin d'index de répertoires.
[^] # Re: FTP
Posté par Zenitram (site web personnel) . Évalué à 3.
Non (cf Firewall, NAT, Ca casse pas mal la simplicité)
et avec peu d'overhead
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...
alors pourquoi s'en passer ?
Parce qu'il ne convient pas dans 99.999% des cas.
Non, on ne peut pas s'en passer quand on est développer/uploader/échange de plusieurs fichiers, je l'utilise moi-même tous les jours (FTP/SFTP), mais je suis réaliste : c'est pour un besoin précis.
Pour transférer un fichier de manière simple dont on a l'URL, soit 99.999% des demandes, FTP est une horreur que ce soit en connexion, overhead, simplicité etc...
[^] # Re: FTP
Posté par dguihal . Évalué à 2.
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.
[^] # Re: FTP
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Question surcharge, je ne sais pas ce que ça donne chez vous, mais initialiser une connexion FTP, ça prend quelques secondes, là où, en HTTP, j'ai déjà la liste des fichiers en HTML, et commencé à en télécharger un.
[^] # Re: FTP
Posté par dguihal . Évalué à 2.
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
[^] # Re: FTP
Posté par Zenitram (site web personnel) . Évalué à 2.
FTP simple???
(et encore je suis pas sur que la connexion data soit ouverte dès le début)
Non, puisqu'ils négocient le port lors du dialogue.
Tu oublie pas mal d'échanges en FTP...
plusieurs secondes pour ça me parait aberrant
Plusieurs secondes, c'est peut-être beaucoup.
Mais dans le genre 5x plus lent que HTTP, sans aucun doute.
Pense aux aller-retour login/pass inutiles, allez je suis gentil je te fais un listing :
Connexion
USER
réponse
PASS
réponse
TYPE I
réponse
PASV
réponse
RETR
réponse avec adresse/port passif
2ème connexion
transfert
en HTTP :
Connexion
GET blabla en 1 fois
réponse + transfert en une fois
Et après tu oses dire que FTP est simple, rapide???
[^] # Re: FTP
Posté par dguihal . Évalué à 3.
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).
[^] # Re: FTP
Posté par zerkman (site web personnel) . Évalué à 2.
Et ça reste du HTTP, encapsulable dans du SSL, permettant donc un certain niveau de sécurité (que FTP ne permet pas, les mots de passe et les données transférées étant en clair).
[^] # Re: FTP
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: FTP
Posté par zerkman (site web personnel) . Évalué à 2.
[^] # Re: FTP
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: FTP
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: FTP
Posté par briaeros007 . Évalué à 2.
Pour éviter de tomber dans l'amalgame faux, ftp a son pendant ssl : ftps.
Même si moi je préfère sftp, inutile d'inventer de faux prétexte pour contrer le ftp. Rien que le principe d'ouvrir de nouvelles connexions est une aberration en soi (-pas au temps où il a été concu, mais maintenant-)
[^] # Re: FTP
Posté par dguihal . Évalué à 3.
Et le File_Transfer_Protocol_over_SSL (ou FTPS) et le Secure_FTP c'est pour les axel ?
[^] # Re: FTP
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: FTP
Posté par dguihal . Évalué à 2.
[^] # Re: FTP
Posté par dguihal . Évalué à 5.
A cela j'ajouterais le mget, mpost et la possibilité majeure à mes yeux de naviguer dans une arborescence distante à partir d'une ligne de commande, et même un semblant de complétion avec un bon client.
Et si tu veux de la sécurité plus avancée tu peux utiliser Secure_FTP.
Donc je suis désolé mais ftp à encore de beaux jours devant lui
[^] # Re: FTP
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Secure FTP… Du FTP encapsulé dans du SSH : l'usine à gaz, alors qu'avec SSH on peut déjà faire du SFTP.
[^] # Re: FTP
Posté par dguihal . Évalué à 4.
Et non un hack en PHP / JSP / brainfuck / ... n'est pas recevable, en pur HTTP.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: FTP
Posté par dguihal . Évalué à 0.
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
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: FTP
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Ça marche, donc d'un façon ou d'une autre ça doit être possible. C'est ainsi que HTTP est le moyen le plus simple de mettre en place un service de VoD, par exemple.
[^] # Re: FTP
Posté par Larry Cow . Évalué à 1.
Non?
[^] # Re: FTP
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 1.
J'adore faire des proz -k=10 ftp://ftp.example.com/pub/data/grosfichier.tgz et télécharger en 10 morceaux d'un coup à une vitesse d'enfer…
[^] # Re: FTP
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: FTP
Posté par Zenitram (site web personnel) . Évalué à 3.
Les windowsiens ont une myriade de logiciels appelés "Download managers" pour gérer même avec des sources multiples (le même fichier sur 10 URL en HTTP différentes, et hop c'est parti). Très pratique au début de l'ADSL lorsque le débit du client était plus gros que le débit du serveur. Ton proz -k=10 fait petit joueur à côté.
Un player Youtube (par exemple) peut faire un seek dans une vidéo qui n'a pas fini de télécharger, tu penses qu'il peut faire comment?
Bref, oui, ça peut, c'est utilisé depuis plus de 10 ans par des centaines de logiciels. HTTP est très fort, et il ne reste pas grand chose à FTP (listing de répertoires, upload... Et encore, on peut uploader en HTTP aussi) qui se traine de grosses casseroles (2 connexions dont parfois une dans l'autre sens que l'initialisation etc...)
[^] # Re: FTP
Posté par zebra3 . Évalué à 4.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: FTP
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Je ne connaissais pas, mais je vais m'y mettre tout de suite, et proposer cette solution autour de moi (on verra s'il y a des inconvénients. La compatibilité avec les liens HTML usuels me parait très bien vue quand même !)
# 20 pages seconde
Posté par yellowiscool . Évalué à 4.
Sinon, bon boulot. Ça fait plaisir de voir quelqu'un autant coder :-)
Envoyé depuis mon lapin.
# Beau...
Posté par eMerzh (site web personnel) . Évalué à 3.
Je suis vraiment intéressé d'avoir un pointeur vers l'info sur Qt et Kio / GVFS...
J'espère que ça arrivera bientôt... avec ça il se pourrait bien que Qt devienne LA plateforme unissant un peu les environnements de développement et offrant une meilleur intégration pour tous...
[^] # Re: Beau...
Posté par suJeSelS . Évalué à -1.
[^] # Re: Beau...
Posté par briaeros007 . Évalué à 2.
Prérequis serveur oracle
installer un serveur X
installer gnome.
...
[^] # Re: Beau...
Posté par georgeswwbush . Évalué à 0.
[^] # Re: Beau...
Posté par Zenitram (site web personnel) . Évalué à 2.
Question de point de vue : en:DRY
[^] # Re: Beau...
Posté par mota (site web personnel) . Évalué à -2.
[^] # Re: Beau...
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: Beau...
Posté par mota (site web personnel) . Évalué à -10.
Donc on peut jouer sur la definition, il n'empeche que cette illustration du concepte DRY (d'ailleurs qu'on retrouve plutot du cote de gtk/gnome) montre bien une incapacite a faire du bas niveau, et a se servir d'outils raisonnables.
Donc quand on ne sait pas coder, on ne se lance pas dans des applications aussi proches du systeme.
[^] # Re: Beau...
Posté par totof2000 . Évalué à 6.
Il fait ce qu'il veut, rien ne t'oblige à utiliser son code .... Bien que je sois d'accord sur le fait que QT n'est pas vraiment adapté à un logiciel d'aussi bas niveau, ce n'est pas une raison pour etre aussi agressif. Le temps qu'il aura passé à coder n'est pas perdu, et rien ne l'epêche de reprendre les parties bas niveau plus tard pour s'affranchir de QT. Et pour reprendre une expression célèbre "qui ne tente rien n'a rien", et "ce sont ceux qui ne font rien qui ne commettent jamais d'erreur". Je préfère des gens comme lui qui essaient des choses, même avec des maladresses que des gens (comme toi ? ) qui ne font rien et qui se permettent de critiquer à tout va.
[^] # Re: Beau...
Posté par mota (site web personnel) . Évalué à -6.
Non.
Je prefere des gens qui comme moi utilisent des outils adaptes pour des projets au diapason de leurs connaissances.
Un mec qui te pond au debote le nouveau gestionnaire de paquet ultra trop hype tendance avec son nouveau site kikoo over trop bien pour sa distrib/os/DE trop revolutionnaire, et qui ne manque pas d'epithete glorifiant a leurs sujets, c'est legerement irritant.
Quand en plus par derriere c'est fait facon branquignole, avec aucune conscience de la realite des choses, en effet, un peu d'agressivite fait office de coup de pied au cul.
Mais bon "vaut mieux (re)faire les choses", meme si ca ne comble aucun vide ni ne fait la roue plus ronde (si ce n'est plus cagneuse, mais on va dire que j'agresse), au moins on a appris a mal faire.
[^] # Re: Beau...
Posté par totof2000 . Évalué à 3.
Il n'a pas appris à mal faire, il a appris à faire en faisant des conneries. Après soit il les corrige, et son truc peut être utilisable, soit il les corrige pas et son truc ne servira jamais. Et même si son truc ne sera utilisé par personne l'expérience qu'il aura acquise lui permettra certainement de faire mieux sur autre chose.
[^] # Re: Beau...
Posté par briaeros007 . Évalué à 3.
Si oui, je fais TOUT LE TEMPS des conneries. Ben oui, je code pas en asm, j'utilise les libs qui me convienne, et j'ose faire des scripts plutot que de retaper des enchainement de commandes tout le temps identique.
[^] # Re: Beau...
Posté par dguihal . Évalué à 10.
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
[^] # Re: Beau...
Posté par CrEv (site web personnel) . Évalué à 9.
$ rpm -qa | grep -i libqt
libqtgui4-4.5.2-0.10mdv2009.1
libqtopengl4-4.5.2-0.10mdv2009.1
libqthelp4-4.5.2-0.10mdv2009.1
libqtconcurrent1-1.2.1-0.1mdv2009.1
libqtdesigner4-4.5.2-0.10mdv2009.1
libqtxml4-4.5.2-0.10mdv2009.1
libqttest4-4.5.2-0.10mdv2009.1
libqtclucene4-4.5.2-0.10mdv2009.1
libqtwebkit4-4.5.2-0.10mdv2009.1
libqtxmlpatterns4-4.5.2-0.10mdv2009.1
libqtcore4-4.5.2-0.10mdv2009.1
libqtsql4-4.5.2-0.10mdv2009.1
libqtscripttools4-4.5.2-0.10mdv2009.1
libqt4-devel-4.5.2-0.10mdv2009.1
libqtscript4-4.5.2-0.10mdv2009.1
libqtdbus4-4.5.2-0.10mdv2009.1
libqtnetwork4-4.5.2-0.10mdv2009.1
libqtsvg4-4.5.2-0.10mdv2009.1
Maintenant, il est possible d'écrire un programme utilisant genre libqtcore et libqtnetwork et tu n'aura aucune dépendance vers X
Et si tu as des dépendances vers X c'est que tu as de mauvais packages...
[^] # Re: Beau...
Posté par Zenitram (site web personnel) . Évalué à 5.
Quand on ne connait pas, on évite de parler : QtCore (le seul module utilisé) ne dépend jamais de X.
# Torrent
Posté par Frédéric Bertolus (site web personnel) . Évalué à 8.
[^] # Re: Torrent
Posté par zerkman (site web personnel) . Évalué à 2.
Modifier, même légèrement un dépôt à la Debian Sid nécessite de regénérer le fichier torrent dans son intégralité. Partager des fichiers entre utilisateurs de deux versions différentes du même torrent est à mon avis impossible.
Peut-être faudrait-il en plus un système pour mettre à jour très régulièrement le fichier, car un torrent généré sur un dépôt style Debian Sid risque d'être un peu gros (quelques dizaines, voire centaines de mégaoctets !), vu le nombre de fichiers.
Cela dit pour les distributions statiques type Debian Stable, c'est relativement envisageable, même s'il reste le problème des mises à jour de sécurité à régler.
[^] # Re: Torrent
Posté par Frédéric Bertolus (site web personnel) . Évalué à 2.
[^] # Re: Torrent
Posté par zerkman (site web personnel) . Évalué à 2.
En plus avec la libtorrent écrite en C bien propre et qui dépote quand même pas mal, je ne pense pas que télécharger un millier de paquets en même temps poserait de problème. A vérifier cependant, et si cela pose quand même un problème il reste encore la solution d'utiliser un pipeline limitant le nombre de paquets téléchargés simultanément.
Par contre, pour que cela soit efficace il faut quand même que les paquets soient « seedés » par suffisamment de monde. Et une fois un paquet téléchargé il faudrait quand même laisser le torrent tourner quelque temps histoire de contribuer à la distribution. Et là, je ne vois pas de solution miracle si à chaque paquet il y a un torrent différent. A moins d'avoir un démon séparé du process d'installation qui s'occupe de gérer cela correctement. Et autre chose, pour partager les paquets il faut évidemment que ces paquets restent sur le disque, donc impossible de les nettoyer pour gagner de la place à la apt-get clean, sauf si les paquets sont obsolètes ou ont été uploadés suffisamment.
[^] # Re: Torrent
Posté par Spyhawk . Évalué à 1.
[^] # Re: Torrent
Posté par Anonyme . Évalué à 1.
# 33 (et plus) commentaires à côté de la plaque !
Posté par Axel . Évalué à 9.
# Raison de l'utilisation de Qt
Posté par steckdenis (site web personnel) . Évalué à 10.
Un joli troll de haut niveau a été lancé sur ce journal, pour fêter le vendredi comme il se doit (faut dire que c'est inévitable avec un journal posté le jeudi soir).
Tout d'abord, ne vous en prenez pas à mes connaissances, ce n'est pas "parce que je ne sais rien faire d'autre" que j'ai utilisé Qt. Simplement, je suis le seul codeur, et j'aime le code lisible. Prenez un gestionnaire de paquets pas trop complexe, genre la libalpm (utilisé par Pacman, le gestionnaire de paquets de Arch Linux), et regardez.
Il y a pas mal de code dedans, dont un qui gère le protocole HTTP, un le HTTP, un les différents types de compression, un un système de queue, etc. Au final, quand on veut résoudre un bug sans connaître le code, on prend plus de temps à trouver le fichier et la fonction incriminée qu'à corriger le code.
Qt permet de factoriser le code, et est un avantage technologique. Déjà il permet de ne pas tout recoder (on a la gestion du réseau dedans, la gestion des fichiers de configuration, la gestion du XML, etc). Ensuite, les signaux et les slots peuvent être utiles (par exemple dans la gestion des téléchargements en parallèle, un téléchargement fini déclanchant l'installation de son paquet), et certains modules, comme QtScript, sont un simple bonus.
Logram n'est absolument pas une distribution à vocation serveur. Sur un serveur, installez une Debian, une Red Hat, ou tout autre. Logram, c'est du bureau, du vrais (donc pas un truc comme Ubuntu qui se dit "desktop" parce que ça fait bien, mais qui fournit également une version serveur "parce que ça fait bien aussi").
D'ailleurs, dans le monde du desktop, nous avons Mandriva, qui utilise la suite URPM ... codé en Perl. Ça alors, un langage de script, qui nécessite tout Perl. Même pas une lib, non non, tout un langage. Il faut vraiment leur dire que ça pue, que c'est pas bien, que le C99 juste au dessus de la LibC c'est mieux, non ?
Et bien non. Si l'utilisation d'une bibliothèque de haut niveau permet de sortir un programme de qualité, ou du moins qui a la possibilité de devenir de qualité, on en profite. Rien ne dépend de X, Qt s'installe en quelques secondes, ça occupe 10Mio de disque dur, quelques Mio de RAM, donc c'est rien. Profitons que nous avons un OS correctement conçu qui permet d'installer des bibliothèques sans encrasser une base de registre et ralentir le tout (on est vendredi).
Sinon, je veux bien qu'on fork Setup. Vous allez simplement passer 6 mois à corriger les bugs dans votre implémentation de ce que Qt fournit, comme par exemple les tables de Hash, très utilisées, les listes, les threads, les signaux, la synchronisation, etc.
Ou alors, vous allez utiliser trente six mille bibliothèques, à la manière des applications C générales, pour avoir la même chose. Ce sera plein de dépendances, mais personne ne va s'en plaindre.
Désolé pour le post un peu long, dure journée.
[^] # Re: Raison de l'utilisation de Qt
Posté par Anonyme . Évalué à 3.
J'suis un Qt fan-boy moi aussi, je peux plus m'en passer. On peut faire un code relativement souple, beau, et léger à la fois sans se prendre la tête 35ans sur un vieux bug alakon.
[^] # Re: Raison de l'utilisation de Qt
Posté par Ludo . Évalué à 2.
A noter que portage, l'outil utilisé chez Gentoo pour gérer les logiciels, est codé en python à ma connaissance.
[^] # Re: Raison de l'utilisation de Qt
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
> une Debian,
Le problème est que sur un parc important, je veux avoir la même distribution sur les serveurs et sur les postes de travail pour gagner du temps.
Donc, il me faudrait une Logram dérivée de debian au minimum ;-)
# Outil de travail collaboratif
Posté par Ludo . Évalué à 1.
Il est codé en Ruby on Rails et possède pas mal de plugins intéressants.
Bravo en tout cas pour toutes tes contributions.
[^] # Re: Outil de travail collaboratif
Posté par steckdenis (site web personnel) . Évalué à 2.
* Le forum est vraiment inutilisable, même pas moyen de voir facilement les messages lus et non-lus
* Il est très difficile à intégrer à un autre site (j'utilisais Drupal pour les nouvelles et pour son forum)
* Le reste est bien pensé mais un peu trop "sérieux"
Néanmoins, c'est un outil d'une très grande qualité bourré de fonctionnalités très intéressantes, comme les Milestones, les Grantt, les statistiques sur le SVN, etc. Je tiens à féliciter son auteur.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.