Comments 30
Извините, но «зачем это нужно» стоит писать в начале а не в конце статьи. Меня этот вопрос мучил на протяжении всей статьи. Отсылать на иностранную вики для пояснения не красиво, в старой статье тоже начинается с установки.
Не приятное впечатление.
Не приятное впечатление.
Несколько лет назад я написал на хабр целый цикл статей, посвящённых как раз этому вопросу — зачем это нужно. Кроме того, людям которые, к примеру, видели только винду или только линух, и никогда не слышали о другой ОС, можно очень долго перечислять какой смысл в существовании неизвестного им линуха/винды, что под ними можно делать полезного, и зачем это может быть нужно. Инферно в этом смысле ничем не хуже — причин её использовать и вариантов этого использования очень много, и если начинать каждую статью об инферно с этого перечисления, то до самой статьи дело уже просто не дойдёт.
Например, лично меня в инферно привлекает возможность писать простые многопоточные приложения, работающие в простой и элегантной среде — это повышает скорость разработки, значительно уменьшает время и усилия необходимые для вылавливания и исправления ошибок, и, самое главное, значительно уменьшает испытываемое в процессе работы раздражение от несовершенства мира в целом и POSIX API в частности. :) Кого-то может привлечь возможность писать кросс-платформенные приложения на чём-то по-лучше Java и .NET. Кого-то — возможность прозрачно объединить и использовать ресурсы самых разных мелких железок и уже имеющихся ОС работающих на обычных машинах (к примеру сервер БД работающий под обычной ОС это ресурс не хуже чем какой-нить датчик, и к нему тоже можно организовать единообразный доступ из любой инферно запущенной в любом другом месте). Кого-то — возможность запустить на своём телефоне полностью «свою» систему со своими приложениями. Кого-то — возможность повышения своей квалификации как разработчика путём изучения исходников действительно простой и элегантной системы. И т.д. и т.п., возможных применений у инферно достаточно много.
Например, лично меня в инферно привлекает возможность писать простые многопоточные приложения, работающие в простой и элегантной среде — это повышает скорость разработки, значительно уменьшает время и усилия необходимые для вылавливания и исправления ошибок, и, самое главное, значительно уменьшает испытываемое в процессе работы раздражение от несовершенства мира в целом и POSIX API в частности. :) Кого-то может привлечь возможность писать кросс-платформенные приложения на чём-то по-лучше Java и .NET. Кого-то — возможность прозрачно объединить и использовать ресурсы самых разных мелких железок и уже имеющихся ОС работающих на обычных машинах (к примеру сервер БД работающий под обычной ОС это ресурс не хуже чем какой-нить датчик, и к нему тоже можно организовать единообразный доступ из любой инферно запущенной в любом другом месте). Кого-то — возможность запустить на своём телефоне полностью «свою» систему со своими приложениями. Кого-то — возможность повышения своей квалификации как разработчика путём изучения исходников действительно простой и элегантной системы. И т.д. и т.п., возможных применений у инферно достаточно много.
я чего-то не понимаю в этой жизни. ОС для написания кросс-платформенных приложений? Это для тех, кому пользоваться SDK не достаточно хардкорно?
Если бы инферно изначально разрабатывалась просто для написания кросс-платформенных приложений, вероятно из неё получилась бы не ОС, а что-то другое, может быть и SDK. Насколько я понимаю, всё происходило примерно так. Возникла потребность в единообразном доступе к самым разным ресурсам предоставляемым самым разным железом, в т.ч. мелкими встроенными устройствами. Взяли существующую OS Plan9, подправили чтобы она работала на нужных железках с минимумом ресурсов (инферно для работы хватает 1MB RAM!), а для простоты разработки и переносимости приложений между всеми этими устройствами добавили виртуальную машину и переписали все приложения OS под неё. Благодаря тому, что все приложения ОС оказались внутри виртуалки, стало довольно просто их контролировать, и появилась возможность реализовать все необходимые виртуалке ресурсы не только через драйвера к реальному железу, но и через API обычных ОС.
В результате получилась ОС, которая будучи запущена на каком-нить датчике с 1MB RAM, на фотоаппарате, на линух сервере или виндовой рабочей станции предоставляет единообразный доступ ко всем ресурсам всех этих систем и возможность писать приложения которые могут работать без изменений на любой из этих систем. Например, на виндовой рабочей станции может крутится приложение, которое при получении определённых показаний от датчика делает снимок фотоаппаратом и заливает его на какой-нить фотохостинг используя для доступа в инет сетевую подсистему линух сервера (что-то вроде NAT, только без NAT :)). При этом само приложение ничего про все эти детали знать не будет вообще — оно будет просто читать данные из одних файликов и писать в другие.
Эти возможности несколько выходят за рамки простых кросс-платформенных приложений, не так ли? Вот поэтому оно и ОС, а не SDK.
В результате получилась ОС, которая будучи запущена на каком-нить датчике с 1MB RAM, на фотоаппарате, на линух сервере или виндовой рабочей станции предоставляет единообразный доступ ко всем ресурсам всех этих систем и возможность писать приложения которые могут работать без изменений на любой из этих систем. Например, на виндовой рабочей станции может крутится приложение, которое при получении определённых показаний от датчика делает снимок фотоаппаратом и заливает его на какой-нить фотохостинг используя для доступа в инет сетевую подсистему линух сервера (что-то вроде NAT, только без NAT :)). При этом само приложение ничего про все эти детали знать не будет вообще — оно будет просто читать данные из одних файликов и писать в другие.
Эти возможности несколько выходят за рамки простых кросс-платформенных приложений, не так ли? Вот поэтому оно и ОС, а не SDK.
Судя по описанию (на Гитхабе и Вашем), OS Inferno — это все же не «распределенная», а «распространяемая» ОС.
В российской IT-традиции «распределенными» называют системы, работающие одновременно на нескольких узлах, с потенциальной возможностью одновременной обработки одного набора данных и, в современных ипостасях, даже прозрачного переноса уже запущенных процессов на другие хосты (как, например, в Cluster Server).
А Инферно все же это «обычная» виртуальная машина, причем не интегрированная в ОС. Что-то среднее между VirtualBox и JVM. Неплохая, но все же пока «вторичная», как разные веб-ОС поверх Javascript в браузере.
В российской IT-традиции «распределенными» называют системы, работающие одновременно на нескольких узлах, с потенциальной возможностью одновременной обработки одного набора данных и, в современных ипостасях, даже прозрачного переноса уже запущенных процессов на другие хосты (как, например, в Cluster Server).
А Инферно все же это «обычная» виртуальная машина, причем не интегрированная в ОС. Что-то среднее между VirtualBox и JVM. Неплохая, но все же пока «вторичная», как разные веб-ОС поверх Javascript в браузере.
Я не знаю насчёт «русской традиции», но есть термин Distributed operating system и инферно ему соответствует. Прозрачного переноса уже запущенных процессов в ней нет, но всё остальное наличествует. На русский этот термин переводится как «распределённая операционная система».
Ваши рассуждения насчёт виртуальной машины тоже не соответствуют действительности. Во-первых инферно это не виртуальная машина. Инферно это операционка (по сути это вариант вполне традиционной OS Plan9), которая после загрузки запускает единственный процесс — виртуальную машину Dis, которая уже в свою очередь выполняет код всех других приложений. Так что если это не называется «VM интегрирована в ОС», то что тогда так называется? Средним между VirtualBox и JVM Dis тоже никак не является — это такая же VM как JVM, и ничего общего с VirtualBox там нет. В чём заключается «вторичность» я тоже не понял — инферно вполне работает на голом железе, на куче разных архитектур. Просто плюс к драйверам, которые работают с голым железом, в инферно написали драйвера, которые работают через syscall-ы *NIX/Win, и получили возможность запускать инферно поверх этих ОС вместо голого железа. Эта фича никак не делает инферно «вторичной».
Ваши рассуждения насчёт виртуальной машины тоже не соответствуют действительности. Во-первых инферно это не виртуальная машина. Инферно это операционка (по сути это вариант вполне традиционной OS Plan9), которая после загрузки запускает единственный процесс — виртуальную машину Dis, которая уже в свою очередь выполняет код всех других приложений. Так что если это не называется «VM интегрирована в ОС», то что тогда так называется? Средним между VirtualBox и JVM Dis тоже никак не является — это такая же VM как JVM, и ничего общего с VirtualBox там нет. В чём заключается «вторичность» я тоже не понял — инферно вполне работает на голом железе, на куче разных архитектур. Просто плюс к драйверам, которые работают с голым железом, в инферно написали драйвера, которые работают через syscall-ы *NIX/Win, и получили возможность запускать инферно поверх этих ОС вместо голого железа. Эта фича никак не делает инферно «вторичной».
Спасибо! Вряд ли буду ставить, но вдруг:)
А про язык Limbo статью не напишете?
А про язык Limbo статью не напишете?
Обзор давно написан: habrahabr.ru/post/8974/ плюс есть полное описание языка на русском: powerman.name/Inferno/Limbo.html
UFO just landed and posted this here
Волков бояться — в лес не ходить! ;-)
Если честно, я подозреваю, что такие зловещие названия были выбраны не случайно. В Bell Labs работали отличные программисты, а они обычно не особо любят маркетологов и прочих sales, поэтому не исключено что названия были выбраны из вредности, с целью максимально осложнить им жизнь. Другое объяснение — просто не повезло. Кто-то из разработчиков читал в это время Данте, а мы все знаем, как сложно придумать названия своим проектам — вот он и мог пойти простым путём, взяв первые попавшиеся названия из читаемой в этот момент книжки, чтобы не морочить себе голову. Впрочем, повезло или не повезло этой операционке с названием это ещё вопрос, лично мне название нравится.
Если честно, я подозреваю, что такие зловещие названия были выбраны не случайно. В Bell Labs работали отличные программисты, а они обычно не особо любят маркетологов и прочих sales, поэтому не исключено что названия были выбраны из вредности, с целью максимально осложнить им жизнь. Другое объяснение — просто не повезло. Кто-то из разработчиков читал в это время Данте, а мы все знаем, как сложно придумать названия своим проектам — вот он и мог пойти простым путём, взяв первые попавшиеся названия из читаемой в этот момент книжки, чтобы не морочить себе голову. Впрочем, повезло или не повезло этой операционке с названием это ещё вопрос, лично мне название нравится.
Отличные программисты обычно не любят маркетологов и sales? Ничо так стетеотипчики у вас в голове. На чем-то основанно, или так, из религиозных соображений?
У них цели слишком разные. Хорошему программисту интересно сделать элегантное решение, его интересует качество архитектуры, кода… и не очень интересуют сроки и стоимость. Маркетологам и продажникам нужно заработать денег, чем больше тем лучше, а что конкретно они продвигают и продают им обычно всё равно. Отсюда возникает конфликт интересов, причём вполне себе неизбежный. А из конфликта, когда на программиста давят с целью получить что-то, что можно будет продавать, как можно быстрее и дешевле, возникает та самая упомянутая мной не любовь.
С точки зрения бизнеса «хороший» программист тот, который учитывает потребности бизнеса в своей работе, и, вместо вылизывания кода, как можно быстрее и дешевле релизит относительно рабочий (a.k.a. «good enough») продукт (а то и вообще нечто, что только выглядит рабочим продуктом). С точки зрения программирования, «хороший» программист тот, который пишет качественный и элегантный код. Судя по Вашему удивлению, Вы считаете что хорошие программисты должны учитывать требования бизнеса, и, соответственно, если они это делают, то причин не любить маркетологов и sales у них нет. А если они этого не делают, то называть их хорошими программистами некорректно. Я прав? Такая точка зрения вполне логична и приемлема. Но мне всё-таки ближе другое определение «хороший» программист или нет, не замутнённое требованиями бизнеса.
С точки зрения бизнеса «хороший» программист тот, который учитывает потребности бизнеса в своей работе, и, вместо вылизывания кода, как можно быстрее и дешевле релизит относительно рабочий (a.k.a. «good enough») продукт (а то и вообще нечто, что только выглядит рабочим продуктом). С точки зрения программирования, «хороший» программист тот, который пишет качественный и элегантный код. Судя по Вашему удивлению, Вы считаете что хорошие программисты должны учитывать требования бизнеса, и, соответственно, если они это делают, то причин не любить маркетологов и sales у них нет. А если они этого не делают, то называть их хорошими программистами некорректно. Я прав? Такая точка зрения вполне логична и приемлема. Но мне всё-таки ближе другое определение «хороший» программист или нет, не замутнённое требованиями бизнеса.
Я совершенно не согласен с тем, что цели у них разные. Цель программиста — написать хороший продукт. Sales более чем заинтересованы в том, чтобы продукты были хорошего качества. Где конфликт?
Ваша предпосылка, что маркетологи и sales предпочитают продавать гавно и заставляют программистов поступаться качеством просто не верна, и именно она меня удивляет.
И да, хорошие программисты обязаны учитывать одно требование бизнеса — требование качества.
Ваша предпосылка, что маркетологи и sales предпочитают продавать гавно и заставляют программистов поступаться качеством просто не верна, и именно она меня удивляет.
И да, хорошие программисты обязаны учитывать одно требование бизнеса — требование качества.
Самое смешное в том, что я абсолютно с Вами согласен. В теории, именно так всё и должно быть. К сожалению, на практике всё обстоит иначе. Хотя иногда попадаются заповедные места. Я сейчас именно в таком и работаю. Но это исключение, а не правило. И даже я вижу, что с другим подходом можно было бы заработать намного больше денег. К счастью, владелец бизнеса не ставит перед собой задачу заработать как можно больше как можно быстрее.
На самом деле таких мест намного больше чем кажется. Любая долгосрочная стратегия предполагает как можно более близкое к идеальному качество. И ваш босс, поверьте, ставит перед собой задачу заработать как можно больше, но как вы правильно заметили, не как можно быстрее.
Стереотип, что Sales и маркетинг готовы пожертвовать качеством лишь бы выпустить абы-что появился из нескольких хрестоматийных примеров, и к сожалению, очень живуч (см. минусы на мои коментарии). К счастью, это лишь стереотип. Найти компанию, в которой ценят качество, не преставляет труда (сложнее найти обратное). Тот-же Dell labs — прекрасный пример того, как убыточный business unit существует вполне безбедно, для того, чтобы повысить качество всей компании. Что характерно, в любой крупной компании существуют подобные innovations labs, убыточные по определению.
Стереотип, что Sales и маркетинг готовы пожертвовать качеством лишь бы выпустить абы-что появился из нескольких хрестоматийных примеров, и к сожалению, очень живуч (см. минусы на мои коментарии). К счастью, это лишь стереотип. Найти компанию, в которой ценят качество, не преставляет труда (сложнее найти обратное). Тот-же Dell labs — прекрасный пример того, как убыточный business unit существует вполне безбедно, для того, чтобы повысить качество всей компании. Что характерно, в любой крупной компании существуют подобные innovations labs, убыточные по определению.
UFO just landed and posted this here
UFO just landed and posted this here
Все три варианта вполне достойные.
Если основная задача — обучение и самообразование, то лучше займитесь инферно. Изучение исходников инферно/Plan9 реально очень сильно прочищает мозги и помогает многое понять о том, как надо и как не надо программировать, причём это даже в большей степени касается программистов с 10-15+ лет опыта, чем новичков.
Если планируется использовать выбранную платформу в проекте, где кроме Вас будут и другие разработчики — лучше взять Go или Erlang. Инферно всё-таки совсем мало известная система, и Вам будет сложно объяснить необходимость её использования в проекте.
Выбор между Go и Erlang определяется в большей степени характеристиками Вашего проекта — если он похож на те задачи, для которых изначально разрабатывался Erlang — лучше него Вы ничего не найдёте; если же проект более-менее общего назначения, то предпочтительнее использовать Go.
Если основная задача — обучение и самообразование, то лучше займитесь инферно. Изучение исходников инферно/Plan9 реально очень сильно прочищает мозги и помогает многое понять о том, как надо и как не надо программировать, причём это даже в большей степени касается программистов с 10-15+ лет опыта, чем новичков.
Если планируется использовать выбранную платформу в проекте, где кроме Вас будут и другие разработчики — лучше взять Go или Erlang. Инферно всё-таки совсем мало известная система, и Вам будет сложно объяснить необходимость её использования в проекте.
Выбор между Go и Erlang определяется в большей степени характеристиками Вашего проекта — если он похож на те задачи, для которых изначально разрабатывался Erlang — лучше него Вы ничего не найдёте; если же проект более-менее общего назначения, то предпочтительнее использовать Go.
UFO just landed and posted this here
Веб-разработка тоже бывает разная. У меня в проекте сайты крутятся на Perl+FastCGI+libev. Perl удобен в плане обработки текста (разбор/генерация HTTP, рендеринг html-шаблонов), FastCGI+libev дают отличную скорость работы, но писать код в событийно-ориентированном стиле — это кучи callback-ов, которые довольно непросто понимать и контролировать. Поэтому основная функциональность вынесена в отдельные сетевые сервисы, часть из которых крутится на инферно, а часть на том же Perl+libev (ещё не дошли руки переписать на инферно).
Теоретически можно полностью поднять сайт на инферно — у mjl (ссылка в конце статьи) есть для этого все необходимые приложения и библиотеки. Но я с этим пока не разбирался. Хотя в планах есть. Не думаю, что имеет смысл поднимать инферновский веб-сервер (вряд ли он будет корректно работать со всевозможными кривыми клиентами как это за столько лет научились делать apache и nginx), но вот FastCGI сервис на инферно поднять наверное смысл есть. По крайней мере можно будет избавиться от куч callback-ов и использовать нормальные нити. Тем более, что я прикрутил к инферно библиотечку re2, и теперь в инферно есть настоящие мощные и удобные регулярные выражения, даже лучше перловских.
Теоретически можно полностью поднять сайт на инферно — у mjl (ссылка в конце статьи) есть для этого все необходимые приложения и библиотеки. Но я с этим пока не разбирался. Хотя в планах есть. Не думаю, что имеет смысл поднимать инферновский веб-сервер (вряд ли он будет корректно работать со всевозможными кривыми клиентами как это за столько лет научились делать apache и nginx), но вот FastCGI сервис на инферно поднять наверное смысл есть. По крайней мере можно будет избавиться от куч callback-ов и использовать нормальные нити. Тем более, что я прикрутил к инферно библиотечку re2, и теперь в инферно есть настоящие мощные и удобные регулярные выражения, даже лучше перловских.
Спасибо за статью.
PS «готовая к использованию в продакшне на коммерческих проектах (мы её именно там и используем)».
В каких проектах используете?
В каких проектах используете?
В разных. У нас весь backend реализован в стиле SOA — много разных сетевых сервисов на разных серверах через которые проходит довольно большой поток данных 24x7. Когда начали внедрять инферно не рискнули переделывать всю архитектуру в стиле естественном для инферно (файловые интерфейсы и 9P) а просто реализовали часть этих обычных tcp-шных сетевых сервисов на инферно. После нескольких лет работы принято решение потихоньку переходить таки на более естественный для инферно стиль работы через 9P вместо tcp, но пока до этого руки ещё не дошли.
Честно не очень понимаю зачем заморачиваться с Инферно, но при этом отказываться от 9P?
Затем, что это коммерческий проект. Внедрение редких и непроверенных технологий вроде Инферно подразумевает высокие риски, которые требовалось минимизировать. Поэтому внедрение проводилось постепенно и осторожно, в частности ценой потери некоторой эффективности в связи с отказом от активного использования 9P с самого начала.
Обновил инструкции по установке для Windows.
Sign up to leave a comment.
Установка OS Inferno New Edition (update)