Пользователь
0,0
рейтинг
16 июня 2012 в 06:30

Установка 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.

Содержание



Особенности установки


Версии OS Inferno

Теоретически, последняя официальная версия «Fourth Edition» вышла примерно в 2004 году. Текущая версия находится в Mercurial репозитории на Google Code, и называет себя «New Edition». Практически, использовать что либо кроме текущей версии из репозитория нет смысла — она абсолютно стабильна, и всегда была стабильна. Её и будем ставить.

Одно- или много- пользовательский стиль установки

Инферно можно установить общесистемно (напр. в /usr/inferno/), чтобы все пользователи могли ей пользоваться. Инферно поддерживает всё, что для этого требуется — работу с правами пользователей, отдельные домашние каталоги, etc. С другой стороны, инферно можно поставить просто в свой домашний каталог (напр. в ~/inferno/), что даже удобнее. Прошлую статью я немного переусложнил описывая одновременно оба способа, но сейчас решил, что проще будет описать только однопользовательский вариант установки. Если у кого-то из читателей этой статьи есть сервер, на котором больше одного пользователя инферно — он вряд ли нуждается в моих инструкциях по установке инферно. ;-) Так что ставить будем в ~/inferno/ на *NIX системах, и в C:\inferno\ на винде.

32/64 бита

OS Inferno 32-битная. Поэтому для установки и запуска в 64-битных OS необходима поддержка 32-битных приложений в этих OS. К сожалению, под 64-битной FreeBSD-9.0 мне так и не удалось запустить инферно.

Hardened/PaX/SeLinux/etc.

Инферно выполняет код в виртуальной машине, плюс поддерживает JIT, поэтому у неё те же проблемы с разнообразными защитами что и у Java, etc. В предыдущей статье я уделил этой теме больше внимания, если возникнут вопросы — посмотрите там.

Время и место

Установленная инферно занимает примерно 200MB. А вот на установку компиляторов может потребоваться до 3-х с лишним гигабайт (например на Xcode или Visual Studio). Компилируется инферно буквально за пару минут на средней системе.

Расположение

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

Установка


В (Hardened) Gentoo Linux 32/64-bit всё тривиально — есть пакет, который ставит инферно общесистемно в /usr/inferno/:
layman -a powerman
emerge inferno

А с остальными операционками сейчас будем разбираться.

Mercurial, компиляторы и все все все

… Ubuntu 12.04 32-bit

sudo apt-get install -y mercurial
sudo apt-get install -y libxext-dev

… Ubuntu 12.04 64-bit

sudo apt-get install -y mercurial
sudo apt-get install -y libc6-dev-i386
sudo apt-get install -y libxext-dev:i386

… FreeBSD 8.0 32-bit

pkg_add -r mercurial

… Mac OS X 10.6.8 Snow Leopard 32-bit

У меня уже были установлены Xcode (3.2.2) и Mercurial (1.7.1).

… Mac OS X 10.7.4 Lion 64-bit

Устанавливаем Xcode (4.3.2) через App Store.
Запускаем Xcode, идём в меню Xcode — Preferences — Downloads и нажимаем Install для Command Line Tools.
Идём на mercurial.berkwood.com и качаем/ставим текущую версию (Mercurial 2.2.2 for OS X 10.7).

… Windows (XP 32-bit, Seven 32-bit, Seven 64-bit)

Идём на mercurial.selenic.com/downloads и качаем/ставим текущую версию (3.0.1).

А вот с компилятором есть варианты. Напрашивающийся вариант с установкой Visual Studio Express обойдётся в 3 с лишним гига на винте. Альтернативный вариант — поставить WinSDK — обойдётся примерно в 800 мегабайт. Я опишу оба варианта, выбирайте сами.

Первый вариант. Идём на www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-cpp-express и качаем/ставим/обновляем (по русскому обычаю — трижды :) иначе не все обновления установятся) «Visual C++ 2010 Express».

Второй вариант. Сначала идём на go.microsoft.com/fwlink/?LinkId=187668 и качаем/ставим полный ".NET Framework 4". Потом идём на www.microsoft.com/en-us/download/details.aspx?id=8279 и качаем/ставим «Windows SDK 7.1». При установке достаточно ограничиться этими пунктами:
#    Windows Native Code Development:
#          Windows Headers and Libraries:
#            [X] Windows Headers
#            [X] x86 Libraries
#      [X] Visual C++ Compilers
#    Redistributable Packages:
#      [X] Microsoft Visual C++ 2010
(В 2014 у меня SDK отказывался устанавливаться пока я не снёс все Visual C++ 2010 Redistributable — они оказались для него слишком новой версии.) Потом тоже обновляем. На самом деле обновлять, наверное, не обязательно, просто уже вошло в привычку.

Скачиваем и обновляем исходники инферно

Не смотря на то, что на официальном сайте для винды предлагается отдельный архив, а для мака отдельные бинарники, нам это всё не нужно, и даже вредно (архив для винды не обновляется нормально из репозитория — возникают конфликты). Так что под всеми ОС будем устанавливаться из inferno-20100120.tgz. Смысл использовать этот архив вместо простого клонирования репозитория в том, что в архив включены некоторые файлы (в основном шрифты), которые лицензия запрещает выкладывать на Google Code, поэтому в репозитории их нет.

… *NIX

wget http://www.vitanuova.com/dist/4e/inferno-20100120.tgz
tar xzf inferno-20100120.tgz
cd inferno/
hg pull -uv

… Win

Скачиваем www.vitanuova.com/dist/4e/inferno.zip (его рекомендуют на сайте, но можно взять и .tgz — у меня без проблем собираются и тот и другой).
Распаковываем в C:\inferno\. Не знаю, что нужно для распаковки .tgz под виндой — у меня стояли Far и 7Zip, распаковывал Far-ом.
Запускаем cmd.
cd \inferno
hg pull -uv

# если получаем конфликт вроде:
merging libinterp/keyring.h
warning: conflicts during merge.
merging libinterp/keyring.h incomplete! (edit conflicts, then use 'hg resolve --mark')
merging libinterp/runt.h
warning: conflicts during merge.
merging libinterp/runt.h incomplete! (edit conflicts, then use 'hg resolve --mark')
3038 files updated, 0 files merged, 106 files removed, 2 files unresolved
use 'hg resolve' to retry unresolved file merges
# то просто восстанавливаем последнюю версию:
hg revert -r tip libinterp\keyring.h
hg revert -r tip libinterp\runt.h
Выходим из cmd.

Настраиваем переменные окружения

Единственная реально необходимая переменная — это PATH. В EMU задаются параметры по умолчанию для запуска инферно, она нужна просто для удобства. Что касается INFERNO_ROOT то инферно про неё вообще не знает, эта переменная нам нужна просто для удобства. Помимо установки переменных в текущем сеансе, пропишем их в стартовые скрипты.

… Ubuntu

export INFERNO_ROOT=$(pwd)
export PATH=$INFERNO_ROOT/Linux/386/bin:$PATH
export EMU=-r$INFERNO_ROOT
echo "export INFERNO_ROOT=$INFERNO_ROOT"                   >> ~/.bashrc
echo "export PATH=\$INFERNO_ROOT/Linux/386/bin:\$PATH"    >> ~/.bashrc
echo "export EMU=-r\$INFERNO_ROOT"                         >> ~/.bashrc

… FreeBSD

export INFERNO_ROOT=$(pwd)
export PATH=$INFERNO_ROOT/FreeBSD/386/bin:$PATH
export EMU=-r$INFERNO_ROOT
echo "export INFERNO_ROOT=$INFERNO_ROOT"                   >> ~/.bash_profile
echo "export PATH=\$INFERNO_ROOT/FreeBSD/386/bin:\$PATH"  >> ~/.bash_profile
echo "export EMU=-r\$INFERNO_ROOT"                         >> ~/.bash_profile

… Mac OS X

export INFERNO_ROOT=$(pwd)
export PATH=$INFERNO_ROOT/MacOSX/386/bin:$PATH
export EMU=-r$INFERNO_ROOT
echo "export INFERNO_ROOT=$INFERNO_ROOT"                   >> ~/.bash_profile
echo "export PATH=\$INFERNO_ROOT/MacOSX/386/bin:\$PATH"   >> ~/.bash_profile
echo "export EMU=-r\$INFERNO_ROOT"                         >> ~/.bash_profile

… Win

Идём в: Панель Управления -> Система -> Дополнительные параметры системы (в XP просто «Дополнительно») -> Переменные среды.
Добавляем в конец Path: ;C:\inferno\Nt\386\bin
Создаём новую переменную: INFERNO_ROOT: C:\inferno
Создаём новую переменную: EMU: -rC:\inferno

Настраиваем параметры сборки

Можно отредактировать файл mkconfig вручную во всех ОС, но для простоты я, где возможно, приведу команды автоматически изменяющие конфиг.

… Ubuntu

perl -i -pe 's/^ROOT=.*/ROOT=$ENV{INFERNO_ROOT}/m'  mkconfig
perl -i -pe 's/^SYSHOST=.*/SYSHOST=Linux/m'         mkconfig
perl -i -pe 's/^OBJTYPE=.*/OBJTYPE=386/m'           mkconfig

В линухе инферно поддерживает IPv6. Более того, оный IPv6 используется по умолчанию. Подходит это вам или нет — решайте сами. Я лично его выключаю:
perl -i -pe 's/ipif6/ipif/g' emu/Linux/emu emu/Linux/emu-g

… FreeBSD

perl -i -pe 's/^ROOT=.*/ROOT=$ENV{INFERNO_ROOT}/m'  mkconfig
perl -i -pe 's/^SYSHOST=.*/SYSHOST=FreeBSD/m'       mkconfig
perl -i -pe 's/^OBJTYPE=.*/OBJTYPE=386/m'           mkconfig

… Mac OS X

perl -i -pe 's/^ROOT=.*/ROOT=$ENV{INFERNO_ROOT}/m'  mkconfig
perl -i -pe 's/^SYSHOST=.*/SYSHOST=MacOSX/m'        mkconfig
perl -i -pe 's/^OBJTYPE=.*/OBJTYPE=386/m'           mkconfig

… Win

Редактируем mkconfig:
ROOT=c:/inferno
SYSHOST=Nt
OBJTYPE=386

Сборка

… *NIX

sh makemk.sh
mk nuke
mk install          # пропустите эту команду на серверах без X-ов и GUI
mk CONF=emu-g install

… Win Seven 64-bit

Если вы ставили WinSDK, то нужно сделать новый ярлык на «Windows SDK 7.1 Command Prompt», зайти в его свойства и дописать параметр /x86 — чтобы получилось вот так:
C:\Windows\System32\cmd.exe /E:ON /V:ON /T:0E /K "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /x86
Если вы ставили Visual C++ 2010, то я не знаю, как запустить 32-битный компилятор (но возможно это делается примерно так же).
Что делать дальше — описано в следующем пункте для всех версий винды.

… Win

Запускаем «Windows SDK 7.1 Command Prompt» (ну или «Visual Studio Command Prompt (2010)» — смотря что вы устанавливали).
cd \inferno
mk nuke
mk install

Запуск


Собственно, это всё. Теперь вы можете запустить инферно командой emu или emu-g (вторая отличается тем, что не поддерживает графический режим, но зато будет работать на серверах без X-ов и очень удобна для запуска разных сетевых сервисов). Графическую среду можно увидеть запустив внутри emu команду wm/wm:
$ emu
; wm/wm



Полезные ссылки


Тем, кто не остановится на установке системы, может быть интересно почитать моё описание Limbo на русском, текущую версию man-документации в html, посмотреть на мои инферно модули и приложения и большой архив приложений под инферно от mjl. Англоязычное коммьюнити обитает в maillist-е и на IRC #inferno в сети freenode.

P.S.


Заранее отвечаю на традиционный вопрос «кому и зачем всё это нужно». В hosted режиме инферно используется примерно так же, как Erlang, Java или Go — для разработки приложений на классном языке программирования, которые выполняются в очень приятной среде, которые просто и комфортно писать и которые работают как минимум не хуже, чем аналогичные приложения на других языках. В отличие от Erlang в Inferno нет многих вещей «из коробки» (но они без проблем реализуются ручками при необходимости) зато это система общего назначения, пригодная для решения любых задач (ну, кроме низкоуровневых драйверов и т.п., как обычно). В отличие от Java мы имеем полноценные лёгкие нити и возможность писать простые многопоточные приложения в стиле CSP. В отличие от Go мы имеем виртуализированную и упрощённую среду, идентичную под любыми ОС. В общем, инферно действительно отличная система давно готовая к использованию в продакшне на коммерческих проектах (мы её именно там и используем) и заслуживает гораздо большей популярности, чем имеет.
Alex Efros @powerman
карма
300,5
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (30)

  • +4
    Извините, но «зачем это нужно» стоит писать в начале а не в конце статьи. Меня этот вопрос мучил на протяжении всей статьи. Отсылать на иностранную вики для пояснения не красиво, в старой статье тоже начинается с установки.
    Не приятное впечатление.
    • +3
      Несколько лет назад я написал на хабр целый цикл статей, посвящённых как раз этому вопросу — зачем это нужно. Кроме того, людям которые, к примеру, видели только винду или только линух, и никогда не слышали о другой ОС, можно очень долго перечислять какой смысл в существовании неизвестного им линуха/винды, что под ними можно делать полезного, и зачем это может быть нужно. Инферно в этом смысле ничем не хуже — причин её использовать и вариантов этого использования очень много, и если начинать каждую статью об инферно с этого перечисления, то до самой статьи дело уже просто не дойдёт.

      Например, лично меня в инферно привлекает возможность писать простые многопоточные приложения, работающие в простой и элегантной среде — это повышает скорость разработки, значительно уменьшает время и усилия необходимые для вылавливания и исправления ошибок, и, самое главное, значительно уменьшает испытываемое в процессе работы раздражение от несовершенства мира в целом и POSIX API в частности. :) Кого-то может привлечь возможность писать кросс-платформенные приложения на чём-то по-лучше Java и .NET. Кого-то — возможность прозрачно объединить и использовать ресурсы самых разных мелких железок и уже имеющихся ОС работающих на обычных машинах (к примеру сервер БД работающий под обычной ОС это ресурс не хуже чем какой-нить датчик, и к нему тоже можно организовать единообразный доступ из любой инферно запущенной в любом другом месте). Кого-то — возможность запустить на своём телефоне полностью «свою» систему со своими приложениями. Кого-то — возможность повышения своей квалификации как разработчика путём изучения исходников действительно простой и элегантной системы. И т.д. и т.п., возможных применений у инферно достаточно много.
  • +1
    я чего-то не понимаю в этой жизни. ОС для написания кросс-платформенных приложений? Это для тех, кому пользоваться SDK не достаточно хардкорно?
    • +4
      Если бы инферно изначально разрабатывалась просто для написания кросс-платформенных приложений, вероятно из неё получилась бы не ОС, а что-то другое, может быть и SDK. Насколько я понимаю, всё происходило примерно так. Возникла потребность в единообразном доступе к самым разным ресурсам предоставляемым самым разным железом, в т.ч. мелкими встроенными устройствами. Взяли существующую OS Plan9, подправили чтобы она работала на нужных железках с минимумом ресурсов (инферно для работы хватает 1MB RAM!), а для простоты разработки и переносимости приложений между всеми этими устройствами добавили виртуальную машину и переписали все приложения OS под неё. Благодаря тому, что все приложения ОС оказались внутри виртуалки, стало довольно просто их контролировать, и появилась возможность реализовать все необходимые виртуалке ресурсы не только через драйвера к реальному железу, но и через API обычных ОС.

      В результате получилась ОС, которая будучи запущена на каком-нить датчике с 1MB RAM, на фотоаппарате, на линух сервере или виндовой рабочей станции предоставляет единообразный доступ ко всем ресурсам всех этих систем и возможность писать приложения которые могут работать без изменений на любой из этих систем. Например, на виндовой рабочей станции может крутится приложение, которое при получении определённых показаний от датчика делает снимок фотоаппаратом и заливает его на какой-нить фотохостинг используя для доступа в инет сетевую подсистему линух сервера (что-то вроде NAT, только без NAT :)). При этом само приложение ничего про все эти детали знать не будет вообще — оно будет просто читать данные из одних файликов и писать в другие.

      Эти возможности несколько выходят за рамки простых кросс-платформенных приложений, не так ли? Вот поэтому оно и ОС, а не SDK.
  • 0
    Судя по описанию (на Гитхабе и Вашем), OS Inferno — это все же не «распределенная», а «распространяемая» ОС.
    В российской IT-традиции «распределенными» называют системы, работающие одновременно на нескольких узлах, с потенциальной возможностью одновременной обработки одного набора данных и, в современных ипостасях, даже прозрачного переноса уже запущенных процессов на другие хосты (как, например, в Cluster Server).
    А Инферно все же это «обычная» виртуальная машина, причем не интегрированная в ОС. Что-то среднее между VirtualBox и JVM. Неплохая, но все же пока «вторичная», как разные веб-ОС поверх Javascript в браузере.
    • +2
      Я не знаю насчёт «русской традиции», но есть термин Distributed operating system и инферно ему соответствует. Прозрачного переноса уже запущенных процессов в ней нет, но всё остальное наличествует. На русский этот термин переводится как «распределённая операционная система».

      Ваши рассуждения насчёт виртуальной машины тоже не соответствуют действительности. Во-первых инферно это не виртуальная машина. Инферно это операционка (по сути это вариант вполне традиционной OS Plan9), которая после загрузки запускает единственный процесс — виртуальную машину Dis, которая уже в свою очередь выполняет код всех других приложений. Так что если это не называется «VM интегрирована в ОС», то что тогда так называется? Средним между VirtualBox и JVM Dis тоже никак не является — это такая же VM как JVM, и ничего общего с VirtualBox там нет. В чём заключается «вторичность» я тоже не понял — инферно вполне работает на голом железе, на куче разных архитектур. Просто плюс к драйверам, которые работают с голым железом, в инферно написали драйвера, которые работают через syscall-ы *NIX/Win, и получили возможность запускать инферно поверх этих ОС вместо голого железа. Эта фича никак не делает инферно «вторичной».
  • +1
    Спасибо! Вряд ли буду ставить, но вдруг:)
    А про язык Limbo статью не напишете?
  • 0
    Все хорошо… только название зловещее. Что Лимб, что Инферно…
    • +1
      Волков бояться — в лес не ходить! ;-)

      Если честно, я подозреваю, что такие зловещие названия были выбраны не случайно. В Bell Labs работали отличные программисты, а они обычно не особо любят маркетологов и прочих sales, поэтому не исключено что названия были выбраны из вредности, с целью максимально осложнить им жизнь. Другое объяснение — просто не повезло. Кто-то из разработчиков читал в это время Данте, а мы все знаем, как сложно придумать названия своим проектам — вот он и мог пойти простым путём, взяв первые попавшиеся названия из читаемой в этот момент книжки, чтобы не морочить себе голову. Впрочем, повезло или не повезло этой операционке с названием это ещё вопрос, лично мне название нравится.
      • –3
        Отличные программисты обычно не любят маркетологов и sales? Ничо так стетеотипчики у вас в голове. На чем-то основанно, или так, из религиозных соображений?
        • +2
          У них цели слишком разные. Хорошему программисту интересно сделать элегантное решение, его интересует качество архитектуры, кода… и не очень интересуют сроки и стоимость. Маркетологам и продажникам нужно заработать денег, чем больше тем лучше, а что конкретно они продвигают и продают им обычно всё равно. Отсюда возникает конфликт интересов, причём вполне себе неизбежный. А из конфликта, когда на программиста давят с целью получить что-то, что можно будет продавать, как можно быстрее и дешевле, возникает та самая упомянутая мной не любовь.

          С точки зрения бизнеса «хороший» программист тот, который учитывает потребности бизнеса в своей работе, и, вместо вылизывания кода, как можно быстрее и дешевле релизит относительно рабочий (a.k.a. «good enough») продукт (а то и вообще нечто, что только выглядит рабочим продуктом). С точки зрения программирования, «хороший» программист тот, который пишет качественный и элегантный код. Судя по Вашему удивлению, Вы считаете что хорошие программисты должны учитывать требования бизнеса, и, соответственно, если они это делают, то причин не любить маркетологов и sales у них нет. А если они этого не делают, то называть их хорошими программистами некорректно. Я прав? Такая точка зрения вполне логична и приемлема. Но мне всё-таки ближе другое определение «хороший» программист или нет, не замутнённое требованиями бизнеса.
          • 0
            Я совершенно не согласен с тем, что цели у них разные. Цель программиста — написать хороший продукт. Sales более чем заинтересованы в том, чтобы продукты были хорошего качества. Где конфликт?
            Ваша предпосылка, что маркетологи и sales предпочитают продавать гавно и заставляют программистов поступаться качеством просто не верна, и именно она меня удивляет.
            И да, хорошие программисты обязаны учитывать одно требование бизнеса — требование качества.
            • 0
              Самое смешное в том, что я абсолютно с Вами согласен. В теории, именно так всё и должно быть. К сожалению, на практике всё обстоит иначе. Хотя иногда попадаются заповедные места. Я сейчас именно в таком и работаю. Но это исключение, а не правило. И даже я вижу, что с другим подходом можно было бы заработать намного больше денег. К счастью, владелец бизнеса не ставит перед собой задачу заработать как можно больше как можно быстрее.
              • 0
                На самом деле таких мест намного больше чем кажется. Любая долгосрочная стратегия предполагает как можно более близкое к идеальному качество. И ваш босс, поверьте, ставит перед собой задачу заработать как можно больше, но как вы правильно заметили, не как можно быстрее.
                Стереотип, что Sales и маркетинг готовы пожертвовать качеством лишь бы выпустить абы-что появился из нескольких хрестоматийных примеров, и к сожалению, очень живуч (см. минусы на мои коментарии). К счастью, это лишь стереотип. Найти компанию, в которой ценят качество, не преставляет труда (сложнее найти обратное). Тот-же Dell labs — прекрасный пример того, как убыточный business unit существует вполне безбедно, для того, чтобы повысить качество всей компании. Что характерно, в любой крупной компании существуют подобные innovations labs, убыточные по определению.
        • +1
          Это официальная версия. :)
          • +1
            Скандалы, интриги, расследования?
  • 0
    А вообще. Сижу я, никого не трогаю, выбираю себе асинхронную высоко производительную платформу для дальнейшего изучения. А тут как назло — то бенчмарки Эрланга, то новости про Go, то вы с Inferno. Теперь у меня кавардак в голове.
    • +2
      Все три варианта вполне достойные.

      Если основная задача — обучение и самообразование, то лучше займитесь инферно. Изучение исходников инферно/Plan9 реально очень сильно прочищает мозги и помогает многое понять о том, как надо и как не надо программировать, причём это даже в большей степени касается программистов с 10-15+ лет опыта, чем новичков.

      Если планируется использовать выбранную платформу в проекте, где кроме Вас будут и другие разработчики — лучше взять Go или Erlang. Инферно всё-таки совсем мало известная система, и Вам будет сложно объяснить необходимость её использования в проекте.

      Выбор между Go и Erlang определяется в большей степени характеристиками Вашего проекта — если он похож на те задачи, для которых изначально разрабатывался Erlang — лучше него Вы ничего не найдёте; если же проект более-менее общего назначения, то предпочтительнее использовать Go.
      • 0
        Веб-разработка, что же еще…
        • +2
          Веб-разработка тоже бывает разная. У меня в проекте сайты крутятся на Perl+FastCGI+libev. Perl удобен в плане обработки текста (разбор/генерация HTTP, рендеринг html-шаблонов), FastCGI+libev дают отличную скорость работы, но писать код в событийно-ориентированном стиле — это кучи callback-ов, которые довольно непросто понимать и контролировать. Поэтому основная функциональность вынесена в отдельные сетевые сервисы, часть из которых крутится на инферно, а часть на том же Perl+libev (ещё не дошли руки переписать на инферно).

          Теоретически можно полностью поднять сайт на инферно — у mjl (ссылка в конце статьи) есть для этого все необходимые приложения и библиотеки. Но я с этим пока не разбирался. Хотя в планах есть. Не думаю, что имеет смысл поднимать инферновский веб-сервер (вряд ли он будет корректно работать со всевозможными кривыми клиентами как это за столько лет научились делать apache и nginx), но вот FastCGI сервис на инферно поднять наверное смысл есть. По крайней мере можно будет избавиться от куч callback-ов и использовать нормальные нити. Тем более, что я прикрутил к инферно библиотечку re2, и теперь в инферно есть настоящие мощные и удобные регулярные выражения, даже лучше перловских.
  • 0
    Спасибо за статью.
    • 0
      PS «готовая к использованию в продакшне на коммерческих проектах (мы её именно там и используем)».
      В каких проектах используете?
      • 0
        В разных. У нас весь backend реализован в стиле SOA — много разных сетевых сервисов на разных серверах через которые проходит довольно большой поток данных 24x7. Когда начали внедрять инферно не рискнули переделывать всю архитектуру в стиле естественном для инферно (файловые интерфейсы и 9P) а просто реализовали часть этих обычных tcp-шных сетевых сервисов на инферно. После нескольких лет работы принято решение потихоньку переходить таки на более естественный для инферно стиль работы через 9P вместо tcp, но пока до этого руки ещё не дошли.
        • 0
          Честно не очень понимаю зачем заморачиваться с Инферно, но при этом отказываться от 9P?
          • 0
            Затем, что это коммерческий проект. Внедрение редких и непроверенных технологий вроде Инферно подразумевает высокие риски, которые требовалось минимизировать. Поэтому внедрение проводилось постепенно и осторожно, в частности ценой потери некоторой эффективности в связи с отказом от активного использования 9P с самого начала.
  • 0
    Обновил инструкции по установке для Windows.
    • 0
      Спасибо, что поддерживаете информацию в актуальном состоянии! :)
      зы: про 64битную версию ничего не слышно?)
      • 0
        Ничего нового вроде не слышно (несколько лет назад вроде бы пробегал патч в maillist-е, но на этом оно и заглохло). Впрочем, особой необходимости в 64-битной версии нет… разве что для того, чтобы не требовались 32-битные библиотеки для сборки.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.