Bluebottle

Какой же это кривой велосипед... Что bluebottle, что singularity - в системе, где нет разделения на адресные пространства на уровне железа, несколько процессов не могут безопасно сущестовать. Не надо говорить про безопасность языка - в программном обеспечении такой сложности всегда есть ошибки, поэтому простейшая аппаратная защита должна присутствовать.

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

А Linux Debian, Ubuntu 7.10, Suse 11 стабильная и промышленная ОС? Или playground для Линуса? Кто пощитал количество критических и секурити багов в ядре 2.6.100?

> в системе, где нет разделения на адресные пространства на уровне железа, несколько процессов не могут безопасно существовать

вот-вот, давно уже необходимо сделать минимально достаточное для разделения на уровне железа.

В Singularity, однако, процессы безопасно и существуют, SIP. Ценой выкидывания "неправильных" опасных указателей.

> Не надо говорить про безопасность языка - в программном обеспечении такой сложности всегда есть ошибки,

надо. Именно в безопасных языках эти ошибки проще выловить и выправить, проще формально верифицировать. Другое дело, что не в ущерб эффективности.

> поэтому простейшая аппаратная защита должна присутствовать.

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

> в системе, где нет разделения на адресные пространства на уровне железа, несколько процессов не могут безопасно сущестовать

могут. Система -- состоит из языка и среды, если у тебя безопасный язык , корректный семантически доступ, и ты физически не можешь его сломать оставаясь в рамках этого языка, то такая система безопасна. Не используй C и кривых указателей, всего делов.

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

Общество в котором отсутствует цветовая дифференциация штанов....

Уважаемый когда нибудь слышал про системы БЕЗ MMU ??? В некоторых случаях, применение которых вполне оправдано.

>несколько процессов не могут безопасно сущестовать.

Советую почитать документацию. http://www.vitanuova.com/inferno/papers/dis.html - к примеру.

> в системе, где нет разделения на адресные пространства на уровне железа

еще более интересные велосипеды -- homebrew CPU, http://www.homebrewcpu.com/

Есть интересные машинки, например в FPGA

Недалеко от них ушли машинки с форт-процессором, то же FPGA : форт используется в качестве ассемблера процессора такой машины, аппаратно реализован в FPGA.

Правда, смысл этих велосипедов, кроме франкенштейновского "потому что могу" не очень ясен. Другое дело, если такой homebrew CPU + шина + ядро ОС (переключение процессов, управление памятью, ресурсами-файлами-объектами) не тупо склеены из разных запчастей (как тот же франкЭнштейн), а точно подогнаны вместе для демонстрации какой-то идеи, концепта, есть какое-то "существенное" преимущество.

Хотя такие системы никогда не будут достаточно массовыми для достаточной дешевизны в производстве.

> Уважаемый когда нибудь слышал про системы БЕЗ MMU ??? В некоторых случаях, применение которых вполне оправдано.

или, например, экзоядро, где мини-ядро просто мультиплексирует для приложений некие абстрактные ресурсы. Что это за ресурсы, память, процессы, файлы -- обрабатывается уровнем выше на некоторой libOS, которая предоставляет для приложения интерфейсный API, который выглядит, как API какой-то ОС.

Но в особых случаях, можно обойти этот API и работать с ресурсами напрямую. Работать безопасно, так как экзоядро предоставило ресурсы корректным безопасным способом.

То есть, ещё один уровень неявности, абстрактности стандартного API libOS в этом случае не нужен, и проще работать с ресурсами напрямую.

> в системе, где нет разделения на адресные пространства на уровне железа, несколько процессов не могут безопасно сущестовать

Несколько старый боян про устройство машины Lilith

http://www.rol.ru/news/it/press/cwm/19_98/pdp.htm

отечественный велосипед: Modula-2 центральный процессор, докатился до транспьютеров.

http://www.rol.ru/news/it/press/cwm/20_98/kron.htm

еще более замшелый баян, RTOS, роботы

http://www.ifr.mavt.ethz.ch/research/xoberon/performance.html

цытатко про активные объекты:

Scheduling Overhead

It is a little difficult to quantify the overhead of the scheduler, since it scales with the number of installed tasks. Anyway, after bootstrapping, the system overhead is less than one percent of the maximum available processor power on a MVME1600 board, with a PowerPC 604 clocked at 100 MHz. After bootstrapping, the system is scheduling service-maintenance routines, along with ethernet, VME and serial drivers. The overhead scales linearly for more processes, with (rule of thumb) an increment of one percent in the worst case (this being a task which exhibits heavy floating-point use with a 100 microseconds deadline).

As an example, a complex parallel machine (Hexaglide), with seven hard real-time, user installed processes with a (min) 300 microseconds deadline, and some non-real-time processes, brings the scheduling overhead close to five percent.

In the same way, the overhead decreases linearly with better PowerPC implementations, as in the new MVME2600 board, powered by a 200 MHz PowerPC604e. In this case, the scheduling overhead after bootstrapping drops to 0.4 percent. How is this possible?

How can XOberon achieve such a performance, which is, by the way, at least three times faster than commercial real-time operating systems running on the same architecture? The answer is simple: a highly optimized scheduler.

The scheduler has been optimized in three ways:

* very tight implementation * hand-tuned assembler code-snippets * very efficient algorithms, and most important: * optimizations in the context-switching, done on a per-process-base * stack-prefetching * fine-tuned memory management * real world, on-chip performance measurements for speed-tuning

As an example, the context switch is usually implemented with a dumb "save everything for the next time" algorithm. XOberon uses the same object-oriented abstractions, presented to the programmer, in order to choose an optimal way for saving (and restoring) this particular task's context. Therefore, some processes are context-switched faster than others, according to the process state.

> Нет в Яве технологий Оберона.

со слов Вирта:

"Вирт очень спокойно так рассказал, что создатели Java за семь лет до ее создания очень подробно изучили исходные коды Оберона и, в частности, исходные коды оберонистых сборщиков мусора они тоже очень хорошо изучили. Далее испортили (corrupted) Оберон сишным синтаксисом и обозвали получившееся словом Java. Кстати, заметил Вирт, то, что они испортили его сишным синтаксисом, был хороший маркетинговый ход с их стороны. Что касается .Net, то она появилась в результате конкуренции, и в принципе они (Java и .Net) более-менее одинаковые."

http://www.stinfa.ru/?id=57223

А если подумать логически,

JVM bytecode, P-code, slim-код в Обероне, динамическая загрузка методов, интроспекция

сборщик мусора (в Обероне потоковый, для анализа не надо было "замораживать" процесс)

хотя согласен, это на уровне общих идей, а не реализации

>http://www.stinfa.ru/?id=57223

http://209.85.129.104/search?q=cache:9PWsWQMRLJsJ:www.stinfa.ru/%3Fid%3D57223+%D1%81%D0%B1%D0%BE%D1%80%D1%89%D0%B8%D0%BA+%D0%BC...