LINUX.ORG.RU

Релиз EiskaltDC++ 2.2.3

 , , , , , ,


0

1

Cостоялся релиз EiskaltDC++ 2.2.3, кроссплатформенного графического клиента для сетей Direct Connect и ADC.

Основные отличия от версии 2.2.2 смотрите в журнале изменений и/или комментариях к новости.

Следующий релиз программы ожидается 18 сентября.

За активностью разработки проекта можно наблюдать на данной странице. Пообщаться с разработчиками можно в Jabber-конференции eiskaltdc@conference.gentoo.ru или в специальной ветке форума. Сообщения об ошибках и запросы на реализацию улучшений принимаются в системе трекинга ошибок Google Code.

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

>>> Подробности

★★

Проверено: maxcom ()

Ответ на: комментарий от kss

>Ну вот я, например, предпочитаю LinuxDC++. Вполне сознавая, что eiskalt более технически продвинут.

Почему?

Ведь в LinuxDC++ даже основные функции: поиск и скачивание нереализованны полноценно - в поиске нет группировки совпадающих результатов, нет фильтра по результатам поиска, в скачивании качает только с одного источника, до того момента как выполнится поиск альтернатив, который на некоторых хабах вообще ограничен по частоте использования несколькими часами.

Ещё один момент это поддержка UPnP - сейчас почти у всех дома используются роутеры, т.к. компьютеров обычно несколько, а в LinuxDC++ нет поддержки UPnP. Хотя можно и вручную конечно в настройках роутера для каждого компьютера порты открыть, но это не самая лёгкая задача для простого пользователя, а с UPnP только галочку в настройках клиента поставить и всё работает.

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

>А что, в EiskaltDC++ альтернативные источники не через TTH ищутся, что ли?

Речь не об этом, а о том что после выполнения поиска в LinuxDC++ результаты не сгруппированны по TTH и если ставишь на закачку какой-либо результат поиска то скачивание начинается только с одного источника, и только спустя несколько минут выполнится поиск по TTH и добавятся остальные источники, а если на хабе ограничение на частоту поиска через TTH раз в два часа то LinuxDC++ так и будет качать с одного источника.

А в EiskaltDC++ после выполнения поиска результаты сгруппированы по TTH и если поставить на закачку такую группу то загрузка начинается сразу со всех источников из этой группы, а через некоторое время как и в LinuxDC++ выполняется поиск по TTH который добавит новые источники если они появились за прошедшее время.

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

>Ведь в LinuxDC++ даже основные функции: поиск и скачивание нереализованны полноценно - в поиске нет группировки совпадающих результатов

По-моему, ты ошибаешься: все есть. Но проверить смогу вечером только, если тебе по-прежнему будет интересно, то отпишусь.

нет фильтра по результатам поиска

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

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

Поиск альтернатив, как я понимаю, в LinuxDC++ ведется при любом последующем ручном поиске. С одной стороны, это менее удобно (хотя, обычно в локалке скорость скачки и так высокая), с другой — нет проблем с обломом ручного поиска, как в моих ссылках выше. А на хабах с ограничением по частоте использования TTH-поиска, как я понимаю, Eiskalt тоже обломать должно.

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

Ну у меня роутера точно нет (за ненадобностью). Честно говоря, я сомневаюсь, что это они действительно почти у всех дома есть, видимо, это особенность твоей выборки.

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

имеющий некоторый tth, ни у кого в локалке нету, а в инете через dht нашлось, качаем с инета.

а что значит с нета? с какого типа сети? не с торрента же.

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

Настройки - шара - использовать быстрый кэш.

[внезапно] это по умолчанию и стояло. valknut быстро хэшировал и не тормозил, а это даже с приниженной скоростью тормозит адски.

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

Всё перечисленное можно найти, надо подключится к нескольким крупным хабам, например, вот список русских хабов http://dchublist.ru/hubs/ и искать. Только обычно для поиска и скачивания надо иметь свою собственную шару размера большего чем минимально разрешённый, который варьируется для различных хабов. Как правило, большинство хабов настроенны так, что чем больше ты расшарил тем больше получаеш бонусов, например, чаще можно пользоваться поиском, в том числе и автоматическим, а это приводит к увеличению источников, ну и у некотрых стоит ограничение на размер шары для качающих, так что если шара слишком маленькая то ничего скачать будет нельзя.

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

http://www.linux.org.ru/jump-message.jsp?msgid=5799703&cid=5804026

Зато обычный (ручной) поиск это иногда и правда «обламывает», было бы и правда неплохо сделать такую фишку с таймером и ожиданием истечения интервала времени для начала поиска.

Если нужны какие-либо расширения или исправления ошибок то надо заводить issue здесь http://code.google.com/p/eiskaltdc/issues/list

Нет issue на багтрекере - нет проблемы, т.е. все голословные высказывания без оформления на багтрекере скорее всего будут проигнорированы.

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

>>Ведь в LinuxDC++ даже основные функции: поиск и скачивание нереализованны полноценно - в поиске нет группировки совпадающих результатов

По-моему, ты ошибаешься: все есть.

В LinuxDC++ 1.1.0 есть, и при добавлении группы в очередь скачивает со всех источников.

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

>Поиск альтернатив, как я понимаю, в LinuxDC++ ведется при любом последующем ручном поиске. С одной стороны, это менее удобно (хотя, обычно в локалке скорость скачки и так высокая), с другой — нет проблем с обломом ручного поиска

Не при любом, а при поиске по такой поисковой фразе, что файлы находящиеся в очереди по ней бы нашлись, например если в очереди есть фильмы со строкой «2011» в имени, то при поиске строки 2011 для них найдутся источники, кстати такой же эффект будет в любом клиенте на ядре DC++, в том числе и на Windows клиентах.

нет проблем с обломом ручного поиска

Это почему же? - Проблема никуда не денется: если перед моментом ручного поиска LinuxDC++ выполнит автоматический поиск альтернатив, то естественно что ручной поиск ничего не даст, и никаких сообщений о причинах отсутствия результатов не выведет. Также никаких сообщений о причинах отсутствия результатов поиска не будет если делать ручные поиски слишком часто. И разве хоть один Windows клиент выводит сообщение о причине?

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

С того же типа сети, DHT может найти по нодам нужный файл у какого-либо клиента DC++ с поддержкой DHT(а это все клиенты основанные на StrongDC++) причём поиск по нодам не ограничивается пользователями с текущего хаба, т.е. найденые источники возможно окажутся не с текущего хаба и соответственно скачивание будет идти не с локалки, а с интернета. Поэтому по умолчанию DHT поиск будет отключён чтобы не навредить пользователям на лимитных интернет тарифах.

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

ишь чего придумали :) а может оно вообще и без подключения к какому то хабу может работать? просто magnet/хэши с форумов брать (есть такие дополнения для движков). типа и торрент не нужен.

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

>а может оно вообще и без подключения к какому то хабу может работать?

возможно и сможет если переделать кое-что в ядре, по крайней мере подключение к хабу не требуется, для функционирования клиента в качесве узла в DHT сети, т.е. файл с нодами заполняется новыми нодами без хаба.

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

>>а может оно вообще и без подключения к какому то хабу может работать?

возможно и сможет если переделать кое-что в ядре, по крайней мере подключение к хабу не требуется, для функционирования клиента в качесве узла в DHT сети, т.е. файл с нодами заполняется новыми нодами без хаба.


Не возможно, а точно сможет.
Надо было сразу правильную ссылку давать:
http://www.adcportal.com/wiki/StrongDC++_DHT

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

Ссылку давал не я.

К тому же вопрос заключался в том можно ли будет просто кликнув по magnet-ссылке в браузере запустить EiskaltDC++ и чтобы он начал поиск через DHT, а затем и скачивание найденного файла, при условии что в автозгрузке нет ни одного хаба, и не подключаясь ни к одному хабу.

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

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

dmitriym-75 ()
Ответ на: комментарий от dmitriym-75

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

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

Да и эти 5 чуть ли не весь день кэшировало.

Это с какой же скоростью выполнялось хеширование? Даже если ограничить скорость хеширования до 10 мегабайт в секунду, то 5 гигабайт прохешируются меньше чем за 10 минут.

pavelvat ()
Ответ на: комментарий от dmitriym-75

Минутка политпросвещения

>Кэширование

Не надо путать хэширование и кэширование.

Кэш — промежуточный буфер с быстрым доступом, содержащий информацию, которая может быть запрошена с наибольшей вероятностью

Хэширование — преобразование входного массива данных произвольной длины в выходную битовую строку фиксированной длины. Такие преобразования также называются хеш-функциями или функциями свёртки, а их результаты называют хешем, хеш-кодом или дайджестом сообщения

Да и эти 5 чуть ли не весь день кэшировало


Как обладатель шары более терабайта, позволю себе усомниться в ваших словах.

redgremlin ★★★★★ ()
Ответ на: комментарий от dmitriym-75

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

вот прямо сейчас такая фигня. скорость хэширования 1.6 МиБ/с , 3% 303:55:XX осталось. ему гарантированно ничего не мешает.

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

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

не надо выдумывать. valknut и другие p2p хэшируют (причём быстро) и ничего не тормозит. а именно этот клиент тормозит всю систему.

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

> не надо выдумывать. valknut и другие p2p хэшируют (причём быстро) и ничего не тормозит. а именно этот клиент тормозит всю систему.

Телепатов тут нет. Конкретизируй особенности своей системы.
С какого раздела происходит хэширование? Какой стоит приоритет у процесса?
Изменялись ли дефолтные настройки хэширования? Если да, то как?

Может быть ты с нфс или самбы файлы хэшируешь с другого компа.
В этом случае есть некоторые особенности.

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

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

Конкретизируй особенности своей системы.

никаких особенностей нет. просто всё остальное, в том числе многочисленные p2p, в том числе работающие в Wine, не тормозят.

Изменялись ли дефолтные настройки хэширования? Если да, то как?

и не менялись. потом менялись. я писал ведь - снижал до 20 МиБс - всё тоже самое - тормозит систему.

Может быть ты с нфс или самбы файлы хэшируешь с другого компа.

нет, нет и нет. ничего такого нет.

Проблема у тебя какая-то локальная и с ней нужно разбираться.

у меня нет локальной проблемы и вообще никакой.

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

вот прямо сейчас такая фигня. скорость хэширования 1.6 МиБ/с , 3% 303:55:XX осталось. ему гарантированно ничего не мешает.

остановил. вышел из программы. вошел. продолжил - хешируют под 20 МиБс (как поставил в ограничениях), система адски тормозит - при написании этого текста система замирала несколько раз (GUI не отвечал)

tommy ★★★★ ()

С другой стороны, дискетами некоторые тоже пользуются... =)

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

система адски тормозит

Это тебе кара небесная за излишнюю любовь к CUE.

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

> вот прямо сейчас такая фигня. скорость хэширования 1.6 МиБ/с , 3% 303:55:XX осталось. ему гарантированно ничего не мешает.

подозреваю что ему мешает 12309 :)

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

> Добавлены новые команды чата: /ip (правила IPFilter), /ratio, /version

а у меня /version и в 2.2.2 есть.

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

>это gcc-4.6

tnx, it works! Еще бы разобраться как брандмауэр настроить правильно...

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