Прочитал топик habrahabr.ru/blogs/linux/67209 и решил выложить сюда свою статью, которая была до этого видна только в закрытой корпоративной Wiki.

Обычно, при создании VPN, используется подключение типа точка-точка к некоторому серверу, либо установка ethernet-туннеля с некоторым сервером, при котором туннелю назначается определённая подсеть. Сервер VPN при этом выполняет функции маршрутизации и фильтрования трафика для доступа к локальной сети через VPN.

Данная статья рассматривает другой подход к созданию виртуальной сети, при котором удалённые системы включаются в уже существующую локальную подсеть, а сервер VPN выполняет роль Ethernet-шлюза. При использовании такого подхода мы всё ещё имеем возможность фильтровать трафик на основании способа подключения (например, использовать для локальной сети и для удалённых пользователей разные фильтры), но исключается необходимость настройки маршрутизации, а удалённые машины включаются прямо в локальную сеть, видят ресурсы, даже способны использовать широковещательные посылки вообще без дополнительной настройки. Через такой VPN у них отображаются все компьютеры локальной сети Windows, все доступные XDMCP-серверы при XDMCP broadcast и т. д.

Я, как старый линуксоид, когда впервые установил Ubuntu и увидел незнакомое слово avahi, конечно же сразу посмотрел в google. Потыкался в несколько ссылок, увидел другие непонятные слова, типа zeroconf, multicast dns, bonjour. Сразу понял, что это какая то мутная технология от Apple и нафиг мне ненужная.

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

Давайте разберемся с терминологией:

1. Zeroconf — это протокол, разработанный Apple и призванный решать следующие проблемы:
   
   • выбор сетевого адреса для устройства;
   • нахождение компьютеров по имени;
   • обнаружение сервисов, например принтеров.
2. Avahi — открытая и свободная реализация протокола zeroconf.
3. Bonjour — open-source реализация протокола zeroconf от Apple.

Когда-то давным давно я собирался и даже обещал написать про механизм виртуальных функций относительно деструкторов. Теперь у меня наконец появилось свободное время и я решил воплотить эту затею в жизнь. На самом деле эта мини-статья служит «прологом» к моей следующей статье. Но я постарался изложить доходчиво и понятно основные моменты по текущей теме. Если вы чувствуете, что еще недостаточно разобрались в механизме виртуальных вызовов, то, возможно, вам следует для начала прочитать мою предыдущую статью.

Сразу же, как обычно, оговорюсь, что: 1) статья моя не претендует на полноту изложения материала; 2) мегапрограммеры ничего нового здесь не узнают; 3) материал не новый и давно описан во многих книгах, но если явно об этом не прочитать и самому специально не задумываться, то можно о некоторых моментах даже не подозревать (до поры, до времени). Также прошу прощения за надуманные примеры :)

За временем не успеть. Все вокруг развивается очень стремительно. В какой-то момент я заметил, что хоть и работаю с последней версией Ruby on Rails, но многих «фич», которые в ней реализованы я не использую, более того о многих я даже не слышал.
Я попробую сделать ретроспективу, что было введено в Rails за последние 14 месяцев. Каждое нововведение буду сопрождать небольшим примером, который буду копировать as is из источника, на котором основана статья, так как подобные пояснения для каждой это тема для кучи отдельных статей или ссылкой.

Сегодня поговорим о Comet и о server push вообще.

Обычные веб-приложения, как и сайты, работают по традиционной модели запрос-ответ-запрос, при этом, в силу особенностей HTTP-протокола и некоторых серверных реализаций обработчиков, приложение не хранит информацию между запросами, так что каждый вызов является независимым, а идентификация или сессионность обеспечиваются более высокоуровневыми средствами (например, всем известная реализация сессий в PHP). Кроме этого, запрос на новую информацию посылает всегда клиент, который заинтересован в получении самой актуальной версии данных. В приложениях, которым критично обновление, это часто становиться узким местом. У нас в одном из предыдущих проектов, было сразу несколько периодических AJAX-запросов на обновление данных. Хотя для такого случая есть варианты и вызова нескольких обработчиков на стороне сервера одним запросом от клиента.

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

Сформулируем, что же мы хотим получить в результате:
1. Чтобы канал поровну делился между пользователями.
2. Чтобы канал зря не простаивал.
3. Чтобы онлайн-игры, ssh и telnet не «лагали» даже при полной загрузке канала, например торрентами.

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

Почему PDF? Формат PDF позволяет создавать документы с целым рядом неоспоримых преимуществ: открытость, кроссплатформеность, распространенность и, что очень важно, точностью и неизменностью передачи данных по цепочке создание, просмотр и печать.

В чем соль? В использовании SVG файлов как шаблонов с возможностью подстановки необходимых полей с последующим преобразованием в PDF.

Какие преимущества? Возможность создания и быстрого редактирования очень сложных шаблонов в привычных векторных редакторах, таких как Adobe Illustrator, Corel Draw или Inkscape. Простота программирования и использование только бесплатных программных средств. Еще одним важным преимуществом является возможность прозрачно использовать UTF-8 для вставляемых текстов.

Что для этого надо? Для использования данного метода нужен выделенный сервер с возможностью установки своих приложений (Inkscape и GhostScript) и выполнением system-команд. При этом всё будет работать как на Windows платформе, так и на Linux.

В последнее время я начал проводить много времени в редакторе среде Emacs, потому что после некоторого периода адаптации понял, что это очень удобная вещь. Конечно, вы можете спросить, мол а может я линуксойд-фанатик и на самом деле ничего удобного в Emacs-е нет. Попытаюсь аргументировать: разве неудобно когда все под рукой? Все в одном средстве: и тектовый редактор, и средство для планирования (например своего свободного времени на неделе), и почтовый клиент, и средство для работы с системами контроля версий, такими, как CVS или SVN, и даже небольшой, просто веб-браузер (большие сайты он конечно не всегда просматривает правильно, но почитать новости на ЛОР-е удобно вполне). По-моему, такой подход имеет право на существование. Да, и не стоит забывать, что среда Emacs имеет встроенный язык программирования elisp, что позволяет заточить среду под свои конкретные нужды или даже разработать свой собственный встроенный модуль и все это еще и OpenSource! В этой статье, я хочу познакомить читателей с jabber-клиентом Emacs-а, который называется jabber.el.