Bittorent client

[Asterisk]

Кажете някой хубав клиент за линукс

[mialy]

Ползвал съм и съм доволен от ktorrent (http://ktorrent.org/) :)

[viktory]

За мен най-добър си остава BitTornado :)

[prestige]

А за мен rtorrent.

[Shaft]

Едно време ползвах доста, едно много леко, ама конзолно - ctorrent (http://ctorrent.sourceforge.net/), после преминах на ktorrent...

[tux-bg]

Аз ползвам Azureus, комуникира добре с Firefox и досега не ми е правил проблеми.

[angel_che]

http://www.transmissionbt.com/

[pavi2mac]

Още 1 глас за KTorrent. Стига да ползва дистро с КДЕ.Иначе за Гном - Deluge

[fly]

Transmission на Linux и Mac OS X ;)

[Metalqga]

http://qbittorrent.sourceforge.net/

[zomane]

Аз също ползвам rtorrent и съм много доволен.rtorrent+screen поне за мен е перфектната комбинация.

[icaci]

Transmission, въпреки леко по-грозната Linux версия :ghi:

[Pesho®]

Под GNOME - Transmission или Deluge, въпрос на избор. Първият е изчистен и приятен за употреба, вторият е мощен дзвер с всички необходими настройки.

Под KDE - Това qBittorrent изглежда интересно, благодаря за линка. От KTorrent съм разочарован - поне допреди няколко месеца се държеше изключително некултурно, когато дисковото пространство е малко.

Под конзола - rTorrent и screen. Само когато се наложи, иначе предпочитам графичните.

[kernel_daemon]

Мерси за това Deluge. Как така съм го изпуснал чак се чудя. Нещо много ми напомня на uTorrent :). Мисля да го пробвам. Иначе до сега карах на Азуреус и KTorrent.

[solar_sea]

rtorrent, най-малкото заради удобството да го командвам отдалечено през ssh и screen.

[Skydive]

Аз пробвах Azureus, върши ми работа и дори не съм проверявал другите торент клиенти какво могат.

[tolostoi]

rtorrent дълго време, вече се ориентирах към deluge (около половин година с него си карам). Не зная дали не звучи тъпо, но един и същ торент пускам да се сваля с transmission имам да речем скорост 500 К, спирам го пускам deluge тегли с 630 К, спирам пак пускам трансмишън и пак е с по-ниска скорост - 500 К т. е същата. Не помня на трансмишън дали беше включено криптирането, на deluge по-подразбиране си е включено (не ми мина през акъла да погленда на рутера дали не лъже някоя програма :rolleyes: ) Кторент ползвам ако съм с КДЕ. Бях пуснал тракер в локалната мрежа и тествах скорости. С кторрент сиидвам с 1 до 2 мегабайта. Пускам rtorrent почти 9 мегабайта сиийд. Тук е възможно понеже машинката беше слаба 1.2 дурон с 512 рам и да не му е стигало на кторента, но ми беше достатъчно за да спра да го ползвам. Deluge си има приятен web интерфейс, само, дето на някой тракери като пейстнеш линка и не тегли торента, което се получаваше и като ползвах rtorrent и трябва пак да се логнеш да го изтеглиш, че да го пуснеш да се сваля :D

[spirtbrat]

Transmission не поддържа DHT. Може би затова не можеш да вдигнеш голяма скорост. То си зависи и от торента де - колко сийдъри има, колко лийчъри, дали те са от БГ (ако това е от значение за скоростта ти) и т.н. В някои случаи DHT помага да си намериш повече сийдъри.
KTorrent не поддържа Super-Seeding, за разлика от rTorrent. Както можеш да се досетиш, това подпомага общата скорост на качване.
За по-подробна информация ->тук (http://en.wikipedia.org/wiki/Comparison_of_BitTorrent_software).

[AK-85]

Под KDE - Това qBittorrent изглежда интересно...
"qBittorrent" не изисква "KDE", само "Qt" (а аз не ги приравнявам).

Аз съм доволен от "KTorrent", а "Azureus" също е добър, само че има един сериозен недостатък - написан е на "Java". И двата имат всички екстри от "µTorrent", които ми трябват; последният ми е еталон и, между другото, държи се нормално с "Wine", но предпочитам native приложения.

При последната инсталация на операционната система търсих клиент, който да е написан на "C/C++" (евентуално може и друг език, който се компилира до машинен код), да има графичен потребителски интерфейс, да не зависи от "KDE" или "GNOME", а само от "XCB" или някой widget toolkit (в краен случай от "Xfce") и да има някакво разумно количество функции. "qBittorrent" беше единствената програма, която отговаряше на условията ("Qt" щеше да ме откаже, но ми трябва за "Skype" така или иначе). Все още има доста дразнещи дреболии по интерфейса (няма сортиране по приоритет на файловете в даден торент, например; нерядко ми се случва да свалям само определени файлове, при това след време в друга сесия още части, но не и цялата информация), но иначе става, затова го използвам в момента.

[Pesho®]

"qBittorrent" не изисква "KDE", само "Qt" (а аз не ги приравнявам).


Това защо го написа? Нито съм твърдял че изисква KDE, нито пък приравнявам Qt с KDE.

[exabyte]

"Azureus" също е добър, само че има един сериозен недостатък - написан е на "Java"
И това е лошо, защото? :) Като фен на Java, ми е любопитно…

[AK-85]

Това защо го написа?
А ти защо написа "Под KDE"? Аз също не съм твърдял, че си твърдял, че изисква "KDE", нито че приравняваш "Qt" с "KDE".

И това е лошо, защото?
Защото при еднакво качествен код с еквивалентна функционалност приложението, написано на "Java", е обречено да използва повече системни ресурси от отговарящото на изискванията ми. Специално "Azureus" многократно е получавал критики, че е ужасно тежък.

[exabyte]

Да, безумно тежък е, и още по-тромав. Не смятам, че вината за това е в Java. Използвани библиотеки, зле написан код… Повечето използвани ресурси се състоят най-вече в повече използвана памет, използваното процесорно време може и да е по-малко.

[Pesho®]

А ти защо написа "Под KDE"?


Защото предпочитам приложения, които използват native toolkit-а на средата, под която работя. Поне по две причини:

1. Native look&feel. В конкретния случай (Qt4 приложение под GNOME) това скоро няма да е проблем, благодарение на QGtkStyle (http://labs.trolltech.com/page/Projects/Styles/GtkStyle).

2. Памет. Ако няма основателна причина, препочитам Qt библиотеките да не се зареждат под GNOME, съответно Gtk под KDE.

[AK-85]

Аз писах, защото някой незапознат (с програмата и принципите ти) може да направи грешен извод. Нямам изисквания за native look, а аргументът за паметта не важи при мен заради "Skype".

Не смятам, че вината за това е в Java.
Нито пък аз. За сметка на това смятам, че "Java" има значителен принос. "µTorrent" е със сравнима функционалност, а контрастът е явен. Не вярвам, че има особена разлика в качеството на кода, което не ми оставя много възможни обяснения. Освен това обърни внимание на първото изречение от предишното ми обяснение.

[prestige]

Да, безумно тежък е, и още по-тромав. Не смятам, че вината за това е в Java. Използвани библиотеки, зле написан код…


Според мен пък точно Java-та е основната причина за тромавостта на Azureus и кое да е Java приложение. Разбирам Azureus да е единственото влачещо се Java приложение на Земята, за да отдадеш причината за това на използваните библиотеките и зле написания код, ама то не е така. Лафа, че "Java върви навсякъде... еднакво бавно" (та дори и на Solaris) не е измислен случайно. Не пиша на Java, но имам допирни точки с нея и съм запознат, колкото да си върша работата. Би ли ми обяснил?
Извинявам се, че измествам темата.

[exabyte]

звинявам се, че измествам темата.

Дизайна на Java позволява много бързи имплементации. Когато бъде компилирана до native код, забавянето спрямо приложение писано на C няма да е значително, а ако правиш по-сложни неща е възможно и Java приложението да работи по-бързо. Това, което ми прави впечатление е, че подобни приложения писани на езици с динамично типизиране, като Python и Perl, вървят много бързо, а ако не става ясно, Java приложенията би трябвало да работят още по-бързо.

Съвременните имплементации на Sun включват множество оптимизации, включително преобразуване на байткода в native код, както и динамично оптимизиране на кода по време на изпълнение, които би трябвало да го правят достатъчно бърз, в множество случаи и по-бърз от код писан на C, който не е бил профилиран.

Определено не бих търсил проблема в езика, нито в имплементацията му. Смятам, че проблема е в използваните библиотеки — комбинацията SWT/GTK+ не ми звучи особено печелившо. Друг вероятен виновник е зле написания код. Имайки предвид, какво чудовище е новата версия на Azureus, почвам да изразявам съмнения във възможностите на авторите му да оптимизират, каквото и да било.

[AK-85]

Съвременните имплементации на Sun включват множество оптимизации, включително преобразуване на байткода в native код, както и динамично оптимизиране на кода по време на изпълнение, които би трябвало да го правят достатъчно бърз, в множество случаи и по-бърз от код писан на C, който не е бил профилиран.
На теория е така, на практика се получава друго (http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=gcc&lang2=java). Обърни внимание, че използваният компилатор далеч не е най-бързият (тази чест е запазена за "ICC" с оглед на платформата, на която са изпълнявани тестовете), съответно картинката е по-розова за "Java", отколкото е реално. Друг практически пример е "Crusoe" на "Transmeta", където се прилагат същите техники, само че виртуалната машина беше хардуерна, съответно не изразходваше ресурси. Скоростта отново не беше впечатляваща (дори и с основополагащата VLIW архитектура), за сметка на други постижения, разбира се.

Освен това подозирам, че имплементацията на "C" не е максимално оптимизирана (между другото, нереалистично е да очакваш, че сериозно приложение, написано на "C/C++", няма да е профилирано), а ако се стигне до героични оптимизации (някои от които дори не са компримиси с принципите на софтуерното инженерство), положението може значително да загрубее.

[exabyte]

На теория е така, на практика се получава друго (http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=gcc&lang2=java).
Напрактика това, което виждам на страницата потвърждава това, което съм имал предвид с написаното. Но определено изглежда да греша за „множеството“. Това, което ме изумява е, е Perl вариантите използват по-малко памет от Java вариантите, това ми обърква представите. :D

[Nuclear]

Аз си ползвам Transmission - тегля торента, save as, едно прозорче с 2-3 бутона, което при нужда се скрива горе в лентата. Не ми трябва нещо тежко, гълтащо памет, с множество статистики за торент, който (вече) се сваля за максимум един час и заемащо целия екран.

[anrieff]

Аз ползвам само rtorrent, за целите ми е напълно достатъчен, а комбинацията от screen + ssh достъп е незаменима. Случи ми се веднъж да изсмуче 1 гигабайт памет, чак до момента, в който се задейства тайнствения OOM Killer :) Малко странно, не знам другите клиенти как се държат при такъв зверски товар, какъвто бях изсипал тогава :D

[MinuTeMan]

Ползвам Deluge 0.5.9.3, но все още не съм се престрашил да пробвам новата версия (1.0). Някакви отзиви за нея има ли, държи ли се стабилно, критични бъгове има ли?