> пользоваться чем-то ещё. Я сам им пользуюсь на домашней файлопомойке. Хотя
> и не могу сказать, что он бережно относится к ресурсам,

Было бы кстати любопытно сравнить на серьезных объемах торрентов с остальными. Есть идеи как это вменяемо сделать при том что swarm по определению штука динамичная, роялит предыстория и прочая, etc, etc?

> но всё же, конечно, заметно меньше KTorrent. :)

Вот мне и не понятно чем он лучше. Интерфейс конечно подробен, но в отместку весьма разлапист и поэтому повседневные операции в нем делаются геморройно. Это пожалуй единственный потенциальный плюс, только даже для того чтобы лог узреть - уже надо тааакой бубен достать... надо пойти в настройки, загрузить плагин, и только тогда можно будет вообще понять что и нафига клиент сейчас делает и нет ли у него проблем. DHT работает как-то странновато, очень медленно набирая пиров при начальном старте. Да и сам TCP-клиент к дохлым пирам зачем-то долбится как дятел постоянно. Я почему-то думал что на дохлых пиров надо забивать после 3-5 попыток. Но кторент долбится к ним перманентно, часто, много и нахально. Зачем? Я не знаю. Наверное чтобы чаще и больше делать заведомо бесполезные соединения на радость натам. Или типа того.

В свое время меня все это достало и я свалил на трансмиссию. Она просто работает, все потребные в типовых случаях элементы управления на виду, а при желании и подробности/логи всяко есть.

> И за документацию попинать можно изрядно — ошибки и во встроенной
> справке, и в страницах руководства встречаются.

Это про трансмишна? Ну если найдете - напишите им баг, они исправят. На сайте вроде вполне адекватно описано и правится часто. Я их отпинал по недостающим моментам на которые наткнулся - исправили.

>> силу обшего движка - они везде одинаковые. И да, иногда нужно
>> нечто нестандартное.
> Вы сами себе противоречите. :))

Нет, я просто хочу чтобы в крейсерском режиме все было просто и понятно. А продвинутые рукоятки - это уже "in the case of emergency"/при необходимости.

> Не говоря о том, что действительно хороший софт имеет минимум рукояток,
> для всего остального имея вменяемую сообразиловку.

Да, хорошо когда дефолты удачны и лишний раз соваться никуда не надо. Проблемы начинаются тогда когда сообразиловка начинает делать не то что надо вам, а то что надо ей :). И оказывается что есть параметры для которых один размер на всех - не катит. Типовой пример: буфера диска. Торент-клиент лучше оси знает что он будет читать/писать сейчас и через несколько секунд. Потому что он и принимает решения о том какие блоки он будет качать и слать. Тут то и оказывается: чем больше буфер, тем лучше живется (механическим) дискам. Но оказывается что есть В. Пупкин с крутым серваком с гигами рамы, а есть роутеры где оперативы 32Мб на все про все и трансмиссия не единственная программа там. И один размер на всех не катит. Т.к. или юзер сервака остается недоволен недоюзежом оперативы для кеширования и переюзежом винча, или юзер роутера офигевает когда у него память в девайсе резко кончается :). Аналогично - например число соединений и скорость с которой их можно устанавливать. У кого-то дохлый роутер за 30 баксов одуревающий если делать 200 соединений в минуту. Ну поработает час и переполняется таблица трекинга у нат, ибо китайцы напаяли минимум оперативы, зато таймаут отслеживания зато ввинтили на полдня, не меньше. И вот уже пачка юзеров с этим крапом идет и хочет вас съесть. А вот програмерам это совсем не надо. Можно сильно урезать соединения. Но тогда недовольны будут уже бравые парни с мощным каналом. У которых "это дерьмо работает тормознее, чем %s". И опять получается что один размер всех не устроит никогда, и даже заавтодетектить это толком нельзя. Потому что хрен бы его там знает что у юзера за сеть и из какого оборудования и что оно потянет а что нет.

> Правда, это требует заметно большего планирования при создании ПО, чем это обычно бывает.

Попробуйте для начала просто предложить алгоритм лимитирования числа соединений, который бы был как быстр на быстрых каналах (для этого надо много соединений и надо их делать быстро, ессно) но не выносил бы мозг говнороутерам (а вот они от большого числа соединений одуревают на раз). При том что внятного метода понять сколько конекций потянет тот или иной конфиг у юзера - нет. Прикольно, да? И вот так там и тут :). У юзеров разные конфигурации. И свойства у них разные. Что хорошо одним, жопа для других. Например, SSD мало смысла подпирать огромными буферами, у него seek time и так нулевой. А вот оператива на буфер сожрется. И  главное юзерской апликухе вот так сходу не особо очевидно, на SSD оно качает или на механику. Однозначного метода это узнать вообще нет в природе :)

> Вы не поверите, но как раз KTorrent это умеет. ;)

Верю, даже видел, только вот мне это оказалось столь же полезно как зайцу стопсигнал: на серверах в датацентрах где обычно такие проблемы с взлетом DHT - почему-то ... внезапно нет KDE и X-ов :). И не то чтобы они там нужны. Все-таки отделение core от GUI позволяет поиметь ряд удобностей недоступных иными методами. Мне такой подход по вкусу - гибкость маневрирования выше.

> А вообще пройдитесь (вы и не только вы) сюда: http://en.wikipedia.org
> /wiki/Comparison_of_BitTorrent_clients

Я там давно был, но там очень устаревшие данные, описаны не все тонкие моменты и вообще ряд клиентов не описан/подробное описание стерто. Видимо, саботеры-делетеры вытерли как "недосточно значимые" половину. Уродство: придя в энциклопедию я в итоге не могу описальник на половину участников сравнения посмотреть.

> ;) Конечно, для многих клиентов с тех пор кое-что изменилось, но,
> поверьте, отнюдь не в сторону ухудшения. :)

Верю. Я их опробовал целую кучу. Клиенты на основе libtorrent например - на любителя: очень задрюченая либа с массой зависимостей. Собирать ее геморно, а в большинстве систем она достаточно стара для того чтобы не уметь искаропки uTorrent'овский вариант передачи метаданных, что ставит крест на магнет-ссылках. А руками качать торент-файлы когда это можно свалить прямо на сам протокол, отдав ему лишь хэш раздачи - прощлый век. Магнет-линку можно закопипастить и скажем в аську/ирц/жаббер кинуть. А вот файл - дольше, медленнее, неудобнее и "как повезет".

>> или порсто для локальных экспериментов или что там еще?
> В обоих обсуждаемых — да.

См. выше. Я на такую ситуацию налетел в датацентре, если что. Видал я там кде на сервере, аж 2 раза.

> Оу. Ну вы, батенька, и зажрались. :)))))))

А что - зажрадись? Ситуации бывают разные :)

> Да пользуйтесь, хоспади, что ж вы на ровном месте наезды видите, и
> тем их только в итоге и провоцируете?! Давайте жить дружно. ;)

Я не вижу наездов, я просто аргументирую почему мне в итоге понравилась данная софтина. Она не лучшая. У нее есть недочеты. Но она делает что мне надо, не греет мозг при типовом юзеже, но позволяет выруливать в случае проблем и позволяет покрутить достаточно рукояток в случае если это становится зачем-то реально надо. Мне так вполне удобно :)