31 июля 2007 г.
Отпуск
Метки:
объявления
Те две недели, пока я в отпуске, можете писать мне на джаббер vonderer@radio-t.com. E-mail и icq те же.
29 июля 2007 г.
Все еще ковыряюсь с Я.ру
vondererlive добавился с первого раза, а этот блог мне добавляли админы ручками и при этом он очень криво собирался по rss. Попытки написать администрации Яndex результатов не дали.
25680257.b47f3f5fbfa22cb6dcd942986f9ed7fd.1201158195.1ee2906ea52a46cd44d896e0459df617
25680257.b47f3f5fbfa22cb6dcd942986f9ed7fd.1201158195.1ee2906ea52a46cd44d896e0459df617
28 июля 2007 г.
Почему XMPP? Часть 4. Безопасность и покой.
Метки:
безопасность,
идеология,
jabber
Последняя на сегодняшний день статья Aaron Toponce о Jabber.
Почему XMPP? Часть 4. Безопасность и покой.
Одним из самых насущных вопросов для людей, пользующихся проприетарными протоколами, является вопрос безопасности (например, шифрования), а вернее - ее отсутствия. XMPP с этой точки зрения превосходен, и, более того, продолжает развиваться в этом направлении.
Шифрование данных - одна из моих самых любимых тем. Я много раз писал о безопасности и давал много презентаций. Я не считаю себя экспертом, но вполне разбираюсь в этой теме, по крайней мере с тех пор, как в 2001 году создал свой GnuPG ключ. Поскольку шифрование данных является столь важной частью моей повседневной жизни, для меня важно использовать протокол, который поддерживает его нативно. Это еще одна причина тому, чтобы выбрать Jabber. Присмотримся получше и включим воображение.
Для начала, воображение. Представьте, что вы работаете на крупном предприятии. Вы используете icq для связи со своими коллегами и возможно даже клиентами. В течение дня вы спорите с коллегой о том, что он(а) делает, на ваш взгляд, неправильно. У нее к вам тоже есть аналогичные претензии. Постепенно вы приходите в праведный гнев и перестаете стесняться каких бы то ни было выражений. Вы ведь никогда не ладили с ним(с ней), и у него(нее) есть несколько друзей, которые хотят ему(ей) помочь любыми доступными способами. Зная о том, что сообщения icq передаются по сети открытым текстом, вы запускаете Wire Shark и отлавливаете все icq пакеты, наблюдая за его(ее) разговором с друзьями о вас. Да, вы сможете видеть весь текст после очистки TCP дампа.
Я не смирюсь со сниффингом пакетов в копоративной сети. Речь о том, что если вас поймают, то вас уволят (если, конечно, вы не из персонала IT). Но, урок есть урок. Используя доступные инструменты сниффинга пакетов, вы можете заполучить логины, пароли и целые разговоры по протоколам IM, которые не используют шифрования. В их числе MSN, AIM, icq, Yahoo! и большинство других. С моей точки зрения все, что передается без шифрования, есть дыра в безопасности. Итак, используя протоколы, которые не шифруют свой траффик, вы просто сами напрашиваетесь на неприятности.
И тут на сцене появляется Jabber. Когда появился XMPP, SSL был явлением первой важности. Каждый аккаунт Jabber, должен был быть соединен шифрованным потоком. Конечно же, изначально SSL использовался по умолчанию. Теперь, с появлением TLS, Jabber по умолчанию использует TLS. Некоторые сервера Jabber поддерживают и SSL, и TLS для максимальной обратной совместимости. В любом случае, вы можете быть уверены, что траффик между вами и сервером на 100% шифрован. Это означает, что сколько бы времени злоумышленник не пытался отловить пакеты с помощью сниффинга, он не сможет заполучить информацию аккаунта, пароль или содержание разговора.
К сожалению, шифрование производится дважды: на клиенте и на сервере. Это означает, что на компьютере пользователя и на сервере могут открытым текстом храниться логи разговоров. В качестве примера: если вы используете Gmail в качестве аккаунта Jabber, вы можете заглянуть во вкладку "Чаты" в веб-интерфейсе Gmail. По умолчанию, логи всех ваших бесед хранятся в вашем аккаунте Gmail (но при желании их можно отключить). Они хранятся открытым текстом после расшифровки их сервером. Меня, и, к счастью, команду разработчиков XMPP, это беспокоит. Почему мы не можем использовать механизм шифрования "клиент-клиент" вместо "клиент-сервер(-сервер)-клиент"? К счастью, в следующих релизах XMPP планируется поддержка такой функции. В любом случае, по проводам идет шифрованный поток и вы можете не беспокоиться насчет не в меру ретивых сотрудников, пытающихся сниффить ваши пакеты в надежде выведать, что же вы говорите о них друзьям. :)
Шифрованием данных никого не удивишь. Многие клиенты включают в себя различные плагины сторонних разработчиков, дающие возможность шифрования в режиме "клиент-клиент" вне зависимости от протокола. Я уже когда-то писал об этом, в надежде хотя бы на какое-то подобие стандарта в этой области. Однако, все эти инструменты просто шифруют текст сообщений, оставляя доступным IP в пакете. Представьте себе шифрование целого пакета "от и до", без единого нешифрованного байта. Именно к этой цели и стремятся разработчики XMPP.
Благодаря децентрализации XMPP, установка Jabber в локальной сети - это еще один способ достичь безопасности. Не только шифруя пакеты, но и изолируя их от внешней сети в принципе - о таком уровне безопасности многие даже и не мечтали! Используя проприетарные IM-сети, вы автоматически ставите себя в зависимость от двух вещей: Интернета и IM-провайдера. Установив на предприятии собственный сервер XMPP, вы получаете невероятно удобное положение: вам совсем не нужно подключение к Интернету и надежный внешний IM-провайдер. В этом случае именно вы держите штурвал в своих руках, и мне кажется, что такого уровня безопасности другими методами вам просто не достичь. Зачем рассылать пакеты по всему Интернету, если они все равно вернутся к вам на предприятие?
Надеюсь, что этот плюс в пользу XMPP убедит пользователей других IM-сетей перейти на Jabber и избавиться от своих проприетарных аккаунтов. Безопасность важна всегда, и почему другие сети до сих пор не занялись ею, остается для меня загадкой. Объединив сторонние плагины шифрования и внутреннюю корпоративную сеть, вы сделаете ваш сервер Jabber защищенным от ненужных глаз. Команда разработчиков XMPP занята усовершенствованием безопасности Jabber, поэтому мне кажется, что этот протокол должен стать единственным используемым всеми. Просто вглядитесь в возможности.
© Aaron Toponce, 'Why XMPP Part 4- Security Means Peace Of Mind', немного вольный перевод: vonderer.
PS. К слову сказать, в пользовательском соглашении icq черным по белому (или какими-то другими, но все равно довольно контрастными цветами) явно прописано примерно следующее: "пользователь icq отказывается от всех интеллектуальных прав на материал, переданный с помощью icq". Как люди после такого прямого заявления о том, что все, что они пишут, может быть на совершенно законных основаниях прочитано (а еще более меня раздражает, что об этом говорят напрямую, вероятно исходя из мнения "пользователь==идиот"), соглашаются и начинают этим пользоваться, мне до сих пор не понятно. Единственная причина, как мне кажется, - у нас, в России, никто не читает пользовательских соглашений, только флажки ставят - лишь бы быстрее начать писать.
Для пользователей beta.ya.ru, которая до сих пор отказывается адекватно работать с этим блогом, ЕЩЕ РАЗ пытаюсь добавить его в свой я.ру:
25680257.b47f3f5fbfa22cb6dcd942986f9ed7fd.1185645117.8a2a514dff43e029f67ece40af8234a5
Почему XMPP? Часть 4. Безопасность и покой.
Одним из самых насущных вопросов для людей, пользующихся проприетарными протоколами, является вопрос безопасности (например, шифрования), а вернее - ее отсутствия. XMPP с этой точки зрения превосходен, и, более того, продолжает развиваться в этом направлении.
Шифрование данных - одна из моих самых любимых тем. Я много раз писал о безопасности и давал много презентаций. Я не считаю себя экспертом, но вполне разбираюсь в этой теме, по крайней мере с тех пор, как в 2001 году создал свой GnuPG ключ. Поскольку шифрование данных является столь важной частью моей повседневной жизни, для меня важно использовать протокол, который поддерживает его нативно. Это еще одна причина тому, чтобы выбрать Jabber. Присмотримся получше и включим воображение.
Для начала, воображение. Представьте, что вы работаете на крупном предприятии. Вы используете icq для связи со своими коллегами и возможно даже клиентами. В течение дня вы спорите с коллегой о том, что он(а) делает, на ваш взгляд, неправильно. У нее к вам тоже есть аналогичные претензии. Постепенно вы приходите в праведный гнев и перестаете стесняться каких бы то ни было выражений. Вы ведь никогда не ладили с ним(с ней), и у него(нее) есть несколько друзей, которые хотят ему(ей) помочь любыми доступными способами. Зная о том, что сообщения icq передаются по сети открытым текстом, вы запускаете Wire Shark и отлавливаете все icq пакеты, наблюдая за его(ее) разговором с друзьями о вас. Да, вы сможете видеть весь текст после очистки TCP дампа.
Я не смирюсь со сниффингом пакетов в копоративной сети. Речь о том, что если вас поймают, то вас уволят (если, конечно, вы не из персонала IT). Но, урок есть урок. Используя доступные инструменты сниффинга пакетов, вы можете заполучить логины, пароли и целые разговоры по протоколам IM, которые не используют шифрования. В их числе MSN, AIM, icq, Yahoo! и большинство других. С моей точки зрения все, что передается без шифрования, есть дыра в безопасности. Итак, используя протоколы, которые не шифруют свой траффик, вы просто сами напрашиваетесь на неприятности.
И тут на сцене появляется Jabber. Когда появился XMPP, SSL был явлением первой важности. Каждый аккаунт Jabber, должен был быть соединен шифрованным потоком. Конечно же, изначально SSL использовался по умолчанию. Теперь, с появлением TLS, Jabber по умолчанию использует TLS. Некоторые сервера Jabber поддерживают и SSL, и TLS для максимальной обратной совместимости. В любом случае, вы можете быть уверены, что траффик между вами и сервером на 100% шифрован. Это означает, что сколько бы времени злоумышленник не пытался отловить пакеты с помощью сниффинга, он не сможет заполучить информацию аккаунта, пароль или содержание разговора.
К сожалению, шифрование производится дважды: на клиенте и на сервере. Это означает, что на компьютере пользователя и на сервере могут открытым текстом храниться логи разговоров. В качестве примера: если вы используете Gmail в качестве аккаунта Jabber, вы можете заглянуть во вкладку "Чаты" в веб-интерфейсе Gmail. По умолчанию, логи всех ваших бесед хранятся в вашем аккаунте Gmail (но при желании их можно отключить). Они хранятся открытым текстом после расшифровки их сервером. Меня, и, к счастью, команду разработчиков XMPP, это беспокоит. Почему мы не можем использовать механизм шифрования "клиент-клиент" вместо "клиент-сервер(-сервер)-клиент"? К счастью, в следующих релизах XMPP планируется поддержка такой функции. В любом случае, по проводам идет шифрованный поток и вы можете не беспокоиться насчет не в меру ретивых сотрудников, пытающихся сниффить ваши пакеты в надежде выведать, что же вы говорите о них друзьям. :)
Шифрованием данных никого не удивишь. Многие клиенты включают в себя различные плагины сторонних разработчиков, дающие возможность шифрования в режиме "клиент-клиент" вне зависимости от протокола. Я уже когда-то писал об этом, в надежде хотя бы на какое-то подобие стандарта в этой области. Однако, все эти инструменты просто шифруют текст сообщений, оставляя доступным IP в пакете. Представьте себе шифрование целого пакета "от и до", без единого нешифрованного байта. Именно к этой цели и стремятся разработчики XMPP.
Благодаря децентрализации XMPP, установка Jabber в локальной сети - это еще один способ достичь безопасности. Не только шифруя пакеты, но и изолируя их от внешней сети в принципе - о таком уровне безопасности многие даже и не мечтали! Используя проприетарные IM-сети, вы автоматически ставите себя в зависимость от двух вещей: Интернета и IM-провайдера. Установив на предприятии собственный сервер XMPP, вы получаете невероятно удобное положение: вам совсем не нужно подключение к Интернету и надежный внешний IM-провайдер. В этом случае именно вы держите штурвал в своих руках, и мне кажется, что такого уровня безопасности другими методами вам просто не достичь. Зачем рассылать пакеты по всему Интернету, если они все равно вернутся к вам на предприятие?
Надеюсь, что этот плюс в пользу XMPP убедит пользователей других IM-сетей перейти на Jabber и избавиться от своих проприетарных аккаунтов. Безопасность важна всегда, и почему другие сети до сих пор не занялись ею, остается для меня загадкой. Объединив сторонние плагины шифрования и внутреннюю корпоративную сеть, вы сделаете ваш сервер Jabber защищенным от ненужных глаз. Команда разработчиков XMPP занята усовершенствованием безопасности Jabber, поэтому мне кажется, что этот протокол должен стать единственным используемым всеми. Просто вглядитесь в возможности.
© Aaron Toponce, 'Why XMPP Part 4- Security Means Peace Of Mind', немного вольный перевод: vonderer.
PS. К слову сказать, в пользовательском соглашении icq черным по белому (или какими-то другими, но все равно довольно контрастными цветами) явно прописано примерно следующее: "пользователь icq отказывается от всех интеллектуальных прав на материал, переданный с помощью icq". Как люди после такого прямого заявления о том, что все, что они пишут, может быть на совершенно законных основаниях прочитано (а еще более меня раздражает, что об этом говорят напрямую, вероятно исходя из мнения "пользователь==идиот"), соглашаются и начинают этим пользоваться, мне до сих пор не понятно. Единственная причина, как мне кажется, - у нас, в России, никто не читает пользовательских соглашений, только флажки ставят - лишь бы быстрее начать писать.
Для пользователей beta.ya.ru, которая до сих пор отказывается адекватно работать с этим блогом, ЕЩЕ РАЗ пытаюсь добавить его в свой я.ру:
25680257.b47f3f5fbfa22cb6dcd942986f9ed7fd.1185645117.8a2a514dff43e029f67ece40af8234a5
24 июля 2007 г.
Обновления
Метки:
объявления,
blogger.com
Изменил дизайн на более читаемый и встроил "социальные" кнопки. В общем и целом готово, но детали еще будут правиться. Кроме прочего сократил число меток, уж больно много их было.
PS. Огромное спасибо Михаилу aka virens за очень полезные ссылки.
PS. Огромное спасибо Михаилу aka virens за очень полезные ссылки.
Qt клиенты для MPD
Как я и обещал, напишу о нескольких MPD клиентах на основе библиотек Qt. К сожалению, они менее популярны, чем GTK, поэтому клиентов мне попалось всего три (клиентов MPD на GTK и Java намного больше). И каждый из клиентов - по-своему интересен. Конечно, все клиенты так или иначе работают с одинаковыми функциями, таково уж ограничение mpd. Однако, в отношении графического оформления всего этого великолепия каждый разработчик может творить, как ему вздумается. Полный список клиентов со ссылками на них можно найти на официальном wiki проекта MPD. К сожалению, в репозитариях ubuntu не оказалось ни одного Qt-клиента для MPD. Все описанные ниже клиенты собирались мною. При сборке ни один компилятор не пострадал (однако, не забудьте, что наличие установленного пакета qt-apps-dev не повредит). :)
kmp
Первое слово, за которое зацепился глаз - kmp. Есть в этой букве K что-то притягательное для пользователя KDE, не находите? :) Итак, оформление крайне простое и винампоподобное. Несмотря на то, что фактически винамповых окон нету, сходство видно невооруженным глазом:
Плейлист и индекс папок/тегов не отличаются особой изящностью, но и глаза не режут. Все просто и удобно. Отдельно стоит отметить иконку в трее: она не только отображает статус, но при нажатии на нее средней клавишей, пользователь может приостановить воспроизведение. Кому-то может понравится. В общем, клиент прост и в меру удобен. Перейдем к более примечательным клиентам.
Quimup
Все гениальное - просто. Фраза старая и знакомая каждому. И, каждый из читателей может привести пример чего-нибудь гениального и простого. Вот и я приведу такой пример. Quimup - один из лучших клиентов MPD, с которыми я познакомился. Интерфейс главного окна все также интуитивно понятен, как и у kmp. Нажатие на кнопку "список" вызывает редактор плейлиста, а "молния" - опции. (К слову сказать, эта "молния" - символ этого клиента и... угадайте какого проигрывателя? ;) )
Однако, в окне помещается обложка альбома (или, после нажатия на нее - комментарии к дорожке, если mpd настроен на поддержку этой функции) и небольшой "светодиод", работающий как индикатор состояния (не соединен с сервером - красный, соединен, но простаивает - синий, соединен и играет - голубой, приостановлен - желтый). На иконке проигрывателя в трее такой же "светодиод", который смотрится аккуратно и стильно. По нажатии на него средней клавишей мыши проигрывание приостонавливается. Однако, особую ценность для меня представляет редактор плейлиста, который выполняет все мои требования к оному:
Отображать индекс можно либо по папкам, либо по исполнителю-альбому. Здесь же имеется один неприятный момент. Если в заголовках файла не указан альбом или исполнитель, то в индексе по исполнителю-альбому песня не отображается.
Кроме всего вышеозначенного, Quimup поддерживает запуск и выключение mpd вместе с клиентом, для этого нужно выставить необходимые настройки во вкладке 'Server'.
UPD: У меня в kubuntu 7.04 Quimup работает, к огромному сожалению, крайне нестабильно и вызывает зависание сервера.
QMPDClient
Другой, не менее замечательный клиент, QMPDClient, основан на библиотеках Qt4. Это самый "продвинутый из рассматриваемых здесь клиентов. Я думаю, скриншот проиллюстрирует мою последнюю фразу лучше всяких слов.
Музыкальные проигрыватели можно условно разделить на две категории: состоящие из отдельных окон и "монолитные", где плейлист, библиотека и элементы управления находятся в одном окне. QMPDClient относится именно к этой категории. В окне программы умещается все необходимое, включая вкладку для интернет-радио. Кроме того, на борту у этого клиента имеется несколько других интересных функций: отображение названия текущего трека во всплывающем окошке и "угадывание" заголовков по имени файла, а использование для него Qt4 дает результат в виде красивого рендеринга шрифтов.
В заключение
Возможность выбора клиента для mpd очень замечательна тем, что она соответствует самой идее свободного ПО: пользователь в праве выбирать то, что нравится ему, никто ничего не навязывает. Поэтому MPD идеологически правилен. Кроме всего прочего, если приспособиться, он чертовски удобен. Надеюсь, что статья оказалась полезна читателю, и помогла выбрать клиент для себя или просто узнать что-то новое. И я очень надеюсь, что в репозитариях Ubuntu появятся Qt-клиенты для MPD.
Конечно же, существует множество других клиентов: GTK2, Java или просто клиенты ввода с устройств. Если читателю будет угодно, я попытаюсь осветить некоторые из них позже. Спасибо за внимание. :)
kmp
Первое слово, за которое зацепился глаз - kmp. Есть в этой букве K что-то притягательное для пользователя KDE, не находите? :) Итак, оформление крайне простое и винампоподобное. Несмотря на то, что фактически винамповых окон нету, сходство видно невооруженным глазом:
Плейлист и индекс папок/тегов не отличаются особой изящностью, но и глаза не режут. Все просто и удобно. Отдельно стоит отметить иконку в трее: она не только отображает статус, но при нажатии на нее средней клавишей, пользователь может приостановить воспроизведение. Кому-то может понравится. В общем, клиент прост и в меру удобен. Перейдем к более примечательным клиентам.
Quimup
Все гениальное - просто. Фраза старая и знакомая каждому. И, каждый из читателей может привести пример чего-нибудь гениального и простого. Вот и я приведу такой пример. Quimup - один из лучших клиентов MPD, с которыми я познакомился. Интерфейс главного окна все также интуитивно понятен, как и у kmp. Нажатие на кнопку "список" вызывает редактор плейлиста, а "молния" - опции. (К слову сказать, эта "молния" - символ этого клиента и... угадайте какого проигрывателя? ;) )
Однако, в окне помещается обложка альбома (или, после нажатия на нее - комментарии к дорожке, если mpd настроен на поддержку этой функции) и небольшой "светодиод", работающий как индикатор состояния (не соединен с сервером - красный, соединен, но простаивает - синий, соединен и играет - голубой, приостановлен - желтый). На иконке проигрывателя в трее такой же "светодиод", который смотрится аккуратно и стильно. По нажатии на него средней клавишей мыши проигрывание приостонавливается. Однако, особую ценность для меня представляет редактор плейлиста, который выполняет все мои требования к оному:
Отображать индекс можно либо по папкам, либо по исполнителю-альбому. Здесь же имеется один неприятный момент. Если в заголовках файла не указан альбом или исполнитель, то в индексе по исполнителю-альбому песня не отображается.
Кроме всего вышеозначенного, Quimup поддерживает запуск и выключение mpd вместе с клиентом, для этого нужно выставить необходимые настройки во вкладке 'Server'.
UPD: У меня в kubuntu 7.04 Quimup работает, к огромному сожалению, крайне нестабильно и вызывает зависание сервера.
QMPDClient
Другой, не менее замечательный клиент, QMPDClient, основан на библиотеках Qt4. Это самый "продвинутый из рассматриваемых здесь клиентов. Я думаю, скриншот проиллюстрирует мою последнюю фразу лучше всяких слов.
Музыкальные проигрыватели можно условно разделить на две категории: состоящие из отдельных окон и "монолитные", где плейлист, библиотека и элементы управления находятся в одном окне. QMPDClient относится именно к этой категории. В окне программы умещается все необходимое, включая вкладку для интернет-радио. Кроме того, на борту у этого клиента имеется несколько других интересных функций: отображение названия текущего трека во всплывающем окошке и "угадывание" заголовков по имени файла, а использование для него Qt4 дает результат в виде красивого рендеринга шрифтов.
В заключение
Возможность выбора клиента для mpd очень замечательна тем, что она соответствует самой идее свободного ПО: пользователь в праве выбирать то, что нравится ему, никто ничего не навязывает. Поэтому MPD идеологически правилен. Кроме всего прочего, если приспособиться, он чертовски удобен. Надеюсь, что статья оказалась полезна читателю, и помогла выбрать клиент для себя или просто узнать что-то новое. И я очень надеюсь, что в репозитариях Ubuntu появятся Qt-клиенты для MPD.
Конечно же, существует множество других клиентов: GTK2, Java или просто клиенты ввода с устройств. Если читателю будет угодно, я попытаюсь осветить некоторые из них позже. Спасибо за внимание. :)
Music Player Daemon
В один прекрасный момент меня окончательно достала заторможенность amaroK, очень хорошего KDE'шного проигрывателя. Заторможенность, как мне показалось, вызвана встроенным файловом браузером, да и при добавлении в плейлист бедный amaroK каждый раз перечитывает теги тех композиций, которые когда-то ранее он уже проигрывал. Так часто упоминаемый мною MOC поглюкивал с ALSA-выводом звука и зашкаливал даже при нормальных настройках громкости. (Проблему я уже решил, но об этом в другой раз.) Поэтому я решил рискнуть и попробовать какой-нибудь другой проигрыватель. От проигрывателя мне требуется следующее: быстрота запуска и отклика, универсальность в поддержке форматов и простой и понятный интерфейс (по возможности - Qt3 или Qt4), включающий в себя максимально удобную интеграцию файлового браузера и плейлиста (собственно, как в MOC или amaroK), а так же, очень желательно, поддержку отправки статистики на last.fm. На этот раз, отказавшись от тучи различных вариантов (благо проигрывателей навалом), я остановился на Music Player Daemon.
Те, кто внимательно читал мои комментарии в этом блоге, могут удивиться - мне ведь раньше очень не нравился MPD. Мне всегда не нравилась одна его особенность: необходимость просканировать папки с музыкой прежде, чем он сможет эту музыку играть. Этакая "навязанная" JukeBox'овость, если позволите, мне не нравится и сейчас. Однако, в этом и "фишка" mpd. Объясню, почему. Как я уже написал выше, все проигрыватели со встроенными браузерами тормозят в двух местах: при чтении папок и при чтении заголовков музыкального файла. Тормозят независимо от того, используют ли они ncurses или Qt3. Однако, если вся эта информация уже проиндексирована и хранится в просто понимаемом проигрывателем файле, то скорость его работы резко возрастает. Добавьте к этому серверно-клиентскую работу, поддержку last.fm и возможность подключения различных клиентов, коих на просторах Интернета - десятки, на любой вкус. В общем, есть над чем задуматься.
Установка в ubuntu, как всегда, простая и непринужденная:
Если нужна поддержка last.fm, следует проделать и следующее:
И ответить на все вопросы.
После установки рекомендуется почитать man mpd, man mpd.conf и man mpdscribble. Если пользователь в системе один, рекомендуется настройки задавать в /etc/mpd.conf и /etc/mpdscribble.conf. Если несколько - в ~/.mpdconf и ~/.mpdscribble/.mpdscribble.conf. В манах это написано, но я здесь продублирую: очень полезно сделать симлинки папок с музыкой в уже указанной в конфиге папке - /var/lib/mpd/music. В остальном файл конфигурации прекрасно закомментирован и вполне доступен любому пользователю, знакомому с английским языком.
Перейдем к клиентам. Поскольку, как я уже сказал, их существует в избытке, я буду рассматривать их по частям. Начну с консольных. Вообще, мне известно всего лишь два: mpc - просто команда для дачи инструкции серверу и ncmpc - полноценный ncurses-клиент. К ознакомлению рекомендуются оба. Добываются способом, привычных нам с самых первых страниц этого блога:
Пара примеров использования mpc (допустим, вы уже добавили все необходимые симлинки в нужную папку, комментарии отделены двумя слэшами):
Очень подробная инструкция по использованию дана, как обычно, в man mpc. А я перейду к другому клиенту, особенно дорогому мне, как любителю MOC, скриншоты объяснят все куда красноречивее, чем слова.
На первом скриншоте - изначальное состояние окна. Мы видим уровень громкости, режим (r - повтор, x - режим ознакомления, z - режим вразнобой), плейлист, состояние воспроизведения. Клавиши 1-6 (F1-F6) переключают режимы: 1 - помощь, 2 - плейлист, 3 - навигация по папкам, 4 - навигация по тегам, 5 - поиск, 6 - часы.
В режиме помощи можно ознакомиться с горячими клавишами и даже назначить новые. Интерфейс прекрасно русифицирован. Управление покажется очень знакомым людям, часто пользующимся vim: с помощью клавиш j/k ведется навигация по папкам, плейлисту и даже помощи.
Навигация по папкам (да и по тегам) вполне стандартная - со времен mc более удобного способа еще не изобрели.
Вот так, теперь я пользуюсь проигрывателем, против которого так упорно выступал. И его главный минус - необходимость в предварительной индексации папок с музыкой, прекрасно компенсируется главным плюсом - быстротой работы.
В следующий раз, расскажу о нескольких иксовых клиентах. Спасибо за внимание. :)
PS. Music Player Daemon поддерживает работу только с UTF-8 заголовками mp3-файлов. Иначе говоря, прежде, чем вы сможете видеть кириллицу в заголовках большинства скачанных с интернета и не только файлов, вам потребуется перекодировать их заголовки в UTF-8, довольно подробное руководство можно найти в блоге ValehO.
Те, кто внимательно читал мои комментарии в этом блоге, могут удивиться - мне ведь раньше очень не нравился MPD. Мне всегда не нравилась одна его особенность: необходимость просканировать папки с музыкой прежде, чем он сможет эту музыку играть. Этакая "навязанная" JukeBox'овость, если позволите, мне не нравится и сейчас. Однако, в этом и "фишка" mpd. Объясню, почему. Как я уже написал выше, все проигрыватели со встроенными браузерами тормозят в двух местах: при чтении папок и при чтении заголовков музыкального файла. Тормозят независимо от того, используют ли они ncurses или Qt3. Однако, если вся эта информация уже проиндексирована и хранится в просто понимаемом проигрывателем файле, то скорость его работы резко возрастает. Добавьте к этому серверно-клиентскую работу, поддержку last.fm и возможность подключения различных клиентов, коих на просторах Интернета - десятки, на любой вкус. В общем, есть над чем задуматься.
Установка в ubuntu, как всегда, простая и непринужденная:
$ sudo aptitude install mpd
Если нужна поддержка last.fm, следует проделать и следующее:
$ sudo aptitude install mpdscribble
$ sudo dpkg-reconfigure mpdscribble
И ответить на все вопросы.
После установки рекомендуется почитать man mpd, man mpd.conf и man mpdscribble. Если пользователь в системе один, рекомендуется настройки задавать в /etc/mpd.conf и /etc/mpdscribble.conf. Если несколько - в ~/.mpdconf и ~/.mpdscribble/.mpdscribble.conf. В манах это написано, но я здесь продублирую: очень полезно сделать симлинки папок с музыкой в уже указанной в конфиге папке - /var/lib/mpd/music. В остальном файл конфигурации прекрасно закомментирован и вполне доступен любому пользователю, знакомому с английским языком.
Перейдем к клиентам. Поскольку, как я уже сказал, их существует в избытке, я буду рассматривать их по частям. Начну с консольных. Вообще, мне известно всего лишь два: mpc - просто команда для дачи инструкции серверу и ncmpc - полноценный ncurses-клиент. К ознакомлению рекомендуются оба. Добываются способом, привычных нам с самых первых страниц этого блога:
$ sudo aptitude install mpc ncmpc
Пара примеров использования mpc (допустим, вы уже добавили все необходимые симлинки в нужную папку, комментарии отделены двумя слэшами):
$ mpc update //обновим индекс
$ mpc ls //просмотрим корень индекса
$ mpc add path/to/file.mp3 //добавим файл в плейлист (автодополнение работает)
$ mpc play //запустим проигрывание
$ mpc //посмотрим статус проигрывания
Очень подробная инструкция по использованию дана, как обычно, в man mpc. А я перейду к другому клиенту, особенно дорогому мне, как любителю MOC, скриншоты объяснят все куда красноречивее, чем слова.
На первом скриншоте - изначальное состояние окна. Мы видим уровень громкости, режим (r - повтор, x - режим ознакомления, z - режим вразнобой), плейлист, состояние воспроизведения. Клавиши 1-6 (F1-F6) переключают режимы: 1 - помощь, 2 - плейлист, 3 - навигация по папкам, 4 - навигация по тегам, 5 - поиск, 6 - часы.
В режиме помощи можно ознакомиться с горячими клавишами и даже назначить новые. Интерфейс прекрасно русифицирован. Управление покажется очень знакомым людям, часто пользующимся vim: с помощью клавиш j/k ведется навигация по папкам, плейлисту и даже помощи.
Навигация по папкам (да и по тегам) вполне стандартная - со времен mc более удобного способа еще не изобрели.
Вот так, теперь я пользуюсь проигрывателем, против которого так упорно выступал. И его главный минус - необходимость в предварительной индексации папок с музыкой, прекрасно компенсируется главным плюсом - быстротой работы.
В следующий раз, расскажу о нескольких иксовых клиентах. Спасибо за внимание. :)
PS. Music Player Daemon поддерживает работу только с UTF-8 заголовками mp3-файлов. Иначе говоря, прежде, чем вы сможете видеть кириллицу в заголовках большинства скачанных с интернета и не только файлов, вам потребуется перекодировать их заголовки в UTF-8, довольно подробное руководство можно найти в блоге ValehO.
21 июля 2007 г.
BitTorrent клиенты на Qt
Метки:
BitTorrent,
KDE,
Qt
Небольшая предыстория. Раньше я редко пользовался BitTorrent-сетью. Когда я использовал СТРИМ, у меня был динамический, но собственный IP и я мог использовать на тот момент еще не прикрытую сеть eDonkey2000, поскольку был соединен с Интернетом напрямую. Чуть позже, когда у меня появилось подключение к локальной сети и я смог наконец начать использовать Linux (да, до этого у меня был программный ADSL-модем), я лишился возможности использовать eDonkey2000 и GNUtella из-за того, что в сети применяется Network Address Translation. Меня это не сильно расстроило, благо внутренних ресурсов хватает. Тогда я впервые попробовал воспользоваться локальным BitTorrent трекером и был благополучно забанен из-за того, что не знал, что такое трекер и ратио (проще говоря, скачал в несколько раз больше, чем раздал). И уже тогда я столкнулся с внешними трекерами (я стал увлекаться аниме, а не всякое аниме возможно было раздобыть в нашей сети).
Однако, вернусь к статье. В Linux я использовал в основном два BitTorrent клиента - KTorrent и qBitTorrent. В этой статье я приведу их плюсы и минусы. Начну с того, что после установки свежей версии kubuntu, мне потребовалось сразу использовать сеть BitTorrent, поэтому я сразу освещу один неочевидный плюс KTorrent - он поставляется вместе с KDE и для новичка очень просто сразу начать им пользоваться.
Итак, теперь к конкретике. Ниже приведены скриншоты основного окна KTorrent. (Прим.: панель меню вынесена в верхнюю панель рабочего стола à la MacOS, поэтому на скриншоте ее не видно.) Сразу видно, что информативность на очень высоком уровне. Особенно приятна вкладка "файлы", в которой мы можем наглядно ознакомиться со степенью выполнения задачи и структурой каталогов, попутно отмечая или снимая отметки с нужных и ненужных соответственно файлов "на лету".
В KTorrent встроено некое подобие поисковика. Это встроенное в KTorrent окно Konqueror'а, в котором загружается поисковая машина указанного пользователем трекера.
При добавлении торрента в закачки возникает окно, спрашивающее, куда положить файлы торрента, а также окно, предлагающее выбрать, какие файлы из закачки исключить:
О приятностях я рассказал, теперь о неприятном. И тут уже виной не оформление. При попытке добавления некоторых торрентов с разных трекеров вылезает сообщение "неправильный формат torrent-файла". А при попытке закачать другой торрент я столкнулся с тем, что KTorrent просто повис, а при последующих попытках загрузиться - благополучно вылетал до тех пор, пока я ручками не удалил этот торрент из его папки.
Теперь посмотрим на главное окно qBitTorrent. Первое, что бросается в глаза - это рендеринг шрифтов и красивое оформление. Да, это Qt4. Благодаря этому клиент очень красивый. И это, несомненно плюс. Теперь о приземленном. В отличии от KTorrent, информативность этого клиента страдает неполнотой. В главном окне у нас имеется список файлов и лог. Никакой вам подробной информации о доступности торрентов, ни возможности посмотреть структуру каталогов торрента.
Конечно, можно посмотреть подробную информацию о торренте, но никакой структуры каталогов мы здесь не увидим.
Вкладка "поиск" - очень заметна (в KTorrent она конечно тоже есть, но вынесена в не очень удачное место). Так что перейдем к ней. Замечательнейшая функция. Позволяет искать торренты прямо из клиента, при этом не подгружая никакие веб-страницы. Поиск ведется сразу в выбранных поисковиках. К сожалению, список поисковиков расширить невозможно - их стабильно четыре: Mininova, ThePirateBay, ISOhunt и Meganova. Впрочем, лично мне их хватает за глаза.
С добавлением торрентов та же проблема, что и с отображением информации о них. Структура каталогов просто не используется - мы тупо видим список файлов.
Я перешел на qBitTorrent совсем недавно и еще не сталкивался с тем, чтобы какой-то торрент отказался качаться. Очень надеюсь, что и не столкнусь.
UPD: Не столкнулся. qBitTorrent ест торренты, которые не принимает KTorrent. Засада в другом. Дело в том, что я попытался скачать файлов на 1 ГБ из торрента объемом в 16 ГБ. Нужные файлы он, конечно же скачал. Но при этом зарезервировал место на все 16 ГБ, забив его пустышками. Такой наглости я от такого замечательного клиента не ожидал. Поэтому оставлю его исключительно в качестве "саппорта" для KTorrent, который свободное место не забивает.
Подведем итоги.
KTorrent:
+ Информативность
+ Работа со структурой каталогов торрента
- Не самый удобный поиск
- Не самая лучшая совместимость с некоторыми торрентами
qBitTorrent:
+ Удобный поиск
+ Красивое оформление
- Непригоден для выкачивания неполных торрентов, ибо все равно забивает место "пустышками"
- Малая информативность
- Отсутствие работы со структурой каталогов
- Невозможность добавлять поисковые сервисы
PS. qBitTorrent отсутствует в репозитариях Ubuntu, о том, как его установить, написано на официальном сайте qBitTorrent.
Однако, вернусь к статье. В Linux я использовал в основном два BitTorrent клиента - KTorrent и qBitTorrent. В этой статье я приведу их плюсы и минусы. Начну с того, что после установки свежей версии kubuntu, мне потребовалось сразу использовать сеть BitTorrent, поэтому я сразу освещу один неочевидный плюс KTorrent - он поставляется вместе с KDE и для новичка очень просто сразу начать им пользоваться.
Итак, теперь к конкретике. Ниже приведены скриншоты основного окна KTorrent. (Прим.: панель меню вынесена в верхнюю панель рабочего стола à la MacOS, поэтому на скриншоте ее не видно.) Сразу видно, что информативность на очень высоком уровне. Особенно приятна вкладка "файлы", в которой мы можем наглядно ознакомиться со степенью выполнения задачи и структурой каталогов, попутно отмечая или снимая отметки с нужных и ненужных соответственно файлов "на лету".
В KTorrent встроено некое подобие поисковика. Это встроенное в KTorrent окно Konqueror'а, в котором загружается поисковая машина указанного пользователем трекера.
При добавлении торрента в закачки возникает окно, спрашивающее, куда положить файлы торрента, а также окно, предлагающее выбрать, какие файлы из закачки исключить:
О приятностях я рассказал, теперь о неприятном. И тут уже виной не оформление. При попытке добавления некоторых торрентов с разных трекеров вылезает сообщение "неправильный формат torrent-файла". А при попытке закачать другой торрент я столкнулся с тем, что KTorrent просто повис, а при последующих попытках загрузиться - благополучно вылетал до тех пор, пока я ручками не удалил этот торрент из его папки.
Теперь посмотрим на главное окно qBitTorrent. Первое, что бросается в глаза - это рендеринг шрифтов и красивое оформление. Да, это Qt4. Благодаря этому клиент очень красивый. И это, несомненно плюс. Теперь о приземленном. В отличии от KTorrent, информативность этого клиента страдает неполнотой. В главном окне у нас имеется список файлов и лог. Никакой вам подробной информации о доступности торрентов, ни возможности посмотреть структуру каталогов торрента.
Конечно, можно посмотреть подробную информацию о торренте, но никакой структуры каталогов мы здесь не увидим.
Вкладка "поиск" - очень заметна (в KTorrent она конечно тоже есть, но вынесена в не очень удачное место). Так что перейдем к ней. Замечательнейшая функция. Позволяет искать торренты прямо из клиента, при этом не подгружая никакие веб-страницы. Поиск ведется сразу в выбранных поисковиках. К сожалению, список поисковиков расширить невозможно - их стабильно четыре: Mininova, ThePirateBay, ISOhunt и Meganova. Впрочем, лично мне их хватает за глаза.
С добавлением торрентов та же проблема, что и с отображением информации о них. Структура каталогов просто не используется - мы тупо видим список файлов.
Я перешел на qBitTorrent совсем недавно и еще не сталкивался с тем, чтобы какой-то торрент отказался качаться. Очень надеюсь, что и не столкнусь.
UPD: Не столкнулся. qBitTorrent ест торренты, которые не принимает KTorrent. Засада в другом. Дело в том, что я попытался скачать файлов на 1 ГБ из торрента объемом в 16 ГБ. Нужные файлы он, конечно же скачал. Но при этом зарезервировал место на все 16 ГБ, забив его пустышками. Такой наглости я от такого замечательного клиента не ожидал. Поэтому оставлю его исключительно в качестве "саппорта" для KTorrent, который свободное место не забивает.
Подведем итоги.
KTorrent:
+ Информативность
+ Работа со структурой каталогов торрента
- Не самый удобный поиск
- Не самая лучшая совместимость с некоторыми торрентами
qBitTorrent:
+ Удобный поиск
+ Красивое оформление
- Непригоден для выкачивания неполных торрентов, ибо все равно забивает место "пустышками"
- Малая информативность
- Отсутствие работы со структурой каталогов
- Невозможность добавлять поисковые сервисы
PS. qBitTorrent отсутствует в репозитариях Ubuntu, о том, как его установить, написано на официальном сайте qBitTorrent.
file+cuesheet, практичное решение
Согласитесь, один альбом в связке файл+cuesheet - штука крайне неудобная. Нет, конечно для нарезания на болванку разницы нету. Но в каждодневной эксплуатации такая связка неудобна по двум причинам: отдельный трэк невозможно добавить в плейлист - надо добавлять сначала весь альбом, а потом убирать из плейлиста ненужные трэки. Это в целом. А вот у пользователей Linux есть вторая, не менее серьезная причина - в Linux в принципе нету проигрывателя, способного использовать связку file+cuesheet. Значит, гораздо удобнее будет разбить один целый файл на несколько маленьких - отдельных трэков. Чем мы и займемся. Итак:
Дано: связка file+cuesheet, являющаяся lossless (или lossy - тут уж без разницы) рипом какого-нибудь аудио компакт-диска.
Задача: разбить этот рип на отдельные трэки.
Решение:
Поскольку задача сформулирована в общем плане, придадим ей немного конкретики удобства ради. Альбомы, пожатые в lossy-формат (всякие ogg, mp3, aac, wma и им подобные) в один файл в сопровождении cue-списка, мне ни разу не попадались, да и кому такой изврат нужен? А вот в lossless (например, flac, ape, wavpack) такое - сплошь и рядом. Поэтому будем изначально ориентироваться на выходные файлы в формате FLAC, как на идеологически правильные и широкоподдерживаемые на всех платформах. А вот поступать к нам будут файлы разных форматов, но скорее всего - ape/wavpack/flac. Поэтому во время установки необходимых пакетов будем исходить из заданных условий.
Теперь непосредственно к решению задачи. У нас есть два пути: использовать bchunk, предварительно раскодировав файл в wav и получив на выходе wav-файлы, которые потом надо будет кодировать в нужный формат, или не тратить наше драгоценное время и работать с файлом напрямую с помощью shntools. Поразмыслив, можно придти к выводу, что второй вариант куда удобнее. Им мы и воспользуемся.
Для начала установим все необходимое. Если хотим подружить систему с Monkey's Audio, то в /etc/apt/sources.list добавляем следующую строку:
И ставим необходимые кодеки и софт:
Теперь - самое интересное. Будем кромсать файл. Допустим, имеются у нас некоторые filename.ape и filename.cue. Натянем резиновые перчатки и возьмем в руки скальпель... Хорошо, а теперь:
Начнется процесс в итоге, в каталоге, в котором мы проводим эти жуткие эксперименты, получим следующее: подопытные файлы остались нетронутыми, а кроме них в этой папке лежат n файлов, которые называются 'split-track001.flac', 'split-track002.flac', 'split-track003.flac'... 'split-trackn.flac'. Вот они-то и есть результат нашей беспощадной деятельности. Итак, файлы мы разрезали, пробуем открыть - да, друзья мои, еще не все. Свеженарезанные файлы не имеют заголовков. Займемся ими. На этот случай у нас припасен скрипт cuetag.
Неудобно? Тогда поступим проще:
Он пожалуется на несколько ошибок из-за специфики заголовков FLAC (–remove-vc-all и –import-vc-from). Проверяем, и - вуаля! - все свеженарезанные файлы обзавелись заголовками в соответствии с cue-файлом.
Надо бы упростить задачу, а то приходится производить слишком много лишних телодвижений, вы не находите? Перефразируя одно известное высказывание: "Линуксоид - человек ленивый. Он обязательно приложит максимум усилий чтобы в последствии не напрягаться." Тогда приступим к написанию скрипта. После нескольких попыток, у меня получилось таки создать нечто похожее. :)
Здесь следует отметить, что хоть и создание временной копии cuesheet'а совершенно необязательно (команды cp "$2" tmp.cue и rm tmp.cue), ее все равно лучше сделать. Почему-то скрипт cuetag не работает с пробелами в названиях файлов, даже если название этого файла заключено в кавычки. По этой же причине я бы не рекомендовал использовать при генерации отдельных файлов префикс, содержащий пробел или другие спецсимволы. После того, как вы сделаете этот скрипт, команда
сделает все за вас - вам следует только не перепутать cue и файл с записью местами и "откинуться на спинку стула". Если вы хотите изменить префикс файлов на выходе или задать им папку - всегда пожалуйста. Для этого почитайте маны и поправьте скрипт по своему вкусу.
К сожалению, я так и не нашел способа автоматизировать процесс переименования готовых файлов исходя из их тегов. Поэтому предлагаю делать это ручками. По крайней мере, команда
хоть немного поможет вам в этом.
Спасибо за внимание. Статья была написана на основе статьи aidanjm под названием Split lossless audio (ape, flac, wv, wav) by cue file in Ubuntu.
Дано: связка file+cuesheet, являющаяся lossless (или lossy - тут уж без разницы) рипом какого-нибудь аудио компакт-диска.
Задача: разбить этот рип на отдельные трэки.
Решение:
Поскольку задача сформулирована в общем плане, придадим ей немного конкретики удобства ради. Альбомы, пожатые в lossy-формат (всякие ogg, mp3, aac, wma и им подобные) в один файл в сопровождении cue-списка, мне ни разу не попадались, да и кому такой изврат нужен? А вот в lossless (например, flac, ape, wavpack) такое - сплошь и рядом. Поэтому будем изначально ориентироваться на выходные файлы в формате FLAC, как на идеологически правильные и широкоподдерживаемые на всех платформах. А вот поступать к нам будут файлы разных форматов, но скорее всего - ape/wavpack/flac. Поэтому во время установки необходимых пакетов будем исходить из заданных условий.
Теперь непосредственно к решению задачи. У нас есть два пути: использовать bchunk, предварительно раскодировав файл в wav и получив на выходе wav-файлы, которые потом надо будет кодировать в нужный формат, или не тратить наше драгоценное время и работать с файлом напрямую с помощью shntools. Поразмыслив, можно придти к выводу, что второй вариант куда удобнее. Им мы и воспользуемся.
Для начала установим все необходимое. Если хотим подружить систему с Monkey's Audio, то в /etc/apt/sources.list добавляем следующую строку:
deb http://morgoth.free.fr/ubuntu feisty-backports main
И ставим необходимые кодеки и софт:
$ sudo aptitude update
$ sudo aptitude install flac wavpack monkeys-audio shntool cuetools
Теперь - самое интересное. Будем кромсать файл. Допустим, имеются у нас некоторые filename.ape и filename.cue. Натянем резиновые перчатки и возьмем в руки скальпель... Хорошо, а теперь:
$ cuebreakpoints filename.cue | shnsplit -o flac filename.ape
Начнется процесс в итоге, в каталоге, в котором мы проводим эти жуткие эксперименты, получим следующее: подопытные файлы остались нетронутыми, а кроме них в этой папке лежат n файлов, которые называются 'split-track001.flac', 'split-track002.flac', 'split-track003.flac'... 'split-trackn.flac'. Вот они-то и есть результат нашей беспощадной деятельности. Итак, файлы мы разрезали, пробуем открыть - да, друзья мои, еще не все. Свеженарезанные файлы не имеют заголовков. Займемся ими. На этот случай у нас припасен скрипт cuetag.
$ cuetag filename.cue split-track001.flac split-track002.flac ... split-trackn.flac
Неудобно? Тогда поступим проще:
$ cuetag filename.cue `ls split-track*.flac`
Он пожалуется на несколько ошибок из-за специфики заголовков FLAC (–remove-vc-all и –import-vc-from). Проверяем, и - вуаля! - все свеженарезанные файлы обзавелись заголовками в соответствии с cue-файлом.
Надо бы упростить задачу, а то приходится производить слишком много лишних телодвижений, вы не находите? Перефразируя одно известное высказывание: "Линуксоид - человек ленивый. Он обязательно приложит максимум усилий чтобы в последствии не напрягаться." Тогда приступим к написанию скрипта. После нескольких попыток, у меня получилось таки создать нечто похожее. :)
$ sudo vim /usr/local/bin/cue2flac.sh
#!/bin/sh
cuebreakpoints "$1" | shnsplit -o flac "$2"
cp "$1" tmp.cue
cuetag tmp.cue `ls split-track*.flac`
rm tmp.cue
$ sudo chmod 755 /usr/local/bin/cue2flac.sh
Здесь следует отметить, что хоть и создание временной копии cuesheet'а совершенно необязательно (команды cp "$2" tmp.cue и rm tmp.cue), ее все равно лучше сделать. Почему-то скрипт cuetag не работает с пробелами в названиях файлов, даже если название этого файла заключено в кавычки. По этой же причине я бы не рекомендовал использовать при генерации отдельных файлов префикс, содержащий пробел или другие спецсимволы. После того, как вы сделаете этот скрипт, команда
$ cue2flac.sh "filename.cue" "filename.ape"
сделает все за вас - вам следует только не перепутать cue и файл с записью местами и "откинуться на спинку стула". Если вы хотите изменить префикс файлов на выходе или задать им папку - всегда пожалуйста. Для этого почитайте маны и поправьте скрипт по своему вкусу.
К сожалению, я так и не нашел способа автоматизировать процесс переименования готовых файлов исходя из их тегов. Поэтому предлагаю делать это ручками. По крайней мере, команда
$ grep TITLE filename.cue
хоть немного поможет вам в этом.
Спасибо за внимание. Статья была написана на основе статьи aidanjm под названием Split lossless audio (ape, flac, wv, wav) by cue file in Ubuntu.
18 июля 2007 г.
Почему XMPP? Часть 3. Децентрализация - вот в чем соль.
Продолжаю перевод цикла статей. Приятного прочтения.
Почему XMPP? Часть 3. Децентрализация - вот в чем соль.
Если вы следите за моими постами, повествующими, почему же XMPP/Jabber лучше, чем все остальные проприетарные протоколы, вы, скорее всего, уже начали понимать, почему же Jabber - король мгновенных сообщений. Нижеприведенная статья расскажет, почему же корона принадлежит Jabber.
Для начала, я хочу, чтобы вы задумались на минуту: когда вы отправляете электронную почту вашему другу, разве вы можете посылать ее только на почтовый ящик того же провайдера, что и ваш? Иными словами, разве, пользуясь Gmail, вы можете посылать сообщения только другим пользователям Gmail? Конечно нет! Это же глупо. Вы можете посылать e-mail другим людям независимо от того, каким почтовым провайдером они пользуются, будь это Yahoo!, Hotmail или сервер какой-то фирмы, а они могут отвечать и пересылать письма вам. Тогда у меня есть вопрос: почему провайдеры IM-систем заставляют вас общаться только со своими пользователями? Почему пользователи MSN могут отправлять сообщения только пользователям MSN? Почему пользователи Yahoo! могут отправлять сообщения только пользователям Yahoo!? AIM? ICQ? Видите? Проблема в том, что только пользователи MSN могут подключаться к "официальным" серверам MSN. То же самое и с остальными. Коммерческие IM-провайдеры попросту "запирают" пользователей в своих сетях.
Нечестно, не правда ли? У меня есть родственники, у которых есть только MSN-аккаунты, таким образом, они могут общаться только с другими пользователями MSN. Это неудобно, потому что я не собираюсь использовать проприетарные IM-протоколы, таким образом, я не могу общаться с ними, если у них нету аккаунтов Jabber (хотя, у некоторых есть). Однако я могу спокойно отправлять им электронную почту. Система e-mail абсолютно децентрализована, а IM-системы - нет. Jabber решает эту проблему. А значит, мои родственники могут использовать Jabber-аккаунты Gmail, в то время как у меня есть свой домашний сервер и я могу общаться с ними без проблем. По правде говоря, если бы вы могли увидеть мой ростер, вы бы заметили, что большинство моих контактов используют Gmail, хотя есть среди них и пользователи LiveJournal, и пользователи jabber.org, и несколько пользователей собственных домашних серверов. Разве это не прекрасно? Независимо от провайдера Jabber, я могу общаться со всеми.
Волшебство децентрализации заключается в службе, которая называется 'server-to-server'. Когда я регистрирую аккаунт, например на jabber.org, я могу добавлять в свой контакт-лист кого угодно, независимо от провайдера. Во время аутентификации мой провайдер (jabber.org) соединяется с провайдером другого пользователя (использующего например gmail.com) и запрашивает информацию о пользователе. Его IM-провайдер уведомляет его об аутентификации, и, если пользователь соглашается, его провайдер соединяется с моим и сообщает ему, что "все OK", и пользователь добавляется в мой ростер. Задумайтесь. Один сервер общается с другим сервером, даже вне домена. Способен ли MSN на такое? Yahoo!? AIM? ICQ? Естественно, нет.
Я знаю, что подумают об этом те, кто пользуется проприетарными IM-протоколами. Даже при том, что Jabber децентрализован, вы можете получать сообщения только от пользователей Jabber, то есть Jabber, по сути, тоже "закрыт". Вы не можете отправлять сообщения пользователям MSN или ICQ - только другим пользователям Jabber. Да, это так, но это не вина Jabber, скорее наоборот. MSN и ICQ противостоят соединению Jabber с их серверами. Подумайте над этим: у вас есть аккаунт Gmail, и вы отправляете письмо пользователю Hotmail. Возникает окошко, которое говорит вам о том, что вы не являетесь пользователем Hotmail, поэтому вы не можете отправлять почту другим пользователям Hotmail. Представьте себе, как это кощунственно. Система e-mail децентрализована, но Hotmail хочет "запереть" своих пользователей. Примерно такая же игра ведется среди IM. Jabber решил проблему "запирания" пользователей, открыв спецификации и сделав IM децентрализованным, однако другие провайдеры отказались поступить подобным образом. Поэтому, в настоящее время, вы можете отправлять сообщения только другим пользователям Jabber, но мне кажется, с учетом растущей популярности Jabber, что долго такая ситуация не продлится.
Когда я услышал о том, что Jabber децентрализован, я был поражен и заинтересован. Мне казалось, что это откроет путь к развитию IM, и если другие провайдеры не присоединятся, они разделят судьбу Титаника. Оказалось, что не казалось. С момента появления Jabber, если верить Википедии, он стал вторым по популярности после AOL (прим. пер.: однако, в силу децентрализации Jabber, никто никогда не сможет узнать точное количество пользователей Jabber :) ). На сегодняшний день количество пользователей Jabber оценивается почти в 90 миллионов. То есть, каждый третий IM-аккаунт - аккаунт Jabber. Я думаю, что постепенно все больше и больше пользователей будет как я переходить на Jabber, что в конце концов выкопает могилу его проприетарным аналогам. Было бы прекрасно, если бы существовала абсолютно децентрализованная IM-система, такая же, как e-mail, не правда ли? Я надеюсь, что мои статьи об XMPP (Прим. пер.: и мои переводы этих статей ;) ) убедят вас, дорогие читатели, что XMPP/Jabber - лучший среди аналогов, и вы зарегистрируете собственные Jabber-аккаунты у того провайдера, которого выберете сами.
© Aaron Toponce, 'Why XMPP Part 3- Decentralization Is Key', немного вольный перевод: vonderer.
PS. В комментариях к оригиналу этой статьи фигурирует одна очень интересная ссылка на статью о неудачной попытке создания возможности для пользователей MSN и Yahoo! общаться с пользователями AIM, благополучно задавленной AOL'ом. AOL blocks Microsoft Net messaging от 23 июля далекого 1999 года.
Почему XMPP? Часть 3. Децентрализация - вот в чем соль.
Если вы следите за моими постами, повествующими, почему же XMPP/Jabber лучше, чем все остальные проприетарные протоколы, вы, скорее всего, уже начали понимать, почему же Jabber - король мгновенных сообщений. Нижеприведенная статья расскажет, почему же корона принадлежит Jabber.
Для начала, я хочу, чтобы вы задумались на минуту: когда вы отправляете электронную почту вашему другу, разве вы можете посылать ее только на почтовый ящик того же провайдера, что и ваш? Иными словами, разве, пользуясь Gmail, вы можете посылать сообщения только другим пользователям Gmail? Конечно нет! Это же глупо. Вы можете посылать e-mail другим людям независимо от того, каким почтовым провайдером они пользуются, будь это Yahoo!, Hotmail или сервер какой-то фирмы, а они могут отвечать и пересылать письма вам. Тогда у меня есть вопрос: почему провайдеры IM-систем заставляют вас общаться только со своими пользователями? Почему пользователи MSN могут отправлять сообщения только пользователям MSN? Почему пользователи Yahoo! могут отправлять сообщения только пользователям Yahoo!? AIM? ICQ? Видите? Проблема в том, что только пользователи MSN могут подключаться к "официальным" серверам MSN. То же самое и с остальными. Коммерческие IM-провайдеры попросту "запирают" пользователей в своих сетях.
Нечестно, не правда ли? У меня есть родственники, у которых есть только MSN-аккаунты, таким образом, они могут общаться только с другими пользователями MSN. Это неудобно, потому что я не собираюсь использовать проприетарные IM-протоколы, таким образом, я не могу общаться с ними, если у них нету аккаунтов Jabber (хотя, у некоторых есть). Однако я могу спокойно отправлять им электронную почту. Система e-mail абсолютно децентрализована, а IM-системы - нет. Jabber решает эту проблему. А значит, мои родственники могут использовать Jabber-аккаунты Gmail, в то время как у меня есть свой домашний сервер и я могу общаться с ними без проблем. По правде говоря, если бы вы могли увидеть мой ростер, вы бы заметили, что большинство моих контактов используют Gmail, хотя есть среди них и пользователи LiveJournal, и пользователи jabber.org, и несколько пользователей собственных домашних серверов. Разве это не прекрасно? Независимо от провайдера Jabber, я могу общаться со всеми.
Волшебство децентрализации заключается в службе, которая называется 'server-to-server'. Когда я регистрирую аккаунт, например на jabber.org, я могу добавлять в свой контакт-лист кого угодно, независимо от провайдера. Во время аутентификации мой провайдер (jabber.org) соединяется с провайдером другого пользователя (использующего например gmail.com) и запрашивает информацию о пользователе. Его IM-провайдер уведомляет его об аутентификации, и, если пользователь соглашается, его провайдер соединяется с моим и сообщает ему, что "все OK", и пользователь добавляется в мой ростер. Задумайтесь. Один сервер общается с другим сервером, даже вне домена. Способен ли MSN на такое? Yahoo!? AIM? ICQ? Естественно, нет.
Я знаю, что подумают об этом те, кто пользуется проприетарными IM-протоколами. Даже при том, что Jabber децентрализован, вы можете получать сообщения только от пользователей Jabber, то есть Jabber, по сути, тоже "закрыт". Вы не можете отправлять сообщения пользователям MSN или ICQ - только другим пользователям Jabber. Да, это так, но это не вина Jabber, скорее наоборот. MSN и ICQ противостоят соединению Jabber с их серверами. Подумайте над этим: у вас есть аккаунт Gmail, и вы отправляете письмо пользователю Hotmail. Возникает окошко, которое говорит вам о том, что вы не являетесь пользователем Hotmail, поэтому вы не можете отправлять почту другим пользователям Hotmail. Представьте себе, как это кощунственно. Система e-mail децентрализована, но Hotmail хочет "запереть" своих пользователей. Примерно такая же игра ведется среди IM. Jabber решил проблему "запирания" пользователей, открыв спецификации и сделав IM децентрализованным, однако другие провайдеры отказались поступить подобным образом. Поэтому, в настоящее время, вы можете отправлять сообщения только другим пользователям Jabber, но мне кажется, с учетом растущей популярности Jabber, что долго такая ситуация не продлится.
Когда я услышал о том, что Jabber децентрализован, я был поражен и заинтересован. Мне казалось, что это откроет путь к развитию IM, и если другие провайдеры не присоединятся, они разделят судьбу Титаника. Оказалось, что не казалось. С момента появления Jabber, если верить Википедии, он стал вторым по популярности после AOL (прим. пер.: однако, в силу децентрализации Jabber, никто никогда не сможет узнать точное количество пользователей Jabber :) ). На сегодняшний день количество пользователей Jabber оценивается почти в 90 миллионов. То есть, каждый третий IM-аккаунт - аккаунт Jabber. Я думаю, что постепенно все больше и больше пользователей будет как я переходить на Jabber, что в конце концов выкопает могилу его проприетарным аналогам. Было бы прекрасно, если бы существовала абсолютно децентрализованная IM-система, такая же, как e-mail, не правда ли? Я надеюсь, что мои статьи об XMPP (Прим. пер.: и мои переводы этих статей ;) ) убедят вас, дорогие читатели, что XMPP/Jabber - лучший среди аналогов, и вы зарегистрируете собственные Jabber-аккаунты у того провайдера, которого выберете сами.
© Aaron Toponce, 'Why XMPP Part 3- Decentralization Is Key', немного вольный перевод: vonderer.
PS. В комментариях к оригиналу этой статьи фигурирует одна очень интересная ссылка на статью о неудачной попытке создания возможности для пользователей MSN и Yahoo! общаться с пользователями AIM, благополучно задавленной AOL'ом. AOL blocks Microsoft Net messaging от 23 июля далекого 1999 года.
17 июля 2007 г.
Почему XMPP? Часть 2. Сберегая ресурсы.
Я продолжаю перевод цикла статей "Почему XMPP?", написанных Aaron Toponece.
Почему XMPP? Часть 2. Сберегая ресурсы.
Я пытаюсь давать своим постам названия поинтереснее. Боюсь, у меня не всегда это получается.
В моем предыдущем посте, посвященном XMPP, я говорил о приоритетах, функции №1, которая интересует меня в Jabber-клиенте. Если я не могу изменить значение приоритета на то, которое мне необходимо, то такой клиент мне неинтересен. Хоть приоритеты рулят и педалят, но они бессмысленны без другой функции Jabber - ресурсов.
Как я уже говорил раньше, спецификации XMPP поддерживают множественное подключение. Однако, когда мы подключаемся к нашему аккаунту больше одного раза, серверу необходим способ различия соединений. Для этих целей и существуют ресурсы. Некоторые провайдеры автоматически выставляют уникальные ресурсы. Однако, хоть это и является удачным решением, мне больше нравится устанавливать ресурс собственноручно. Итак, я хочу изменить ресурс, но почему?
Вне зависимости от клиента процесс прост. При создании нового аккаунта или изменения существующего, в окне обычно есть поле, которое называется "Ресурс". Заполните его таким образом, чтобы значение соответствовало вашим нуждам. Выше я писал, что серверу необходимо различать между собой ваши подключения, поэтому ресурсы должны быть уникальными (прим. пер.: в рамках вашего аккаунта, конечно же - в клиенте у некоего дяди Васи может стоять такой же ресурс как и у вас, и никому это не навредит). Если вы попытаетесь подключить клиент, и у вас это не удастся - проверьте ресурс. Скорее всего, соединение с таким же ресурсом уже установлено.
Большинство клиентов автоматически заполняют это поле. Для Gajim умолчательное значение - 'Gajim', для CenterICQ - 'centericq', для Bitlbee (несложно догадаться) - 'bitlbee'. Я уже писал, что предпочитаю указывать тот ресурс, который подходит ситуации. Посмотрите на приведенный ниже скриншот Gajim:
Как я уже говорил, некоторые сервера устанавливают ваш ресурс сами, не давая вам его изменить, или вам кажется, что ресурс устанавливаете вы, а сервер генерирует случайный набор символов, именуемый хэшем, и добавляет его после вашего ресурса. Например, разработчики Google Talk использовали этот прием для того, чтобы ресурс пользователя был уникальным при каждом подключении независимо от того, какой ресурс задал пользователь. Причина такого решения в том, что пользователь может не разбираться в ресурсах и приоритетах, поэтому он оставит в поле "ресурс" умолчательное значение, заданное клиентом. Однако пользователям, которые знают, что они делают, это может мешать. Например, мне нужна возможность изменять мои ресурс и приоритет так, как я этого хочу, поэтому я не использую Jabber на Gmail.com.
Зачем менять ресурс? В чем "фишка"? Ну, с одной стороны нам нужны уникальные названия для каждого соединения. С другой стороны, использование ресурса может помочь вам в информировании пользователей в вашем ростере (прим. пер. для пользователей ICQ: контакт-лист Jabber'а называется roster) о вашем текущем местоположении, например 'Home', 'Work', 'School', о вашей текущей операционной системе, например 'Mac' или 'Linux', или о сервере, на котором установлен клиент, например 'hercules' или 'athena'. Всегда может возникнуть новый повод обозначить свой ресурс. Почему нужна возможность изменять его? Потому что она у вас есть.
В сочетании с приоритетами, эта функция может стать прекрасной причиной перейти с вашего старого проприетарного IM-протокола на Jabber. XMPP дает вам бóльшую гибкость, необходимую для постоянного присутствия в сети, нежели использование бестолкового клиента в сочетании с бестолковой же службой в надежде на лучшее. Как я недавно узнал, AIM поддерживает множественные подключения, но когда кто-то шлет вам сообщение, оно приходит на все подключенные клиенты. По-моему, это нерационально. Тем более, что XMPP/Jabber справляется с подобной ситуацией столь элегантно.
Мы только что достигли вершины айсберга. Существует еще много причин перейти на Jabber, чем вы можете предположить, и я собираюсь рассказать обо всех, в надежде, что вы увидите причину перейти на лучший IM протокол в мире.
© Aaron Toponce, 'Why XMPP Part 2- Saving Your Resources', немного вольный перевод: vonderer.
Почему XMPP? Часть 2. Сберегая ресурсы.
Я пытаюсь давать своим постам названия поинтереснее. Боюсь, у меня не всегда это получается.
В моем предыдущем посте, посвященном XMPP, я говорил о приоритетах, функции №1, которая интересует меня в Jabber-клиенте. Если я не могу изменить значение приоритета на то, которое мне необходимо, то такой клиент мне неинтересен. Хоть приоритеты рулят и педалят, но они бессмысленны без другой функции Jabber - ресурсов.
Как я уже говорил раньше, спецификации XMPP поддерживают множественное подключение. Однако, когда мы подключаемся к нашему аккаунту больше одного раза, серверу необходим способ различия соединений. Для этих целей и существуют ресурсы. Некоторые провайдеры автоматически выставляют уникальные ресурсы. Однако, хоть это и является удачным решением, мне больше нравится устанавливать ресурс собственноручно. Итак, я хочу изменить ресурс, но почему?
Вне зависимости от клиента процесс прост. При создании нового аккаунта или изменения существующего, в окне обычно есть поле, которое называется "Ресурс". Заполните его таким образом, чтобы значение соответствовало вашим нуждам. Выше я писал, что серверу необходимо различать между собой ваши подключения, поэтому ресурсы должны быть уникальными (прим. пер.: в рамках вашего аккаунта, конечно же - в клиенте у некоего дяди Васи может стоять такой же ресурс как и у вас, и никому это не навредит). Если вы попытаетесь подключить клиент, и у вас это не удастся - проверьте ресурс. Скорее всего, соединение с таким же ресурсом уже установлено.
Большинство клиентов автоматически заполняют это поле. Для Gajim умолчательное значение - 'Gajim', для CenterICQ - 'centericq', для Bitlbee (несложно догадаться) - 'bitlbee'. Я уже писал, что предпочитаю указывать тот ресурс, который подходит ситуации. Посмотрите на приведенный ниже скриншот Gajim:
Как я уже говорил, некоторые сервера устанавливают ваш ресурс сами, не давая вам его изменить, или вам кажется, что ресурс устанавливаете вы, а сервер генерирует случайный набор символов, именуемый хэшем, и добавляет его после вашего ресурса. Например, разработчики Google Talk использовали этот прием для того, чтобы ресурс пользователя был уникальным при каждом подключении независимо от того, какой ресурс задал пользователь. Причина такого решения в том, что пользователь может не разбираться в ресурсах и приоритетах, поэтому он оставит в поле "ресурс" умолчательное значение, заданное клиентом. Однако пользователям, которые знают, что они делают, это может мешать. Например, мне нужна возможность изменять мои ресурс и приоритет так, как я этого хочу, поэтому я не использую Jabber на Gmail.com.
Зачем менять ресурс? В чем "фишка"? Ну, с одной стороны нам нужны уникальные названия для каждого соединения. С другой стороны, использование ресурса может помочь вам в информировании пользователей в вашем ростере (прим. пер. для пользователей ICQ: контакт-лист Jabber'а называется roster) о вашем текущем местоположении, например 'Home', 'Work', 'School', о вашей текущей операционной системе, например 'Mac' или 'Linux', или о сервере, на котором установлен клиент, например 'hercules' или 'athena'. Всегда может возникнуть новый повод обозначить свой ресурс. Почему нужна возможность изменять его? Потому что она у вас есть.
В сочетании с приоритетами, эта функция может стать прекрасной причиной перейти с вашего старого проприетарного IM-протокола на Jabber. XMPP дает вам бóльшую гибкость, необходимую для постоянного присутствия в сети, нежели использование бестолкового клиента в сочетании с бестолковой же службой в надежде на лучшее. Как я недавно узнал, AIM поддерживает множественные подключения, но когда кто-то шлет вам сообщение, оно приходит на все подключенные клиенты. По-моему, это нерационально. Тем более, что XMPP/Jabber справляется с подобной ситуацией столь элегантно.
Мы только что достигли вершины айсберга. Существует еще много причин перейти на Jabber, чем вы можете предположить, и я собираюсь рассказать обо всех, в надежде, что вы увидите причину перейти на лучший IM протокол в мире.
© Aaron Toponce, 'Why XMPP Part 2- Saving Your Resources', немного вольный перевод: vonderer.
16 июля 2007 г.
Почему XMPP? Часть 1. Приоритет.
Уважаемые читатели. В условиях отсутствия идей для новых сообщений, я решил немного поупражняться в английском языке и перевести несколько попавшихся мне на глаза интересных статей. Они касаются Jabber и предназначены в первую очередь для тех людей, которых я активно призываю переходить на него с icq. Перевод достаточно вольный, и, возможно, местами корявый. Прошу прощения за все шероховатости, ежели таковые имеются. Ссылки на оригинал и страницу автора приведены в конце поста. Спасибо за внимание.
Почему XMPP? Часть 1. Приоритет.
Сейчас я хотел бы поговорить на одну из самых любимых мною тем - о протоколе XMPP. Я надеюсь, что этими постами я смогу убедить своих читателей, что XMPP - лучший из протоколов мгновенных сообщений. После того, как все будет сказано, у вас не останется сомнений в том, что вы хотите использовать XMPP в качестве основного способа передачи мгновенных интернет-сообщений.
Однако, прежде, чем я начну, я отвечу на вопрос - а почему "XMPP", а не "Jabber"? Ну, вообще-то, два этих термина равнозначны и я совсем не против использования одного термина вместо другого до тех пор, пока они используются правильно. Но, все-таки, есть небольшая разница. XMPP - это основной протокол Jabber, обертка, если позволите, которая используется Google Talk, Jabber.org и другими Jabber-серверами. Jabber же - термин, использующийся в отношении чего-то большего, нежели протокол. Jabber - компания, сервер-демон и приложение с открытым исходным кодом. XMPP - просто движок. Таким образом, здесь и далее, я буду говорить и об XMPP, и о Jabber, используя термин 'Jabber'.
С термином разобрались, давайте теперь обсудим основную, на мой взгляд, вкусность Jabber - приоритет. Представим себе следующее: допустим, из IM-сетей вы используете исключительно ICQ. Залогинившись дома, вы можете общаться с друзьями и родными с помощью ICQ. Однако, вы оставляете домашний компьютер и ICQ на нем включенными, уходя на работу, а придя на работу, вы снова логинитесь в сеть ICQ. Что происходит? Правильно, ваш домашний ICQ отключается, а вы входите в сеть с работы. (Прим. пере.: А ведь еще может и зациклиться логин дома и на работе, и вы вообще конкретно обломаетесь с выходом в сеть с работы - на полчаса забанят, дабы не доканывали вы сервер АОЛа священный логинами своими нечистивыми.) Иначе говоря, вы можете выходить в сеть под одним аккаунтом только с одного клиента в одно и то же время. Так же обстоит ситуация и с другими проприетарными протоколами: например, MSN, AIM или Yahoo!.
Теперь вы уходите с работы. Вы выключаете компьютер и отправляетесь домой. Из-за того, что вы вне сети дома, а компьютер на работе уже выключен, ваш аккаунт находится вне сети. И что же случается, если в это время кто-то из вашего контакт-листа хочет связаться с вами? Конечно, есть множество других способов: сотовый телефон или электронная почта, например. Однако, зачем же быть столь ограниченным из-за своих клиента и IM-сети? Если я хочу присутствовать в сети 24 часа в сутки, 7 дней в неделю, независимо от моего местонахождения, у меня вряд ли это получится с ICQ или другим проприетарным протоколом. По крайней мере, это будет очень непросто. К счастью, с Jabber все намного проще.
Во-первых, Jabber поддерживает несколько соединений с сервером, независимо от местонахождения и клиента. Это означает, что вы можете быть в сети одновременно и дома, и на работе, при этом оба соединения будут постоянно работать. И независимо от того, отключились ли вы на работе или нет, вы всегда будете подключены с домашнего компьютера (если конечно не случится конец света или провод не оборвется). Удобно, не правда ли? Вы можете быть подключены к сети из дома, школы, с работы, у друзей или где-нибудь еще.
Тут же возникает вопрос. Допустим, вы подключились дважды из дома: с настольного компьютера и лаптопа, при этом ваш компьютер на работе тоже подключен к Jabber-сети. Таким образом, вы подключены сразу с 3 клиентов. Теперь, ваш друг хочет прислать вам сообщение. На какой клиент оно поступит? К счастью, Jabber не упускает из виду и этот момент. При каждом подключении вы устанавливаете значение приоритета. Клиент с самым высоким приоритетом и получит это сообщение. На нижеприведенном графике (позаимствованном у O'Relly) приведена схема подобной ситуации.
Таким образом, если приоритет подключения вашего лаптопа - 5, настольного компьютера - 15, а на работе - 8, то сообщение поступит на настольный домашний компьютер, так как у него самый высокий приоритет. Все просто. Где бы вы ни были, вы можете быть уверены, что сообщение поступит именно на тот клиент, доступ к которому вы имеете в данный момент времени: вы выставляете наиболее высокий приоритет и получаете новые сообщения без каких бы то ни было проблем независимо от числа подключенных к вашему аккаунту клиентов. Наибольший приоритет - 127, наименьший - 0.
Я думаю, теперь все поняли, что первая причина, по которой стоит переходить на Jabber - это наличие приоритетов и возможность множественного подключения. Можете ли вы получить нечто подобное от других IM-провайдеров? Сомневаюсь. Я, например, постоянно подключен с помощью centericq в screen на моем сервере. Приоритет равен 5, а статус постоянно away. Я им пользуюсь, когда я не нахожусь дома или на работе. И если кто-то хочет отправить мне сообщения, я постоянно доступен и могу получить сообщение в любой момент, подключившись к серверу по SSH. Дома и на работе я использую Gajim, с высоким приоритетом, чтобы всегда получать сообщения там, где я нахожусь (дома установлен приоритет 10, на работе - 15 на случай, если забуду отключиться дома).
© Aaron Toponce, 'Why XMPP Part 1- It’s All About Priority', немного вольный перевод: vonderer.
PS. После того, как этот пост появился на моей странице на beta.ya.ru, мне в комментариях deadcat указал на следующее:
"согласно RFC 3921, минимальное значение приориетета: -128 (минус 128).
http://tools.ietf.org/html/rfc3921
2.2.2.3. Priority
The OPTIONAL element contains non-human-readable XML character data that specifies the priority level of the resource. The value MUST be an integer between -128 and +127."
То есть, приоритетов может быть не 128, а вдвое больше. Единственная неувязка заключается здесь в том, что далеко не всякий клиент поддерживает отрицательные значения приоритета. Например, kopete (а значит, скорее всего и pidgin) не позволяет назначить отрицательное значение, а tkabber совершенно спокойно выставляет отрицательный приоритет.
Почему XMPP? Часть 1. Приоритет.
Сейчас я хотел бы поговорить на одну из самых любимых мною тем - о протоколе XMPP. Я надеюсь, что этими постами я смогу убедить своих читателей, что XMPP - лучший из протоколов мгновенных сообщений. После того, как все будет сказано, у вас не останется сомнений в том, что вы хотите использовать XMPP в качестве основного способа передачи мгновенных интернет-сообщений.
Однако, прежде, чем я начну, я отвечу на вопрос - а почему "XMPP", а не "Jabber"? Ну, вообще-то, два этих термина равнозначны и я совсем не против использования одного термина вместо другого до тех пор, пока они используются правильно. Но, все-таки, есть небольшая разница. XMPP - это основной протокол Jabber, обертка, если позволите, которая используется Google Talk, Jabber.org и другими Jabber-серверами. Jabber же - термин, использующийся в отношении чего-то большего, нежели протокол. Jabber - компания, сервер-демон и приложение с открытым исходным кодом. XMPP - просто движок. Таким образом, здесь и далее, я буду говорить и об XMPP, и о Jabber, используя термин 'Jabber'.
С термином разобрались, давайте теперь обсудим основную, на мой взгляд, вкусность Jabber - приоритет. Представим себе следующее: допустим, из IM-сетей вы используете исключительно ICQ. Залогинившись дома, вы можете общаться с друзьями и родными с помощью ICQ. Однако, вы оставляете домашний компьютер и ICQ на нем включенными, уходя на работу, а придя на работу, вы снова логинитесь в сеть ICQ. Что происходит? Правильно, ваш домашний ICQ отключается, а вы входите в сеть с работы. (Прим. пере.: А ведь еще может и зациклиться логин дома и на работе, и вы вообще конкретно обломаетесь с выходом в сеть с работы - на полчаса забанят, дабы не доканывали вы сервер АОЛа священный логинами своими нечистивыми.) Иначе говоря, вы можете выходить в сеть под одним аккаунтом только с одного клиента в одно и то же время. Так же обстоит ситуация и с другими проприетарными протоколами: например, MSN, AIM или Yahoo!.
Теперь вы уходите с работы. Вы выключаете компьютер и отправляетесь домой. Из-за того, что вы вне сети дома, а компьютер на работе уже выключен, ваш аккаунт находится вне сети. И что же случается, если в это время кто-то из вашего контакт-листа хочет связаться с вами? Конечно, есть множество других способов: сотовый телефон или электронная почта, например. Однако, зачем же быть столь ограниченным из-за своих клиента и IM-сети? Если я хочу присутствовать в сети 24 часа в сутки, 7 дней в неделю, независимо от моего местонахождения, у меня вряд ли это получится с ICQ или другим проприетарным протоколом. По крайней мере, это будет очень непросто. К счастью, с Jabber все намного проще.
Во-первых, Jabber поддерживает несколько соединений с сервером, независимо от местонахождения и клиента. Это означает, что вы можете быть в сети одновременно и дома, и на работе, при этом оба соединения будут постоянно работать. И независимо от того, отключились ли вы на работе или нет, вы всегда будете подключены с домашнего компьютера (если конечно не случится конец света или провод не оборвется). Удобно, не правда ли? Вы можете быть подключены к сети из дома, школы, с работы, у друзей или где-нибудь еще.
Тут же возникает вопрос. Допустим, вы подключились дважды из дома: с настольного компьютера и лаптопа, при этом ваш компьютер на работе тоже подключен к Jabber-сети. Таким образом, вы подключены сразу с 3 клиентов. Теперь, ваш друг хочет прислать вам сообщение. На какой клиент оно поступит? К счастью, Jabber не упускает из виду и этот момент. При каждом подключении вы устанавливаете значение приоритета. Клиент с самым высоким приоритетом и получит это сообщение. На нижеприведенном графике (позаимствованном у O'Relly) приведена схема подобной ситуации.
Таким образом, если приоритет подключения вашего лаптопа - 5, настольного компьютера - 15, а на работе - 8, то сообщение поступит на настольный домашний компьютер, так как у него самый высокий приоритет. Все просто. Где бы вы ни были, вы можете быть уверены, что сообщение поступит именно на тот клиент, доступ к которому вы имеете в данный момент времени: вы выставляете наиболее высокий приоритет и получаете новые сообщения без каких бы то ни было проблем независимо от числа подключенных к вашему аккаунту клиентов. Наибольший приоритет - 127, наименьший - 0.
Я думаю, теперь все поняли, что первая причина, по которой стоит переходить на Jabber - это наличие приоритетов и возможность множественного подключения. Можете ли вы получить нечто подобное от других IM-провайдеров? Сомневаюсь. Я, например, постоянно подключен с помощью centericq в screen на моем сервере. Приоритет равен 5, а статус постоянно away. Я им пользуюсь, когда я не нахожусь дома или на работе. И если кто-то хочет отправить мне сообщения, я постоянно доступен и могу получить сообщение в любой момент, подключившись к серверу по SSH. Дома и на работе я использую Gajim, с высоким приоритетом, чтобы всегда получать сообщения там, где я нахожусь (дома установлен приоритет 10, на работе - 15 на случай, если забуду отключиться дома).
© Aaron Toponce, 'Why XMPP Part 1- It’s All About Priority', немного вольный перевод: vonderer.
PS. После того, как этот пост появился на моей странице на beta.ya.ru, мне в комментариях deadcat указал на следующее:
"согласно RFC 3921, минимальное значение приориетета: -128 (минус 128).
http://tools.ietf.org/html/rfc3921
2.2.2.3. Priority
The OPTIONAL element contains non-human-readable XML character data that specifies the priority level of the resource. The value MUST be an integer between -128 and +127."
То есть, приоритетов может быть не 128, а вдвое больше. Единственная неувязка заключается здесь в том, что далеко не всякий клиент поддерживает отрицательные значения приоритета. Например, kopete (а значит, скорее всего и pidgin) не позволяет назначить отрицательное значение, а tkabber совершенно спокойно выставляет отрицательный приоритет.
1 июля 2007 г.
Игры в Linux
Вот и созрел пост, неожиданно для меня самого.
Когда-то я писал, что в Linux много различных логических игр-"времяубивалок". Но, как говорится, "не ими едиными". Итак, мои текущие наблюдения в области компьютерных игр, играбельных в Linux. Ниже описаны игры, в которые играю я.
Heroes of Might and Magic IV, или wine в действии.
Время от времени я развлекаюсь тем, что пытаюсь запускать различные виндовые игрушки в wine. В последней на данный момент версии wine (0.9.40), Baldur's Gate II перестал работать адекватно (последний раз я эту игру вполне адекватно запускал в wine 0.9.33). Однако, попытавшись запустить установленную ранее в Windows XP Heroes of Might and Magic IV Winds of War, с noCD, я, честно говоря, удивился. Игра идет без тормозов и глюков, хотя со звуком творятся странные вещи (как и в других приложениях, запускаемых в wine). Впрочем, хоть музыка в Heroes of Might and Magic - довольно мощная составляющая, никто не мешает отключить звук wine и включить какую-нибудь кельтскую музыку отдельно, в любимом проигрывателе. Хотя HoMM4 и не является лучшей игрой серии, она по праву считается одной из самых красивых 2D-игрушек.
SEGA Genesis, NES, SNES, Nintendo 64.
Эмуляция Windows в wine(X) - не единственный способ поиграть в хорошие игры в Linux. Другим простым способом является эмуляция разнообразных игровых приставок: Sega Genesis, Dendy (NES), Super Nintendo (SNES) или Nintendo 64. На мой взгляд, эти приставки являются самым удачным выбором для эмуляции на PC. (Хотя эмуляция Nintendo 64 все еще довольно нестабильна.) Есть конечно еще и например Atari, GameBoy или PSX и более совершенные. Но, к сожалению в случае с первыми - наблюдать такую графику на экране 1280х1024 - исключительный мазахизм, мне кажется, что даже совершенно уникальный геймплей не спасет такую игру, а в случае со вторыми - нестабильная эмуляция и приличные тормоза.
Если в случае эмуляции Windows все более или менее ясно - либо wine, либо Cedega, то в эмуляции приставок есть из чего выбрать. К сожалению, большинство хороших эмуляторов написаны либо под DOS (например, один из лучших на сегодняшний день эмуляторов SEGA Genesis - Genecyst), либо под Windows (Gens32), а процесс "эмуляции в эмуляции" крайне сомнителен, хотя мне удавалось запускать Genecyst в DOSbox, мне это кажется нелогичным. Поэтому рассмотрю лучшие, на мой взгляд, эмуляторы.
Начну со своей любимой SEGA Genesis. Эмулятор Gens - лучший для Windows, и не с проста: великолепная совместимость, огромное количество графических фильтров и удобство использования оставляют позади всех конкурентов. К сожалению, этот эмулятор прекратил развитие с версией 2.14 и сейчас начинания его разработчика реализуются в Gens32. Но самое интересное состоит в том, что Gens был OpenSource проектом, поэтому этот замечательный эмулятор может быть собран в любой операционной системе, в том числе, и в linux. К сожалению, последняя версия (2.14) отказалась собираться на моей машине, как бы я не плясал вокруг нее с бубном. Однако, на форумах Ubuntu выложены *deb-пакеты версий 2.12a и 2.12b. Конечно, кроме Gens существует dgen - безgui'вый эмулятор, но он намного слабже по своим возможностям.
Эмуляторов для NES (Nintendo Entertainment System, Dendy) я не разбирал, поэтому не скажу, что FCEU - единственный и лучший, но он оставил приятное впечатление и не вызвал нареканий. Все игры, которые я пытался в нем запустить, пошли. Тем и доволен. :)
Эмуляторов SNES (Super Nintendo Entertainment System) очень немного. Однако, имеется два превосходных эмулятора. Оба кроссплатформенные. zSNES - очень прост в использовании, хотя ранее пару раз наглухо вешал систему. Второй - snes9x, изначально заточенный для командной строки однако имеющий довольно приятный GUI на GTK2.
Теперь о том, чем же хороши приставочные эмуляторы. Не сомневаюсь, что многим доводилось играть в приставки, когда они "рулили и педалили" - в начале-середине 90х. Думаю, многие согласятся, что на приставках существовало множество хороших аркад-платформеров, ну и игр других жанров. В качестве примера, приведу мои любимые игры "на все времена": Sonic 3 & Knuckles (SEGA), Earthworm Jim (SEGA/SNES), Earthworm Jim 2 (SEGA/SNES), Ultimate Mortal Combat 3 (SEGA/SNES), Super Mario 3 (SNES), Super Mario Land (SNES), разнообразные Tetris и их модификации, арканоиды и пинболы. Конечно, поиграть в KDE'шные шарики, заполняя пространство между ними, интересно и увлекательно. С другой стороны, гораздо больше удовольствия можно получить от аркадной приставочной игры.
X-Moto
Помнится, лет 5 назад, я увлеченно играл в игру под названием Elastomania. Суть ее заключалась в том, что человек на странном мотоцикле, рессоры которого вытягиваются на немеряную длину в условиях странной физики, катается по уровням и собирает яблоки. Игра довольно сложная и интересная с точки зрения логики и реакции. Совершенно недавно, пролистывая блоги, я наткнулся на отичнейший кроссплатформенный клон "Эластомании" под названием X-Moto.
Помимо стандартного набора из сложных уровней и затягивающего прочно и надолго геймплея, которые были свойственны Elastomania, в игре имеются и свои "фишки" - например, скриптовые уровни, где платформы или ягоды (местный аналог яблок Эластомании) двигаются во всех направлениях. Другой замечательной "фишкой" является проигрывание "реплея" во время повторного прохождения уровня, где "призрачный мотоциклист" повторяет раннее прохождение игроком уровня, таким образом, игроку становится намного удобнее и интереснее совершенствовать свой результат, соревнуясь с собой в прямом смысле этих слов.
Frets On Fire
Ну и наконец, пару слов о той игре, из-за которой у меня и возникло желание написать этот пост. Сегодня утром, проглядывая свою RSS-ленту, наткнулся на статью об очень своеобразной игре - Frets On Fire. Она должна крайне понравится всем без исключения любителям гитарной музыки и просто любителям интересных и необычных игр. Процесс игры трудно описать в двух словах. Выше имеется видео, прекрасно характеризующее процесс игры. Хотя он и может показаться малоинтересным, игра сложная и затягивающая. С официального сайта игры можно скачать версию для Linux, Windows или MacOS X. Там же можно найти ссылки на сайты с большим количеством песен (поскольку в комплекте идут только туториал и три песни). У игры имеется всего лишь один недостаток - это объем. 30 МБ на саму игру, плюс объем архива с одной песней колеблется от 6 до 10 МБ.
Когда-то я писал, что в Linux много различных логических игр-"времяубивалок". Но, как говорится, "не ими едиными". Итак, мои текущие наблюдения в области компьютерных игр, играбельных в Linux. Ниже описаны игры, в которые играю я.
Heroes of Might and Magic IV, или wine в действии.
Время от времени я развлекаюсь тем, что пытаюсь запускать различные виндовые игрушки в wine. В последней на данный момент версии wine (0.9.40), Baldur's Gate II перестал работать адекватно (последний раз я эту игру вполне адекватно запускал в wine 0.9.33). Однако, попытавшись запустить установленную ранее в Windows XP Heroes of Might and Magic IV Winds of War, с noCD, я, честно говоря, удивился. Игра идет без тормозов и глюков, хотя со звуком творятся странные вещи (как и в других приложениях, запускаемых в wine). Впрочем, хоть музыка в Heroes of Might and Magic - довольно мощная составляющая, никто не мешает отключить звук wine и включить какую-нибудь кельтскую музыку отдельно, в любимом проигрывателе. Хотя HoMM4 и не является лучшей игрой серии, она по праву считается одной из самых красивых 2D-игрушек.
SEGA Genesis, NES, SNES, Nintendo 64.
Эмуляция Windows в wine(X) - не единственный способ поиграть в хорошие игры в Linux. Другим простым способом является эмуляция разнообразных игровых приставок: Sega Genesis, Dendy (NES), Super Nintendo (SNES) или Nintendo 64. На мой взгляд, эти приставки являются самым удачным выбором для эмуляции на PC. (Хотя эмуляция Nintendo 64 все еще довольно нестабильна.) Есть конечно еще и например Atari, GameBoy или PSX и более совершенные. Но, к сожалению в случае с первыми - наблюдать такую графику на экране 1280х1024 - исключительный мазахизм, мне кажется, что даже совершенно уникальный геймплей не спасет такую игру, а в случае со вторыми - нестабильная эмуляция и приличные тормоза.
Если в случае эмуляции Windows все более или менее ясно - либо wine, либо Cedega, то в эмуляции приставок есть из чего выбрать. К сожалению, большинство хороших эмуляторов написаны либо под DOS (например, один из лучших на сегодняшний день эмуляторов SEGA Genesis - Genecyst), либо под Windows (Gens32), а процесс "эмуляции в эмуляции" крайне сомнителен, хотя мне удавалось запускать Genecyst в DOSbox, мне это кажется нелогичным. Поэтому рассмотрю лучшие, на мой взгляд, эмуляторы.
Начну со своей любимой SEGA Genesis. Эмулятор Gens - лучший для Windows, и не с проста: великолепная совместимость, огромное количество графических фильтров и удобство использования оставляют позади всех конкурентов. К сожалению, этот эмулятор прекратил развитие с версией 2.14 и сейчас начинания его разработчика реализуются в Gens32. Но самое интересное состоит в том, что Gens был OpenSource проектом, поэтому этот замечательный эмулятор может быть собран в любой операционной системе, в том числе, и в linux. К сожалению, последняя версия (2.14) отказалась собираться на моей машине, как бы я не плясал вокруг нее с бубном. Однако, на форумах Ubuntu выложены *deb-пакеты версий 2.12a и 2.12b. Конечно, кроме Gens существует dgen - безgui'вый эмулятор, но он намного слабже по своим возможностям.
Эмуляторов для NES (Nintendo Entertainment System, Dendy) я не разбирал, поэтому не скажу, что FCEU - единственный и лучший, но он оставил приятное впечатление и не вызвал нареканий. Все игры, которые я пытался в нем запустить, пошли. Тем и доволен. :)
Эмуляторов SNES (Super Nintendo Entertainment System) очень немного. Однако, имеется два превосходных эмулятора. Оба кроссплатформенные. zSNES - очень прост в использовании, хотя ранее пару раз наглухо вешал систему. Второй - snes9x, изначально заточенный для командной строки однако имеющий довольно приятный GUI на GTK2.
Теперь о том, чем же хороши приставочные эмуляторы. Не сомневаюсь, что многим доводилось играть в приставки, когда они "рулили и педалили" - в начале-середине 90х. Думаю, многие согласятся, что на приставках существовало множество хороших аркад-платформеров, ну и игр других жанров. В качестве примера, приведу мои любимые игры "на все времена": Sonic 3 & Knuckles (SEGA), Earthworm Jim (SEGA/SNES), Earthworm Jim 2 (SEGA/SNES), Ultimate Mortal Combat 3 (SEGA/SNES), Super Mario 3 (SNES), Super Mario Land (SNES), разнообразные Tetris и их модификации, арканоиды и пинболы. Конечно, поиграть в KDE'шные шарики, заполняя пространство между ними, интересно и увлекательно. С другой стороны, гораздо больше удовольствия можно получить от аркадной приставочной игры.
X-Moto
Помнится, лет 5 назад, я увлеченно играл в игру под названием Elastomania. Суть ее заключалась в том, что человек на странном мотоцикле, рессоры которого вытягиваются на немеряную длину в условиях странной физики, катается по уровням и собирает яблоки. Игра довольно сложная и интересная с точки зрения логики и реакции. Совершенно недавно, пролистывая блоги, я наткнулся на отичнейший кроссплатформенный клон "Эластомании" под названием X-Moto.
Помимо стандартного набора из сложных уровней и затягивающего прочно и надолго геймплея, которые были свойственны Elastomania, в игре имеются и свои "фишки" - например, скриптовые уровни, где платформы или ягоды (местный аналог яблок Эластомании) двигаются во всех направлениях. Другой замечательной "фишкой" является проигрывание "реплея" во время повторного прохождения уровня, где "призрачный мотоциклист" повторяет раннее прохождение игроком уровня, таким образом, игроку становится намного удобнее и интереснее совершенствовать свой результат, соревнуясь с собой в прямом смысле этих слов.
Frets On Fire
Ну и наконец, пару слов о той игре, из-за которой у меня и возникло желание написать этот пост. Сегодня утром, проглядывая свою RSS-ленту, наткнулся на статью об очень своеобразной игре - Frets On Fire. Она должна крайне понравится всем без исключения любителям гитарной музыки и просто любителям интересных и необычных игр. Процесс игры трудно описать в двух словах. Выше имеется видео, прекрасно характеризующее процесс игры. Хотя он и может показаться малоинтересным, игра сложная и затягивающая. С официального сайта игры можно скачать версию для Linux, Windows или MacOS X. Там же можно найти ссылки на сайты с большим количеством песен (поскольку в комплекте идут только туториал и три песни). У игры имеется всего лишь один недостаток - это объем. 30 МБ на саму игру, плюс объем архива с одной песней колеблется от 6 до 10 МБ.
Подписаться на:
Сообщения (Atom)
