Текст книги "Вопросы истории: UNIX, Linux, BSD и другие"
Автор книги: Алексей Федорчук
Жанры:
ОС и Сети
,сообщить о нарушении
Текущая страница: 9 (всего у книги 28 страниц)
Для начала заметим, что Таненбаум, по его же словам, не ставил самоцелью создание именно микроядерной ОС: задачей его команды было просто построение системы надежной и безопасной. Другое дело, что решение этой задачи им всегда виделось именно в микроядерной архитектуре. Почему он и предложил таковое, причем в виде, кардинально отличающемся от всех предлагавшихся ранее реализаций.
Отличие первое – микроядро 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 буквально в последнее время пошёл по пути, от которого в восторге далеко не все применители, майнтайнеры и разработчики. И кто знает, не сделает ли это востребованными более иные операционки, как давно существующие, так и недавно рождённые. Однако это область, где кончается история и начинается политика, да ещё и приправленная предсказаниями и пророчествами.
Глава девятая. UNIX: хождения в народ
Как бы ни хотелось апологетам абстрактной свободы вообще и свободы софта откреститься от внешнего мира, с его презренными проприетарными разработками, результаты их деятельности сосуществовали с последними в едином пространстве. И сосуществование между этими общественно-технологическими системами было если и не всегда мирым, то обычно взаимонаправленным. И, подобно тому как Linux проникал в enterprise-среду, проприетарные UNIX'ы предпринимали попытки внедриться на пользовательские десктопы. Зачем и почему? Не трудно ответить.
Зачем нужен десктопный UNIXНа протяжении многих лет изо всех закоулков FOSS-мира слышались радостные вопли о UNIX'е с человеческим лицом. А с распространением Linux'а они стали перемежаться стонами о неготовности его к десктопу.
Зачем надо готовить Linux к десктопу? Исторический опыт, в том числе и отражённый в этой книжке, однозначно свидетельствует, что система, пришедшая в дома на пользовательские десктопы, неизбежно рано или поздно окажется в промышленном секторе.
Это хорошо иллюстрируется случаем с Windows: её 95-я инкарнация, появившись на пользовательских десктопах сначала как платформа для запуска игрушек, быстро проникла на десктопы и офисных работников. А с выходом сестры во интерфейсе – Windows NT 4.0 – оказалась и достаточно массовой средой для серверов рабочих станций. И с тех пор только укрепляла свои позиции по всем фронтам.
Напротив, enterprise-систему, на пользовательские десктопы не попавшую, столь же неизбежно ждёт увядание и в её основной, промышленной, нише. Забегая вперёд, скажу, что такова была судьба проприетарных UNIX'ов, таких как Tru64, HP-UX, Sun Solaris и ряд ныне забытых: иные мертвы, остальные существуют по инерции, на старых корпоративных контактах. И одна из причин том – недостаточное внимание десктопному сектору.
Как показывает история, системам, не преуспевшим на десктопах, мало чего светит и на противоположном полюсе пользовательского пространства – на всякого рода гаджетах. И тут достаточно вспомнить блистательный взлёт PalmOS и Symbian, не имевших никаких десктопных традиций – и их медленное, но неуклонное отступление под натиском Windows Mobile/CE, перешедшее затем в паническое бегство.
В меньшем масштабе история повторилось и при появлении нетбуков: модели с предустановленным Linux'ом быстро исчезли из прайс-листов. И не вследствие козней «Империи зла», а из-за отсутствия спроса. Отдельные же сохранившиеся реликты – не более чем платформы для установки пиратской Windows.
Подозреваю, что в ближайшее время следует ожидать и ещё одного витка истории. С появлением Windows 8, в том числе и в мобильной модификации, сдадут свои позиции гаджеты на Android'е, казалось бы, властвующем здесь безраздельно. Ибо длинные руки Microsoft'а дотянулись до святая святых без-win'ного мира: до ARM-процессоров. И тут магия имени сработает в очередной раз: потребители гаджетной продукции, снова предпочтут устройства с системой, хотя бы именем похожей на ту, что стоит на их настольных персоналках. А поскольку Android за всё время своего доминирования на гаджетах так и не порадовал, в отличие от былых PalmOS и Symbian, своими технологическими достоинствами, к ним присоединятся и многие из тех, кого действительно можно назвать пользователями.
Я далёк от мысли считать себя самым умным. И уверен, что сказанное выше задолго до меня понимали серьёзные дяди из фирм, разрабатывающих проприетарные UNIX'ы. Почему время от времени можно было наблюдать попытки экспансии последних на рабочие столы применителей, о чём нынче не очень любят говорить вслух – или просто напрочь забыли.
Блеск и нищета персональных Workstation'овВ этом разделе я расскажу о почти забытой истории – первых попытках «десктопизации» рабочих станций на RISC-процессорах под управлением проприетарных UNIX, происходивших в 90-х годах прошлого столетия. И надо сказать, некоторые предпосылки к тому имелись.
С одной стороны, в те времена былинные под UNIX развивалось некоторое количество обычных пользовательских приложений. Лучший текстовый процессор всех времен и народов – WordPerfect, замечательная электронная таблица Wings, в которой было реализовано большинство достижений, позднее приписанных Excel'у, Frameworks – единственная настольная издательская система, пригодная для вёрстки очень больших и очень сложно структурированных документов, – все они имели и версии под большинство проприетарных UNIX-систем. А уж что касается специализированных приложений, типа ГИС или имидж-процессоров, то они и разрабатывались под UNIX, а лишь затем портировались на Windows NT или получали аналогов под свободные UNIX-подобные системы.
С другой же стороны, в это время начала стираться грань между рабочими станциями и персональными компьютерами. С древних времён существует мнение, что рабочая станция – это что-то могучее и серьёзное, а персональный компьютер – слабое и легкомысленное. На рубеже 80-х и 90-х годов прошлого века оно имело некоторые основания: в рабочих станциях мощные высокоскоростные (в плане мегагерц) процессоры с RISC-архитектурой – в персональных компьютерах CISC-процессоры с тактовой частотой, дай бог переваливающей за 10 МГц. В «работягах» – мегабайты памяти, в «персоналках» – роковые 640 КБ, в лучшем случае до мегабайта, из которого треть невозможно использовать без дополнительных ухищрений. «Работяги» комплектуются мощными видеосистемами и крупноформатными мониторами высокого разрешения – в «персоналках» гнездятся CGA/EGA-адаптеры, к которым подсоединены соответствующие мониторы о четырнадцати дюймах. В рабочих станциях...
Да, собственно, на этом сравнение можно заканчивать: сказанного, казалось бы, достаточно, чтобы возмести между «работягами» и «персоналками» Железную Стену, разделяющую Мир Гуманного Воображения и Мир Страха перед будущим, как писали некогда классики. Не зря же приобщившиеся рабочих станций ласково называли персональные компьютеры «писюками» (причём вне зависимости от того, шла ли речь о собственно «плебейских» IBM PC или претендующих на аристократичность Macintosh’ах). Однако возгордились они рано, потому что ситуация менялась прямо на глазах.
Уже появление первых процессоров Intel 80486 с их внутренними RISC-инструкциями ознаменовало начало «стирания грани» между «персоналками» и «работягами» в номинальной вычислительной мощности, а Pentium и Pentium II процесс усугубили. И к рубежу тысячелетий можно было говорить о полном «замазывании пропасти», как бы ни пытался этому воспрепятствовать профессор Выбегалло. А поскольку в это же время происходило стремительное вымирание почти всех аппаратных платформ некогда легендарных рабочих станций, то ныне рабочая станция – это обычно, за исключением отдельных реликтов, тот же компьютер на базе архитектуры x86, что и «персоналка», и различия их – в сфере применения, определяющей детали конфигурации.
На моей памяти в 90-х годах прошлого века было три попытки проникновения рабочих станций на пользовательские десктопы. Первым на этом поле решил сыграть Hewlett-Packard со своей RISC-платформой HP-PA (Precission Architecture) и UNIX-операционкой HP-UX. Где-то в 1993-1994 годах появились сообщения о создании пользовательского варианта таких машин, в несколько урезанной (с точки зрения памяти и дискового пространства) комплектации, но зато по вполне «пользовательской» цене, сопоставимой со стоимостью тогдашних PC-брендов типа IBM или Compaq. В начале 1995 года машины эти демонстрировались на первой отечественной выставке UNIXExpo – и, должен заметить, впечатление производили изрядное, особенно в отношении 3D flying'а («облёта» виртуального трёхмерного ландшафта) и воспроизведения видео в реальном времени – на PC и то, и другое были ещё практически недоступно. Однако дальнейшего развития это начинание не получило, о причинах чего скажу чуть позже.
Вторым вступила в игру компания DEC с компьютерами на базе процессоров Alpha – первыми в те времена с точки зрения номинального быстродействия и к тому же первыми 64-разрядными. Эти машины были способны работать под управлением нескольких ОС – собственных VAX/VMS и DEC UNIX (Tru64 UNIX), а также Windows NT; существовал тогда уже и порт Linux под процессоры Alpha (кстати, вообще первый порт этой ОС на платформу, отличную от i386).
Компания DEC пошла другим путем, нежели Hewlett-Packard: она предоставила возможность сторонним производителям собирать машины на базе своих процессоров и материнских плат, прочие же компоненты Alpha-компьютеров к тому времени (на дворе был 1997 год) уже использовались стандартные, те же самые, что и для PC. Я знал две или три фирмы в Москве, собиравшие на заказ такие машины, также по цене, не превосходящей высококлассные персоналки. А комплектовались они, по желанию заказчика, любой из поддерживаемых ОС – правда, за отдельную мзду. Но не возбранялось приобретать их без ОС вообще, и устанавливать на них Linux своими силами.
В третьем раунде борьбы за пользовательские десктопы (гонг прозвучал в самом конце 90-тых) выступила компания Sun. Она также обратилась к услугам сторонних партнёров, в числе которых были и крупные российские компьютерные фирмы (например, R-Style). Они продавали самые обычные компьютеры Sparc, комплектовавшиеся из экономии стандартной для PC видеосистемой (а не собственным видеоадаптером 3D Creator, который, будучи и сам не дешевым, требовал дорогущего фирменного монитора) и IDE-дисками. В качестве предустановленной ОС на них имел место быть, разумеется, Solaris.
Все три проекта потерпели фиаско. Причин к тому было несколько:
• и дороговизна стульев (пардон, UNIX-десктопов) для трудящихся всех стран, привыкших уже к дешёвому и относительно качественному самосбору, утратив привычку «меряться брендами»;
• и неудачность комплектации: так, HP-PA в «пользовательском» исполнении скорее напоминал сетевую рабочую станцию, мало пригодную к автономному существованию; сфера же применения «самосборных» Sparc вообще оказывалась неясной – для пользовательских десктопов они были дороговаты, до серверов не дотягивали из-за дисковой подсистемы, а как серьезные графические станции не проходили из-за слабой видеосистемы;
• и постепенное прекращение развития большинства пользовательских приложений для проприетарных UNIX;
• и, наконец, просто утвердившаяся среди конечных пользователей привычка к Windows всякого рода.
Собственно, единственным из трех перечисленных проектов, имевшим шансы на успех, был вариант Alpha. Этому способствовала
• и политика, ориентированная на «конструктора-самоделкина» (вплоть до сборщика-индивидуала – такая возможность в Москве тоже имелась);
• и самая демократичная из всех трёх рассмотренных вариантов цена: когда в конце 1997 года я всерьёз размышлял о покупке такой машины «навалом», то высчитал, что она, при прочих равных, обошлась бы на 500 баксов дороже, чем самосборный компьютер на Pentium-II;
• и, наконец, наличие порта самой демократичной ОС – Linux – именно её устанавливали на «самосборные альфы» все известные мне их обладатели.
Конечно, можно было бы порассуждать на темы альтернативной истории – о том, что было бы, если бы платформа Alpha с ОС Linux на борту во второй половине 90-тых годов завоевала бы хоть какую-то популярность. Но история не имеет сослагательного наклонения. И единственное, что мы можем извлечь из нее, – это память об ошибках.
