LINUX.ORG.RU

анабиозникам - превед!

Andru ★★★★
()

Перегруженные мю, кю и прочие -торренты всё равно не нужны. Даже маководам, надеюсь.

/вот что меня удручает, так это отсутствие Трансмишшна под Оффтопик. Очень и очень нужно.

SplindeR
()

Проприетарное г-но не нужно.

Alex_A_V ★★
()

кстати , µTorrent вантузный прекрасно работает под wine .

elipse ★★★
()

они не знают про ktorrent?

dreamer ★★★★★
()
Ответ на: комментарий от Kaschenko

> Чем эта проприетарная поделка хороша ?

Миниатюрная по весу, при этом никаких сторонних зависимостей, быстрый неперегруженый интерфейс, мгновенно стартует, не ест память. По неизвестным мне обстоятельствам некоторые торренты качает гораздо быстрее того же KTorrent, и даже те, что KTorrent не качает вообще. Имеет колонку 'Remaining'. Работает как часы, не глючит от версии к версии.

Вобщем, один из примеров отличного бесплатного ПО под Windows. Называется учитесь как нужно делать программы.

Dendy ★★★★★
()
Ответ на: комментарий от SplindeR

Маковский µторрент ниразу неперегружен, и собрки под мак были уже довольно давно. Трансмишн имеет свойство жутко тупить на больших(>50GB) торрентах.

kostian ★★★★☆
()

Опа. С приветом из анабиоза. Пользовался uTorrentом с момента покупки макбука. Начинал с 0.9.0 первой беты. А ты только нашел...

iRunix ★★★★
()
Ответ на: комментарий от Dendy

> По неизвестным мне обстоятельствам некоторые торренты качает гораздо быстрее того же KTorrent, и даже те, что KTorrent не качает вообще.

Все P2P клиенты обладают таким не очень хорошим свойством - они лучше всего качают с пиров, работающих под тем же клиентом. И это никак не зависит ни от протокола, ни от качества его реализации в клиенте. Соответственно лучше всего качать тем клиентом, который наиболее распространён в конкретной p2p-сети. Под Windows µTorrent - ЕМНИП самый популярный, и почти на всех торрент-трекерах большинство пользователей пользуются именно им.

Deleted
()
Ответ на: комментарий от MoRoZ

> это заговор!

Нет никакого заговора. Просто в протоколах не стандартизованы некоторые вещи, вроде алгоритма оптимального выбора пиров с которых качать, или какие именно части файла запрашивать в первую очередь. А реализовать это можно очень по-разному.

Deleted
()
Ответ на: комментарий от Deleted

> Все P2P клиенты обладают таким не очень хорошим свойством - они лучше всего качают с пиров, работающих под тем же клиентом. И это никак не зависит ни от протокола, ни от качества его реализации в клиенте.

Вы как-то ну уж очень лихо обобщили все протоколы, в результате звучит совершенно неубедительно. С чего это работа моего клиента будет зависеть от юзер-агента чужого протокола? Намекаете на саботаж со стороны разработчика µTorrent? Лично я регулярно замечаю у KTorrent'а ошибки соединения с трекором и низкую скорость обновления пиров - в том же µTorrent количество подключений оказывается почему-то больше.

Видя насколько хромая происходит разработка KTorrent я думаю, что вопросы оптимизации в нём стоят на последнем месте. Откуда и подобные огрехи в работе. Он до сих пор крешится при первом старте после закрытия, как и полгода назад. До сих пор зависает при старте на несколько секунд, вычитывая торренты из базы, при том, что их там может быть не одна сотня. До сих пор перепроверка данных для нескольких торрентов происходит _одновременно_, а не последовательно, что вызывает дикий треск винта и тормозит прочие дисковые операции. До сих пор менеджер последовательности закачек выглядит ужасно. До сих пор операции над торрентами производятся в GUI-потоке, что вызывает кратковременные зависания интерфейса здесь и там.

Dendy ★★★★★
()
Ответ на: комментарий от Dendy

> Вы как-то ну уж очень лихо обобщили все протоколы, в результате звучит совершенно неубедительно. С чего это работа моего клиента будет зависеть от юзер-агента чужого протокола? Намекаете на саботаж со стороны разработчика µTorrent? Лично я регулярно замечаю у KTorrent'а ошибки соединения с трекором и низкую скорость обновления пиров - в том же µTorrent количество подключений оказывается почему-то больше.

Прочитай моё предыдущее сообщение.

> Видя насколько хромая происходит разработка KTorrent я думаю, что вопросы оптимизации в нём стоят на последнем месте. Откуда и подобные огрехи в работе. Он до сих пор крешится при первом старте после закрытия, как и полгода назад. До сих пор зависает при старте на несколько секунд, вычитывая торренты из базы, при том, что их там может быть не одна сотня. До сих пор перепроверка данных для нескольких торрентов происходит _одновременно_, а не последовательно, что вызывает дикий треск винта и тормозит прочие дисковые операции. До сих пор менеджер последовательности закачек выглядит ужасно. До сих пор операции над торрентами производятся в GUI-потоке, что вызывает кратковременные зависания интерфейса здесь и там.


Багрепорты уже в багтрекере?

Deleted
()
Ответ на: комментарий от Dendy

> Видя насколько хромая происходит разработка KTorrent я думаю, что вопросы оптимизации в нём стоят на последнем месте. Откуда и подобные огрехи в работе. Он до сих пор крешится при первом старте после закрытия, как и полгода назад.

видимо у меня какой-то другой кторрент

overmind88 ★★★★★
()
Ответ на: комментарий от Deleted

> Прочитай моё предыдущее сообщение.

То-есть вы хотите сказать, что KTorrent и другие клиенты идеально реализуют протокол, а µTorrent его обходит, добавляя какие-то свои фичи, с помощью которых список пиров стаёт больше? Вилами по воде, если нет конкретных фактов нарушения протокола, то это всё охота на ведьм.

> Багрепорты уже в багтрекере?

К сожалению что я перечислил - это ошибки в дизайне, которые на виду. В багтрекере им делать нечего.

>> Он до сих пор крешится при первом старте после закрытия, как и полгода назад.

> видимо у меня какой-то другой кторрент

Моя вина. Он не крешится, а ждёт, пока предыдущая копия закроется. То-есть при старте второй копии показывается мёртвое главное окно первого KTorrent'а, которое может висеть несколько секунд, после чего исчезает. Зрелище нелицеприятное.

Только что проверил горячий старт KTorrent'а - 15 секунд трещания винтом. При том, что он я закрыл его минуту назад. Закрытие и повторный запуск снова - 3 секунды. Холодный старт µTorrent под Windows XP - мгновенный. Здесь уже пенять остаётся не на кого.

Dendy ★★★★★
()
Ответ на: комментарий от Dendy

> То-есть вы хотите сказать, что KTorrent и другие клиенты идеально реализуют протокол, а µTorrent его обходит, добавляя какие-то свои фичи, с помощью которых список пиров стаёт больше? Вилами по воде, если нет конкретных фактов нарушения протокола, то это всё охота на ведьм.

Перечитай моё сообщение ещё раз. Я говорил про то, что в P2P протоколах есть немало вещей, которые можно реализовать сильно по-разному, и реализации при этом останутся совместимыми на уровне протокола.

Это примерно как если два человека идут навстречу друг другу и им надо друг друга обойти. Если они начнут это делать по одинаковому алгоритму (например оба начнут обходить справа) - разойдутся сразу. А если один начнёт обходить справа, а другой - слева, то они не смогут разойтись на этом шаге и придётся предпринимать следующий.

> К сожалению что я перечислил - это ошибки в дизайне, которые на виду. В багтрекере им делать нечего.


На виду у кого? Я уже это писал и на этом форуме и много где ешё: если проблема не сообщена разработчикам (с указаниями как её воспроизвести), то это просто выдумка пользователя. Телепатии не существует.

Deleted
()
Ответ на: комментарий от Deleted

> Я говорил про то, что в P2P протоколах есть немало вещей, которые можно реализовать сильно по-разному, и реализации при этом останутся совместимыми на уровне протокола.

Это справедливо только если клиент на другом конце знает кто к нему подключился и начинает ломать протокол под себя. Запрещать некоторые действия, искуственно тормозить или обходить протокол. Пока нет фактов, доказывающих заточенность клиентов µTorrent друг под друга предлагаю оставить догадки при себе.

> На виду у кого? Я уже это писал и на этом форуме и много где ешё: если проблема не сообщена разработчикам (с указаниями как её воспроизвести), то это просто выдумка пользователя. Телепатии не существует.

Ну то что время старта пропорциональна количеству торрентов думаю ни для кого из разработчиков не секрет. То что начиная с сотни торрентов Queue Manager становится неюзабельным тоже. И что проверка торрентов происходит параллельно. У них был огромный опыт создания KTorrent 2, более того у них в руках мощнейший тулкит как Qt 4, в котором замечательное API для многопоточности. Тут как ни крути, а всё упирается в квалификацию самих разработчиков, и отправь ты хоть сотню багрепортов - принципиально ничего не изменится.

Dendy ★★★★★
()
Ответ на: комментарий от Dendy

> Это справедливо только если клиент на другом конце знает кто к нему подключился и начинает ломать протокол под себя. Запрещать некоторые действия, искуственно тормозить или обходить протокол. Пока нет фактов, доказывающих заточенность клиентов µTorrent друг под друга предлагаю оставить догадки при себе.

Ещё раз - протокол не ломается. На уровне протокола uTorrent и KTorrent, а так же другие нормальные торрент-клиенты совместимы. Разница в поведении. Попробуй подумать.

> Ну то что время старта пропорциональна количеству торрентов думаю ни для кого из разработчиков не секрет. То что начиная с сотни торрентов Queue Manager становится неюзабельным тоже. И что проверка торрентов происходит параллельно. У них был огромный опыт создания KTorrent 2, более того у них в руках мощнейший тулкит как Qt 4, в котором замечательное API для многопоточности. Тут как ни крути, а всё упирается в квалификацию самих разработчиков, и отправь ты хоть сотню багрепортов - принципиально ничего не изменится.


Так ты всё-таки отправил багрепорты и при этом ничего не изменилось? Или не отправил, а просто бессмысленно ноешь какой KTorrent плохой? И не надо решать за разработчиков что для них секрет, а что не секрет.

Deleted
()
Ответ на: комментарий от Deleted

> Ещё раз - протокол не ломается.

Я и не говорю, что он нарушается. Я говорю, что претензии к установке параметров, позволяющих общаться между одними и теми же клиентами "лучше", при этом оставаясь в рамках протокола, беспочвены и притянуты за уши. Поэтому давайте оставим эту тему в покое.

> Так ты всё-таки отправил багрепорты и при этом ничего не изменилось?

Я был у них на сайте, общался на форуме. Там один разработчик, который не один год трудится над проектом. Костяк программы сварен и оброс плагинами (по большей части бесполезными, так как их нужно было встроить в программу). Проект движется вперёд и только вперёд, очевидные ошибки дизайна уже никто не будет исправлять - попросту некому, некогда да и квалификации боюсь может нехватить.

Именно поэтому параллельно растут такие проекты как QBitTorrent, QTorrent и Transmission с интерфейсом на Qt. Хотя и они не блещут.

Dendy ★★★★★
()
Ответ на: комментарий от SplindeR

> уж не знаю, как они в эти 80 запихнули столько ерунды.

В мак-версии ерунды-то и нет, только самое необходимое, мне даже нескольких функций нехватает. Да и весит он не 80, а 1.3М, вроде.

a3
()
Ответ на: комментарий от Dendy

> Я и не говорю, что он нарушается. Я говорю, что претензии к установке параметров, позволяющих общаться между одними и теми же клиентами "лучше", при этом оставаясь в рамках протокола, беспочвены и притянуты за уши. Поэтому давайте оставим эту тему в покое.

#%$&*%! Да нет там никаких параметров. Ты вообще представляешь как работают файлообменные p2p-сети?

Deleted
()
Ответ на: комментарий от Deleted

> Ты вообще представляешь как работают файлообменные p2p-сети?

Мы говорим не про абстрактные p2p-сети, а про конкретный протокол. И как он работает я представляю. Только не понимаю к чему вы клоните. Приведите конкретный пример, почему пара µTorrent-клиентов должна работать лучше, чем в другой комбинации.

Dendy ★★★★★
()
Ответ на: комментарий от Dendy

> Мы говорим не про абстрактные p2p-сети, а про конкретный протокол. И как он работает я представляю. Только не понимаю к чему вы клоните. Приведите конкретный пример, почему пара µTorrent-клиентов должна работать лучше, чем в другой комбинации.

Ну ладно. Допустим, что ты - торрент-клиент. Тебе сервер сообщил адреса пиров для некоторого торрента. Плюс информацию о том, какие у какого пира есть части файлов, сколько уже с них качают и т.п. Твоя задача - наиболее оптимально выбрать к каким пирам подключаться, с тем учётом, что их несколько сотен, а интернет канал не резиновый. Твои действия?

Deleted
()
Ответ на: комментарий от Deleted

> Твои действия?

Собственно мои действия роли не играют. Вопрос в том, почему в этом случае действия клиентов µTorrent и KTorrent должны отличаться?

Dendy ★★★★★
()
Ответ на: комментарий от Dendy

>почему пара µTorrent-клиентов должна работать лучше, чем в другой комбинации.

Обмен пирами в мюТорренте организован несколько отлично от других клиентов

DNA_Seq ★★☆☆☆
() автор топика
Ответ на: комментарий от Dendy

> Собственно мои действия роли не играют. Вопрос в том, почему в этом случае действия клиентов µTorrent и KTorrent должны отличаться?

А почему мы в нашей дискуссии друг друга понять не можем? Вроде оба Homo Sapiens'ы, оба мужского пола и даже оба на одном языке разговариваем. Вот ведь блин загадка...

P.S. Я уже потерял надежду что-либо тебе объяснить.

Deleted
()

Не понимаю, что находят в этом мюторренте? Торрент-клиент должен быть (1) простой, (2) легкой, (3) быстрой программой, которую можно запустить и забыть! Зачем нужна всякая многофункциональность, внешний красивый вид и пр.? rtorrent, transmission и возможно еще несколько - вот каким должен быть торрент-клиент! Ничего лишнего! Монструозные ktorrent, azerus, utorrent (есть маразматики, которые это "чудо" через wine гоняют...) и прочие, которые на четверть съедают проц и память - в печку!

paxac
()
Ответ на: комментарий от Deleted

> А почему мы в нашей дискуссии друг друга понять не можем?

Я задаю конкретный вопрос, а вы ходите вокруг да около, аппелируя общими фразами "p2p-сети" и "Homo Sapience". Повторюсь, я не понимаю, почему имея на руках стандарт протокола и получив одни и те же данные от трекера алгоритм работы клиентов должен отличаться. Можете не намекать на тайные знания, а говорить сразу в лоб.

> Обмен пирами в мюТорренте организован несколько отлично от других клиентов

Ну вот хоть какое-то обьяснение. Вопрос в том насколько эта возможность отличается от стандарта.

Dendy ★★★★★
()
Ответ на: комментарий от Dendy

> Повторюсь, я не понимаю, почему имея на руках стандарт протокола и получив одни и те же данные от трекера алгоритм работы клиентов должен отличаться. Можете не намекать на тайные знания, а говорить сразу в лоб.

Говорю сразу и в лоб - алгоритма оптимального выбора пиров для коннекта не существует, так как для одного p2p-клиента все остальные клиенты - "чёрные ящики". Поэтому разработчики каждого клиента велосипедят собственный эвристический алгоритм выбора куда подключаться, а так же принимать ли входящее подключение от другого конкретного пира или нет.

Ну и кроме того, как уже сказал человек выше - возможно что у µTorrent'а есть какой-то свой дополнительный механизм обмена информацией между пирами. В случае p2p такое делается очень легко и без вмешательства в протокол. И сразу же говорю: я не знаю, действительно ли такое есть в µTorrent, просто говорю что такое вполне возможно.

Deleted
()
Ответ на: комментарий от Dendy

> Я задаю конкретный вопрос, а вы ходите вокруг да около, аппелируя общими фразами "p2p-сети" и "Homo Sapience". Повторюсь, я не понимаю, почему имея на руках стандарт протокола и получив одни и те же данные от трекера алгоритм работы клиентов должен отличаться. Можете не намекать на тайные знания, а говорить сразу в лоб.

Даже и не знаю, что тут можно сказать - вам конкретно поясняют, где могут быть различия, а вы упорно твердите свое.

Привели пример про двух идущих на встречу друг-другу прохожих, про возможных различиях в алгоритме выборки пиров. А вам снова не понятно.

andreyu ★★★★★
()
Ответ на: комментарий от Deleted

> Поэтому разработчики каждого клиента велосипедят собственный эвристический алгоритм выбора куда подключаться, а так же принимать ли входящее подключение от другого конкретного пира или нет.

То-есть получается, что в некоторых случаях "собственный эвристический алгоритм" µTorrent оказывается лучше "собственного эвристического алгоритма" KTorrent. Что можно отнести к недостаткам последнего.

> В случае p2p такое делается очень легко и без вмешательства в протокол.

То-есть что я и говорил - обход протокола для улучшения алгоритма выбора пиров. Или ведение нечесной игры, вроде отключения неугодных µTorrent'у клиентов. Пока я вижу это единственно возможным случаем улучшения работы самого µTorrent'а.

Но насколько я вас понял - лучшая работа µTorrent'а обеспечивается при условии, что он работает честно с произвольными чёрными ящиками плюс остаётся строго в рамках протокола. Только с идентичными клиентами он каким-то образом умудряется работать "лучше", за счёт чего только - остаётся загадкой.

Dendy ★★★★★
()
Ответ на: комментарий от paxac

Толсто! А память съедается в основном на кэши

DNA_Seq ★★☆☆☆
() автор топика
Ответ на: комментарий от Dendy

Dendy, у меня ktorrent и uTorrent стартуют одинаково, потому тебе пора в игнор, ты слишком уныл.

linux4ever
()

трансмишону давным давно пора в могилу.

stave ★★★★★
()
Ответ на: комментарий от Dendy

> То-есть получается, что в некоторых случаях "собственный эвристический алгоритм" µTorrent оказывается лучше "собственного эвристического алгоритма" KTorrent. Что можно отнести к недостаткам последнего.

Ещё раз - µTorrent работает лучше только с другими пирами, работающими под µTorrent. Соответственно, если большинство пиров на конкретном сервере работает под µTorrent, то µTorrent с этим трекером работает лучше. Тут нет такого понятия лучше или хуже алгоритм.

> Но насколько я вас понял - лучшая работа µTorrent'а обеспечивается при условии, что он работает честно с произвольными чёрными ящиками плюс остаётся строго в рамках протокола. Только с идентичными клиентами он каким-то образом умудряется работать "лучше", за счёт чего только - остаётся загадкой.


Ты неправильно понял. Объяснять не буду, так как мне надоело говорить одно и то же N-ный раз.

Deleted
()
Ответ на: комментарий от Dendy

Кстати, в спецификациях BitTorrent нету стандартизированного обмена пирами (PEX). На данный момент ЕМНИП существует 2 реализации обмена пирами - одна от uTorrent, другая от Vuze. Другие клиенты используют, естественно, первую, так как uTorrent популярнее. Поэтому считайте, что KTorrent использует чужую реализацию, не до конца изученную, поэтому и плохо работает.
Не вижу у KTorrent каких-либо недостатков. Никогда не наблюдал вышеперечисленные недостатки.

h31 ★★★★
()
Ответ на: комментарий от Dendy

Постараюсь объяснить.
Существуют разные реализации, но все они подходят под спецификацию. Например, мужчины и женщины думают различно, но и те, и другие являются человеками. Когда два человека думают одинаково, то работа идет лучше, все слажено, но когда они думают различно, то возникают споры и т.д. Но оба думают, просто разные _реализации_, и одинаковые совместно работают лучше, чем различные.

h31 ★★★★
()
Ответ на: комментарий от Deleted

> ... при этом останутся совместимыми на уровне протокола.

>> Но насколько я вас понял - лучшая работа µTorrent'а обеспечивается при условии, что он работает честно с произвольными чёрными ящиками плюс остаётся строго в рамках протокола.

> Ты неправильно понял.

Собственно я никак не могу склеить две эти противоречащие мысли.

Dendy ★★★★★
()
Ответ на: комментарий от Dendy

> Собственно я никак не могу склеить две эти противоречащие мысли.

Я выше привёл простой пример с двумя людьми, идущими на встречу друг другу по одной прямой. Они не смогут сходу разойтись не потому что один глупее, а другой умнее, а просто потому что они применят разный алгоритм выбора пути обхода. То что две какие-то вещи _разные_ не означает, что одна из них хуже другой.

Найди какой-нибудь торрент-трекер, на котором большинство пиров будет под KTorrent. Вот там KTorrent будет работать лучше (в плане скорости поиска пиров и скачивания), чем µTorrent.

Deleted
()
Ответ на: комментарий от h31

> Постараюсь объяснить.

Спасибо за обьяснение. Другими словами протокол позволяет достаточно широкий спектр возможностей, а каждый клиент их сужает по-своему, рассчитывая, что клиент на другом конце сделает так же. Так? Тогда это можно охарактеризовать как недостаток протокола и методы обхода этого недостатка, расширяя протокол.

Dendy ★★★★★
()
Ответ на: комментарий от Dendy

Да, расширением протокола эту проблему можно придавить, но полностью убрать невозможно.

h31 ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.