CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
24.05.2016

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Заметки

Заметка не про Linux

CITKIT.ru
Цикл "Операционные системы:
Ностальгия по будущему
"

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

В этой заметке я хочу поговорить о двух вещах: (1) чем проектирование и разработка операционных систем в годы моей молодости отличается от сегодняшних реалий, и (2) так ли уж действительно грустно обстоит дело с перспективами новых операционных систем. Еще раз хочу оговориться, что я выражаю только свою собственную точку зрения, не обсуждавшуюся и не согласованную даже с моими коллегами.

Работа молодости нашей

В некоторых комментариях к первой заметке меня укоряют в унылости и ностальгии по молодости. Да, возможно, текст получился не самым веселым. Но ведь, с другой стороны, и тема не юмористическая. Наверное, с окончательным (и уже давнишним) выходом из щенячьего возраста у меня исчез щенячий восторг по любому поводу, что кажется мне вполне естественным. Что же касается ностальгии по молодости, то пусть любой человек моего возраста бросит в меня камень, если он не вспоминает с сожалением о прошедших годах. Хотя бы потому, что в двадцать лет у человека вся жизнь впереди, а под шестьдесят большая часть ее уже прожита.

Однако поверьте, я сожалел не о молодости, а о той работе, в которой мне довелось участвовать, и о том коллективе, в котором мне посчастливилось работать. Как говорилось в первой заметке, я начал свою профессиональную карьеру в знаменитом Институте точной механики и вычислительной техники (ИТМиВТ), институте, где под руководством академика Сергея Алексеевича Лебедева были созданы лучшие советские универсальные компьютеры БЭСМ-1, М-20, БЭСМ-6 и многие другие машины специального назначения.

Вместе с несколькими своими однокурсниками с мехмата МГУ я попал в пятую лабораторию ИТМиВТ, которой тогда руководил Лев Николаевич Королев (напомню, что речь идет о 1971 г.). Пятая лаборатория работала совместно с первой лабораторий, которая была главной в институте по проектированию универсальных ЭВМ. Руководил лабораторией Владимир Андреевич Мельников, а работали в ней совершенно замечательные, уникальные инженеры Андрей Андреевич Соколов, Владимир Иванович Смирнов, Леонид Александрович Зак и многие другие.

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

Как говорилось в первой заметке, в начале 1970-х гг. первая и пятая лаборатории ИТМиВТ начали проект AC-6, и все вновь поступившие в институт молодые сотрудники были к этой работе привлечены. После выполнения первых производственных заданий по написанию интерпретаторов новых процессоров мы досконально знали особенности этих машин, поскольку это происходило параллельно с разработкой архитектуры и системы команд при нашем посильном участии. Интерпретаторы поначалу делались для того, чтобы можно было делать ассемблеры и компиляторы для новых машин, не дожидаясь появления аппаратуры.

После начала работ по проектированию и написанию операционной системы для центрального процессора (ЦП) АС-6 мы решили попытаться довести интерпретатор ЦП АС-6 до такого уровня, чтобы можно было прямо-таки на нем полностью отлаживать операционную систему. Для этого были реализованы все привилегированные команды, а затем вне интерпретатора писались эмуляторы разных частей новой ОС, в окружении которых разрабатывались и отлаживались другие компоненты операционной системы. Постепенно эмуляторы заменялись на код ЦП АС-6, и, в конце концов, мы получили полное ядро операционной системы, с использованием которого на интерпретаторе можно было пропускать реальные задачи (например, запускать компиляторы). Конечно, в этом режиме система работала страшно медленно (с замедлением от 400 до 1000 раз), но все-таки можно было отлаживать и тестировать ее целиком. И здесь нас, безусловно, выручила только БЭСМ-6, лучшая ЭВМ всех времен и народов.

Интересно, что после этого этапа переход на реальную аппаратуру ЦП АС-6 прошел на редкость легко (не считая того, что поначалу сама аппаратура работала с ошибками и крайне ненадежно, из-за чего временами нам приходилось возвращаться в среду интерпретатора).

В одном из комментариев что-то бормоталось про «никому не известную АС-6». Да, эта система не слишком известна в широких массах, но на ней многие годы работал Советский центр управления полетами. При ее использовании был выполнен исторический советско-американский проект ЭПАС (экспериментальный полет «Апполон-Союз») и ряд более поздних космических полетов.

В работе над АС-6 инженеры и программисты совместно увлеченно трудились, потому что, во-первых, это было очень интересно, во-вторых, мы чувствовали, что во многих вещах являемся первопроходцами (не только в СССР, а во всем мире; например, в АС-6 на много лет раньше, чем в других системах была реализована идея NUMA: в системе имелась единая адресация основной памяти всех входивших в нее компьютеров), в-третьих, система была действительно нужна для развития области управления космическими полетами, и мы чувствовали ответственность перед своими будущими пользователями.

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

Легко видеть, что подобные условия выполнения программно-аппаратных проектов теперь просто невозможны. Во-первых, наступило время специализации, и процессоры все больше изготавливаются не теми компаниями, которые делают операционные системы. Во-вторых, жизнь все более убыстряется, и уже давно нет времени на сравнительно неторопливое совместное проектирование «железа» и системного «софта». Конечно, гораздо быстрее портировать на новую аппаратуру какой-либо вариант UNIX, что теперь, как правило, и делается (безусловно, при таком подходе невозможно использовать в ОС все возможности аппаратуры). В результате, как говорилось в первой заметке, исчез спрос на новые идеи в области операционных систем, и в этой области образовался застой.

Туманные, но все же перспективы

Засилье UNIX в мире операционных систем (с вашего разрешения я абстрагируюсь в этой заметке от ОС семейства Windows, поскольку это одноплатформенные системы, и вообще здесь речь идет не о противостоянии UNIX и Windows) напоминает мне засилье SQL-ориентированных СУБД в мире баз данных. Словами одного из комментаторов предыдущей заметки, и то, и другое – это старая добрая «кухонная плита», которая является вполне функциональным устройством, и если в чем и нуждается, так это в профилактическом обслуживании.

Тем не менее, в области баз данных исследовательская работа просто кипит. Ежегодно печатаются сотни исследовательских статей с описанием новых методов, алгоритмов и реализованных прототипов систем. Конечно, частично результаты этих работ рано или поздно используются компаниями-производителями основных SQL-ориентированных СУБД – IBM, Oracle, Microsoft и некоторыми другими. Но многие результаты, как казалось еще несколько лет тому назад, просто пропадали, не находя применения в реальных производственных системах (неважно, проприетарных или с открытыми кодами).

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

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

Основное отличие упомянутых систем от традиционных СУБД состоит в том, что они являются специализированными, а не универсальными. Каждая из них ориентирована на сравнительно узкий класс приложений, обеспечивая приложениям этого класса производительность, существенно превосходящую ту, которую можно получить при использовании универсальных СУБД. Специализированные СУБД получаются на порядок проще универсальных. По мнению Стоунбрейкера (которое кажется мне вполне справедливым), сегодня новые проекты в области системного программирования являются оправданными только в том случае, когда можно получить работоспособную, пригодную на производственного использования систему не дольше чем через полтора года после запуска проекта. При ориентации на специализированные системы это реально.

Так вот, я думаю, что и в области операционных систем можно попытаться заняться разработкой специализированных систем. На первый взгляд, полная функциональность универсальных ОС не требуется не только во встраиваемых системах, но и в операционных системах, которые используются в узлах вычислительных кластеров и вычислительных облаков. Здравой идеей, как мне кажется, является разработка специализированных ОС для поддержки новых систем управления данными (конечно, никто не решится трогать платформы традиционных серверов баз данных).

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

Более того, ориентация на быструю разработку специализированных систем несколько выравнивает шансы российских и зарубежных разработчиков. Понятно, что в России вряд ли удастся найти инвесторов для основания компании-стартапа, которая будет вести такую разработку. Значит, нужно использовать подход open-source с формированием международных команд разработчиков. А желающие найдутся – в мире есть много грамотных молодых людей, которым очень хочется попробовать сделать свою систему.

На всякий случай хочу еще раз уточнить. Я говорю о небольших специализированных системах. Любая попытка затеять разработку с нуля новой универсальной ОС (даже опирающейся на совершенно замечательные идеи) практически обречена на провал. Linux здесь является исключением, а не правилом. Одаренный и работоспособный Линус Торвальдс начал свою работу в нужное время (начало эпохи Internet) в нужном месте (Хельсинки – одной и центральных точек европейского Internet) на правильной основе (стандартной архитектуре UNIX). И даже при этом потребовалось пятнадцать лет, чтобы довести ядро системы до приемлемого уровня зрелости. А правило подтверждает достаточно бесславный (?) конец многих интересных проектов 1980-х гг., таких как упоминавшийся в предыдущей заметке проект КЛОС и французский проект Chorus, о которых, тем не менее, следовало бы поговорить подробнее.




Комментарии

Страницы комментариев: 1 :: 2 :: 3 :: 4 :: следующая

tweak, Wed Apr 8 22:54:24 2009:
2Сергей> Меня как пользователя вполне бы устроило для начала, чтобы в существующих пользовательских ОС была реализована tag file system. Директории и иерархии - это какой-то прошлый век, честное слово. Ну сколько можно!

при том, что все отдельные "запчасти" существуют сами по себе, в виде набора концепций: файлы-объекты процессов и пространства имён процессов-файлов в Plan 9; content-addresable memory в git VCS (файлы-блобы, адресуемые по sha1 и "индексный" файл) git shelve, hg shelve; "семантический десктоп"; вики-ссылки, гипертекстовые ссылки "на содержимое" в Xanadu Теда Нельсона и Purple numbers (из более работающего NLS/AUGMENT Дуга Энгельбарта).

Осталось только объеденить это вместе единым API, что-то среднее между ФС в Plan9 и D-Bus


> Судя по комментариям, и ntfs, и ext3fs имеют для этого все необходимое. Так за чем дело стало? Вот она, зона ближайшего развития.

да-да, кулер тоже вертолёт, только маленький ещё. Reiserfs3 и Reiser4fs с файлами-директориями и тегами и категориями гораздо ближе к идеалу.
Вопрос про "tag fs" -- это больше вопрос из области "семантический десктоп" и его API. Хотя не вижу причин не сделать его параллельно существующему ФС пути: есть у "объекта" 2-3 пути: в ФС "физический", в логической "семантической" VFS "логический" путь и объекты системы/URL/GUID. Нужен всего лишь демон, который будет поддерживать связи между объектами, доступными по разным путям, и семантическая обвязка.
Alexa, Wed Feb 11 15:12:16 2009:
Автор плачется, что нет нормальных разработок.
Я не раз плакался коллегам и начальству, что можно сделать свою систему АСУ, круче, легче, дешевле.
Начальник сказал, что "наверху" уже все бабки поделили, часть от заплаченных за забугорное ПО - тоже (откат - самая важная вещь в нынешнем бизнесе), а мне не следует лезть в дела, где я не шурупаю...
аноним, Sat Jan 17 20:35:40 2009:
2Сергей, суббота, 17 января 2009 г. 05:30:52:
Может Вам предоставить возможность вручную собирать файл по кластерам, разбросанным на диске??
Сергей, Sat Jan 17 05:30:52 2009:
Меня как пользователя вполне бы устроило для начала, чтобы в существующих пользовательских ОС была реализована tag file system. Директории и иерархии - это какой-то прошлый век, честное слово. Ну сколько можно!

Судя по комментариям, и ntfs, и ext3fs имеют для этого все необходимое. Так за чем дело стало? Вот она, зона ближайшего развития.
Владимир, Thu Dec 25 08:28:24 2008:
Вряд ли отсутствие принципиально новых операционок происходит от отсутствия романтиков программирования. Может быть дело в том, что существующие концепции файловых систем/иерархии, процессов, тредов - в самом деле наиболее удачно подходят к существующей аппаратуре ? Т.е. можно добавить или изменить что-то, но принесёт ли это СУЩЕСТВЕННОЕ улучшение жизни программистов ? Будут ли эти нововведения стоить того, чтобы переписать существующий софт под новые идеи ?

Ведь просто новые операционки (на старых принципах) создаются часто и много: во первых, для встраиваемых устройств, во вторых - просто энтузиастами. Я, например, лет 5 назад переписывался с человеком, который пытался (и даже неплохо получалось) создать операционку для тяжелой математики. Т.е. ему было важно получить минимум прерываний/переключений, максимум свободной памяти и предельно высокую скорость работы с HDD (вплоть до собственной файловой системы, хотя я вообще не уверен, что там было что-то похожее на файловую структуру).

Так же точно периодически создаются новые языки программирования, но в массы они опять же не уходят - вероятно, по той же причине - нет серьёзного качественного прироста для широкого круга задач.
аноним, Wed Dec 24 12:14:35 2008:
Я могу ошибаться, но мне кажется что в айбиэмовских iServer (развитие платформы AS/400) база данных DB/400 интегрирована в операционную систему. Файловая система при этом то ли отображается, то ли реально хранится в базе данных.

А NTFS в виндах (разработанная отнюдь не микрософтом, а DEC) тоже во многом база данных, хотя это не так очевидно, например она поддерживает транзакции.
Алексей Федорчук, Thu Dec 4 13:32:11 2008:
К анониму

Прекратите читать не про Linux.
аноним, Thu Dec 4 12:37:01 2008:
К автору. Прекратите в заглавиях своих опусов использовать слово Linux.

Я равнодушен к Linux.
Как я равнодушен к Linux.
Это не об Linux.
Заметка не про Linux.
И вновь заметка не про Linux.
Не о Linux.
И кто такой этот Linux.

Право же, смешно читать.
Всё.
аноним, Wed Nov 19 12:09:48 2008:
"Следующий большой прорыв"... я не про файловую систему а-ля СУБД - в этом случае сохраняются отдельные ресурс ОЗУ и ресурс ФАЙЛЫ. Я про ПАМЯТЬ вообще. В СУБД нет ресурса "ОЗУ" и нет ресурса "ФАЙЛЫ". вместо этого там другой ресурс, решающий вопрос хранения данных - например в РСУБД это ресурс "ТАБЛИЦЫ", который ОДНОВРЕМЕННО служит и для и оперативной обработки, и долговременного хранения данных.
veter, Mon Nov 17 12:54:54 2008:
"Было также предложено вводить триггеры - программы. которые срабатывали бы при обращении или изменении файлов, как это делается в БД для записей. Вот этого пока нету."

Еще как есть. Механизм inotify встроен в ядра линукса ветки 2.6. См. пакет incron ("cron-like daemon which handles filesystem events").

Страницы комментариев: 1 :: 2 :: 3 :: 4 :: следующая

Комментарии заморожены.

Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds