Journal Azureus

Posté par  .
Étiquettes :
0
16
jan.
2008
Azureus est un client bittorrent libre (GPL).
Mais jusqu'à maintenant sous Linux il fallait utiliser la vm "pas encore tout à fait libre" de Sun pour utliser Azureus.
Bonne nouvelle, c'est n'est plus le cas. L'excellentissime Fedora 8 a eu une mise à jour d'Azureus (3.0.3.4) et qui marche bien avec IcedTea. Ce n'est pas parfait, mais ça marche. Le plus gros problème est qu'Azureus est principalement conçu pour les polices par défauts de Windows. Donc il faut ajuster la largeur des colonnes, et c'est réglé.
J'ai déjà dit plus d'une fois qu'Azureus était disponible sur Fedora (avant avec gcj) mais ça n'a jamais été réellement exploitable. Ça a mis du temps, mais ça l'est aujourd'hui.

J'image qu'il y a des pisses vinaigre qui vont dire : Azureus ... java ... trop gros ... etc.

Oublions les. Ce qu'il faut "retenir" est que maintenant l'un des clients bittorrent les plus populaire marche sous Linux et avec une vm 100 % libre.

En passant, quasiment toutes les prochaines distributions auront IcedTea (et donc très très probablement Azureus).

  • # old news is so exciting !

    Posté par  (site web personnel) . Évalué à 10.

    rien de révolutionnaire... azureus fonctionne déjà depuis un bout de temps avec du 100% libre.

    azureus est dans le 'main' de debian depuis novembre 2006 car buildable/utilisable avec gcj/gij

    </pisse_vinaigre>

    • [^] # Re: old news is so exciting !

      Posté par  . Évalué à 1.

      > azureus est dans le 'main' de debian depuis novembre 2006 car buildable/utilisable avec gcj/gij

      Il est dans Fedora depuis la même époque voire plus (FC6). Mais il n'a jamais marché chez moi correctement.
      "Buildable" c'est sûr. Mais qu'entends-tu par "utilisable" ?
      Tu l'utilises depuis novembre 2006 ?
      Je l'utilise seulement depuis quelques heures....

    • [^] # Re: old news is so exciting !

      Posté par  . Évalué à 2.

      > azureus est dans le 'main' de debian depuis novembre 2006 car buildable/utilisable avec gcj/gij

      T'appelles ça utilisable :
      Date: Sat, 3 Nov 2007 14:16:19 -0600
      http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=449176
      Même problème sous Fedora avec gcj (FC6/F7).
      Pour moi ce n'est pas utilisable.

      Notes que le mainteneur ne semble pas espérer corriger ce problème avec gcj :
      As a workaround, you can use Sun's VM instead of the GNU VM. With the Sun VM being open-sourced, hopefully it will be available in Debian soon.

      • [^] # Re: old news is so exciting !

        Posté par  . Évalué à 1.

        De toutes façons même avec la VM de Sun Azureus n'a jamais été vraiment utilisable, des que y'a trop de fichiers dans un torrent il pète totalement les plombs !

        • [^] # Re: old news is so exciting !

          Posté par  . Évalué à -1.

          N'importe quoi.

          • [^] # Re: old news is so exciting !

            Posté par  . Évalué à 2.

            Bah ta jamais eu le message d'erreur "au secours trop de descripteurs de fichiers ouvert, java ne peut pas gérer tout ça" (interprétation libre) avec Azureus ? Suivie de l'arrêt (erreur) de tout les torrents.

            Ça arrive aussi quand on as beaucoup de torrent ouverts.

            • [^] # Re: old news is so exciting !

              Posté par  . Évalué à 0.

              > Bah ta jamais eu le message d'erreur

              Non.

              > "au secours trop de descripteurs de fichiers ouvert, java ne peut pas gérer tout ça"

              En passant, c'est probablement lié à une limite de Linux (le noyau).
              Il n'y a que depuis le 2.6 que le nombre de descripteur ouvert est généreux par défaut sous Linux.

              Je serais curieux de savoir avec quoi tu as eu ce problème.
              Linux 2.4 ?

              Si c'est un problème Linux, ce n'est pas un problème java.

              • [^] # Re: old news is so exciting !

                Posté par  . Évalué à 2.

                Non Linux-2.6
                Et les clients bittorrent en C,C++ et autres s'en sortes très biens.
                J'ai cherché un moyen de contourner ça dans les nombreuses options d'Azureus mais je n'ai rien trouvé.

                Je vote soit pour une limitation de java, soit pour un problème de conceptions d'Azureus qui ouvre effectivement plus de DF que Linux ne peut en gérer, faudrais voir comment les autres clients BT gèrent ça.

                • [^] # Re: old news is so exciting !

                  Posté par  . Évalué à 1.

                  Pas de problème ici.
                  Pour info :
                  - kernel-2.6.23.9-85.fc8
                  - java-1.7.0-icedtea-1.7.0.0-0.19.b21.snapshot.fc8
                  - azureus-3.0.3.4-2.fc8

                  Ce qui est fournit pour F8.

                  Pour mon Azureus qui tourne (depuis 1 jours et 1 heure) :
                  $ lsof -p 10302 | wc -l
                  348

                  Pas énorme (notons que ça inclus les connexions réseaux).

                • [^] # Re: old news is so exciting !

                  Posté par  . Évalué à 1.

                  azureus -> nombre maximum de fichier ouverts par défaut.
                  Ou alors modifier son fichier /etc/security/limits.conf ;)

                  • [^] # Re: old news is so exciting !

                    Posté par  . Évalué à 2.

                    Y'avais déjà cette option de configuration à l'époque mais ça ne marchait pas, quand à limit je doute que Azureus apprécie de se voir limiter, au final le résultat risque d'être le même (erreur -> echec)

                    Bon c'était p-e un bug je re- essaierai (va falloir que je trouve un gros torrent plein de fichiers), mais à l'époque ça m'a pas mal gêné. Je devais servir de miroir pour assurer la disponibilité de plusieurs gros torrents et je me suis bien fait chier avec Azureus quelques-jours avant de passer a autre-chose.

  • # Azureus ... java ... trop gros ... etc

    Posté par  . Évalué à 10.

    Alors que rtorrent est tellement efficace.
    C'est vrai quoi, quel est l'interet d'une GUI pour du torrent ?

    • [^] # Re: Azureus ... java ... trop gros ... etc

      Posté par  . Évalué à 10.

      Ca sert à bloquer pendant des heures à regarder les temps d'estimation, le pourcentage, la quantité de données envoyées/reçues, le débit up/down... évoluer ?

      • [^] # Re: Azureus ... java ... trop gros ... etc

        Posté par  (site web personnel) . Évalué à 7.

        Pourquoi "évoluer" ? Parce que la CLI ça fait old-school et que la GUI ça roxxxx et c'est super hype/moderne/trop lol/.... ?


        rTorrent est toujours développé donc il évolue aussi... Moi je trouve que c'est super de pouvoir lancer ce soft dans un "screen" et de le laisser touner tout seul dans son coin... Et ne pas avoir besoin de Xorg, JAVA et tout le merdier pour au final, quoi ? Télécharger des fichiers ! Ben c'est bien©.

        • [^] # Re: Azureus ... java ... trop gros ... etc

          Posté par  (site web personnel) . Évalué à 3.

          Tu n'as pas compris : il dit qu'il peut regarder sur un graphique les données (débits & co) évoluer, pas que Azureus est évolué.

        • [^] # Re: Azureus ... java ... trop gros ... etc

          Posté par  . Évalué à 2.

          Je suis entièrement d'accord, et un des avantages de rTorrent est qu'il tourne sur du matériel peu gourmand. Personnellement, j'utilise rTorrent sur un en:NSLU2, et ça permet de laisser tourner le téléchargement sans avoir besoin d'avoir l'ordinateur allumé, ce qui représente un très gros avantage face à Azureus.

          OK, l'interface en curses n'est certes pas folichonne, mais tout ce que je demande à un client bittorrent, c'est de télécharger, et d'afficher quelques données (débits, pourcentage téléchargé ...). De plus, rTorrent permet de surveiller un dossier, et de lancer automatiquement le téléchargement de tous les torrents qui s'y trouvent, ce qui fait qu'on n'est même pas obligé de passer par l'interface.

        • [^] # Re: Azureus ... java ... trop gros ... etc

          Posté par  . Évalué à 2.

          Relis bien ma phrase.
          Le verbe "évoluer" s'applique aux graphes que l'on voit évoluer dans le temps et non à Azureus (que je ne considère pas plus ou moins évolué que rTorrent vu que je ne l'ai jamais testé)...

      • [^] # Re: Azureus ... java ... trop gros ... etc

        Posté par  (site web personnel) . Évalué à 4.

        Ca m'étonnerait qu'il n'y ait pas ça dans rtorrent.
        Qui dit IHM en mode texte ne dit pas austérité fonctionnelle.

    • [^] # Re: Azureus ... java ... trop gros ... etc

      Posté par  (site web personnel) . Évalué à 2.

      Ce que j'apprécie dans Azureus c'est sa bdd distribuée et la possibilité de coder des extensions.
      Par exemple ici, nous sommes sur un VPN et nous avons codé un plugin qui permet de détecter les autres clients azureus sur le réseau et nous pouvons nous échanger des fichiers avec des torrents décentralisés.
      Pareil, quand un tracker est à plat, grâce à la base de donnée distribuée, le téléchargement peut continuer.

      Je ne connais pas assez rtorrent par contre, je ne sais pas ce dont il est capable... Mais voila pourquoi j'utilise azureus.

  • # Pas besoin d'attendre les prochaines distributions

    Posté par  (site web personnel) . Évalué à 2.

    Je l'ai testé sous archlinux donc version (3.0.1.6) avec icedtea 1.4 ça fonctionnait déjà parfaitement.

    D'ailleurs je tiens a ne pas remercier les contributeurs icedtea d'avoir modifier le configure icedtea pour récupérer les sources openjdk via mercurial et un plugin de celui-ci (forest) uniquement disponible via mercurial lui-même, pas terrible pour l'automatisation d'un builder (tinderbox). avant openjdk était rapatrier depuis une archive sur le web c'était quand même mieux.

    Sinon je tiens quand même à les remerciers énormément car à part un patch pour virer le -Werror, ça build tout seul :)

  • # Avantage et inconvénient ?

    Posté par  (site web personnel) . Évalué à 2.

    Je me suis mis à Torrent ce week-end en découvrant le logiciel Transmission
    http://www.transmissionbt.com/

    Qu'apporte de plus Azureus par rapport à Transmission pour le téléchargement d'oeuvres ou de logiciel sous licence libre ?

    Il m'a semblé que Transmission avait juste ce qu'il fallait, ni plus, ni moins pour effectuer sa tache correctement.

    • [^] # Re: Avantage et inconvénient ?

      Posté par  . Évalué à 1.

      L'"idée" n'est pas de rentrer dans le jeux de qui a la plus gros ou la mieux carrosée, mais seulement d'indiquer qu'un logiciel populaire (populaire n'est pas un synonyme de "plus mieux bien") était disponible en 100 % libre (Azureus marche avec IcedTea).

    • [^] # Re: Avantage et inconvénient ?

      Posté par  . Évalué à 10.

      Je ne connais pas bien transmission, mais il est vraisemblable qu'Azureus soit à Transmission ce qu'Emacs est à Nano.
      Bref, si tu veux faire le café en téléchargeant, utilise Azureus.

      (Cela dit, ktorrent a quasiment toutes les fonctionnalités d'Azureus et bouffe beaucoup moins de ressources sous KDE... enfin voilà... )

      • [^] # Re: Avantage et inconvénient ?

        Posté par  (site web personnel) . Évalué à 2.

        justement... j'allais demander pourquoi personne ne parlait de Ktorrent... c'est à 98% aussi utilisable qu'azureus (pour ce que j'en fais) 400% moins lourd. et je peux le laisser tourner sur mon portable pendant 5 jours sans avoir peur qu'un freeze ait bloqué ma machine toute la nuit... du bonheur quoi :)

        • [^] # Re: Avantage et inconvénient ?

          Posté par  . Évalué à 2.

          J'ai utilisé transmision sur fedora 8. C'est très simple, ergonomique mais il n'est pas compatible avec certains tracker privée. Azureus est très bien sous windows quoique beaucoup lui préfère utorrent. Personnelement j'utilise le fabuleux ktorrent compatible avec tout les tracker privés tout fois il lui manque l'érgonomie et la simplcité de transmission.

        • [^] # Re: Avantage et inconvénient ?

          Posté par  . Évalué à 1.

          Je suis pas certain que ktorrent soit moins lourd qu'Azureus. Pour avoir testé ktorrent j'ai remarqué qu'il consommait certes moins de mémoire mais également nettement plus de ressources CPU. Et quand j'ai comparé, Azureus avait deux fois plus de torrent en téléchargement que ktorrent. Donc attention aux a priori.

          Sinon il parait que kget va inclure une gestion des torrent. C'est peut-être même déjà dispo sous KDE4.0 (mais en fait j'en sais rien).

          • [^] # Re: Avantage et inconvénient ?

            Posté par  . Évalué à 1.

            moi j'ai eu l'appréciation inverse : moins de cpu, mais a peu près autant de mémoire (un peu moins il est vrai).XD

          • [^] # Re: Avantage et inconvénient ?

            Posté par  . Évalué à 2.

            "Sinon il parait que kget va inclure une gestion des torrent. C'est peut-être même déjà dispo sous KDE4.0 (mais en fait j'en sais rien)."
            En effet, c'est prévu[1] : "Continued work on the BitTorrent plugin for KGet."

            Par contre, je sais pas à quel point il gèrera le tout (trackers privés ?)...



            1 http://dot.kde.org/1197522021/

    • [^] # Re: Avantage et inconvénient ?

      Posté par  . Évalué à 2.

      Transmission pas mal, mais il ne respecte pas le port qu'on lui attribue dans la configuration oO, du coup je suis passé à Déluge qui est aussi très bien et reste très simple, malgrès quelques options de plus que Transmission.

      Maintenant je suis repassé sous KDE donc j'utilise Ktorrent qui est du même niveau que Deluge.

      • [^] # Re: Avantage et inconvénient ?

        Posté par  (site web personnel) . Évalué à 2.

        Je sais pas trop ce que tu appelles « configuration oO », mais dans les toutes dernières version de Transmission (1.01), le port reste bien le même pendant toute l'utilisation...

        • [^] # Re: Avantage et inconvénient ?

          Posté par  . Évalué à 2.

          Bah c'est configuration suivie du smiley oO, parce que quand tu configure le client sur le port 28881 et que quand tu regarde du coté du tracker il utilise le port 5xxxx qui est évidemment fermé...

          Bon en effet c'était la version 0.7, la version finale n'a peut-être plus ce bug, mais l'interface c'est pas mal alourdie d'après les screenshots que j'ai vu :/

    • [^] # Re: Avantage et inconvénient ?

      Posté par  (site web personnel) . Évalué à 2.

      Azureus présente des possibilités de configuration avancées assez hallucinantes. Et il utilise aussi une base de données distribuées grâce à laquelle tu peux continuer à télécharger même si le tracker ne répond plus. Je crois que ce sont les dév d'Azureus eux-mêmes qui ont codé cette extension au protocole BitTorrent, et que donc ça ne peut marcher qu'entre utilisateurs d'Azureus.

      Sinon, j'ai moi aussi découvert Transmission il y a peu, et depuis j'utilise plus que lui ! Simple, léger, facile à compiler et à configurer, bonne intégration dans Gnome, activement maintenu : que du bonheur !

      • [^] # Re: Avantage et inconvénient ?

        Posté par  (site web personnel) . Évalué à 1.

        Pour être plus précis, Azureus utilise une version modifiée de Kademlia pour sa DHT (Distributed Hash Table).
        Ce n'est pas un truc totalement obscure quoi... (http://www.azureuswiki.com/index.php/DistributedTrackerAndDa(...)

      • [^] # Re: Avantage et inconvénient ?

        Posté par  . Évalué à 2.

        Je crois que ce sont les dév d'Azureus eux-mêmes qui ont codé cette extension au protocole BitTorrent, et que donc ça ne peut marcher qu'entre utilisateurs d'Azureus.

        Ca fait longtemps que bittorrent a une version officielle de ce procédé et qui est intéropérable avec une grande quantité de clients, tandis qu'Azureus tiens absolument à rester enfermés dans leurs propre excréments.

        http://en.wikipedia.org/wiki/BitTorrent_(protocol)

        Alternatively, in a trackerless system (decentralized tracking) every peer acts as a tracker. This is implemented by the BitTorrent, µTorrent, BitComet, KTorrent and Deluge clients through the distributed hash table (DHT) method. Azureus also supports a trackerless method that is incompatible (as of April 2007) with the DHT offered by all other supporting clients.

    • [^] # Re: Avantage et inconvénient ?

      Posté par  . Évalué à 0.

      En passant, il y a aussi le très bon client Deluge.
      Dans mon ordre de préférence (je n'ai pas testé transmission) :
      - Azureus
      - Deluge
      - Ktorrrent

  • # L'excellentissime Fedora 8

    Posté par  . Évalué à 3.

    > L'excellentissime Fedora 8

    Question que je me pose depuis pas mal de temps : tu bosses pour RedHat ou une société partenaire ?

    Ne prends pas cette question comme une critique, ce n'en est pas une. Je me suis longtemps posé la même question au sujet du regrett^W Sam_from_ms.

    • [^] # Re: L'excellentissime Fedora 8

      Posté par  . Évalué à 1.

      > Question que je me pose depuis pas mal de temps : tu bosses pour RedHat ou une société partenaire ?

      Je ne bosses pas pour Red Hat, je ne fais pas parti d'une société partenaire, etc...

      J'ai écrit ici et ailleurs "excellentissime Fedora" pour qu'on me "foute la paix" et éviter les "ne l'écoutez pas, il est pro-Fedora/Red Hat et gnagnagni et gnagnagna". Je préfère dire de suis que je suis pro-Fedora/Red Hat avec ce que cela implique de subjectif/affectif.
      C'est mal d'être "passionné" ?

      • [^] # Re: L'excellentissime Fedora 8

        Posté par  (site web personnel) . Évalué à 4.

        "J'ai écrit ici et ailleurs "excellentissime Fedora" pour qu'on me "foute la paix" et éviter les "ne l'écoutez pas, il est pro-Fedora/Red Hat et gnagnagni et gnagnagna".
        => Ça ressemble à un vieux troll à chaque fois que tu parles de Fedora, c'est un peu lassant à force... Enfin ce n'est que mon point de vue.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.