Inferno и Plan 9: Часть 1.Обзор

Забавно, только что установил Inferno New Edition, и зашёл Charon'ом на лор. А тут для меня уже новость написали.

zenith> По поводу Limbo - как язык вообще ниачом, выглядит как динозавр в 21-м веке.

В связке с платформой Inferno это очень даже замечательное средство. Особенно для интеграции программ.

Не совсем так, чтобы не было накладных расходов на виртуализацию, нужно, чтобы продукт делали ребята из Bell Labs

зашевелились ))
эти системы по концепции очень хороши, но, опять-таки не популярны и пока мало софта под них. сингулярити от М$ просто как недоразвитый клон на фоне Inferno

> Может если после плана желание не отпадет, тоже качну (:

давай-давай, «план» у них хороший, забористый, вставляет не по-детски :D

Вот тебе пример: в нашей конторе сервер Plan 9 используется для ежедневного бэкапа (man venti). Профит очевиден - имеем полный бэкап за каждый день за последние полгода на одном зеркалированном терабайте )

Вот тебе пример: в нашей конторе сервер Plan 9 используется для ежедневного бэкапа (man venti). Профит очевиден - имеем полный бэкап за каждый день за последние полгода на одном зеркалированном терабайте )

эм, ну давайте от задачи спрошу, нужен сервак с нормальным аптаймом (не кластер, второй стоит в горячем резерве), всё это безобразие по запросу юзеров тянет данные с толстого стораджа (допустим уже есть) и занимается их обработкой, после чего выкидывает результат пользователю

сейчас выбор между: AIX, Solaris, Linux (Red Hat), имеет ли смысл рассматривать Plan 9 в качестве конкурента?

Старые фильмы ужасов такие смищные, особенно эти блестящие кофейники на веревочках..

и конечно же Plan 9 from the outer space: «resurrect the dead»

это круче чем всеми любимое семейство BSD

> По поводу Limbo - как язык вообще ниачом, выглядит как динозавр в 21-м веке.

Язык C на момент создания тоже был динозавром. Подчёркиваю: не сейчас, в 2010, а на момент создания, в 1972 примерно.

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

Собственно с развитием грид систем(и просто систем с выносом сети на юзерлевел) как раз подошли к тому что идеи заложенные в план9, вместе с протоколами и архитектурой будут широко востребованы. Просто механизм этого востребования будет не «все ставьте план9(адепт брызжет слюной)» а интеграция части план9, в линукс(ну и в любой другой юникс, да). В качестве API, сервисов и среды для разработки приложений. С устранением конфликтов с текущим юниксом(они там надизайнили кучу мелочей в макропроцессоре, поправили семантику команд и тп), с переписывание под GPL, если это необходимо.

Сейчас подобный проект есть, эмуляция план9 на пользовательском уровне юникс, от авторов. Но это форма прозелитизма. То что сейчас разбиратся в том что теперь у вас две версии cat (!) обычная и 9p это ужос. А разарабам вобщемто пофиг - они не некрофилы, они просто прилетели из далекого прошлого когда это все было еще живо. Прямо как в фильме(ну, почти).

> Язык C на момент создания тоже был динозавром

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

неплохо, но мало конкретики :( и «слайды, слайды»

> «ну какого хрена эти виндовсы, линуксы, бзди, х86???..

А разгадка одна: безблагодатность лучшее — враг хорошего.

>zenith> По поводу Limbo - как язык вообще ниачом, выглядит как динозавр в 21-м веке.

В связке с платформой Inferno это очень даже замечательное средство. Особенно для интеграции программ.

Средство для чего? Для интеграции программ во что?

Есть много слов, не имеющих смысл, когда они произносятся отдельно. Средство и интеграция - это одни из таких слов. http://www.effman.ru/169

Честно говоря, я скорее соглашусь с zenith. Во времена, когда набирают силу многопроцессорные (многоядерные) системы и функциональные языки программирования, вроде Erlang, Inferno кажется несколько устаревшим.

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

«Всё есть файл» - это идея Unix. В Unix она реализована не до конца, поэтому Plan 9 может быть Unix'ом в большей степени, чем сам Unix. Приделываем поддержку протокола 9P в Unix и получаем Unix таковым, каким он и должен быть. Идея «Сеть - это компьютер» и виртуальные машины реализованы, например, в Erlang.

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

Язык C на момент создания тоже был динозавром. Подчёркиваю: не сейчас, в 2010, а на момент создания, в 1972 примерно.

не был он нифига динозаврой, кобол был динозаврой

а С 1972 года разлива только сейчас кажется динозаврой, из этого временного интервала и то, только некоторым товарищам

Был он динозавром, был. Строкового типа в нём не было и нет до сих пор, перечислимых типов не было, множеств не было, вариантных типов не было. В тогдашних Алголах и Паскалях это было.

Позже появились Модула-2 и Object Pascal, в которых появились настоящие модули, которых в Си нет до сих пор, и объекты (которые реализованы уже в Си++, да и то - при отсутствии нормальной реализации модулей эти объекты до сих пор выглядят несколько костыльными).

Был он динозавром, был. Строкового типа в нём не было и нет до сих пор, перечислимых типов не было, множеств не было, вариантных типов не было. В тогдашних Алголах и Паскалях это было.

у меня стойкое ощущение что Вы некорректно трактуете парадигму динозавры... динозавра - это что-то большое, неповоротливое

так вот С всегда был небольшой и аккуратный :) и именно это позволило ему успешно пережить коллег по цеху

Позже появились Модула-2 и Object Pascal, в которых появились настоящие модули

это Вы сейчас про что?

модули, которых в Си нет

и не надо, он для того

> у меня стойкое ощущение что Вы некорректно трактуете парадигму динозавры... динозавра - это что-то большое, неповоротливое

В своём посте я имел ввиду именно ископаемое животное, а не его геометрические характеристики ;)

Кстати, по поводу легковесных процессов в Plan9. Насколько я знаю, там модель 1:1, какая нафиг легковесность? На каждый чих контекст дёргать? Это особенно печально в силу того, что в select там тоже нет и придётся городить тред на сокет (бишь «файл», или как там правильно). Так что Plan9 тоже динозавра, на этот раз уже в обоих смыслах ;)

>основная фишка - концепт «всё есть файл». Какой правда от этого профит программистам - неясно.

Профит простой - программировать на более высоком уровне абстракций не используя такие тяжелые наркотики как c++ и java :)

> Профит простой - программировать на более высоком уровне абстракций не используя такие тяжелые наркотики как c++ и java :)

Это всё общие слова ;)

>у меня стойкое ощущение что Вы некорректно трактуете парадигму динозавры... динозавра - это что-то большое, неповоротливое

А, в этом смысле. Я о том, что динозавр - это нечто устаревшее или даже вымершее. Ну если так, то возражений нет. Си - это высокоуровневый ассемблер, каким он и был задуман.

>Кстати, по поводу легковесных процессов в Plan9. Насколько я знаю, там модель 1:1, какая нафиг легковесность? На каждый чих контекст дёргать?

Plan 9 устарел, т.к. его заменил Inferno. А в Inferno никаких дёрганий контекстов нет - там виртуальная машина, она и изолирует процессы друг от друга.

Это особенно печально в силу того, что в select там тоже нет и придётся городить тред на сокет (бишь «файл», или как там правильно).

Особенно печально, что вы, похоже, не поняли принцип, по которому работает Plan 9. Там нет сокетов и тредов. Там есть файловые серверы. Операционная система ставит запросы по протоколу 9P в очередь, а эта очередь обрабатывается одним сервером.

Так что Plan9 тоже динозавра, на этот раз уже в обоих смыслах ;)

Нет, идея Plan 9 «всё - это файл» очень простая, изящная и гибкая, а её реализация должна быть очень компактной.

>Профит простой - программировать на более высоком уровне абстракций не используя такие тяжелые наркотики как c++ и java :)

Это всё общие слова ;)

Нет, это не общие слова. Почитайте описание протокола 9P - это центральная идея Plan 9. Суть в том, что для передачи любой информации в любую программу на любом сетевом узле, не требуется изобретать ещё один протокол и писать программу, реализующую этот протокол: все необходимые данные можно передать в удобном виде в другую программу, не зависимо от того, где эта программа работает - на локальном узле или на сетевом.

> Нет, это не общие слова. Почитайте описание протокола 9P - это центральная идея Plan 9. Суть в том, что для передачи любой информации в любую программу на любом сетевом узле, не требуется изобретать ещё один протокол и писать программу, реализующую этот протокол: все необходимые данные можно передать в удобном виде в другую программу, не зависимо от того, где эта программа работает - на локальном узле или на сетевом.

Выглядит классно, согласен. Но не совсем понятно как например без дополнительного демона соединиться по smtp с каким-нить хостом, который не умеет 9P. Можно вкратце для Ъ? :)

Выглядит классно, согласен. Но не совсем понятно как например без дополнительного демона соединиться по smtp с каким-нить хостом, который не умеет 9P.

Можно вкратце для Ъ? :)

Вкратце для не Ъ - в по ссылке в новости есть пример, в котором без дополнительных демонов программа обращается по HTTP к хосту с веб-сервером.

Для Ъ:

Чтобы подключиться к удаленной машине используя протокол TCP, мы должны открыть файл /net/tcp/clone. Затем в каталоге /net/tcp появится управляющий каталог соединения, в ctl-файл которого мы можем записать команду «connect IP-адрес», записать запрос в файл data, а затем, прочитав его, получить ответ. На языке командного интерпретатора Plan 9 все это выглядит так:

<>[3]/net/tcp/clone {
        dir=/net/tcp/^`{cat <[0=3]}
        echo connect 74.125.77.99!80 >$dir/ctl &&
        {
                echo 'GET /search?q=Plan9&btnI=I''m+Feeling+Lucky HTTP/1.1' &&
                echo 'connection: close' &&
                echo 'host: www.google.com' &&
                echo ''
        }>$dir/data
        cat $dir/data
}

Вообще - это скорее вопрос из серии: «Под какой буквой будет смонтирован сетевой диск в Unix, если я запускаю DOS-программу?»

> Осилил статью. Автор считает что раз были созданы сокеты и отдельно X сервер и еще кое что, то это типа «портит идеальную картину мира всё файл, что мешает разработчику, типа сложно очень». Не согласен.

я, допустим, тоже не согласен, но ты UNIX HATERS HANDBOOK читал? претензии-то там высказанные — обоснованные.

по их мнению делает UNIX-подобные ОС морально устаревшими

Р. Пайк на эту тему вообще написал, что дальнейший R&D не имеет смысла: http://herpolhode.com/rob/utah2000.pdf . Зря это он. Не всё так плохо.

позволяют — пишешь свой malloc вместо стандартного, и делаешь пул сам
Ну фрагментация же, внутренняя и внешняя

> эм? plan 9, про неё по ссылке сказ

Nemo книжки не просто так писал — он по ним курсы операционных систем «как написать сисколл» на примере Plan 9 вёл. Очень говорит, наглядно вышло (они до того что-то и на юниксах читали, но неосиляторов больше было).

500 анонимусов поставили себе Plan9...

> В статье нашли с чем сравнивать - регистровую vs стековой. Пыль в глаза короче.

ну я в доке Lua 5.0 видел разумное сравнение регистровой vs. стековой, применительно конкретно к Lua, с цифрами, графиками. Более содержательное сравнение.
Dalvik тоже нам кагбе намекает.

По поводу Limbo - как язык вообще ниачом, выглядит как динозавр в 21-м веке.

ADT в чистом виде + каналы и потоки — это основная его составляющая. Каналы в чистом виде перекочевали в go, а с ADT сымпровизировали.

Насколько я понял из статьи, основная фишка - концепт «всё есть файл». Какой правда от этого профит программистам - неясно.

Унификация. Файл — это универсальный ресурс. Почти как объекты ядра в объектной модели системы в NT в встроенной ВФС (а не в той, что идёт с \\Device\...).
Профит — унификация разнородного API по управлению «ресурсами» в стандартный файловый open/read/write/close. Ортогональность API.

Хотя тоже не очень ясно — вот были сервера приложений, стали файл-серверы. Вместо одной/двух функций API стало несколько.

> В связке с платформой Inferno это очень даже замечательное средство. Особенно для интеграции программ

ага, занятный бложик http://www.caerwyn.com/ipn/

> в нашей конторе сервер Plan 9 используется для ежедневного бэкапа (man venti).

плюс, он самовосстанавливающийся: http://plan-9.org.ru/index.php?option=com_content&view=article&id=69:backupre...

> Р. Пайк на эту тему вообще написал, что дальнейший R&D не имеет смысла: http://herpolhode.com/rob/utah2000.pdf . Зря это он

вроде бы, оптимизма прибавилось: http://www.usenix.org//event/hotos05/final_papers/full_papers/hunt/hunt.pdf

> То что сейчас разбиратся в том что теперь у вас две версии cat (!) обычная и 9p это ужос.

дооо... юникс версия cat такая особенная: http://harmful.cat-v.org/software/dynamic-linking/

=========
A quick sampling suggests that Plan 9 programs are
typically smaller than FreeBSD/386 programs even with shared
libraries. Here are some FreeBSD sizes:

: unix; size /bin/cat /bin/ed /usr/bin/awk /usr/X11/bin/sam
text data bss dec hex filename
54188 4324 9760 68272 10ab0 /bin/cat
122835 8772 81920 213527 34217 /bin/ed
135761 4772 15756 156289 26281 /usr/bin/awk
52525 1412 53448 107385 1a379 /usr/X11/bin/sam

Of those, awk and sam use shared libraries. The corresponding Plan 9
sizes are:

; cd /bin; size cat ed awk sam
15996t + 2208d + 944b = 19148 cat
45964t + 4212d + 41232b = 91408 ed
114731t + 35660d + 12040b = 162431 awk
86574t + 7800d + 66240b = 160614 sam
=======

это bsd, а в люниксах всё ещё хуже. (cat -v considered harmful)
И cat/man/lynx всё ещё не делают ничего, относящееся к кошке/человеку/рыси. На заборе тоже написано, а там....

они просто прилетели из далекого прошлого когда это все было еще живо. Прямо как в фильме(ну, почти).

FEEEED MEEE !!11 FEEED MEEE!! THEY WANT OUT BRAIN!!!111

> Средство для чего? Для интеграции программ во что?

всего. во всё

>всего. во всё

Маркетолог?

> Вкратце для не Ъ - в по ссылке в новости есть пример, в котором без дополнительных демонов программа обращается по HTTP к хосту с веб-сервером.

Вообще-то, я этот код в статье видел, он делает тоже самое что и netcat, в общем-то, только тут вместо сокета - файл. И что? В качестве протокола всё тот же http в данном случае, хотя вы написали: «не требуется изобретать ещё один протокол и писать программу, реализующую этот протокол». Так вот, конкретно в этом коде написана программка, которая «реализует» http. Дык, где профит то?

> (линукс это уже умеет), и плеер сможет работать через сеть, даже не подозревая об этом ) имхо, большой потенциал здесь есть.

У самого руки пока не дошли (хотя уже давно хочется попробовать). Лично мне дома хотелось бы иметь возможность, не логинясь по SSH, на 2-м ПК:

- записывать DVD,

- опрашивать SMART винчестеров.

Из более экзотических целей для домашнего применения:

- «локально» использовать подключенные мониторы 2-го ПК (xdmx, конечно, тоже вариант),

- использовать openCL-совместимую видеокарту/ЦПУ 2-го ПК для вычислений.

На сегодняшний день уже все из этих пунктов реальны?

> FEEEED MEEE !!11 FEEED MEEE!! THEY WANT OUT BRAIN!!!111

Правильно визжишь. Сравнивать размеры бинарей типа cat сейчас, это именно безумное виззжание. Для особо маленьких размеров есть busybox. Если же сейчас скомпилять coreutils(соотвествующие утилиты естественно) из юниксов конца 80-х - тоже получатся маленькие бинари, ога. Но никто в здравом уме не ставит себе System V оригинальный или пробегавший тут легаси LSL4.

> Лично мне дома хотелось бы иметь возможность, не логинясь по SSH, на 2-м ПК: ...

Ты это, открой для себя ключи ssh - лучьшие кючи ssh в мире, да.

PS
А их даже можно совсем без пароля сделать! Ужос!

PPS
plan9 это сейчас фактически API для разраболтчиков с примерами, не более.

> Автор считает что раз были созданы сокеты и отдельно X сервер и еще кое что, то это типа «портит идеальную картину мира всё файл, что мешает разработчику, типа сложно очень». Не согласен. Если лишь только это по их мнению делает UNIX-подобные ОС морально устаревшими, то можно считать что «ложная тревога».

Ну, морально устаревшими для пользователя, может и нет, но для не матёрого разработчика, думаю, - да. Т.е. специалисты знают, наверняка, уже всё АПИ напамять и им пополам. А посмотрев со стороны, оказывается, что почему-то блочное устройство и один файл (на диске) это просто файл, а вот сокет и файл (на диске) - это уже разные вещи. Почему они, вдруг, разные? Если не ошибаюсь, потому что появились позже, чем блочные устройства и файлы на них. Т.е. новое стало чем-то дополнительным, а не подчинилось принятым договорённостям.

Лично меня очень заинтересовал подход Плана (в плане программирования) после того, как мне пришлось писать коммуникацию через RS-232 и TCP (без блокировки и таймаутов, т.е. через select) под линуксом и виндой. Ну, под виндой, все выглядит очень сложно по сравнению с линуксом. Но и под линуксом это могло бы быть значительно проще!

Тут кто-то программировал уже что-то подобное под План?

> Ты это, открой для себя ключи ssh - лучьшие кючи ssh в мире, да.

Это, конечно, да. Но если у меня, например, 1 «сервер», 1 «десктоп» и 1 ноут, то получается, мне нужно не просто включить ноут с файлами для записи, но и примонтировать нужный каталог на сервере, потом не забыть отмонтировать. И точно также для десктопа. Вместо того, чтобы включив десктоп или ноут просто получить доступ к ресурсам сервера (не подсоединяя к самому серверу ничего лишнего).

PPS
plan9 это сейчас фактически API для разраболтчиков с примерами, не более.

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

> Тут кто-то программировал уже что-то подобное под План?

Вот мне тоже интересно как без селекта и _без_ Limbo написать сервер, поддерживающий тыщи соединений. Limbo нафиг не сдался, ибо в юниксе вместо него можно и Erlang заюзать. Интересует именно родная реализация на C используя легковесные потоки, ну или, на худой конец, используя аналог поллинга на сокетах.

Может кто-нить тыкнуть в пример? ;)

> Вообще-то, я этот код в статье видел, он делает тоже самое что и netcat, в общем-то, только тут вместо сокета - файл. И что? В качестве протокола всё тот же http в данном случае, хотя вы написали: «не требуется изобретать ещё один протокол и писать программу, реализующую этот протокол». Так вот, конкретно в этом коде написана программка, которая «реализует» http. Дык, где профит то?

В данном конкретном случае профит в том, что не надо писать netcat, достаточно наколотить это дело прямо из шелла.

В качестве примера этот код приведен неудачно, поскольку как-раз здесь приходится использовать внешний и по сути чужеродный для Plan9 протокол.

Я понимаю профит (для меня - один из) Plan9 в другом - в унификации подхода. Посредством файлового ввода/вывода делается фактически все. Более того, может быть целая цепочка файловых серверов, на конце которой можно получить требуемый результат. Даже для общения с внешним миром. Надо тебе почту прочитать - запусти соответствующий файловый сервер и читай ее чем угодно, хоть cat'ом, без какого-либо специального почтового клиента. При этом файловый сервер может пользоваться услугами еще одного файлового сервера для получения почты. При этом для системы нет разницы, является ли файловый сервер системным или нет, локальные это файлы, удаленные, да и физические файлы ли это вообще - все взаимодействие идет посредством 9p.

Таким образом можно уйти от использования монстров, умеющих что-то одно более-именее хорошо, все остальное посредственно или отвратительно, и все это по-своему (подход, практикуемый в windows и все больше применяемый в unix-подобных системах), и обратиться к своеобразному развитию так называемого unix-way.

> Собственно с развитием грид систем(и просто систем с выносом сети на юзерлевел) как раз подошли к тому что идеи заложенные в план9, вместе с протоколами и архитектурой будут широко востребованы.

И где широкое применение 9P?

> Я понимаю профит (для меня - один из) Plan9 в другом - в унификации подхода. Посредством файлового ввода/вывода делается фактически все. Более того, может быть целая цепочка файловых серверов, на конце которой можно получить требуемый результат.

Это всё хорошо, но это - только самый низкий уровень. Ты можешь представить РСУБД или оконную систему в виде файлового сервера, не вопрос. Но профита от этого ровно никакого.

> Вот мне тоже интересно как без селекта и _без_ Limbo написать сервер, поддерживающий тыщи соединений.

Простите, но это называется - шаблонное мышление.

Может кто-нить тыкнуть в пример? ;)

HTTP сервер устроит?

http://plan9.bell-labs.com/magic/man2html/8/httpd

http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/ip/httpd/

>> Вот мне тоже интересно как без селекта и _без_ Limbo написать сервер, поддерживающий тыщи соединений.

Простите, но это называется - шаблонное мышление.

http://plan9.bell-labs.com/magic/man2html/8/httpd

Там, насколько я понял, модель «1 запрос - 1 нить», это немного не то, что требуется.

> Это всё хорошо, но это - только самый низкий уровень. Ты можешь представить РСУБД или оконную систему в виде файлового сервера, не вопрос. Но профита от этого ровно никакого.

Если Вы его не видите, это не значит, что его нет.

В качестве примера посмотрите редактор Acme - прекрасный образец оконной системы-файлового сервера с широкими возможностями.

>> Это всё хорошо, но это - только самый низкий уровень. Ты можешь представить РСУБД или оконную систему в виде файлового сервера, не вопрос. Но профита от этого ровно никакого.

Если Вы его не видите, это не значит, что его нет.

Я, можно сказать, только его и вижу. Но нас таких мало. Даже меньше, чем профита от модели «всё - файл-сервер» :)