Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 84
хорошая система :)
на windows ставится вобще эллементарно
на windows ставится вобще эллементарно
объясните мне. а зачем это всё надо?)
Лично мне это всё надо по глубоко личной причине, которая связана с некоторыми личными проблемами и особенностями моей личности. А именно: меня заебало сложное, раздутое, тормознутое, глюкавое ПО. Меня раздражает, что оно продолжает усложняться и раздуваться, и конца и края этому не видно!
Inferno даёт возможность писать простые программы в простой среде. При этом не уступающие по функциональности обычному софту в винде или линухе. Достигается этот эффект во многом за счёт более правильной и элегантной архитектуры, позволившей упростить множество вещей.
Простой пример: в линухе есть файлы, сокеты, юникс-сокеты, блокирующий I/O, неблокирующий I/O, асинхронный I/O, куча всякой другой ху*ни, плюс дополнительные настройки всех этих восхитительно пахнущих крупными проблемами дырявых «абстракций» вроде setsockopt и ioctl. В Inferno вместо всего этого — только файлы, только блокирующий I/O для этих файлов, и нити. Минимум абстракций с простым и однозначным поведением. Позволяющий реализовать ту же функциональность с примерно той же производительностью. Но значительно проще. И то же самое абсолютно во всём. В линухе есть процессы и есть нити. В инферно — только нити. В линухе хренова туча способов реализации IPC и синхронизации между процессами и нитями… одни только сигналы чего стоят! В инферно — только типизированные каналы.
А линух, по сравнению с виндой, достаточно простая и прозрачная система. Вот от чего окончательно плохо делается…
И не то, чтобы я не справлялся с линухом. Отлично справляюсь, много лет занимаясь всем этим очень вдумчиво и глубоко.
Просто этоН Е П Р А В И Л Ь Н О !!!
Этот путь непрерывного усложнения и раздувания ведёт либо в тупик либо в ад, и я не уверен, что хуже.
Я ответил на Ваш вопрос?
Inferno даёт возможность писать простые программы в простой среде. При этом не уступающие по функциональности обычному софту в винде или линухе. Достигается этот эффект во многом за счёт более правильной и элегантной архитектуры, позволившей упростить множество вещей.
Простой пример: в линухе есть файлы, сокеты, юникс-сокеты, блокирующий I/O, неблокирующий I/O, асинхронный I/O, куча всякой другой ху*ни, плюс дополнительные настройки всех этих восхитительно пахнущих крупными проблемами дырявых «абстракций» вроде setsockopt и ioctl. В Inferno вместо всего этого — только файлы, только блокирующий I/O для этих файлов, и нити. Минимум абстракций с простым и однозначным поведением. Позволяющий реализовать ту же функциональность с примерно той же производительностью. Но значительно проще. И то же самое абсолютно во всём. В линухе есть процессы и есть нити. В инферно — только нити. В линухе хренова туча способов реализации IPC и синхронизации между процессами и нитями… одни только сигналы чего стоят! В инферно — только типизированные каналы.
А линух, по сравнению с виндой, достаточно простая и прозрачная система. Вот от чего окончательно плохо делается…
И не то, чтобы я не справлялся с линухом. Отлично справляюсь, много лет занимаясь всем этим очень вдумчиво и глубоко.
Просто это
Этот путь непрерывного усложнения и раздувания ведёт либо в тупик либо в ад, и я не уверен, что хуже.
Я ответил на Ваш вопрос?
ответили, причем, оч. понятно
Спасибо, буду учить.
Эта ос сейчас — не для пользователя. Она — среда разработки.
А что, так трудно другие комментарии почитать? Или статьи из этого блога? Или это такая попытка троллинга?
habrahabr.ru/blogs/os_inferno/42998/#comment_1067024
habrahabr.ru/blogs/os_inferno/42998/#comment_1067024
Расскажи, пожалуйста, а как в Inferno сделать файловую операцию (open, read, write) время работы которой ограничено таймаутом?
Если там нет select и асинхронного I/O.
Или может быть там есть что-то типа перловского alarm()?
Если там нет select и асинхронного I/O.
Или может быть там есть что-то типа перловского alarm()?
Файловые операции блокирующие. Если нужно параллельно что-то делать или ограничить их таймаутом — файловые операции выносятся в отдельную нить. Вот пример кода «основной» нити, которая ждёт либо данных от второй нити (выполняющей файловые операции) либо от таймера:
t := Timer.start(600);
alt {
data := <-input =>
t.stop();
# process the data
<-t.timeout =>
# request timed out
}
Когда два канала — это да, хорошо, а как сделать что-то вроде:
t := Timer.start(600);
alt {
sys->read(fd1, buf1, len buf1) =>
# process the data
<-t.timeout =>
# request timed out
}
Допустим можно spawn'уть отдельный процесс который делает read, а потом посылает результат в канал.
Некрасиво, но хоть что-то.
Хорошо если этот процесс успеет отработаь за отведённое время, а если таймаут наступит раньше.
Тогда остаётся процесс-зомби ждущий в read()
Что с ним делать? Прибивать через /prog?
Как-то совсем некрасиво: много лишнего кода плюс создание лишнего процесса и канала для кадого чтения.
t := Timer.start(600);
alt {
sys->read(fd1, buf1, len buf1) =>
# process the data
<-t.timeout =>
# request timed out
}
Допустим можно spawn'уть отдельный процесс который делает read, а потом посылает результат в канал.
Некрасиво, но хоть что-то.
Хорошо если этот процесс успеет отработаь за отведённое время, а если таймаут наступит раньше.
Тогда остаётся процесс-зомби ждущий в read()
Что с ним делать? Прибивать через /prog?
Как-то совсем некрасиво: много лишнего кода плюс создание лишнего процесса и канала для кадого чтения.
Когда два канала — это да, хорошо, а как сделать что-то вроде:
t := Timer.start(600);
alt {
sys->read(fd1, buf1, len buf1) =>
# process the data
<-t.timeout =>
# request timed out
}
Допустим можно spawn'уть отдельный процесс который делает read, а потом посылает результат в канал.
Некрасиво, но хоть что-то.
Хорошо если этот процесс успеет отработаь за отведённое время, а если таймаут наступит раньше.
Тогда остаётся процесс-зомби ждущий в read()
Что с ним делать? Прибивать через /prog?
Как-то совсем некрасиво: много лишнего кода плюс создание лишнего процесса и канала для кадого чтения.
t := Timer.start(600);
alt {
sys->read(fd1, buf1, len buf1) =>
# process the data
<-t.timeout =>
# request timed out
}
Допустим можно spawn'уть отдельный процесс который делает read, а потом посылает результат в канал.
Некрасиво, но хоть что-то.
Хорошо если этот процесс успеет отработаь за отведённое время, а если таймаут наступит раньше.
Тогда остаётся процесс-зомби ждущий в read()
Что с ним делать? Прибивать через /prog?
Как-то совсем некрасиво: много лишнего кода плюс создание лишнего процесса и канала для кадого чтения.
Не «допустим можно spawn'уть», а именно это и нужно делать.
Насчёт «некрасиво» — категорически не согласен! Непривычно, после Perl-а — да. Мультиплексирование I/O через select/poll/epoll и таймауты на alarm гораздо хуже. Я много такого кода писал за последние годы, есть с чем сравнивать.
Насчёт прибивания процесса — да, прибивать.
На самом деле никакого лишнего и некрасивого кода не возникает. Всё зависит от задачи.
Например, таймер никто не заставляет заводить на каждый отдельный read — его можно заводить на все операции I/O которые должен выполнить процесс.
Если нужен таймер именно на отдельную операцию чтения, можно в несколько строчек сделать обёртку а-ля:
где killmeafter() запустит отдельную нить, которая через 600 секунд убьёт процесс-родитель; а stop() наоборот, убьёт порождённую killmeafter() нить.
В других ситациях можно позволить нити выполняющей read висеть сколько хочет. Например, она обслуживает конкретного клиента, и если клиент отвалится и перелогинится то процесс, который его обслуживал, будет убит в момент, когда клиент залогинится снова, а не по таймауту для read().
Насчёт «некрасиво» — категорически не согласен! Непривычно, после Perl-а — да. Мультиплексирование I/O через select/poll/epoll и таймауты на alarm гораздо хуже. Я много такого кода писал за последние годы, есть с чем сравнивать.
Насчёт прибивания процесса — да, прибивать.
На самом деле никакого лишнего и некрасивого кода не возникает. Всё зависит от задачи.
Например, таймер никто не заставляет заводить на каждый отдельный read — его можно заводить на все операции I/O которые должен выполнить процесс.
Если нужен таймер именно на отдельную операцию чтения, можно в несколько строчек сделать обёртку а-ля:
t := killmeafter(600); sys->read(...); t.stop();
где killmeafter() запустит отдельную нить, которая через 600 секунд убьёт процесс-родитель; а stop() наоборот, убьёт порождённую killmeafter() нить.
В других ситациях можно позволить нити выполняющей read висеть сколько хочет. Например, она обслуживает конкретного клиента, и если клиент отвалится и перелогинится то процесс, который его обслуживал, будет убит в момент, когда клиент залогинится снова, а не по таймауту для read().
Да, для perl-программиста не помешает ещё раз упомянуть один факт: в Inferno очень лёгкие нити. Никаких проблем плодить их тысячами и десятками тысяч нет. Всё реально летает. А выделение блокирующих операций в отдельные нити обычно сказывается на архитектуре программы самым положительным образом.
Тот же Timer, в вышеприведённом примере, тоже запускается в отдельной нити, разумеется.
Тот же Timer, в вышеприведённом примере, тоже запускается в отдельной нити, разумеется.
Не очень это дешево — число процессов в инферно ограничено числом порядка 1500.
А sys->sleep() в emu реализован через запуск треда OS.
А sys->sleep() в emu реализован через запуск треда OS.
В смысле треда host OS (CreateThread() в случае Win32)
Откуда информация про 1500?
Я гонял разнообразные тесты, большое кол-во нитей выполняющих I/O с сетью, etc. И сравнивал с аналогичными тестами на Perl через epoll. Результаты были сравнимы.
Вы можете предложить тест, демонстрирующий дороговизну нитей инферно, точнее где нити бы проигрывали тому же epoll?
Я гонял разнообразные тесты, большое кол-во нитей выполняющих I/O с сетью, etc. И сравнивал с аналогичными тестами на Perl через epoll. Результаты были сравнимы.
Вы можете предложить тест, демонстрирующий дороговизну нитей инферно, точнее где нити бы проигрывали тому же epoll?
#define MAXSLEEPERS 1500 в os.c
kuku()
{
sys->sleep(10000);
}
…
for(i:=0; i<3000; i++)
{
spawn kuku();
}
И посмотрите в TaskManager (или в top под Linux) сколько тредов будет при этом у emu (я бы это назвал багом конкретной реализации, это нисколько не умаляет плюсы инферны, но мешает её применению в реальных проектах).
про сравнение бенчмарков с epoll — не знаю, у меня пока что проблема просто таймауты организовать, рано еще профилировкой заниматься.
kuku()
{
sys->sleep(10000);
}
…
for(i:=0; i<3000; i++)
{
spawn kuku();
}
И посмотрите в TaskManager (или в top под Linux) сколько тредов будет при этом у emu (я бы это назвал багом конкретной реализации, это нисколько не умаляет плюсы инферны, но мешает её применению в реальных проектах).
про сравнение бенчмарков с epoll — не знаю, у меня пока что проблема просто таймауты организовать, рано еще профилировкой заниматься.
Э… А… Простите, нафига запулять 3000 sleep-ов? Ради 3000 таймеров?! Сделайте одолжение, почитайте внимательно /appl/lib/timers.b, и Вы увидите, что это вовсе не обязательно. Вообще, чтение исходников Inferno очень полезно для кармы и самообразования.
Вариант, да.
Спасибо.
Пока Вы быстро отвечаете, ещё спрошу — с сокетами на подобный лимит не наталкивались?
Если да, если ли workaround, как этот для таймеров?
Там подобный механизм: osenter(), функция_хост_ос(), osleave()
Спасибо.
Пока Вы быстро отвечаете, ещё спрошу — с сокетами на подобный лимит не наталкивались?
Если да, если ли workaround, как этот для таймеров?
Там подобный механизм: osenter(), функция_хост_ос(), osleave()
функция_хост_ос() — это например write()
Хехе. С таймерами — это не 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 не получит данные другие сокеты работать не смогут. Точно не уверен, надо тестировать. Но даже если и так — Вы уверены, что это проблема реальная, а не очередная шпала для бензопилы?
Помните тот анекдот, про сибирских мужиков и японскую бензопилу? Которую они таки сломали о железную шпалу, и пошли дальше валить деревья топорами? Всегда можно придумать дурную задачу, не имеющую нормального решения. А нужно делать нечто совершенно обратное: искать простые и элегантные решения реально имеющихся, а не теоретических (!) задач.
Что касается сокетов, насколько я читал, в 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 не получит данные другие сокеты работать не смогут. Точно не уверен, надо тестировать. Но даже если и так — Вы уверены, что это проблема реальная, а не очередная шпала для бензопилы?
Workaround в том смысле, что могли бы все sleep'ы обслужить одним тредом OS внутри сишного кода инферны, а не выносить это в модуль на лимбо.
С сокетами тоже можно не ждать окончания работы блокирующих функций в тредах OS, а использовать один тред OS и неблокирующие функции.
Насчёт реально ли мешает мне сейчас лимит с сокетами — пока, к счастью, нет.
Лимит на sleep'ы мешал.
Хотя могу привести примеры реальных задач, где он помешает (http-spider, etc), но я их на Инферно переносить пока не планирую.
Может быть к тому времени, когда это понадобится, выйдет 5-я версия :)
С сокетами тоже можно не ждать окончания работы блокирующих функций в тредах OS, а использовать один тред OS и неблокирующие функции.
Насчёт реально ли мешает мне сейчас лимит с сокетами — пока, к счастью, нет.
Лимит на sleep'ы мешал.
Хотя могу привести примеры реальных задач, где он помешает (http-spider, etc), но я их на Инферно переносить пока не планирую.
Может быть к тому времени, когда это понадобится, выйдет 5-я версия :)
Я у себя в tmp откопал именно такие тесты, о которых идёт речь. Я тоже примерно с них начинал, и тоже держа в голове спайдера. :) Так вот, я стряхнул с них пыль, и потестировал снова. Запускаю 10_000 нитей, в которых выполняется sys->sleep(5000). Если Inferno действительно ограничивает кол-во одновременно работающих нитей такого типа 1_500, то тест должен отработать секунд за 30.
На практике все нити завершаются через 5 секунд, но при этом возникает небольшой затор, пока основная нить получает от них сообщения через каналы, поэтому в сумме тест отрабатывает за 6.5 секунд. (Число в последней колонке — кол-во миллисекунд прошедших с вывода предыдущей строки.)
sleep10k.b
На практике все нити завершаются через 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
> Если 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)
Там веселее, 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)
Или вот так:
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
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
grep по исходникам показывает, что MAXSLEEPERS встречается только в сорцах для Nt. У меня под линухом создаётся 10_000 процессов, всё по-честному. Кстати, лучше юзайте версию из svn.
Но всё-таки столько нитей одновременно выполняющих блокирующие операции требующие выделенной нити host OS это очень вырожденный случай. А обычные нити самой Inferno действительно очень лёгкие — я сейчас проверил, 30_000 нитей работающих с каналами (что не требует выделенных нитей host OS) создалось за 6 секунд. При этом никакого заметного увеличения кол-ва процессов самого emu не наблюдалось.
Но всё-таки столько нитей одновременно выполняющих блокирующие операции требующие выделенной нити host OS это очень вырожденный случай. А обычные нити самой Inferno действительно очень лёгкие — я сейчас проверил, 30_000 нитей работающих с каналами (что не требует выделенных нитей host OS) создалось за 6 секунд. При этом никакого заметного увеличения кол-ва процессов самого emu не наблюдалось.
Спасибо за статьи.
У меня просьба: не могли бы Вы в следующий раз затронуть тему именно «зачем это надо»? Хотя бы тупо небольшой разбор примеров, где ОС уже применяется (личные примеры?).
P.S. habrahabr.ru/blogs/os_inferno/42829/#comment_1058397 отличный комментарий. )
У меня просьба: не могли бы Вы в следующий раз затронуть тему именно «зачем это надо»? Хотя бы тупо небольшой разбор примеров, где ОС уже применяется (личные примеры?).
P.S. habrahabr.ru/blogs/os_inferno/42829/#comment_1058397 отличный комментарий. )
Инсталляция валиться на Vista. Кто-нибудь сталкивался?
Короче, собрал я 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
(при установке отключаем всё, кроме двух пунктов:
Оно докачивало ещё 39 MB (если ему верить, конечно)
И вот здесь начинаются первые серьёзные проблемы. У меня оно падало в процессе установки раз 6, наверное. Но я не сдавался, тупо его перезапускал… и таки прорвался — оно успешно поставилось. Правда, на C: в корне оставило после себя кучу говна, но я не обиделся. (Я думал что уже отвык от такого, под линухом если что-то падает, то оно будет падать пока не починишь, перезапускать бессмысленно… но, как выяснилось, навык под виндой всё тупо перезапускать не выветривается с подкорки даже за очень много лет. :))
Всё вместе на винте сожрало порядка 400 MB. [censored]! (Сколько же оно сожрало бы при установке последних версий и без выключения всех галочек до каких можно дотянуться?)
Дальше выкачиваем через svn (в командной строке, как в статье) Inferno в
Редактируем
Чтобы обойти первую ошибку при сборке нужно дополнительно отредактировать
Дальше начинается ламбада. Поскольку MS VC++ 2005 и MS SDK 2008 никогда друг о друге не слышали, то для того, чтобы при компиляции они использовались вместе, нужно ручками прописать переменные окружения PATH, INCLUDE и LIB так, чтобы в них перечислялись пути обоих. Для этого запускаем сначала:
и смотрим/копируем значение переменных VC++:
после чего запускаем следующего товарища:
и устанавливаем переменные в сумму обоих значений. У меня это выглядело примерно так:
Дальше всё более-менее как в статье:
… в процессе оно навернётся с ошибкой типа:
Но! Это-ж винда. Поэтому есть простое решение неизвестной проблемы:
Ну да. А чего вы ждали? Перезапустил команду и всё собралось на ура. :)
Теперь вешаете на рабочий стол ярлык на:
Всё. Обновлять систему как описано в статье. Только, вероятно, имеет смысл наваять .bat-файл для выставления переменных окружения.
Я старался выкачивать и ставить всё по-минимуму. 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-файл для выставления переменных окружения.
спасибо, полюбопытствую.
а можно ли выложить уже собранную? трафик — большая проблема :(
Выложить-то можно, вопрос в том, что именно выложить. Если с трафиком проблема, то, вероятно, Вам обновляемая svn-версия не нужна. Возможно, вообще версия с исходниками не нужна? Тогда Вам может быть проще всего взять версию годовой давности на офф.сайте: inferno.tgz плюс Nt.tgz — где-то 20 MB в сумме. Насколько я понимаю, их должно хватить…
А где скриншоты?
хоть бы один скриншот!
как все уныло…
как все уныло…
Вот поверьте, не ради красоты эту ось ставлят и пишут под нее…
Ну, кстати, если туда ещё и красоты добавить, то хуже от этого не станет. Иконок и тем наваять вроде никогда проблемой небыло. Только вот как с Tk быть? Там же вся графика на Tk, так что тему нужно на Tk натягивать. Я когда-то этим вопросом интересовался, и вроде темы для Tk существуют, только вот где их брать и как устанавливать так и не понял. В Inferno даже в mkconfig есть для этого настройка:
TKSTYLE=std, но что с ней делать не ясно.общеизвестно что иллюстрации способствуют лУтшему восприятию статьи
Полностью согласен. Может предложите, иллюстрации чего именно вставлять в статью описывающую выполнение нескольких команд в командной строке? Окна терминала с этими командами? Оно не менее скучное. Скриншоты графической оконной среды Inferno? Они к делу отношения почти не имеют, да и выглядят не самым суперским образом. Что ещё? Абстрактные картинки?
Красота должна быть во всём, а не только в архитектуре ;)
Я добавил скриншот. Так лучше? :)
да! кстати как собрать на маке? Xcode стоит. какие либо серьезные отличия от линуксовой установке будут?
Гляньте чуть ниже.
ОС только в зачаточном состоянии, что бы из нее сделать более или менее массовый продукт, потребуется очень много времени.
Любопытно, исходя из чего был сделан вывод о «зачаточном состоянии»?
У меня немного другая информация. Inferno базируется на идеях Plan9, и у них довольно много общего кода. Так что их развитие и взросление идёт параллельно — фиксы одной системы практически сразу дублируются во второй. Plan9 вышел в 1992. Inferno в 1997. Свободно распространяться в инете с обычными открытыми лицензиями Plan9 начал в 2000, Inferno примерно в 2005.
Обе системы большой популярности не имеют, но работают достаточно давно и стабильны. Так что это что угодно, только не зачаточное состояние. :)
А что касается массовости… Inferno никогда не проектировалась в качестве замены серверным или десктопным операционкам, так что массовость может быть исключительно в роли либо операционки для встроенных устройств либо виртуальной машины типа JVM.
У меня немного другая информация. Inferno базируется на идеях Plan9, и у них довольно много общего кода. Так что их развитие и взросление идёт параллельно — фиксы одной системы практически сразу дублируются во второй. Plan9 вышел в 1992. Inferno в 1997. Свободно распространяться в инете с обычными открытыми лицензиями Plan9 начал в 2000, Inferno примерно в 2005.
Обе системы большой популярности не имеют, но работают достаточно давно и стабильны. Так что это что угодно, только не зачаточное состояние. :)
А что касается массовости… Inferno никогда не проектировалась в качестве замены серверным или десктопным операционкам, так что массовость может быть исключительно в роли либо операционки для встроенных устройств либо виртуальной машины типа JVM.
Под 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 нужно будет так:
Идём на connect.apple.com/
(логин:adcbugmenot с паролем:bugmenot)
Качаем в Downloads->DeveloperTools «Xcode 2.5 Developer Tools (Disk Image)»
Выкачиваем 900 MB
(Возможно Xcode есть на вашем установочном DVD, и качать его не нужно.)
При установке нужно включить раздел «Command Line Support» (полностью). Остальное можно не ставить.
Устанавливается оно в 2 GB! (винда нервно курит в сторонке)
Я устанавливал Inferno в домашний каталог (в
В
Чтобы обойти первый вылет по ошибке при сборке, нужно отредактировать файл
на
Дальше всё как обычно:
Через некоторое время оно вылетит по ошибке, т. к. пропустит сборку одной из библиотек. Решается это так:
Готово.
Надо отметить, что 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
Готово.
…
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 — одинаково вылетает там
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 — одинаково вылетает там
Я только что обновился без проблем, правда, под Linux. Скорее всего у Вас проблемы из-за того, что вчера в каталог doc/ добавили файл INSTALL.ms, хотя там уже был файл install.ms. В Linux из-за этого проблем нет, а вот под виндой были бы точно — у неё файловая система case insensitive и два таких файла в одном каталоге не выжили бы. Думаю, этот конфликт по именам файлов был создан не специально, и его скоро поправят. А пока, как вариант, Вам ничего не мешает поставить предыдущую ревизию (333).
оказывается не только в windows, в mac os на HFS+ по умолчанию такой же режим включен
Уже пофиксили: r341.
Совет с ida весьма пригодится и линуксоидам, думаю. По крайней мере, у меня не собралось, пока не подправил файлик. Также хочу напомнить, что для запуска графической оболочки нужно еще установить DISPLAY и запускать от пользователя, который сможет достучаться до X.
А теперь по существу — система, как видно, легковесная. Но только честно говоря, мне эта легковесность не совсем по душе. Например, шелл очень неудобный. Не хочу показаться снобом, но система кроме внутренней красоты и гармонии должна еще быть удобной для пользователя и разработчика. Возможно, я не прав и ее удобнйо сделать можно. Тогда жду следующих статей :)
А теперь по существу — система, как видно, легковесная. Но только честно говоря, мне эта легковесность не совсем по душе. Например, шелл очень неудобный. Не хочу показаться снобом, но система кроме внутренней красоты и гармонии должна еще быть удобной для пользователя и разработчика. Возможно, я не прав и ее удобнйо сделать можно. Тогда жду следующих статей :)
Проблему с idatab.dis уже поправили в svn. Тупо выложили заранее скомпилированный файл с другим именем и в mkfile его копируют в idetab.dis. Проблем из-за этого никаких не будет, потому что байт-код Dis абсолютно портабельный. Проблема была в том, что idatab.b написан таким образом, что limbo при компиляции нужен очень большой стек. При запуске limbo под Inferno — это не проблема. А при запуске limbo под host OS (что и происходит при mk install) — в зависимости от настроек стека в host OS при компиляции этого файла limbo может навернуться. (Вообще дико, что при современных объёмах памяти, в некоторых системах до сих пор стек по умолчанию ограничен 8KB.)
Что касается удобства шелла. Частично проблема решается программированием. Например, у меня в /usr/powerman/profile:
Эта кракозябра создаёт функцию (читай — команду) с именем «точка», которая при запуске с параметрами — выполняет и запоминает их, а при запуске без параметров — выполняет последние запомненные параметры. Используется примерно так:
А по сути, чтобы перестать испытывать дискомфорт из-за отсутствия поддержки readline в sh и amarok в wm/wm лично мне было достаточно осознать, что этот sh — НЕ ШЕЛЛ! Хоть и удачно им прикидывается. Это такая лазейка, дырочка, через которую можно попасть внутрь работающей виртуальной машины, и ручками её поковырять — позапускать какие-то процессы, покилять работающие, посмотреть что происходит, etc. Покажите мне хотя бы такой, без readline, sh для JVM!
Ещё один момент заключается в том, что обычно разрабочики в Inferno работают в графической среде, acme, etc. А wm/sh немного более вменяемый.
Что касается удобства шелла. Частично проблема решается программированием. Например, у меня в /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 немного более вменяемый.
Какой-то неубедительный аргумент, почему я должен перестать испытывать дискомфорт :) Я понимаю, что «хоть что-то» лучше, чем ничего, но при этом хороший шелл был бы лучше, чем «хоть что-то». И совершенно необязательно этот тяжелый шелл тянуть с собой на конечные машины. Но для разработки был бы очень полезен.
Ок, уговорили. Если Вы вызвались реализовать для sh поддержку нормального интерфейса — я только «за»! :)
Кстати, почитайте вот эти ветки:
wm/sh with tab completion
shell history
Кстати, почитайте вот эти ветки:
wm/sh with tab completion
shell history
Я нашёл одно важное для понимания ситуации с этими фичами письмо. Для тех, кому лень кликнуть, или плохо с английским, кратко перескажу суть.
В Inferno архитектура организована так, что окно терминала (wm/sh) не эмулирует терминал вроде vt100, как в *nix. Как следствие этого, приложения, работающие в этом окне, не имеют доступа к функциональности типа управления курсором. Вместо этого, редактирование содержимого окна реализовано в самом окне терминала (wm/sh). Благодаря этому редактирование вводимой строки доступно во всех приложениях, включая sh, и приложениям для этого вообще ничего делать не нужно — им достаточно сделать один read(stdin), и, когда юзер нажмёт Enter, он вернёт им введённую и уже отредактированную пользователем строку.
Это позволило очень многое упростить в реализации, но поставило новые вопросы: реализацию вещей типа history или tab completion возможно реализовать только на уровне окна терминала. С одной стороны — это круто, т. к. даст эти фичи сразу всем работающим в окне терминала приложениям. С другой — терминалу сложно различать какое именно приложение сейчас работает, следовательно сложно поддерживать разную history и разные фичи tab completion в разных приложениях. Кроме того, приложение может переключить терминал в raw режим (например, для ввода пароля), и тоже не совсем понятно как это совместить с этими фичами.
В общем, используется необычная архитектура (что как раз вполне обычно для Inferno :-)), со своими плюсами и минусами.
В Inferno архитектура организована так, что окно терминала (wm/sh) не эмулирует терминал вроде vt100, как в *nix. Как следствие этого, приложения, работающие в этом окне, не имеют доступа к функциональности типа управления курсором. Вместо этого, редактирование содержимого окна реализовано в самом окне терминала (wm/sh). Благодаря этому редактирование вводимой строки доступно во всех приложениях, включая sh, и приложениям для этого вообще ничего делать не нужно — им достаточно сделать один read(stdin), и, когда юзер нажмёт Enter, он вернёт им введённую и уже отредактированную пользователем строку.
Это позволило очень многое упростить в реализации, но поставило новые вопросы: реализацию вещей типа history или tab completion возможно реализовать только на уровне окна терминала. С одной стороны — это круто, т. к. даст эти фичи сразу всем работающим в окне терминала приложениям. С другой — терминалу сложно различать какое именно приложение сейчас работает, следовательно сложно поддерживать разную history и разные фичи tab completion в разных приложениях. Кроме того, приложение может переключить терминал в raw режим (например, для ввода пароля), и тоже не совсем понятно как это совместить с этими фичами.
В общем, используется необычная архитектура (что как раз вполне обычно для Inferno :-)), со своими плюсами и минусами.
О том, что никакой интерактивности от этого sh ждать не приходится — это я уже понял, почитав исходники. Однако все же остается нерешенным вопрос, кто же отвечает за редактирование при запуске sh из командной строки (не wm/sh, а просто sh). emu?
В общем, спасибо за помощь. Буду еще ковырять. Однако все же сказывается неудобство нового языка — нет возможности просто портировать существующие приложения.
В общем, спасибо за помощь. Буду еще ковырять. Однако все же сказывается неудобство нового языка — нет возможности просто портировать существующие приложения.
Чем дальше я вникаю в исходники Inferno, тем больше я убеждаюсь, что «просто портировать существующие приложения» — это плохая идея. (Т. е. работать-то это будет, но смысла в этом мало.)
Чтобы почувствовать силу Inferno, нужно существующие приложения портировать не просто, а реализовывать их с совершенно иной архитектурой. Фактически, полностью перепроектировать их! А после этого вопрос переноса существующего кода практически полностью теряет смысл (исключая чисто алгоритмический код, обсчитывающий данные — этот от архитектуры обычно не зависит, но он и портируется с практически любого C-подобного языка на Limbo один-в-один).
Чтобы почувствовать силу Inferno, нужно существующие приложения портировать не просто, а реализовывать их с совершенно иной архитектурой. Фактически, полностью перепроектировать их! А после этого вопрос переноса существующего кода практически полностью теряет смысл (исключая чисто алгоритмический код, обсчитывающий данные — этот от архитектуры обычно не зависит, но он и портируется с практически любого C-подобного языка на Limbo один-в-один).
Я убрал из статьи команду:
Если вы её уже успели выполнить, можете вернуть обычные права:
Вместо этого в Inferno обычно используется другой подход. Каталог /tmp не доступен обычным пользователям на запись, он является просто точкой подключения временного каталога пользователя. Т. е. вы должны создать у себя в домашнем каталоге любой подкаталог для хранения временных файлов, и подключать его вместо /tmp:
А чтобы не делать bind каждый раз можно его прописать в файл настраивающий ваш name space при запуске
Где-то так, в общем. :)
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
Где-то так, в общем. :)
Для установки 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/ вот эти пакеты:
В mkconfig прописываем:
Дальше всё как обычно:
P.S. У меня Leopard под VMware работает почему-то значительно медленнее Tiger, и, на глаз, inferno компилировалась тоже очень долго (примерно час).
Хорошая новость — в отличие от установки под 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 installP.S. У меня Leopard под VMware работает почему-то значительно медленнее Tiger, и, на глаз, inferno компилировалась тоже очень долго (примерно час).
У меня emu падает с Segmentation Fault, если в имени первичной группы пользователя, которому принадлежит директория inferno, есть пробел. На поведение, соответствующее заранее выбранной политике не похоже ;-)
Поскольку в нашей сети у всех рядовых пользователей группа по умолчанию содержит в имени пробел, то использовать inferno, видимо, не получится — все время смотреть на падения и соображать, откуда еще какой пробел вылез — сил нет.
Поскольку в нашей сети у всех рядовых пользователей группа по умолчанию содержит в имени пробел, то использовать inferno, видимо, не получится — все время смотреть на падения и соображать, откуда еще какой пробел вылез — сил нет.
Насколько я понимаю, пробелы в именах файлов считаются в OS Inferno хоть и допустимыми теоретически (т.к. их поддерживает протокол Styx, а вся работа с файлами идёт через него), но не рекомендуемыми (т.к. из-за пробелов возникает куча геморроя с экранированием парамеров команд в sh, и т.п.).
В результате в некоторых частях Inferno такие файлы обрабатываются нормально, а в других — нет. И это как раз похоже на «поведение, соответствующее заранее выбранной политике».
В результате в некоторых частях Inferno такие файлы обрабатываются нормально, а в других — нет. И это как раз похоже на «поведение, соответствующее заранее выбранной политике».
Ну, насколько я знаю, sh спроектирован так, чтобы количество проблем с пробелами уменьшить — там есть понятие списков, которые применяются вместо строк, разделенных пробелами — что шаг вперед по сравнению с юниксовыми sh.
Однако в данном случае мы имеем другую проблему — полное вылетание виртуальной машины. Мне удалось добиться интересного эффекта: я захожу по rstyx на inferno — и inferno в тот же миг падает, приходится ее перепускать. Я не гарантирую, что дело тут в пробелах, но склонен подозревать, что дело именно в них, потому что в другом месте аналогичное падение от пробелов зависело.
Однако в данном случае мы имеем другую проблему — полное вылетание виртуальной машины. Мне удалось добиться интересного эффекта: я захожу по rstyx на inferno — и inferno в тот же миг падает, приходится ее перепускать. Я не гарантирую, что дело тут в пробелах, но склонен подозревать, что дело именно в них, потому что в другом месте аналогичное падение от пробелов зависело.
А что выступает в роли клиента rstyx? Другая Inferno? Почему тогда не падает она? Вообще, Вы бы описали ситуацию более конкретно, может я под vmware смогу проверить этот баг… и, кстати, описывать её лучше сразу в трекере.
См. файл 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.
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.
Я не понял, из чего сделан такой вывод. Поясните?
Э…
1) файл CHANGES однозначно указывает нам на то что версия в транке 20090627 более протухшая нежели 20100115
2) сборка версии из транка обнаруживает отсутствие кучи файлов. ладно бы только шрифтов указанных в этой статье. wm/wm тоже нет. Разбираться что там есть, а чего там нет — желание стремящееся к нулю. она просто неюзабельная и всё.
1) файл CHANGES однозначно указывает нам на то что версия в транке 20090627 более протухшая нежели 20100115
2) сборка версии из транка обнаруживает отсутствие кучи файлов. ладно бы только шрифтов указанных в этой статье. wm/wm тоже нет. Разбираться что там есть, а чего там нет — желание стремящееся к нулю. она просто неюзабельная и всё.
Да ну, глупости. Откуда Вы вообще этот SVN откопали? Репозиторий находится там же, но он давно на Mercurial, а не SVN: code.google.com/p/inferno-os/source/browse/ и там вполне свежий CHANGES. Вероятно, старый SVN-репозиторий всё ещё не удалён гуглом после перехода с SVN на Mercurial, но добраться туда легальным образом нельзя — разве что через какие-нить старые ссылки. Возможно, в моей статье эти ссылки и указаны, но Вы поймите — это статья, а не вики, статьи обычно не обновляют, и эта устарела почти на 4 года.
Именно он в Вашей статье и указан. Спасибо, попробую сегодня пересобрать со свежего SVN. Да, статья устарела. Теперь в файл mkfiles/mkfile-Linux-386 необходимо добавлять опцию -fno-omit-frame-pointer в CFLAGS, иначе на свежих ядрах мы получаем Segmentation fault при запуске emu.
Мне удалось завести под vmware mac os x lion, так что я, наверное, таки обновлю эту статью. Точнее, выложу новую, для современных ОС.
Эта статья плоха тем что она слишком путанная и на 50% перекликается с другой Вашей статьёй: habrahabr.ru/post/42829/
Для установки ОС новичкам нужны простые, понятные и однозначные сценарии работающие во всех случаях для hosted и native установки. Это такие сценарии которые (в случае Linux) можно реализовать путём последовательного бездумного копипаста команд из статьи в консоль. Тогда систему будут изучать люди с разным уровнем начальной подготовки, а не только те кто смог продраться через замысел автора.
Проверил версию из Mercurial (не из SVN, как я думал) по Вашей ссылке — ставится отлично. Большое спасибо. Но опять же, не всем доступно разобраться как этой ссылкой воспользоваться. Как-нибудь так:
$ cd ~
$ hg clone inferno-os.googlecode.com/hg/ inferno
$ cd inferno
=)
Для установки ОС новичкам нужны простые, понятные и однозначные сценарии работающие во всех случаях для hosted и native установки. Это такие сценарии которые (в случае Linux) можно реализовать путём последовательного бездумного копипаста команд из статьи в консоль. Тогда систему будут изучать люди с разным уровнем начальной подготовки, а не только те кто смог продраться через замысел автора.
Проверил версию из Mercurial (не из SVN, как я думал) по Вашей ссылке — ставится отлично. Большое спасибо. Но опять же, не всем доступно разобраться как этой ссылкой воспользоваться. Как-нибудь так:
$ cd ~
$ hg clone inferno-os.googlecode.com/hg/ inferno
$ cd inferno
=)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Установка OS Inferno New Edition