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

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

Существует множество альтернативных подходов к этой задаче (и их количество тоже косвенно указывает на то, что ни один из них не решает проблему достаточно хорошо): 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, вот о ней я и хочу немного рассказать.

Часть 1

Содержание

• Heap
  
  • Что в памяти моей…
  • Немного о сборке мусора
  • Типы объектов в heap
  • Создаём свои сложные структуры в heap
• Array
  
  • adt и ref adt
• GC
  
  • Отключение объекта в heap от GC

Heap

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

Модули для Limbo написанные на C так же иногда называют драйверами OS Inferno т.к. они встроены в ядро OS. Необходимость в таких модулях обычно вызвана либо желанием добавить к Limbo отсутствующую в Inferno функциональность (подключить существующие 3rd-party C/C++ библиотеки, дать доступ к специфичным для конкретной host OS syscall-ам) либо желанием выжать максимально возможную производительность (по моим наблюдениям разница в скорости между Limbo с включенным JIT и C примерно 1.3-1.5 раза, но иногда и это может оказаться критичным).

Сейчас наличие нескольких подключений к интернет на одном, в том числе и домашнем сервере — не редкость. Городские локалки, ADSL, 3G модемы… Добавим к этому сети домашние локальные и внешние виртуальные (VPN), и получим ядрёную смесь интерфейсов, между которыми необходимо роутить трафик, балансировать трафик между разными каналами в интернет (когда они есть), и переключаться с нерабочих каналов на рабочие (когда они отваливаются).

Судя по постам в инете, большинство людей, столкнувшихся с этой ситуацией, очень плохо представляет себе, как это настраивается. Надо отметить, что в линухе действительно управление роутингом весьма сложное и запутанное — следствие эволюционного развития и поддержки (частичной) совместимости. Я хочу описать принципы настройки роутинга multihomed серверов на конкретном, достаточно сложном, примере: на сервере три физических сетевых интерфейса (один в домашнюю локалку и два к ADSL-модемам), два ADSL-подключения (ADSL-модемы в режиме bridge, так что pppd поднимает этот же сервер) к разным провайдерам (одно со статическим IP, второе с динамическим), плюс VPN на сервер компании — итого шесть интерфейсов.

Тема достаточно сложная, поэтому для понимания материала потребуется хотя бы минимальное понимание работы роутинга (что такое default route и gateway), файрвола (маркировка пакетов, отслеживание соединений, связь между разными таблицами и цепочками файрвола и роутингом), pppd (скрипты ip-up/ip-down) и протоколов IP и TCP.

К сожалению, встроенного механизма для распространения и установки дополнительного софта в OS Inferno нет. Если вы написали модуль для Limbo или полноценное приложение, и хотите им поделиться, то вариантов его распространения немного:

1. просто выложить ваши файлы на любом сайте, и предоставить пользователям вручную устанавливать их в свою систему куда и как угодно
2. использовать такие же mkfile/mkconfig файлы какие используются стандартными модулями и приложениями в /appl/

Как вы понимаете, первый вариант — это, фактически, не вариант. :) Это возврат назад, в пещеры. Второй вариант используется, например, для всего софта в репозитории mjl. Но и у этого подхода есть неприятные ограничения, вызванные тем, что ваши файлы в результате просто копируются в системные каталоги /dis/, /module/, etc. (точно так же, как стандартные модули и приложения из /appl/):

• если используется *nix как host OS, и Inferno установлена общесистемно root-ом или менеджером пакетов вашего дистрибутива, то для установки дополнительных модулей/приложений потребуются права root (либо sudo mk в host OS, либо sudo emu и нативный mk)
• глобальная установка неудобна, если хочется для своего приложения использовать модифицированную версию этих модулей/приложений
• глобальная установка неудобна, если разным приложениям нужны разные версии одного и того же модуля (mjl решает эту проблему традиционным для *nix способом добавляя номер major версии к имени модуля, что не очень элегантно и приводит к именам вроде «util0.m»)
• деинсталляция превращается в нетривиальную операцию, что в конечном итоге приводит к замусориванию системных каталогов
• имена модулей/приложений разных разработчиков могут конфликтовать (впрочем, эта проблема есть и в *nix/win, и её можно обойти используя подкаталоги в /dis/ и /module/ с именем разработчика или его сайта)

Я хочу предложить альтернативный подход, разработанный по мотивам DJB'шного slashpackage. Update: этот подход был недавно принят разработчиками инферно, так что его уже можно считать не альтернативным, а официальным. :)

Заметил странное поведение хабраленты (обычной, не 3.0, с url вида habrahabr.ru/rss/lenta/HEX_HERE): если не заходить на сайт, то RSS не обновляется. Использую встроенную читалку Opera 9.64/Linux. Даже если ручками нажать Update — всё-равно не обновляет. А если зайти на сайт — через некоторое время (или сразу, если снова нажать Update) RSS обновляется и приезжают новые топики.

Есть такая хорошая библиотечка: MatrixSSL. Маленькая, шустрая, безопасная… и, главное, со вполне вменяемым API, а не тем кошмаром, который в OpenSSL. Но у неё есть один недостаток: авторы релизнули библиотеку под GPL, а не LGPL, чтобы стимулировать юзеров покупать платную версию.

В связи с этим у меня вопрос к тем, кто разбирается в лицензировании: возможно ли избежать лицензирования приложения, использующего MatrixSSL, под GPL, если использовать следующий трюк. Пишется отдельное приложение, под GPL, которое работает как сетевой сервис: принимает RPC-запросы, отвечает на них… и которое фактически предоставляет через этот свой RPC-интерфейс доступ к API MatrixSSL. А основное приложение, хоть оно и будет использовать этот сетевой сервис, уже будет не под GPL.

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

Update: Судя по комментариям, необходимо уточнить, ещё раз (и, наверное, ещё много-много раз) — я ничего не имею против того, чтобы платить авторам такой классной библиотеки. Но релизить свой софт под GPL из-за неё я не хочу, я предпочитаю Public Domain или, в крайнем случае другие открытые лицензии, но не GPL-вирус!

В результате одной дискуссии на тему безопасных форумов/CMS на PHP мне пришла в голову идея: давайте вместе составим список безопасных веб-приложений! Задача списка — помогать при выборе приложения для установки и предоставить обзор текущей ситуации с безопасностью веб-приложений.

Изначально речь шла о форумах и CMS, но, думаю, ограничиваться этими двумя приложениями не обязательно. Для добавления приложения в список оно должно соответствовать нескольким критериям:

1. Вы его либо используете (использовали), либо знаете лично того, кто использует.
2. Это не должно быть узкоспециализированное приложение.
3. Бесплатное.
4. Open source.
5. Ну и самое главное: безопасное!

Я предлагаю определять безопасное приложение по следующим критериям:

• Первый публичный релиз был не менее двух лет назад.
• Для последней стабильной версии нет известных уязвимостей.
• В базе Common Vulnerabilities and Exposures (CVE) нет записей по этому приложению минимум за последний год (уязвимости в плагинах можно не учитывать, при условии что приложение вполне юзабельно без этих плагинов и в типовую инсталляцию они не входят).
• В случае отсутствия приложений, полностью подходящих под эти критерии, можно включать в список наиболее безопасное из существующих (отдельно для каждого ЯП).

Форум	Проверить	ЯП
YaBB	cve sf seclab milw0rm exploit ps secunia	Perl
phpBB 3	cve sf seclab milw0rm exploit ps secunia	PHP
Snitz Forum 2000	cve sf seclab milw0rm exploit ps secunia	ASP
CMS	Проверить	ЯП
papaya CMS	cve sf seclab milw0rm exploit ps secunia	PHP
eZ Publish	cve sf seclab milw0rm exploit ps secunia	PHP
Блог	Проверить	ЯП
Serendipity	cve sf seclab milw0rm exploit ps secunia	PHP
e-commerce	Проверить	ЯП
osCommerce	cve sf seclab milw0rm exploit ps secunia	PHP

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

Итак, вы написали некое приложение на Limbo, и хотите установить его на другую машину, или распространять через интернет. Скорее всего, там где будет устанавливаться это приложение OS Inferno не установлена. Это горько, но более чем вероятно. :) Что же делать? Обучать пользователей вашего приложения устанавливать и настраивать у себя OS Inferno? Включать полную инсталляцию Inferno (до 250 MB) в архив с каждым вашим приложением? Нет, всё гораздо проще!

Давайте посмотрим, как можно урезать Inferno до минимума, необходимого для работы вашего приложения. Для этого надо разобраться, что происходит при запуске emu — как загружается OS Inferno.

OUTDATED: Эта статья устарела, для установки под современными OS см. новую статью.

Update: Добавлено описание установки под Windows XP SP2.
Update: Добавлено описание установки под Mac OS X 10.4.8 Tiger.
Update: Добавлено описание установки под Mac OS X 10.5.5 Leopard.

New Edition

Да, версия в svn называет себя именно так! Установите, запустите браузер (Charon) и сами убедитесь. (В принципе, последний релиз это "Fourth Edition", но на практике это уже давно тот же svn — «Fourth Edition» вышел примерно в 2004, а сейчас на офф.сайте под видом «Fourth Edition» выложен снапшот svn от 20071003.)

Версия в svn абсолютно стабильна, и, в отличие от инсталляшки «Fourth Edition», её значительно проще обновлять. Для установки на боевые сервера или выпуска вашего приложения она не менее удобна. В общем, минусом является только необходимость иметь subversion и компилятор для сборки системы, всё остальное плюсы.

Итак, ставим свеженькую OS Inferno из SVN, в hosted режиме (т.е. в виде эмулятора, работающего под другой OS).

Вы думали, что "настоящие мужчины используют Windows"? Вы крупно ошибались. Они используют IDE Acme. Которую среди прочего отличает отсутствие подсветки синтаксиса.

Причём это не потому, что Acme ещё молода, и просто не успела обзавестись такой, критически важной для IDE, фичей. (Не знаю точно, сколько лет Acme, но Пайк ещё в 1994 выпустил статью "Acme — A User Interface for Programmers".) Нет, дело в другом! Эта «фича» считается ненужной, и даже вредной.

В OS Inferno очень необычно сделана работа с пользователями. Во-первых, когда запускается emu, вы получаете командную строку без необходимости вводить логин и пароль. При этом ваше имя пользователя выставляется таким же, как и в основной системе (host OS). Во-вторых, вы можете запустить, например, wm/wm wm/login, ввести имя другого пользователя (причём пароль у вас даже не спросят), и продолжить работу как этот пользователь. Аналогично можно воспользоваться командой runas ИМЯПОЛЬЗОВАТЕЛЯ sh, чтобы не запускать графическую оболочку.

В связи со всем этим возникает логичный вопрос: Inferno — многопользовательская система, или нет?

Вот так компактно выглядит моя Opera. Достигается это простым трюком: вернее меню отключаем, вместо него включаем «Main Bar», на который накидываем кнопки-аналоги нужных пунктов меню, плюс любые полезные штуки.

P.S. Если названия кнопок слишком длинные (типа «Перевод на русский (PROMPT)»), то можно выйти из оперы и отредактировать имена в ~/.opera/toolbar/*.ini. Возможно есть более простой способ, но я его не нашёл.

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

Основная проблема в том, что бакап не относится к тем вещам, которые можно сделать не думая! Если попытаться тупо запаковать всё содержимое винта, то во-первых вам негде будет эти архивы (ежедневные! :)) хранить, и во-вторых ваша машина будет круглосуточно заниматься архивированием себя, любимой, вместо выполнения ваших задач. А когда начинаешь думать (что уже непросто), то оказывается, что данные на винте очень разные, и бакапить их желательно тоже по-разному (что окончательно осложняет ситуацию). Как следствие, либо принимается решение не делать бакапы вообще (замаскированное под «отложить на потом»), либо ставится первая попавшаяся утилита и кое-как быстро настраивается, в надежде, что этого будет достаточно.

Пока я не стал фрилансером, я не знал, что такое спам. У меня хватало ума не светить свой email где попало, а для регистраций на сайтах использовать временные email. И я привык к тому, что вся почта у меня бегает очень быстро, письма никогда не теряются, и никто не жалуется что мой сервер отказался принимать его письмо. Став фрилансером, я оказался вынужден опубликовать свой email, причём на многих сайтах — ведь новые клиенты должны иметь возможность легко со мной связаться. И спам полился… сначала небольшим ручейком, но в последнее время он уже напоминает скорее полноводную реку, чем ручеёк.

Использование традиционных спам-фильтров (RBL, GMail, SpamAssassin, etc.) меня не устроило: все они время от времени ошибаются, и принимают за спам нормальные письма. И не важно, они их давят, возвращают отправителю, или складируют в отдельную папку чтобы я их периодически просматривал — в любом случае есть ненулевая вероятность потерять важное письмо.

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

Я познакомился с линухом много лет назад. И для меня был только один человек, которого я могу в каком-то смысле считать своим «гуру». Я в то время хорошо знал DOS, весьма поверхностно OS/2 и Win3.1, держал свою BBS и был нодом в Fido. В общем, сама по себе командная строка, чисто внешне, меня даже привлекала, но… в остальном мой опыт был абсолютно бесполезен. А он работал админом у местного провайдера.

Update: Статья и скрипты были обновлены в марте 2013 (прошло 5 лет, старые скрипты не сильно отличаются от текущих, но всё-таки лучше изучать актуальный код, а логика загрузки системы за эти годы немного изменилась — иначе работает udev, появились новые синтетические fs вроде devtmpfs, /var/run переехал в /run, etc.).

Когда я осваивал Linux, мне было очень интересно что происходит при загрузке системы. Попытка разобраться в процессе загрузки привела меня в исходники загрузочных скриптов (/etc/inittab, /etc/rc*, /etc/init.d/*, ...) и их конфигов (/etc/sysconfig/*, /etc/cond.f/*, ...). Надо отметить серьёзные размеры и сложность этих скриптов — чтобы в них разобраться потребовалось немало времени. Но я в те времена искренне верил, что загрузка это сложный процесс, и что размеры и сложность загрузочных скриптов вполне оправданы.

Когда меня окончательно достал RedHat (2001 год), я решил собрать свой дистрибутив на базе LFS. Для своего дистрибутива пришлось самостоятельно разрабатывать загрузочные скрипты, и тут-то выяснилась правда: ничего сложного в процессе загрузки нет!

Решил наконец-то поднять у себя персональный OpenID сервер (ну да, я параноик, не хочу чтобы кто-то ещё собирал информацию на каких сайтах я бываю). Причём хотелось чтобы он был написан на Perl. Поискал в сети — нету! Более того, невероятно, но на CPAN только два модуля для OpenID, один жутко раздутый и явно недописанный, а второй вроде бы неплохой (Net::OpenID::Server Фитцпатрика), но документации и примеров для него практически нет. :(

В общем, за 6 часов написал свой сервер: OpenIDsrv. Может пригодится другим параноикам или в качестве дополнения к документации на Net::OpenID::Server.

Современная память (DRAM), вопреки общепринятому мнению, хранит информацию после отключения питания от нескольких секунд до нескольких минут (а если её охладить жидким азотом — до нескольких часов). Что даёт возможность, например, отключить питание загруженного компа, переставить память в другой комп, и загрузить на нем специальную утилиту, которая просканирует память и найдёт в ней ключи шифрования диска. Или не переставлять никуда память, а просто подключить USB-винт к взламываемому компу, и после передёргивания питания загрузиться с него. Взлом подтверждён для BitLocker, FileVault, dm-crypt, и TrueCrypt.

New Research Result: Cold Boot Attacks on Disk Encryption
Lest We Remember: Cold Boot Attacks on Encryption Keys (с видео)

Я только что из любопытства воспользовался Дзен-поиском Яндекса. Запрос выпал довольно любопытный: «kjlrf FVEH». На этот запрос Яндекс ответил следующее: «Запрос исправлен на «лодка АМУР», так как для «kjlrf FVEH» ничего не найдено.».

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