Книга: Вопросы истории: UNIX, Linux, BSD и другие

Глава восьмая. MINIX 3: вторая жизнь

Глава восьмая. MINIX 3: вторая жизнь

Вступление

Кто же из линуксоидов не знает старика MINIX'а? Эта миниатюрная учебно-показательная UNIX-подобная ОС была создана четверть века назад профессором Эндрю Таненбаумом. Предназначалась она для вразумления студентов и приобщения их к идеалам UNIX на самой демократической платформе всех времён и народов – на IBM PC-совместимых компьютерах. Она уже фигурировала в нашей истории – в разделе о зарождении Linux. Ибо именно MINIX вразумил Линуса Торвальдса настолько, что он занялся сочинением своей терминальной программы, которой суждено было превратиться в Linux.

В том же разделе была описана и история ОС MINIX, сначала 1, а потом и 2, которую можно рассматривать как предысторию героини сегодняшнего рассказа. И которая завершилась анонсом MINIX 3, состоявшимся 24 октября 2005 года. Насколько повторяясь, подчеркну: это была не просто следующий релиз прежних MINIX'ов, а совершенно новая операционная система, и цифра «3» здесь – не номер версии, а часть её имени собственного. Таненбаум неоднократно подчеркивал, что сходство ее с предшественниками – лишь в первом компоненте названия, а различие между MINIX 1/2 и MINIX 3 не меньше, чем между Windows 3.1 и Windows XP.

Отныне MINIX 3 более не рассматривалась как учебно-показательная разработка, а позиционировалась как всамделишняя операционная система общего назначения, предназначенная, в перспективе, для широкого класса устройств, в том числе и встраиваемых. Это символизировалось и сменой правового статуса системы: отныне она распространялась под лицензией BSD.

Официальный сайт проекта – .minix3.org. Интересно, что буквально через несколько месяцев после анонса MINIX 3, 1 февраля 2006 года, Романом Игнатовым был создан русскоязычный ресурс по этой системе – minix3.ru, который успешно развивается и по сей день.

Отличие новой системы заключалось ещё и в модели разработки. MINIX 1 и MINIX 2 были фактически личными творениями Эндрю Таненбаума, а все дополнения к ней, вроде ставшего знаменитым патча Брюса Эванса (именно с его дополнением использовал MINIX Линус Торвальдс для работы над своей будущей операционкой), носили, в силу условий распространения, сугубо неофициальный характер.

К разработке же MINIX 3 Таненбаум с самого начала привлёк широкий круг участников – от своего соавтора по второму изданию учебника Альберта Вудхалла до студентов, аспирантов и сотрудников Университета Врийе, а также волонтёров. Состав участников проекта, по понятным причинам, был весьма текучим, и перечислить их всех поимённо не представляется возможным. Однако нельзя не отметить среди них наших соотечественников – упомянутого выше Романа Игнатова и Евгения Иванова.

О микроядрах

В MINIX 3 воплотилось представление Таненбаума и его соратников о том, какова должна быть современная операционная система. Однако, чтобы говорить нём, надо опять обратиться к истории – на этот раз к истории микроядерных операционок (краем этот вопрос был затронут в предыдущей главе).

Каждый школьник-линуксоид знает, что MINIX с самого своего рождения представляла собой микроядерную ОС. А вот какая он, эта микроядерность?

Для начала зададимся вопросом, а что же такое ядро вообще? Традиционно ядро определяется как программа, обеспечивающая взаимодействие всего остального системного и прикладного софта с аппаратной частью компьютера, и распределение его ресурсов между приложениями. В соответствие с этим ядро функционирует в отдельной области памяти, которая так и называется – пространством ядра. Память же, отводимая под все остальные программы, именуется пользовательским пространством; протекающим там процессам доступ в пространство ядра закрыт, и как-либо влиять на ядро, в том числе и негативно (вследствие ошибок в программе или злого умысла), они не могут. Но все процессы внутри пространства ядра взаимодействуют друг с другом, и ошибка в одном из компонентов может повлечь за собой тяжкие последствия, вплоть до краха системы.

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

С другой стороны, в понятие аппаратной части включаются и внешние, по отношению к системе процессор/память, устройства, от видеокарт и жестких дисков до принтеров, сканеров, сетевых адаптеров и многого, многого другого.

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

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

В результате ядра стали катастрофически увеличиваться в размерах. Что влекло за собой а) непроизводительные расходы ресурсов, в первую очередь памяти, и б) рост числа ошибок, обусловленный огромными объемами «ядрёного» кода, недоступного восприятию человека.

С первой болезнью научились бороться посредством модульного подхода: многие части ядра, обеспечивающие работу отдельных внешних устройств (т.н. драйверы устройств) или ядерных сервисов (в Linux их подчас также называют драйверами, например, драйвер файловой системы «имя рек»), могут не встраиваться жестко в исполняемый файл – образ ядра, а подключаться к нему в виде внешних модулей. И ныне ядра всех активно развивающихся UNIX-подобных систем, таких, как Linux или BSD, являются модульно-монолитными (подчас их для краткости называют и просто модульными).

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

Один из «косметических» вариантов решения проблемы был предложен Мэттом Диллоном и реализован им в системе DragonFlyBSD, о которой рассказывалось в предыдущей главе. Прошедшие с её появления годы доказали жизнеспособность этой реализации. Однако проблемы «большого» монолитного ядра это не снимало.

Для кардинального решения проблемы устойчивости ядра и были придуманы микроядра. Идея их – в том, чтобы, по словам Таненбаума, «вынести ядро за пределы ядра». То есть оставить в ядре только средства управления базовой аппаратурой, а драйверы устройств и сервисы выделить в отдельные программы, функционирующие в пользовательском пространстве памяти. При необходимости они обращаются к функциям ядра через специальные процедуры, но влиять на него каким-либо образом не могут. Такой подход приводит к повышению надежности системы, но снижает производительность, поскольку требует дополнительных накладных расходов.

Собственно, идея микроядра появилась очень давно, чуть ли не одновременно с самыми первыми UNIX'ами. Однако долгое время производительность машин не позволяла эффективно использовать микроядра в составе практически применяемых систем. Тем не менее, различных их реализаций было создано очень много. Время от времени то или иное микроядро пропагандировалось как основа операционной системы будущего, но удачных реализаций законченных микроядерных систем оказалось довольно мало.

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

Из свободных микроядерных реализаций наибольшую известность приобрело микроядро Mach, разрабатывавшееся вплоть до второй половины 90-х годов университетами – сначала Карнеги-Меллона, а затем штата Юта. Различные его версии в разное время составляли основу законченных систем, как свободных – BSD Mach (она же xMach) или Yamitt, так и проприетарных – NeXT и продолжившей её дело MacOS X. Все они имели в своем составе микроядро Mach, поверх которого запускалась драйверно-сервисная часть от ядра BSD, собранная в виде отдельного модуля.

Впрочем, из всех перечисленных систем только BSD Mach можно назвать по настоящему микроядерной, так как у него BSD-окружение ядра функционировало в пользовательском пространстве. И у NeXT, и у MacOS X BSD-окружение запускалось в том же пространстве ядра, так что микроядерными их можно назвать только по имени. А Yamitt в том виде, в каком я её наблюдал, просто не запускалась вообще.

Наконец, как мы видели, начиная с 1987 года и по настоящее время существует MINIX 1/2, основанная на собственной реализации микроядра. Каковую, в рамках очерченных для ннеё задач, можно считать удачной. А вот будет ли сопутствовать удача её потомку – микроядру нашей героини, MINIX 3, рассудит история.

Собственно о MINIX 3

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

Отличие первое – микроядро MINIX 3 самое микроядреное микроядро в мире. Из него вычищено все, кроме перечисленных ранее компонентов, таких, как обработчик прерываний, средства запуска и останова процессов, планировщик задач, механизм межпроцессного взаимодействия; правда, почему-то в ядро включён и один из сервисов – сервис часов. В результате все это хозяйство укладывается менее чем в 4000 строк кода – и только оно исполняется в пространстве ядра.

Второе отличие – драйверная и сервисная части, вычлененные из ядра, разделены между собой. В результате образуется знаменитая четырехслойная модель – метафора, в основании которой лежит ядро, надстраиваемое «драйверным слоем», которое, в свою очередь, перекрывается «сервисным слоем» и венчается «слоем пользовательских программ».

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

Наконец, четвертое, и, пожалуй, главное: сервер реинкарнаций. Это процесс, выступающий родительским по отношению к процессам всех драйверов и сервисов. Которые он запускает при старте, а в дальнейшем отслеживает состояние. Если процесс какого-либо драйвера или сервиса в силу неких причин самопроизвольно «умирает», он запускает его вновь. Если один из драйверов или сервисов начинает вести себя «нехорошо», сервер реинкарнаций в состоянии убить соответствующий ему процесс и тут же запустить его заново, обеспечивая, таким образом прозрачное для пользователя самовосстановление системы при отказе почти любого драйвера устройства или системной службы.

Очевидно, что такая, достаточно сложная, схема взаимодействия драйверов и системных служб не может не привести к некоторой потере производительности по сравнению с обычными системами, где драйверы и сервисы сосуществуют в едином пространстве памяти, вне зависимости от того, пользовательском или «ядерном» (а подчас еще и вместе с ядром). То есть – неизбежно должны вызвать снижение быстродействия системы. В каких масштабах? Исследования команды Таненбаума дают ответ на этот вопрос, и к нему я еще вернусь. Но сначала сделаю маленькое отступление на тему, что такое быстродействие операционной системы вообще и с чем его едят, то есть – чем меряют.

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

Однако имеет ли скорость загрузки системы к быстродействию ее при реальной работе? Отнюдь. Достаточно вспомнить, что MS DOS 3.3 на IBM PC/XT грузилась быстрее, чем любой Linux на любом супер-мега-Ivy Bridge. Перефразируя слова Сергея Образцова, измерение скорости загрузки ОС, строго говоря, даже к скорости загрузки ОС никакого отношения не имеет. Потому как зависит скорость загрузки в первую очередь от количества подгружаемых модулей и стартовых сервисов. Так что измерение её на самом деле меряет радиус кривизны рук пользователя, меру его лени или, напротив, количество свободного времени, которое он способен выделить на доведение системы до ума. А в последнее время, с распространением SSD-накопителей, скорость загрузки ОС вообще измеряет толщину кошелька пользователя или степень его жадности.

Не лучше и с тестами на реальных приложениях под разными ОС. Например, со столь любимым сравнением скорости обработки запросов web-сервером под Linux и FreeBSD, на основании чего делается вывод о превосходстве одной операционки над другой. Кстати, и не помню даже, кого над кем, да это и не важно. Потому что сразу же возникает закономерный вопрос: а что меряется в этом случае? Сравнительное быстродействие ОС? Или все-таки качество реализации конкретной версии Apache или, например, MySQL под ту и другую систему?

В общем, отдав в свое (не такое уж давнее) время дань увлечению всякого рода тестированием (это занятие было бы точнее классифицировать как пузометрию или … ну, то, что в этнографической литературе называют «сравнением мужей», подробно описанному в книжке: Мир FOSS. Заметки гуманитария), я пришел к стойкому убеждению, что в большинстве случаев это либо измерение аршином с точностью до ангстрема, либо, по изящному выражению Таненбаума, сравнение яблок с апельсинами.

И тем не менее, методика тестирования, предложенная командой Таненбаума, производит впечатление. Во-первых, она (команда) поставила себе целью оценить влияние на быстродействие системы одного-единственного фактора: выноса драйверов за пределы ядра и перемещения их в пользовательское пространство. И потому тестирование быстродействия MINIX 3 проводилось… на MINIX 2. Каким образом? Очень просто: в качестве сравнительных объектов использовались каноническая MINIX 2, с одной стороны, и она же, пересобранная с удалением из ядра драйверов устройств и еще некоторыми модификациями, что фактически превратило её в MINIX 3.

Во-вторых, в качестве тестов выполнялись процедуры, скорость которых действительно зависит от ОС исключительно или очень существенно: время исполнения системных вызовов, скорость чтения из файла и записи в файл, а также чтения непосредственно из блочного устройства (винчестера). Тесты с реальными приложениями тоже проводились – но предельно простыми (в смысле – мало подверженными посторонним по отношению к ОС влияниям): пересборка образа системы и набора контрольных тестов POSIX, а также обработка текстового файла утилитами типа sed, grep.

Результаты оказались парадоксальными. Разумеется, квази-Minix 3 проиграла MINIX 2 по всем статьям. Но давайте посмотрим, где и насколько.

По чисто «ядерным» тестам вроде исполнения системных вызовов отставание первой составило 12%, по тестам на файловых операциях и запросах к базам данных – 8-9%, по тестам на реальных приложениях – 6%. Последнее на современных машинах практически равнозначно отсутствию визуальной разницы вообще.

Чего нет у рыб?

Результаты тестов, о которых я только что говорил, были опубликованы в работе ? «A Lightweight Method for Building Reliable Operating Systems Despite Unreliable Device Drivers» ещё в январе 2006 года. Они показали, что катастрофического провала производительности при переходе к «чистому» микроядру не наблюдается. И, следовательно, идея, положенная в основу архитектуры MINIX 3:

   • имеет право на существование, и

   • заслуживает дальнейшего развития.

Так что дело оставалось за малым: воплотить идею во что-то, реально работающее. А до этого на момент публикации результатов тестов, MINIX 3 было также далеко, как омарам – нетрадиционным способом пробраться до города Пекина.

Обычно, когда описывают особенности некоей системы, разговор начинается с того, что в ней есть. Я же нарушу традицию, и расскажу о том, чего с MINIX 3 не было. И даже не в момент её анонса, а более чем год спустя, на рубеже 2006-2007 годов, когда мне довелось познакомиться с ней воочию – в актуальной на тот момент версии ?3.1.2.

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

Выдающийся русский филолог и писатель Лев Успенский (автор, в числе многого прочего, замечательной книжки «Занимательная топонимика») в своих воспоминаниях рассказывает, как в студенческие годы сдавал экзамен по какой-то биологической дисциплине. И на вопрос, вынесенный в заглавие этого раздела, ответил: «У рыб нет монокля и полного собрания сочинений Шпильгагена». А на уточняющий вопрос, знает ли он, чего ещё нет у рыб, сказал: «Знаю. Но монокля и собрания сочинений Шрильгагена у них точно нет». За что и был удостоен отличной отметки.

С MINIX 3 – случай аналогичный. Монокль к установочному ее диску не прилагается, и полное собрание сочинений Шпильгагена на нем не присутствует (да и вряд ли вообще существует в оцифрованном виде). Однако, как и с рыбами, список отсутствующих в MINIX 3 функций моноклем и Шпильгагеном далеко не исчерпывается.

Итак, в MINIX 3 отсутствовали:

   • поддержка огромного количества современного оборудования – от шины USB до интерфейса SATA, а видеоподсистема обеспечивала работу только в VESA-режиме;

   • возможность динамической линковки приложений с функциями системных библиотек;

   • поддержка каких-либо файловых систем, кроме своей собственной – даже доступ к ISO 9660 осуществлялся через устройство, которое у людей располагается обычно чуть ниже спины;

   • поддержка виртуальной памяти.

Ясное дело, что с прикладным софтом дело обстояло не лучше. В свежеустановленной системе имелся набор классических UNIX-утилит в реализации, примерно соответствующей стандарту POSIX, то есть далеко не самых богатых возможностями. Конечно, эту проблему можно было частично решить путём доустановки дополнительных пакетов (а их уже тогда было). Но вот с поддержкой устройств, файловых систем и прочего системного инвентаря рядовой пользователь ничего поделать не мог – это была вахта разработчиков.

И они стояли её доблестно: постепенно в MINIX 3 появилась поддержка виртуальной и разделяемой памяти, иных файловых систем, вплоть до подсистемы FUSE с экспериментальной поддержкой NTFS. Обрастала она и драйверами устройств, расширялся круг портированных приложений, в том числе за счёт задействования системы pkgsrc – той же самой, что была принята на вооружение в DragonFlyBSD.

Описывать хронологию всех этих изменений в деталях я не буду: заинтереосвавшийся читатель легко может отследить их по новостному разделу официального сайта или его русскоязычного его гомолога. На последнем, кроме того, можно видеть, как крепла поддержка в MINIX 3 русского языка – сначала усилиями отечественных добровольцев, а потом и на официальном уровне.

И ныне, пожалуй, в MINIX 3 не найти разве что, действительно, монокля и полного собрания сочинений Шпильгагена – большинство остальных атрибутов полноценной операционки в ней имеется. Что внушает оптимизм относительно его дальнейшего развития.

Заключение

Вот о будущем всех трёх родившихся на наших глазах операционных систем я и хотел бы сказать несколько слов под занавес. С одной стороны, и DragonFlyBSD, и MINIX 3 развиваются – может быть, не такими темпами, как хотелось бы их поклонникам, но поступательно и необратимо. Правда, о Syllable этого не скажешь – её жизнь протекает ни шатко, ни валко. Но относительный успех хотя бы двух систем из трёх, на фоне бурного развития Linux»а, показателен. Это при том, что разработчики Free- и других BSD тоже не сидят сложа руки.

С другой стороны, Год Великого перелома, о котором речь пойдёт в одной из следующих статей цикла, смешал карты: сначала интенсивная десктопизация Linux, а затем внедрение её инкарнации – Android»а , казалось бы, не оставил для всех других операционных систем места под солнцем.

Однако у этой медали, как ни странно, есть и третья сторона: Linux буквально в последнее время пошёл по пути, от которого в восторге далеко не все применители, майнтайнеры и разработчики. И кто знает, не сделает ли это востребованными более иные операционки, как давно существующие, так и недавно рождённые. Однако это область, где кончается история и начинается политика, да ещё и приправленная предсказаниями и пророчествами.

Оглавление книги