Journal Deux petites chose pour vous occuper jusqu'à demain

Posté par (page perso) .
Tags : aucun
18
12
nov.
2009
Bonjour,

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 (page perso) . Évalué à 3.

    le FTP est géré

    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 (page perso) . Évalué à -2.

      Je te retourne la question : quelle est l'avantage du HTTP par rapport au FTP ?

      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 (page perso) . Évalué à 8.

        Je te retourne la question : quelle est l'avantage du HTTP par rapport au FTP ?

        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 . Évalué à 4.

          Parce que ça fera 4012 lignes.
        • [^] # Re: FTP

          Posté par . Évalué à 3.

          En quoi son nom précise qu'il rend le transfert de fichier simple ?
          • [^] # Re: FTP

            Posté par . Évalué à 7.

            FTP c'est pas Fimple Transfert Profocol ?
        • [^] # Re: FTP

          Posté par (page perso) . Évalué à 4.

          Setup utilise QNetworkAccessManager, et gère HTTP et FTP, bien entendu.
          • [^] # Re: FTP

            Posté par (page perso) . Évalué à 1.

            Je crois que je me suis mal fait comprendre : je demandais pourquoi il voulait que Setup ne gère pas HTTP alors que ça ne lui coûte rien de le supporter. C'est tout l'avantage d'avoir choisit QtNetwork (bon, même si pour juste le besoin de réseau, libcurl aurait suffit, mais quitte à utiliser QtCore pour le reste, QtNetwork était évident)
    • [^] # Re: FTP

      Posté par . Évalué à 1.

      comme cela a froid, l'interet est comme son nom l'indique : File transfer protocole

      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 (page perso) . Évalué à 4.

        Bon, pour résumer, ce que je voulais dire, ce n'est pas que FTP n'a pas d'intérêt en tant que tel. Seulement qu'il a des inconvénients que HTTP n'a pas, et qu'il n'apporte rien d'utile que HTTP ne fasse pas déjà.

        Bref, qu'aujourd'hui, on n'a pas besoin de FTP, sauf si on tient à se fabriquer des ennuis.
        • [^] # Re: FTP

          Posté par . Évalué à 3.

          disons que ftp est utile quand on doit envoyer des documents, car là on peut choisir les != reprtoires, les droits toussa.
          Mais pour récupérer un document c'est clair que http est bien plus adapté que ftp.
          • [^] # Re: FTP

            Posté par (page perso) . Évalué à 2.

            FTP est utile quand on doit envoyer des documents et qu'on se moque de la sécurité de son mot de passe qui est envoyé en clair. Encore une fois, il n'a que des inconvénients face à SFTP, cette fois-ci.
            • [^] # Re: FTP

              Posté par (page perso) . Évalué à 2.

              D'une façon générale, FTP est absolument inutile. Dans la plupart des situations où on l'utilise, il est remplaçable par HTTP (pour récupérer des documents) et SFTP (pour en envoyer).

              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 . Évalué à 1.

              ah sftp est très bien et remplace très avantageusement ftp.
              Mais là on parlait de ftp vs http, pas de ftp vs sftp.
              • [^] # Re: FTP

                Posté par (page perso) . Évalué à 2.

                Bon, je récapitule ma position :
                - 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 . Évalué à 3.

                  - 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.
                  • [^] # Re: FTP

                    Posté par (page perso) . Évalué à 1.

                    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. Ça tombe bien, lftp sait faire du HTTP. 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) Forcément : il n'y a aucune sécurité. Aujourd'hui, je pense que la sécurité est plus importante que le temps processeur et la bande passante, qu'on a à revendre. 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. s/FTP/HTTP/
                    • [^] # Re: FTP

                      Posté par . Évalué à 3.

                      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
                  • [^] # Re: FTP

                    Posté par . É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.

                    Ç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 . Évalué à 2.

                      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 .....
                      • [^] # Re: FTP

                        Posté par (page perso) . Évalué à 3.

                        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.

                        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 . Évalué à 2.

                          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
                          • [^] # Re: FTP

                            Posté par (page perso) . Évalué à 3.

                            C'est certainement pas par hasard

                            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 . Évalué à 2.

                              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
                            • [^] # Re: FTP

                              Posté par (page perso) . Évalué à 2.

                              FTP est bien pour l'upload, quand on se moque de la sécurité. Sinon, il y a SFTP, qui lui est bien sous tous rapports.
                              • [^] # Re: FTP

                                Posté par (page perso) . Évalué à 1.

                                Quand vous parlez de SFTP vous parlez bien de FTP par SSH non ?
                                • [^] # Re: FTP

                                  Posté par (page perso) . Évalué à 2.

                                  Non, de SSH File Transfer Protocol. Le seul lien avec FTP, c'est le nom qui ressemble, mais ça n'utilise pas FTP, c'est un protocole lié à SSH.
                                  • [^] # Re: FTP

                                    Posté par (page perso) . Évalué à 1.

                                    Je m'étais compris >__<

                                    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 (page perso) . Évalué à 4.

                                      Il y a aussi le FTPS ou le FTP sur SSL, a ne pas confondre avec le SFTP (module dans SSH).

                                      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 (page perso) . Évalué à 3.

                        Tu es au courant que lftp prend en charge HTTP ?
                        • [^] # Re: FTP

                          Posté par . Évalué à 2.

                          Non mais ça ne change rien au fait qu'HTTP n'apporte rien par rapport a son surcout BP/CPU dans ce cas
                          • [^] # Re: FTP

                            Posté par (page perso) . Évalué à 2.

                            HTTP n'apporte rien par rapport a son surcout BP/CPU dans ce cas

                            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 . Évalué à 3.

                              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.
                              • [^] # Re: FTP

                                Posté par (page perso) . Évalué à 2.

                                J'avais essayé il y a quelques années de faire un serveur HTTP/DAV avec apache et c'était d'une lenteur insupportable. Bref, intenable en production sur des gros fichiers.

                                Quelqu'un utilise le WebDav sur un vrai serveur de fichier, avec une utilisation normale ?
                                • [^] # Re: FTP

                                  Posté par . Évalué à 1.

                                  Effectivement mod_dav est d'une lenteur incompréhensible. Mais c'est purement dut à l'implémentation. Mais avec une implémentation serveur et client correcte c'est tout à fait utilisable.
                                  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 (page perso) . Évalué à 2.

                    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.

                    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 . Évalué à 2.

                      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é.
                      • [^] # Re: FTP

                        Posté par (page perso) . Évalué à 3.

                        Y'a pas de header dans ftp, une fois la connexion ouverte,

                        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 . Évalué à 2.

                          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
                          • [^] # Re: FTP

                            Posté par (page perso) . Évalué à 2.

                            DAV.
                            • [^] # Re: FTP

                              Posté par . Évalué à 2.

                              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.
                              • [^] # Re: FTP

                                Posté par (page perso) . Évalué à 3.

                                je n'ai pas encore vu de miroirs webdav

                                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 (page perso) . Évalué à 3.

                                FTP permet de faire du transfert de fichier de manière simple,

                                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 . Évalué à 2.

                                  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.
                                  • [^] # Re: FTP

                                    Posté par (page perso) . Évalué à 3.

                                    Le mode PASV, il marche, parce que ton routeur NAT a des hacks pour que ça passe. Avec un NAT tout simple, rien à faire, ça ne passe pas.

                                    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 . Évalué à 2.

                                      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
                                      • [^] # Re: FTP

                                        Posté par (page perso) . Évalué à 2.

                                        Le protocole est ultra simple

                                        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 . Évalué à 3.

                                          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).
          • [^] # Re: FTP

            Posté par (page perso) . Évalué à 2.

            Il y a l'extension DAV pour envoyer des fichiers par HTTP.

            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 (page perso) . Évalué à 2.

              DAV, c'est potentiellement très bien, sauf qu'Apache ne permet pas de fournir un service par utilisateurs comme OpenSSH…
              • [^] # Re: FTP

                Posté par (page perso) . Évalué à 2.

                J'utilise un serveur Trac/Subversion accessible par HTTPS, l'accès SVN en écriture passe par DAV avec une gestion d'utilisateurs par fichier .htaccess .
                • [^] # Re: FTP

                  Posté par (page perso) . Évalué à 2.

                  Oui, mais c'est très loin derrière ce que fait OpenSSH, avec de vrais droits sur le système de fichiers.
                  • [^] # Re: FTP

                    Posté par (page perso) . Évalué à 2.

                    DAV, c'est bien mais le peu que je l'ai utilisé, ce n'est pas imaginable de transférer 10000 fichiers et 600Go de fichier avec.
            • [^] # Re: FTP

              Posté par . Évalué à 2.

              (que FTP ne permet pas, les mots de passe et les données transférées étant en clair).
              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 . Évalué à 3.

              A bon ?

              Et le File_Transfer_Protocol_over_SSL (ou FTPS) et le Secure_FTP c'est pour les axel ?
              • [^] # Re: FTP

                Posté par (page perso) . Évalué à 2.

                Secure FTP c'est une usine à gaz par-dessus SSH alors qu'il a lui-même son protocole de transfert de fichiers, SFTP.
                • [^] # Re: FTP

                  Posté par . Évalué à 2.

                  Il a quand même le mérite d'exister
        • [^] # Re: FTP

          Posté par . Évalué à 5.

          Et le reget ? Je ne savais pas que HTTP permettait de recommencer un transfert là ou il s'était interrompu.

          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 (page perso) . Évalué à 3.

            HTTP permet de commencer un téléchargement à la position que l'on veut. Donc de reprendre un chargement.

            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 . Évalué à 4.

              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.
              • [^] # Re: FTP

                Posté par . Évalué à 8.

                Si tu es réellement très curieux, tu lis la spécification HTTP/1.1 pour trouver ta réponse, comme toutes les Personnes Très Curieuses. Sinon tu n'es pas très curieux, et en tant que Personne Très Curieuse, je me sens insulté par les mauvaises contrefaçons comme toi qui n'ont rien à voir avec la curiosité. Sinon sans surprise, la réponse à ta question se trouve en 12 secondes dans la spécification HTTP/1.1 comme le savent toutes les Personnes Très Curieuses qui se sont sortie les doigts du pull pour alimenter leur vraie curiosité :

                - http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14(...)

                Ceci est une vraie réponse.

                « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

                • [^] # Re: FTP

                  Posté par . Évalué à 0.

                  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
                  • [^] # Re: FTP

                    Posté par . Évalué à 6.

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

                    Je passe tout simplement le temps nécessaire à alimenter la faim gargantuesque de ma curiosité aussitôt qu'elle le réclame. Évidemment je ne dis pas que sur le long terme, ça n'ait pas fait de moi quelqu'un de génial doublé d'une efficacité redoutable. Mais c'est à mon insu et mon but initial n'a jamais été de devenir exceptionnellement compétent.

                    « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

              • [^] # Re: FTP

                Posté par (page perso) . Évalué à 2.

                wget --continue

                Ç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 . Évalué à 1.

              Si tu as une PKI X.509/SSL, c'est plus logique d'utiliser des services qui peuvent en tirer partie (type FTP over SSL ou FTP over TLS) que d'aller t'encombrer avec une PKI parallèle pour gérer tes clés SSH.

              Non?
    • [^] # Re: FTP

      Posté par (page perso) . Évalué à 1.

      On peut faire du resume sur du HTTP ?
      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 (page perso) . Évalué à 2.

        Oui, on peut demander le téléchargement d'un fichier à partir d'un décalage donné. Par exemple avec wget --continue.
      • [^] # Re: FTP

        Posté par (page perso) . Évalué à 3.

        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…

        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 . Évalué à 4.

          À ce sujet, il peut être intéressant de jeter un œil au format Metalink, qui permet ce que font les download managers sous Windows : il s'agit d'un fichier XML décrivant pour une liste de fichiers de multiples sources de téléchargement (par FTP, HTTP et même BitTorrent).

          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 (page perso) . Évalué à 2.

            Ho ! Ça c'est excellentissime !
            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 (page perso) . Évalué à 4.

    Quand je pense que c'est plusieurs milliers de pages par seconde avec une page statique, cela ne vaut pas le coup de générer des pages statiques (méthode utilisée par linuxfr) ?

    Sinon, bon boulot. Ça fait plaisir de voir quelqu'un autant coder :-)

    Envoyé depuis mon lapin.

  • # Beau...

    Posté par (page perso) . Évalué à 3.

    Beau boulot....

    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 . Évalué à -1.

      Mouai, avec Qt, il s'enferme un peu à un type de marché particulier pour son logiciel. Je me vois mal justifier d'installer cette bibliothèque sur un serveur. Donc si ce n'était déjà pas assez le bazar dans le monde des gestionnaire de paquets, là on en a une couche en plus.
      • [^] # Re: Beau...

        Posté par . Évalué à 2.

        Je me vois mal justifier d'installer cette bibliothèque sur un serveur.
        Prérequis serveur oracle
        installer un serveur X
        installer gnome.
        ...
      • [^] # Re: Beau...

        Posté par (page perso) . Évalué à 2.

        là on en a une couche en plus.

        Question de point de vue : en:DRY
        • [^] # Re: Beau...

          Posté par (page perso) . Évalué à -2.

          Suis-je le seul que ca choque de voir quelque chose d'aussi bas niveau (pour le systeme) qu'un gestionnaire de paquets dependre d'une bibliotheque graphique ?
          • [^] # Re: Beau...

            Posté par (page perso) . Évalué à 3.

            Qt n'est pas qu'un bibliothèque graphique.
            • [^] # Re: Beau...

              Posté par (page perso) . Évalué à -10.

              Ca n'en reste pas moins un gros bousin de framework, completement pas standard et qui la plupart du temps depend d'un enorme autre gros bousin nomme X.

              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 . Évalué à 6.

                Donc quand on ne sait pas coder, on ne se lance pas dans des applications aussi proches du systeme.
                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 (page perso) . Évalué à -6.

                  (comme toi ? )

                  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 . Évalué à 3.

                    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.
                    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 . Évalué à 3.

                      je suis pas sur que faire qqch en évitant de réinventer la roue une nieme fois c'est ce qu'on peut appeller 'faire des conneries'.

                      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 . Évalué à 10.

                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
              • [^] # Re: Beau...

                Posté par (page perso) . Évalué à 9.

                franchement je suis pas à le défendre, mais ton commentaire montre juste que tu n'as pas l'air de savoir à quoi ressemble Qt en fait...

                $ 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 (page perso) . Évalué à 5.

                et qui la plupart du temps depend d'un enorme autre gros bousin nomme X.

                Quand on ne connait pas, on évite de parler : QtCore (le seul module utilisé) ne dépend jamais de X.
  • # Torrent

    Posté par (page perso) . Évalué à 8.

    Puisque tu développes nouveau gestionnaire de paquet, tu ne pourrais pas en profiter pour y donner nativement la possibilité d'ajouter des dépôts torrents ?
    • [^] # Re: Torrent

      Posté par (page perso) . Évalué à 2.

      Très bonne idée, mais à mon avis cela risque de générer quelques problèmes:

      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 (page perso) . Évalué à 2.

        Je me trompe peut-être, mais je pensais à un fichier torrent par paquet. Tu ne régénères donc que les fichiers torrent des paquets que tu met à jour, et pas l'ensemble…
        • [^] # Re: Torrent

          Posté par (page perso) . Évalué à 2.

          En effet, cela serait beaucoup plus simple, j'ai honte de ne pas y avoir pensé ! :)

          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 . Évalué à 1.

      Je ne sais pas si d'autres gestionnaires le font (yum ?), mais c'est implémenté dans ZYpp, via aria2.
    • [^] # Re: Torrent

      Posté par (page perso) . Évalué à 1.

      Sur Arch on a 2 gars qui voulait faire des dépôts sur Gnutella (pour décentralisé au maximum). On a salué l'initiative mais on a tué l'idée dans l'œuf à cause de certains problèmes de gestion de version et toussa.
  • # 33 (et plus) commentaires à côté de la plaque !

    Posté par . Évalué à 9.

    Plutôt que de débattre de FTP vs HTTP sur un journal qui n'a absolument rien à voir avec ça, je vais juste dire bravo denis !
  • # Raison de l'utilisation de Qt

    Posté par (page perso) . Évalué à 10.

    Bonjour,

    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 (page perso) . Évalué à 3.

      +1

      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 (page perso) . Évalué à 2.

      +1

      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 (page perso) . Évalué à 3.

      > Logram n'est absolument pas une distribution à vocation serveur. Sur un serveur, installez
      > 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 (page perso) . Évalué à 1.

    Vu que tu aimes bien tester des logiciels et que ton outil de travail collaboratif ressemble d'un point de vue fonctionnel à un outil que j'utilise au quotidien, je ne sais pas si tu connais Redmine: http://www.redmine.org/
    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 (page perso) . Évalué à 2.

      J'ai utilisé Redmine pendant 10 mois, avant le site que j'ai codé. J'ai pu apprécier tout ce qu'il permet, ainsi que ses défauts, qui m'ont conduit à créer ce site :

      * 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 à ceux qui les ont postés. Nous n'en sommes pas responsables.