На конференции CloudOpen ведущие разработчики гипервизора KVM Ави Кивити (Avi Kiviti) и Дор Лаор (Dor Laor) представили (http://mailman.cs.huji.ac.il/pipermail/linux-il/2013-Septemb...) новую свободную операционную систему OSv (http://www.osv.io), выпущенную под лицензией BSD. Система OSv значительно легковеснее Linux и написана на языке C++ с использованием элементов стандарта C++11. В отличие от Linux, OSv был изначально разработана для эффективной работы внутри виртуальной машины, и нацелена на выполнение с максимальной производительностью обособленных приложений, выполняемых с минимальной прослойкой поверх гиперевизора.
Из гипервизоров поддерживаются KVM и Xen, кроме того доступны средства для интеграции с облачным сервисом Amazon EC2. Из особенностей OSv также можно отметить полностью автоматизированный процесс тюнинга и отсутствие необходимости менять конфигурацию выполняемого окружения. Управление может производиться на лету при помощи REST API или через Shell, доступный из SSH. Загрузка приложений в окружения осуществляется по аналогии с платформами PaaS. Обновления осуществляются через перезаливку готового системного образа.
OSv способна запускать программы на языке Си и окружения, подобные JVM. В том числе возможен запуск JVM-реализаций Java (OpenJDK), JavaScript (Rhino, Nashorn), Scala, Clojure, Ruby (jRuby) и Python (Jython). При запуске Java-проектов поддерживаются типовые Java-фреймворки, такие как Tomcat, JBoss и SpringSource. Из поддерживаемых приложения на языке Си отмечаются Memcached, Redis, Nginx и MongoDB. Запуск программ на Си требует дополнительного портирования с учётом упрощённого ядра ОС.
OSv не реализует традиционное (но медленное) разделение между пространством пользования и ядра, так как в облачной инфраструктуре виртуальная машина обычно обслуживает только одно приложение. OSv предоставляет легковесный планировщик ресурсов с реализацией кооперативной многозодачности, при которой ядро и программа используют общие области памяти. В итоге удаётся добиться максимальной отзывчивости и предсказуемой производительности.<center><a href="https://docs.google.com/presentation/d/11mxUl8PBDQ3C4QyeHBT8... src="http://www.opennet.me/opennews/pics_base/0_1379496436.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></a></center>
Из планов на будущее отмечается (http://www.osv.io./devel-menu): поставка специально оптимизированного JVM, изменённого в плане более тесной интеграции с ядром OSv; обеспечение поддержки VMware; расширение средств управления (shell, REST API); улучшение поддержки средств для упрощённого развёртывания приложений в стиле PaaS-систем (Platform as a Service); портирование для архитектур POWER и ARMv8; поддержка запуска приложения на языке Python.
URL: http://mailman.cs.huji.ac.il/pipermail/linux-il/2013-Septemb...
Новость: http://www.opennet.me/opennews/art.shtml?num=37936
Выпустили - всё быстро и хорошо.
Адаптируют ещё под кучу платформ и типов задач - будет тот же линукс.
Ничего не напоминает? Chrome 5 vs Chrome 30 по быстродействию....
> Адаптируют ещё под кучу платформ и типов задач - будет тот же линукс.В этом то и основная фича OSv - никаких платформ, только работа поверх Xen и KVM. Об оборудовании пусть хост-система думает. Никаких типов задач - запускается только одно приложение, Одно окружение OSv - одно приложение.
Только "запустить программу на питон" - без прыга с бубном не вариант, на си - портировать надо, а если кто захочет запустить какой-нибудь ejabberd - парни побегут переписывать половину операционки? И получится в результате очередной склад костылей, когда они запилят возможность запускать программы на чем угодно, а не только на урезанном субсете си и JVM.
Зачем портировать саму программу? Проще портировать интерпретаторы. И не надо будет переписывать операционку.
Да, побольше виртуализации и контейнеров, пожирнее!!! Мало! Мало!! Мало!!!Linux -> KVM -> OSv -> JVM -> там пустить ядро Linux на Жава скрипте, а в ней Qubes.
Обозвать всё это дело Суперзащищенностью, из-за оверхеда придётся купить 1024-ядерные процы
по 50ГГц, минимум 2Tb RAM! и петабайтный RAID, для снапшотов ZFS!
Где-то я это видел, по-моему называется IBM z/OS
>>OSv -> JVM -> там пустить ядро LinuxО, точно. Проглядел, что API - JVM. Тогда придётся портировать компилятор питона под яву и сами питоновые приложения подправлять. Знатный геморрой получается, однако.
Тогда чем это лучше нативной JVM под конкретную ось, я, честно говоря, не знаю. Оверхед.
>Тогда чем это лучше нативной JVM под конкретную ось, я, честно говоря, не знаю.
>Оверхед.Нет юзерспейса. Это уже может дать ощутимый прирост производительности для однозадачных серверов. Какой-нибудь мегасервис типа Facebook или Google с радостью воспользуется подобным решением.
>>>OSv -> JVM -> там пустить ядро Linux
> О, точно. Проглядел, что API - JVM. Тогда придётся портировать компилятор питона
> под яву и сами питоновые приложения подправлять. Знатный геморрой получается, однако.Ничего подправлять особо не надо, ведь существует JPython.
> JPythonЧто это?
> Что это?Это питон. Сделанный окончательно череж ж... ж... жабу!
>>>OSv -> JVM -> там пустить ядро Linux
> О, точно. Проглядел, что API - JVM. Тогда придётся портировать компилятор питона
> под яву и сами питоновые приложения подправлять. Знатный геморрой получается, однако.Jython же вроди объявлен.
В общем выиграли на производительности внутри ос, проиграли на ява-машине...
разве облачные платформы не для этого созданы? Запускать программы поверх абстрактоного железа. (ну с кучей плюшек впридачу) А раз код оптимизировать и там и там придется...
Легкость подобной ос при работе в KVM при сравлении с линуксом сомнительна, к к это тот же процесс в том же планировщике того же линукса.
> разве облачные платформы не для этого созданы? Запускать программы поверх абстрактоного
> железа. (ну с кучей плюшек впридачу) А раз код оптимизировать и
> там и там придется...
> Легкость подобной ос при работе в KVM при сравлении с линуксом сомнительна,
> к к это тот же процесс в том же планировщике того
> же линукса.Внутри облачных виртуальных машин запускаются обычные (т.е. УНИВЕРСАЛЬНЫЕ) ОС, а OSv продвигается как специализированная. Ясен пень, что на своих специализированных задачах она уделает любой универсальный подход. Хотя бы уже тем, что нет постоянного переключения user-kernel.
>поддержка запуска приложения на языке Python.Ну вот когда будет, тогда и будем посмотреть. А пока оптимальнее своего собственного образа генты я как бы ничего и не видел.
Жабовцам.... словом, им вот есть с чего радоваться (наверное), - остальным вряд ли.
Нах жабовцам это не впилось (по крайней мере мне)
>> Config files over 1000И все по дефолту нормально работает
>> Tuning manual, certifiсationsОга, наверно MS-certified
>> License GPL/proprietaryЗачем-то бздишников обидели
Низачет им за пиар.
>И все по дефолту нормально работаетПока не сталкиваетесь с реальной нагрузкой
Еще как радоваться! Несколько JVM на одном железе разом, друг с другом никак не конфликтуют, ресурсы гипервизор распределяет, накладные расходы на виртуализацию минимальны... Сказка!
А так у вас JVM конфликтуют, что ли? Или орперационка ресурсы хуже делит, чем гипервизор?
Про jvm ничего не скажу, а вот то, что СУБД под управлением одной оси жестко конфликтуют за ресурсы - факт. Ну, так возможно и jvm'ы тоже.
>Про jvm ничего не скажу, а вот то, что СУБД под управлением одной оси жестко конфликтуют за ресурсы - факт. Ну, так возможно и jvm'ы тоже.Няяя... А вот они же но запущенные внутри vm - становятся няшными, белыми и пушистыми?
В рашке в IT только точки остались? Жаль. А ведь когда то были величиной =\= 0 :-(
Глупости не говорите!Если каждую СУБД распихать в свою собственную ВМ, то улаживать траблы гонки за ресурсами будет уже гипервизор. А у него это куда лучше получается чем у оси, - в режиме изолированных контейнеров это проще, ибо.
> Глупости не говорите!
> Если каждую СУБД распихать в свою собственную ВМ, то улаживать траблы гонки
> за ресурсами будет уже гипервизор. А у него это куда лучше
> получается чем у оси, - в режиме изолированных контейнеров это проще,
> ибо.Слышали про такую штуку - cgroups?
...
Вот, а они есть.
Дело в том, что JVM одна, а программ выполняется несколько. А тут, как и при любой виртуализации, сразу несколько отдельных машин. Например, хоть десяток глассфишей и томкэтов можно одновременно запустить. И все они могут один порт использовать, но разные айпи адреса. То есть, все плюсы виртуализации и ОЧЕНЬ МАЛЕНЬКИЕ накладные расходы.
Разве не запускается несколько экземпларов явамашины? В целом, вижу плохо оптимизированный софт, раз раскидывание процессов на несколько виртуалок на одном железе ускоряет его работу.
> Разве не запускается несколько экземпларов явамашины?Для этого нужно мозг иметь. Ну хоть какой нить ...
Можно и несколько. Но эффективнее - по разным машинам, потому что не "ускоряет", а "упрощает". Один сервер - одна JVM - один сервис.
> Можно и несколько. Но эффективнее - по разным машинам, потому что не
> "ускоряет", а "упрощает". Один сервер - одна JVM - один сервис.Тогда уж и "... - один физический сервер - одна стойка - один датацентр". Проще некуда :-)
В рамках набора виртуальных машин проще делить ресурсы между _различными_ _пользователями_ . Ну, в том смысле, что каждый из этих пользователей получает в своё распоряжение как бы настоящую систему (в случае с рассматриваемой OSv это, очевидно, не так). В ней у владельца виртуалки есть полный административный доступ, возможность самостоятельно рулить правами, самостоятельно ставить нужные версии софта итп. И вся эта конструкция, тем не менее, остаётся подконтрольной сервис-провайдеру.А ещё сервис-провайдер оказывается в состоянии оверселлить своё железо, что, несомненно, положительно сказывается на его финансовом состоянии. Короче, все в выигрыше ;)
Насколько хорошо в этой схеме будет функционировать рассматриваемая OSv, мне пока непонятно. Виртуальный линукс хорош тем, что это линукс, какая-то его дистрибуция, требуемая для данной задачи (наши, например, биллинг сертифицировали строго под определённые версии сюзи и, кажется, RH). Ограничение в один процесс кажется неудобным - далеко не все задачи по распараллеливанию уместно решать через потоки, к тому же, если речь идёт о писанине на Питоне или Руби.
В общем, сейчас стоит дождаться реакции целевой аудитории - крупных хостеров и прочих клауд-провайдеров.
ХМ... Разве не бвывает приложений которым нужны разные права для своей работы, для изоляции разных процессов там, файлов пользователя и системных. Получается, что взлом любого пользовательского процесса дает доступ ко всему приложению, ошибка в нем херит весь "контейнер" со всеми данными... Ну или нарезать на несколько виртуалок опять же.
> Получается, что взлом любого пользовательского процесса дает доступ ко всему приложениюА взлом гипервизора - ко всем виртуалкам.
Отсюда мораль - сколько прослоек друг на друга не громозди, от криворуких индусов это не спасет.
> далеко не все задачи по распараллеливанию уместно решать через потоки, к тому же, если речь идёт о писанине на Питоне или Руби.в JPython нет GIL, а в JRuby - его аналога.
А. просмотрел, что там только J{ython,Ruby} заявлены. Ну-у, э-э, тогда да. Правда "это уже не Джонни^Wне совсем питон", но куды деваться.
На линуксе контейнеры эту проблему решают запросто. Прямо сейчас, причем это отлаженная технология, для которой давно известны все мыслимые подводные камни и методы борьбы с ними.
> На линуксе контейнеры эту проблему решают запросто. Прямо сейчас, причем это отлаженная
> технология, для которой давно известны все мыслимые подводные камни и методы
> борьбы с ними.Наоборот. UID namespaces, например - очень свежее и экспериментальное минное поле.
Virtuozzo уже обкатано от и до за хрен знает сколько лет.
OpenVZ - это не мейнстрим. Мейнстримный вариант OpenVZ - это LXC. А он пока ооочень сырой.
Пока торт. Запустить томкат сминимумом обвеса...хочу!
> по производительности планировщик OSv опережает Linux на 400%.Ага, в каком-нибудь синтетическом случае, который никто в жизни не увидит в реальных применениях.
>> по производительности планировщик OSv опережает Linux на 400%.
> Ага, в каком-нибудь синтетическом случае, который никто в жизни не увидит в
> реальных применениях.При запуске виртуальной системы, очевидно.
>>> по производительности планировщик OSv опережает Linux на 400%.
>> Ага, в каком-нибудь синтетическом случае, который никто в жизни не увидит в
>> реальных применениях.
> При запуске виртуальной системы, очевидно.Тогда Linux надо грузить с systemd, говорят, там вообще отрицательное время загрузки (ты еще не нажал "вкл", а десктоп уже запустился и готов к работе). Всякие OSv отдыхают по определению))
А что смущает? Что обрезанная операционка шустрее полной?
> А что смущает? Что обрезанная операционка шустрее полной?"обрезанная операционка" - это в ваших израилях.
Что интересно, лицензия BSD авторами преподносится как преимущество ;)
> Что интересно, лицензия BSD авторами преподносится как преимущество ;)Ну так очередной проектец с академическим уклоном: в теории все круто, на практике преимущества высосаны из пальца. А захочешь на таком запустить ejabberd - "ой, а это не предусмотрено в нашей игрушечной операционке".
Вы не на мою мысль отвечаете.
http://erlangonxen.org/
Иначе они бы тупо с CDDL кучу проблем бы поймали.
А вот ещё под вопросом, что первопричина, то что планировали изначально "блоботорговлю" и в результате вынуждены были использовать единственную боле-менее современную фс из доступных под BSD-like лицензией, или же на столько были восхищены ZFS что ради её "технологического стека" выбирали соответствующую лицензию.
И на основании продвигаемых юз-кейсов этой OSv как раз первый вариант выглядит более вероятным.
Угу, очень похоже на то.
Естественно блоботорговля. Еще одни желающие магазина серверных приложений.
Кто-нибудь сможет объяснить чем оно отличается от CoreOS в плане юз кейсов, а не архитектуры?
Типа быстрее и проще, поэтому предпочтительнее для запуска одной программы. Создана абсолютно для другого, в сабже не используется особой изоляции между процессами внутри себя, даже наоборт. Изоляцию и управление ресурсами обеспечивает гипервизор ниже.
Одно приложение - одна ось - один проц - один компьютер - одна жизнь
при этом действительно обратное Одна жиэнь -> много компьютеров -> много процов -> много осей -> много приложений
>обратное Одна жиэнь -> много компьютеров ->"хорошую религию придумали индусы"
DOS 2.0, хотя идея здравая, зачем отдельным приложениям полноценная система, но если все выполняется с одинаковыми правами, как насчет безопасности данных внутри VM, любая уязвимость приложения позволяет получить все пароли и явки присутствующие в системе.
> любая уязвимость приложения позволяет получить все пароли и явки присутствующие в системе.В какой именно системе? В гостевой? Так там практически ничего и нет - только информация этого приложения.
> В какой именно системе? В гостевой? Так там практически ничего и нет
> - только информация этого приложения.зачем тогда вообще ОС если будет запускатся только одно приложение?
> зачем тогда вообще ОС если будет запускатся только одно приложение?API.
>> зачем тогда вообще ОС если будет запускатся только одно приложение?
> API.Это можно сделать и на уровне ядра хост-системы (OpenVZ, LXC).
Наличие дополнительной прослойки в виде выделенного ядра (поверх ядра общего назначения) не вполне оправдано.
Судя по опыту VM/370 - вполне.
> Судя по опыту VM/370 - вполне.Если бы это написал кто-то другой, я бы, возможно, попробовал отнестить к данному утверждению серьезно.
Но после того, как я прочитал ваше давешнее обоснование, почему "wayland создавался исключительно под планшеты", воспринимать вас всерьез, извините, уже не могу.
Оверхед на переключения контекста же. С выделенным ядром приложение работает в одном контексте, т е их не будет.
>> В какой именно системе? В гостевой? Так там практически ничего и нет
>> - только информация этого приложения.
> зачем тогда вообще ОС если будет запускатся только одно приложение?Потому что совсем без ОС приложение работать не будет. Нужен libc и прочие стандартные API.
Ну да, подумаешь приложение имеет доступ к приватным данным, кому они нужны! Главное до гипервизора не добрались!Я хотел сказать, что если виртуалки могут связываться друг с другом только через сеть, а внутри виртуалки защита никакая, то уязвимость может дать доступ к тем данным которые в случае полноценной системы можно было бы защитить, например, веб приложение может не иметь прав на изменение своего кода или не может писать в любую директорию, в случае отсутствия пользователей и разделения процессов защиту организовать гораздо сложнее.
> Ну да, подумаешь приложение имеет доступ к приватным данным, кому они нужны!
> Главное до гипервизора не добрались!
> Я хотел сказать, что если виртуалки могут связываться друг с другом только
> через сеть, а внутри виртуалки защита никакая, то уязвимость может дать
> доступ к тем данным которые в случае полноценной системы можно было
> бы защитить, например, веб приложение может не иметь прав на изменение
> своего кода или не может писать в любую директорию, в случае
> отсутствия пользователей и разделения процессов защиту организовать гораздо сложнее.С некоторыми серверами общение может происходить исключительно через сетевые сокеты. Например, web-сервер лезет за данными на SQL-сервер (или кластер). В этом случае на SQL-сервере (кластере) всякие разграничения по папкам и процессам могут быть излишними.
идея абсолютно нездравая. у этих людей не было доса, вирусни и прочих головняков от отсутствия хардварной защиты.
короче не нужно.
> DOS 2.0Нет, это CMS 2.0. В старой IBMовской, насквозь виртуализированной VM/370 есть специальная гостевая ОС под названием CMS. Насколько я понимаю, subj - инкарнация этой идеи. А DOS отнюдь не затачивалась под работу в виртуальных машинах.
> Нет, это CMS 2.0. В старой IBMовской, насквозь виртуализированной VM/370 есть специальная
> гостевая ОС под названием CMS. Насколько я понимаю, subj - инкарнация
> этой идеи. А DOS отнюдь не затачивалась под работу в виртуальных
> машинах.Вы рассуждаете примерно так же, как Линус стебется: "если это проработало 30 лет - значит, это круто по определению".
Хорошо известные в народе "хрущевки" стоят до сих пор, хотя прошло уже больше 30 лет.
Угу, стоят. И, похоже, развалятся попозже, чем многие новостройки.
> Угу, стоят. И, похоже, развалятся попозже, чем многие новостройки.А вы жить в них пробовали?
Особенно весело, когда в соседней квартире говорят "будьте здоровы" на каждый ваш чих, а зимой приходится покрывать все стены и углы двойным слоем ковров, чтобы хоть как-то защититься от сквозняков с улицы.
Зачем вы дыры в соседнюю квартиру продолбили? Я жил в трёх хрущевках по паре лет в каждой слышно было только, если дети сверху бегали. Хотя Союз большой и строители в нём очень разные были.Сделайте ремонт минвата, гипсокартон, а ковры в музей сдайте и будет вам щасте.
вообще-то квартиры (и хрущевки в т.ч.) во времена СССР государство давало гражданам бесплатно, т.е. по сути дарило (это звучит как ненаучная фантастика сейчас, во времена когда квартиры не даются, а продаются, да еще и за добровольную сдачу в рабство, которое политкорректно именуется "ипотекой"). если вам не нравится ваша квартира - можете вернуть ее обратно государству - скажите что подарок не подошёл, что размер не ваш.
> Вы рассуждаете примерно так же, как Линус стебется: "если это проработало 30 лет - значит, это круто по определению".Не, всё это старо, как говно мамонта. Просто до PC технологии долго доходят. Вспомните, через какое время после изобретения туда пришла защита памяти, вытесняющая многозадачность и т.д.
Персоналки буквально 5-7 лет назад более-менее освоили виртуальные машины (с поддержкой в ЦП), тогда как на mainframe'ах эти виртуальные машины были 30 лет назад. CMS - естественное развитие этой же философии.
--------------------------------------------------------
Вообще, IT не такая бурно развивающаяся отрасль, как кажется. И многие идеи очень долго идут в жизнь. Тот же вывод типов в языках (type inference) придумали сначала в 1969-м, а потом в 1978-м годах. А массово в языках он появился в 90-х и 2000-х.
Здорово - любая перспективная разработка в плане ОС теперь может стать популярной. А не "сначала напиши все драйверы".
> Здорово - любая перспективная разработка в плане ОС теперь может стать популярной.
> А не "сначала напиши все драйверы".Сначала напиши софт.
Вопрос только в том, будет ли это _операционкой_, а не framework-ом
для выполнения какой-то узкой задачи, и куда соответственно денется
понятие переносимого софта и он сам.
> типовые Java-фреймворки, такие как Tomcat, JBoss и SpringSourceTomcat - это фреймворк? И JBoss?
Это просто лишний уровень прослойки между ядром хоста и процессами приложения, не так ли?
> Это просто лишний уровень прослойки между ядром хоста и процессами приложения, не
> так ли?Это очень тонкая прослойка между гипервизором и приложением. Обычная ОС толще.
Что-то всех на жаве заклинило. Сказано же - нативные поддерживаются, только с портированием может быть гемор из-за куцести ядра. Для говнохостинга может сгодиться, если оверхед минимален.
А потому что лично я для жабы профит вижу, а для остального - не очень.
Где угодно, где нужно предоставить потенциально ненадёжному юзеру/коду виртуальный ресурс. Хотя, на фоне соседней новости про netbsd, для общего применения оно бледновато смотрится.
> Где угодно, где нужно предоставить потенциально ненадёжному юзеру/коду виртуальный ресурс.Для этого есть межпроцессная изоляция и разделение привилегий между пользователями.
Если уровень их безопасности недостаточен - значит, нужно решать проблему, а не городить костыли.
> А потому что лично я для жабы профит вижу, а для остального
> - не очень.Да ладно?! Кластер редиса или мемкеша будет благодарен за такую штучку.
На говнохостинге отлично живут контейнеры
А это тот же контейнер, только с оверхедом на виртуализацию.
И походу, единственная мотивация - мода на "облачные технологии".
Годная идея. Кстати, идея не нова. NetBSD пилил подобное. А ещё была коммерческая ОС для запуска приложений на Erlang в легковесной среде поверх гипервизора. Так-что идея не нова.
а по поводу jvm поверх гипервизора так вообще они в печали
http://en.wikipedia.org/wiki/Maxine_Virtual_Machineесли брать еще глубже, то guestvm
https://kenai.com/projects/guestvmThe Maxine Virtual Edition (VE) is a Java platform, implemented in Java, that runs directly on the Xen hypervisor. Maxine VE is based on the Maxine VM and has an integrated network stack and file system written in Java. It runs on 64 bit x86 systems running the Xen hypervisor.
поэтому в данный момент идея не то что не нова, а уже затерта до дыр и таких базовых прототипов создано более чем достаточно. Но почему-то никого из них еще в продакшене нету.
Потому что начальники IT-отделов хотят вывалить все вычисления на юзеров,
а из сервера сделать байтовую помойку с кэшем, который раз в день сливается
с основной базой. Вон мозилла с гуглей совсем прихуели, впаивают компиляторы в браузеры.Лет через 10 на компьютеры буду инкрементально сливаться шифрованные дампы базы и сайта,
а сервер будет работать как коммутатор.
> Потому что начальники IT-отделов хотят вывалить все вычисления на юзеров,
> а из сервера сделать байтовую помойку с кэшем, который раз в день
> сливается
> с основной базой. Вон мозилла с гуглей совсем прихуели, впаивают компиляторы в
> браузеры.
> Лет через 10 на компьютеры буду инкрементально сливаться шифрованные дампы базы и
> сайта,
> а сервер будет работать как коммутатор.Ну так и отлично. Будет очередно "закат мейнфреймов (aka облаков)" и вчисления снова вернутся на юзерские устройства.
Оричинальный закат мейнфреймов произвошел в связи
с ростом производительности персоналок, а грядущий закат облаков произойдет из-за роста производительности мобильный девайсов, недостаточность которой как раз и породила современную моду на "облака".
Почему это "была"?
что только не придумают, лишь бы не использовать уже готовое (Inferno OS, к примеру)
> что только не придумают, лишь бы не использовать уже готовое (Inferno OS, к примеру)У всего готового есть Фундаментальный Недостаток (какой - спросите у Марка).
У такого "готового" есть один очень простой недостаток - это академические поделки, о реальную эксплуатацию не бившиеся. Потому из них удачные идеи тянут в уже устоявшиеся реальные системы. На то эти академические прототипы и нужны.
Один оверхед убирают изобретая 32-битный ДОС, другой добавляют прикручивая к линуксу виртуализацию. Облачным провайдерам это может и надо, а вот разумному человеку хз.
> Облачным провайдерам это может и надо, а вот разумному человеку хз.- Так продукт и не рассчитан на десктоп. Причем здесь пользователь к гипервизорам, виртуализациям и паравиртуализациям, даже если этот пользователь разумен...
> Вместо этого OSv предоставляет легковесный
> планировщик ресурсов с реализацией кооперативной
> многозадачности, при которой ядро и программа
> используют общие области памяти и работают без
> блокировок.Сегодня, в эпоху SMP систем было бы не очень умно жёстко привязывать процесс к использованию ровно одного процессорного ядра. В связи с чем встаёт вопрос: это огрехи перевода, или разработчики разрабатывают свою OSv исходя из каких-то странных соображений?
>> Вместо этого OSv предоставляет легковесный
>> планировщик ресурсов с реализацией кооперативной
>> многозадачности, при которой ядро и программа
>> используют общие области памяти и работают без
>> блокировок.
> Сегодня, в эпоху SMP систем было бы не очень умно жёстко привязывать
> процесс к использованию ровно одного процессорного ядра. В связи с чем
> встаёт вопрос: это огрехи перевода, или разработчики разрабатывают свою OSv исходя
> из каких-то странных соображений?Недолго эпохе массового SMP осталось (в текущем виде, когда все ядра системы находятся в одном SMP-домене). У этого подхода есть довольно жесткие ограничения на масштабируемость (надо ведь как-то когерентность кэшей поддерживать, к примеру, да и отдельный контроллер памяти в каждом процессоре задачу не упрощает) и уже сейчас на двухсокетных x86 серверах широко практикуется применение NUMA (по домену на каждый сокет). И с ростом количества ядер NUMA будет применяться на массовых серверах (где нельзя сделать бычтрый interconnect между сокетами из-за ценовых соображений) все шире.
Мне одному кажется, что гипервизор, управляющий аппаратными ресурсами и в котором выполняются изолированные приложения, которые вне его работать не могут - это не что иное, как... surprise! Операционная система?Ну да, ну типа уровень изоляции у неё сильнее... Или не сильнее, если в гипервизоре есть дыры... Но ведь ОС же.
Не совсем, гипервизор не предоставляет высокоуровневого API виртуальным машинам, уровень изоляции между отдельными сущностями намного выше, нет навороченного управления памятью, драйверов и многого другого, что есть в обычных операционных системах. В то время, как даже DOS, не являясь операционной системой в полном смысле этого выражения, предоставляла приложениям файловую систему.
Это микроядерная операционная система и есть... :)
Да, самое время интегрировать jvm в systemd... Потеринг, ты где?
ein Volk, ein Reich, ein Führer!сначала мы засунули в Кровавый Энтерпрайз кривую тормознутую жабу, а теперь будем её самоотверженно ускорять!
У проекта есть своя четко обозначенная ниша, в которой он дает существенные преимущества.Значит будет жить.
