|
|
|
Hanabishi
Стаж: 14 лет 7 месяцев Сообщений: 2897
|
Hanabishi ·
21-Окт-22 17:29
(2 года назад, ред. 21-Окт-22 17:37)
electronus писал(а):
83790173Ребята, как решить по-хорошему лимит ext4 на длинные русские имена файлов?
Никак. Все актуальные фс имеют ограничение на длину названия файла в 255 байт.
https://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits
|
|
|
|
asacha
Стаж: 18 лет 5 месяцев Сообщений: 1990
|
asacha ·
27-Окт-22 21:32
(спустя 6 дней)
electronus писал(а):
83790173Ребята, как решить по-хорошему лимит ext4 на длинные русские имена файлов?
Можно использовать NTFS (ntfs-3g), у которого ограничение - 255 юникодных символов. Использовать можно либо на отдельном разделе, либо в файле через loopback device (man losetup, man mount).
Только я бы не стал все раздачи переносить на NTFS - она в Линухе трмознутая, из за того, что FUSE. Переносите на NTFS только проблемные раздачи.
В принципе, ещё должно быть можно перейти на однобайтовую кодировку, используя локаль ru_RU.CP1251. Тогда русские буквы в именах будут занимать по одному байту и любое NTFS'ное имя, содержащее только символы, представимые в CP1251, должно будет поместиться в 255 байт. Но я не знаю как это настроить.
|
|
|
|
Hanabishi
Стаж: 14 лет 7 месяцев Сообщений: 2897
|
Hanabishi ·
27-Окт-22 21:58
(спустя 25 мин., ред. 27-Окт-22 22:01)
asacha писал(а):
83821946Только я бы не стал все раздачи переносить на NTFS - она в Линухе трмознутая, из за того, что FUSE.
Начиная с 5.15 есть новый драйвер в ядре.
asacha писал(а):
83821946должно быть можно перейти на однобайтовую кодировку, используя локаль ru_RU.CP1251
Черевато огромным количеством проблем с системой, так как в линуксе UTF-8 стандарт де факто и весь софт пишется с расчетом на нее.
Вообще все это ненужные пляски, проще в клиенте файл переименовать и все. Не знаю как с этим дела в Transmission, но в qBittorrent точно можно.
Сейчас даже проверил: qBittorrent автоматом просто обрезает название файла и все работает, со стороны пользователя даже ничего не требуется делать.
|
|
|
|
asacha
Стаж: 18 лет 5 месяцев Сообщений: 1990
|
asacha ·
27-Окт-22 23:02
(спустя 1 час 3 мин.)
Hanabishi писал(а):
83822060Начиная с 5.15 есть новый драйвер в ядре.
А что у этого ядреного модуля с длиной имен файлов?
До сих пор, у всех "родных" файловых систем в mainline Linux было ограничение в 255 байтов.
NTFS-3g - дело другое, у FUSE ограничение всегда было больше (2K, кажется).
Hanabishi писал(а):
83822060Черевато огромным количеством проблем с системой
Какие могут быть проблемы с RPi, используемой как seed-box? Думаю, что никаких, ибо там русского языка вообще нигде быть не должно, кроме как в именах файлов.
|
|
|
|
Hanabishi
Стаж: 14 лет 7 месяцев Сообщений: 2897
|
Hanabishi ·
27-Окт-22 23:45
(спустя 42 мин., ред. 27-Окт-22 23:54)
asacha писал(а):
83822378А что у этого ядреного модуля с длиной имен файлов?
Все нормально, работает аналогично винде.
asacha писал(а):
83822378До сих пор, у всех "родных" файловых систем в mainline Linux было ограничение в 255 байтов.
Фактически ограничение именно в 255 символов, разница только в кодировке.
Родные линуксовые фс для хранения имен используют UTF-8, где символ это 1 байт, соответственно и длина получается 255 байт, а буквы кириллицы просто занимают 2 символа.
NTFS же использует UTF-16, где каждый символ это 2 байта, то есть имена занимают вдвое больше места (2х255 байт), но зато кириллица тут влезает в 1 символ.
asacha писал(а):
83822378Какие могут быть проблемы с RPi, используемой как seed-box?
Трудно сказать, тут не попробуешь - не узнаешь.
|
|
|
|
asacha
Стаж: 18 лет 5 месяцев Сообщений: 1990
|
asacha ·
28-Окт-22 01:30
(спустя 1 час 45 мин., ред. 28-Окт-22 01:30)
Hanabishi писал(а):
83822489Фактически ограничение именно в 255 символов, разница только в кодировке.
В Линуксе ограничение на длину имени файла в байтах. Каждая файловая система сообщает ядру (подсистеме VFS) имена какой максимальной длины, в байтах, она поддерживает. Вообще, имя файла в Линухе - это произвольная последовательность произвольных байтов (кроме двух "запрещённых" значений: ноль 0x00, и косая черта 0x2F). Никаких "символов", с точки зрения ядра (VFS), в именах файлов нет, никаких кодировок тоже нет: в ядре только байты. Вся возня с кодировками - это user space.
Hanabishi писал(а):
83822489UTF-8, где символ это 1 байт,
Авторы Unicode с вами категорически не согласны. В UTF-8 один символ может занимать до 4 байт.
|
|
|
|
Hanabishi
Стаж: 14 лет 7 месяцев Сообщений: 2897
|
Hanabishi ·
28-Окт-22 02:10
(спустя 39 мин., ред. 28-Окт-22 02:12)
asacha писал(а):
83822751Каждая файловая система сообщает ядру (подсистеме VFS) имена какой максимальной длины, в байтах, она поддерживает.
Не вижу противоречия. У NTFS получается 2х255 в байтах, как уже было сказано. И это прекрасно видно в коде.
asacha писал(а):
83822751Вся возня с кодировками - это user space.
Да ну? А я вот прямо в коде драйвера вижу возню с кодировками. Никакого юзерспейса здесь быть не может, когда данные фс физически хранятся на диске в UTF-16.
asacha писал(а):
83822751Авторы Unicode с вами категорически не согласны. В UTF-8 один символ может занимать до 4 байт.
Под символом я имел в виду 1 codepoint = 1 байт. "Буквы кириллицы занимают 2 символа" - имелось в виду 2 кодпоинта. И вообще UTF-8 аж до 6 кодпоинтов (= 6 байт) может содержать.
В UTF-16 при этом 1 codepoint = 2 байта. И до 2 кодпоинтов (4 байта) в общем.
|
|
|
|
asacha
Стаж: 18 лет 5 месяцев Сообщений: 1990
|
asacha ·
29-Окт-22 18:30
(спустя 1 день 16 часов, ред. 29-Окт-22 19:55)
Hanabishi писал(а):
83822817И это прекрасно видно в коде.
Спасибо за ссылку на код! Очень любопытно.
Ссылка, правда, на неинтересное место (макрос 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, учитывая, что априори никто не знает, на какой файловой системе находится каталог?! Я не смог придумать... 
Hanabishi писал(а):
83822817А я вот прямо в коде драйвера вижу возню с кодировками.
Это возня с представлением данных на диске. Я же говорил про "собственно ядро" (VFS) и POSIX/Linux API, где чистые байты. Внутри реализации FS может быть что угодно: любые ограничения или перекодировки. Например, VFAT не позволяет создавать файлы с двоеточием в имени. А если когда-нибудь напишут драйвер FS для RT-11/RSX-11/VAX-VMS, то там будут превращать буквы в кодировку RADIX-50. Это личное дело каждой файловой системы. Что не отменяет того, что все API как в ядре (VFS), так и между ядром и user space (POSIX) используют байты и знать не знают о кодировке.
Hanabishi писал(а):
83822817Под символом я имел в виду 1 codepoint = 1 байт.
Спорить об определениях не интересно, но чтобы понимать друг друга приходится договариваться о терминах. Байт в 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).
|
|
|
|
Hanabishi
Стаж: 14 лет 7 месяцев Сообщений: 2897
|
Hanabishi ·
29-Окт-22 18:51
(спустя 21 мин.)
asacha, в общем все это конечно очень интересно обсуждать, но для данной темы оффтоп 
Здесь важен лишь итог, что новый драйвер NTFS в ядре успешно реализует ее виндовое поведение и указанные названия файлов вмещает целиком, я даже специально проверил.
Но опять же имхо проще использовать клиент, который решает эту проблему тупо переименованием файла.
|
|
|
|
asacha
Стаж: 18 лет 5 месяцев Сообщений: 1990
|
asacha ·
29-Окт-22 20:11
(спустя 1 час 19 мин.)
Hanabishi писал(а):
83831080Здесь важен лишь итог, что [...] указанные названия файлов вмещает целиком
Да, согласен. Возможно, с появлением ядерного драйвера NTFS, можно будет использовать NTFS для хранения раздач, но пока - страшновато. Новый код не бывает без глюков...
Hanabishi писал(а):
83831080Но опять же имхо проще использовать клиент, который решает эту проблему тупо переименованием файла.
Да, конечно. Жаль только, что я таких клиентов не встречал. qBittorrent-nox на RPi-4 (Ubuntu 20.04) у меня сдох уже на 1500 раздачах. Он не только начал безбожно тормозить в UI, но и практически перестал раздавать. Возможно, не раздавал он из-за того, что я не сумел подобрать подходящие параметры (готовые пресеты не подошли: оно либо не раздавало, либо ему не хватало для работы памяти). Пришлось вернуться на убогий Transmission, который запросто потянул >5500 раздач, но, вместо переименования файлов, помечает раздачу как ошибочную и прекращает скачивать.
|
|
|
|
Hanabishi
Стаж: 14 лет 7 месяцев Сообщений: 2897
|
Hanabishi ·
30-Окт-22 00:51
(спустя 4 часа, ред. 30-Окт-22 00:56)
asacha писал(а):
83831449Возможно, с появлением ядерного драйвера NTFS, можно будет использовать NTFS для хранения раздач
На самом деле может быть очень полезно под раздачи использовать фс с контролем целостности данных, там Btrfs или ZFS. Об ошибках диска узнаешь сразу, не нужно гадать о целостности и перехешировать раздачи в поисках ошибок. Ext4 и NTFS в этом плане сильно отстают.
|
|
|
|
dimibyte
Стаж: 14 лет 3 месяца Сообщений: 20
|
dimibyte ·
12-Дек-22 13:57
(спустя 1 месяц 13 дней)
- Vuze устарел, но умеет в I2P и TOR и не умеет разговаривать с bt*.
- Transmission из под земли достаёт пиров, но, к сожалению, из-за отсутствия настроек прокси, скорость оставляет желать лучшего.
- qBittorrent... совсем не понимаю как он работает, но пиров как-будто не видит. Удобен для использования с отдельными интерфейсами (напр. Lokinet или Yggdrasil).
- Deluge более свободный в настройках и удобный по сравнению с Transmission, но работает нестабильно с пирами и информации по ним не предоставляет. Нет возможности разделения протоколов прокси из-за чего он DHT пускает по прокси или интерфейсу, что не всегда требуется и приводит к прекращению работы DHT.
- Tixati, хоть и с закрытым кодом, но работает изрядно хорошо и гибко с предоставлением дополнительных удобств по типу каналов, в которых можно пускать медиа поток для желающих (радио, стрим). Но главное это гибкая настройка прокси по протоколам и отдельно для трекеров и пиров. Предоставляет информацию по работе DHT.
|
|
|
|
xcop9000
Стаж: 2 года 4 месяца Сообщений: 27
|
xcop9000 ·
25-Дек-22 12:35
(спустя 12 дней)
Цитата:
29901258Какой самый лучший клиент для Linux
Наверное тот который стоит по умолчанию в вашем дистрибутиве.
|
|
|
|
Hanabishi
Стаж: 14 лет 7 месяцев Сообщений: 2897
|
Hanabishi ·
25-Дек-22 15:45
(спустя 3 часа)
xcop9000 писал(а):
84080728Наверное тот который стоит по умолчанию в вашем дистрибутиве.
Владельцы арчей и прочих минимальных дистров вышли из чата. 
|
|
|
|
sjelenfalt
Стаж: 14 лет 5 месяцев Сообщений: 56
|
sjelenfalt ·
24-Мар-23 03:54
(спустя 2 месяца 29 дней)
|
|
|
|
asacha
Стаж: 18 лет 5 месяцев Сообщений: 1990
|
asacha ·
24-Мар-23 14:05
(спустя 10 часов)
sjelenfalt писал(а):
84483150qBitTorrent
На машинах с маленьким количеством памяти (1-2GB) он совсем плохо работает, увы. Можно сказать, вообще не раздаёт.
А ещё, я не нашел для него хорошего remote GUI клиента.
|
|
|
|
Hanabishi
Стаж: 14 лет 7 месяцев Сообщений: 2897
|
Hanabishi ·
24-Мар-23 14:11
(спустя 5 мин.)
asacha писал(а):
84484687На машинах с маленьким количеством памяти (1-2GB) он совсем плохо работает, увы.
Эмм, мягко скажем неправда.
asacha писал(а):
84484687А ещё, я не нашел для него хорошего remote GUI клиента.
Родной WebUI вроде вполне сносный, почти полностью покрывает функционал десктопного клиента. Но тут конечно на вкус и цвет.
|
|
|
|
asacha
Стаж: 18 лет 5 месяцев Сообщений: 1990
|
asacha ·
24-Мар-23 18:10
(спустя 3 часа)
Hanabishi писал(а):
84484717Эмм, мягко скажем неправда.
Можете поделиться файлом с настройками qBittorrent для 2GB RAM?
Я несколько месяцев мучил qBittorent-nox на RaspberryPi-4 с 2GB RAM и 1500 раздачами. На минимальных настройках он почти ничего не раздавал, а при попытке что-то увеличить, уходил в своп и вообще переставал работать. Возможно, есть "золотая середина", но я её не нащупал. После перехода на Transmission 3.0 эти раздачи стали нормально раздаваться (не слишком быстро, но Transmission вообще тормознутый, что делать).
Hanabishi писал(а):
84484717Родной WebUI вроде вполне сносный
Я уже забыл, - это тот, который на Питоне написан?
Помню, что был очень функциональный GUI, но у меня он невыносимо тормозил. Пришлось отказаться, потому что ждать по 5-10 секунд окончания любого действия - это выше моих сил.
|
|
|
|
Hanabishi
Стаж: 14 лет 7 месяцев Сообщений: 2897
|
Hanabishi ·
24-Мар-23 18:24
(спустя 13 мин.)
asacha писал(а):
84485779Можете поделиться файлом с настройками qBittorrent для 2GB RAM?
Тут нечем делиться особо. Сам по себе клиент потребляет смешное количество памяти (зависит от количества раздач конечно).
Реально память занимать может только дисковый кэш, что соответственно решается его отключением. Если у вас версия с libtorrent 1.x, то достаточно значение "Disk cache" установить на 0. Если с libtorrent 2.x, то параметр "Disk IO type" сменить с "Memory mapped files" на "POSIX-compliant".
asacha писал(а):
84485779Я уже забыл, - это тот, который на Питоне написан?
Это тот, который в браузере открывается.
|
|
|
|
spiker01
Стаж: 14 лет 8 месяцев Сообщений: 19
|
spiker01 ·
26-Мар-23 07:15
(спустя 1 день 12 часов)
Всем привет. Я не фанат какого либо дистрибутива или клиента. Итак понадобилось мне скачать для одного парня файл. У меня 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 лучше и не будет "спариваться(на букву е) с" мозгом?
|
|
|
|
asacha
Стаж: 18 лет 5 месяцев Сообщений: 1990
|
asacha ·
27-Мар-23 16:22
(спустя 1 день 9 часов)
spiker01 писал(а):
84493103Какой клиент под GNU/Linux лучше и не будет "спариваться(на букву е) с" мозгом?
На десктопе использую qBittorrent. Проблемы бывали только одного вида: иногда сходил с ума, когда кончалось место на диске. Приходилось перезапускать. Вроде, в последних версиях с этим лучше (давно не попадал в такую ситуацию)
|
|
|
|
Aburus
Стаж: 15 лет 3 месяца Сообщений: 32
|
Aburus ·
02-Апр-23 03:17
(спустя 5 дней, ред. 02-Апр-23 03:17)
spiker01 писал(а):
Внимание знатоки!(Играет музыка из программы: "Что? Где? Когда?") Вопрос: Какой клиент под GNU/Linux лучше и не будет "спариваться(на букву е) с" мозгом?
В тонкости клиентов я, увы, сейчас не вникаю, но в свое время отлично и круглосуточно у меня работал rtorrent с фронтом. Сейчас просто какой-то transmission в дебиановом дистрибутиве, но в нем мне неудобен интерфейс.
|
|
|
|
asacha
Стаж: 18 лет 5 месяцев Сообщений: 1990
|
asacha ·
03-Апр-23 16:50
(спустя 1 день 13 часов)
Aburus писал(а):
84529265transmission в дебиановом дистрибутиве, но в нем мне неудобен интерфейс
К Transmission есть очень приличный front-end под названием Transmission Remote GUI
|
|
|
|
yandrey0
Стаж: 17 лет 3 месяца Сообщений: 591
|
yandrey0 ·
03-Апр-23 21:33
(спустя 4 часа)
Он давно протух и не собирается в актуальных дистрибутивах, из живых похожих gui tremotesf, transmission-remote-gtk .
|
|
|
|
asacha
Стаж: 18 лет 5 месяцев Сообщений: 1990
|
asacha ·
03-Апр-23 22:56
(спустя 1 час 22 мин., ред. 03-Апр-23 22:56)
yandrey0 писал(а):
84538307Он давно протух
Почему Вы так решили? Последний коммит в github'е был сделан вчера. Релизов, правда, нет с 2019 года.
yandrey0 писал(а):
84538307не собирается в актуальных дистрибутивах
Не понимаю, о чём вы? Ubuntu 23.04 (Lunar Lobster) - вроде, актуальный сегодня. 
Я только что собрал и релиз 5.18.0, и свежий master из git'а в Ubunut 23.04, всё собралось и запустилось.
Единственная засада: в Readme, приложенном к релизу, отсутствует нужная команда lazarus - нужно пользоваться инструкцией с первой страницы проекта в git'е.
Бинарный релиз у меня под Lunar Lobster, действительно, не запустился, но собрать из исходников заняло меньше 10 минут, включая установку fp-compiler и lazarus.
yandrey0 писал(а):
84538307из живых похожих gui tremotesf, transmission-remote-gtk
Спасибо!
Надо будет посмотреть. (Если судить по страничке проекта на github'е, то tremotesf выглядит более серьёзным.)
|
|
|
|
yandrey0
Стаж: 17 лет 3 месяца Сообщений: 591
|
yandrey0 ·
04-Апр-23 00:31
(спустя 1 час 34 мин.)
asacha писал(а):
84538614Последний коммит в github'е был сделан вчера.
Толку от этих коммитов с исправлением ссылок и текстов мало, разработка и поддержка остановилась.
asacha писал(а):
84538614Не понимаю
По Федоре сужу, 7 лет прошло как что то поломалось 
|
|
|
|
asacha
Стаж: 18 лет 5 месяцев Сообщений: 1990
|
asacha ·
04-Апр-23 01:40
(спустя 1 час 8 мин.)
yandrey0 писал(а):
84538963разработка и поддержка остановилась
Он работает и очень удобен. Что ещё нужно? (Обидно, конечно, что разработка остановилась - если она не возобновится, то рано или поздно возникнут проблемы, но пока всё нормально.)
yandrey0 писал(а):
84538963По Федоре сужу, 7 лет прошло как что то поломалось
Проблемы с федорой не имеют отношения к "остановке разработки и поддержки". Семь лет назад transgui активно разрабатывался и был однозначно лучше всех конкурентов. Видимо, в федоре им вообще не пользуются, потому никто и не заметил, что он перестал там собираться.
|
|
|
|
yandrey0
Стаж: 17 лет 3 месяца Сообщений: 591
|
yandrey0 ·
12-Апр-23 14:05
(спустя 8 дней, ред. 12-Апр-23 14:05)
Transmission к 4 версии по функционалу (announce-ip, torrent-added-verify-mode) стал пригоден для пользования, пытаюсь перейти на него с rTorrent, но есть некоторые слегка и очень останавливающие переход моменты: не усредненные мгновенные скорости, отсутствие привычной информации отдано/принято для каждого пира, вопросы по работе с трекерами, более 2-мя трекерами в одном tier'е странное поведение. Процессор, по сравнению с rTorrent в одних условиях, жрет в разы больше!
Я не ищу причины почему нет, очень старался, даже адаптировал под себя максимально похожие вебморды ))
|
|
|
|
gI-0p3a
Стаж: 15 лет 5 месяцев Сообщений: 15
|
gI-0p3a ·
05-Май-23 18:43
(спустя 23 дня, ред. 05-Май-23 18:43)
Однозначно на данный момент 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 в лучшую сторону ?
|
|
|
|
yandrey0
Стаж: 17 лет 3 месяца Сообщений: 591
|
yandrey0 ·
05-Май-23 19:00
(спустя 17 мин.)
gI-0p3a писал(а):
84681525qbittorrent-nox ... рулю через веб морду.
Оригинальную веб морду? она несколько неудобна на текущий момент по фильтрации/группировке трекеров и сразу видимых ошибок по ним. Из альтернативных ничего для себя подходящего не нашел ( qb-web красивая, но не то) думаю делать свою он основе оригинальной, но огорчают скудные возможности web api по трекерам
|
|
|
|
