Вышел очередной релиз bittorrent-клиента Transmission 2.70 (http://www.transmissionbt.com/), вслед за которым была сразу выпущена версия 2.71 с исправлением одной ошибки, приводящей к краху на платформе Mac OS X 10.6 Snow Leopard. Transmission - это относительно легкий и не требовательный к ресурсам torrent-клиент, написанный на языке Cи и поддерживающий разнообразные интерфейсы пользователя: GTK, Qt, native Mac, Web-интерфейс, daemon, command-line.
Изменения в Transmission 2.70:- Все платформы:
- Существенно увеличена скорость работы протокола µTP.
- Исправлена ошибка в обработке шифрованных соединений, когда входящее соединение в некоторых случаях могло не установиться.
- Исправлены ошибки в планировщике ограничителя скорости.
- Исправлены крахи при обработке некоторых магнитных ссылок.
- Mac OS X:
- Поддержка центра уведомлений (Notification Center) в системе Mountain Lion.
- Возможен предпросмотр торрент-файлов с помощью Quick Look в Finder.
- Добавлена опция убрать закачку из списка при окончании сидирования.
- Исправлено отображение Web Client с Bonjour.
- Исправлены ошибки с исключениями для Time Machine.
- Ряд других мелких исправлений и улучшений.
- Удален перевод: Simplified Chinese, т.к. нет локализаторов готовых его поддерживать в актуальном состоянии.
- GTK+:
- Для работы теперь требуется GTK+ 3.4 или более новые выпуски.
- Qt:
- Реализовано управление скоростями из системного трэя.
- Улучшено поведение при щелчке по торрентам в списке.
- Исправлена ошибка при которой торренты могли не удаляться.
- Исправлена ошибка с unicode-символами в пути по умолчанию.
- Web Client
- Вкладка инспектора теперь показывает файлы, вложенные в директории.
- Улучшена работа скроллинга на iPad
- Исправлено неправильное отображение символов.
- Исправлена ошибка с попыткой показывать десктопные уведомления не имея на это прав.URL: http://www.transmissionbt.com/
Новость: http://www.opennet.me/opennews/art.shtml?num=34946
Допидивают Qt-версию, молодцы!
> ДопидиваютОпечатка по Фрейду :)
По непривычной клавиатуре вообще-то. Хотя...
Когда ждать сбор мусора протокола в один небольшой файл, когда не все файлы из раздачи качаешь?
[captain]Когда кто-нибудь запилит патч[/captain]
А лучше бы все торрент клиенты договорились и приняли один стандарт для хранения подобной инфы, например в виде опции. Даже если б это и были просто оригинальные sparse-файлы.
а ещё лучше если бы они отвязались, наконец, от имён файлов в торренте.
> а ещё лучше если бы они отвязались, наконец, от имён файлов в торренте.Для самого по себе протокола имена файлов не важны. Для него это один непрерывный блок данных. Как его скроят клиенты - да это уже их проблемы.
Вот чего торренту не хватает так это глобальной индексации отдельных файлов, в духе осла. Потому что иначе есть ситуация когда есть 5 раздач с одинаковыми файлами, но разным imfohash и в результате пиры никогда на найдут обладателя нужного файла.
> Для самого по себе протокола имена файлов не важны.только вот пиров ищут по инфохэшу, в который ВНИЗАПНА!..
> Потому что иначе есть ситуация когда есть 5 раздач
> с одинаковыми файлами, но разным imfohash и в результате пиры никогда
> на найдут обладателя нужного файла.вот и я об этом же. привязка инфохэша к именам идиотична. приводит к тому, что клиенты должны делать костыли для переименования (и все они неудобные).
> только вот пиров ищут по инфохэшу, в который ВНИЗАПНА!..Инфохэш вообще можно рассматривать как нечто типа unique ID раздачи с неким набором параметров. Хэш покрывает весь набор параметров. Это и баг и фича одновременно :). Фича - в том что зная только инфохэш можно тем не менее найти метаданные, подкачать их и получить все параметры раздачи. У других протоколов с именно таким функционалом - небогато.
> вот и я об этом же. привязка инфохэша к именам идиотична.
На самом деле баг местами является фичой. Кроме всего прочего совсем глобальная индексация может привести к тому что каждый клиент будет надрываться далеко за пределами своих возможностей, расшарив весь HDD. К чему это приводит - можно посмотреть на примере осла...
> Инфохэш вообще можно рассматривать как нечто типа unique ID раздачичто никак не отменяет идиотичности формирования его по именам. вот чем не понравилась идея формировать его путём хэширования хэшей всех блоков данных, например? не менее уникально, зато на имена наплевать с высокой колокольни. ну, точнее, надо ещё хэшировать размеры файлов вдобавок, чтобы какой-нибудь гад не подсунул файлы не в том порядке. и всё — проблема с именами исчезла насовсем. и файлы можно переименовывать совершенно без костылей. да, можно сбоку привинтить ещё хэш имён, если это критично. да ещё что-нибудь придумать. мне, например, намного критичней переименование без костылей. потому что «abc.dvdrip.by.джигурда.ребёнокджигурды.родственникджигурды.неродственникджигурды.mkv» — это ужасно. ТАКОЕ я на винте хранить не хочу.
p.s. а если файлы не объединять, то вообще можно было бы и поиск по отдельным файлам сделать. не теряя остальных достоинств.
подскажите, как блокировать по ИП-адресам, а то одни берут но не раздают.
Кэп намекает, что в пирамиде принимающих-раздающих всегда будут люди, которые приняли больше, чем раздали. Вплоть до соотношения 100:0. Будешь их расстреливать или лишать интернетика?
казнить, нельзя помиловать
> чем раздали. Вплоть до соотношения 100:0. Будешь их расстреливать или лишать
> интернетика?Во первых, соотношение 100:0 это как? Скачал 100 байтов но отдал 0? Негодяй. Правда так поступает любой клиент, т.к. блок обычно крупнее и при всем желании раздавать неполный блок - не выйдет :)
Во вторых, протокол торрента сам автоматически наказывает тех кто не аплоадит. Личеры аплоадят тем пирам кто им больше всего налил, вот так вот просто и сурово. По сути этакий бартер, ты мне - я тебе. По поводу чего тот кто не аплоадит получает самую плохую скорость даунлоада из всех возможных. И сам себя наказывает, качая намного дольше чем более кооперативные пиры :). Если сидеров мало а личеров много, т.е. стая хилая - такой гражданин будет вообще в почти полном пролете. А если сидеров намного больше личеров - так сидеры все-равно льют ничего не прося в замен и большинство пиров все-равно сами того не желая получаются "халявщики". Например, если вы будете качать релиз убунты - там около 4 000 сидеров. Они любому кто пришел валят по возможностям его канала, так что аплоад от вас как-то не сильно то и требуется в такой ситуации :). В общем то процесс получился самобалансирующимся и дуракоустойчивым. Не вижу особого смысла его передергивать.
> Во вторых, протокол торрента сам автоматически наказывает тех кто не аплоадитфигня. протоколу положить с большим пробором на всё это, политики реализуют клиенты. кто мешает сделать клиента, который будет честно опрашивать пиров на предмет наличия у них кусков, и тем же пирам на такие же вопросы отвечать «извини, чувак, у меня ваще всё плохо, вот, половина твоих кусков есть — а больше ничего» (в грубом описании, конечно, лень сейчас вдаваться в тонкости протокола)?
и это мы не касаемся пока идиотической идеи «рейтинга на трекерах», которая вообще мегакостыль.
> фигня. протоколу положить с большим пробором на всё это, политики реализуют клиенты.Эта логика стандартизирована в официальном описальнике протокола. Реализуют ее, конечно, клиенты. И в принципе они могут это делать и как-то иначе. Но в официальном описальнике протокола оно вот так вот прописано. Все что касается choke/unchoke/optimistic unchoke (потребного для начального старта этой логики).
> кто мешает сделать клиента, который будет честно опрашивать пиров на предмет
> наличия у них кусков, и тем же пирам на такие же вопросы отвечать «извини, чувак,
> у меня ваще всё плохо, вот, половина твоих кусков есть — а больше ничего»Ничто не помешает. Только эти ремотные пиры если они личеры - не будут такому клиенту лить новые куски почти никогда, выбирая более достойных - тех, кто налил им больше всего.
Лучший способ получить от личера порцию данных - максимально быстро налить ему порцию данных которую просил он. Почти все клиенты реализуют именно эту логику - поэтому обдурить получится только самого себя. Несомненно, когда-то файл укачается и если ничего не аплоадить. Только это займет намного дольше времени, особенно в случае когда полтора сидера надрываются на 100500 личеров. Некооперативный клиент будет ждать пока сидер ему что-то сможет накапать + изредка будет получать крохи за счет optimistic unchoke на весьма лимитированном пайке. А остальные будут барыжить частями между собой по принципу ты мне - я тебе. Нет отдачи -> давай, досвидания, тут вон еще толпа готовых лить. Логика простая и эффективная. И референсный дизайн просто в стандарте прописан. Поменять можно. Вот только всех ремотных клиентов и их логику заменить тебе будет немного сложновато. Хотя, конечно, ты можешь лить файл сам себе, юзая свою логику, правда какой в этом пойнт? У глобальных структур есть "глобальная логика". Логика большинства клиентов - решает. Ты не можешь немедленно заменить все ремотные клиенты. Поэтому в среднем по больнице к тебе ремотными клиентами будет применена логика из официальной доки. А поскольку желание аплоадить зависит от ремоты - извини, ты просто нагреешь сам себя и будешь качать с минимально возможной скоростью. При таком раскладе файл может запросто качаться в разы дольше. Специально проверял - в стаях с дефицитом бандвиза на личеров после того как перестаешь аплоадить скорость рушится в разы. А если нет дефицита бандвиза от сидеров - так собственно и пофиг, все-равно все кто может аплоадить будут недоюзывать канал, пересиливая малочисленных личеров своим флудом.
В общем то у перцев вышла довольно забавная логика склонная к самобалансировке и самозащите/воздаюнию некооперативным. Это референсная логика имплементнутая в почти всех клиентах.
> (в грубом описании, конечно, лень сейчас вдаваться в тонкости протокола)?
Зато не лень было авторам протокола. Которые детально прописали этот аспект в референсной портянке протокола. Правильно сделали - теперь большинство клиентов энфорсит именно такую логику.
> и это мы не касаемся пока идиотической идеи «рейтинга на трекерах», которая
> вообще мегакостыль.А вот это вообще маразм, от которого многие уходят. Все-равно магнитные ссылки и DHT - FTW. Трекеры [как сущность индексирующая пиров раздачи] - прошлый век :). Хорошая технология - она неубиваема и без единой точки отказа. Как DHT. Потому что уродов - много. А вот перефлудить 20М юзерей даже очень крутым уродам кишка тонка.
хм, нечто прописано? странно. ложная память, чтоб её. пардон-с.
> хм, нечто прописано? странно. ложная память, чтоб её. пардон-с.http://www.bittorrent.org/beps/bep_0003.html
Данный весьма ранний BEP давно стал частью стандарта. Требования к алгоритму unchoke там описаны (внизу). По поводу чего почти все клиенты именно такой алгоритм и реализуют. Вполне удачный алгоритм в общем то.
А ты их iptablesом, чтобы наверняка.
На самом деле ситуация, когда один пир только от тебя принимает, и ничего не отдаёт, вполне честная рабочая схема
так мне не жалко если ктото не хочет раздавать, но бывают ситуации, когда только начал раздавать, сидов еще нет, а этот мало того что не раздает, так и весь канал на себя тянет
А как ты видишь, что он якобы не раздает?
> так и весь канал на себя тянетА вот это уже странно. По идее скорости должны более-менее ровно балансироваться. При условии что остальные в состоянии качать. А если не в состоянии - так тогда бандвиз просто пропал бы зря недоюзанным. Это чем-то лучше? [разве что для прова :D]
Вот кажется, что клиенту чего-то не хватает.
Например, мне не хватает массового изменения приоритетов. В том числе для файлов. В том числе для "скачки по порядку".
Компактного интерфейса не хватает, до 10 раздач пойдёт, а дальше уже тяжко рулить раздачами.
> Компактного интерфейса не хватает, до 10 раздач пойдёт, а дальше уже тяжко рулить раздачами.Там есть фильтры и сортировка. Много лет пользуюсь Transmission для скачивания и раздачи сотен торрентов, без каких бы то ни было трудностей.
Лучше просто иметь вменяемый интерфейс, а не один гигантский пункт на одну раздачу.
View->Compact View or Alt+C спасут отца русской демократии.
А категории тут не нунжны. Фильтры рулят. Программа создавалась именно как простая качалка торентов, и не включает функционал медиацентра + библотеки как другие. Лично я не понимаю смысла организации по категориям, я скачиваю какое-то время раздаю, когда надо подчищать список вбиваю название(разумеется не полное) в фильтр и убираю, делов-то.
> Компактного интерфейса не хватает,Внезапно, у интерфейса, как минимум GTKшного и вебморды - точно есть компактный режим :)
в transmission-remote-gtk точно есть
Ну так это минималистичный (или минималистический, хз) торрент-клиент. В нем по определению много-чего не хватает. Тут вопрос в другом - или его функционал конкретному пользователю достаточен, или нет.
мне, например, не хватает опции "не ограничивать скорость локальных пиров"
> Например, мне не хватает массового изменения приоритетов.А что, выделить в списке желаемые торренты -> right-click -> properties -> появится диалог свойств всей выделенной группы -> (вкладка) options -> порулить приоритетом торрента - не катит? По логике вещей должно бы.
Использую daemon версию на серваке, подключаюсь с различных клиентов, заметил такую штуку, когда заканчивается место на диске, с любых клиентов невозможно "Удалить торрент и контент", получается торрент файл удаляется, а контент продолжает храниться на диске, пока руками не почистишь, и не перезапустишь демона.Сталкивался кто ни будь с этой багой?
встречал ровно такую же ситуацию под xubuntu 12.04 (использовался дефолтный gtk-клиент, версию не помню)
Transmission сильно тормозит на проверке закаченных файлов. Другие запущенные приложения при этом начинают буквально ползать вместо нормально работы. В Deluge запущенная проверка скаченного ни на что не влияет — кнопки нажимаются, окна перетаскиваются, меню выпадает, клик мышкой работает без задержек. Интересно, почему так?
дай угадаю - zfs?
> Transmission сильно тормозит на проверке закаченных файлов.Вранье. Я специально бенчил, она очень быстро считет хэши. Кстати именно поэтому у тебя и тормозит: диск просто не успевает данные подавать :)
> Другие запущенные приложения при этом начинают буквально ползать
Ну так и скажи: "файловая система зашилась потому что слоупочная".
> вместо нормально работы.
Кто виноват что
1) ФС зашилась и тормозит?
2) Ну а где был планировщик ввода вывода? Хотя я и подозреваю что планировать 6Мб/сек на всю ораву - это как делить кусок сахара на 20 человек, но все-таки :)> В Deluge запущенная проверка скаченного ни на что не влияет —
Питонятина - слоупочная, она наверное и с диска медленнее читает по этому поводу, так что другим больше остается :)
> кнопки нажимаются, окна перетаскиваются, меню выпадает,
Не хочу ничего сказать, но если обычная user-mode программа может поставить операционку настолько раком - грош цена такой wannabe-многозадачной операционке в базарный день.
> клик мышкой работает без задержек. Интересно, почему так?
Потому что ФС и/или ОС облажались работать с нормальной скоростью и планировать операции ввода-вывода. Прикинь, во незадача? Ты сам же лишний раз дал поводы для лулзов :)
>> Transmission сильно тормозит на проверке закаченных файлов.
> Вранье. Я специально бенчил, она очень быстро считет хэши. Кстати именно поэтому
> у тебя и тормозит: диск просто не успевает данные подавать :)
>> Другие запущенные приложения при этом начинают буквально ползать
> Ну так и скажи: "файловая система зашилась потому что слоупочная".ФС тут ни при чём — Deluge пересчитывает 2,5ГБ файл за пять секунд, если тот в кэше, ничего не тормозя. Trasmission всё время лезет на диск как слон в посудную лавку.
>> вместо нормально работы.
> Кто виноват что
> 1) ФС зашилась и тормозит?Разработчики Transmission, которые не используют буферизацию ФС, очевидно.
> 2) Ну а где был планировщик ввода вывода? Хотя я и подозреваю
> что планировать 6Мб/сек на всю ораву - это как делить кусок
> сахара на 20 человек, но все-таки :)Во FreeBSD нет планировщика I/O. А какой есть — слишком примитивный, чтобы иметь альтернативы. Пора бы это уже знать.
>> В Deluge запущенная проверка скаченного ни на что не влияет —
> Питонятина - слоупочная, она наверное и с диска медленнее читает по этому
> поводу, так что другим больше остается :)Чуть не поперхнулся чаем. Тебе же говорят, что Deluge не тормозит, а Transmission тормозит. А ты наоборот своё гнёшь. Разуй глазки. Может у тебя Transmission единственной программой работает, у меня — нет, и лишний раз проверку запускать нужно заранее планировать тормоза на несколько минут, чтобы ничего в других программах не делать.
>> кнопки нажимаются, окна перетаскиваются, меню выпадает,
> Не хочу ничего сказать, но если обычная user-mode программа может поставить операционку
> настолько раком - грош цена такой wannabe-многозадачной операционке в базарный день.Если обычное приложение общается с диском как со своей собственностью, то тут либо оно МЕДЛЕННО работает, но само, либо БЫСТРО, но тормозит всё остальное.
>> клик мышкой работает без задержек. Интересно, почему так?
> Потому что ФС и/или ОС облажались работать с нормальной скоростью и планировать
> операции ввода-вывода. Прикинь, во незадача? Ты сам же лишний раз дал
> поводы для лулзов :)Облажались разработчики Transmission, не могли придумать более прямого пути для проверки файла.
> Разработчики Transmission, которые не используют буферизацию ФС, очевидно.изя, буферизацией заниматься должна ОС. а если ОС в этом надо так сильно помогать — то это значит только одно: фуфловая у тебя ОС.
> изя, буферизацией заниматься должна ОС.В случае именно торрента у менеджера кэша в клиенте сие лучше получится. Для ФС это почти рандомный доступ. Для торрент-клиента же заранее известно что будет дальше.
> В случае именно торрента у менеджера кэша в клиенте сие лучше получится.
> Для ФС это почти рандомный доступ. Для торрент-клиента же заранее известно
> что будет дальше.рандомный доступ? при проверке хэшей? лол.
> рандомный доступ? при проверке хэшей? лол.А, блин, вот эпически ступил то. Ночью надо спать а не сообщения на форум постить.
да вот и я удивился, откуда там рандом. это же мы потому над изей и смеёмся, что его мощная система с enterprise-class FS становится колом при простом последовательном чтении.
> да вот и я удивился, откуда там рандом. это же мы потому
> над изейusira, когда ты, наконец, научишься уважать ники? Когда-нибудь это тебе зачтётся. Не здесь, так в другом месте.
> и смеёмся, что его мощная система с enterprise-class FS становится колом при простом последовательном чтении.
При последовательном чтении в Deluge, пересчёте контрольных сумм торрент-контента, колом почему-то ничего не становится. Когда пересчитывает Transmission, колом становится всё GUI на GTK.
> usira, когда ты, наконец, научишься уважать ники?изя, тебя это беспокоит? ты хочешь об этом поговорить?
> Когда пересчитывает Transmission, колом становится всё GUI на GTK.
изя, ты путаешься в показаниях. выше ты писал, что колом становится весь софт, который к диску обращается. ты уже выдохни, наконец, подожди, пока отпустит и напиши непротиворечиво.
>> В случае именно торрента у менеджера кэша в клиенте сие лучше получится.
>> Для ФС это почти рандомный доступ. Для торрент-клиента же заранее известно
>> что будет дальше.
> рандомный доступ? при проверке хэшей? лол.Если блоки файла распределены по всему диску равномерно, то можно считать, что доступ к диску рандомный.
> Если блоки файла распределены по всему диску равномерно, то можно считать, что
> доступ к диску рандомный.если твоя FS на этом зашивается, то можно считать, что твоя FS — фуфло.
> ФС тут ни при чёмЕсли клинит system-wide так что тормозит вообще все - очень даже при чем. Это означает что диск тормозит и когда некая программа просит операцию, операция не выполняется немедленно а оседает в немеряной очереди операций. И программа висит в соотв. вызове ожидая пока операционка отпедалит эту операцию. Если очередь большая а диск/ФС тормозные - получаем вот такой вот дец. Как раз общесистемный - клинить начинает любую программу которую угораздило хоть что-то с файлами делать и это не было асинхронной операцией.
А скажи, клевый у меня телепатор? :)
> — Deluge пересчитывает 2,5ГБ файл за пять секунд, если тот в кэше,
Трансмишн, как ни странно, тоже. Потому что чудес не бывает.
> ничего не тормозя. Trasmission всё время лезет на диск как слон в посудную лавку.
В общем случае в реалистичном сценарии (ака куча разных торрентов, явно превышающих объем оперативки) торенты в кэш не лезут и большую часть времени с точки зрения ОС будет cache miss. Тем более что ОС не знает что попросят следующим вот так сходу.
У трансмишна кстати с неких пор есть настройки встроенного буфера. Поскольку клиент намного лучше ОС знает что он будет читать и писать дальше, этот буфер имеет смысл и может изрядно разгрузить диск, сделав I/O менее хаотичным и более крупноблочным. Если диск совсем гэ а оперативы много - можно этот встроенный кэш увеличить. Трансмишн станет жрать больше памяти но заметно разгрузит диск.
>> 1) ФС зашилась и тормозит?
> Разработчики Transmission, которые не используют буферизацию ФС, очевидно.Буферизация ФС для торрентов в большинстве случаев будет лажаться. Просто потому что это в своем нативном виде совершенно рандомный доступ и как правило к весьма большому объему данных, много больше чем есть оперативы. По поводу чего почти всегда будет беспонтовый cache miss. По этому поводу есть ряд стратегий по борьбе с этим. В частности - засунуть менеджер кэша и локальный кэш в апликуху. Этот кэш в курсе того что качается и что потребуется записывать. И в курсе что хотят ремотные пиры и что они захотят чуть попозже. Поэтому он может затолкаьт в себя заранее крупными блоками и потом цедить пирам по мере их возможностей. Сильно разгрузив диск, благо механическому диску очень неудобно когда его долбят мелкими рандомныим запросами - он больше гоняет головы туда-сюда чем читает/пишет. А вот такой кэш может нехило разгрузить диск. Попробуй увеличить.
>> 2) Ну а где был планировщик ввода вывода?
[...]
> Во FreeBSD нет планировщика I/O. А какой есть — слишком примитивный, чтобы
> иметь альтернативы. Пора бы это уже знать.Я как-то не обязан в чужих инвалидностях детально разбираться. Собственно планировщик ввода вывода должен в такой ситуации попилить более-менее честно то что есть на всех. Ж@па конечно никуда не денется, но ее масштаб сократится. В том плане что программы будут в среднем меньше висеть в системных вызовах, так что времена их реакции улучшатся.
> Чуть не поперхнулся чаем. Тебе же говорят, что Deluge не тормозит, а
> Transmission тормозит.Значит где-то есть разница в логике работы с диском. Может быть у Deluge встроенный буфер здоровый по дефолту, например.
> А ты наоборот своё гнёшь. Разуй глазки. Может у тебя Transmission
> единственной программой работает, у меня — нет,(глядя на работающий трансмишн) у меня он висит в трее пока я печатаю это сообщение. Ничего не клинит. Ну то-есть вообще совсем. Я такое не лю и потому предпринял ряд мер к тому чтобы подобные ситуации в принципе возникать не могли.
1) System и data диски у меня разнесены. Поэтому даже абсолютный завал винтов с данными запросами не вызовет подвисания всех системных программ (вообщем всего что не работало с data дисками).
2) Я настроил трансмишну достаточно внятный кэш.
3) Я уверен что ФС в крейсерском режиме у меня не зашивается и не фрагментирована что пиндец.
4) Я сделал FULL-дефраг торрентов, положив темпарь на один физический диск и финальное назначение на другой. Так что файл чисто физически вынужден отдефрагментироваться при переносе из темпаря в финальную локацию.
5) Кстати для системы SSD - вещь. Правда от конфигурационной диры трансмиссии я его избавил. Чтоб не протирался лишний раз.> и лишний раз проверку запускать нужно заранее планировать тормоза
> на несколько минут, чтобы ничего в других программах не делать.Ну я не виноват что из тебя системщик столь хреновый что у тебя дисковая подсистема зашивается настолько что все остальные программы тоже пролетают. У меня такого нет, потому что я сам себе не враг. У меня такие ситуации исключены на уровне дизайна локаций файловой системы. То-есть, я понимая причину таких тормозов просто изничтожил не то что тормоза, а потенциал для их возникновения вообще. При упомянутом разделении локаций просто не возникнет ситуация когда система и программы в ней будут курить бамбук попав в немерянную очередь запросов к диску.
>> настолько раком - грош цена такой wannabe-многозадачной операционке в базарный день.
> Если обычное приложение общается с диском как со своей собственностью,Для тупых намекаю что делить ресурсы - как раз обязанность многозадачной системы. Не дос чай и не винды 3.1 с кооперативной многозадачностью.
> то тут либо оно МЕДЛЕННО работает, но само, либо БЫСТРО, но тормозит всё остальное.
Ну да, иногда в апликухах вставляют холостые циклы для компенсации дефективности работы операционки. Но это вообще-то воркэраундинг гунявости разделения ресурсов операционкой.
> Облажались разработчики Transmission, не могли придумать более прямого пути для
> проверки файла.По изначальной задумке, апликухи о таких вещах вообще знать ничего не должны. Если им это приходится узнавать - то только в силу гунявости операционок или криворукости тех кто ими рулит. Правда просто?
хороший клиент, спасибо авторам. здорово было бы если настройки фильтров не сбрасывались при перезапуске, а то мамка порево спалит
Умеет ли он не шейпить трафик по локальным пирам/cидам ?
Пользуюсь web клиентом на сервачке 24/7 уже 4 года. Отличная штука. Именно с автономной файлопомойки-торентокачалки началось мое знакомство с Linux. Успехов проекту.
> с автономной файлопомойки-торентокачалки началось мое знакомство с Linux. Успехов проекту.Share and enjoy!
натолкнулся случайно на совершенно непотребную "фичу".Существует флаг private в торрент-файлах, который "запрещает" торрент-клиентам использовать DHT и PEX.
это непозволительно, ящитаю. Пересобрал для себя transmission без этой "фичи".
надо исправить файл libtransmission/metainfo.c:
/* private */
if( !tr_bencDictFindInt( infoDict, "private", &i ) )
if( !tr_bencDictFindInt( meta, "private", &i ) )
i = 0;
+ i=0;
inf->isPrivate = i != 0;
breaking news! у торрентов есть флаг "private"! мой rtorrent игнорирует его с того момента, как я начал пользоваться rtorrent.