Это делал каждый страстный любитель ОС: зарисовывал общую схему создания отличной ОС. Собирая все лучшие функции и свойства из любимых ОС и старательно избегая попадания в ловушки нелюбимых ОС. Воможно наши цели были непритязательны и мы всего лишь хотели немного перенастроенную версию существующей ОС. Но иногда в нас играют амбиции и у нас появляются большие креативные идеи сотворения революции в вычислительной технике. Давний читатель и автор на OSNews просто не может совладать с собой, так что он взялся не только выложить план, но и попытаться создать ОС своей мечты.
<br /><br />
Перевод: Роман <br />
<a href=http://www.osnews.com/story.php?news_id=9192>Оригинал </a> доступен на OSNews.com.

Это третья моя попытка все это записать. Первая была слишком подробной. Вторая по прежнему была слишком длинна. На этот раз я решил просто выложить свои идеи и постараться пояснить их просто и кратко. Более всего это похоже на обзор. Просто существует слишком много подробностей, чтобы пытаться выжать все их здесь. Многие из этих идей на самом деле не новы, о некоторых уже говорили до этого. Я просто пытаюсь понять, как их собрать вместе в единую систему.

Я работаю с компьютерами уже 30 лет и они, определенно, не стали ничуть проще. Фактически, я даже уверен в том, что они стали сложнее. Конечно, сегодня я могу делать такие вещи, о которых никогда и подумать бы не мог, но, похоже, что в то время как компьютеры стали в тысячи раз мощнее, они, в то же время, стали в тысячи раз сложнее.

Я опробовал практически все основные существующие операционные системы и я всегда попадал в какие-то сложные ситуации. Поэтому я не переставал думать, - "А что, если мы начнем с нуля и переосознаем то, как операционная система работает в целом?". Одной из первых операционных систем, с которыми мне довелось поработать, была Exec 8 на Univac 1108. В ней было реализовано большинство из используемых всеми основными современными операционными системами концепций. Сейчас вы, возможно, думаете, - "у нее не было графического интерфейса!". И это правда. Но я говорю о концепциях, лежащих внутри: процессах, файлах, о том как запускаются и взаимодействуют программы - вот об этих вещах.

Некоторое время я занимался мозговым штурмом и теперь я хочу выложить некоторые сложившиеся идеи. Сейчас это всего лишь идеи, некоторые или все из которых, возможно, вообще не будут работать. Возможно, что я не догадался до какой-то грани идеи, которая делает ее реализацию невозможной. Но я чувствую необходимость опубликовать их по нескольким причинам. Во-первых, я надеюсь, что когда они будут где-нибудь опубликованы, они перестанут кружить в моей голове, и я смогу поспать. Во-вторых, я не хочу ситуации вроде той, что была с Microsoft и SenderID.

И последнее, что я хотел бы сказать прежде чем начать. В качестве примеров я собираюсь упомянуть некоторое используемое мной ПО, такое как Linux, OpenBSD, gcc, K3B и прочее. Пожалуйста, не надо воспринимать это как унижение мной этого ПО. Просто я использую то, с чем лучше всего знаком. Я по прежнему считаю, что это отличное ПО, которое я использую каждый день и буду продолжать использовать в ближайшем обозримом будущем.

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

Простота

Я читал книгу "Better, Faster, Lighter Java" и, хотя автор говорит именно о Java, он мог бы так же говорить о вычислительной технике в общем.

Глава вторая называется "Сохраняйте " ("Keep It Simple") и поясняет ценность простоты. Она даже доходит до утверждений о том, что "простота может быть ключевой ценностью". Я надеюсь, что я смогу передать или поставить ссылку на первую часть второй главы, поскольку я думаю, что это применимо ко всему в вычислительной технике.

Так что, главная моя цель - сделать всю систему настолько простой и элегантной, насколько это возможно. Если сложностей не избежать, то их следует сохранить в одном месте и не позволять им инфицировать оставшуюся систему.

Плоские файлы и реляционные базы данных

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

Альтернатива хранению данных в плоских файлах (flat files) - хранить их в базе данных, чаще всего в реляционной базе данных. Хотя такой подход имеет некоторые преимущества перед плоскими файлами, используя реляционную базу данных, программе придется делать запросы к ней, а затем, как правило, преобразовыватьрезультат во внутренние структуры данных программы. Это особенно неудобно при использовании объектно-ориентированног программировани. Конечно, существуют и объектно-ориентированныебазы данных, но я не слышал, чтобы хоть одна из них нашла широкое применение, особенно из открытых, вроде MySQL или PostgreSQL.

Моя идея состоит в том, что необходимо сохранять данные на диске в родном объектном формате программы. Таким образом, вместо постоянных преобразований и интерпретаций данных, приложение может просто обращаться к такому объекту напрямую. А когда эти данные нужны в формате плоского файла, у вас будет приложение-конвертер (объект), которое сможет обращаться к внутренним данным и конвертировать их в файл или формат сплошного типа.

Например, предположим, что у вас на компьютере есть какие-либо сжатые (с помощью Ogg Vorbis или чего-то подобного) аудио объекты. И вы хотите зажечь аудио CD, который можно проигрывать в обычном плеере аудио CD. Вы создадите объект "список проигрывания" (playlist) и соедините его вывод (об этом позже) со входом объекта-конвертера Ogg Vorbis, а затем с объектом прожига аудио CD.

Где это хранится?

Еще одна проблема, которую я бы хотел решить, это "где находятся эти данные?" или "что я сделал с тем файлом?". Буквально вчера я искал электронную таблицу, в которой была некоторая необходимая мне информация. Одно время я держал ее на своей настольной машине. Потом, в течение прошлого года, я несколько раз менял эту машину и еще чаще переустанавлива различные операционные системы. Так что, в конце концов, я положил ее на свой файловый сервер. Но когда я начал искать ее, я не видел ее нигде. Хуже того, я не мог точно вспомнить как она была названа. Мне пришлось провести много поисков, прежде чем я окончательно понял дурацкую вещь. Я потратил, наверное, минут 20 на ее поиски и пока шло время я уже начал волноваться, что я потерял ее и думал когда же (если вообще?) я делал ее архивную копию. Да мне просто не нужен такой стресс!

Моя мысль по этому поводу состоит в удалении разделения между различными разделами, дисками, файловыми серверами, носителями CD, DVD и прочими. Больше никаких разделов C:, D: и E:. Никаких host7:/shared... Никаких монтирований CD носителей. Все это всего лишь одно большое объектное пространство хранения данных. Если оно находится вовне, машина может его найти. Если это публичная информация, то ее можно получить через Интернет. Если она хранилась на кассете, CD или на архивном DVD и этот носитель не находится в приводе, ОС скажет вам на каком носителе хранился этот объект, и вы сможете найти его и вставить, а приложение сможет продолжать работу даже не зная что произошло. Если в это время у вас нет доступа к носителю, у вас должна быть возможность остановить приложение прямо там, где оно находится и перезапустить его позже в точности в том же состоянии, когда у вас появится носитель (подробнее об этом позже).

**Похоже, что Google, Apple и другие придвигаются к тому, чтобы сделать это реальностью в существующих сегодня операционных системах, так что это хорошая новость.

Ссылаемся друг на друга

Еще одной проблемой плоских файлов является отсутствие информации о данных, хранящихся в файле. В BeOS была база данных, встроенная в файловую систему, что было приятной добавкой, и, как я понимаю, в Longhorn от Microsoft тоже должна была появиться какая-то разновидность встроенной базы данных до того, как ее отменили. Также я недавно обнаружил, что файловая система ext3 для Linux позволяет добавлять к файлам дополнительные "".

Но я хочу пойти дальше всего этого. Моя идея в том, что необходимо брать объект так, как он определен в сегодняшних языках, вроде C++ и Eiffel, и добавлять некоторую дополнительную информацию к нему. Когда был создан объект, кем был создан объект, его контрольная сумма MD5, биты защиты, обычные мета-данные, которые имеет файл сегодня в ОС - информацию такого рода.

В дополнение к этому, самым важным добавлением является таблица ссылок. Это таблица, которая поддерживается ОС, и хранит список всех объектов, связанных с этим объектом. Это дает нам несколько преимуществ. Во-первых, она позволяет легко находить любой объект, который связан с некоторым объектом. Во-вторых, она позволяет определить, какие из объектов сейчас используются в системе. Если ни один активный объект в системе не ссылает на данный объект (отличный от папки), то его можно вернуть в хранилище и удалить из активной системы.

Вернемся к музыкальному примеру, все музыкальные объекты будут ссылаться на исполнителя, который их создал. Все треки Beatles будут ссылаться на объект Artist Beatles. Объект Artist Beatles не будет специально ссылаться на песни, так как песни будут единственным типом объектов, которые смогут ссылаться на Beatles. Мы ведь не хотим раздувать объект Artist лишними ссылками на каждый возможный тип объектов, который может ссылаться на него. Мы даже не знаем, что из себя представляет каждый тип объектов, который может ссылаться. И даже если бы мы это сделали, нам бы пришлось менять класс Artist каждый раз при создании нового класса, который ссылается на класс Artist. Вместо всех объектов мы просто будем иметь общий список, который сможет указывать на любой тип объектов (класс "ANY" в Eiffel). Этот список будет автоматически поддерживаться ОС и обновляться во время работы программы. А когда вы захотите найти все имеющиеся у вас песни, созданные The Beatles, вы просто возьмете объект Beatles и поищете в списке его ссылок объекты класса "Track".

индекс статьи
страница 1 - текущая : страница без заголовка
страница 2 : страница без заголовка
страница 3 : страница без заголовка
страница 4 : страница без заголовка