Какой самый лучший клиент для Linux

Никак. Все актуальные фс имеют ограничение на длину названия файла в 255 байт.
https://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits

Можно использовать NTFS (ntfs-3g), у которого ограничение - 255 юникодных символов. Использовать можно либо на отдельном разделе, либо в файле через loopback device (man losetup, man mount).
Только я бы не стал все раздачи переносить на NTFS - она в Линухе трмознутая, из за того, что FUSE. Переносите на NTFS только проблемные раздачи.
В принципе, ещё должно быть можно перейти на однобайтовую кодировку, используя локаль ru_RU.CP1251. Тогда русские буквы в именах будут занимать по одному байту и любое NTFS'ное имя, содержащее только символы, представимые в CP1251, должно будет поместиться в 255 байт. Но я не знаю как это настроить.

Начиная с 5.15 есть новый драйвер в ядре. Черевато огромным количеством проблем с системой, так как в линуксе UTF-8 стандарт де факто и весь софт пишется с расчетом на нее.

---

Вообще все это ненужные пляски, проще в клиенте файл переименовать и все. Не знаю как с этим дела в Transmission, но в qBittorrent точно можно.
Сейчас даже проверил: qBittorrent автоматом просто обрезает название файла и все работает, со стороны пользователя даже ничего не требуется делать.

А что у этого ядреного модуля с длиной имен файлов?
До сих пор, у всех "родных" файловых систем в mainline Linux было ограничение в 255 байтов.
NTFS-3g - дело другое, у FUSE ограничение всегда было больше (2K, кажется). Какие могут быть проблемы с RPi, используемой как seed-box? Думаю, что никаких, ибо там русского языка вообще нигде быть не должно, кроме как в именах файлов.

Все нормально, работает аналогично винде. Фактически ограничение именно в 255 символов, разница только в кодировке.
Родные линуксовые фс для хранения имен используют UTF-8, где символ это 1 байт, соответственно и длина получается 255 байт, а буквы кириллицы просто занимают 2 символа.
NTFS же использует UTF-16, где каждый символ это 2 байта, то есть имена занимают вдвое больше места (2х255 байт), но зато кириллица тут влезает в 1 символ. Трудно сказать, тут не попробуешь - не узнаешь.

В Линуксе ограничение на длину имени файла в байтах. Каждая файловая система сообщает ядру (подсистеме VFS) имена какой максимальной длины, в байтах, она поддерживает. Вообще, имя файла в Линухе - это произвольная последовательность произвольных байтов (кроме двух "запрещённых" значений: ноль 0x00, и косая черта 0x2F). Никаких "символов", с точки зрения ядра (VFS), в именах файлов нет, никаких кодировок тоже нет: в ядре только байты. Вся возня с кодировками - это user space. Авторы Unicode с вами категорически не согласны. В UTF-8 один символ может занимать до 4 байт.

Не вижу противоречия. У NTFS получается 2х255 в байтах, как уже было сказано. И это прекрасно видно в коде. Да ну? А я вот прямо в коде драйвера вижу возню с кодировками. Никакого юзерспейса здесь быть не может, когда данные фс физически хранятся на диске в UTF-16. Под символом я имел в виду 1 codepoint = 1 байт. "Буквы кириллицы занимают 2 символа" - имелось в виду 2 кодпоинта. И вообще UTF-8 аж до 6 кодпоинтов (= 6 байт) может содержать.
В UTF-16 при этом 1 codepoint = 2 байта. И до 2 кодпоинтов (4 байта) в общем.

Спасибо за ссылку на код! Очень любопытно.
Ссылка, правда, на неинтересное место (макрос MAX_BYTES_PER_NAME_ENTRY нигде не используется), но правильное место содержит ту же константу NTFS_NAME_LEN, равную 255.
Остаётся вопрос: как число 255 соотносятся с длиной имени UTF-8, которые в user-space? Если коротко, то никак.Такое чувство, что "новое поколение" разработчиков пришло с какими-то новыми идеями и сломало функции statvfs/pathconf. Эти функции нужны, например, чтобы я в программе на C/C++ знал, какого размера нужно выделить буфер, когда перебираю файлы в директории. С этой точки зрения, число 255 для NTFS - неправильное. Более разумная реализация в vfat: там возвращают 1530 (255*6, по "старому" UTF-8). Получается, что для выделения памяти statvfs/pathconf больше не пригодны, жаль.
Самое главное: какой вообще практический смысл может быть в выдаче 255 для NTFS, учитывая, что априори никто не знает, на какой файловой системе находится каталог?! Я не смог придумать... Это возня с представлением данных на диске. Я же говорил про "собственно ядро" (VFS) и POSIX/Linux API, где чистые байты. Внутри реализации FS может быть что угодно: любые ограничения или перекодировки. Например, VFAT не позволяет создавать файлы с двоеточием в имени. А если когда-нибудь напишут драйвер FS для RT-11/RSX-11/VAX-VMS, то там будут превращать буквы в кодировку RADIX-50. Это личное дело каждой файловой системы. Что не отменяет того, что все API как в ядре (VFS), так и между ядром и user space (POSIX) используют байты и знать не знают о кодировке. Спорить об определениях не интересно, но чтобы понимать друг друга приходится договариваться о терминах. Байт в UTF-8 называется "code unit". А codepoint - это и есть символ, кодирующийся в UTF-8 несколькими "code units", т.е несколькими байтами. Всё это хорошо описано в википедии или в RFC3629. Интересно, что с 2003 года (RFC3629) в UTF-8 один codepoint может содержать не более 4 code units, а не 6, как было раньше (в устаревшем стандарте ISO/IEC 10646): с 2003 года в UTF-8 можно закодировать только то, что помещается в UTF-16 (upd: до 2003 года в UTF-8 можно было закодировать codepoints не представимые в UTF-16).

asacha, в общем все это конечно очень интересно обсуждать, но для данной темы оффтоп
Здесь важен лишь итог, что новый драйвер NTFS в ядре успешно реализует ее виндовое поведение и указанные названия файлов вмещает целиком, я даже специально проверил.
Но опять же имхо проще использовать клиент, который решает эту проблему тупо переименованием файла.

Да, согласен. Возможно, с появлением ядерного драйвера NTFS, можно будет использовать NTFS для хранения раздач, но пока - страшновато. Новый код не бывает без глюков... Да, конечно. Жаль только, что я таких клиентов не встречал. qBittorrent-nox на RPi-4 (Ubuntu 20.04) у меня сдох уже на 1500 раздачах. Он не только начал безбожно тормозить в UI, но и практически перестал раздавать. Возможно, не раздавал он из-за того, что я не сумел подобрать подходящие параметры (готовые пресеты не подошли: оно либо не раздавало, либо ему не хватало для работы памяти). Пришлось вернуться на убогий Transmission, который запросто потянул >5500 раздач, но, вместо переименования файлов, помечает раздачу как ошибочную и прекращает скачивать.

На самом деле может быть очень полезно под раздачи использовать фс с контролем целостности данных, там Btrfs или ZFS. Об ошибках диска узнаешь сразу, не нужно гадать о целостности и перехешировать раздачи в поисках ошибок. Ext4 и NTFS в этом плане сильно отстают.

1. Vuze устарел, но умеет в I2P и TOR и не умеет разговаривать с bt*.
   
2. Transmission из под земли достаёт пиров, но, к сожалению, из-за отсутствия настроек прокси, скорость оставляет желать лучшего.
   
3. qBittorrent... совсем не понимаю как он работает, но пиров как-будто не видит. Удобен для использования с отдельными интерфейсами (напр. Lokinet или Yggdrasil).
   
4. Deluge более свободный в настройках и удобный по сравнению с Transmission, но работает нестабильно с пирами и информации по ним не предоставляет. Нет возможности разделения протоколов прокси из-за чего он DHT пускает по прокси или интерфейсу, что не всегда требуется и приводит к прекращению работы DHT.
   
5. Tixati, хоть и с закрытым кодом, но работает изрядно хорошо и гибко с предоставлением дополнительных удобств по типу каналов, в которых можно пускать медиа поток для желающих (радио, стрим). Но главное это гибкая настройка прокси по протоколам и отдельно для трекеров и пиров. Предоставляет информацию по работе DHT.

Наверное тот который стоит по умолчанию в вашем дистрибутиве.

Владельцы арчей и прочих минимальных дистров вышли из чата.

qBitTorrent

На машинах с маленьким количеством памяти (1-2GB) он совсем плохо работает, увы. Можно сказать, вообще не раздаёт.
А ещё, я не нашел для него хорошего remote GUI клиента.

Эмм, мягко скажем неправда. Родной WebUI вроде вполне сносный, почти полностью покрывает функционал десктопного клиента. Но тут конечно на вкус и цвет.

Можете поделиться файлом с настройками qBittorrent для 2GB RAM?
Я несколько месяцев мучил qBittorent-nox на RaspberryPi-4 с 2GB RAM и 1500 раздачами. На минимальных настройках он почти ничего не раздавал, а при попытке что-то увеличить, уходил в своп и вообще переставал работать. Возможно, есть "золотая середина", но я её не нащупал. После перехода на Transmission 3.0 эти раздачи стали нормально раздаваться (не слишком быстро, но Transmission вообще тормознутый, что делать). Я уже забыл, - это тот, который на Питоне написан?
Помню, что был очень функциональный GUI, но у меня он невыносимо тормозил. Пришлось отказаться, потому что ждать по 5-10 секунд окончания любого действия - это выше моих сил.

Тут нечем делиться особо. Сам по себе клиент потребляет смешное количество памяти (зависит от количества раздач конечно).
Реально память занимать может только дисковый кэш, что соответственно решается его отключением. Если у вас версия с libtorrent 1.x, то достаточно значение "Disk cache" установить на 0. Если с libtorrent 2.x, то параметр "Disk IO type" сменить с "Memory mapped files" на "POSIX-compliant". Это тот, который в браузере открывается.

Всем привет. Я не фанат какого либо дистрибутива или клиента. Итак понадобилось мне скачать для одного парня файл. У меня Arch GNU/Linux. Для мелких раздач и скачиваний всегда пользовался Transmission, а тут крупный "торрент" - размер 48 Гигабайт и качать нужно сразу на флешку. В общем сначала конечно скормил файл Transmisson-gtk и указал, что качать, а главное куда. Всё нормально начал качать и внезапно выяснилось, что каким то невероятным образом качает он не только в целевую папку(флешку), но и на жёсткий диск в папку загрузки(возможно после перезагрузки решил продолжить закачку в другое место, хотя флешка была на месте). Ну Ок. Устанавливаю Deluge - он вобще не запускается, ему требуется настройка вроде как я понял. Ок. Устанавливаю Ktorrent. Отличный клиент по интерфейсу, спасибо что нет "закоса" под какой нибудь "тач скрин" интерфейс и gtk4(gtk5-10-25)(личное оценочное мнение), а нормальный человеческий интерфейс, где не нужно выполнять 10 кликов для того, что бы добраться до какой нибудь опции. Но тут возникла проблема в другом, (скачав гигабайт 20 раздачи - 50% примерно)заметил он не цепляет всех личей и всех сидов. На CMS трекера показывает 11 сидов(изначально было двое) и 3 лича(изначально был я один вроде), а у меня в клиенте в колонке сиды пишет 2(2) в колонке личи 0(1). Кроме того, несмотря на то, что я "залогинен" на Rutracker-е у меня в профиле перестало отображать, что я раздаю и что качаю. Я так понимаю Ktorrent не корректно(для трекера) обменивается информацией с трекером(если вобще это делает).
Внимание знатоки!(Играет музыка из программы: "Что? Где? Когда?") Вопрос: Какой клиент под GNU/Linux лучше и не будет "спариваться(на букву е) с" мозгом?

На десктопе использую qBittorrent. Проблемы бывали только одного вида: иногда сходил с ума, когда кончалось место на диске. Приходилось перезапускать. Вроде, в последних версиях с этим лучше (давно не попадал в такую ситуацию)

В тонкости клиентов я, увы, сейчас не вникаю, но в свое время отлично и круглосуточно у меня работал rtorrent с фронтом. Сейчас просто какой-то transmission в дебиановом дистрибутиве, но в нем мне неудобен интерфейс.

К Transmission есть очень приличный front-end под названием Transmission Remote GUI

Он давно протух и не собирается в актуальных дистрибутивах, из живых похожих gui tremotesf, transmission-remote-gtk .

Почему Вы так решили? Последний коммит в github'е был сделан вчера. Релизов, правда, нет с 2019 года. Не понимаю, о чём вы? Ubuntu 23.04 (Lunar Lobster) - вроде, актуальный сегодня.
Я только что собрал и релиз 5.18.0, и свежий master из git'а в Ubunut 23.04, всё собралось и запустилось.
Единственная засада: в Readme, приложенном к релизу, отсутствует нужная команда lazarus - нужно пользоваться инструкцией с первой страницы проекта в git'е.
Бинарный релиз у меня под Lunar Lobster, действительно, не запустился, но собрать из исходников заняло меньше 10 минут, включая установку fp-compiler и lazarus. Спасибо!
Надо будет посмотреть. (Если судить по страничке проекта на github'е, то tremotesf выглядит более серьёзным.)

Толку от этих коммитов с исправлением ссылок и текстов мало, разработка и поддержка остановилась. По Федоре сужу, 7 лет прошло как что то поломалось

Он работает и очень удобен. Что ещё нужно? (Обидно, конечно, что разработка остановилась - если она не возобновится, то рано или поздно возникнут проблемы, но пока всё нормально.) Проблемы с федорой не имеют отношения к "остановке разработки и поддержки". Семь лет назад transgui активно разрабатывался и был однозначно лучше всех конкурентов. Видимо, в федоре им вообще не пользуются, потому никто и не заметил, что он перестал там собираться.

Transmission к 4 версии по функционалу (announce-ip, torrent-added-verify-mode) стал пригоден для пользования, пытаюсь перейти на него с rTorrent, но есть некоторые слегка и очень останавливающие переход моменты: не усредненные мгновенные скорости, отсутствие привычной информации отдано/принято для каждого пира, вопросы по работе с трекерами, более 2-мя трекерами в одном tier'е странное поведение. Процессор, по сравнению с rTorrent в одних условиях, жрет в разы больше!
Я не ищу причины почему нет, очень старался, даже адаптировал под себя максимально похожие вебморды ))

Однозначно на данный момент qBittorent лучший !!!
Ос Debian 11.6, qbittorrent-nox/stable 4.2.5-0.1 amd64, рулю через веб морду.
IPv4 и IPv6, 350-400 соединений максимум.
Никаких вопросов за месяц не возникло !
До этого 12 лет на Deluge 'раздавал'....
И ещё в качестве net.ipv4.tcp_congestion_control BBR , a net.core.default_qdisc выставил FQ.
Ко кому интересно пробуйте:
# nano /etc/sysctl.conf
И в конце прописываем...
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
Затем командуем
# sysctl --system
Считаеться net.core.default_qdisc = fq для серверов, а fq_codel для нагруженных роутеров
https://habr.com/ru/articles/322430/
Напишите изменилась ли у вас up\down в лучшую сторону ?

Оригинальную веб морду? она несколько неудобна на текущий момент по фильтрации/группировке трекеров и сразу видимых ошибок по ним. Из альтернативных ничего для себя подходящего не нашел (qb-web красивая, но не то) думаю делать свою он основе оригинальной, но огорчают скудные возможности web api по трекерам