Язык программирования в операционной системе inferno. внутреннее окружение приложений 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

Описание Inferno

Напишите отзыв о статье "Inferno (операционная система)"

Примечания

См. также

Ссылки

  • (англ.)
  • с официальными исходниками (англ.)
  • (рус.)
  • (рус.)
  • (рус.)
  • (рус.)
  • - статья, содержащая перечень ссылок на другие ресурсы по Inferno (рус.)
  • (англ.)
  • (рус.)
  • (рус.)

Отрывок, характеризующий Inferno (операционная система)

– Это метампсикова, – сказала Соня, которая всегда хорошо училась и все помнила. – Египтяне верили, что наши души были в животных и опять пойдут в животных.
– Нет, знаешь, я не верю этому, чтобы мы были в животных, – сказала Наташа тем же шопотом, хотя музыка и кончилась, – а я знаю наверное, что мы были ангелами там где то и здесь были, и от этого всё помним…
– Можно мне присоединиться к вам? – сказал тихо подошедший Диммлер и подсел к ним.
– Ежели бы мы были ангелами, так за что же мы попали ниже? – сказал Николай. – Нет, это не может быть!
– Не ниже, кто тебе сказал, что ниже?… Почему я знаю, чем я была прежде, – с убеждением возразила Наташа. – Ведь душа бессмертна… стало быть, ежели я буду жить всегда, так я и прежде жила, целую вечность жила.
– Да, но трудно нам представить вечность, – сказал Диммлер, который подошел к молодым людям с кроткой презрительной улыбкой, но теперь говорил так же тихо и серьезно, как и они.
– Отчего же трудно представить вечность? – сказала Наташа. – Нынче будет, завтра будет, всегда будет и вчера было и третьего дня было…
– Наташа! теперь твой черед. Спой мне что нибудь, – послышался голос графини. – Что вы уселись, точно заговорщики.
– Мама! мне так не хочется, – сказала Наташа, но вместе с тем встала.
Всем им, даже и немолодому Диммлеру, не хотелось прерывать разговор и уходить из уголка диванного, но Наташа встала, и Николай сел за клавикорды. Как всегда, став на средину залы и выбрав выгоднейшее место для резонанса, Наташа начала петь любимую пьесу своей матери.
Она сказала, что ей не хотелось петь, но она давно прежде, и долго после не пела так, как она пела в этот вечер. Граф Илья Андреич из кабинета, где он беседовал с Митинькой, слышал ее пенье, и как ученик, торопящийся итти играть, доканчивая урок, путался в словах, отдавая приказания управляющему и наконец замолчал, и Митинька, тоже слушая, молча с улыбкой, стоял перед графом. Николай не спускал глаз с сестры, и вместе с нею переводил дыхание. Соня, слушая, думала о том, какая громадная разница была между ей и ее другом и как невозможно было ей хоть на сколько нибудь быть столь обворожительной, как ее кузина. Старая графиня сидела с счастливо грустной улыбкой и слезами на глазах, изредка покачивая головой. Она думала и о Наташе, и о своей молодости, и о том, как что то неестественное и страшное есть в этом предстоящем браке Наташи с князем Андреем.
Диммлер, подсев к графине и закрыв глаза, слушал.
– Нет, графиня, – сказал он наконец, – это талант европейский, ей учиться нечего, этой мягкости, нежности, силы…
– Ах! как я боюсь за нее, как я боюсь, – сказала графиня, не помня, с кем она говорит. Ее материнское чутье говорило ей, что чего то слишком много в Наташе, и что от этого она не будет счастлива. Наташа не кончила еще петь, как в комнату вбежал восторженный четырнадцатилетний Петя с известием, что пришли ряженые.
Наташа вдруг остановилась.
– Дурак! – закричала она на брата, подбежала к стулу, упала на него и зарыдала так, что долго потом не могла остановиться.
– Ничего, маменька, право ничего, так: Петя испугал меня, – говорила она, стараясь улыбаться, но слезы всё текли и всхлипывания сдавливали горло.
Наряженные дворовые, медведи, турки, трактирщики, барыни, страшные и смешные, принеся с собою холод и веселье, сначала робко жались в передней; потом, прячась один за другого, вытеснялись в залу; и сначала застенчиво, а потом всё веселее и дружнее начались песни, пляски, хоровые и святочные игры. Графиня, узнав лица и посмеявшись на наряженных, ушла в гостиную. Граф Илья Андреич с сияющей улыбкой сидел в зале, одобряя играющих. Молодежь исчезла куда то.

Вот уже почти тридцать лет Plan 9 будоражит умы юниксоидов. Операционная система, на десятилетия опередившая свое время, оказалась просто не нужна и была выброшена на обочину айтишного мира. Inferno, ее преемница, оказалась еще менее востребованной и в конце концов нашла свою смерть в руках никому не известной компании Vita Nuova. Однако обе системы и по сей день продолжают допиливаться отдельными разработчиками и даже применяются для решения узкого круга задач. Появилось множество форков, большая часть из них умерли, а некоторые живут и по сей день. Едва ли не самый интересный из них - Node9, симбиоз платформы Inferno и языка Lua, способный потягаться с великим и ужасным Erlang.

Вместо введения

Я уже давно слежу за развитием Inferno и Plan 9, читаю листы рассылки, оцениваю форки, время от времени всплывающие на GitHub, а нередко и сам пишу что-нибудь незамысловатое на Limbo, стандартном языке Inferno. Поэтому проект Node9, базирующийся на идеях Inferno и использующий один из моих любимых и, как мне кажется, сильно недооцененный язык Lua, сразу привлек мое внимание. И как оказалось, не зря. Проект действительно оказался более чем серьезным и гораздо более развитым, чем все остальные «варианты» системы, виденные мной до этого. Что такое Node9? В терминологии самих разработчиков это hosted operating system, а в более привычной нам формулировке - среда или даже, лучше сказать, платформа для запуска распределенных приложений. Node9 базируется на идеях и технологиях Inferno и Plan 9, которые должны быть известны многим читателям. Тем не менее без некоторых пояснений не обойтись.

В свое время в основу Plan 9 легла идея единого IPC-механизма, который бы позволял обмениваться данными как локальным, так и удаленным процессам. Предполагалось, что вся система будет построена вокруг этого механизма, поэтому уже на ранних этапах разработки ОС был спроектирован протокол 9P (в Inferno его переименовали в Styx), отвечающий за его реализацию. А все остальные компоненты системы, включая драйверы, графический стек и обычные приложения, использовали его для взаимодействия друг с другом.

Ключевая особенность 9P в том, что, по сути, это протокол доступа к удаленным (и локальным) файлам. Поэтому в Plan 9 буквально все было представлено (синтетическими) файлами, начиная от указателя мыши и заканчивая сетевым стеком. Многие вполне обычные приложения также предоставляли доступ к «своим файлам» с целью обмена данными с другими приложениями. Даже настройка системы осуществлялась не через конфиги, а с помощью скриптов, записывающих те или иные значения в файлы. А самое главное - одна Plan 9 машина могла смонтировать всю или часть файловой системы другой машины по сети и использовать ее файлы для взаимодействия с удаленными приложениями, то есть, по сути, выполнять удаленный вызов процедур (RPC). Такой подход позволял из коробки получить многие интересные вещи, включая удаленный рабочий стол (дисплей, клавиатура и мышь - это ведь тоже файлы), удаленный доступ к периферии, простое и удобное масштабирование вычислительных систем. Мой излюбленный пример - реализация NAT. В Plan 9 она вообще не нужна, достаточно смонтировать каталог /net (содержит файлы сетевого стека) удаленной машины поверх локального, и все запущенные после этого приложения будут использовать сетевой стек этой машины.

По идее, такой трюк не должен работать, так как для доступа к сетевому стеку удаленной машины нужен сетевой стек локальной. Но в Plan 9 это работает, благодаря так называемым пространствам имен. Это еще один ключевой механизм Plan 9, который гарантирует, что любые изменения файлового дерева, видимого одному процессу, не отразятся на файловых деревьях, видимых другим процессам. Возвращаясь к примеру с NAT, это значит, что смонтированный сетевой стек удаленной машины будет виден только смонтировавшему его процессу и его потомкам, тогда как все остальные процессы будут продолжать работать с локальным сетевым стеком. Это очень мощный механизм, позволяющий создавать различные окружения для процессов, а также контролировать их доступ к ресурсам (кстати, песочницы OpenVZ, LXC и Docker в Linux используют ту же идею пространств имен).

Последнее, что важно для нас в контексте введения в Node9, - это каналы и потоки. Язык Limbo, используемый в Inferno по умолчанию, оснащен очень простой и эффективной системой многопоточности, которая, кстати говоря, впоследствии перекочевала в язык Go. Суть ее проста до безобразия: в любой момент любую функцию можно отправить в отдельный поток, вызвав ее с помощью ключевого слова spawn. Нечто подобное есть в чистом Lua и некоторых других языках, но важно не это. Важно то, что при вызове такой функции можно указать в ее аргументах канал передачи данных (есть такой тип данных в Limbo), через который она сможет общаться с дочерним потоком. Это называется модель многопоточности CSP , и она применяется в Limbo и Go для синхронизации потоков и обмена данными между ними. Но что самое интересное, канал можно превратить в файл! И конечно же, этот файл (точнее, каталог, его содержащий) можно смонтировать с удаленной машины. Брюки превращаются… в распределенное приложение.

Соберем все это вместе и получим потрясающую платформу для создания распределенных приложений. Проблема только в том, что Plan 9 сама по себе довольно маргинальная система, и внедрять ее в продакшен никто не будет. Inferno, с другой стороны, способна работать поверх других систем, включая Linux, OS X и Windows, но использует язык Limbo, который хоть и имеет низкий порог вхождения, но почти никому не известен и не располагает хорошей базой готовых библиотек. Именно по этой причине появился Node9.

Кто и как использует Inferno и Plan 9

  • Компания Coarid применяет Plan 9 и ее компоненты в своих решениях NAS.
  • IBM использовала Plan 9 и некоторые компоненты Inferno на одной из своих суперкомпьютерных систем Blue Gene/L, построенной на базе 64 тысяч процессоров.
  • ОС Plan 9 использовалась для управления системой освещения стадиона на Олимпийских играх в Сиднее в 2000 году.
  • Долгое время операционная система Inferno применялась в некоторых аппаратных решениях Lucent (позднее Alcatel-Lucent), таких как файрволы и шлюзы. Достоверно известно, что внутри Lucent Managed Firewall, Lucent VPN Firewall Portfolio и Lucent Pathstar скрыта именно ОС Inferno.
  • На основе операционной системы Inferno работали некоторые модели аппаратов для SIP-телефонии, в частности Philips IS2630 и Alcatel Webtouch.
  • Некоторые исследовательские центры и университеты выбирают Inferno в качестве платформы для grid-вычислений: Cambridge Crystallography Data Centre (CCDC), The University of York Department of Biology, Rutgers University Libraries, Evotec OAI AG (Deutsche Boerse EVT; TecDAX 30), Montclair State University.

Inferno, LuaJIT, libuv и все-все-все

Итак, Node9 - это симбиоз низкоуровневой части hosted-версии (работающей поверх другой ОС) Inferno, быстрого JIT-компилятора LuaJIT и библиотеки асинхронной обработки событий libuv, изначально разработанной для Node.js, а теперь используемой и другими проектами. Что все это дает стороннему разработчику? Ну, во-первых, это, конечно же, весь тот комплекс фирменных технологий Inferno / Plan 9 с возможностью писать софт на достаточно распространенном и очень простом в освоении языке Lua, снабженном эффективным JIT-компилятором LuaJIT.

В-вторых, это простая многопоточная модель, реализованная внутри самой платформы. В Node9 все процессы и потоки работают внутри одного процесса нижележащей ОС. Это значит, что для переключения между потоками не потребуется переключение контекста, а это может дать серьезный выигрыш в производительности. Ну и плюс ко всему уже обсуждавшаяся ранее модель CSP на основе функций, каналов и файлов, привязанных к каналам. CSP намного эффективнее традиционных реализаций многопоточности и, по сути, решает почти все проблемы распараллеленных приложений. Потоки здесь не делят одно адресное пространство (область видимости потока = области видимости функции), они не получают доступ к одним и тем же данным, а вместо этого используют синхронные сообщения (нет проблемы блокировок), их очень просто синхронизировать.

В-третьих, эффективная система асинхронной обработки событий (I/O, TCP, UDP, TTY), не погружающая программиста в callback hell, известный любому разработчику на Node.js. Node9 опирается на libuv во всем, что касается обработки ввода-вывода. Поэтому даже системные вызовы (если их можно так назвать в контексте «ОС, работающей поверх ОС») здесь реализованы через «событийный цикл». Работает это так. Планировщик Node9 последовательно передает управление каждому работающему потоку до тех пор, пока один из них не сделает системный вызов. В этот момент запускается примерно такая функция (в данном случае функция read):

Function S.read(vp, s_read, fd, buf, nbytes) s_read.fd = fd s_read.buf = buf s_read.nbytes = nbytes n9.sysreq(vp, n9.Sys_read) coroutine.yield() return s_read.ret end

Она помещает системный вызов в очередь libuv (функция n9.sysreq()), затем приостанавливает исполнение текущего потока и возвращает управление обратно. После этого планировщик передает управление следующему потоку, а по исчерпании очереди потоков запускает один проход событийного цикла libuv (проверка, получены ли запрошенные данные, в данном случае с диска или по сети, Node9 не делает различий). Затем все начинается сначала. Если же в ходе цикла libuv обнаруживает получение данных, управление возвращается сделавшему системный вызов потоку. Вдумчивый читатель может сказать, что все это сильно напоминает идею так называемых зеленых потоков , реализованную в Smalltalk, Tcl, Erlang, и будет абсолютно прав. Как и ее родоначальница Inferno, Node9 полностью основана на этой модели, но с привлечением возможностей libuv и языком Lua вместо Limbo. Реализация программной платформы на основе «зеленых потоков» уже неоднократно доказывала свою эффективность, и она почти не проигрывает событийной модели, применяемой в Node.js и nginx. Однако в отличие от последних она позволяет «просто писать код» и не переиначивать свое мышление в пользу callback-ориентированного программирования, что чревато ошибками и сильным запутыванием кода.

Благодаря тому что Node9 построена вокруг протокола 9P, ее приложения очень просто связать с приложениями на любых других языках, для которых есть библиотека с реализацией 9P. А таких языков много, это чистый си, Go, Java и множество других. И да, все они будут доступны удаленно.

Пробуем

В данный момент Node9 находится в стадии пре-бета. Работать она работает, софт запускать позволяет, планировщик планирует, libuv обрабатывает, однако многие функции Inferno до сих пор остаются нереализованными. Например, пока что нет возможности создать файловый сервер (в терминологии Plan 9 / Inferno это приложение, экспортирующее собственные интерфейсы через файлы), невозможно смонтировать каталоговую структуру удаленной машины, но можно открыть для монтирования для Plan 9 машин. Тем не менее с платформой уже есть смысл познакомится хотя бы для оценки ее возможностей в текущем состоянии (веб-приложение для нее можно написать уже сейчас).

Итак, Node9 доступна на GitHub и в данный момент умеет работать только в OS X и Linux, а после полного перевода системы на libuv заявлена поддержка множества других систем. Устанавливаем git и клонируем репозиторий:

$ git clone https://github.com/jvburnes/node9.git $ cd node9

Сборка системы осуществляется с помощью приложения premake , а для сборки LuaJIT понадобится еще и automake. Все остальные инструменты сборки стандартные, поэтому установки пакета build-essential в Ubuntu и его аналогов в других дистрибутивах будет достаточно. После этого просто запускаем сборочный скрипт и ждем:

$ ./rebuild.sh

После успешного завершения компиляции запускаем систему (любители белых яблочек заменяют LD_LIBRARY_PATH на DYLD_LIBRARY_PATH):

$ export LD_LIBRARY_PATH=./lib $ bin/node9

На экран должно вывалиться приглашение командной строки. Это местный шелл, возможностей у него кот наплакал: стандартные cd, ls, cat и несколько команд, которые ты найдешь в каталоге fs/appl. Сама система будет заперта в песочнице, корнем которой будет каталог fs внутри каталога с установленным Node9. Предварив команду пробелом, ее можно превратить в Lua-выражение. Никаких стандартных для UNIX пайпов и перенаправления ввода-вывода пока нет, только три команды, только хардкор.


Для запуска своего Lua-скрипта просто кладем его в fs/appl, а затем запускаем как обычную команду, опустив расширение (.lua). API здесь отличается от стандартного Lua. Базовые «системные вызовы» включены в модуль sys. Чтобы ознакомиться с ними, можно почитать исходник appl/syscall.lua. Модуля для сетевого взаимодействия нет вообще, вместо него, как и положено, файлы, в данном случае каталог /net. Чтобы узнать, как с ним работать, можно почитать исходники в каталоге fs/appl. Также в состав включена Lua-библиотека Penlight с набором функций для манипуляции с разными типами данных. В остальном ничего экстраординарного. Обычный проект в своей постначальной стадии развития. Готовый каркас, который осталось только допилить и завернуть в красивую упаковку.



Выводы

Node9 - более чем интересный проект. Его разработчики решили исправить то, чем Inferno всегда отпугивала программистов. Я сильно сомневаюсь, что эта система когда-нибудь приобретет большую известность, хотя бы потому, что Lua у многих программистов не ассоциируется с чем-то серьезным (даже если таковым является). Но свою нишу она вполне способна занять, благо большая часть работ по разработке платформы уже выполнена.

;
3. Установка системы и приложения (Вы читаете данный раздел).
От теории - к практике. Операционная система Inferno поставляется в виде исходных текстов, которые можно скачать с официального сайта (http://www.vitanuova.com/inferno/downloads.html) или получить через систему контроля версий Mercurial (в этом случае вы получите более новую и, вероятно, менее стабильную версию системы).

Короткая инструкция по сборке находится в файле INSTALL, а за более детальным описанием можно обратиться к русскоязычной статье: http://inferno.execbit.ru/wiki.wsgi/Установка. К слову, в другом сетевом материале (http://habrahabr.ru/blogs/os inferno/42998) описан не только процесс инсталляции из исходников, но и некоторые первичные настройки, а сайт производителя предлагает подробную документацию (http://www.vitanuova.com/inferno/docs.html) уже на английском языке: полное руководство пользователя, обзор протокола Styx, описание процесса разработки приложений для ОС, документация по Limbo и т.п.

Доступность исходников позволила энтузиастам скомпилировать и запустить Inferno на платформах, поддержка которых официально не заявлена - например, на Android и Nintendo DS (см. рис. ниже).


Запуск Inferno на Nintendo DS


Готовых приложений для Inferno пока немного - система заняла специфическую нишу. Она выступает как платформа для создания узконаправленных распределенных приложений для решения конкретных задач. Существующего набора софта достаточно для комфортной разработки приложений и взаимодействия с сетью.

Для Inferno созданы текстовые редакторы, ряд серверов, клиент электронной почты, браузеры, полный пакет инструментов для разработки ПО, включающий компилятор языка Limbo и библиотеки для него, ассемблер и дизассемблер кода для виртуальной машины Dis, отладчик, профилировщик, генератор синтаксических анализаторов и прочее. Существуют даже несколько простых игр, таких как «Сапер», «Тетрис» и «Змейка».
С довольно подробным списком существующего для Inferno софта (как системного, так и прикладного) можно ознакомиться в Википедии: http://en.wikipedia.org/wiki/List of Inferno applications.

Централизованного хранилища программ для Inferno не существует, да и вообще отмечу, что сторонние приложения для Inferno - явление редкое. Однако, покопавшись на тематических ресурсах, можно кое-что отыскать.

Например, мне удалось найти VNC-просмотрщик, альтернативный менеджер окон, клиент для СУБД MySQL, клиент и сервер NFS, модули поддержки разных файловых систем, компиляторы и интерпретаторы разных языков программирования.

Некоторые разработчики создали серверы с собственным ПО для Inferno, пример тому -ресурс www.ueber.net/code (автор - Mechiel Lukkien).

Выводы



В операционной системе Inferno реализованы многие интересные идеи. Пусть на сегодня каждая из них уже не является уникальной, другого продукта, объединяющего все эти концепции, попросту нет.

Несмотря на малую популярность, в чисто техническом плане Inferno - это, возможно, одна из самых «правильно» реализованных платформ. Причины низкой распространенности банальны: изначально не нацеленная на массы маркетинговая политика, скудный выбор программного обеспечения (и сложность портирования софта, существующего на других платформах), ограниченная поддержка оборудования и многие другие факторы. Впрочем, все это не мешает компании Vita Nuova продавать решения на основе Inferno производителям электроники, разработчикам кластеров и бизнес-приложений.

В общем, Inferno - это, безусловно, интересный проект, демонстрирующий свой взгляд на многие, казалось бы, привычные вещи. Однако существующее программное обеспечение позволяет воспринимать Inferno скорее как платформу для исполнения некоторых специфичных программ или как среду разработки, но не как ОС для повседневного использования.

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




Top