Комментарии 197
круто! спасибо за статью.
Читать замучился, но мне понравилось =)
Отлично. Давно гуглил почитать чтото пережеванное о синугларитиос
Спасибо за перевод. Наконец-то я понял, что такое эта Singularity. :)
Грамотно написать ОС можно при помощи обработчиков, с копированием блока памяти и возвратом статуса. Простой пример:
Базовый обработчик работы с диском представляет собой блочное устройство, назовем его blrw.
На blrw делаем обработчик, который предоставляет файловую систему - fs.
При записи fs выделяет область памяти, через blrw копирует в нее содержимое диска, выполняет операции и контролирует целостность fs. Если все успешно - ставится флаг, если нет - то код ошибки.
blrw, в который прошел вызов обрабатывает флаг и копирует (или не копирует) область памяти на диск. Если и тут произошел сбой - идет флаг в микроядро, которое делает шатдаун/паник
Такой подход полностью соответствует парадигме ООП, и работу файловой системы можно представить в виде объекта blrw.fs, где функции низкого уровня приватны и доступны только для обхекта fs.
В свою очередь, объект fs может предоставить тип файловой системы - fs.vfat, fs.ext3 и каждый будет со своими свойствами и методами
Обработка ошибок будет многоступенчатая, что снижает риск.
Драйверы, от глюков которых падает система, тоже могут быть оформлены в виде объектов.
Например vid - объект работающий с видеоподсистемой, а vid.ati - с картами фирмы ati.
Если карта не может выполнить операцию, то экран переключается в режим vid (vesa/vga), который работает по умолчанию на большинстве карт и работа продолжается
Базовый обработчик работы с диском представляет собой блочное устройство, назовем его blrw.
На blrw делаем обработчик, который предоставляет файловую систему - fs.
При записи fs выделяет область памяти, через blrw копирует в нее содержимое диска, выполняет операции и контролирует целостность fs. Если все успешно - ставится флаг, если нет - то код ошибки.
blrw, в который прошел вызов обрабатывает флаг и копирует (или не копирует) область памяти на диск. Если и тут произошел сбой - идет флаг в микроядро, которое делает шатдаун/паник
Такой подход полностью соответствует парадигме ООП, и работу файловой системы можно представить в виде объекта blrw.fs, где функции низкого уровня приватны и доступны только для обхекта fs.
В свою очередь, объект fs может предоставить тип файловой системы - fs.vfat, fs.ext3 и каждый будет со своими свойствами и методами
Обработка ошибок будет многоступенчатая, что снижает риск.
Драйверы, от глюков которых падает система, тоже могут быть оформлены в виде объектов.
Например vid - объект работающий с видеоподсистемой, а vid.ati - с картами фирмы ati.
Если карта не может выполнить операцию, то экран переключается в режим vid (vesa/vga), который работает по умолчанию на большинстве карт и работа продолжается
Насколько я знаю Singularity не единственная система написаная на C#. Про другие системы можете что-нибудь написать?
есть еще CosmOS
правда, мне с ходу не удалось найти у них на сайте подробностей о том, какую модель изоляции они там используют
забавно еще видеть у них в FAQ это:
правда, мне с ходу не удалось найти у них на сайте подробностей о том, какую модель изоляции они там используют
забавно еще видеть у них в FAQ это:
Developers of Cosmos should not look at Singularity source to avoid contaminating Cosmos and violating the Singularity license.
If you want to check out real Open Source OSes written in c# go to http://www.sharpos.org, http://www.ensemble-os.org/ or http://www.gocosmos.org/
НЛО прилетело и опубликовало эту надпись здесь
Еще есть Cosmos.
хороший перевод, спасибо. но Mike Hearn, видимо, периодами впадает в черную депрессию и начинает писать ужоснахи вроде
>>К примеру, QNX — операционная система, разработанная для встроенных приложений, вроде роутеров Cisco
или
>>Windows NT разрабатывалась как чисто микроядерное решение, но ... они однажды сдались и «переехали» в ядро вместе с GUI — за что получили массу критики, но это сделало Windows отзывчивой, а юзеров счастливыми.
впихнуть полную реализацию сетевых протоколов (особенно SMB :) ) в kernel-space было, конечно, отличным способом осчастливить юзеров.
к переводу претензий никаких, еще раз огромное спасибо.
>>К примеру, QNX — операционная система, разработанная для встроенных приложений, вроде роутеров Cisco
или
>>Windows NT разрабатывалась как чисто микроядерное решение, но ... они однажды сдались и «переехали» в ядро вместе с GUI — за что получили массу критики, но это сделало Windows отзывчивой, а юзеров счастливыми.
впихнуть полную реализацию сетевых протоколов (особенно SMB :) ) в kernel-space было, конечно, отличным способом осчастливить юзеров.
к переводу претензий никаких, еще раз огромное спасибо.
заманчиво..
Давно пора переходить на новую систему, которая не будет нести кучи
проблем и болячек старых ОС. Грамотно спроектированная и написанная с нуля ОС будет иметь все шансы на огромный успех, даже с учетом того что она будет абсолютно несовместима со старым ПО.
И как бы вы не любили Microsoft, это единственная фирма которая имеет достаточный опыт в разработке ОС и имеет финансовые возможности для осуществления переворота на рынке ОС.
проблем и болячек старых ОС. Грамотно спроектированная и написанная с нуля ОС будет иметь все шансы на огромный успех, даже с учетом того что она будет абсолютно несовместима со старым ПО.
И как бы вы не любили Microsoft, это единственная фирма которая имеет достаточный опыт в разработке ОС и имеет финансовые возможности для осуществления переворота на рынке ОС.
еще IBM способна на это.
Вообще, давно пора переходить на новую платформу, чтобы не тащить за собой вагон проблем архитектуры x86
А причем тут x86? :]
Microsoft делает операционку под x86, так? Сингулярити, фигулярити — нет никакой разницы, потому что платформа x86 сама по себе изначально ущербна.
Нуу... вообще Windows NT была и под PowerPC и под Alpha. Только вот Alpha уже не жива (хотя технологически решение было существенно более лучшее чем x86), а PowerPC не сильно майнстрим. Вообще виживают не самые технологически правильные вещи, а те что становятся массовыми и дешевыми. Хороший пример это как раз x86 платформа.
Грамотно спроектированная и написанная с нуля ОС будет иметь все шансы на огромный успех
Хорошие технические решения без должной поддержки и раскрутки полный пшик. К тому же под платформу Windows и *nix написано огромное количество ПО. Так что новая ОС должна предоставлять легкие методики портирования на нее иначе софта на ней не появится и юзать ее никто не будет. ОС это не самоцель это просто окружение для запуска нужных вам программ.
>> И как бы вы не любили Microsoft
если сингулярити будет распространяться под GPL то я с радостью поставлю ее себе.
>> это единственная фирма которая имеет достаточный опыт в разработке ОС
ого!
если сингулярити будет распространяться под GPL то я с радостью поставлю ее себе.
>> это единственная фирма которая имеет достаточный опыт в разработке ОС
ого!
Нереально круто, хотя и знакомо много.
Пошел распечатывать, хочу перечитать более вдумчиво.
Спасибо!
Пошел распечатывать, хочу перечитать более вдумчиво.
Спасибо!
Я так понял, что отсутствие виртуальной памяти в Singularity ограничивает суммарную потребляемую память размером RAM? Или я где-то невнимательно прочитал?
Вобщем, все в контексте винды написано. Возникает вопрос, а нафига тогда упоминать линух и никсы вообще? Да и вообще зачем говорить про новую ОСь, опираясь на винду?
Вот кусок, например:
1. Около 80% всех крэшей в Windows вызваны глюками в драйверах.
2. Анализ кода Linux показал, что код драйверов в 7 раз более подвержен ошибкам, чем остальные части ядра.
3. Когда драйвер падает, он забирает «на тот свет» всю систему, при этом теряются данные пользователя и — как следствие — его доверие.
Ну что за бред? :) Когда это линух падал от ошибки в модуле? Спокойно выгрузит лишний глючный модуль и продолжит работу, ни на какой "тот" и "этот" свет не пойдет. И кто это код линуха анализировал? девелоперы мелкософта?
Собсно я к тому, что в тексте про мелкософт упоминать вскользь линух, а потом писать в этом контексте про ошибки опять же винды как-то неуместно, получается впечатление, что это "везде так", а это ошибка.
А дальше вообще интересно. Например, вот: "Каналы — это основанные на сообщениях пайпы, вроде UNIX'овых сокетов, но строго типизированных и быстрых"
Как может быть пересылка куска памяти void* медленнее, чем "строго типизированный" канал? А как же проверки? А как же накладные расходы?
Ну и сама суть - C#. Это ж за собой тянуть всю платформу для того, что бы "ядро" запустить? А кто же тогда запустит платформу? Вот тот кусок, который "немного на С++ и ассемблере" ? Это что же получается, лоадер грузит .NET, который далее грузит "ядро". Стоп. А куда и как лоадер грузит этот .NET?
Ну и накладные расходы байт-кода.
Вобщем, одни вопросы и никаких ответов. Где, хотя бы, замеры скорости, которые, как говориться в статье, провели участники проекта? Где цифры то?
За труды по переводу - спасибо, но, имхо, по сути это все похоже на воспевание непонятно чего.
Вот кусок, например:
1. Около 80% всех крэшей в Windows вызваны глюками в драйверах.
2. Анализ кода Linux показал, что код драйверов в 7 раз более подвержен ошибкам, чем остальные части ядра.
3. Когда драйвер падает, он забирает «на тот свет» всю систему, при этом теряются данные пользователя и — как следствие — его доверие.
Ну что за бред? :) Когда это линух падал от ошибки в модуле? Спокойно выгрузит лишний глючный модуль и продолжит работу, ни на какой "тот" и "этот" свет не пойдет. И кто это код линуха анализировал? девелоперы мелкософта?
Собсно я к тому, что в тексте про мелкософт упоминать вскользь линух, а потом писать в этом контексте про ошибки опять же винды как-то неуместно, получается впечатление, что это "везде так", а это ошибка.
А дальше вообще интересно. Например, вот: "Каналы — это основанные на сообщениях пайпы, вроде UNIX'овых сокетов, но строго типизированных и быстрых"
Как может быть пересылка куска памяти void* медленнее, чем "строго типизированный" канал? А как же проверки? А как же накладные расходы?
Ну и сама суть - C#. Это ж за собой тянуть всю платформу для того, что бы "ядро" запустить? А кто же тогда запустит платформу? Вот тот кусок, который "немного на С++ и ассемблере" ? Это что же получается, лоадер грузит .NET, который далее грузит "ядро". Стоп. А куда и как лоадер грузит этот .NET?
Ну и накладные расходы байт-кода.
Вобщем, одни вопросы и никаких ответов. Где, хотя бы, замеры скорости, которые, как говориться в статье, провели участники проекта? Где цифры то?
За труды по переводу - спасибо, но, имхо, по сути это все похоже на воспевание непонятно чего.
у меня убунта падала из-за ошибки в видеодрайвере!
>> Как может быть пересылка куска памяти void* медленнее, чем "строго типизированный" канал?
а в каналах Singularity ничего не пересылается это просто абстракция поэтому они и быстрее
там напрямую пишется/читается память, без копирования
>> Ну и сама суть - C#. Это ж за собой тянуть всю платформу для того, что бы "ядро" запустить?
эта "платформа" очень маленькая если хотите живых примеров, смотрите на ха-ха Silverlight, там минимальный рантайм, достаточный для выполнения C# впихнут в полтора мегабайта вместе с остальным функционалом Silverlight.
>> Где, хотя бы, замеры скорости, которые, как говориться в статье, провели участники проекта? Где цифры то?
цифры есть в официальных публикациях, которые нетрудно найти
>> Как может быть пересылка куска памяти void* медленнее, чем "строго типизированный" канал?
а в каналах Singularity ничего не пересылается это просто абстракция поэтому они и быстрее
там напрямую пишется/читается память, без копирования
>> Ну и сама суть - C#. Это ж за собой тянуть всю платформу для того, что бы "ядро" запустить?
эта "платформа" очень маленькая если хотите живых примеров, смотрите на ха-ха Silverlight, там минимальный рантайм, достаточный для выполнения C# впихнут в полтора мегабайта вместе с остальным функционалом Silverlight.
>> Где, хотя бы, замеры скорости, которые, как говориться в статье, провели участники проекта? Где цифры то?
цифры есть в официальных публикациях, которые нетрудно найти
>> у меня убунта падала из-за ошибки в видеодрайвере!
холивар -> там :)
как это абстракция? а как же типизация? и что они тогда шлют по этой абстракции? если написано "типизировано" - значит должны быть проверки типов.
платформа маленькая? да ну бросьте :) вы мне лучше скажите, как эта плафторма стартует _до_ ядра.
цифры погляжу ;)
холивар -> там :)
как это абстракция? а как же типизация? и что они тогда шлют по этой абстракции? если написано "типизировано" - значит должны быть проверки типов.
платформа маленькая? да ну бросьте :) вы мне лучше скажите, как эта плафторма стартует _до_ ядра.
цифры погляжу ;)
проверки типов происходят еще во время установки приложения
а в run-time код тупо "фигачит"
>> вы мне лучше скажите, как эта плафторма стартует _до_ ядра
она не стартует "до ядра"
там пара тысяч строк кода на C, который и "стартует" эту платформу
а в run-time код тупо "фигачит"
>> вы мне лучше скажите, как эта плафторма стартует _до_ ядра
она не стартует "до ядра"
там пара тысяч строк кода на C, который и "стартует" эту платформу
а нафиг такой канал? :) я думал несколько иначе о них, типа для передачи данных между процессами, как-то так.
Дык не все так просто со стартом, имхо. Интересно будет поглядеть, что дальше будет.
Дык не все так просто со стартом, имхо. Интересно будет поглядеть, что дальше будет.
>> а нафиг такой канал? :) я думал несколько иначе о них, типа для передачи данных между процессами, как-то так.
он и нужен для передачи данных между процессами
просто к данным быстрее обращаться напрямую, чем копировать их туда-сюда ;)
Singularity гарантирует безопасность такого доступа, поэтому там так можно делать, а в Unix нельзя :)
он и нужен для передачи данных между процессами
просто к данным быстрее обращаться напрямую, чем копировать их туда-сюда ;)
Singularity гарантирует безопасность такого доступа, поэтому там так можно делать, а в Unix нельзя :)
воот! Дык если между процессами, то в шарпе я могу динамически создать разные типы и кидать их в канал, совсем не в compile-time, а именно в рантайме. И если канал мне гарантирует типизацию, то "проверки типов происходят еще во время установки приложения" бессмысленно.
к слову сказать, в Singularity "динамизм" приложений сильно ограничен в частности, там нет Reflection и нельзя генерировать код в run-time опять же, из-за соображений безопасности (из-за того, что такой код невозможно верифицировать статически)
Почитал я еще раз, подумал, и никак не возьму в толк. Вот взяли они .NET, обрезали его хорошенько, запихнули на уровень ядра и... И что, собсно, получили? Особых фишек .NET-а уже нет, если GC оставили - провал производительности, имхо таки убрали, что там остается? Reflection нет тоже, дык вроде бы и получился тот же С++, тольк объектный. А, забыл вроде проверки границ массивов и подобные фишечки платформы, но это же накладные все те же расходы, ведь так?
Вобщем то, я почему то не вижу смысла в этом деянии, обрезать шарп до уровня плюсов, запихнуть его в ядро, внести кучу абстракций, которые вносят дополнительные расходы, и что же получаем? "Быстродействие" ? Вот уж вряд ли, что-то моя сомневаться сильно-сильно :( Не верю я в жизнь байт-кода в ядре.
Вобщем то, я почему то не вижу смысла в этом деянии, обрезать шарп до уровня плюсов, запихнуть его в ядро, внести кучу абстракций, которые вносят дополнительные расходы, и что же получаем? "Быстродействие" ? Вот уж вряд ли, что-то моя сомневаться сильно-сильно :( Не верю я в жизнь байт-кода в ядре.
>> там нет Reflection и нельзя генерировать код в run-time
Кошмар, нет reflection? А какже тогда всякие Linq там работать будут? Или их на уровень доверенных библиотек вынесут? Да и вообще reflection иногда просто незаменим!
Кошмар, нет reflection? А какже тогда всякие Linq там работать будут? Или их на уровень доверенных библиотек вынесут? Да и вообще reflection иногда просто незаменим!
собственно, абстракция канала это часть формальной модели, которая используется для гарантии свойств безопасности
эта абстракция сильнее, чем абстракция "вот у нас есть кусок памяти и мы можем в него писать по рандомным адресам" с ней легче доказать интересующие нас свойства
эта абстракция сильнее, чем абстракция "вот у нас есть кусок памяти и мы можем в него писать по рандомным адресам" с ней легче доказать интересующие нас свойства
Ну кхмм, сильверлайт не очень хороший пример=) во первых под виндовс он занимает 4 мегабайта, а не полтора, но у меня подозрение что его удалось уменьшить за счет использования библиотек из самого виндовса(директикс какой нибудь там и прочее).
А под линукс для него нужен mono (.net для линукса) который весит 40 метров=) + сам moonlight 3 метра.
А под линукс для него нужен mono (.net для линукса) который весит 40 метров=) + сам moonlight 3 метра.
то линукс
в Windows-версии используется независимая от десктопного .NET среда исполнения как раз и впихнутая в дистрибутив
про библиотеки речь не идёт интересует именно минимальный размер run-time, необходимый для работы C#-кода
в Windows-версии используется независимая от десктопного .NET среда исполнения как раз и впихнутая в дистрибутив
про библиотеки речь не идёт интересует именно минимальный размер run-time, необходимый для работы C#-кода
.NET Micro Framework, ограниченное подмножество .NET, в самом сокращенном виде может занимать всего 390 Kb.
в 4 мегабайта помимо среды исполнения C# впихнуты еще и библиотеки, и плагин для браузера, и рендеринг графики и чёрт знает что еще
>но у меня подозрение что его удалось уменьшить за счет использования библиотек из самого виндовса
Давайте засудим Apple за "использования библиотек из самого виндовса" =)
Давайте засудим Apple за "использования библиотек из самого виндовса" =)
Убунта вся падала, или только X не стартовал?
>> Когда это линух падал от ошибки в модуле? Спокойно выгрузит лишний глючный модуль и продолжит работу
вызывающе неверная информация, модуль обладает всеми правами ядра (и вообще это код ядра, просто загружается по-другому), и посылает систему в crash одной левой пяткой
накладные расходы на UNIX пайпы связаны с переключением контекста, потому как это системные вызовы
вызывающе неверная информация, модуль обладает всеми правами ядра (и вообще это код ядра, просто загружается по-другому), и посылает систему в crash одной левой пяткой
накладные расходы на UNIX пайпы связаны с переключением контекста, потому как это системные вызовы
ммм? я занимался писательством модулей ядра и знаю, о чем говорю. при ошибке модуль выгружается.
а пайпы в сингулярити не будут ядерными и не будет переключений контекста?
а пайпы в сингулярити не будут ядерными и не будет переключений контекста?
При какой "ошибке" ? Модуль, к примеру, может "по ошибке" повредить любую внутреннюю структуру данных ядра. Как ядро об этом узнает ? Память-то у них общая, никакого разграничения доступа нет.
вы имеете в виду что модуль может выгрузить себя если нашел аппаратную ошибку? ну так и немодульный драйвер может себя отключить. Проблема в том, что ошибку обнаружить можно наверное только в нескольких процентах случаев, если же идет банальный сбой по памяти, то ядру можно только стреляться.
в сингулярити нет переключений контекста, вы статью не читали?
в сингулярити нет переключений контекста, вы статью не читали?
нет, я хотел сказать, что в большинстве случаев, когда винда валится в бсод, в линухе драйвер просто выгружается, например при работе с памятью по несуществующему адресу или при проваливании стека.
нет, такое сделать, увы, нереально в ядре, при достуре по NULL или несуществующему адресу просто вылетает Oops, да и способов поломать ядро на порядок больше - испортить структуры или подсунуть испорченные, испоганить таблицу сегментов, самое замечательное это залочить перерывания навечно или просто нагадить в своем обработчике прерываний, и т.п.
Вот тот кусок, который "немного на С++ и ассемблере" ? Это что же получается, лоадер грузит .NET, который далее грузит "ядро". Стоп. А куда и как лоадер грузит этот .NET?
Ну и накладные расходы байт-кода.
Тут вот подробнее написано http://www.rsdn.ru/article/singularity/s…
Реально там не используется VM, а используется компиляция в бинарный код. Для того чтобы в коде небыло ошибок, компилятор осуществляет валидацию на уровне компиляции кода.
>Ну и сама суть - C#. Это ж за собой тянуть всю платформу для того, что бы "ядро" запустить?
Лол, ты не понимаешь разницу между C# (на самом деле Sing#) и .Net?
Взял бы и проверил, чем позориться. Нету в Singularity .Net Framework. Да и runtime особо нет.
Лол, ты не понимаешь разницу между C# (на самом деле Sing#) и .Net?
Взял бы и проверил, чем позориться. Нету в Singularity .Net Framework. Да и runtime особо нет.
ндя... перевести всю систему на байт-код MSIL... может оно и хорошо с точки зрения безопасности, но с точки зрения быстродействия самого кода - вряд ли. Не достигли еще JIT-компиляторы байт-кода такого же совершенства, как оптимизирующие компиляторы C++.
Вычислительные мощности дешевле, чем труд программистов, пишущих быстрый и безопасный код.
там не JIT-компилятор, трансляция в машинный код производится в deploy-time, при установке приложения
вообще-то и сегодня в .NET приложениях это практикуется - google "ngen"
вообще-то и сегодня в .NET приложениях это практикуется - google "ngen"
Насколько я понял там не MSIL, а свой компайлер который делает бинарный файлы.
да, мне тоже показалось это сомнительно как то
Еще пара вопросов:
а) код будет открытым?
б) есть какие-нибудь сроки выхода?
в) как оно например в сравнении с каким-нибудь Minix?
а) код будет открытым?
б) есть какие-нибудь сроки выхода?
в) как оно например в сравнении с каким-нибудь Minix?
a) код недавно был открыт (валяется на CodePlex)
б) говорить о сроках выхода неуместно, т.к. это исследовательский проект, а не full-blown OS
в) Minix это совсем другое различны модели изоляции, в Singularity код формально верифицируем
б) говорить о сроках выхода неуместно, т.к. это исследовательский проект, а не full-blown OS
в) Minix это совсем другое различны модели изоляции, в Singularity код формально верифицируем
Лицензия MSR-LA http://www.codeplex.com/singularity/lice…
Сейчас сырцы можете скачать.
под вистой установить не удалось. по причине оцуцтвия .net 1.1 (2.0 дифолтовый и есть разница - читал в конференции на кодеплексе)
под вистой установить не удалось. по причине оцуцтвия .net 1.1 (2.0 дифолтовый и есть разница - читал в конференции на кодеплексе)
интересно, но сложно читать такую большую статься с экрана. хотел распечатать, но не нашел на хабре print view :(
aardvark (если у вас Firefox)
при установке программы она компилируется и статически проверяется различными анализаторами.
прям Gentoo какая-то :-)
Если на картинке интерфейс этой системы то это ппц конечно полный, виндовс фореве!!!
Запустите пожалуйста в "виндовс форева" cmd.exe - ужаснетесь убогости интерфейса. Нет, правда.
А нахер мне её запускать, мне вполне хватает графического интерфейса великого виндовса ХП
Действительно, вам ее не нужно запускать. Главное чтобы вам права выше Users в виндах случайно не дали. Power users для вас слишком много.
а кто мне может права какие-то давать я сам себе хозяин на своем компутере
Свой гробьте сколько хотите. А в любой конторе с админом - только users, поскольку даже элементарных основ вы не знаете.
...и твой компутер уже не твой, а часть ботнета :P
Увидел картинку и сразу в каменты срать, ай-яй-яй
У этой системы еще нет пользовательского интерфейса. И, может быть, никогда не будет. Не для того ее делают, что всякие своими грязными ручищами... :)
http://www.habrahabr.ru/blog/os_inferno/ - Оч похожая идея, только оно может работтать внутри другой ОС, те не требует драйверов для железа, и имеет ещё много полезных фич.
Оооо, великий план9 :) Это ИМХО вообще тяжелейшая форма наркомании. Чего стоит только cat /dev/net/http/ru/wikipedia/org :)
Хотя на домашнем "кластере" из 4-х виртуалок оно прожило 2 месяца :)
Хотя на домашнем "кластере" из 4-х виртуалок оно прожило 2 месяца :)
Отличная статья, прочитал, несмотря на объём, на одном дыхании)
Спасибо автору и переводчику!
Спасибо автору и переводчику!
Singularity — это микроядерный дизайн, особенностями которого являются высокая производительность, единое адресное пространство, статическая верификация типов и гибкое управление правами доступа.
Всё-таки, высокая производительность никогда не была особенностью микроядерного дизайна. Собственно, в оригинале всё правильно написано:
Singularity is a high performance, single address space microkernel design, which uses static type verification to enforce reliability properties and flexible pattern based ACLs.
Всё-таки, высокая производительность никогда не была особенностью микроядерного дизайна. Собственно, в оригинале всё правильно написано:
Singularity is a high performance, single address space microkernel design, which uses static type verification to enforce reliability properties and flexible pattern based ACLs.
у меня написано, что высокая производительность это особенность микроядерного дизайна Singularity, а не микроядерного дизайна вообще
просто не подумал, что кто-то может прочитать иначе
сейчас исправлю
просто не подумал, что кто-то может прочитать иначе
сейчас исправлю
собственно, и оригинал можно точно так же misunderstand "high performance, single address space microkernel design", прочитав это, можно подумать, что эти эпитеты относятся к любому microkernel design
Спасибо большое, очень интересно было почитать.
Самый главный вопрос: можно ли будет мегатонны уже существующего софта заставить работать хотя бы через какой-нибудь полупрозрачный эмулятор. Иначе сложно представить, как может быть осуществлён переход на такую новую платформу.
Самый главный вопрос: можно ли будет мегатонны уже существующего софта заставить работать хотя бы через какой-нибудь полупрозрачный эмулятор. Иначе сложно представить, как может быть осуществлён переход на такую новую платформу.
"Я ничего не понял из того что ты сказал, но ты достучался до моего сердца!".
Спасибо вам за статью. Очень далек от темы, но было очень интересно и написано вполне популярно. Great job!
Спасибо вам за статью. Очень далек от темы, но было очень интересно и написано вполне популярно. Great job!
я нихера не понял из того что ты сказал, но ты мне близок... ты... ты... достучался до моего сердца!
(с) Джей и молчаливый Боб наносят ответный удар
(с) Джей и молчаливый Боб наносят ответный удар
Забыли тесты скорости создания процессов в линкс, винде сингулярити, пин-понг между ядрами и кажется выделение памяти.
Отличнейшая статься, узнал для себя много нового. Спасибо.
С огромным интересом прочёл, спасибо!
Есть кое-какие странности:
"Виртуальная память — отличная штука, одно из самых больших улучшений надежности компьютеров за последние 13 лет. Windows 3.1 не использовала её, в отличие о Windows 95"
Т.е. своп в Win 3.x мне приснился?
"В чистом MSIL мы не можем записать специализированные инструкции, необходимые для управления железом, поэтому нам нужно какое-то другое решение. И оно выглядит, как что-то вроде небезопасной DLL, предоставляющее объекты, абстрагирующие инструкции, управляющие железом."
И чем это принципиально отличается от драйверов в традиционных ОС? Что тут, что там - нативный код, работающий напрямую с железом.
"К счастью для нас, на помощь приходит DRM! Да, я не шучу! Новейшие архитектуры CPU, разрабатываемые в Intel и AMD, обладают кое-чем, называющимся (довольно удачно) IOMMU. Эта штуковина делает для железа то, что обычный MMU делает для процессора — регулирует доступ к памяти, проецируя чтение/запись по DMA через таблицы страниц. Работая с IOMMU, вы можете предотвратить несанкционированный доступ к памяти по DMA."
Замечательно, но зачем тогда вообще использовать MSIL и среду исполнения .net? Чтоб софт тормозил? Достаточно добавить поддержку такого железа в существующие ОС (если ее там еще нет).
В общем, МС опять развлекаются созданием bloatware путем заметания мусора под ковер и нагромождения лишних сущностей.
"Виртуальная память — отличная штука, одно из самых больших улучшений надежности компьютеров за последние 13 лет. Windows 3.1 не использовала её, в отличие о Windows 95"
Т.е. своп в Win 3.x мне приснился?
"В чистом MSIL мы не можем записать специализированные инструкции, необходимые для управления железом, поэтому нам нужно какое-то другое решение. И оно выглядит, как что-то вроде небезопасной DLL, предоставляющее объекты, абстрагирующие инструкции, управляющие железом."
И чем это принципиально отличается от драйверов в традиционных ОС? Что тут, что там - нативный код, работающий напрямую с железом.
"К счастью для нас, на помощь приходит DRM! Да, я не шучу! Новейшие архитектуры CPU, разрабатываемые в Intel и AMD, обладают кое-чем, называющимся (довольно удачно) IOMMU. Эта штуковина делает для железа то, что обычный MMU делает для процессора — регулирует доступ к памяти, проецируя чтение/запись по DMA через таблицы страниц. Работая с IOMMU, вы можете предотвратить несанкционированный доступ к памяти по DMA."
Замечательно, но зачем тогда вообще использовать MSIL и среду исполнения .net? Чтоб софт тормозил? Достаточно добавить поддержку такого железа в существующие ОС (если ее там еще нет).
В общем, МС опять развлекаются созданием bloatware путем заметания мусора под ковер и нагромождения лишних сущностей.
>> Т.е. своп в Win 3.x мне приснился?
думаю, автор просто перепутал версии windows, в Win 3.x действительно впервые появилась виртуальная память
>> И чем это принципиально отличается от драйверов в традиционных ОС? Что тут, что там - нативный код, работающий напрямую с железом.
мы работаем не напрямую с железом, а через HAL, который является SIP это значит, что мы еще при установке драйвера знаем всё про этот драйвер и про то, как он взаимодействует с железом
это значит, что драйвер не будет делать то, чего от него не ожидают
>> Замечательно, но зачем тогда вообще использовать MSIL и среду исполнения .net? Чтоб софт тормозил?
а кто сказал, что там софт тормозит? и почему он должен тормозить? MSIL используется для развёртывания приложения (deployment), а не для непосредственного исполнения
зачем это нужно очень подробно описано в статье
>> В общем, МС опять развлекаются созданием bloatware путем заметания мусора под ковер и нагромождения лишних сущностей.
к сожалению, лишние сущности необходимы для гарантий безопасности
вы же сами видите, что творится в Windows сегодня ;)
думаю, автор просто перепутал версии windows, в Win 3.x действительно впервые появилась виртуальная память
>> И чем это принципиально отличается от драйверов в традиционных ОС? Что тут, что там - нативный код, работающий напрямую с железом.
мы работаем не напрямую с железом, а через HAL, который является SIP это значит, что мы еще при установке драйвера знаем всё про этот драйвер и про то, как он взаимодействует с железом
это значит, что драйвер не будет делать то, чего от него не ожидают
>> Замечательно, но зачем тогда вообще использовать MSIL и среду исполнения .net? Чтоб софт тормозил?
а кто сказал, что там софт тормозит? и почему он должен тормозить? MSIL используется для развёртывания приложения (deployment), а не для непосредственного исполнения
зачем это нужно очень подробно описано в статье
>> В общем, МС опять развлекаются созданием bloatware путем заметания мусора под ковер и нагромождения лишних сущностей.
к сожалению, лишние сущности необходимы для гарантий безопасности
вы же сами видите, что творится в Windows сегодня ;)
еще раз насчёт "тормозов"
вы не подумали о том, что в Singularity благодаря свойствам её рантайма возможно, к примеру, заинлайнить вызовы драйвера при компиляции? это возможно лишь managed-среде исполнения
у таких систем потенциал в производительности намного выше, чем у традиционных
вы не подумали о том, что в Singularity благодаря свойствам её рантайма возможно, к примеру, заинлайнить вызовы драйвера при компиляции? это возможно лишь managed-среде исполнения
у таких систем потенциал в производительности намного выше, чем у традиционных
Своп под 3.1 был только на 80386. Была еще Windows 286, это какая-то обточенная то ли 3.0 то ли 3.1 под 286 онли, но умела ли она vm - не помню, а в википедию лезть за этой пылью лень:)
Спасибо за перевод. Сам не знаю как я его дочитал до конца ;)
Огромное спасибо за пост, очень интересно было почитать.
а зачем она нужна то вообще? это десктопная или серверная ось предполагается? или просто как лабораторный эксперимент? если она выйдет из лаборатории, то откуда под нее софт появится? микрософт опять нечем заняться, вот и дурят.
лучше чем Виндовс ХП никогда уже не придумают
По сути ядро singularity - это одна виртуальная машина, выполняющая инъектируемые куски кода. Круто.
Насчет Java хочется поправить, что untrusted code через reflection не может (и никогда не мог) получить доступ к системным ресурсам, поскольку выполнение кода контролируется SecurityManager-ом. Проблемы с эксплоитами возникали в имплементации Java 1.1 от Microsoft, где были обойдены некоторые основные принципы спецификации в угоду более native интеграции с платформой Windows (например, любой объект автоматически имплементировал COM).
Насчет Java хочется поправить, что untrusted code через reflection не может (и никогда не мог) получить доступ к системным ресурсам, поскольку выполнение кода контролируется SecurityManager-ом. Проблемы с эксплоитами возникали в имплементации Java 1.1 от Microsoft, где были обойдены некоторые основные принципы спецификации в угоду более native интеграции с платформой Windows (например, любой объект автоматически имплементировал COM).
Хорошая статья по теме, была на RSDN на великом и могучем.
По теме:
1. В теории выглядит конечно хорошо и ново, но пока дело до практического применения не дошло, то говорить об эффективности и надежности - сложно, разве что только в теории. А тем временем, l4 уже себя отлично зарекомендовало в embedded устройствая.
2. "К счастью для нас, на помощь приходит DRM! Да, я не шучу! Новейшие архитектуры CPU, разрабатываемые в Intel и AMD, обладают кое-чем, называющимся (довольно удачно) IOMMU. Эта штуковина делает для железа то, что обычный MMU делает для процессора — регулирует доступ к памяти, проецируя чтение/запись по DMA через таблицы страниц."
Туманно и непонятно, что тут за архитектуры такие. Тем не менее, вот это предложение как раз и означает лишь то, что на данный момент (пока такие "новейшие архитектуры CPU" не используються) драйвер легко может закрашить систему, через DMA контроллер (что собственно я и писал в соседней теме о Windows Se7en и надежности ОС), т.е. все прелести Singularity по защите памяти и ресурсов, для драйверов - пустой звук. Кстати, у PPC давно уже есть аппаратный IOMMU.
3. "Что может такой драйвер сделать, кроме как накосячить со звуковой картой? Да ничего. Хоть он и может подвесить систему, неправильно программируя железо, такие баги очень редки."
Ой как опрометчиво. Такая вещь, как Interrupt lookup как раз таки очень часто возникает (я в Linux не разу не видел kernel panic, а вот interrupt lookup от своей звуковой карты - неоднократно), и завешивают систему намертво.
А вообще, конечно Microsoft применила интересный подход, эдакая микроядерность в новом стиле.
По теме:
1. В теории выглядит конечно хорошо и ново, но пока дело до практического применения не дошло, то говорить об эффективности и надежности - сложно, разве что только в теории. А тем временем, l4 уже себя отлично зарекомендовало в embedded устройствая.
2. "К счастью для нас, на помощь приходит DRM! Да, я не шучу! Новейшие архитектуры CPU, разрабатываемые в Intel и AMD, обладают кое-чем, называющимся (довольно удачно) IOMMU. Эта штуковина делает для железа то, что обычный MMU делает для процессора — регулирует доступ к памяти, проецируя чтение/запись по DMA через таблицы страниц."
Туманно и непонятно, что тут за архитектуры такие. Тем не менее, вот это предложение как раз и означает лишь то, что на данный момент (пока такие "новейшие архитектуры CPU" не используються) драйвер легко может закрашить систему, через DMA контроллер (что собственно я и писал в соседней теме о Windows Se7en и надежности ОС), т.е. все прелести Singularity по защите памяти и ресурсов, для драйверов - пустой звук. Кстати, у PPC давно уже есть аппаратный IOMMU.
3. "Что может такой драйвер сделать, кроме как накосячить со звуковой картой? Да ничего. Хоть он и может подвесить систему, неправильно программируя железо, такие баги очень редки."
Ой как опрометчиво. Такая вещь, как Interrupt lookup как раз таки очень часто возникает (я в Linux не разу не видел kernel panic, а вот interrupt lookup от своей звуковой карты - неоднократно), и завешивают систему намертво.
А вообще, конечно Microsoft применила интересный подход, эдакая микроядерность в новом стиле.
Хороший перевод. Хорошая статья. Прям разработка будущего.
Микроядро в 17 метров? Подождем, что дальше из этого будет.
> Восемьдесят процентов крэшей Windows вызвано глюкавыми драйверами,
> а не ошибками в ядре (подозреваю, что остальные 20% вызваны сбоями в железе).
Повесилило, особенно то что в скобках :)
> а не ошибками в ядре (подозреваю, что остальные 20% вызваны сбоями в железе).
Повесилило, особенно то что в скобках :)
17 метров - многовато для микроядра..
Тем временем, разработчикам QNX удалось добится практически мгновенной загрузки (миллисикунды) на Intel Atom.
http://onqpl.blogspot.com/2008/06/do-fas…
http://onqpl.blogspot.com/2008/06/do-fas…
Круто, все переходим на Singularity, предварительно выбросив в помойку - Игрушки, офисы, вообщем-то весь GUI soft и весь win32 софт. Хорошая новость - кое-что можно будет поднять из написаного на Java, C#, ocaml, Haskell.
Серьезно, я когда читал это года 2 назад - сильно проперся, а потом решил узнать как они собираются прицепить ко всей этой красоте хотя бы win32 - ответ был - не собираемся. Надеюсь передумают - поднимут в этом объектно-ориентированном пространстве - LegacyWin32Process, который по старой памяти будет использовать MMU и context switching.
Серьезно, я когда читал это года 2 назад - сильно проперся, а потом решил узнать как они собираются прицепить ко всей этой красоте хотя бы win32 - ответ был - не собираемся. Надеюсь передумают - поднимут в этом объектно-ориентированном пространстве - LegacyWin32Process, который по старой памяти будет использовать MMU и context switching.
Сдается мне, для чего этот проект задуман - так это чтобы похерить такие проги, как Daemon Tools. Дескать, DRM - это наше всё. В смысле - всё, песец.
Не совсем так... чет статья не совсем про Сингулярити, это не виртуалка, и не "как выше было написано" первая операционка на С#,и ни как в статье написано что основная цель это микроядро и упор на безопасность.. все это да...
но идея другая...
Сингурярити - это первая объекто-ориентировнная операционная система! =)
Кто хочет знать подробнее читайте арзивы rsdn magazine =)
но идея другая...
Сингурярити - это первая объекто-ориентировнная операционная система! =)
Кто хочет знать подробнее читайте арзивы rsdn magazine =)
при всей своей нелюбви к ms вынужден все же счесть, что тут они копают в правильном направлении.
Странно, но идеи эти давно витали в воздухе. Фриман много высказывался по поводу проектирования систем будущего (хотябы ЕС его вспомнить, надеюсь, что она развивается). Только там за идею проектирования системы брался объектный подход. Одним из вариантов реализации было построение виртуальной машины, поддерживающей объекты на своем "машинном" уровне (в ЕС это по-моему называется крэкером). Такая ВМ могла быть написана как для голого железа, так и для существующей ОС в качестве простого приложения. Защита тоже планировалась, как я понял, чисто математическая в основе объекты. В качестве средств разработки выбраны 2 языка реализующие различные парадигмы программирования, спроектированные специально для ЕС. Да, это ограничения, но они позволяют добиться защиты адресных пространств процессов (ой, прошу прощения, там понятия процесса нет, как и программы). Вообще много новшеств планировалось, но все уперлось в реализацию. А новшеств было множество: отказ от файловой системы в пользу постреляционной БД, новый подход к безопасному проектированию ПО, использование последний разработок в области UI (Zoom world, аналоги интерфейса на canon cat)...
Есть вики проекта, но там помоему все уехало совсем в иные края...
http://unienv.org/
Люди знают мало альтернатив, совсем мало... А их на самом деле куча, идей много новых, куд больше неплохих реализаций старых. HelenOS, например, очень себе приятна внутри =) FOS от Олега наиболее понятное микроядро (код очень хороший)...
Спасибо за статью. Отличная)
Есть вики проекта, но там помоему все уехало совсем в иные края...
http://unienv.org/
Люди знают мало альтернатив, совсем мало... А их на самом деле куча, идей много новых, куд больше неплохих реализаций старых. HelenOS, например, очень себе приятна внутри =) FOS от Олега наиболее понятное микроядро (код очень хороший)...
Спасибо за статью. Отличная)
Кто-нибудь может привести сравнение Singularity с JNode?
Ну, в общем, довольно свежие и элегантные идеи присутствуют. Однако есть и спорные места, а именно:
- Многопользовательская работа: невозможность поставить программу локально без проверки админом.
- Закрытость кода: 100% стабильность невозможна без 100%-ой осведомленности.
- Многопользовательская работа: невозможность поставить программу локально без проверки админом.
- Закрытость кода: 100% стабильность невозможна без 100%-ой осведомленности.
Просто спасибо, огромное спасибо за перевод. Узнал немало нового про эту OS.
"Микроядра типично медленнее, чем монолитные ядра — из-за накладных расходов на переключения между режимами процессора (user-mode в kernel-mode и обратно). Кроме того, существуют еще и расходы на переключение процессора между двумя процессами пользовательского режима (переключение контекста)" это вроде бы имеет смысл только для x86 и прочей CISC, или я не прав?
Идея связки "единое адресное пространство + типобезопасный язык" заимствована из Oberon OS Вирта.
Что-то мне кажется что оно не доживет до полноценной ОС, хотя концепции безусловно интересные
тачскрин в командной строке?
это однозначно круто! )))
это однозначно круто! )))
спасибо. Очень понравилось. Красивый концепт.
"ядерный разработчик" - улыбнуло
Что-то где-то как-то не так... Что мешает криворукому драйверописателю написать драйвер под некое своё устройство, который будет через DMA гробить систему? Некий плумифический IOMMU? А как он работает на системах, где контроллер шины и памяти находится не в CPU, а в чипсете? Он же 100% аппаратно зависымый от чипсета. У AMD он реализован в гипертранспорте, у Интела - через их чудо-виртуализацию. Я если процессор не Intel и не AMD? А если архитектура не x86?
Второй момент - если все исполняется в одном коце защты, то любая минимальаня уязвимость даёт полный и абсолютный контроль над системой и никакие антивирусы не помогут, т.к. они тоже работают на более высоком уровне. А уязвимостей будет вагон - сделать 100% надёжный анализатор это нынче из области фантастики - нужно менять всю филисофию программирования. Плюс, уязвимость в любом компоненте автоматически распространяет её на всю систему - с таким механизмом защиты достатончо пропустить однин модуль и все кто нипопадя смогут им воспорльзоваться, ведь он страсть какой доверенный.
Третий момент - все эти танцы с динамической компиляцией и уборкой мусора на данный момент работают весьма сомнительно. Уборка мусора в частности приводит к крайне неравномерной производительности системы - скорость исполнения может меняться в стотни раз в зависимости от объёма доступной памяти. Не говоря о том, что это большой тормоз на многих алгоритмах.
Короче, идея забавная, но на нынешнем этапе развития науки и техники слабореализуемая. Хотя кто знает, куда этот путь выведет...
Второй момент - если все исполняется в одном коце защты, то любая минимальаня уязвимость даёт полный и абсолютный контроль над системой и никакие антивирусы не помогут, т.к. они тоже работают на более высоком уровне. А уязвимостей будет вагон - сделать 100% надёжный анализатор это нынче из области фантастики - нужно менять всю филисофию программирования. Плюс, уязвимость в любом компоненте автоматически распространяет её на всю систему - с таким механизмом защиты достатончо пропустить однин модуль и все кто нипопадя смогут им воспорльзоваться, ведь он страсть какой доверенный.
Третий момент - все эти танцы с динамической компиляцией и уборкой мусора на данный момент работают весьма сомнительно. Уборка мусора в частности приводит к крайне неравномерной производительности системы - скорость исполнения может меняться в стотни раз в зависимости от объёма доступной памяти. Не говоря о том, что это большой тормоз на многих алгоритмах.
Короче, идея забавная, но на нынешнем этапе развития науки и техники слабореализуемая. Хотя кто знает, куда этот путь выведет...
>> Уборка мусора в частности приводит к крайне неравномерной производительности системы
это только если руки растут из задницы
во-первых, ядро Singularity предоставляет на выбор несколько различных GC
во-вторых, ничто не мешает просто выделить через GC большой плоский шматок памяти и строить свой собственный аллокатор поверх него разве это не очевидно?
это только если руки растут из задницы
во-первых, ядро Singularity предоставляет на выбор несколько различных GC
во-вторых, ничто не мешает просто выделить через GC большой плоский шматок памяти и строить свой собственный аллокатор поверх него разве это не очевидно?
Ээээ... а ваш аллокатор не соврешенно не будет использовать никаких объектных типов, включая встроенные? Если да, то он всё равно будет засирать свою память. Во-вторых, строить свой аллокатор это бред, а кучу расширять тоже самому? Может ещё и аналог MMU для простоты написать и поверх него свою ось? :))))
>> строить свой аллокатор это бред
вообще, да, мне тоже кажется, что это бред
мне просто непонятны задачи, которые вы собираетесь решать, где GC не подходит и нельзя построить workaround поверх объектной модели Singularity для специфического алгоритма
>> Не говоря о том, что это большой тормоз на многих алгоритмах.
вот мне и интересно, каких
вообще, да, мне тоже кажется, что это бред
мне просто непонятны задачи, которые вы собираетесь решать, где GC не подходит и нельзя построить workaround поверх объектной модели Singularity для специфического алгоритма
>> Не говоря о том, что это большой тормоз на многих алгоритмах.
вот мне и интересно, каких
Про аллокаторы - берём какой-нибудь более-менее сложную программу на языке уборкой мусора - что-то вроде Netbean или eclipse и с ужасом види что они засирают >500 МБ памяти за две секунды работы. Плюс до трети процессорного времни уходит на уборку мусора.
Так чтобы с ходу - архиваторы, медипроигрыватели, медиакодеки, работа с графикой.
Так чтобы с ходу - архиваторы, медипроигрыватели, медиакодеки, работа с графикой.
ну нет, у меня Eclipse не засирает больше 100-200 мб обычно, и уж тем более не через 2 секунды работы
там внизу, кстати, есть кнопочка "collect garbage" и счётчик used/allocated memory, вот вы попробуйте туда нажать
если GC запросил у системы 500 мб памяти, это не означает, что он использует все 500 мб
медиакодекам, насколько мне известно, не нужны сложные структуры данных, использующие объектную модель вроде .NET, всё что нужно алгоритмам кодеков описывается POD (plain old data) структурами, которые ещё с первого CLR поддерживаются в .NET (называется value-тип, хранится в хипе, как сишная структура, as is)
вообще вы попробуйте для CLR какое-нибудь приложение построить, вот тогда и будем говорить, а то у вас, похоже, такое впечатление, что там на каждую временную переменную в счетчике цикла выделяется объект на куче :D
семантика MSIL-программ намного яснее для компилятора, чем семантика C (из-за отсутствия random access memory), это позволяет легко делать оптимизации, вроде region inference (когда время жизни объектов выводится ещё на этапе компиляции, и выделение памяти на куче заменятся на стек)
медиапроигрыватели это вообще GUI над медиакодеками, там тормозить-то нечему
а насчёт работы с графикой.. ну вот я сейчас работаю с 3D-графикой на работе, и почему-то прекрасно всё работает из C# :) дело в том, что современные приложения для работы с графикой используют ресурсы GPU для этого, и вся "работа с графикой" сводится к дерганью вызовов драйвера (через DirectX), а с этим хоть тормознейший Ruby справится и не подавится
посмотрите, к примеру, на WPF (современный GPU-ускоренный фреймворк для построения GUI для .NET) вот уж что там тормозит, так это точно не рендеринг
там внизу, кстати, есть кнопочка "collect garbage" и счётчик used/allocated memory, вот вы попробуйте туда нажать
если GC запросил у системы 500 мб памяти, это не означает, что он использует все 500 мб
медиакодекам, насколько мне известно, не нужны сложные структуры данных, использующие объектную модель вроде .NET, всё что нужно алгоритмам кодеков описывается POD (plain old data) структурами, которые ещё с первого CLR поддерживаются в .NET (называется value-тип, хранится в хипе, как сишная структура, as is)
вообще вы попробуйте для CLR какое-нибудь приложение построить, вот тогда и будем говорить, а то у вас, похоже, такое впечатление, что там на каждую временную переменную в счетчике цикла выделяется объект на куче :D
семантика MSIL-программ намного яснее для компилятора, чем семантика C (из-за отсутствия random access memory), это позволяет легко делать оптимизации, вроде region inference (когда время жизни объектов выводится ещё на этапе компиляции, и выделение памяти на куче заменятся на стек)
медиапроигрыватели это вообще GUI над медиакодеками, там тормозить-то нечему
а насчёт работы с графикой.. ну вот я сейчас работаю с 3D-графикой на работе, и почему-то прекрасно всё работает из C# :) дело в том, что современные приложения для работы с графикой используют ресурсы GPU для этого, и вся "работа с графикой" сводится к дерганью вызовов драйвера (через DirectX), а с этим хоть тормознейший Ruby справится и не подавится
посмотрите, к примеру, на WPF (современный GPU-ускоренный фреймворк для построения GUI для .NET) вот уж что там тормозит, так это точно не рендеринг
>> А уязвимостей будет вагон - сделать 100% надёжный анализатор это нынче из области фантастики
сделать анализатор для unmanaged C кода это и правда из области фантастики
вот только вы забываете о том, что в Singularity используется как раз-таки другая "философия программирования" (как вы выразились) формально верифицируемый language framework
формально это значит, математическими методами
единственный неверифицируемый на сегодня код находится в ядре Singularity, но там совсем немного кода, и его безопасность тоже можно доказать формально (собственно, разработчики этой OS сегодня именно этим и занимаются)
сделать анализатор для unmanaged C кода это и правда из области фантастики
вот только вы забываете о том, что в Singularity используется как раз-таки другая "философия программирования" (как вы выразились) формально верифицируемый language framework
формально это значит, математическими методами
единственный неверифицируемый на сегодня код находится в ядре Singularity, но там совсем немного кода, и его безопасность тоже можно доказать формально (собственно, разработчики этой OS сегодня именно этим и занимаются)
т.е. чтобы найти уязвимость в такой системе, надо найти уязвимость в самих математических методах доказательства теорем
и если это случится, то это будет проблема не только Singularity...
и если это случится, то это будет проблема не только Singularity...
Пока что вся философия сводится к тому, что каждая проверенная библиотека и программа считается 100% безопасной. Для яэра и это может быть справедливо - можно вылизать ядро так, чтобы оно было безопасно, но что будете делать, например, с HD-video компрессором/декомпрессором? В ядро встривать? Для каждого кодека? Не реально. Писать на .NET? Нихватит никакой просизводительности производительности. Придётся допустить использовать библиотеки, написанные сторонними авторами. В реальной жизни есть миллион задач, в том числе повседневных, где просто необходимо использовать очень сложные библиотеки написанные на нативном коде или имеющие доступ непосредственно к ядру - это антивирусы, архиваторы, кодеки и прочее, включая видеодрайверы. И уязвимость в любом из них будет глобальной уязвимостью системы.
Пока что это попытка натянуть новый подход к написанию ОС к старому подходу в написании программ и драйверов. А нужно что-то гораздо более масштабное.
Пока что это попытка натянуть новый подход к написанию ОС к старому подходу в написании программ и драйверов. А нужно что-то гораздо более масштабное.
>> например, с HD-video компрессором/декомпрессором? В ядро встривать? Для каждого кодека? Не реально.
Singularity это микроядро, вы туда ничего не "встроите"
все драйверы и кодеки это обычные процессы, и, кстати, преимуществ в производительности у ядра Singularity перед процессами нет
>> это антивирусы
в Singularity не нужны антивирусы, потому что априори система считается безопасной, это доказано математически
>> Писать на .NET? Нихватит никакой просизводительности производительности.
объясните, почему?
сдаётся мне, вы оперируете ложными предубеждениями
в Singularity нельзя использовать нативный код, вообще, в принципе
неужели вы это ещё не поняли? ни драйвер, ни кодек, ни даже большая часть ядра не обладают такими привилегиями там
да-да, большая часть ядра Singularity определена через т.н.з. "unsafe C#", который, несмотря на приставку "unsafe" прекрасно верифицируется
>> Пока что это попытка натянуть новый подход к написанию ОС к старому подходу в написании программ и драйверов.
если бы вы читали статью, то вы бы такого не написали
в Singularity нельзя писать ни программы, ни драйверы "по-старому"
Singularity это микроядро, вы туда ничего не "встроите"
все драйверы и кодеки это обычные процессы, и, кстати, преимуществ в производительности у ядра Singularity перед процессами нет
>> это антивирусы
в Singularity не нужны антивирусы, потому что априори система считается безопасной, это доказано математически
>> Писать на .NET? Нихватит никакой просизводительности производительности.
объясните, почему?
сдаётся мне, вы оперируете ложными предубеждениями
в Singularity нельзя использовать нативный код, вообще, в принципе
неужели вы это ещё не поняли? ни драйвер, ни кодек, ни даже большая часть ядра не обладают такими привилегиями там
да-да, большая часть ядра Singularity определена через т.н.з. "unsafe C#", который, несмотря на приставку "unsafe" прекрасно верифицируется
>> Пока что это попытка натянуть новый подход к написанию ОС к старому подходу в написании программ и драйверов.
если бы вы читали статью, то вы бы такого не написали
в Singularity нельзя писать ни программы, ни драйверы "по-старому"
Ответьте на следующзие вопросы. Выберите наиболее подохдящий вам вариант:
1) При прогирывании и редактриовании аудио-видео на этой чудо ОС я буду:
a) Пользоваться только встроенными кодеками от Microsoft. Никогда не смотреть и не копировать пиратское видео. После появление новых кодеков ходить по друзьям и смотрть видео на их компьюетрах под алтернативными ОС.
б) Тоже что и (а), но видео с новыми кодеками буду смотреть по одному кадру в пять секунд при помощи кодеков на .NET
в) Поставлю вагон кодеков исполняющихся в нативном коде, и буду обновлять их вместе с обновлением стандартов кодеков.
2) Для архивирования я буду:
a) использовать только формат CAB от микрософт, а для остальных форматов мириться с 50-100 кратной потерей производительности.
б) Поставлю архиватор работающий в нативном коде.
3) При редактированаии фото и видео, кроме перечисленного в п.1 я буду:
а) мириться с минимум трёхкратной потерей производительности и закупать память гигабайтами.
б) буду использовать редакторы имеющие библиотеки работающие в нативном коде.
4) После того, как в результате уязвимостей в системе, анализаторе когда или программах использующий нативный код в мою систему поселится троян, который будет работать на уровне ядра и не будет удалться ничем кроме переустановки системы, я буду:
а) Упорно сносить всё к чертям три-шесть раз в год после обнаружения каждой критичной уязвимости.
б) В будущем уязвимостей не будет, код будет писаться безглючным, в ОС будут находит не больше одной ошибки в за два-три года, безногие будут ходить, гулхие петь, слепые прозреют, а с небес будет сыпаться манна небесная.
в) В ОС уже будет встроен нативный антивирус и я буду использовать его. Никто и никогда не напишщет антивируса лучше. Микрсофт - лучший писатель антивирусов, а компьюетры защищать нужно MS Malicious Software Removal Tool и встроенным в Windows firewall'ом.
в) Поставлю себе антивирус имеющий доступ к нативному коду.
Другие варианты ответов искренне приветствуются.
1) При прогирывании и редактриовании аудио-видео на этой чудо ОС я буду:
a) Пользоваться только встроенными кодеками от Microsoft. Никогда не смотреть и не копировать пиратское видео. После появление новых кодеков ходить по друзьям и смотрть видео на их компьюетрах под алтернативными ОС.
б) Тоже что и (а), но видео с новыми кодеками буду смотреть по одному кадру в пять секунд при помощи кодеков на .NET
в) Поставлю вагон кодеков исполняющихся в нативном коде, и буду обновлять их вместе с обновлением стандартов кодеков.
2) Для архивирования я буду:
a) использовать только формат CAB от микрософт, а для остальных форматов мириться с 50-100 кратной потерей производительности.
б) Поставлю архиватор работающий в нативном коде.
3) При редактированаии фото и видео, кроме перечисленного в п.1 я буду:
а) мириться с минимум трёхкратной потерей производительности и закупать память гигабайтами.
б) буду использовать редакторы имеющие библиотеки работающие в нативном коде.
4) После того, как в результате уязвимостей в системе, анализаторе когда или программах использующий нативный код в мою систему поселится троян, который будет работать на уровне ядра и не будет удалться ничем кроме переустановки системы, я буду:
а) Упорно сносить всё к чертям три-шесть раз в год после обнаружения каждой критичной уязвимости.
б) В будущем уязвимостей не будет, код будет писаться безглючным, в ОС будут находит не больше одной ошибки в за два-три года, безногие будут ходить, гулхие петь, слепые прозреют, а с небес будет сыпаться манна небесная.
в) В ОС уже будет встроен нативный антивирус и я буду использовать его. Никто и никогда не напишщет антивируса лучше. Микрсофт - лучший писатель антивирусов, а компьюетры защищать нужно MS Malicious Software Removal Tool и встроенным в Windows firewall'ом.
в) Поставлю себе антивирус имеющий доступ к нативному коду.
Другие варианты ответов искренне приветствуются.
>> а для остальных форматов мириться с 50-100 кратной потерей производительности.
да это бред, какая там 50-100 кратная потеря производительности? своими глазами видел худший случай это 2-х кратное падение и то из-за того что то был JIT-компилятор (у него не так много времени на оптимизации, как у оффлайнового)
в лучшем случае будет прирост производительности из-за hotspot-оптимизации и знания компилятором (который работает либо в deploy time, либо в run time) особенностей железа пользователя
>> а) мириться с минимум трёхкратной потерей производительности
это туда же
>> a) Пользоваться только встроенными кодеками от Microsoft.
ну так никто не запрещает написать свой кодек или портировать уже существующий
>> ) После того, как в результате уязвимостей
их не будет, и вирусов тоже не будет :)
да это бред, какая там 50-100 кратная потеря производительности? своими глазами видел худший случай это 2-х кратное падение и то из-за того что то был JIT-компилятор (у него не так много времени на оптимизации, как у оффлайнового)
в лучшем случае будет прирост производительности из-за hotspot-оптимизации и знания компилятором (который работает либо в deploy time, либо в run time) особенностей железа пользователя
>> а) мириться с минимум трёхкратной потерей производительности
это туда же
>> a) Пользоваться только встроенными кодеками от Microsoft.
ну так никто не запрещает написать свой кодек или портировать уже существующий
>> ) После того, как в результате уязвимостей
их не будет, и вирусов тоже не будет :)
Гхм... Для архиваторов потеря производительности будет 50..100 раз. В два раза падение может быть на сетевый/офисных задач. Полагать, что hotspot может соптимизировать лучше чем авторы соврмсенных архиваторо - по карйней мере наивно.
Свой кодек тоже будете на .NET писать? :) SSE2,SEE3 тоже из-под него использовать? :) Это, мягко-говоря, невозможно. КОдеки нынче затачиваются под архитектуру конкретного процессора и, как-правило, содерат несколько вариантов под различные CPU.
Про уфзвимости, это я готов согласиться, но только после изобретения нуль-траспортировки. Пока что уменьшения количества ошибок и уязвимостей в программах не наблюдается. Более того, имеется скорее тенденция к увеличению количества ошибок.
Свой кодек тоже будете на .NET писать? :) SSE2,SEE3 тоже из-под него использовать? :) Это, мягко-говоря, невозможно. КОдеки нынче затачиваются под архитектуру конкретного процессора и, как-правило, содерат несколько вариантов под различные CPU.
Про уфзвимости, это я готов согласиться, но только после изобретения нуль-траспортировки. Пока что уменьшения количества ошибок и уязвимостей в программах не наблюдается. Более того, имеется скорее тенденция к увеличению количества ошибок.
во, первых, "на .NET" я его не буду писать, т.к. это библиотека классов для Windows
>> SSE2,SEE3 тоже из-под него использовать? :) Это, мягко-говоря, невозможно.
интересно, как же это я использовал супер-пупер-распараллеленный GPU через C++?
я сделал простую шаблонную библиотеку для имитации шейдерного DSL (вроде boost::spirit, который имитирует язык BNF) это при запуске компилировалось в шейдер
и это в древнем убогом C++
а у IL-компилятора Singularity просто развязаны руки, т.к. он обладает знанием семантики программы на уровне использования ей библиотеки классов
компиляция для SSE делается тривиальным введением классов типа Float4 и операторов над ними (умножить-сложить-etc) и модификации компилятора, чтобы он оператор "сложить два float4" компилировал в соответствующую SSE-инструкцию
/* хуяк, волшебный SSE! */
Math.Float4 a = b + c;
причём это уже сегодня есть, к примеру, в (кто бы мог подумать) Microsoft Visual C++
начиная с дремучей версии 7.0 там появились "intrinsics" (интринсики) это как раз такие специальные "встроенные" функции и типы данных (int128, к примеру), которые компилятор преобразует в SSE-код
и это интринсики там есть для MMX, SSE, SSE2 и SSE3
и это в древнем C++!
компилятор Singularity технологически несравненно совершенней, и там можно даже сделать хоть компилятор в GPU-код это на порядки проще, чем прикрутить аналогичное к C++
кстати, аналог транслятора в GPU этого есть и для C сегодня, называется NVidia CUDA
>> SSE2,SEE3 тоже из-под него использовать? :) Это, мягко-говоря, невозможно.
интересно, как же это я использовал супер-пупер-распараллеленный GPU через C++?
я сделал простую шаблонную библиотеку для имитации шейдерного DSL (вроде boost::spirit, который имитирует язык BNF) это при запуске компилировалось в шейдер
и это в древнем убогом C++
а у IL-компилятора Singularity просто развязаны руки, т.к. он обладает знанием семантики программы на уровне использования ей библиотеки классов
компиляция для SSE делается тривиальным введением классов типа Float4 и операторов над ними (умножить-сложить-etc) и модификации компилятора, чтобы он оператор "сложить два float4" компилировал в соответствующую SSE-инструкцию
/* хуяк, волшебный SSE! */
Math.Float4 a = b + c;
причём это уже сегодня есть, к примеру, в (кто бы мог подумать) Microsoft Visual C++
начиная с дремучей версии 7.0 там появились "intrinsics" (интринсики) это как раз такие специальные "встроенные" функции и типы данных (int128, к примеру), которые компилятор преобразует в SSE-код
и это интринсики там есть для MMX, SSE, SSE2 и SSE3
и это в древнем C++!
компилятор Singularity технологически несравненно совершенней, и там можно даже сделать хоть компилятор в GPU-код это на порядки проще, чем прикрутить аналогичное к C++
кстати, аналог транслятора в GPU этого есть и для C сегодня, называется NVidia CUDA
НЛО прилетело и опубликовало эту надпись здесь
Если у них хватит терпения/денег/мативации сделать реально нормальную ОС я буду их уважать!
Эх, жалко закрыли проект. Причины?
Вроде как исследовательский проект, поэтому живет в продолжателях своего дела — Drawbridge, Midori и пр.
Спасибо за информацию. Тоже думал, что у них что-то не получилось
Подробнее тут
Получилась слишком хорошей, чтобы быть правдой
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Всё, что вы хотели знать о Singularity, но боялись спросить