The Singularity Research Development Kit (RDK) is based on the Microsoft Research Singularity project. It includes source code, build tools, test suites, design notes, and other background materials.
Singularity is a research project focused on the construction of dependable systems through innovation in the areas of systems, languages, and tools. We are building a research operating system prototype (called Singularity), extending programming languages, and developing new techniques and tools for specifying and verifying program behavior.
Здравствуйте, Mirrorer, Вы писали:
M>здесь M>The Singularity Research Development Kit (RDK) is based on the Microsoft Research Singularity project. It includes source code, build tools, test suites, design notes, and other background materials.
Посмотрел. Прикольно.
Хотя насчёт полной безопасности системы они, конечно, погорячились. В ряде мест там используется вполне так прямая работа с памятью, по крайней мере в реализации GC.
Здравствуйте, Cyberax, Вы писали:
C>Хотя насчёт полной безопасности системы они, конечно, погорячились. В ряде мест там используется вполне так прямая работа с памятью, по крайней мере в реализации GC.
Так собственно, никто 100% managed код в ядре и не обещал . Суть в том, что его очень мало (т.е. легко его верифицировать), зато всё остальное безопастно по определению.
Здравствуйте, Curufinwe, Вы писали:
C>>Хотя насчёт полной безопасности системы они, конечно, погорячились. В ряде мест там используется вполне так прямая работа с памятью, по крайней мере в реализации GC. C>Так собственно, никто 100% managed код в ядре и не обещал . Суть в том, что его очень мало (т.е. легко его верифицировать), зато всё остальное безопастно по определению.
Нет, там именно из managed-кода идёт небезопасная работа с помощью "магических" классов доступа к памяти и т.п.
Здравствуйте, Cyberax, Вы писали:
C>Нет, там именно из managed-кода идёт небезопасная работа с помощью "магических" классов доступа к памяти и т.п.
Насколько я помню по старым материалам и видео, вся небезопастная работа сосредоточенна в небольшой части ядра системы (вроде даже драйвера устройств не могут ничего "плохого" сделать). Деталей про "магические" классы увы не знаю, но не думаю что они доступны вне ядра и т.о. пользоательские SIP никак не могут доюраться до памяти других процессов.
Здравствуйте, Cyberax, Вы писали:
C>>>Хотя насчёт полной безопасности системы они, конечно, погорячились. В ряде мест там используется вполне так прямая работа с памятью, по крайней мере в реализации GC. C>>Так собственно, никто 100% managed код в ядре и не обещал . Суть в том, что его очень мало (т.е. легко его верифицировать), зато всё остальное безопастно по определению. C>Нет, там именно из managed-кода идёт небезопасная работа с помощью "магических" классов доступа к памяти и т.п.
Выдержка про использование managed кода в системных частях (в частности — GC).
The lowest layer of the Singularity kernel is written in assembler and C++, which can only be checked in limited ways with primitive tools. This layer therefore contains as little code and as little functionality as possible; it consists primarily of code which cannot be expressed in MSIL, such as context switches, I/O instructions, and low-level parts of the garbage collector (GC). If the code in this layer fails, the system as a whole can fail in any way.
The next layer of the Singularity kernel is written in unsafe C#, which also can only be checked in limited ways with primitive tools. This layer again contains as little code and functionality as possible; it includes most of the GC, page table, and I/O access code. If the code in this layer fails, the system can fail in almost any way.
L>The next layer of the Singularity kernel is written in unsafe C#, which also can only be checked in limited ways with primitive tools. This layer again contains as little code and functionality as possible; it includes most of the GC, page table, and I/O access code. If the code in this layer fails, the system can fail in almost any way.
Угу, именно. И этот слой весьма большой по объёму, и совсем не тривиальный.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, leper, Вы писали:
L>>
L>>The next layer of the Singularity kernel is written in unsafe C#, which also can only be checked in limited ways with primitive tools. This layer again contains as little code and functionality as possible; it includes most of the GC, page table, and I/O access code. If the code in this layer fails, the system can fail in almost any way.
C>Угу, именно. И этот слой весьма большой по объёму, и совсем не тривиальный.
Но этот слой написан один раз и находится в ядре, пользователю до него нет доступа.
... << RSDN@Home 1.2.0 alpha rev. 786>>
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
L>>>The next layer of the Singularity kernel is written in unsafe C#, which also can only be checked in limited ways with primitive tools. This layer again contains as little code and functionality as possible; it includes most of the GC, page table, and I/O access code. If the code in this layer fails, the system can fail in almost any way.
C>>Угу, именно. И этот слой весьма большой по объёму, и совсем не тривиальный. K>Но этот слой написан один раз и находится в ядре, пользователю до него нет доступа.
Ядро Линукса тоже написано один раз, находится в ядре, и пользователю до него нет доступа.
Здравствуйте, Cyberax, Вы писали:
K>>Но этот слой написан один раз и находится в ядре, пользователю до него нет доступа. C>Ядро Линукса тоже написано один раз, находится в ядре, и пользователю до него нет доступа.
Ты сравниваешь небольшой слой ядра написанный на небезопасной шарпе с огромным ядром Линукса?
... << RSDN@Home 1.2.0 alpha rev. 786>>
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Kisloid, Вы писали:
C>Ядро Линукса тоже написано один раз, находится в ядре, и пользователю до него нет доступа.
Здравствуйте, Curufinwe, Вы писали:
C>>Ядро Линукса тоже написано один раз, находится в ядре, и пользователю до него нет доступа. C>А в линуксе SIP есть?
Нет, там HIP.
Здравствуйте, Kisloid, Вы писали:
C>>Ядро Линукса тоже написано один раз, находится в ядре, и пользователю до него нет доступа. K>Ты сравниваешь небольшой слой ядра написанный на небезопасной шарпе с огромным ядром Линукса?
98% кода в Линуксе — это драйверы. Которые тоже полностью безопасными сделать вряд ли получится.
Небольшой слой небезопасного кода в Singularity — он как-то совсем даже не "небольшой". В частности, полная реализация мощного современного GC будет соперничать по сложности и объёму с недрайверной частью Линукса.
Если уж делать надёжную систему — то нужно использовать что-то типа QNX.
Здравствуйте, Curufinwe, Вы писали:
C>>Нет, там HIP. C>>Но и SIP никто не мешает сделать. C>Но почему-то не сделали и сомневаюсь, что сделают
Сделать-то достаточно просто. Запускаем нужное окружение в ядерном пространстве — и вперёд с песней. Только это нафиг никому не нужно.
C>А ведь это и есть основная фича Singularity — очень дешёвые процессы.
Я как-то уже писал, что дешовые аппаратно-защищённые процессы можно сделать с помощью сравнительно простого аппаратного дополнения. Которое уже есть на некоторых не-x86-системах: http://www.rsdn.ru/Forum/?mid=1929179
Здравствуйте, Cyberax, Вы писали:
C>Сделать-то достаточно просто. Запускаем нужное окружение в ядерном пространстве — и вперёд с песней. Только это нафиг никому не нужно.
И что, можем запустить там кучу процессов без аппаратной защиты и гарантировать, что один не сможет испортить память другому?
C>>А ведь это и есть основная фича Singularity — очень дешёвые процессы. C>Я как-то уже писал, что дешовые аппаратно-защищённые процессы можно сделать с помощью сравнительно простого аппаратного дополнения. Которое уже есть на некоторых не-x86-системах: http://www.rsdn.ru/Forum/?mid=1929179
Здравствуйте, Curufinwe, Вы писали:
C>>Сделать-то достаточно просто. Запускаем нужное окружение в ядерном пространстве — и вперёд с песней. Только это нафиг никому не нужно. C>И что, можем запустить там кучу процессов без аппаратной защиты и гарантировать, что один не сможет испортить память другому?
Ну если окружение это гарантирует — то почему бы и нет? Был как-то проект по запуску Java в kernel space, например.
То есть, никто не мешает портировать SIP из Singularity в виде модуля для Линукса
C>>Я как-то уже писал, что дешовые аппаратно-защищённые процессы можно сделать с помощью сравнительно простого аппаратного дополнения. Которое уже есть на некоторых не-x86-системах: http://www.rsdn.ru/Forum/?mid=1929179
C>Какая там доля рынка у этих не-x86-систем?
Так и Singularity особо на текущем рынке x86 не нужна. А доля ARMов, пожалуй, по количеству сейчас превышает долю PC (ARMы — это встраиваемые процессоры).
Здравствуйте, SilverCloud, Вы писали:
SC>... не можете выложить куда-нибудь, откуда есть докачка?
Спасибо, не надо. Версию 6601 всё-таки удалось скачать.
Здравствуйте, Cyberax, Вы писали:
C>>Но почему-то не сделали и сомневаюсь, что сделают C>Сделать-то достаточно просто. Запускаем нужное окружение в ядерном пространстве — и вперёд с песней. Только это нафиг никому не нужно.
...потому что дико медленно.
Короче, очередной бессмысленный флэйм затеваешь.
Сингулярити микроядерная ОС лишенная проблем производительности оных. Надежность ее на порядки выше чем у Линукса или Виндов. Иначе бы за нее просто никто не взялся.
Другое дело, что это исследование которое вряд ли дойдет в исходном виде до практики. Как минимум МС прийдется коренным образом пересмотреть свои идеи Джит-компиляции.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
. Суть в том, что его очень мало (т.е. легко его верифицировать), зато всё остальное безопастно по определению.
