Привет.
Эта статья открывает цикл публикаций об операционной системе «Сивелькирия», на данный момент находящейся на раннем этапе проектирования и разработки. В статьях цикла будут подробно описаны системные проблемы популярных операционных систем и предложены пути их решения. Автор не ставит перед собой цели убедить кого-либо в чём-либо и сосредотачивается исключительно на описании предложенных решений ради извлечения пользы из обсуждения. Публикация будет вестись частями, поскольку объём полного описания выходит за любые разумные ограничения на размер хабростатьи.
Всем, кто заинтересовался, добро пожаловать под кат.
В наше время никого не удивишь заявлениями о разработке очередной операционной системы, которая должна стать лучше, удобнее и привлекательнее своих предшественниц и конкурентов. Существуют, как минимум, три крупных игрока на рынке ОС для персональных компьютеров и два — на рынке ОС для мобильных устройств. Несмотря на кажущееся разнообразие, нельзя не отметить определённого сходства между ними: хотя технологии и способы представления сервисов операционной системой разнятся, большая часть концепций и понятий остаётся неизменной при переходе от одной системы к другой.
Так, практически все популярные на данный момент операционные системы предоставляют поддержку общей функциональности на уровне реализации (окна, графика, файлы, сеть, оборудование), но не на уровне выражения понятий предметной области (сообщения чата, списки треков, счета за услуги). Существующие исключения (список контактов, буфер обмена, панель уведомлений) лишь подчёркивают правило. Техническая реализация (файлы, процессы, потоки) также во многом похожа.
Единицей использования возможностей компьютера во всех случаях является приложение, которое само решает, как направить имеющиеся ресурсы на достижение своих целей. Различные приложения связаны между собой лишь постольку, поскольку их разработчики позаботились о такой связи; зачастую программы, выполняющие близкие функции, не могут обмениваться данными, имеют разный интерфейс, используют различную терминологию и так далее. Такое обособление компонентов имеет сугубо технические корни, однако в итоге страдает пользователь. Компьютер из цельного инструмента превращается в нагромождение разнородных решений, а всеобщая совместимость, заслуживающая того, чтобы стать основопологающим принципом проектирования, остаётся лишь опциональной возможностью.
В настоящее время появляется всё больше решений, интегрирующих различные приложения и сервисы друг с другом. Производители программных продуктов, похоже, поняли, что сведение множества возможностей к одной удобной системе — это единственный путь к гармонии и порядку, позволяющий сделать жизнь пользователя лучше и проще. Тем не менее, во многих случаях слепая борьба несовместимых между собой программ, каждая из которых пытается объять необъятное, сменяется ещё более ожесточённой борьбой интеграторов, делающих всё возможное, чтобы не выпустить пользователя (и разработчика) за пределы своей платформы. Вместо того, чтобы объединять мир, интеграторы разделяют его, чтобы править.
Другим неизбежным аспектом мира отдельных приложений для решения конкретных задач является то, что каждое из приложений будет обладать своими достоинствами и недостатками, зачастую — неустранимыми. Выбор между удобством интерфейса, богатством функциональности и поддержкой конкретных операций настолько же неизбежен, насколько прискорбен. Если пользователю для достижения его целей требуются возможности, не предоставляемые в рамках одного приложения, это вынуждает его пользоваться более чем одним инструментом, тратя время и силы на переключение и перекачку данных.
Разработка программ — трудоёмкий процесс, и поэтому количество и качество функциональных возможностей в рамках любого продукта неизбежно будет ограничено. В то же время, львиная доля задач и проблем, решаемых разработчиками, уже решены в других продуктах; повторное использование этих решений вместо их повторной разработки высвободило бы ресурсы, которые можно направить на достижение других, более нужных пользователю, целей.
Наконец, поведение программ зачастую не подчиняется этическим нормам. Вместо того, чтобы помогать пользователю в работе, программы пристают к нему с назойливыми замечаниями и предложениями. Вместо того, чтобы выработать удобный способ предоставления услуг, основанный на взаимном уважении, они перемешивают рекламное содержимое с целевым. В результате складывается ситуация, в которой даже владелец устройства не контролирует его поведение.
Операционная система «Сивелькирия» задумана как решение описанных выше и некоторых других проблем. По замыслу и по дизайну она должна централизовано, уважительно, на взаимовыгодных условиях помогать достигать своих целей следующим категориям участников процесса разработки и использования ПО:
- Конечным пользователям — предоставляя полные, удобные, совместимые, переносимые и надёжные решения.
- Покупателям программных продуктов — предоставляя гарантии того, что все выбранные ими решения окажутся совместимы между собой и что использование одного конкретного решения, с одной стороны, не ограничит их возможности по использованию смежных продуктов, а с другой — не поставит их в ситуацию, когда из-за неустранимых проблем одной устаревшей системы придётся менять весь стек используемых технологий.
- Разработчикам — давая им возможность сосредоточиться на решении тех задач, ради которых затевалась разработка, а также извлечь из повторного использования кода максимально возможную пользу.
- Поставщикам программного обеспечения — открывая путь к выпуску на рынок ПО, применимого в максимально широком контексте и, как следствие, подходящего максимально возможному кругу пользователей.
- Поставщикам содержимого — позволяя сосредоточиться на предоставлении содержимого, которое автоматически становится доступным максимально широкому кругу лиц в максимально широком контексте, избежав необходимости разработки технических решений, повторяющих уже существующие.
Ниже будет описана архитектура такой операционной системы и то, каким образом она позволяет выправить ситуацию. Также в дальнейших статьях цикла будут подробно рассмотрены проблемы, которые она решает, чтобы показать, что они требуют системного подхода. Наконец, будут показаны достоинства и недостатки предложенного решения и то, каким образом оно может из концепции превратиться в готовый продукт.
Концепция ОС «Сивелькирия»
Операционная система «Сивелькирия» начинается с пересмотра основ, при котором часть общепринятых концепций подвергается устранению или замене. Следующие сущности, обычно составляющие основу операционной системы, не существуют в рамках ОС «Сивелькирия»:
- Приложение.
- Процесс.
- Файл как область данных на диске.
- Сквозная файловая система, навигация по которой ограничена лишь правами доступа.
- Командная строка как среда для запуска отдельных приложений.
- Универсальные скрипты.
- Доступность базового API операционной системы любому компоненту.
- Возможность прямого переноса стандартных библиотек большинства современных языков программирования. Как следствие, возможность прямого переноса существующего ПО с других операционных систем, кроме отдельных случаев.
- Поддержка языков программирования без объектной ориентации.
Этот список неполон. Он ни в коей мере не означает ограничения возможностей программиста или пользователя и лишь указывает, что в рамках ОС «Сивелькирия» те же цели достигаются иначе, нежели в большинстве ныне существующих операционных систем.
Отказавшись от этих устоявшихся сущностей, мы предполагаем выстроить операционную систему, основанную на следующих принципах:
- Операционная система «Сивелькирия» является объектно-ориентированной в том смысле, что она предоставляет объектные интерфейсы для выражения всех понятий предметной области, с которыми может работать ПО, выполняемое в рамках данной ОС. Все сущности, с которыми ведётся работа в рамках прикладных или системных программ, должны быть представлены в виде объектов, реализующих один или более интерфейсов, определённых операционной системой. Обмен данными за пределами этой структуры не допускается. Данные, получаемые из внешних источников, оборачиваются в данные интерфейсы в точке входа.
- Единицей распространения программного кода является модуль. Разница между модулями, предоставляющими прикладную функциональность, и модулями, выполняющими функции системного уровня, минимальна или отсутствует.
- Операционная система содержит библиотеку прототипов модулей, выделенных по функциональному признаку. Каждый прототип определяет, какие функции предоставляет модуль и какими входными и выходными данными он оперирует (в терминах объектных интерфейсов). Каждый модуль реализует один (и только один) прототип. Прототипы организованы так, чтобы каждый модуль выполнял одну (и только одну) функцию вне зависимости от происхождения входных и назначения выходных данных.
- Порядок загрузки и выгрузки модулей и вызова функций из них, компоновка модулей и их взаимодействие, организация, приоритеты и синхронизация потоков, время жизни объектов данных и способы их обработки определяются операционной системой. Реализации модулей и объектов данных не делают на этот счёт никаких предположений за пределами гарантий, дающихся в определении интерфейсов и прототипов.
- Каждому модулю доступны только те данные и способы взаимодействия с операционной системой, которые необходимы для выполнения его функции (определяемой прототипом). Ни один модуль не имеет доступа ко всем функциям операционной системы. Дублирование функций, уже возложенных на определённый прототип, в рамках модуля, относящегося к другому прототипу, не допускается.
- Разработка интерфейсов данных и прототипов модулей ведётся непрерывно, совместными усилиями разработчиков программ и разработчиков операционной системы. Интерфейсы и прототипы изменяются и дополняются по мере необходимости.
В следующих статьях цикла будет подробно показано, как эти и другие принципы будут применяться на практике. Полный текст доступен на сайте проекта.
Автор: Furax
