Хотелось бы знать, как народ отнесся бы к появлению проекта по созданию Руccкой
ОС. Причём не только русской, но и всего русскоговорящего населения?
Присоеденились бы вы к такому проекту?
Ответ на
»сообщение 2339« (Николай)
___________________________
Выскажу точку зрения дилетанта (я уже похожее здесь читал в менее категоричной форме): современная ОС, построенная правильно, должна состоять из ядра и виртуальной машины. Ядро оптимизировано для работы с железом, а виртуальная машина - для работы с прикладными программами. Все очень просто!
Не все так просто. :) Но раз затронули этот вопрос, давайте немного порассуждаем.
Думаю, имеет смысл во избежание сумбурности обсуждения (хотя для мозгового штурма сумбурность бывает полезной) каким-то образом очертить рамки обсуждения. Задать
аксиоматику. Или ориентиры, к которым можно время от времени обращаться.
В области ОС (так уж сложилась жизнь) многое крутится вокруг UNIX. Хотя что есть UNIX, а что не UNIX -- вопрос непростой. Действительно, если двигатель от "Мерседеса", а все остальное от "Запорожца", то назвать "Запорожцем" полученный автомобиль как-то неправильно. И наоборот.
В сфере ОС уже устоялись определенные базовые ценности и стереотипы. Как и любые стереотипы, они позволяют выживать "популяции", но иногда приходит время, когда стоит на стереотипы взглянуть критически. На предмет их ломки и смены. Ломать -- дело нехитрое, а строить новое надо, понимая зачем оно нужно и какую пользу приносит.
К чему я веду? Предлагаю взять за основу обсуждения теоретико-практический базис в сфере ОС. Как вариант, предлагаю классическую книгу Э.Таненбаума и А.Вудхалла "Операционные системы. Разработка и реализация" (2007):
http://www.ozon.ru/context/detail/id/3092042/
Разбор нутра UNIX на примере MINIX 3 с попутным изложением подходов в других ОС -- вполне подходящая "печка", от которой можно плясать в обсуждениях. Воспринимая сказанное авторами не как истину в последней инстанции, но как вполне устойчивые (и во многом принятые) взгляды на суть современного ОСестроения.
Теперь в отношении виртуальных машин. В упомянутой книге есть специальная часть, посвященная этому вопросу (1.5.3 "Виртуальные машины"). Сразу скажу, что изложение там идет, что называется, "галопом по Европам", но некое представление для обсуждения дает. Теперь оставим в стороне Таненбаума (но у кого книга под рукой, стоит для сравнения в нее посмотреть).
Виртуальная машина ОС и виртуальная машина языка программирования -- понятия близкие, но
разные. Оба отвечают за абстрагирование от нижележащего исполняемого слоя (будь то оборудование, другая виртуальная машина или иное ПО). Предполагается, что конструкция виртуальной машины напоминает конструкцию реального оборудования (в частности, процессора), т.е. снаружи это выглядит как черный ящик с интерфейсом в виде набора команд (инструкций) и правил их использования.
Ранее (
»сообщение 2288«) я уже говорил о том, что ОС и язык программирования (точнее, его реализация -- система программирования) в пределе могут считаться одной и той же сущностью. Важное утверждение. Будем считать это некоей гипотезой и посмотрим, что она может нам дать для понимания.
В самом деле, любая ОС является программной системой (как и система программирования). Она имеет дело с унифицированным управлением задачами и распределением ресурсов (чем занимаются многие системы программирования). У языка программирования (его реализации) есть ядро -- исполняющая система (run-time system). В этом смысле ОС и язык близки (для простоты изложения буду иногда приравнивать язык к его реализации; надеюсь, из контекста будет понятно, что в действительности подразумевается).
ОС работает не только сама по себе, но и обеспечивает взаимодействие с ней двух основных сущностей (людей и программ). Про третью сущность -- внешнее оборудование -- на время забудем, приравнивая ее к программам (драйверам).
Взаимодействие с ОС обусловлено разными языковыми слоями ОС:
* программный (API, процедурный интерфейс системных вызовов),
* командный (CLI, command language interface),
* пользовательский (UI, реализуемый обычно через GUI).
Первые два относительно легко поддаются четкому и однозначному описанию. С третьим – напряженка. "Плавает" и отражается в документации весьма неоднозначно. Собственно, исходя из этого можно делать UNIX-подобную ОС (она будет UNIX или нет?) в любой комбинации этих языковых слоев (например, реализовать только командный или программный).
Если мы взглянем на язык (систему программирования), то увидим, что аналогом командного интерфейса ОС является сам язык, а пользовательского -- интерфейс инструментальной среды (IDE). Программный же интерфейс для языка обычно требуется, если обеспечивается API-интеграция с другим языком (когда язык является "сервером", которого вызывает язык-клиент).
Идем дальше. Взглянем на две ОС, которые точно можно считать разными по архитектуре: UNIX и Oberon System.
В первой ОС главной единицей исполнения является процесс. Во второй – модуль (далее под этим словом подразумевается модуль в понимании модульного программирования, точнее, языков Modula-2 и Oberon). Процесс в UNIX – это не языковое понятие. У него нет конкретного отображения на языковую сущность (это и хорошо, и плохо). Модуль же имеет однозначный аналог в языке (Обероне) – сущность с тем же названием "модуль" (из-за чего нередко происходит терминологическая путаница – о языковом модуле идет речь или об исполняемом). Это также и хорошо, и плохо.
Модели Вирта оказалось достаточно, чтобы соединить язык и ОС. Т.е. представить ОС как "обычную" программную систему, реализованную на данном языке, причем оставаясь в рамках языка (вспомним, модуль в системе Oberon – это почти процесс в UNIX). Почему "почти"? Потому что он не является изолированной сущностью, работающей только в своем адресном пространстве, а связан и взаимодействует с другими сущностями –- другими (загруженными и исполняемыми) модулями.
Основу основ любой ОС составляют средства мультипрограммирования (multiprogramming, multitasking), т.е. средства диспетчеризации (планирования) процессов (задач). Думаю, стоит даже считать UNIX'ом любую ОС, которая использует именно UNIX-механизм мультипрограммирования (вне зависимости от реализации языкового слоя – программного, командного, пользовательского).
Вспомним классику: монитор Хансена-Хоара. Это и есть специальный модуль в понимании модульного программирования (вынесенный на уровень языка), который обеспечивает основу мультипрограммирования. Собственно говоря, начиная с языка Modula (мониторы, модули устройств), Вирт уделял свое внимание, прежде всего, этому аспекту – сведению мультипрограммирования (т.е. задач ОС) к уровню языка программирования. В Modula и Modula-2 были эксперименты с сопрограммами (заимствованными из Симулы). В Обероне была уже несколько иная модель, но сохранившая идею совмещения понятий языка с понятиями ОС.
К чему столь подробное изложение? Если для исполнения языка программирования на разных процессорных архитектурах совсем не обязательно иметь виртуальную машину (работы М.Франца по динамической кодогенерации на основе семантического словаря – лишь один из альтернативных вариантов решения), то несложно сделать вывод о том, что и ОС совсем не обязательно реализовывать через виртуальную машину (с сохранением и приумножением всех достоинств абстрагирования). Вполне вероятно, что ее (точнее, работу с ней) можно представлять в виде особого языка (совсем не Оберона) или связки языков, близких по классификации именно к языкам программирования.
Отсюда также следует, что взгляды на то, что есть ядро ОС, что есть микроядро, экзоядро и т.д. (гранулировать можно по-разному), могут быть пересмотрены с учетом усиления возможностей контроля сложности ОС средствами языка высокого уровня.
В конечном итоге ОС –- это программная система. И она должна подчиняться законам конструирования программных систем. Можно, конечно, считать архитектуру ОС наиважнейшей и игнорировать конкретный язык реализации. Но можно и не игнорировать. Второе направление (наличие языкового контроля) представляет особый интерес (не забывая, разумеется об архитектуре ОС).
Языки Си и Оберон сближает то, что оба -- компактные языки, которые достаточно полноценно реализуют фон-неймановскую архитектуру (без сложных наворотов). Т.е. сами по себе выступают в роли "виртуальных машин". Оба являются языками реализации соответствующих ОС: UNIX и Oberon System. При этом мы (участники проекта "Роса") накопили достаточно информации о недостатках той и другой связки "язык - ОС". Дело за "малым" -- тщательно и критически переработать накопленную информацию (а также раздобыть уточняющую) и попробовать найти новое решение. Желательно (для преемственности), чтобы оно позволяло понятным образом трансформироваться в предельные сущности -- процессы UNIX и модули Оберона.
Ответ на
»сообщение 2342« (Lisp Hobbyist)
___________________________
Вообще-то сам Вирт неоднократно в своих статьях "наезжал" на мэйнстрим.
Приведите, пожалуйста, примеры его "наездов" и суть своего несогласия (обоснованного, надеюсь) с этими "наездами".
Кроме того, в науке есть понятие "бремя доказательства". Раз уж Вирт выдвинул тезисы о том, что "необходимый признак ЯВУ --- машинная независимость" и "минимализм в определении ЯП --- хорошо", то ему и предстоит это доказать, причем обязательно.
Прежде чем переходить к каким бы то ни было доказательствам, неплохо бы сформулировать
аксиоматику. Что есть "
машинная независимость"? Разные люди понимают это по-разному. Если Вы можете сформулировать, будет интересно посмотреть. А заодно убедиться в том (уж не знаю как), что Вы и Вирт понимаете это одинаково. А то это будет напоминать сравнение процессоров разных архитектур по тактовой частоте.
В отношении "однозначности" семантики я Вам привел примеры промышленных международных стандартов, познакомившись с которыми, можно понять, что "однозначность" -- это стремление к некоему идеалу, который, увы, для описаний подобных языков недостигнут. При этом запутанность/туманность стандартов много выше описания Вирта (сугубо мое мнение).
Можно ли однозначности семантики вообще достичь, если в описании используется
естественный язык (английский, например)? Философский вопрос. Но думаю, скорее всего, невозможно.
Так что Ваши претензии к лаконичному описанию Виртом классического Обероона в этом плане выглядят "наездами".
Но так уж получилось, что мне довелось найти в этом обосновании немалую дырку (впоследствие оказалось, что еще раньше ее нащупали авторы Oakwood guidelines). Ничего личного, обычные научные разборки.
И что это за "дырка"? Укажите конкретно.
