Добро пожаловать,
Свежие материалы
Обсуждения
Микропроцессор "Эверест" (1)
Запрет регистрации на osrc.info (1)
Ответ Javе и Flash'у (70)
Новая программа поддержки от Microsoft (2)
Solaris будет портирован на Itanium и POWER? (3)
9 декабря вышла новая сборка Xameleon (9)
рассылка (2)
ЗРОС (3)
Новый стиль OSRC.info (2)
Обсуждение статьи "Взгляд на развитие YellowTAB" (124)В Сети
Гостей: 4, Пользователей: 1 ...
Roman I Khimov смотрит rss.php
рекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07
Пользователей: 1007
Новичок: alicemokas
Roman I Khimov смотрит rss.phpрекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07
Пользователей: 1007
Новичок: alicemokas
| Центр информации по операционным системам :: Форумы :: Концепции :: ОС-21 |
|
<< Предыдущая тема | Следующая тема >> |
| Заглядывая в туманное будущее - обсуждение | ||
| Переход на страницу 1 2 3 ... 8 [9] 10 ... 13 14 15 | |
|
Модераторы: Roman I Khimov, Wanderer, Dron
|
| Автор | Добавил | ||
| may |
| ||
 ID пользователя #420 Зарегистрирован: Понедельник 05.09.2005 08:03Местонахождение: г.Чита Сообщений: 6 | captain cobalt написал(а) ... may написал(а) ... Конкретный потенциально опасный модуль можно либо проверить, либо принять на веру, что все нормально, понадеявшись на цифровую подпись. Каким образом может быть произведена проверка в Bluebottle мне никто так и не ответил. Bluebottle - это рантайм для языка Active Oberon. Вообразим себе систему, в которой нельзя загружать бинарные модули, только через исходник на безопасном языке. Active Oberon - безопасный язык (без модуля SYSTEM). Механизма для проверки безопасности бинарного модуля, или импортирующего SYSTEM нет. Есть только чёткое разделение на безопасные и системные модули. И на уровне архитектуры стараются минимизировать количество кода в системных модулях - используют их только для специфичных непереносимых вещей. Основная же часть (более 99%) является безопасной. Что непонятно? Из написанного в предыдущем абзаце понятно абсолютно все:) Хотелось бы обрести уверенность насчет оставшегося 1%  Предлагаю пообсуждать как это можно сделать captain cobalt написал(а) ... may написал(а) ... Вот.что если уж речь идет об новой ОС, то закладываться надо в первую очередь не на превосходство над существующими, а на "должно быть так". Такая архитектура это именно "должно быть так". may написал(а) ... Дальше можно не читать. 1. Микроядро в кольце 0 Почему же? captain cobalt написал(а) ... Если необходимо взаимодействие/совместимость с другими ОС, то гораздо сподручнее не кольцами жонглировать, а перенести Bluebottle в желаемую ОС. См, например, WinAos. Ура!!! Заработало У нас начинается конструктивный диалог Если позиционировать Bluebottle именно как "рантайм для языка Active Oberon", то снимается очень много вопросов которые возникают если считать ее ОС. Давайте немного среду доработаем, уберем из нее особенности которые нужны ОС и не нужны рантайму (например возможность прямого доступа к портам и памяти и работу рантайма в кольце 0) и получим замечательную среду исполнения для языка Active Oberon. Вот эту среду действительно можно переносить из одной ОС в другую, т.е. получиться кроссплатформенный рантайм, который за счет легкости, стройности и целостной концепции составит очень серьезную конкуренцию и .Net и Java. А если еще и ОС, в которой эксплуатируется замечательный рантайм Bluebottle, обеспечит нам ПОЛНОСТЬЮ контролируемое исполнение кода оперирующего с "железом"... От таких перспектив дыхание перехватывает Мы ж тогда смело сможем заявить "У нас в системе все безопасно, и язык и рантайм и низкоуровневые модули" Кстати ничего не слышно о проекте разворачивания Bluebottle под QNX? Если это прокатит получиться очень мощный тандем. Если соберемся свою систему делать надо иметь ввиду как возможного конкурента | ||
| Наверх | | ||
| captain cobalt |
| ||
  ID пользователя #12 Зарегистрирован: Воскресенье 04.07.2004 21:44Местонахождение: /ru/perm Сообщений: 144 | may написал(а) ... Оставшийся 1% - это можно сказать "собственно система". Как обрести уверенность насчёт ядра ОС? Как можно не доверять Microsoft и пользоваться Windows? Хотелось бы обрести уверенность насчет оставшегося 1% Предположим, что речь идёт о драйвере устройства. Как мы можем быть уверены, что он действительно управляет именно этим устройством? Особенно если мы сами не знаем как управлять устройством? Если драйвер произведён изготовителем устройства, ему можно доверять?may написал(а) ... Даже системные модули в Bluebottle преимущественно используют безопасные конструкции.Предлагаю пообсуждать как это можно сделать Если SYSTEM в модуле драйвера используется только для доступа к пространству портов ввода-вывода, то целостность памяти может быть сохранена. may написал(а) ... Замечательно.Если позиционировать Bluebottle именно как "рантайм для языка Active Oberon", то снимается очень много вопросов которые возникают если считать ее ОС. Давайте немного среду доработаем, уберем из нее особенности которые нужны ОС и не нужны рантайму (например возможность прямого доступа к портам и памяти и работу рантайма в кольце 0) Bluebottle - это именно "рантайм для языка Active Oberon". Собственно рантайму в принципе не нужен доступ к кольцу 0. Достаточно адресного пространства, которое обычно может предоставить практически любая другая ОС. Системные средства нужны только системным модулям. Именно поэтому стараются минимизировать количество кода в системных модулях для повышения переносимости. may написал(а) ... Означает ли это использование Bluebottle поверх другой существующей OC?А если еще и ОС, в которой эксплуатируется замечательный рантайм Bluebottle, обеспечит нам ПОЛНОСТЬЮ контролируемое исполнение кода оперирующего с "железом"... Здесь имеется несколько затруднений, среди которых наиболее часто упоминаемое - различие в способах управления памятью. Bluebottle поверх другой ОС - это ещё один уровень абстракции. Поэтому результат не сможет работать быстрее или надёжнее, чем нижележащая ОС. Работающая поверх аппаратуры "нативная" Bluebottle может быть быстрее, чем другие ОС из-за более эффективного взаимодействия между прикладными модулями и драйверами (важно, например, для графики). Также она может работать надёжнее, чем другие ОС из-за повсеместного использования безопасного языка, в то время как ядра других ОС полностью написаны на ненадёжных низкоуровневых языках. may написал(а) ... Нет.Кстати ничего не слышно о проекте разворачивания Bluebottle под QNX? may написал(а) ... Вряд ли.Если это прокатит получиться очень мощный тандем. Bluebottle основана на модулях и прямых процедурных вызовах. QNX на процессах и обмене сообщениями. Опять же различное отношение к управлению памятью и реальному времени. bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом. | ||
| Наверх |
| ||
| may |
| ||
| ID пользователя #420 Зарегистрирован: Понедельник 05.09.2005 08:03Местонахождение: г.Чита Сообщений: 6 | captain cobalt написал(а) ... may написал(а) ... Хотелось бы обрести уверенность насчет оставшегося 1% Оставшийся 1% - это можно сказать "собственно система". Как обрести уверенность насчёт ядра ОС? Разными способами например открыть исходный код ядра, чтобы все желающие могли убедиться, что оно таки надежное. Или отдать ядро на тестирование в организацию пользующуюся авторитетом у пользователей. Либо просто делать заключения по опыту эксплуатации captain cobalt написал(а) ... Как можно не доверять Microsoft и пользоваться Windows? Очень просто - сейчас очень много народу, по крайней мере из моих знакомых, пользуются Виндами, но Микрософту вобщем-то недоверяют То есть при пользовании учитывают, что им никто ничем не обязан. captain cobalt написал(а) ... Предположим, что речь идёт о драйвере устройства. Как мы можем быть уверены, что он действительно управляет именно этим устройством? Особенно если мы сами не знаем как управлять устройством? Если драйвер произведён изготовителем устройства, ему можно доверять? Сноска: считаем что в надежности ядра мы уже убедились, способы см. выше Итак - убираем драйвер в кольцо 3. Ядро живет в кольце 0. Таким образом драйвер у нас полностью подконтролен ядру ОС. От ошибок при работе с железом это нас не избавит но по-крайней мере проконтролировать что код работает только с определенным железом сможем. Ну и доступ к памяти конечно контролируем. captain cobalt написал(а) ... may написал(а) ... Предлагаю пообсуждать как это можно сделать Даже системные модули в Bluebottle преимущественно используют безопасные конструкции. Если SYSTEM в модуле драйвера используется только для доступа к пространству портов ввода-вывода, то целостность памяти может быть сохранена. А может быть можно сделать по-другому - убрать драйвера из рантайма, ибо не место им там. А кроме как для доступа к железу низкоуровневые конструкции ни для чего больше не нужны. Тогда можно запретить вобще экспорт модуля System, и гарантировать, что в пределах рантайма у нас целостность памяти обеспечивается за счет ЯП. captain cobalt написал(а) ... may написал(а) ... Если позиционировать Bluebottle именно как "рантайм для языка Active Oberon", то снимается очень много вопросов которые возникают если считать ее ОС. Давайте немного среду доработаем, уберем из нее особенности которые нужны ОС и не нужны рантайму (например возможность прямого доступа к портам и памяти и работу рантайма в кольце 0) Замечательно. Bluebottle - это именно "рантайм для языка Active Oberon". Собственно рантайму в принципе не нужен доступ к кольцу 0. Достаточно адресного пространства, которое обычно может предоставить практически любая другая ОС. Системные средства нужны только системным модулям. Именно поэтому стараются минимизировать количество кода в системных модулях для повышения переносимости. Вынести "системные модули" на уровень ОС Запускать рантайм в кольце 3 как один из "драйверов" ОС Для устройств в рантайме сделать прокси-объекты с жестко зафиксированным интерфейсом. captain cobalt написал(а) ... may написал(а) ... А если еще и ОС, в которой эксплуатируется замечательный рантайм Bluebottle, обеспечит нам ПОЛНОСТЬЮ контролируемое исполнение кода оперирующего с "железом"... Означает ли это использование Bluebottle поверх другой существующей OC? Да. Работа с "железом" - функция операционки. Работа с прикладным кодом - функция рантайма, который пользуется функциями операционки. captain cobalt написал(а) ... Здесь имеется несколько затруднений, среди которых наиболее часто упоминаемое - различие в способах управления памятью. Bluebottle поверх другой ОС - это ещё один уровень абстракции. Поэтому результат не сможет работать быстрее или надёжнее, чем нижележащая ОС. Работающая поверх аппаратуры "нативная" Bluebottle может быть быстрее, чем другие ОС из-за более эффективного взаимодействия между прикладными модулями и драйверами (важно, например, для графики). Также она может работать надёжнее, чем другие ОС из-за повсеместного использования безопасного языка, в то время как ядра других ОС полностью написаны на ненадёжных низкоуровневых языках. Основным свойством в современных системах должна выступать, на мой взгляд, все-таки не скорость, а надежность. Скорость можно добавить за счет более мощного железа, а вот надежность никак. Тем более за счет надежности можно косвенно компенсировать потерю скорости, например снижая кол-во необходимых внутренних системных проверок, что ведет, кстати, к снижению объема кода системы. А вот если попытаться, как сейчас делается, превратить скорость в надежность то будет в точности наоборот - дополнительные проверки ->увеличение объема кода. Если так посмотреть, то идеальная система это очень маленькое, предельно надежное ядро с очень жесткими механизмами контроля за любым кодом в системе + контролируемые драйвера + рантайм с прикладным кодом. Дополнительная надежность системы, которую привносит безопасный язык программирования, никуда не денется если большинство прикладного кода исполняется в рантайме. Вот и получается примерная схема микроядро в кольце 0, драйвера в кольце 3, рантайм в ранге драйвера в кольце 3 и прикладной код. А еще одна фишка это повторное использование кода. Так что нужен очень тщательный дизайн библиотек объектов в рантайме. Возможно вплоть до каркасов типичных приложений в системе. И вобще можно дерево классов объектов используемых в системе зафиксировать как минимум на уровне интерфейсов классов. И уже на базе этого дерева делать саму ОС и рантайм согласованно. Тогда получиться ОС лучше всего "заточеная" на исполнение кода из под рантайма, и то, что ОС и рантайм фактически это 2 части кода, которые выполняются в разных кольцах защиты, влиять на производительность особо не будет. Может быть стоит рассмотреть возможность эмуляции АПИ например от Линукса за счет моста к рантайму. Тогда ОС и унаследованный код тоже сможет выполнять в отдельном адресном пространстве на кольце 3 как отдельное приложение. Но это уже на сладкое | ||
| Наверх | | ||
| captain cobalt |
| ||
| ID пользователя #12 Зарегистрирован: Воскресенье 04.07.2004 21:44Местонахождение: /ru/perm Сообщений: 144 | Ну вот, совсем другой конструктивный разговор. Прежде всего следует отметить, что в Bluebottle рантайм - это самый нижний уровень. По большому счёту рантайм состоит из следующих частей: -- динамический компоновщик модулей -- распределитель памяти со сборщиком мусора -- шедулер активных объектов вся остальная система состоит из модулей работающих поверх рантайма, пользующихся его услугами. Системные модули также работают поверх рантайма (не под ним) и пользуются, например, активными объектами. Как только мы помещаем системные модули в другое адресное пространство, мы сразу сталкиваемся с трудностями. Так как шедулер активных объектов не сможет дотянуться в другое адресное пространство, возникает вопрос, кто будет обеспечивать вытесняющую параллельность для кода, расположенного в различных адресных пространствах. Лежащее под рукой решение это may написал(а) ... Здесь возникают проблемы с устройствами с высокой пропускной способностью, к которым относятся гигабитные сетевые карты и видеокарты.Для устройств в рантайме сделать прокси-объекты Как прокачать гигантские объёмы данных из одного адресного пространства в другое? Простейшее решение - копировать данные. Несерьёзно. Другой способ - воспользоваться разделяемыми страницами. Это позволяет повысить пропускную способность, в пределе до скорости прямого доступа к разделяемым данным в одном адресном пространстве. Но - за счёт больших буферов (перерасход памяти) и существенного увеличения латентности. А это может быть критично. may написал(а) ... В современном железе типа ia32 используется аппаратная защита памяти. Каждый формируемый адрес проверяется. Из каждого миллиарда проверок вероятно в среднем менее одной завершается неуспешно. Также огромное количество вычислительных ресурсов тратится на проверки зависимости по данным и прочие накладные расходы суперскаляров. Если бы все эти вычислительные ресурсы были доступны программно, то распараллеливание команд можно было проводить во время компиляции, а (программные) проверки адресов вставлять только там где это необходимо. Высвободившиеся вычислительные ресурсы можно "использовать с пользой". Основным свойством в современных системах должна выступать, на мой взгляд, все-таки не скорость, а надежность. Скорость можно добавить за счет более мощного железа, а вот надежность никак. Тем более за счет надежности можно косвенно компенсировать потерю скорости, например снижая кол-во необходимых внутренних системных проверок, что ведет, кстати, к снижению объема кода системы. А вот если попытаться, как сейчас делается, превратить скорость в надежность то будет в точности наоборот - дополнительные проверки ->увеличение объема кода. bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом. | ||
| Наверх |
| ||
| Roman I Khimov |
| ||
  ID пользователя #1 Зарегистрирован: Воскресенье 27.06.2004 12:37Местонахождение: Санкт-Петербург Сообщений: 601 | Капитан, а все-таки, если сборки изначально представлены на машинном языке, то их можно подправить как угодно. То есть, специально обойти тот самый безопасный язык, который, до тех пор пока работаешь в его рамках, все держит под контролем. Ну а дальше нулевое кольцо и печальные выводы. А вот рассмотрим, к примеру, .NET - есть IL и если сборки изначально представлены именно в нем, то нет никакой возможности обойти безопасность платформы (если, конечно, не отыскать баги в ее реализации). Ну а скорость можно достичь через AOT, поддерживаемый на системном уровне, то есть, чтобы результаты AOT вообще нигде и никак не были видны - не пользовательское это дело. Такая платформа может работать в нулевом кольце и пользоваться всеми преимуществами этого подхода - это будет действительно безопасно. Греби и улыбайся! | ||
| Наверх |
| ||
| captain cobalt |
| ||
| ID пользователя #12 Зарегистрирован: Воскресенье 04.07.2004 21:44Местонахождение: /ru/perm Сообщений: 144 | В данном случае IL используется в качестве безопасного языка. То что в .NET называется AOT, является базовым в Обероне, причём из исходников в бинари. Если представлять модули в виде исходников, можно добиться точно такой же безопасности. .NET не предназначена для системного программирования. В настоящее время лежащий под платформой код и сама платформа реализуются на небезопасном языке C. Платформа .NET является чрезвычайно усложнённой (надо поддерживать кучу особенностей множества языков), поэтому практически наверняка в её реализации будет куча ошибок. Поэтому "безопасную ОС на .NET" (например, Vista) можно считать мифом. Скорее всего, Microsoft изобретёт новую флагманскую платформу (в соответствии с принципом огня и движения) раньше чем появится надёжная реализация .NET (обесценив тем самым усилия затраченные на её реализацию). bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом. | ||
| Наверх |
| ||
| Roman I Khimov |
| ||
| ID пользователя #1 Зарегистрирован: Воскресенье 27.06.2004 12:37Местонахождение: Санкт-Петербург Сообщений: 601 | captain cobalt написал(а) ... Если представлять модули в виде исходников, можно добиться точно такой же безопасности. Вот на такой вариант согласная. Только компилировать значительно дольше. captain cobalt написал(а) ... .NET не предназначена для системного программирования. И тем не менее проект Singularity написал ядро на C#. Конечно же, с использованием небезопасных конструкций и ассемблерных вставок - куда деваться. captain cobalt написал(а) ... В настоящее время лежащий под платформой код и сама платформа реализуются на небезопасном языке C. Такого кода много. Это плохо. Если свести количество такого кода к минимуму, то он вполне будет доступен для полного аудита в стиле OpenBSD. captain cobalt написал(а) ... Платформа .NET является чрезвычайно усложнённой (надо поддерживать кучу особенностей множества языков), поэтому практически наверняка в её реализации будет куча ошибок. Ну это бабушка надвое... captain cobalt написал(а) ... Поэтому "безопасную ОС на .NET" (например, Vista) можно считать мифом. Но она, при этом, уже создана...  captain cobalt написал(а) ... Скорее всего, Microsoft изобретёт новую флагманскую платформу (в соответствии с принципом огня и движения) раньше чем появится надёжная реализация .NET (обесценив тем самым усилия затраченные на её реализацию). Кхм. Для того, чтобы понять всю прелесть дальнейшей фразы, необходимо посмотреть м/ф "Скамейка" Смешариков. Неизвестно! Да, она, наверное, уже высохла... Нет, понимаешь, не высохла... Греби и улыбайся! | ||
| Наверх |
| ||
| Dron |
| ||
  ID пользователя #13 Зарегистрирован: Понедельник 05.07.2004 11:16Местонахождение: Москва Сообщений: 651 | 2captain cobalt: Ты вот говоришь, что изучить оберон не сложно... не спорю... Но вот есть такой разговорный язык - Токипона.. давай все дружно перейдем на него... и будем разговаривать? Там всего-то 60 слов... и все будут счастливы. PS: Кстати я вот в который раз не понимаю что в этом обероне можно сделать... объясни тупому. вижу эти вот окна и что дальше то?  Ну то что интерфейс убогий - это мы опустим... как вот хотя бы сеть настроить... а то пока шел таймаут - она вся стояла! Даже на мышу не реагировала...  [ Редактирование понедельник 19.09.2005 12:30 ] Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее... Андрей Валяев | ||
| Наверх |
| ||
| captain cobalt |
| ||
| ID пользователя #12 Зарегистрирован: Воскресенье 04.07.2004 21:44Местонахождение: /ru/perm Сообщений: 144 | Dron написал(а) ... На самом деле там 118 слов. Но вот есть такой разговорный язык - Токипона.. давай все дружно перейдем на него... и будем разговаривать? Там всего-то 60 слов... и все будут счастливы. -ссылка-Оберон изучить несложно, а Токи Пона - сложно. Повсеместно распространённые электронно-вычислительные машины вообще работают в двоичном коде. Программирование - это построение иерархий абстракций, из более простых вещей более сложных. От языка программирования требуется лишь способ для описания такой иерархии. В языке Oberon это модули, типы и процедуры. Active Oberon предоставляет средства параллелизма. Dron написал(а) ... В котором именно?PS: Кстати я вот в который раз не понимаю что в этом обероне можно сделать... объясни тупому. Для Bluebottle рекомендуется брать последний Crazy Fresh. По вопросам аппаратной совместимости я пока квалифицированно проконсультировать не могу. Кстати, недавно обнаружилась такая вещь (не моё): http:/sage.h15.ru/?e1l0 Dron написал(а) ... Принципы пользовательского интерфейса Bluebottle описаны в диссере Томаса Фрея -ссылка-вижу эти вот окна и что дальше то? Ну то что интерфейс убогий - это мы опустим... Dron написал(а) ... И вообще лучше читать документацию. как вот хотя бы сеть настроить... P.S. Offtop: Как насчёт Мейера? -ссылка- bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом. | ||
| Наверх |
| ||
| Dron |
| ||
| ID пользователя #13 Зарегистрирован: Понедельник 05.07.2004 11:16Местонахождение: Москва Сообщений: 651 | И вообще лучше читать документацию. Как насчет русскоязычной??? Или я опять должен делать то, что не хочу? Пусть в Токипона 118 слов... суть от этого не меняется... Я вот не хочу изучать Токипону. и ты тоже не хочешь... Так почему же ты считаешь что все с радостью пойдут изучать оберон? вообще глядя на оберон (вот чайник я, английского не знаю, комп вижу в первые) я вообще не понимаю что делать. Пусть там есть документация - пользователи не читают документацию. Пусть комп я вижу далеко не в первый раз... всеравно не мне понятно как это работает! Какой из всего вывод? За 20 лет можно было сделать хотя бы покрасивее. Я не фанат Виндуз... но это и вовсе не означает что я привык все делать из командной строки. я хочу чтобы было удобно! хочу чтобы меня не заставляли думать на какую кнопку нажать. чтобы меня не заставляли пытаться прочитать англоязычную документацию... (которую при самом старте на меня вывалили целый экран и маленькую тележку)... я не хочу изучать оберон... И я думаю, что таких как я не единицы... таких как я большинство. Может быть поэтому никто не использует Блюботл (читать - меньше милиона пользователей) И вовсе не такой я вижу ОС будующего... Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее... Андрей Валяев | ||
| Наверх |
| ||
| Переход на страницу 1 2 3 ... 8 [9] 10 ... 13 14 15 | |
Powered by e107 Forum System