absolute wrote:
> C>Да они полные ламеры! Вот тут человек еще и сам сделал КОМПЬЮТЕР:
> В проекте Oberon тоже делали машины Ceres.
Ceres workstation (built around the National Semiconductor 32032 CPU). А
тут человек полностью сам свой процессор изготовил.

> C>Ага, конечно. А давайте по фичам сравним ядро BlueBottle и Linux?
> Вытесняющая параллельность — есть.
Защита памяти: нет. Что собственно и является диагнозом и смертным
приговором для реальных применений этой системы.

> Файловые операции — есть.
Интеллектуальное кэширование, multipath IO, RAID'ы всех уровней,
anticipatory scheduler, read-ahead?

> Стек TCP\IP — есть.
Его нет только на Z80. Хотя нет, и там уже есть.

> Обработка прерываний — есть.
Это у нас уже фича ОС?

> Если же учитывать количество разработчиков, то оберонистый разработчик
> куда продуктивнее.
Вот вам: http://haiku-os.org/learn.php — пишут около десятка человек в
течение нескольких лет на С++. Недавно устанавливал из чистого интереса
— так BlueBottle там даже рядом не лежало.

А еще есть ReactOS и куча других "любительских" ОСей.

> Ранее здесь рассматривались примеры вставок картинок в исходные тексты.
> А также коммандеров — гиперссылок, при нажатии на которых запускается
> произвольная команда.
Боже мой, и это называется верхом технологической мысли?

> C>GNU/Linux.
> Ещё раз подчеркну, что особый интерес представляют не фичи сами по себе,
> а затраченные на разработку усилия.
> Размеры сообществ разработчиков различаются на порядки, а достигнутые
> существенные результаты — не так сильно.
Вы бредите. Linux и BlueBottle — это просто несравнимые вещи.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>Защита памяти: нет.

Защита памяти: программная.
Это даёт ИНЫЕ возможности.
Вряд ли один способ безусловно превосходит другой.

C>Интеллектуальное кэширование, multipath IO, RAID'ы всех уровней,
C>anticipatory scheduler, read-ahead?

Когда такие вещи реализуются в ядре, не всегда ясно, как это будет взаимодействовать с процессами и влиять на реалтаймовость.

В Bluebottle такие вещи могут реализовываться в активных объектах и параллелизм более ясный.

В Оберонах в принципе с файлами работают иначе чем в юниксах.
И буферизация там весьма интересна и остроумна.

C>Вот вам: http://haiku-os.org/learn.php
C>так BlueBottle там даже рядом не лежало.
C>А еще есть ReactOS и куча других "любительских" ОСей.

Да, спасибо, имею представление.

C>Боже мой, и это называется верхом технологической мысли?

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

C>Вы бредите. Linux и BlueBottle — это просто несравнимые вещи.

Так и есть.
Соответственно, не определены операции лучше\хуже.
Разные системы.

absolute wrote:
> C>Защита памяти: нет.
> Защита памяти: программная.
Читаю: никакая. В Обероне есть возможность использовать ассемблерный
код, а значит любая программа может порушить всю систему. В общем,
"Welcome to Win3.11!".

> Вряд ли один способ безусловно превосходит другой.
Аппаратный — превосходит. Последняя дыра в механизме аппаратной защиты
была обнаружена в Intel386. Ну можно еще сюда засчитать возможность
утечки данных из-за особенностей когерентности кэша при hyper-threading'е.

В програмной реализации дыр будет больше.

> C>Интеллектуальное кэширование, multipath IO, RAID'ы всех уровней,
> C>anticipatory scheduler, read-ahead?
> Когда такие вещи реализуются в ядре, не всегда ясно, как это будет
> взаимодействовать с процессами и влиять на реалтаймовость.
Ой, а в QNXе они есть. Видимо никто им не сказал, что это невозможно...

> В Bluebottle такие вещи могут реализовываться в активных объектах и
> параллелизм более ясный.
"Могут", а в Линуксе уже есть. Да и не может большая часть этого быть
реализована в пользовательском коде, так как нужен доступ к оборудованию.

> В Оберонах в принципе с файлами работают иначе чем в юниксах.
> И буферизация там весьма интересна и остроумна.
Какая? LRU-буферизация?

> Наибольший интерес представляет лишь тот факт, что компетентные
> оберонщики многократно превосходят по производительности обычных
> программистов.
От того, что вы повторите это 100 раз — оно правдой не станет. Нет в
Обероне никаких предпосылок к увеличению производительности труда. Ну
разве что если сравнивать с программированием на чистом С или ассемблере.

> Соответственно, не определены операции лучше\хуже.
> Разные системы.
Тогда и не стоит говорить, что производительность труда программиста BB
намного превышает производительность труда разработчиков Linux'а.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C> Читаю: никакая. В Обероне есть возможность использовать ассемблерный код

В Обероне есть КОНТРОЛИРУЕМАЯ возможность использовать ассемблерный код.
Точно также как в линуксе есть возможность использовать загружаемые модули ядра.

C> Аппаратный — превосходит. Последняя дыра в механизме аппаратной защиты
C> была обнаружена в Intel386.

Аппаратная защита не защищает сама по себе.
Она должна работать под управлением ядра — софтовой сущности.
Уязвимости в ядрах не такая уж экстраординарная вещь, не так ли?

C> Ой, а в QNXе они есть. Видимо никто им не сказал, что это невозможно...

В ядре ли они есть?

C> "Могут", а в Линуксе уже есть. Да и не может большая часть этого быть
C> реализована в пользовательском коде, так как нужен доступ к оборудованию.

Вот это и есть главная разница в подходах: "нужен доступ к оборудованию".
В Обероне тщательно разделяются системный и прикладной код.
И количество системного кода всеми силами стараются минимизировать.

Кэширование относится по большей части к файловому уровню.
Драйвер файловой системы может быть ПОЛНОСТЬЮ написан на безопасном языке.
Ему не "нужен доступ к оборудованию".
Ему нужен лишь доступ к драйверу блочного устройства.
Поэтому это МОЖЕТ быть "реализовано в пользовательском коде".
И именно это сделано в Обероне.

C> Какая? LRU-буферизация?

С файлами работают иначе на прикладном уровне.
СГ пытался начать рассказывать.
Если интересно, можно продолжить.
Без клочков кода на Обероне не обойдётся.

C> От того, что вы повторите это 100 раз — оно правдой не станет. Нет в
C> Обероне никаких предпосылок к увеличению производительности труда. Ну
C> разве что если сравнивать с программированием на чистом С или ассемблере.

Я просто делю количество фич на количество людей, учитывая время.
Оберон — это и язык системного программирования, и именно в этой области
обладает наиболее ошеломляющими возможностями.
С какими языками системного программирования его следует сравнивать?

Здравствуйте, absolute, Вы писали:

A>Кэширование относится по большей части к файловому уровню.
A>Драйвер файловой системы может быть ПОЛНОСТЬЮ написан на безопасном языке.
A>Ему не "нужен доступ к оборудованию".
A>Ему нужен лишь доступ к драйверу блочного устройства.
A>Поэтому это МОЖЕТ быть "реализовано в пользовательском коде".
A>И именно это сделано в Обероне.

Это так же как в Win NT?

absolute wrote:
> C> Читаю: никакая. В Обероне есть возможность использовать ассемблерный код
> В Обероне есть КОНТРОЛИРУЕМАЯ возможность использовать ассемблерный код.
Каким образом? Сборки компилируются в native-код и никоим образом не
верифицируются. То есть я могу собрать модуль, пометив его как
"безопасный", а потом в бинарном редакторе поменять код. Ну или я могу
собрать свою версию компилятора с "улучшениями".

> Точно также как в линуксе есть возможность использовать загружаемые
> модули ядра.
В отличие от BlueBottle'а в Линуксе ядерный модуль может вставить только
процесс с достаточными привиллегиями.

> C> Аппаратный — превосходит. Последняя дыра в механизме аппаратной защиты
> C> была обнаружена в Intel386.
> Аппаратная защита не защищает сама по себе.
> Она должна работать под управлением ядра — софтовой сущности.
Минимальный код аппаратной защиты — это несколько килобайт. Например,
микроядро QNXа — это 16 килобайт рукописного ассемблерного кода, который
как раз и занимается управлением памятью и процессами. Естественно, он
очень хорошо проверен.

> Уязвимости в ядрах не такая уж экстраординарная вещь, не так ли?
Обычно не в механизме защиты памяти.


> C> Ой, а в QNXе они есть. Видимо никто им не сказал, что это невозможно...
> В ядре ли они есть?
В виде отдельных серверов — это микроядерная система.

> C> "Могут", а в Линуксе уже есть. Да и не может большая часть этого быть
> C> реализована в пользовательском коде, так как нужен доступ к оборудованию.
> Вот это и есть главная разница в подходах: "нужен доступ к оборудованию".
> В Обероне тщательно разделяются системный и прикладной код.
А в Линуксе значит не разделяется...

> Кэширование относится по большей части к файловому уровню.
Это уровень над файловой системой. В современных ОСах он работает с
аппаратными кэшами винчесторов или RAID-контроллеров, оптимизируя чтение
файлов с учетом состояния винчестеров и нагрузки на них.

> Драйвер файловой системы может быть ПОЛНОСТЬЮ написан на безопасном языке.
Может. Но эффективным он не будет.

> Поэтому это МОЖЕТ быть "реализовано в пользовательском коде".
> И именно это сделано в Обероне.
Все красиво на бумаге, да забыли про овраги... Именно поэтому в Обероне
и не реализованы высокопроизводительные алгоритмы работы с дисками.

> Если интересно, можно продолжить.
> Без клочков кода на Обероне не обойдётся.
Я прекрасно знаю Обероновский подход — он еще на mainframe'ах был в свое
время опробован.

> Я просто делю количество фич на количество людей, учитывая время.
Я тоже. Получается не особо блистательная цифра.

Например, берем Haiku — там за 4 года силами 5 человек написано:
— Микроядро с достаточно интересной архитектурой (и защитой памяти, кстати).
— GUI-подсистема.
— Аудио-подсистема.
— Сетевой стек.
— Окружение системы (утилиты и т.п.).

Или ReactOS — там сейчас уже некоторые виндовые программы можно
запускать, делалось примерно 10 человеколет.

> С какими языками системного программирования его следует сравнивать?
С++, например.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C> Каким образом? Сборки компилируются в native-код и никоим образом не
C> верифицируются. То есть я могу собрать модуль, пометив его как
C> "безопасный", а потом в бинарном редакторе поменять код. Ну или я могу
C> собрать свою версию компилятора с "улучшениями".

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

Bluebottle не может надёжно исполнять произвольный двоичный код — факт.

C> В отличие от BlueBottle'а в Линуксе ядерный модуль может вставить только
C> процесс с достаточными привиллегиями.

В Обероне это контролируется на уровне исходного кода.

C> > Уязвимости в ядрах не такая уж экстраординарная вещь, не так ли?
C> Обычно не в механизме защиты памяти.

Вот именно.
Уязвимости в других частях ядра могут вызвать уязвимость защиты памяти.

Хорошо если ядро — микро, и не меняется со временем, его можно проверить один раз.
Если же ядро постоянно меняется, каждый раз возникают сомнения в его надёжности.

В Обероне в качестве защиты выступает компилятор — весьма устойчивая
и неизменяющаяся часть.

C> В виде отдельных серверов — это микроядерная система.

Значит в виде процессов.
Если бы было в ядре, встал бы вопрос о реалтаймовости процессов.

C> А в Линуксе значит не разделяется...

И ядро и прикладной код почти повсеместно разрабатывается
на ненадёжных низкоуровневых языках.
Затем режется весьма крупными кусками — на ядро и процессы.
Уязвимость в малом участке такого куска — уязвимость всего куска.

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

Наверное, на Обероне это принципиально невозможно?

C> Может. Но эффективным он не будет.

Почему?

C> Я прекрасно знаю Обероновский подход — он еще на mainframe'ах был в свое
C> время опробован.

Тогда какие проблемы? (с)

Сколь угодно много клиентов могут согласовано одновременно работать с одним файлом.
Что аналогичное предлагают другие современные ОСи?

C> Например, берем Haiku — там за 4 года силами 5 человек написано:
C> — Микроядро с достаточно интересной архитектурой (и защитой памяти, кстати).
C> — GUI-подсистема.
C> — Аудио-подсистема.
C> — Сетевой стек.
C> — Окружение системы (утилиты и т.п.).

Чего из этого нет в Bluebottle?

C> > С какими языками системного программирования его следует сравнивать?
C> С++, например.

Это уже было.

С какими системными проектами на С++ следует сравнить?

absolute wrote:
> C> Каким образом? Сборки компилируются в native-код и никоим образом не
> C> верифицируются. То есть я могу собрать модуль, пометив его как
> C> "безопасный", а потом в бинарном редакторе поменять код. Ну или я могу
> C> собрать свою версию компилятора с "улучшениями".
> Имеется механизм получения безопасного машинного кода —
> компилятор безопасного языка программирования.
И что? В компиляторе бывают ошибки, особенно если он оптимизирующий
(хотя Оберону это не грозит). В _реальной_ системе еще и существует
недоверяемый код.

В BlueBottle'е нет механизмов верификации машинного кода и нет механизма
аппаратной защиты. Точно так же как в Win3.11

> В Обероне это контролируется на уровне исходного кода.
Как? Ничерта там не контролируется — вы путаете защиту времени
исполнения и статическую проверку зависимостей.

Это все равно, что говорить, что DOS можно сделать надежным, если из
компиляторов языков библиотеки работы с аппаратурой.

> C> В виде отдельных серверов — это микроядерная система.
> Значит в виде процессов.
> Если бы было в ядре, встал бы вопрос о реалтаймовости процессов.
В QNXе это примерно одно и то же. Кстати, ФС в QNXе дает realtime-гарантию.

> C> А в Линуксе значит не разделяется...
> И ядро и прикладной код почти повсеместно разрабатывается
> на ненадёжных низкоуровневых языках.
И что? Кто мешает писать в Линуксе на Питоне или (о Боже!) на Обероне?

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

> C> Может. Но эффективным он не будет.
> Почему?
Слишком много зависит от тонких внутренних механизмов ядра.

> C> Я прекрасно знаю Обероновский подход — он еще на mainframe'ах был в свое
> C> время опробован.
> Тогда какие проблемы? (с)
Оказалось неудобно.

> Сколь угодно много клиентов могут согласовано одновременно работать с
> одним файлом. Что аналогичное предлагают другие современные ОСи?
flock(2).

> C> Например, берем Haiku — там за 4 года силами 5 человек написано:
> C> — Микроядро с достаточно интересной архитектурой (и защитой памяти,
> кстати).
> C> — GUI-подсистема.
> C> — Аудио-подсистема.
> C> — Сетевой стек.
> C> — Окружение системы (утилиты и т.п.).
> Чего из этого нет в Bluebottle?
Если кратко — всего. Если полно, то все приведенные подсистемы Haiku на
световые годы лучше BlueBottle.

> Это уже было.
Да, Оберон успешно показал свою несостоятельность.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C> И что? В компиляторе бывают ошибки, особенно если он оптимизирующий

Что, если таким компилятором скомпилировать ядро ОС с аппаратной защитой?

C> В _реальной_ системе еще и существует
C> недоверяемый код.

Это belief.

C> В BlueBottle'е нет механизмов верификации машинного кода

"ОС должна запускать на исполнение произвольный машинный код"
Это ещё один belief.

Bluebottle — это ОС с открытыми исходниками.
Это даёт возможность полноценно использовать преимущества безопасного языка.
Сомневающиеся могут самостоятельно перекомпилировать исходники.

C> Как? Ничерта там не контролируется — вы путаете защиту времени
C> исполнения и статическую проверку зависимостей.

Оберон — это язык программирования с сильной типизацией.
Имеется штатное средство динамической компоновки с контролем типов.

C> И что? Кто мешает писать в Линуксе на Питоне или (о Боже!) на Обероне?

Ничто не мешает.
Существует даже версия системы Oberon для Linux.
Линукс здесь выступает в качестве лишнего уровня абстракции,
снижающего производительность.

C> Слишком много зависит от тонких внутренних механизмов ядра.

Так как в Обероне — буферы совершенно отдельны и независимы.
Можно сделать свою реализацию, специально заточенную под задачу.
И не нужна будет телепатия: "наверное файл будут читать последовательно".

C> flock(2)

И каковы будут типичные объёмы прикладного кода одинаковой функциональности?

C> Если кратко — всего. Если полно, то все приведенные подсистемы Haiku на
C> световые годы лучше BlueBottle.

Да это же голословное утверждение.

C> Да, Оберон успешно показал свою несостоятельность.

Нет, однозначных выводов нет.

absolute wrote:
> C> И что? В компиляторе бывают ошибки, особенно если он оптимизирующий
> Что, если таким компилятором скомпилировать ядро ОС с аппаратной защитой?
А ничего. Защищенность будет зависеть от качества реализации уже самой
системы, а не компиляторы.

> C> В _реальной_ системе еще и существует
> C> недоверяемый код.
> Это belief.
Нда...

> C> В BlueBottle'е нет механизмов верификации машинного кода
> "ОС должна запускать на исполнение произвольный машинный код"
> Это ещё один belief.
Да? А что у нас там запускается в BlueBottle?

> C> Как? Ничерта там не контролируется — вы путаете защиту времени
> C> исполнения и статическую проверку зависимостей.
> Оберон — это язык программирования с сильной типизацией.
> Имеется штатное средство динамической компоновки с контролем типов.
Еще раз медленно: оно работет во время компиляции. Нужен контроль
времени выполнения.

Сейчас его можно обеспечить аппаратно (в BlueBottle нет) или программно
с помощью управляемого кода (в BlueBottle тоже нет).

> C> И что? Кто мешает писать в Линуксе на Питоне или (о Боже!) на Обероне?
> Ничто не мешает.
> Существует даже версия системы Oberon для Linux.
Вот, так что аргумент про несуществование "безопасных" в смысле
BlueBottle ОСей отпадает.

> Линукс здесь выступает в качестве лишнего уровня абстракции,
> снижающего производительность.
Слова "Оберон" и "производительность" могут быть в одном предложении
только если оно звучит так: "Производительность Оберона — фиговая", так
как его компиляторы — далеко не самые лучшие.

> C> Слишком много зависит от тонких внутренних механизмов ядра.
> Так как в Обероне — буферы совершенно отдельны и независимы.
Какие буферы? Вы о чем это?

> Можно сделать свою реализацию, специально заточенную под задачу.
> И не нужна будет телепатия: "наверное файл будут читать последовательно".
Вы понимаете что такое кэши SCSI-контроллеров и ATA-винчестеров?

> C> flock(2)
> И каковы будут типичные объёмы прикладного кода одинаковой функциональности?
Вероятно, для обычных ОС будут меньше.

> C> Если кратко — всего. Если полно, то все приведенные подсистемы Haiku на
> C> световые годы лучше BlueBottle.
> Да это же голословное утверждение.
Да, примерно как "производительность программиста на Обероне —
значительно выше".

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, absolute,

C>>В компиляторе бывают ошибки, особенно если он оптимизирующий

A>Что, если таким компилятором скомпилировать ядро ОС с аппаратной защитой?

А какова вероятность, что такие ошибки привели к компрометированию защиты по случайности? Простите за тавтологию


Аппаратная защита работает над компилятором. Если по-случайности какой-то код пользователя попробует вызвать код ядра некорректным образом, возникнет исключение, которое это ядро обработает. И система может этот процесс завершить по своему усмотрению.


Если же кто-то хочет эксплуатировать уязвимости, он будет их искать специально, что увеличивает шансы для эксплоита. Допустим, они могут быть в любом компиляторе. Тогда Оберон имеет недостаток — нет дополнительного слоя защиты. Каковы шансы возникновения ошибок в компиляторах, есть ли на этот счёт какие-нибудь исследования? Может нужен этот слой, а может и нет.


Уязвимости в логике проще найти. Их и будут искать и находить — компилятор ошибок в логике не исправляет. А если не находят, значит плохо ищут или не в состоянии найти. Много знаете уязвимостей в дырявом виндосе, в ядре XPSP2? Их находят во всяких аутглюках. А там люди мотивированно ищут.

А надёжность некоторых других систем возможно обеспечена только статусом Неуловимого Джо.

Здравствуйте, absolute, Вы писали:

A>А что будет, если предложить С#/С++ программисту сделать компилятор своего языка?

Ну так пишут. GCC тот же посмотрите.

Здравствуйте, Cyberax, Вы писали:

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

Защищённость всегда будет зависеть и от компилятора.
Что, если мы соберём крутое ядро линуха глючным си-компилятором?
Скорее всего, ничего хорошего.

Поэтому аппелировать к глюкам компиляторов не имеет смысла.
Наоборот, в Обероне компилятор — это основной механизм защиты.
И ничего "в довесок" не нужно (ну, рантайм должен быть корректным).

C> Да? А что у нас там запускается в BlueBottle?

Код, откомпилированный из безопасного языка.

C> Еще раз медленно: оно работет во время компиляции. Нужен контроль
C> времени выполнения.

Какой контроль времени выполнения?
Вот, например, если индексы массива нельзя проверить во время компиляции,
будут вставлены динамические проверки.
Нулевые указатели в Обероне обычно ловятся аппаратной защитой памяти,
потому что оверхед при работе в штатном режиме нулевой.

C> Сейчас его можно обеспечить аппаратно (в BlueBottle нет) или программно
C> с помощью управляемого кода (в BlueBottle тоже нет).

Чем не годятся исходники на безопасном языке.

C> Слова "Оберон" и "производительность" могут быть в одном предложении
C> только если оно звучит так: "Производительность Оберона — фиговая", так
C> как его компиляторы — далеко не самые лучшие.

Кроме оптимизации компиляторов существует "оверхед платформы".
В Обероне он меньше (за счёт например отсутствия аппаратной защиты).
Реальные системы на Обероне выглядят более экономичными.

C> Какие буферы? Вы о чем это?

Через которые осуществляется собственно дисковый ввод-вывод.

C> Вы понимаете что такое кэши SCSI-контроллеров и ATA-винчестеров?

Наверное это память, расположенная в самих винчестерах.

Дело даже не в этом.
По этому поводу прозвучало только лишь
"Слишком много зависит от тонких внутренних механизмов ядра."
и
"Нет, но сразу обнаружится, что BlueBottle совсем не маленькая и
элегантная ОС."

Так вот, степень интеграции компонентов в Обероне — очень высокая.
Фактически, весь код представляет собой единую
"расширяемую модульную систему" (с)

Поэтому аргументы типа "зависит от механизмов" имеют смысл лишь
если взаимодействию компонентов препятствует аппаратная защита.

C> Вероятно, для обычных ОС будут меньше.

А почему, если в Обероне встроенные механизмы более высокоуровневые?

Здравствуйте, gear nuke, Вы писали:

gn> А какова вероятность, что такие ошибки привели к компрометированию защиты по случайности?

Неизвестно.
В обоих случаях оптимистическая точка зрения — "в компиляторах ошибок нет".
Для более простых языков программирования достичь этого проще.

gn> Аппаратная защита работает над компилятором. Если по-случайности какой-то код пользователя попробует вызвать код ядра некорректным образом, возникнет исключение, которое это ядро обработает.

В Обероне, если по случайности написать код, некорректно вызывающий ядро, то такой код просто не скомпилируется.

gn> Тогда Оберон имеет недостаток — нет дополнительного слоя защиты. Каковы шансы возникновения ошибок в компиляторах, есть ли на этот счёт какие-нибудь исследования? Может нужен этот слой, а может и нет.

Ну вот. В некоторых системах есть, а вот в Обероне нет.
А сам слой тоже должен компилироваться компилятором.

gn> Много знаете уязвимостей в дырявом виндосе, в ядре XPSP2? Их находят во всяких аутглюках. А там люди мотивированно ищут.

В Обероне прикладной код по архитектуре ДОЛЖЕН быть написан на безопазном языке.
Это изначально устраняет многие проблемы.

gn> А надёжность некоторых других систем возможно обеспечена только статусом Неуловимого Джо.

Возможно.
Тем не менее, возможные источники проблем вполне ясны и могут быть проконтролированы.

Здравствуйте, gear nuke, Вы писали:

GN>Здравствуйте, absolute, Вы писали:

A>>А что будет, если предложить С#/С++ программисту сделать компилятор своего языка?

GN>Ну так пишут. GCC тот же посмотрите.

Разработчики GCC не являются оппонентами Оберона.

Здравствуйте, Cyberax, Вы писали:


C>В BlueBottle'е нет механизмов верификации машинного кода и нет механизма
C>аппаратной защиты. Точно так же как в Win3.11

Как раз в Win3.11 был механизм аппаратной защиты.

absolute wrote:
> В Обероне, если по случайности написать код, некорректно вызывающий
> ядро, то такой код просто не скомпилируется.
В Обероне нет механизма защиты памяти, а значит банальный

cli ; Запретим маскируемые прерывания
f: jmp f ; И устроим "пятисекундную паузу"

завесит всю систему (так было и в Win9x).

--
С уважением,
Alex Besogonov (alexy@izh.com)

Трурль wrote:
> C>В BlueBottle'е нет механизмов верификации машинного кода и нет механизма
> C>аппаратной защиты. Точно так же как в Win3.11
> Как раз в Win3.11 был механизм аппаратной защиты.
Только для DOS-приложений, причем далеко не от всего (прерывания в Винде
не виртуализировались до NT4).

--
С уважением,
Alex Besogonov (alexy@izh.com)

absolute wrote:
> A>>А что будет, если предложить С#/С++ программисту сделать компилятор
> своего языка?
> GN>Ну так пишут. GCC тот же посмотрите.
> Разработчики GCC не являются оппонентами Оберона.
Я исправил в GCC несколько багов — значит я являюсь разработчиком GCC.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, absolute, Вы писали:

A>В Обероне прикладной код по архитектуре ДОЛЖЕН быть написан на безопазном языке.

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