Пользователь
0,1
рейтинг
23 октября 2008 в 16:53

Установка OS Inferno New Edition

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).

OS Inferno hosted on Mac OS X

Особенности установки в разных системах


Хотя Inferno должна устанавливаться и работать одинаково во всех системах, все мы прекрасно знаем, что нюансы есть всегда. Я протестировал установку в Hardened Gentoo Linux и в Ubuntu 8.04. Надеюсь, такой выбор систем перекроет большинство нюансов установки и в других дистрибутивах Linux.

Hardened Gentoo Linux

С компилятором и .h-файлами в Gentoo проблем не будет, я вас уверяю. :) А вот Hardened немного работы добавит. Дело в том, что emu умеет работать как в режиме интерпретации байт-кода виртуальной машины Dis, так и в режиме JIT. А Hardened (точнее, входящий в него PaX) очень не любит генерации кода на лету с передачей на него управления. Поэтому для запуска emu в JIT-режиме для него потребуется частично отключить PaX. Этим занимаются команды paxctl и chpax. На системах без PaX этих команд, скорее всего, нет, и выполнять их не нужно. Ещё один нюанс возникает при включенном Trusted Path Execution (TPE), но обычно достаточно проследить чтобы права на каталог с emu принадлежали root. Как бороться с SeLinux — разбирайтесь сами. :)

Ubuntu 8.04

Вот чего тут нет… э… ничего тут нет. :) Ни Hardened нет, ни subversion, ни библиотек, ни .h-файлов. Придётся ставить:

apt-get install subversion build-essential 
apt-get install libx11-dev libxext-dev x11proto-xext-dev

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

Установка OS Inferno


Ниже описана установка от root, в каталог /usr/local/inferno, в полноценном многопользовательском режиме. Отличия при установке от обычного пользователя в ~/inferno/ я буду упоминать по ходу процесса — в основном они сводятся к тому, что часть команд выполнять бессмысленно и/или не нужно.

Затраты времени/трафика/дискового пространства примерно следующие:
  • архив версии из svn занимает порядка 30 MB, но понятно, что svn накачает трафика значительно больше
  • система полностью [пере]собирается на моём Core2Duo 6600 примерно за две минуты
  • в установленном виде на диске она занимает порядка 250 MB
ВНИМАНИЕ: Inferno достаточно сильно не любит «странные» символы в именах файлов и каталогов. Включая пробел! Это не баг, это осознанное архитектурное решение. Поэтому рекомендуется проследить, чтобы в каталоге куда ставится Inferno, и в вашем домашнем каталоге внутри Inferno, имена файлов были без символов вроде ":", "!", "#", пробела, etc.

Качаем. Все команды, если не сказано обратного, выполняются от root. При установке в домашний каталог установите INFERNO_ROOT, например, так: /home/powerman/inferno. И, разумеется, все команды выполняйте от обычного пользователя.

export INFERNO_ROOT=/usr/local/inferno
svn checkout http://inferno-os.googlecode.com/svn/trunk/ $INFERNO_ROOT
cd $INFERNO_ROOT

Настраиваем параметры компиляции. Вместо perl -i -pe можно запустить любимый текстовый редактор и отредактировать mkconfig ручками.

export PATH=$INFERNO_ROOT/Linux/386/bin:$PATH
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

Собираем систему. Помните, paxctl нужен только на системах защищённых PaX и только для запуска в JIT-режиме.

sh makemk.sh
mk nuke
mk install
paxctl -psmxe Linux/386/bin/emu

Настраиваем параметры emu. Эту команду желательно прописать себе в ~/.bashrc — чтобы не передавать эти параметры при каждом запуске emu. (Кстати, ещё очень желательно в ~/.bashrc прописать export PATH=/usr/local/inferno/Linux/386/bin:$PATH — будет удобнее запускать emu и limbo.) Разумеется, размеры оконной системы Inferno нужно выставить какие вам удобнее, не обязательно 1024x768. В принципе, удобнее, когда размеры окна Inferno меньше разрешения host OS. Параметр -c0 отключает JIT (для включения просто запускайте emu -c1). Дело в том, что при включенном JIT сложнее отлаживать свои приложения — отладчик не работает, границы массивов контролируются хуже, etc. А скорость у Inferno и без JIT более чем впечатляющая.

export EMU="-r$INFERNO_ROOT -g1024x768 -c0"

Настраиваем пользователя inferno. При установке в домашний каталог эти команды выполнять не нужно. Второй chown нужен при включенном TPE.

groupadd inferno
useradd -m -s /bin/bash -g inferno inferno
chown -R inferno:inferno $INFERNO_ROOT
chown -R root:root $INFERNO_ROOT/Linux/386/bin/
echo exec $INFERNO_ROOT/Linux/386/bin/emu $EMU  >>~inferno/.bashrc
mv usr usr.skel
ln -s /home usr
cp -a usr.skel/inferno/* ~inferno/

Update: см. комментарий по поводу настройки /tmp.

Шрифты


В принципе, к этому моменту OS Inferno установлена, и её можно использовать. Но в «Fourth Edition» входят дополнительные шрифты (B&H Lucida), которые из-за лицензионных ограничений гугл не разрешает выкладывать в svn на code.google.com. В принципе большинство приложений будет работать и без них. Кроме того, их можно заменить альтернативными бесплатными шрифтами (так вроде бы сделали в проекте Acme SAC). Но я с этим не разбирался. Поэтому мы сейчас, быстренько, выкачаем и установим во временный каталог «Fourth Edition», и выдерем из неё эти шрифты. :)

mkdir /tmp/inferno
cd /tmp/inferno
wget http://www.vitanuova.com/dist/4e/20071003/inferno.tgz
wget http://www.vitanuova.com/dist/4e/20071003/Linux.tgz
tar xzf inferno.tgz
tar xzf Linux.tgz
chown -R root:root /tmp/inferno
chpax -psmxe Linux/386/bin/emu
sh install/Linux-386.sh /tmp/inferno/
cp -r fonts/{lucida,lucidasans,lucm,pelm,LICENCE} /usr/local/inferno/fonts/
rm -rf /tmp/inferno

Тестируем


Точка с запятой в начале строк — это приглашение Inferno-вского sh. Завершение работы с Inferno — в текстовом режиме либо Ctrl-D, либо Ctrl-C, в графическом — закрытие графического окна Inferno. (Графическая среда запускается командой wm/wm.)

Вход под пользователем inferno. При установке в домашний каталог этот шаг пропускаете.

# su - inferno
; cd
; pwd
/usr/inferno
; cat /dev/user
inferno

Вход под обычным пользователем. Команда cp проинициализирует ваш домашний каталог, её в будущем повторять перед запуском Inferno не нужно. Установку PATH и EMU тоже лучше прописать в ~/.bashrc. Тогда для запуска Inferno достаточно будет запустить emu.

$ cp -r /usr/local/inferno/usr.skel/inferno/* ~/
$ export PATH=/usr/local/inferno/Linux/386/bin:$PATH
$ export EMU="-r/usr/local/inferno/ -g1024x768 -c0"
$ emu
; cd
; pwd
/usr/powerman
; cat /dev/user
powerman

Начальная настройка Inferno


При запуске emu система минимально инициализируется, после чего запускается sh, который выполняет /lib/sh/profile для дальнейшей инициализации системы. Я в него обычно прописываю:
  • Установку тайм-зоны. В принципе это можно сделать один раз скопировав файл, но использовать bind — это более Infern-ish. :)
  • Переход в домашний каталог текущего пользователя (по умолчанию система находится в корневом каталоге).
  • Если в домашнем каталоге пользователя настроены соответствующие файлы — продолжить инициализацию системы этими файлами.
Итак, прописываете в /usr/local/inferno/lib/sh/profile:
bind /locale/Moscow /locale/timezone
cd
load std
and {ftest -e namespace} {nsbuild}
and {ftest -e profile} {run profile}

При установке в домашний каталог на этом настройка заканчивается — нет никакого смысла настраивать три субъекта авторизации с кучей паролей при работе под единственным аккаунтом.


Настройка авторизации

Для начала необходимо объяснить, что и зачем настраивается. Авторизация работает следующим образом: клиент и сервис взаимно авторизуют друг друга с помощью сертификатов на базе private/public ключей — всё почти как у ssh или https. Почти потому, что авторизуют они друг друга действительно взаимно. Для этого они оба должны получить свои сертификаты у одного и того же CA (certificate authority), которому оба доверяют. Так что именно CA, выдавая или не выдавая эти сертификаты, определяет, будет у клиента доступ к сервису, или нет.

Таким образом, нам нужно настроить три разные системы — сервер авторизации, некий полезный сервис, и терминал клиента. Для этого мы можем запустить три независимых emu на своей машине — с точки зрения Inferno это будут три разных сервера, на которых будут запущены разные приложения. Разумеется, при таком варианте есть некоторые ограничения — например, невозможно запустить два одинаковых сетевых сервиса в разных emu — у них будет конфликт при попытке открыть TCP порт. Ну и файлы на диске у них общие, разумеется — но это не касается «виртуальных» файлов (а-ля /proc и /dev в Linux), которые в Inferno используются очень активно. Так что отличий между этими тремя emu вам хватит, чтобы воспринимать их как действительно разные и независимые сервера.

Первым делом нужно прописать адрес (hostname или IP) сервера авторизации на машинах клиента и сервиса. Но, поскольку файлы у них в нашей конфигурации совпадают, то достаточно отредактировать один файл /usr/local/inferno/lib/ndb/local (можете вписать 127.0.0.1):
SIGNER=powerman.name

Дальше запускаем сервер авторизации. Он будет запускаться под юзером inferno, и все файлы с ключами и сертификатами CA будут доступны только этому юзеру.
# su - inferno
; cat /dev/user; echo
inferno

… очищаем базу ключей
; cp /dev/null /keydb/keys; chmod 600 /keydb/keys

… генерируем сертификат нашего CA, на указанное имя (любое)
; auth/createsignerkey powerman.name

… запускаем сервис авторизации, при этом потребуется установить пароль, который в будущем нужно будет вводить при каждом запуске этого сервиса — это необходимо т.к. ключи в файлах будут зашифрованы этим паролем
; svc/auth
Key: 
Confirm key:

… теперь мы можем завести на нашем сервисе авторизации настоящие пользовательские аккаунты, с паролями, наконец-то :) — один для пользователя inferno (просто чтобы не заводить ещё и третьего юзера, им будет пользоваться второй сервер для запуска полезных сервисов) и второй для пользователя powerman (который будет использовать клиентский терминал на третьем сервере для подключения к полезному сервису на втором сервере)
; auth/changelogin inferno
new account
secret: 
confirm: 
expires [DDMMYYYY/permanent, return = 23102009]: permanent
change written
; auth/changelogin powerman
new account
secret: 
confirm: 
expires [DDMMYYYY/permanent, return = 23102009]: permanent
change written

… ну и полюбуемся на запущенные на этом «сервере» TCP-сервисы
; netstat
tcp/0      inferno    Announced    0.0.0.0!6673         ::!0
tcp/1      inferno    Announced    0.0.0.0!6677         ::!0
tcp/2      inferno    Announced    0.0.0.0!6671         ::!0
tcp/3      inferno    Announced    0.0.0.0!6672         ::!0
; 

Сервер авторизации оставляем работать, и запускаем следующий emu — с полезным сервисом.
# su - inferno
; cat /dev/user; echo
inferno

… ndb/cs это что-то вроде универсального ресолвера, без него в Inferno с сетью особо не поработаешь (есть ещё ndb/dns, но в hosted режиме его можно не запускать и использовать dns-ресолвер host OS)
; ndb/cs

… обращаемся к сервису авторизации (первый сервер), представляемся под своим логином/паролем, и получаем от него свой сертификат (это операция единоразовая, при условии что сертификат не expire-нется и файл куда сейчас будет сохранён полученный сертификат никто не удалит).
; getauthinfo default
use signer [$SIGNER]: 
remote user name [inferno]: 
password: 
save in file [yes]:

… теперь, имея сертификат, можно запустить полезный сервис — например rstyx, который позволяет удалённо выполнять на этом сервере команды — аналог ssh
; svc/rstyx
; netstat
tcp/0      inferno    Announced    0.0.0.0!6668         ::!0
;

Оставляем его работать и запускаем третий emu — терминал юзера powerman.
$ emu
; cat /dev/user; echo
powerman
; ndb/cs
; getauthinfo default
use signer [$SIGNER]: 
remote user name [powerman]: 
password: 
save in file [yes]: 

… теперь мы можем подключиться ко второму серверу и выполнить на нём команду. для примера, посмотрим список процессов сначала на этом терминале, а потом на втором сервере
; ps
       1        1   powerman    0:00.0    release    74K Sh[$Sys]
       8        7   powerman    0:00.0        alt    17K Cs
      11        1   powerman    0:00.0      ready    74K Ps[$Sys]
; cpu powerman.name ps
       1        1    inferno    0:00.0    release    83K Bufio[$Sys]
       8        7    inferno    0:00.0        alt    17K Cs
      13        1    inferno    0:00.0        alt     9K Listen
      15        1    inferno    0:00.0    release     9K Listen[$Sys]
      22        1   powerman    0:00.0      ready     1K Ps[$Sys]
;

Обновление системы


Здесь всё абсолютно тривиально:
cd /usr/local/inferno
svn up
mk install

Что дальше?


RTFM. RTFM. И снова RTFM. Система очень сильно отличается от традиционных. Причём чтением документации ограничиться не рассчитывайте — нужно читать исходники, там всё самое главное. :)

Когда появится понимание что как работает — пишите на Limbo. (На sh писать не советую — он слишком медленный, что довольно странно, кстати.) Пишите сетевые сервисы, распределённые системы, или полноценные GUI-приложения.

Удачи! :)
Alex Efros @powerman
карма
300,5
рейтинг 0,1
Реклама помогает поддерживать и развивать наши сервисы

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

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

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

  • НЛО прилетело и опубликовало эту надпись здесь
  • +8
    объясните мне. а зачем это всё надо?)
    • +23
      Лично мне это всё надо по глубоко личной причине, которая связана с некоторыми личными проблемами и особенностями моей личности. А именно: меня заебало сложное, раздутое, тормознутое, глюкавое ПО. Меня раздражает, что оно продолжает усложняться и раздуваться, и конца и края этому не видно!

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

      Простой пример: в линухе есть файлы, сокеты, юникс-сокеты, блокирующий I/O, неблокирующий I/O, асинхронный I/O, куча всякой другой хуйни, плюс дополнительные настройки всех этих восхитительно пахнущих крупными проблемами дырявых «абстракций» вроде setsockopt и ioctl. В Inferno вместо всего этого — только файлы, только блокирующий I/O для этих файлов, и нити. Минимум абстракций с простым и однозначным поведением. Позволяющий реализовать ту же функциональность с примерно той же производительностью. Но значительно проще. И то же самое абсолютно во всём. В линухе есть процессы и есть нити. В инферно — только нити. В линухе хренова туча способов реализации IPC и синхронизации между процессами и нитями… одни только сигналы чего стоят! В инферно — только типизированные каналы.

      А линух, по сравнению с виндой, достаточно простая и прозрачная система. Вот от чего окончательно плохо делается…

      И не то, чтобы я не справлялся с линухом. Отлично справляюсь, много лет занимаясь всем этим очень вдумчиво и глубоко.
      Просто это Н Е П Р А В И Л Ь Н О !!!
      Этот путь непрерывного усложнения и раздувания ведёт либо в тупик либо в ад, и я не уверен, что хуже.

      Я ответил на Ваш вопрос?
      • +3
        ответили, причем, оч. понятно
      • 0
        Спасибо, буду учить.
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Эта ос сейчас — не для пользователя. Она — среда разработки.
          • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              А что, так трудно другие комментарии почитать? Или статьи из этого блога? Или это такая попытка троллинга?
              habrahabr.ru/blogs/os_inferno/42998/#comment_1067024
              • НЛО прилетело и опубликовало эту надпись здесь
                • +1
                  Вы бы хоть прочитали что это такое.
                  Всё, я кормением троллей не занимаюсь. Не понимаете — значит вам оно не надо. Всего доброго.
      • 0
        Расскажи, пожалуйста, а как в Inferno сделать файловую операцию (open, read, write) время работы которой ограничено таймаутом?
        Если там нет select и асинхронного I/O.
        Или может быть там есть что-то типа перловского alarm()?
        • 0
          Файловые операции блокирующие. Если нужно параллельно что-то делать или ограничить их таймаутом — файловые операции выносятся в отдельную нить. Вот пример кода «основной» нити, которая ждёт либо данных от второй нити (выполняющей файловые операции) либо от таймера:

          t := Timer.start(600);
          alt {
          data := <-input =>
          	t.stop();
          	# process the data
          <-t.timeout =>
          	# request timed out
          }
          
          • 0
            Когда два канала — это да, хорошо, а как сделать что-то вроде:
            t := Timer.start(600);
            alt {
            sys->read(fd1, buf1, len buf1) =>
            # process the data
            <-t.timeout =>
            # request timed out
            }

            Допустим можно spawn'уть отдельный процесс который делает read, а потом посылает результат в канал.
            Некрасиво, но хоть что-то.
            Хорошо если этот процесс успеет отработаь за отведённое время, а если таймаут наступит раньше.
            Тогда остаётся процесс-зомби ждущий в read()
            Что с ним делать? Прибивать через /prog?
            Как-то совсем некрасиво: много лишнего кода плюс создание лишнего процесса и канала для кадого чтения.
          • 0
            Когда два канала — это да, хорошо, а как сделать что-то вроде:
            t := Timer.start(600);
            alt {
            sys->read(fd1, buf1, len buf1) =>
            # process the data
            <-t.timeout =>
            # request timed out
            }

            Допустим можно spawn'уть отдельный процесс который делает read, а потом посылает результат в канал.
            Некрасиво, но хоть что-то.
            Хорошо если этот процесс успеет отработаь за отведённое время, а если таймаут наступит раньше.
            Тогда остаётся процесс-зомби ждущий в read()
            Что с ним делать? Прибивать через /prog?
            Как-то совсем некрасиво: много лишнего кода плюс создание лишнего процесса и канала для кадого чтения.
            • 0
              Не «допустим можно spawn'уть», а именно это и нужно делать.

              Насчёт «некрасиво» — категорически не согласен! Непривычно, после Perl-а — да. Мультиплексирование I/O через select/poll/epoll и таймауты на alarm гораздо хуже. Я много такого кода писал за последние годы, есть с чем сравнивать.

              Насчёт прибивания процесса — да, прибивать.

              На самом деле никакого лишнего и некрасивого кода не возникает. Всё зависит от задачи.

              Например, таймер никто не заставляет заводить на каждый отдельный read — его можно заводить на все операции I/O которые должен выполнить процесс.

              Если нужен таймер именно на отдельную операцию чтения, можно в несколько строчек сделать обёртку а-ля:

              t := killmeafter(600);
              sys->read(...);
              t.stop();
              


              где killmeafter() запустит отдельную нить, которая через 600 секунд убьёт процесс-родитель; а stop() наоборот, убьёт порождённую killmeafter() нить.

              В других ситациях можно позволить нити выполняющей read висеть сколько хочет. Например, она обслуживает конкретного клиента, и если клиент отвалится и перелогинится то процесс, который его обслуживал, будет убит в момент, когда клиент залогинится снова, а не по таймауту для read().
        • 0
          Да, для perl-программиста не помешает ещё раз упомянуть один факт: в Inferno очень лёгкие нити. Никаких проблем плодить их тысячами и десятками тысяч нет. Всё реально летает. А выделение блокирующих операций в отдельные нити обычно сказывается на архитектуре программы самым положительным образом.

          Тот же Timer, в вышеприведённом примере, тоже запускается в отдельной нити, разумеется.
          • 0
            Не очень это дешево — число процессов в инферно ограничено числом порядка 1500.
            А sys->sleep() в emu реализован через запуск треда OS.
            • 0
              В смысле треда host OS (CreateThread() в случае Win32)
            • 0
              Откуда информация про 1500?

              Я гонял разнообразные тесты, большое кол-во нитей выполняющих I/O с сетью, etc. И сравнивал с аналогичными тестами на Perl через epoll. Результаты были сравнимы.

              Вы можете предложить тест, демонстрирующий дороговизну нитей инферно, точнее где нити бы проигрывали тому же epoll?
              • 0
                #define MAXSLEEPERS 1500 в os.c

                kuku()
                {
                sys->sleep(10000);
                }

                for(i:=0; i<3000; i++)
                {
                spawn kuku();
                }

                И посмотрите в TaskManager (или в top под Linux) сколько тредов будет при этом у emu (я бы это назвал багом конкретной реализации, это нисколько не умаляет плюсы инферны, но мешает её применению в реальных проектах).

                про сравнение бенчмарков с epoll — не знаю, у меня пока что проблема просто таймауты организовать, рано еще профилировкой заниматься.
                • 0
                  Э… А… Простите, нафига запулять 3000 sleep-ов? Ради 3000 таймеров?! Сделайте одолжение, почитайте внимательно /appl/lib/timers.b, и Вы увидите, что это вовсе не обязательно. Вообще, чтение исходников Inferno очень полезно для кармы и самообразования.
                  • 0
                    Вариант, да.
                    Спасибо.

                    Пока Вы быстро отвечаете, ещё спрошу — с сокетами на подобный лимит не наталкивались?
                    Если да, если ли workaround, как этот для таймеров?

                    Там подобный механизм: osenter(), функция_хост_ос(), osleave()
                    • 0
                      функция_хост_ос() — это например write()
                    • 0
                      Хехе. С таймерами — это не work around. Вы же не говорите, что a+=5 это work around чтобы не писать a=a+1;a=a+1;a=a+1;a=a+1;a=a+1;. :-)

                      Помните тот анекдот, про сибирских мужиков и японскую бензопилу? Которую они таки сломали о железную шпалу, и пошли дальше валить деревья топорами? Всегда можно придумать дурную задачу, не имеющую нормального решения. А нужно делать нечто совершенно обратное: искать простые и элегантные решения реально имеющихся, а не теоретических (!) задач.

                      Что касается сокетов, насколько я читал, в Inferno нити host OS не выделяются конкретным нитям Dis навсегда. Т. е. если у Вас есть 10_000 нитей Dis делающих какие-то операции требующие функциональности нитей host OS (вроде того же sleep или работы с сокетами), а количество нитей host OS ограничено, например, 1_500, то эти 1_500 будут по очереди обслуживать все ваши 10_000 нитей Dis. При нормальном I/O это не проблема, но если получится так, что все 1_500 из 10_000 сокетов, которые в данный момент обслуживаются нитями host OS, подвисли в ожидании данных — вполне возможно что пока кто-то из этих 1_500 не получит данные другие сокеты работать не смогут. Точно не уверен, надо тестировать. Но даже если и так — Вы уверены, что это проблема реальная, а не очередная шпала для бензопилы?
                      • 0
                        Workaround в том смысле, что могли бы все sleep'ы обслужить одним тредом OS внутри сишного кода инферны, а не выносить это в модуль на лимбо.
                        С сокетами тоже можно не ждать окончания работы блокирующих функций в тредах OS, а использовать один тред OS и неблокирующие функции.

                        Насчёт реально ли мешает мне сейчас лимит с сокетами — пока, к счастью, нет.
                        Лимит на sleep'ы мешал.

                        Хотя могу привести примеры реальных задач, где он помешает (http-spider, etc), но я их на Инферно переносить пока не планирую.

                        Может быть к тому времени, когда это понадобится, выйдет 5-я версия :)
                        • 0
                          Я у себя в tmp откопал именно такие тесты, о которых идёт речь. Я тоже примерно с них начинал, и тоже держа в голове спайдера. :) Так вот, я стряхнул с них пыль, и потестировал снова. Запускаю 10_000 нитей, в которых выполняется sys->sleep(5000). Если Inferno действительно ограничивает кол-во одновременно работающих нитей такого типа 1_500, то тест должен отработать секунд за 30.

                          На практике все нити завершаются через 5 секунд, но при этом возникает небольшой затор, пока основная нить получает от них сообщения через каналы, поэтому в сумме тест отрабатывает за 6.5 секунд. (Число в последней колонке — кол-во миллисекунд прошедших с вывода предыдущей строки.)

                          $ emu -pmain=100M
                          ; time sleep10k
                          spawned:   120
                              1 sleepy threads wake up:  4881
                              2 sleepy threads wake up:     0
                             10 sleepy threads wake up:  1176
                             50 sleepy threads wake up:   162
                            100 sleepy threads wake up:    96
                            150 sleepy threads wake up:     3
                            200 sleepy threads wake up:     1
                            250 sleepy threads wake up:     1
                           1000 sleepy threads wake up:     7
                           2000 sleepy threads wake up:    17
                           5000 sleepy threads wake up:    40
                          10000 sleepy threads wake up:    59
                          finished:     1
                          0l 6.564r 6.564t
                          ; 
                          

                          sleep10k.b
                          • 0
                            > Если Inferno действительно ограничивает кол-во одновременно работающих нитей такого типа 1_500, то тест должен отработать секунд за 30.

                            Там веселее, 1501'й sleep() не ставится в очередь на ожидание, а превращается в sleep(0)
                            Причём молча.

                            попробуй заменить свой
                            sys->sleep(5000);
                            на
                            t1 := sys->millisec();
                            sys->sleep(5000);
                            sys->print("(%d)", sys->millisec()-t1);

                            (да, я на Windows это проверяю, бинарник emu.exe вот отсюда: www.vitanuova.com/inferno/net_download4T.html)
                          • 0
                            Или вот так:
                            func(c: chan of int)
                            {
                            t1 := sys->millisec();
                            sys->sleep(5000);
                            realsleeptime := sys->millisec()-t1;
                            if(realsleeptime>4000)
                            sleepok ++;
                            else
                            sleepaborted ++;
                            c <-= 1;
                            }

                            У меня в итоге:
                            sleepok=1501 sleepaborted=8499
                            • 0
                              grep по исходникам показывает, что MAXSLEEPERS встречается только в сорцах для Nt. У меня под линухом создаётся 10_000 процессов, всё по-честному. Кстати, лучше юзайте версию из svn.

                              Но всё-таки столько нитей одновременно выполняющих блокирующие операции требующие выделенной нити host OS это очень вырожденный случай. А обычные нити самой Inferno действительно очень лёгкие — я сейчас проверил, 30_000 нитей работающих с каналами (что не требует выделенных нитей host OS) создалось за 6 секунд. При этом никакого заметного увеличения кол-ва процессов самого emu не наблюдалось.
  • +2
    Спасибо за статьи.
    У меня просьба: не могли бы Вы в следующий раз затронуть тему именно «зачем это надо»? Хотя бы тупо небольшой разбор примеров, где ОС уже применяется (личные примеры?).

    P.S. habrahabr.ru/blogs/os_inferno/42829/#comment_1058397 отличный комментарий. )
  • 0
    Инсталляция валиться на Vista. Кто-нибудь сталкивался?
    • –1
      Я сейчас заканчиваю собирать под XP. Не без извращений, но собирается. Vista у меня нет. Отчёты о проблемах с установкой под Vista я где-то видел, или в mail list-е, или в issue tracker-е.
  • +3
    Короче, собрал я Inferno под WinXP SP2. Но там всё так непросто получается, что совать это в статью никакого желания нет. Если учесть тот факт, что я с виндой не работаю вообще и Visual Studio никогда в глаза не видел… то я вполне мог что-то нахомутать и переусложнить. В общем, я готов выслушать любые рекомендации на тему как это делать менее отвратительным способом здесь, в комментариях, а в статью перенесу окончательный вариант.

    Я старался выкачивать и ставить всё по-минимуму. VC++ 2005 взял из соображений «под ним точно собирали когда-то» и «2005 наверное весит меньше самой новой версии». :) SDK 2008 взял исключительно потому, что SDK 2003 не давали без проверки windows genuine, а я качал всё из линуха и видел их genuine в белых тапочках.

    Идём на www.collab.net/downloads/subversion/
    Качаем «CollabNet Subversion Command-Line Client v1.5.3 (for Windows)»
    (они пытаются задрачивать, но это решается — логин:bugmenot с паролем:nobug)
    Выкачиваем 3 MB
    Ставим CollabNetSubversion-client-1.5.3-1.win32.exe
    Перезапускаем открытые cmd.exe/far.exe/etc. чтобы обновить PATH

    Идём на www.microsoft.com/express/2005/download/default.aspx
    Качаем «Microsoft Visual C++ 2005 Express Edition»
    Выкачиваем 3 MB (для начала)
    Ставим vcsetup.exe
    (при установке отключаем «графическую IDE», ибо нафиг оно не надо)
    Оно докачивает ещё 68 MB

    Идём на www.microsoft.com/downloads/details.aspx?FamilyId=E6E1C3DF-A74F-4207-8586-711EBE331CDC&displaylang=en
    Качаем «Windows SDK for Windows Server 2008 and .NET Framework 3.5»
    Выкачиваем меньше 1 MB (нда… это уже настораживает)
    Ставим setup.exe
    (при установке отключаем всё, кроме двух пунктов:
      dev tool -> windows headers and libraries
      dev tool -> windows development tools -> win32 development tools
    )
    Оно докачивало ещё 39 MB (если ему верить, конечно)
    И вот здесь начинаются первые серьёзные проблемы. У меня оно падало в процессе установки раз 6, наверное. Но я не сдавался, тупо его перезапускал… и таки прорвался — оно успешно поставилось. Правда, на C: в корне оставило после себя кучу говна, но я не обиделся. (Я думал что уже отвык от такого, под линухом если что-то падает, то оно будет падать пока не починишь, перезапускать бессмысленно… но, как выяснилось, навык под виндой всё тупо перезапускать не выветривается с подкорки даже за очень много лет. :))

    Всё вместе на винте сожрало порядка 400 MB. [censored]! (Сколько же оно сожрало бы при установке последних версий и без выключения всех галочек до каких можно дотянуться?)

    Дальше выкачиваем через svn (в командной строке, как в статье) Inferno в E:\inferno.
    Редактируем E:\inferno\mkconfig:
        ROOT=E:/inferno
        SYSHOST=Nt
        OBJTYPE=386
    

    Чтобы обойти первую ошибку при сборке нужно дополнительно отредактировать E:\inferno\mkfiles\mkfile-Nt-386 и добавить параметр -force:multiple (я без понятия что это, но оно помогло):
        LDFLAGS=        $LDEBUG -nologo -incremental:no -map -force:multiple
    

    Дальше начинается ламбада. Поскольку MS VC++ 2005 и MS SDK 2008 никогда друг о друге не слышали, то для того, чтобы при компиляции они использовались вместе, нужно ручками прописать переменные окружения PATH, INCLUDE и LIB так, чтобы в них перечислялись пути обоих. Для этого запускаем сначала:
        Menu->Visual C++ 2005 Express Edition->Visual Studio Tools->Visual Studio 2005 Command Prompt
    

    и смотрим/копируем значение переменных VC++:
        echo %PATH%
        echo %INCLUDE%
        echo %LIB%
    

    после чего запускаем следующего товарища:
        Menu->Microsoft Windows SDK v6.1->CMD Shell
    

    и устанавливаем переменные в сумму обоих значений. У меня это выглядело примерно так:
    PATH=C:\Program Files\Microsoft Visual Studio 8\Common7\IDE;C:\Program Files\Microsoft Visual Studio 8\VC\BIN;C:\Program Files\Microsoft Visual Studio 8\Common7\Tools;C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\bin;C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;C:\Program Files\Microsoft Visual Studio 8\VC\VCPackages;%PATH%
    set INCLUDE=C:\Program Files\Microsoft Visual Studio 8\VC\INCLUDE;%INCLUDE%
    set LIB=C:\Program Files\Microsoft Visual Studio 8\VC\LIB;C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\lib;%LIB%


    Дальше всё более-менее как в статье:
        e:
        cd \inferno
        PATH=e:\inferno\Nt\386\bin;%PATH%
        mk nuke
        mk install
    

    … в процессе оно навернётся с ошибкой типа:
        mk: limbo -c -IE:/inferno/module ...  : exit status=exit(1)
    

    Но! Это-ж винда. Поэтому есть простое решение неизвестной проблемы:
        mk install
    

    Ну да. А чего вы ждали? Перезапустил команду и всё собралось на ура. :)

    Теперь вешаете на рабочий стол ярлык на:
        E:\inferno\Nt\386\bin\emu.exe -rE:/inferno -g1024x768 -c0
    


    Всё. Обновлять систему как описано в статье. Только, вероятно, имеет смысл наваять .bat-файл для выставления переменных окружения.
    • 0
      спасибо, полюбопытствую.
    • 0
      а можно ли выложить уже собранную? трафик — большая проблема :(
      • 0
        Выложить-то можно, вопрос в том, что именно выложить. Если с трафиком проблема, то, вероятно, Вам обновляемая svn-версия не нужна. Возможно, вообще версия с исходниками не нужна? Тогда Вам может быть проще всего взять версию годовой давности на офф.сайте: inferno.tgz плюс Nt.tgz — где-то 20 MB в сумме. Насколько я понимаю, их должно хватить…
        • 0
          основная проблема именно в SDK этом, Visual Studio 2008 есть… можно ли собрать только имея её?
          • 0
            Нет, без SDK собрать не получится. Но он тянет где-то 40 MB, это вроде не много даже если сидеть на 33.600.
  • 0
    А где скриншоты?
  • НЛО прилетело и опубликовало эту надпись здесь
    • +3
      О, спасибо. Во всём треде и комментах — вы единственный, кто запостил ссылку, которая приведёт меня на страничку проекта.
      А скрины — ад! ^_^
      • –1
        Oops. Сейчас добавлю ссылок. :) В прошлых статьях их было до чёрта, и я решил что все, кому это интересно, уже их знают. Такая глупая мысль могла прийти ко мне в голову только потому, что я не спал больше суток когда готовил статью.
  • 0
    хоть бы один скриншот!
    как все уныло…
    • 0
      Вот поверьте, не ради красоты эту ось ставлят и пишут под нее…
      • –1
        Ну, кстати, если туда ещё и красоты добавить, то хуже от этого не станет. Иконок и тем наваять вроде никогда проблемой небыло. Только вот как с Tk быть? Там же вся графика на Tk, так что тему нужно на Tk натягивать. Я когда-то этим вопросом интересовался, и вроде темы для Tk существуют, только вот где их брать и как устанавливать так и не понял. В Inferno даже в mkconfig есть для этого настройка: TKSTYLE=std, но что с ней делать не ясно.
        • 0
          TKSTYLE=std влияет какой mkfile будет пользоваться в libtk, в данном случае mkfile-std. Он там и один. Все tk примитивы рисуются очень просто через draw.h. Возможно что авторы специально выбирали как можно более простую схему прорисовки чтобы работало как можно более быстрее в случае когда замаунтили удалённый /dev/draw и draw комманды бегают по сетке. Сделать свой стиль похоже не так и сложно — copy-paste оригинальный и подправить прорисовку.
      • 0
        общеизвестно что иллюстрации способствуют лУтшему восприятию статьи
        • 0
          Полностью согласен. Может предложите, иллюстрации чего именно вставлять в статью описывающую выполнение нескольких команд в командной строке? Окна терминала с этими командами? Оно не менее скучное. Скриншоты графической оконной среды Inferno? Они к делу отношения почти не имеют, да и выглядят не самым суперским образом. Что ещё? Абстрактные картинки?
          • 0
            да, покажите скриншот операционки внутри XP например uname -a запустите или что там аналогичное. народ вообще не в курсе что за инферна такая… почему бы сразу не заинтересовать?
      • +1
        Красота должна быть во всём, а не только в архитектуре ;)
    • 0
      Я добавил скриншот. Так лучше? :)
      • 0
        да! кстати как собрать на маке? Xcode стоит. какие либо серьезные отличия от линуксовой установке будут?
  • –2
    ОС только в зачаточном состоянии, что бы из нее сделать более или менее массовый продукт, потребуется очень много времени.
    • 0
      Любопытно, исходя из чего был сделан вывод о «зачаточном состоянии»?

      У меня немного другая информация. Inferno базируется на идеях Plan9, и у них довольно много общего кода. Так что их развитие и взросление идёт параллельно — фиксы одной системы практически сразу дублируются во второй. Plan9 вышел в 1992. Inferno в 1997. Свободно распространяться в инете с обычными открытыми лицензиями Plan9 начал в 2000, Inferno примерно в 2005.

      Обе системы большой популярности не имеют, но работают достаточно давно и стабильны. Так что это что угодно, только не зачаточное состояние. :)

      А что касается массовости… Inferno никогда не проектировалась в качестве замены серверным или десктопным операционкам, так что массовость может быть исключительно в роли либо операционки для встроенных устройств либо виртуальной машины типа JVM.
  • 0
    Под MacOSX проблем было чуть больше. И тупой перезапуск команд не помогал — это всё-таки не винда. :) Но проблемы мелкие, связаны с mkfile-ами, и я думаю что они скоро будут в svn исправлены, так что вы можете с ними и не столкнуться.

    Надо отметить, что MacOSX у меня конкретно тормозит, скорее всего это связано с отсутствием VMware tools для хакинтоша. В частности, установка Xcode несколько раз «замирала» минут на 10 — я уже хотел её прибить.

    Идём на www.collab.net/downloads/community/
    Качаем «Universal Subversion 1.5.2 Binaries for MAC OS X (32 and 64 bit)»
    Выкачиваем 15 MB (хмм, под винду/линух было 3-5 MB...)
    Ставим Subversion 1.5.2-2 Universal.dmg
    На винте оно кушает ещё 56 MB
    Запускать svn нужно будет так: /opt/subversion/bin/svn (не знаю, почему /opt/subversion/bin было не добавить в PATH автоматически или не установить симлинки в /usr/bin).

    Идём на connect.apple.com/
    (логин:adcbugmenot с паролем:bugmenot)
    Качаем в Downloads->DeveloperTools «Xcode 2.5 Developer Tools (Disk Image)»
    Выкачиваем 900 MB
    (Возможно Xcode есть на вашем установочном DVD, и качать его не нужно.)
    При установке нужно включить раздел «Command Line Support» (полностью). Остальное можно не ставить.
    Устанавливается оно в 2 GB! (винда нервно курит в сторонке)

    Я устанавливал Inferno в домашний каталог (в ~/inferno/). Но, теоретически, можно ставить многопользовательский вариант так же, как описано в статье для Linux.

    В mkconfig прописываем:
    ROOT=/Users/powerman/inferno
    SYSHOST=MacOSX
    OBJTYPE=386
    

    Чтобы обойти первый вылет по ошибке при сборке, нужно отредактировать файл appl/lib/ida/mkfile, заменив в конце
    idatab.dis:N:
            ;
    

    на
    idatab.dis:N:
            ulimit -s 65536
            limbo idatab.b
    


    Дальше всё как обычно:
    export PATH=~/inferno/MacOSX/386/bin:$PATH
    sh makemk.sh
    mk nuke
    mk install
    

    Через некоторое время оно вылетит по ошибке, т. к. пропустит сборку одной из библиотек. Решается это так:
    cd libkeyring
    mk install
    cd ..
    mk install
    

    Готово.
    • 0

      A /Users/rol/inferno/doc/20020628.pdf
      A /Users/rol/inferno/doc/ebookimp.pdf
      A /Users/rol/inferno/doc/20020715.ms
      svn: In directory '/Users/rol/inferno/doc'
      svn: Can't open file '/Users/rol/inferno/doc/.svn/tmp/text-base/INSTALL.ms.svn-base': No such file or directory

      эээ и что дальше ?? запускал и из под обычного пользователя и из под sudo — одинаково вылетает там

      • 0
        Я только что обновился без проблем, правда, под Linux. Скорее всего у Вас проблемы из-за того, что вчера в каталог doc/ добавили файл INSTALL.ms, хотя там уже был файл install.ms. В Linux из-за этого проблем нет, а вот под виндой были бы точно — у неё файловая система case insensitive и два таких файла в одном каталоге не выжили бы. Думаю, этот конфликт по именам файлов был создан не специально, и его скоро поправят. А пока, как вариант, Вам ничего не мешает поставить предыдущую ревизию (333).
        • 0
          оказывается не только в windows, в mac os на HFS+ по умолчанию такой же режим включен
          • 0
            Уже пофиксили: r341.
    • 0
      Совет с ida весьма пригодится и линуксоидам, думаю. По крайней мере, у меня не собралось, пока не подправил файлик. Также хочу напомнить, что для запуска графической оболочки нужно еще установить DISPLAY и запускать от пользователя, который сможет достучаться до X.

      А теперь по существу — система, как видно, легковесная. Но только честно говоря, мне эта легковесность не совсем по душе. Например, шелл очень неудобный. Не хочу показаться снобом, но система кроме внутренней красоты и гармонии должна еще быть удобной для пользователя и разработчика. Возможно, я не прав и ее удобнйо сделать можно. Тогда жду следующих статей :)
      • 0
        Проблему с idatab.dis уже поправили в svn. Тупо выложили заранее скомпилированный файл с другим именем и в mkfile его копируют в idetab.dis. Проблем из-за этого никаких не будет, потому что байт-код Dis абсолютно портабельный. Проблема была в том, что idatab.b написан таким образом, что limbo при компиляции нужен очень большой стек. При запуске limbo под Inferno — это не проблема. А при запуске limbo под host OS (что и происходит при mk install) — в зависимости от настроек стека в host OS при компиляции этого файла limbo может навернуться. (Вообще дико, что при современных объёмах памяти, в некоторых системах до сих пор стек по умолчанию ограничен 8KB.)

        Что касается удобства шелла. Частично проблема решается программированием. Например, у меня в /usr/powerman/profile:

        fn . { args:=$*; if {! ~ $#args 0} { .=$* }; $. }
        

        Эта кракозябра создаёт функцию (читай — команду) с именем «точка», которая при запуске с параметрами — выполняет и запоминает их, а при запуске без параметров — выполняет последние запомненные параметры. Используется примерно так:

        ; . echo ok
        ok
        ; .
        ok
        

        А по сути, чтобы перестать испытывать дискомфорт из-за отсутствия поддержки readline в sh и amarok в wm/wm лично мне было достаточно осознать, что этот sh — НЕ ШЕЛЛ! Хоть и удачно им прикидывается. Это такая лазейка, дырочка, через которую можно попасть внутрь работающей виртуальной машины, и ручками её поковырять — позапускать какие-то процессы, покилять работающие, посмотреть что происходит, etc. Покажите мне хотя бы такой, без readline, sh для JVM!

        Ещё один момент заключается в том, что обычно разрабочики в Inferno работают в графической среде, acme, etc. А wm/sh немного более вменяемый.
        • 0
          Какой-то неубедительный аргумент, почему я должен перестать испытывать дискомфорт :) Я понимаю, что «хоть что-то» лучше, чем ничего, но при этом хороший шелл был бы лучше, чем «хоть что-то». И совершенно необязательно этот тяжелый шелл тянуть с собой на конечные машины. Но для разработки был бы очень полезен.
          • 0
            Ок, уговорили. Если Вы вызвались реализовать для sh поддержку нормального интерфейса — я только «за»! :)

            Кстати, почитайте вот эти ветки:
            wm/sh with tab completion
            shell history
          • 0
            Я нашёл одно важное для понимания ситуации с этими фичами письмо. Для тех, кому лень кликнуть, или плохо с английским, кратко перескажу суть.

            В Inferno архитектура организована так, что окно терминала (wm/sh) не эмулирует терминал вроде vt100, как в *nix. Как следствие этого, приложения, работающие в этом окне, не имеют доступа к функциональности типа управления курсором. Вместо этого, редактирование содержимого окна реализовано в самом окне терминала (wm/sh). Благодаря этому редактирование вводимой строки доступно во всех приложениях, включая sh, и приложениям для этого вообще ничего делать не нужно — им достаточно сделать один read(stdin), и, когда юзер нажмёт Enter, он вернёт им введённую и уже отредактированную пользователем строку.

            Это позволило очень многое упростить в реализации, но поставило новые вопросы: реализацию вещей типа history или tab completion возможно реализовать только на уровне окна терминала. С одной стороны — это круто, т. к. даст эти фичи сразу всем работающим в окне терминала приложениям. С другой — терминалу сложно различать какое именно приложение сейчас работает, следовательно сложно поддерживать разную history и разные фичи tab completion в разных приложениях. Кроме того, приложение может переключить терминал в raw режим (например, для ввода пароля), и тоже не совсем понятно как это совместить с этими фичами.

            В общем, используется необычная архитектура (что как раз вполне обычно для Inferno :-)), со своими плюсами и минусами.
            • 0
              О том, что никакой интерактивности от этого sh ждать не приходится — это я уже понял, почитав исходники. Однако все же остается нерешенным вопрос, кто же отвечает за редактирование при запуске sh из командной строки (не wm/sh, а просто sh). emu?

              В общем, спасибо за помощь. Буду еще ковырять. Однако все же сказывается неудобство нового языка — нет возможности просто портировать существующие приложения.
              • 0
                Чем дальше я вникаю в исходники Inferno, тем больше я убеждаюсь, что «просто портировать существующие приложения» — это плохая идея. (Т. е. работать-то это будет, но смысла в этом мало.)

                Чтобы почувствовать силу Inferno, нужно существующие приложения портировать не просто, а реализовывать их с совершенно иной архитектурой. Фактически, полностью перепроектировать их! А после этого вопрос переноса существующего кода практически полностью теряет смысл (исключая чисто алгоритмический код, обсчитывающий данные — этот от архитектуры обычно не зависит, но он и портируется с практически любого C-подобного языка на Limbo один-в-один).
  • 0
    Я убрал из статьи команду:
    chmod 1777 $INFERNO_ROOT/tmp/
    

    Если вы её уже успели выполнить, можете вернуть обычные права:
    chmod 0755 $INFERNO_ROOT/tmp/
    

    Вместо этого в Inferno обычно используется другой подход. Каталог /tmp не доступен обычным пользователям на запись, он является просто точкой подключения временного каталога пользователя. Т. е. вы должны создать у себя в домашнем каталоге любой подкаталог для хранения временных файлов, и подключать его вместо /tmp:
    ; pwd
    /usr/powerman
    ; mkdir tmp
    ; bind -c tmp /tmp
    

    А чтобы не делать bind каждый раз можно его прописать в файл настраивающий ваш name space при запуске emu:
    ; pwd
    /usr/powerman
    ; echo 'bind -c tmp /tmp' >> namespace
    

    Где-то так, в общем. :)
  • 0
    Для установки OS Inferno под Mac OS X 10.5.5 (Leopard) понадобится SVN (15 MB, берём на www.collab.net/downloads/community/) и Xcode (идёт в комплекте с лицензией, а для хакинтошей/vmware выкачиваем 995 MB на connect.apple.com/ — логин берёте на bugmenot, качать надо xcode312_2621_developerdvd.dmg).

    Хорошая новость — в отличие от установки под 10.4 (Tiger) устанавливать из Xcode 2 GB всякого мусора не обязательно, достаточно установить ~300 MB. Для этого нужно вместо основного пакета ./XcodeTools.mpkg установить из подкаталога ./Packages/ вот эти пакеты:
    • DeveloperToolsCLI.pkg (55MB)
    • gcc4.0.pkg (95MB)
    • DevSDK.pkg (176MB)
    • QuickTimeSDK.pkg (3MB)
    • CoreAudioSDK.pkg (1.5MB)
    • OpenGLSDK.pkg (3.5MB)


    В mkconfig прописываем:
    ROOT=/Users/powerman/inferno
    SYSHOST=MacOSX
    OBJTYPE=386


    Дальше всё как обычно:
    export PATH=~/inferno/MacOSX/386/bin:$PATH
    sh makemk.sh
    mk nuke
    mk install


    P.S. У меня Leopard под VMware работает почему-то значительно медленнее Tiger, и, на глаз, inferno компилировалась тоже очень долго (примерно час).
    • 0
      Да, забыл добавить. Под Leopard ставятся VMwareTools (которые нужно предварительно выдрать из VMwareFusion — darwin.iso 3.5 MB). Из заметных отличий — начинает работать copy&paste между host os и leopard, но, к сожалению, графика не ускоряется. :(
  • 0
    У меня emu падает с Segmentation Fault, если в имени первичной группы пользователя, которому принадлежит директория inferno, есть пробел. На поведение, соответствующее заранее выбранной политике не похоже ;-)

    Поскольку в нашей сети у всех рядовых пользователей группа по умолчанию содержит в имени пробел, то использовать inferno, видимо, не получится — все время смотреть на падения и соображать, откуда еще какой пробел вылез — сил нет.
    • 0
      Насколько я понимаю, пробелы в именах файлов считаются в OS Inferno хоть и допустимыми теоретически (т.к. их поддерживает протокол Styx, а вся работа с файлами идёт через него), но не рекомендуемыми (т.к. из-за пробелов возникает куча геморроя с экранированием парамеров команд в sh, и т.п.).

      В результате в некоторых частях Inferno такие файлы обрабатываются нормально, а в других — нет. И это как раз похоже на «поведение, соответствующее заранее выбранной политике».
      • 0
        Ну, насколько я знаю, sh спроектирован так, чтобы количество проблем с пробелами уменьшить — там есть понятие списков, которые применяются вместо строк, разделенных пробелами — что шаг вперед по сравнению с юниксовыми sh.

        Однако в данном случае мы имеем другую проблему — полное вылетание виртуальной машины. Мне удалось добиться интересного эффекта: я захожу по rstyx на inferno — и inferno в тот же миг падает, приходится ее перепускать. Я не гарантирую, что дело тут в пробелах, но склонен подозревать, что дело именно в них, потому что в другом месте аналогичное падение от пробелов зависело.
        • 0
          А что выступает в роли клиента rstyx? Другая Inferno? Почему тогда не падает она? Вообще, Вы бы описали ситуацию более конкретно, может я под vmware смогу проверить этот баг… и, кстати, описывать её лучше сразу в трекере.
  • 0
    См. файл CHANGES в Inferno из SVN (http://inferno-os.googlecode.com/svn/trunk/):

    20090627
    push changes described for arm in 20090330 (but not previously pushed)
    begin change of inferno-os.googlecode.com from svn to mercurial

    См. файл CHANGES в Inferno с оф.сайта (http://www.vitanuova.com/dist/4e/inferno-20100120.tgz):

    20100115
    appl/cmd/tarfs.b man/4/tarfs changes to permission handling from mechiel [issue 220]
    appl/spree/mkfile add explicit -I$ROOT/module [issue 209, powerman]

    Вывод — ПРЕДПОЧТИТЕЛЬНЕЙ версия с оф.сайта, а не из SVN.
    • 0
      Я не понял, из чего сделан такой вывод. Поясните?
      • 0
        Э…

        1) файл CHANGES однозначно указывает нам на то что версия в транке 20090627 более протухшая нежели 20100115

        2) сборка версии из транка обнаруживает отсутствие кучи файлов. ладно бы только шрифтов указанных в этой статье. wm/wm тоже нет. Разбираться что там есть, а чего там нет — желание стремящееся к нулю. она просто неюзабельная и всё.
        • 0
          Да ну, глупости. Откуда Вы вообще этот SVN откопали? Репозиторий находится там же, но он давно на Mercurial, а не SVN: code.google.com/p/inferno-os/source/browse/ и там вполне свежий CHANGES. Вероятно, старый SVN-репозиторий всё ещё не удалён гуглом после перехода с SVN на Mercurial, но добраться туда легальным образом нельзя — разве что через какие-нить старые ссылки. Возможно, в моей статье эти ссылки и указаны, но Вы поймите — это статья, а не вики, статьи обычно не обновляют, и эта устарела почти на 4 года.
          • 0
            Именно он в Вашей статье и указан. Спасибо, попробую сегодня пересобрать со свежего SVN. Да, статья устарела. Теперь в файл mkfiles/mkfile-Linux-386 необходимо добавлять опцию -fno-omit-frame-pointer в CFLAGS, иначе на свежих ядрах мы получаем Segmentation fault при запуске emu.
            • 0
              Мне удалось завести под vmware mac os x lion, так что я, наверное, таки обновлю эту статью. Точнее, выложу новую, для современных ОС.
              • 0
                Да, было бы неплохо обновить
              • 0
                Эта статья плоха тем что она слишком путанная и на 50% перекликается с другой Вашей статьёй: habrahabr.ru/post/42829/

                Для установки ОС новичкам нужны простые, понятные и однозначные сценарии работающие во всех случаях для hosted и native установки. Это такие сценарии которые (в случае Linux) можно реализовать путём последовательного бездумного копипаста команд из статьи в консоль. Тогда систему будут изучать люди с разным уровнем начальной подготовки, а не только те кто смог продраться через замысел автора.

                Проверил версию из Mercurial (не из SVN, как я думал) по Вашей ссылке — ставится отлично. Большое спасибо. Но опять же, не всем доступно разобраться как этой ссылкой воспользоваться. Как-нибудь так:

                $ cd ~
                $ hg clone inferno-os.googlecode.com/hg/ inferno
                $ cd inferno

                =)

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