> man operating_systems
Переход на страницу  1 2 [3] 4 5 6
Модераторы: Roman I Khimov, Wanderer, Dron
Автор Добавил
pumba103
Вторник 04.10.2005 22:18
ID пользователя #327
Зарегистрирован: Понедельник 30.05.2005 10:28
Местонахождение: Moscow
Сообщений: 11
czarker написал(а) ...
Хочу обратить всеобщее внимание на тот факт, что NO вообще не клиент OSRC.info: прелесть NO заключается в уникальной среде исполнения программ, но инноваций в области системного дизайна там нет. Имеется в виду, что они есть в Blueottle, но это, похоже, прямой потомок, при создании которого люди вспомнили о том, что они всё же ОС пишут.

Очень хочется узнать, что есть "инновации в системном дизайне". Иначе непонятно как NO включающая такие вещи как :
* отказ от концепции программ,
* уникальный текстоориентированный интерфейс (TUI),
* отличную от HTML концепцию и реализацию гипертекста,
* концепцию "document centric computing" (в версии NO with Gadgets)'
* и так далее, я назвал только несколько инноваций навскидку
обьявляется инноваций не содержащей.
Наверх
ddc
Вторник 04.10.2005 23:08
Free Software Zealot


ID пользователя #202
Зарегистрирован: Воскресенье 06.02.2005 09:32
Местонахождение: Москва
Сообщений: 189
Roman I Khimov
Native Oberon - это ОС, являющаяся поздней почти точной копией Plan9, основанной на языке Oberon и использующей его возможности.

pumba103
pumba103 написал(а) ...
* отказ от концепции программ,
Демагогия. Вопрос скорее в характере программ и вопросах, связанных с их запуском, но это и есть среда исполнения, т.е. вопрос лежит вне области системного дизайна.
pumba103 написал(а) ...
* уникальный текстоориентированный интерфейс (TUI),
Вах!!! Финальная версия Plan9 1st edtn появилась в 1984 году (за 3 с лишним года до первой версии Native Oberon), и уже имела именно этот уникальный текстоориентированный интерфейс.
pumba103 написал(а) ...
* отличную от HTML концепцию и реализацию гипертекста,
Вот за это спасибо. Я давно так не смеялся... Требуется ответ, или и так понятно?
pumba103 написал(а) ...
* концепцию "document centric computing" (в версии NO with Gadgets)'
См. п. 1.
pumba103 написал(а) ...

* и так далее, я назвал только несколько инноваций навскидку
Ждём продолжение...
Вообще NO можно рассматривать как Plan9 с языковой спецификой, ибо функционал повторяется в деталях. Просто там люди занимались системным дизайном, поэтому красивые слова говорились про среду исполнения (вспоминаем документы про особенности С в Plan9), а здесь люди разработали великолепную среду исполнения, а потому красивые слава направлены в адрес системного дизайна.
P.S.: Обратите внимание, я не говорю, что NO - плохая ОС, я говорю, что в ней нет эксклюзивных особенностей системного дизайна.

Но это всё, конечно, моё сугубо личное мнение...
Наверх
captain cobalt
Среда 05.10.2005 06:55

ID пользователя #12
Зарегистрирован: Воскресенье 04.07.2004 21:44
Местонахождение: /ru/perm
Сообщений: 144
Native Oberon является портом ETH Oberon.

TUI в Plan9 принадлежит к Acme.

Давайте для выяснения, кто у кого срисовал, почитаем главного курителя плана, Роба Пайка?
Статью Acme: A User Interface for Programmers.

Вот парочка цитат:
Acme is a new program, a combined window system, editor, and shell, that applies some of the ideas distilled by Oberon.

Most of Acme's style, however, derives from the user interface and window system of Oberon [Wirt89, Reis91].


bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом.
Наверх
Сайт
Dron
Среда 05.10.2005 10:03


ID пользователя #13
Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651
Капитан... вот ты там про ненадежность драйверов упомянул... да возможно что злоумышленник подменил драйвер харда... (такое возможно и в Блюботле) и все перестало работать... это так.

Но что мешает мне в MDF проверить подпись того же драйвера (тем более что базовые драйвера все будут родными)...

И еще... разделение user/system - помоему явно недостаточное... драйвер должен иметь доступ только к тем ресурсам, которые относятся к соответствующему оборудованию.

Мне пофиг язык... на то и существуют правила чтобы их нарушать. надежность должна быть выше этого...

вот насчет эмуляции - я согласен с Романом... здесь надежность на другом уровне... даже если ты будешь писать в псевдокоде - ты не сможешь ее обойти...
Одна беда - это медленно. не хочется тратить свои гигагерцы на тупое переваривание одних инструкций в другие.

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

Андрей Валяев
Наверх
Сайт
pumba103
Среда 05.10.2005 10:19
ID пользователя #327
Зарегистрирован: Понедельник 30.05.2005 10:28
Местонахождение: Moscow
Сообщений: 11
2czarker
Констатирую, что вы не понимаете ни что такое Plan9 ни что такое Oberon иначе вы не написали, что Oberon есть почти точная копия Plan9 опираясь только на то, что TUI Acme наследует некоторые идеи TUI Oberon. Кстати TUI Oberon появился в Ceres Oberon в 1985 году, а первое издание Plan9 согласно "Plan9: The early papers" в 1990.
Можно много смеяться и ставить много смайликов, но это не компенсирует того, что вы ничего не знаете о перечисленных инновациях в Oberone.
Возросшая агрессивность ответа кстати стопроцентно свидетельствует об отсутствии аргументов. Кстати вашего определения, что такое "системный дизайн" и также не увидел.
Наверх
ddc
Среда 05.10.2005 10:42
Free Software Zealot


ID пользователя #202
Зарегистрирован: Воскресенье 06.02.2005 09:32
Местонахождение: Москва
Сообщений: 189
pumba103 написал(а) ...
что такое "системный дизайн" и также не увидел
Тяжко с Вами. На вскидку трудно подобрать достаточно короткое и точное определение. Днём подумаю и вечером отвечу.
Про точную копию я конечно... эхм... погорячился.
По-моему, Вы фактографически не правы, но сейчас у меня нет времени. Вечером либо представлю доказательства своей правоты, либо извинения.
P.S.: С датами я всё-таки напутал: первый релиз Plan9 был в 1986 году, т.е. не за 3 года, а за год до первой реализации Oberon.
P.P.S.: А вот что касается смайликов, то я продолжаю настаивать на том, что гипертекстовый формат, даже если он хороший, не имеет отношения к плюсам и минусам операционной системы, и в особенности её строения, и приводить его в каестве достоинства NO было по меньшей мере абсурдно. Или Вы не согласны с этим?
captain cobalt написал(а) ...
TUI в Plan9 принадлежит к Acme.
Базовые концепции TUI появились ещё в первом графическом интерфейсе Plan9. Позже в ACME были реализованы детали, являвшиеся стандартными в ETH Oberon, но концепция уже была заложена в Plan9 до появления ETH Oberon.
[ Редактирование среда 05.10.2005 10:46 ][ Редактирование среда 05.10.2005 10:59 ]

Но это всё, конечно, моё сугубо личное мнение...
Наверх
captain cobalt
Среда 05.10.2005 11:07

ID пользователя #12
Зарегистрирован: Воскресенье 04.07.2004 21:44
Местонахождение: /ru/perm
Сообщений: 144
Dron написал(а) ...
ПОльзователь вообще странное существо... он никогда не захочет сидеть в рамках заданных кем-то еще...
Разработчик драйверов тоже может не захотеть работать в рамках, навязываемых микроядром.
Dron написал(а) ...
было бы скучно жить в однотипных серых квартирах... было бы скучно смотреть на телевизор с одной программой...
На самом деле наоборот.
Когда Windows пользователям показывают Linux и сотни оконных менеджеров и рабочих столов для него, они обычно отвечают "я хочу один рабочий стол. стандартный. как в винде".

Программисты тоже особо не стремятся к разнообразию. Большинство из них было бы радо работать на одном, максимум двух языках. Этот факт подтверждает и то, что некоторые из них не хотят учить Оберон.
Dron написал(а) ...
Предположим что Оберон вдруг обрел популярность... (ну скажем сравнимую с виндой)... всякого стороннего ПО будет не меньше... и кто поручится? 99% юзеров никогда не задумаются о том юзает модуль систем или нет...
Может быть, пользователи также не задумываются о том, выполняется ли код в режиме пользователя или в режиме ядра и с радостью будут запускать модули ядра? Впрочем, многие Windows пользователи действительно не понимают, почему маленькая утилита требует права администратора.

Тем не менее, загрузка/инсталляция системных и прикладных модулей может производиться через разные пользовательские интерфейсы. Это может дать пользователю контроль над своей конфигурацией, и помешать "случайно" загрузить системный модуль.
Dron написал(а) ...
Капитан... вот ты там про ненадежность драйверов упомянул... да возможно что злоумышленник подменил драйвер харда... (такое возможно и в Блюботле) и все перестало работать... это так.
Замечательно.
Таким образом, устойчивость системы зависит не только от устойчивости ядра, но и от устойчивости драйверов.

А если устойчивость системы зависит от устойчивости драйверов, то:
-- зачем чинить разработчикам драйверов всякие дурацкие препятствия и мешать достичь максимальной производительности?
-- почему бы не дать разработчикам драйверов более безопасный язык программирования, чтобы повысить устойчивость драйверов?

Драйверы - это не тот класс программного обеспечения, который пользователи постоянно меняют. Сколько ты просмотрел драйверов ATAPI CD-ROM, прежде чем остановиться на одном из них?
Dron написал(а) ...
Мне пофиг язык... на то и существуют правила чтобы их нарушать. надежность должна быть выше этого...
Повысить надёжность с помощью безопасного языка программирования - тоже неплохая идея.
Dron написал(а) ...
вот насчет эмуляции - я согласен с Романом... здесь надежность на другом уровне... даже если ты будешь писать в псевдокоде - ты не сможешь ее обойти...
Почему бы не использовать безопасный язык в качестве такого "псевдокода", к тому же компилирующегося в весьма эффективный код?
Dron написал(а) ...
Одна беда - это медленно. не хочется тратить свои гигагерцы на тупое переваривание одних инструкций в другие.
Вот именно.
Самое важнейшее требование к архитектуре - она должна быть спроектирована разумно.
А не достигать одни максимальные характеристики в ущерб другим.

Современные монолитные ядра позволяют загружать модули ядра, потому что это разумно. Именно системы, основанные на этих ядрах используются шире всего, потому что это разумно.

Система Bluebottle позволяет:
-- повысить производительность за счёт избавления от накладных расходов аппаратной защиты памяти
-- повысить устойчивость за счёт применения безопасного языка даже для системных модулей

Таким образом, Bluebottle имеет более высокую разумность применения с точки зрения технических характеристик.

Микроядра -- не имеют более высокую разумность. И даже имеют сомнительно более высокую надёжность.

bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом.
Наверх
Сайт
den1
Среда 05.10.2005 11:14
ID пользователя #363
Зарегистрирован: Вторник 05.07.2005 16:47
Местонахождение: Россия. Москва.
Сообщений: 151
captain cobalt написал(а) ...
Давайте для выяснения, кто у кого срисовал, почитаем главного курителя плана, Роба Пайка?

Вот парочка цитат:
Acme is a new program, a combined window system, editor, and shell, that applies some of the ideas distilled by Oberon.

Most of Acme's style, however, derives from the user interface and window system of Oberon [Wirt89, Reis91].

Да, действительно верно. Более того - я мог запамятовать, но вот здесь www.oberon2005.ru - в аудиозаписи выступления Никлауса Вирта должны быть его слова в подтверждение.

Кстати, пара интересных ссылок, тем, кто не читал пока:

http://dpla.ru/wirth
Особенно поразило доктора Вирта то, что бортовая ЭВМ ДПЛА построена на простых байтовых процессорах 51 семейства.
...
И гости, и хозяева согласились с неразумностью использования каких-либо операционных систем в системах реального времени. Именно исключение операционной системы профессор Вирт считает своей основной заслугой при проектировании программного обеспечения беспилотного вертолёта.
...
В беседах обсуждались общие проблемы универсальных алгоритмических языков. Присутствующие разделили сожаление по поводу распространения в качестве фактического стандарта крайне неудачного языка программирования "Си". Признано целесообразным использование в будущих разработках беспилотных комплексов языка программирования ОБЕРОН, созданного профессором Виртом на основе "Паскаля" по методу элиминации. Доктор С.З.Свердлов выразил готовность реализовать компилятор с ОБЕРОНа для микроЭВМ 51 семейства.
.

http://alenacpp.blogspot.com/2005/09/blog-post_21.html
Как вы, наверное, заметили, Вирт несколько недолюбливает C и C++, противопоставляет им Оберон. Он создавал очень небольшой, строгий, не громоздкий язык, спецификация Оберона занимает всегдо 16 страниц, что гораздо меньше, чем спецификация C++, и Вирт этим гордится. Вообще поклонники Оберона очень часто противопоставляют Оберон и C++ [Oberon против С++, pdf]. И ставят такие акценты: возможно приведение типов - значит считай, что нет типизации. Можно объявить friend функции - значит считай, что нет инкапсуляции. И т.п. Имхо, неправильно это. Да я теоретически могу использовать приведение типов, но это не значит, что я это делаю постоянно. C++ предоставляет программисту свободу, за что я и люблю этот язык, но этой свободой надо пользоваться аккуратно.
Наверх
Сайт
den1
Среда 05.10.2005 11:37
ID пользователя #363
Зарегистрирован: Вторник 05.07.2005 16:47
Местонахождение: Россия. Москва.
Сообщений: 151
Dron написал(а) ...
Одна беда - это медленно. не хочется тратить свои гигагерцы на тупое переваривание одних инструкций в другие.
Это сейчас кажется, что медленее. Ненамного - можно оценить и медленнее, за счёт реорганизации. Процессоры, что идут на смену современным позволят применить иной подход к надёжности. Другими словами - уже существует запас по скорости. Сейчас наконец-то осознание надёжности начинает доминировать над скоростью. Я нашёл отличный ресурс с собирательной информацией о проектах ИИ, реализуемых на языках Оберон семейства - неожиданно много довольно интересных проектов.

Вобщем это всё я к тому, что пока цепочка приоритетов выстраивается примерно так:
скорость (было - небыстрые процессоры) ->надёжность (сейчас - относительно быстрые процессоры появились, однако бардак в структуре ОС, отсутствие хороших стандартов и сбои в работе ОС всех замучили) ->разумность (будущее - система работает надёжно и быстро, но хотелось бы, чтобы она ещё была и умной при этом ) ->повышение скорости размышлений умных систем и надёжности работы во время этих размышлений .
Наверх
Сайт
captain cobalt
Среда 05.10.2005 11:56

ID пользователя #12
Зарегистрирован: Воскресенье 04.07.2004 21:44
Местонахождение: /ru/perm
Сообщений: 144
Dron написал(а) ...
И еще... разделение user/system - помоему явно недостаточное... драйвер должен иметь доступ только к тем ресурсам, которые относятся к соответствующему оборудованию.
Некоторые устройства могут совместно использовать один вектор прерывания. Только драйвер устройства может узнать, относится ли прерывание к его устройству.

Если драйвер некорректно обрабатывает "ложные" прерывания, то он может повлиять на работу другого устройства. Защищаться от этого очень сложно и не ст'оит свеч.

bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом.
Наверх
Сайт
Переход на страницу  1 2 [3] 4 5 6  

Перейти:     Наверх

Транслировать сообщения этой темы: rss 0.92 Транслировать сообщения этой темы: rss 2.0 Транслировать сообщения этой темы: RDF
Powered by e107 Forum System

© OSRC.info, 2004-2010.
Авторские права на любые материалы, авторы которых явно указаны, принадлежат их авторам. По вопросам публикации таких материалов обращайтесь к авторам.
Авторские права на любые другие материалы принадлежат OSRC.info.
Сайт является помещением библиотеки. Копирование, сохранение на жестком диске или иной способ сохранения произведений осуществляются пользователями на свой риск.
При использовании материалов сайта ссылка на OSRC.info обязательна.