• Модули вместо микросервисов

      Термин "модуль" (module) взят из статьи Modules vs. microservices. Так же для описания чего-то среднего между микросервисами и монолитами иногда используют термины "микролит" (microlith) или "моносервис" (monoservice). Но, не смотря на то, что термин "модуль" и так уже нагружен общеизвестным смыслом, на мой взгляд он подходит лучше других вариантов. Update: В комментарии lega использовал термин "встроенный микросервис" — он лучше описывает суть подхода, чем "модуль".


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


      Я пишу микросервисы с 2009 года, но применять модули вместо микросервисов в реальных проектах пока не пробовал — всё описанное далее это моё предположение о том, каким должен быть вышеупомянутый баланс, и оно нуждается как в теоретической критике так и в проверке практикой.

      Читать дальше →
    • Переход с bash на zsh

      • Tutorial

      Чтобы перейти с bash на zsh необходимо знать базовые отличия между ними — без этого будет сложно провести первоначальную настройку zsh в ~/.zshrc.


      Я не нашёл краткого описания этих отличий когда переходил сам, и мне пришлось потратить немало времени на вычитывание документации zsh. Надеюсь, эта статья упростит вам переход на zsh.


      Зачем переходить


      Для начала — а стоит ли вообще тратить своё время и внимание на переход? Учить ещё один диалект sh, менее распространённый чем POSIX sh или bash, заново заниматься настройкой рабочего окружения…


      На мой взгляд, если вы проводите много времени в консоли, вам нравятся Vim или Emacs и вы уже потратили немало времени на их настройку "под себя" — однозначно стоит! Zsh по духу очень на них похожа: это очень сложная и гибкая программа, чьи возможности полностью мало кто знает, но потратив некоторое время на настройку можно получить очень удобную лично вам рабочую среду.

      Читать дальше →
    • Защита личных данных на Android-телефоне

      • Tutorial
      Мобильных компьютеров уже давно больше, чем стационарных. И наших личных данных на них так же значительно больше, чем на стационарных. При этом текущий дизайн OS мобильных устройств создаёт впечатление, что одна из их основных задач — как можно сильнее упростить доступ третьим лицам (в основном — корпорациям и государству, но и мелким разработчикам мобильных приложений тоже обламывается от этого пирога) к вашим личным данным.

      Частичная открытость Android немного улучшает ситуацию, но полноценного решения проблемы утечки приватных данных пока не существует. Основная проблема в том, что пока на устройстве используются блобы нет никаких гарантий, что в них нет закладок (вроде обнаруженных в прошивках Samsung Galaxy). Аналогичная проблема с проприетарными приложениями без открытых исходников (вроде всего пакета GApps, начиная с самого Google Play Маркет). По сути всё как раз наоборот — крайне высока вероятность, что закладки там есть. Нередко их даже не пытаются скрывать, выдавая за удобные «фичи» для синхронизации и/или бэкапа ваших данных, обеспечивания вас полезной рекламой, и «защиту» от вредоносного софта или на случай утери устройства. Один из самых надёжных способов защиты своих данных описан в статье Mission Impossible: Hardening Android for Security and Privacy, но там речь не о телефоне, а о планшете, причём с поддержкой только WiFi (мобильных чипов без блобов по-моему вообще пока ещё нет, для мобильного инета вместе с этим планшетом предлагается использовать отдельный 3G-модем, блобы в котором никому не навредят т.к. на этом модеме личных данных просто нет), и, на всякий случай, физически отрезанным микрофоном. Но, несмотря на невозможность полноценно защитить личные данные на телефоне, я считаю что стоит сделать максимум возможного: прикрыть столько каналов утечек, сколько получится — ведь мало кто может позволить себе не использовать мобильный телефон или не держать на нём личные данные (хотя бы контакты и историю звонков).

      Читать дальше →
    • Авторинг Perl модулей

      • Tutorial
      При разработке перл-модулей приходится делать много работы, которая практически не связана с задачами и кодом модуля — начиная от создания десятка типовых файлов/каталогов и заканчивая выполнением десятка одинаковых операций необходимых для выпуска новой версии.

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

      Кроме того, многие из нас пишут на перле очень много лет, и последний раз читали perlnewmod когда изучали перл. В результате, когда создаются новые модули это нередко делается в стиле 15-ти летней давности, причём система сборки выбирается практически случайным образом — либо древний, но знакомый и точно умеющий что угодно EUMM, либо одна из других (не потому, что нужна именно она, а просто в надежде что она окажется проще и удобнее EUMM, не создав при этом новых проблем… которые она всё-таки со временем создаёт).

      Далее кратко описаны имеющиеся на начало 2015 года средства, которые могут облегчить процесс разработки перл-модулей, сделать ваши модули более современными, и упростить другим разработчикам доработку ваших модулей. Я постарался перечислить их основные плюсы и минусы, но т.к. сам пользовался не всеми то буду дополнять/исправлять этот список в соответствии с вашими комментариями.

      Читать дальше →
    • Разбираемся с rtorrent всерьёз

      • Tutorial
      Об установке и базовой настройке rtorrent на хабре хватает статей, как и споров о том, стоит ли вообще связываться с хардкорным rtorrent или лучше обойтись чем-нибудь более дружественным к пользователю. Лично я много лет назад пересмотрел все качалки и в результате rtorrent оказался самым стабильным и эффективным. Интерфейс у него не самый удобный, но достаточно понятный и юзабельный чтобы это не стало серьёзной проблемой. Альтернативные интерфейсы вроде rutorrent у меня как-то не прижились - ставить php только ради rutorrent неохота, а остальные варианты выглядят совсем слабо (и ни одного кроме rutorrent даже нет в портаж Gentoo).

        

      Одно из основных преимуществ rtorrent — очень гибкие возможности по его настройке и автоматизации. К сожалению, синтаксис ~/.rtorrent.rc достаточно нестандартный, нормальная документация отсутствует, поэтому обычно настройка сводится к поиску и копированию (попытка что-то в них изменить кроме констант/путей к каталогам обычно проваливается) готовых рецептов или вообще ограничивается редактированием констант в базовой конфигурации.

      На днях я решил, что так дальше продолжаться не может — мы очень много лет знакомы, он для меня столько хорошего выкачал, а я всё никак не познакомлюсь с ним поближе! Не скажу, что досконально с ним разобрался, но по крайней мере я смог реализовать все свои идеи по автоматизации rtorrent, и сделал это понимая, что и почему я делаю, без шаманства с чужими рецептами.

      Читать дальше →
    • Документация Mojolicious: Потерянные Главы

      • Tutorial
      Это продолжение серии статей о веб-фреймворке для Perl — Mojolicious: первая часть.

      Этот цикл статей предполагает, что читатель уже поверхностно знаком с фреймворком, и у него возникла потребность разобраться в деталях, которые либо не описаны в документации, либо описаны недостаточно подробно и понятно. Для начального ознакомления идеально подходит официальная документация (на английском).

      Асинхронность: синхронизируем с помощью Mojo::IOLoop::Delay


      Mojo::IOLoop::Delay предоставляет механизм, обеспечивающий для асинхронно выполняющихся callback-ов:

      • описание последовательно выполняющихся операций без «лапши» callback-ов
      • передачу результатов из callback-а(ов) текущего шага на следующий
      • общие данные для callback-ов, объединённых в одну задачу
      • синхронизацию групп callback-ов
      • перехват и обработку исключений в callback-ах

      Используемые термины:

      • (асинхронная) операция — обычно это вызов асинхронной функции вроде  таймера или выкачивания url, которой необходимо передать callback
      • шаг — callback, который анализирует данные полученные с предыдущего  шага (если это не первый шаг), и запускает одну или несколько новых  операций, либо возвращает финальный результат (если это последний шаг)
      • задача — список шагов, которые должны выполняться последовательно  (т.е. следующий шаг вызывается только после того, как все операции  запущенные на предыдущем шаге завершаются)

      Альтернатива Promises

      Это альтернативный подход к проблеме, обычно решаемой с помощью Promise/Deferred или Future. Вот приблизительное сравнение со спецификацией Promises/A+
      Читать дальше →
    • Документация Mojolicious: Потерянные Главы

      • Tutorial
      Update: статья обновлена для соответствия Mojolicious 6.0.

      Mojolicious — восхитительный современный веб-фреймворк для Perl. Из недостатков я могу назвать только два: политика в отношении обратной совместимости и документация.

      Этот цикл статей предполагает, что читатель уже поверхностно знаком с фреймворком, и у него возникла потребность разобраться в деталях, которые либо не описаны в документации, либо описаны недостаточно подробно и понятно. Для начального ознакомления идеально подходит официальная документация (на английском).

      Содержание


      1. Недостатки
      2. Роутинг: внутреннее устройство
      3. Роутинг: настройка
      4. Параметры HTTP-запроса
      5. Парсинг
      6. Tips & Tricks
        1. Поддержка неблокирующих приложений в режиме CGI
        2. Как работает Mojo::UserAgent при тестировании своего приложения
        3. ojo и Mojolicious::Lite
        4. Переменные окружения


      Другие статьи в этой серии



      Недостатки


      В официальном FAQ написано: "… we will always deprecate a feature before removing or changing it in incompatible ways between major releases … as long as you are not using anything marked experimental, untested or undocumented, you can always count on backwards compatibility …". Для начала, вторая фраза противоречит первой. Далее, вот цитата из Guides::Contributing «Features may only be changed in a major release or after being deprecated for at least 3 months.». Честно говоря, 3 месяца это и так смешной срок когда речь идёт об обратной совместимости, но похоже что даже этот срок соблюдается не всегда (поддержку «X-Forwarded-HTTPS» сделали deprecated два месяца назад, а удалили месяц назад — да, это был «major release» поэтому формально правила не нарушены, но общее отношение к обратной совместимости вполне показательно). Как много разработчиков обновляет фреймворк чаще чем раз в 3 месяца, да ещё и при этом тщательно вычитывает Changes или логи своего приложения на предмет deprecated-предупреждений? При этом, в течении последнего года было deprecated примерно 20 функций/фич. На практике, конечно, всё не так плохо, как это звучит — что-то ломается не так уж часто (лично меня за последний год коснулась только замена $app->secret() на $app->secrets()). Но факт остаётся фактом — обратную совместимость ломают, ломают часто, причём без по-настоящему веских причин: например, в случае с secret() абсолютно ничего не мешало добавить в код
      sub secret { shift->secrets([shift]) }
      
      либо просто добавить поддержку дополнительных параметров в secret() вместо добавления новой функции secrets() реализовав нужную фичу вообще не ломая совместимость.

      Что касается документации, то многие считают её отличной, даже одним из серьёзных достоинств Mojolicious, но никак не недостатком. Проблема с документацией в том, что она вся сосредоточена на примерах. Это реально круто, когда ты начинаешь изучать фреймворк. Это экономит кучу времени, когда тебе нужно сделать фичу и ты быстро гуглишь пример аналогичной фичи в официальных guides. Но как только ты выходишь за рамки стандартных задач и возникает необходимость понять, как что-то устроено идеологически или архитектурно, какие конкретно параметры может принимать эта функция и что конкретно она может возвращать в разных ситуациях — выясняется, что для многих модулей Mojolicious такая документация отсутствует в принципе. И не потому, что эта информация относится к «недокументированным возможностям» — почти всё это мельком упоминается здесь и там в разных примерах, а значит считается «документированным». Нередко есть несколько способов получить доступ к определённым данным (параметры запроса, тело ответа, etc.) но не описано чем они друг от друга отличаются и в каких ситуациях правильнее пользоваться какими способами. И последнее — алфавитный порядок функций в доке, серьёзно?! Нет, я понимаю, все люди разные и кому-то наверняка это удобно, но многим всё-таки на порядок проще воспринимать документацию в которой функции сгруппированы по задачам. (Хотя в коде, особенно при чтении его через браузер, где не так удобно пользоваться поиском как в Vim, алфавитный порядок функций неожиданно оказался довольно удобным — кроме new/DESTROY/AUTOLOAD — их всё-таки лучше размещать в начале.) В результате, чтобы разобраться приходится вычитывать код (некоторые предпочитают вместо этого смотреть тесты!), что не так просто — во-первых он не является эталоном читабельности: автор любит использовать фишки перла, которые позволяют писать код компактно (и нередко такой код быстрее работает), но читабельность это ухудшает; во-вторых активное использование и наследования и обмена событиями между объектами усложняет понимание того, что и как происходит внутри 104 классов, из которых состоит Mojolicious-5.

      С проблемой обратной совместимости мы мало что можем сделать (хотя, наверное, можно сделать плагин к Mojolicious, который будет её эмулировать по мере возможности). Зато вторую проблему решить не сложно — недостающую документацию можно написать самостоятельно. По мере изучения Mojolicious я планирую описывать некоторые вещи, которые, по-хорошему, должны быть в официальной документации, отсюда и название этой статьи.
      Читать дальше →
      • +20
      • 12,6k
      • 7
    • Немножко анонимен

        Обсуждение анонимности нужно начинать не со слов прокси/тор/впн, а с определения задачи: анонимно подключиться к чужому серверу по SSH это одно, анонимно поднять свой веб-сайт это другое, анонимно работать в инете это третье, etc. — и все эти задачи решаются по-разному. Эта статья о задаче «анонимно работать в интернете как пользователь».

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

        Во-первых, нужно адекватно оценивать потенциального противника. Если вы хотите быть «анонимным», значит вы пытаетесь избежать возможности связывания вашей активности в интернете с вашим физическим расположением и/или настоящим именем. Обычные пользователи и так не имеют возможности вас отслеживать (технически, социальные методы когда по вашему нику на форуме легко гуглится ваш аккаунт в соц.сетях со всеми личными данными мы здесь не рассматриваем). Ваш провайдер/соседи могут иметь возможность прослушать большую часть вашего трафика, но, как правило, вы им не интересны (да, соседи могут украсть ваши пароли, но заниматься отслеживанием вашей активности или вашей деанонимизацией они не станут). Что же касается владельцев используемых вами ресурсов (веб-сайтов, прокси/vpn-серверов, etc.) то у них в распоряжении множество средств по отслеживаю вас (DNS-leaks, Flash/Java-плагины, баннерные сети, «отпечатки браузера», множество разных видов кук, etc.) плюс серьёзный коммерческий интерес к тому, чтобы надёжно вас отслеживать (для таргетирования рекламы, продажи данных, etc.). Ну а правительство и спец.службы могут получить доступ и к данным, которые на вас собирают веб-сайты, и к данным, которые собирают провайдеры. Таким образом получается, что те, кто имеют возможность и желание вас отслеживать — имеют доступ к большинству возможных каналов утечки.

        Во-вторых, каналов утечки информации очень и очень много. И они очень разнообразны (от внезапно отключившегося VPN до получения реального IP через Flash/Java-плагины браузера или отправки серийника на свой сервер каким-нить приложением при попытке обновления). Более того, регулярно обнаруживаются (и создаются) новые. Поэтому попытка блокировать каждый из них в индивидуальном порядке, уникальными для каждого методами, просто не имеет смысла, всё-равно что-то где-то протечёт.

        В-третьих, при «работе в интернете» используется не только браузер — большинство пользуются так же IM, торрентами, почтой, SSH, FTP, IRC… при этом часто информация передаваемая по этим каналам пересекается и позволяет их связать между собой (.torrent-файл скачанный с сайта под вашим аккаунтом грузится в torrent клиент, ссылка пришедшая в письме/IM/IRC открывается в браузере, etc.). Добавьте сюда то, что ваша ОС и приложения тоже регулярно лазят в инет по своим делам, передавая при этом кучу деанонимизирующей вас информации…

        Из всего этого логически следует то, что пытаться добавить «немножко анонимности» путём использования браузера со встроенным Tor, или настройкой торрент-клиента на работу через SOCKS — нет смысла. Большинство вас не сможет отследить и без этих мер, а тех, кто имеет возможности и желание вас отследить эти меры не остановят (максимум — немного усложнят/замедлят их работу).
        Читать дальше →
      • Удобная разработка для OS Inferno в Vim

          FAQ: Что такое OS Inferno и зачем она нужна?

          Под инферно писать софт можно как внутри самой инферно (используя Acme IDE, компилятор limbo и mk для сборки), так и снаружи, в host os (используя любой редактор/IDE, и host os -версии limbo и mk) — при этом запускать инферно понадобится только для запуска тестов или отладки. Я подготовил несколько проектов/скриптов, которые предназначены упростить разработку под инферно вообще, и разработку используя Vim запущенный в host os в частности.
          Читать дальше →
        • Inferno Shell

            FAQ: Что такое OS Inferno и зачем она нужна?

            Оболочка ОС Инферно много лет вызывала у меня исключительно отрицательные эмоции. И я никогда не понимал, что в Inferno sh вызывает восторг у некоторых людей. Но, как говорится, лучше поздно чем никогда — сегодня я решил таки тщательно разобраться с шеллом, и в результате меня тоже проняло — это таки действительно уникальная вещь! Невероятно элегантная и простая.
            Читать дальше →
          • Inferno Часть 0: пространства имён

            • Перевод
            FAQ: Что такое OS Inferno и зачем она нужна?

            Я обещал, но ещё не написал пост о том, как установить и запустить Inferno, и делать невероятные вещи; я раздул его до серии статей, из которых это первая, вводная часть. Я собираюсь немного рассказать о пространствах имён (namespaces). Это критическая часть ОС, и одна из тех вещей, которые сильно отличают Plan 9 и Inferno от того, что сейчас работает на вашем компе.

            Inferno малоизвестна, и я не намерен её евангелизировать. Я хочу помочь сократить разрыв между предысторией и практикой, чтобы объяснить как использовать Inferno, и почему она работает так, как работает.

            Мне придётся немного отклониться в сторону. Я собираюсь поговорить об эволюции пространств имён, не совсем в хронологическом порядке, скорее в порядке развития возможностей, и потом показать как использовать возможности Inferno.
            Читать дальше →
          • Каталог статей по OS Inferno

              Практически каждая статья по OS Inferno вызывает вопросы из серии «что это такое и для чего оно нужно». Эти вопросы вполне уместны, но начинать каждую статью с ответа на этот вопрос невозможно — по крайней мере я не готов ответить на этот вопрос одним абзацем, а на развёрнутый ответ и целой статьи мало. Поэтому в данной статье будет поддерживаться полный каталог всех статей об ОС Инферно на хабре, и в новых статьях можно будет просто ссылаться на этот каталог.

              Обзоры OS Inferno


              Первое знакомство с OS Inferno … закончилось ничем, т.к. сработал стереотип «раз это ОС, значит она должна быть полноценной альтернативой традиционным десктопным или серверным ОС». Стыдно.

              Второе знакомство с OS Inferno … прошло намного удачнее — удалось избавиться от стереотипов и понять, как и для чего можно начинать использовать эту ОС.

              Поверхностный обзор OS Inferno … ну очень поверхностный, скорее просто список фич а не обзор.

              Архитектура OS Inferno — 1,
              Архитектура OS Inferno — 2,
              Графика в Inferno,
              Limbo,
              3 сущности! … этот цикл из 5-ти статей и есть обзор системы.
              Читать дальше →
            • Установка OS Inferno New Edition (update)

              • Tutorial
              FAQ: Что такое OS Inferno и зачем она нужна?

              Информация в предыдущем посте устарела почти на 4 года, и меня попросили её обновить. Так же попросили не смешивать в одном посте установку с настройкой, поэтому здесь будет только установка, а настройка инферно описана в отдельном посте. Update: Описание установки для Windows обновлено в июне 2014.

              Итак, мы будем устанавливать распределённую ОС Inferno. На официальном сайте есть инструкции по установке, но они не совсем корректны и тоже немного устарели. Inferno может работать в двух режимах — native (на голом железе или в qemu/etc. как все обычные ОС) и hosted (как обычное приложение под *NIX/Win). Инструкции по установке native Inferno можно найти в русской вики. Помимо этого существуют и другие варианты — например, установка Inferno на Android (англ.). Лично я смысла в использовании native Inferno на обычных компах не вижу, поэтому буду описывать установку hosted Inferno под Gentoo, Ubuntu, FreeBSD, MacOSX и Windows.
              Читать дальше →
            • GrSecurity/PaX: предустановленные security level

                (Статья для тех, кто уже в теме. Остальным будет интереснее сначала почитать мои предыдущие статьи про Hardened Gentoo: описание, установка, настройка, впечатления.)

                Речь пойдёт про настройку GrSecurity/PaX (я дал русскоязычные ссылки, но англоязычные намного информативнее) в ядре линуха. Всё описанное актуально для Hardened Gentoo (ядро 3.1.5), но применимо в любом дистрибутиве (там не будет предустановленных Gentoo-шных security level workstation/server/virtualization, но по моему описанию в этой статье их легко будет реализовать вручную).

                Кроме того я провёл небольшое тестирование производительности с целью определить насколько использование GrSecurity/PaX тормозит работу системы. Тесты проводились на Core2Duo в 32-битной OS в single user mode на компиляции ядра с -j3, бралось среднее значение user+sys по трём прогонам (скорость сборки ядра сравнивалась с эталонной: при отключенных GrSecurity и PaX в ядре и использовании обычного, не hardened, gcc).
                Читать дальше →
                • +17
                • 5,4k
                • 6
              • viewdoc — удобный доступ к любой документации

                  Для просмотра разной внешней документации (man/perldoc/pydoc/etc.) в Vim есть множество плагинов и рецептов. Проблема в том, что одни не настраиваются на открытие окон с документацией удобным мне способом, другие не расширяются для поддержки новых источников документации, третьи глючат и написаны слишком криво чтобы их можно было относительно просто пофиксить и выслать патч автору. На днях меня эта ситуация окончательно достала, и я написал плагин viewdoc, решающий все эти проблемы.

                  Он прост внутри и удобен в использовании, предоставляет единый пользовательский интерфейс для работы с любой документацией (включая встренный :help), умеет определять требуемую документацию по контексту, гибко настраивается, и очень просто расширяется (внешними плагинами или прямо в ~/.vimrc) для добавления новых источников документации. Основной недостаток — тестировался только в linux, может работать в других *nix, точно не будет работать в винде.
                  Читать дальше →
                • Простая минималистская реализация сложных JavaScript приложений

                  • Tutorial
                  Я хочу описать простой минималистский подход к разработке сложных JavaScript приложений. Из внешних библиотек будут использоваться только jQuery и мой js-шаблонизатор, причём из jQuery используются только $.ready(), $.ajax() и $.proxy() — т.е. суть не в библиотеках (их тривиально заменить на предпочитаемые вами), а в самом подходе.

                  В основе подхода лежат две идеи:
                  1. JavaScript виджеты — небольшие модули, каждый из которых «владеет» определённой частью веб-странички (т.е. всё управление этой частью странички происходит исключительно через методы этого модуля, а не через прямую модификацию DOM — инкапсуляция). Виджет отвечает исключительно за функциональность, но не за внешний вид; поэтому прямая модификация части DOM, которым «владеет» виджет, снаружи виджета допускается — но только для чисто дизайнерских задач (для архитектуры и общей сложности приложения нет принципиальной разницы между коррекцией внешнего вида через CSS или jQuery).
                  2. Глобальный диспетчер событий. Взаимодействие между виджетами осуществляется путём посылки сообщений глобальному диспетчеру (слабая связанность, паттерн Mediator/Посредник), а уже он принимает решение что с этим сообщением делать — создать/удалить виджеты, дёрнуть методы других виджетов, выполнить дизайнерский код, etc. В отличие от динамического подхода к обработке событий (когда обработчики конкретного события добавляются/удаляются в процессе работы) статический диспетчер сильно упрощает понимание и отладку кода. Безусловно, есть задачи, для которых нужны именно динамические обработчики событий, но в большинстве случаев это избыточное усложнение, поэтому всё, что можно, делается статическими обработчиками.

                  Читать дальше →
                • Избавляемся от PGP в почтовом ящике mutt

                  • Tutorial
                  На мой параноидальный взгляд по возможности всё общение по почте и IM должно быть зашифровано. (Не потому, что мне есть что скрывать, а просто потому, что я не вижу причин показывать свои сообщения соседу Пете, вне зависимости от того, где он работает — нигде, у провайдера, или в спецслужбе.) Для почты это PGP/GPG, для IM это OTR. Но это шифрование призвано защищать сообщения в процессе передачи по сети, а не на винте в почтовом ящике/логах IM. На винте от него толку нет, одни неприятности — медленный поиск в сообщениях (если в вашем MUA поиск вообще работает в зашифрованных письмах), невозможность обрабатывать почтовый ящик простыми скриптами, etc. Если есть необходимость шифровать данные у себя на винте, то для этого есть другие, более подходящие и универсальные средства, чем PGP для части писем.

                  Поскольку PGP требуется только во время передачи по сети, то было бы идеальным решением шифровать/дешифровать письма в момент приёма/передачи, т.е. используя локальный POP3/SMTP relay сервер. В этом случае все почтовые клиенты (MUA) автоматически получили бы «поддержку PGP», и при этом ничего о PGP сами не знали, и работали с не зашифрованными письмами. Под Windows такой сервер есть — GPGrelay. Под *NIX я аналога найти не смог. Есть утилитка kuvert, которая может автоматически шифровать исходящую почту, но утилитки для дешифровки входящей я не нашёл.

                  Но девиз mutt не зря «All mail clients suck. This one just sucks less.» — мне удалось с помощью его гибкости, небольшого вспомогательного скрипта для qmail, и такой-то матери решить эту, на первый взгляд банальную, задачку.
                  Читать дальше →
                  • +18
                  • 2,2k
                  • 9
                • Установка Perl-модулей в Gentoo

                  • Tutorial
                  imageСамый большой недостаток экосистемы языка Perl — управление модулями (другой кандидат на эту роль — долгострой Perl6, но не будем о нём). Что любопытно, самое большое достоинство этой же экосистемы — наличие единого архива модулей CPAN. Поразительно, собрать и организовать модули смогли, а реализовать удобную установку/обновление/удаление — нет.

                  Богатство выбора… или очередное TIMTOWTDI


                  imageСуществует множество альтернативных подходов к этой задаче (и их количество тоже косвенно указывает на то, что ни один из них не решает проблему достаточно хорошо): cpan, cpanplus, cpanminus, pip, cpansite, minicpan/mcpani, perlbrew, cpan-outdated, cpan-listchanges, local::lib, …

                  Итак, у нас может быть:
                  • Несколько версий самого perl (разумеется, каждая со своими глобальными модулями), в т.ч. установленные в домашний каталог юзера (см. perlbrew).
                  • Глобальные (доступные при запуске perl) и локальные (подключаемые из любого каталога/каталогов, обычно располагающиеся внутри отдельного проекта или в домашнем каталоге пользователя) модули.
                  • Глобальные модули бывают трёх типов: core (идущие вместе с perl), site (устанавливаемые вручную админом) и vendor (устанавливаемые менеджером пакетов вашей ОС).
                  • Все глобальные модули находятся в подкаталогах «номер.версии.perl/», и эти каталоги никто автоматически не чистит. А при установке новой версии perl создаются новые аналогичные каталоги. И perl подгружает модули из каталогов всех доступных предыдущих версий. Так что умножьте core+site+vendor на количество обновлений perl — вот в таком количестве каталогов/вариантов находятся ваши глобальные модули.
                  • Источники модулей тоже бывают разные: CPAN, локальные зеркала-оверлеи CPAN с приватными модулями, просто свои или скачанные из инета модули отсутствующие в CPAN-совместимой системе.
                  И всю эту радость надо администрировать: устанавливать, обновлять, … В Gentoo для упрощения администрирования глобальных Perl-модулей есть утилитка g-cpan, вот о ней я и хочу немного рассказать.
                  Читать дальше →
                • Разработка модулей для Limbo на C (часть 2)

                  • Tutorial
                  Часть 1

                  Содержание



                  Heap


                  Чтобы на C корректно создавать и уничтожать сложные структуры, с которыми будет работать код на Limbo, необходимо представлять себе как они хранятся в памяти, т.е. как организован heap в Inferno. Все упомянутые ниже функции для работы с heap описаны в libinterp/heap.c, а структуры в include/interp.h.
                  Читать дальше →