Текст книги "Вопросы истории: UNIX, Linux, BSD и другие"
Автор книги: Алексей Федорчук
Жанры:
ОС и Сети
,сообщить о нарушении
Текущая страница: 7 (всего у книги 28 страниц)
Теперь оставалось только обеспечить загрузку новообретённой системы. Загрузчиком её являлся самый обычный GRUB. И потому посредством стандартного текстового редактора (в качестве коего выступал jed – к счастью или несчастью, но никакого vi не было и в помине) правился его конфигурационный файл.
Затем система перезагружалась (обязательно с помощью комбинации из трех пальцев, но никак не Reset’ом) с первой дискеты и при появлении меню GRUB’а переводилась в режим его редактирования. Тут следовало указать новый корневой раздел, после чего сделанные изменения изменения записать в MBR. После этого, вынув дискету, можно было загрузить AtheOS уже нормальным образом. При этом система практически мгновенно переходила в графический режим, и после авторизации перед глазами возникал рабочий стол с пузырчатыми обоями, в углу которого сиротливо ютились пиктограммы для запуска программ: файлового менеджера, браузера, терминала, утилиты настройки (Prefs) и пары-тройки системных мониторов.
Штатный набор приложений выглядел бедновато, но мог быть расширен за счёт дополнительных пакетов, правда, тоже не очень многочисленных. Это выполнялось в два приема: сначала пакет распаковывался из архива, а потом регистрировался в базе данных специальной утилитой. В отличие от всех тогдашних UNIX-подобных систем, дополнительные пакеты устанавливаются каждый в свой подкаталог каталога /usr, а не раскидывал свои файлы по древу многочисленных bin’ов, lib’ов и прочих man’ов. Не будем обсуждать, хорошо это или плохо – но ныне такой подход практикуется в PC-BSD и некоторых дистрибутивах Linux.
Что еще остается добавить? Утилита конфигурирования Prefs позволяла настроить разрешение экрана и глубину цвета, выбрать экранные шрифты (в качестве системных используются шрифты True Type) и раскладку клавиатуры – они представлены для большинства европейских языков, хотя русского среди них не было, как и кириллических экранных шрифтов, хотя русская locale имелась.
Не знаю, удалось ли мне в своём рассказе передать то чувство лёгкости, быстроты, компактности, аккуратности интерфейса, простоты установки и использования, которое испытывал при общении с AtheOS действующий пользователь Linux или BSD. Но она вызывала именно такие эмоции. Конечно, на тот момент времени её нельзя было рассматривать как полноценную универсальную ОС для практической деятельности. Хотя уже тогда резонные люди утверждали, что применяться как платформа для разработки она могла. А её потенциал как системы для настольного использования просмтаривался достаточно явно.
Что же касается утверждения автора об отсутствии связи AtheOS с UNIX – можно констатировать: он постарался, чтобы его систему нельзя было бы спутать с Linux или FreeBSD. Однако несомненно, что идеологически он следовал именно пути UNIX, а не, скажем, традициям DOS или Windows. Хотя в те годы AtheOS часто сравнивали с AmigaOS или BeOS.
Увы, потенциал AtheOS так и не был реализован. Разработки Курта прекратились в начале 2002 года, последнее обновление сайта датировалось осенью 2003-го. Хотя, повторяю, сайт был доступен ещё долгое время, пока на нём не появилось сообщение об окончании срока регистрации домена. Ныне сайт символически восстановлен в качестве своего рода мемориала по тому же адресу – правда, дальше первой страницы пройти по нему нельзя.
О причинах прекращения разработки в Сети ходили противоречивые слухи. В частности, писали о том, что Курт увлёкся любительским пилотированием и потерял интерес к AtheOS. А поскольку в ходе активной его разработки он, в отличие от Линуса, не особенно привлекал к нему посторонних разработчиков, проект оказался «бесхозным», и Афина Паллада не пришла ему на помощь.
Так что столь интересный и потенциально многообещающий проект можно было бы считать мертвым. Однако чувство печали – ведь с уходом чего-то хорошего становится как-то грустно – заставляло меня время от времени наведываться на сайт проекта в надежде увидеть там какие-то подвижки. Пока вдруг по наитию не набрал слово «AtheOS» в поисковой строке Google.
ЭпилогИ тут в очередной раз обнаружилось, что приключения никогда не кончаются, по крайней мере – в мире Open Source (надеюсь, вы не забыли, что AtheOS распространялась по лицензии GPL?). Так вот, угасание проекта вызвало, видимо обиду не только у меня: на одном только SourceForge я обнаружил тогда пять разработок, выводящих свою генеалогию из системы Курта.
Правда, по настоящему действующей была только одна, носившая имя Syllable. Но зато это было настоящее развитие, продолжающееся и поныне, хотя далеко не теми темпами, как при Курте. Так что хочется верить – история AtheOS еще не окончена.
Я же пока сделаю выводы из истории прошедшей. главный из них таков: даже в наш век, когда одни разработчики Open Source пользуются поддержкой крупных фирм, другие просто работают в них за зарплату, а третьи сами образуют коммерческие фирмы, четвёртые создают большие и устоявшиеся сообщества, а пятые вообще уповают на поддержку родного государства, разработка новой, оригинальной и эффективной ОС силами индивидуала-энтузиаста оказывается возможной. Причём разработка в короткий срок – в отличие от развиваемых сообществом долгостроев, на которые не будем указывать пальцем.
Конечно, и это второй урок нашей истории – до определённого предела. После которого требуется привлечение соратников и единомышленников. Курту Скавену это не удалось – или это не входило в его планы. Но если проект интересен не только его автору, соратники и единомышленники появляются сами, даже если автор потерял всякий интерес к своему созданию. И это – третий урок, который мы в очередной раз извлекаем из истории Open Source.
Так что AtheOS, как это и сказано в заглавии статьи, можно считать предпоследним взлётом индивидуального ОСетворчества. Почему предпоследним? Не только потому, что было бы обидно, если бы он оказался последним. Но и потому, что в двух ближайших статьях цикла мы увидим более иные примеры его. Причём примеры более оптимистичные.
Героинями следующих двух статей цикла также будут ОС третьего тысячелетия – DragonFlyBSD и MINIX3. Хотя первая из них рассматривается обычно как форк FreeBSD, а вторая – как развитие той самой «игрушечной» MINIX, которая вдохновила Линуса Торвальдса на создание своей терминальной программы, обе они нынче являют собой вполне самостоятельные системы. И история их в этом качестве целиком принадлежит уже нашему времени. А судьба их оказалась более счастливой, нежели у героини сегодняшнего рассказа.
Глава седьмая. «Драгонада» Мэтта Диллона
Как было отмечено в прошлой главе, новые операционные системы возникают на наших глазах возникает не каждый день. И, главное, не каждая из возникших систем активно развивается, а не забрасывается по прошествии недолгого времени или входит в состояние стагнации. В этой главе я расскажу о счастливой судьбе такой системы, пусть не завоевавшей мир, но вполне благополучной.
Как догадались многие читатели, речь пойдёт о DragonFlyBSD, ответвлении FreeBSD, для которой отсчёт времени пошёл в июне 2003, и я за которой я следил с самого начала. И которую начал использовать с того момента, как она к тому стала пригодна.
«Железная» ретроспективаНачало нулевых годов стало одним из переломных моментов в развитии информационной сферы. Вычислительные мощности обычных настольных персоналок достигли такой страшной силы, что сполна, а то и с лихвой, перекрывали потребности подавляющего большинства пользователей. По крайней мере тех, чьим основным занятием было создание контента – до начала эры тотального его потребления оставалось ещё несколько лет.
И тут обнаружилось, что, впервые с момента появления персональных компьютеров, софтверный сектор индустрии не смог выполнить свое сакральное предназначение – вытрясать пользовательские кошельки на перманентный апгрейд своих машин, что обеспечивало бы финансовые источники для дальнейшего развития сектора хардверного. И развитие базового компьютерного «железа» – процессоров и чипсетов, определяющих лицо платформы, – если и не прекратилось, то резко затормозилось.
Конечно, время от времени производители продолжали бодро рапортовать об очередном повышении тактовых частот процессоров, увеличении их кэша до совершенно невообразимых, некогда вполне достаточных для основной памяти, объемов, включении дополнительных наборов инструкций под замысловатыми названиями, встраивании в чипсеты поддержки всего, чего можно, и даже того, чего, как недавно казалось, нельзя – например, 3D-графики. Однако накал страстей вокруг всего этого был не тот, что в во второй половине 90-х. А отчёты о тестировании процессоров и материнских плат стали напоминать просмотр фотофиниша на стометровке.
главное же, что, подобно рекордам в стометровке, достижения «камнестроителей» все меньше волновали широкие пользовательские массы. Ведь от медведя не убежит и олимпийский чемпион, а успеть за пивом в магазин перед его закрытием способен любой мало-мальски тренированный человек. Так и с компьютерами: настольно-пользовательские задачи в большинстве случаев стали решаться средствами любого подручного «железа», купленного за пределами лавки древностей. А задачи «тяжелые» по прежнему требовали более чем всех ресурсов персоналок, и потому решались обычно не на них (по крайней мере, разумными людьми).
Правда, стимуляции пользовательского интереса для производители в первые нулевые предложили два архитектурных решения, продаваемые как революционные. Первым (по времени) была архитектура Pentium 4. Она обеспечивала рост тактовой частоты процессоров, поражающй воображение пользователя, тянущегося к бумажнику. И к тому же перспективы роста казались тогда безграничными.
Правда, на счет безграничности жизнь довольно скоро внесла свои коррективы. И разговоры о том, что эта технология позволит играючи достичь тактовой частоты в 10 гигагерц, как-то стихли сами собой. Однако чисто случайно оказалось, что гигагерцев, в отличие пряников, как раз и хватило на всех (кроме тех, которым, как уже говорилось, их не будет хватать всегда).
Вторая, столь же революционная, новинка – 64-разрядные вычисления. Вспомним терью статью цикла: каким прорывом в светлое будущее были 32-битные процессоры для PC, те самые первые «трешки», которые сделали возможным портирование на эту архитектуру UNIX и, в конечном счёте, появление Linux. Повторилась ли история на новом витке диалектической спирали?
Увы, отрицательный ответ был получен практически мгновенно. Потому что в те далекие уже годы аппаратура PC едва поспевала за софтом – 32-битные ОС разменивали уже второй десяток лет своего существования, и приложений, использующих 32 разряда на полную катушку, было вдоволь. В описываемый же момент их в пользовательском сегменте просто не было по одной простой причине – не востребованности. К слову сказать, почти нет их и по сей день. Ибо единственная ниша пользовательских приложений, где 64 бита хоть как-то задействованы – параноидальная криптография.
Так что усилия «камнестроителей» пропадали бы втуне. Если бы ещё не одно новшество, о котором я сознательно не упоминал ранее – Hyper Threading, то есть виртуальная мультипроцессорность. Каковая в некоторых (правда, весьма редких) задачах давала вполне даже реальный прирост производительности. Правда, он мало значил для пользователей, работающих преимущественно интерактивно. Но весьма способствовал производительности труда применителей – тех, кто, в силу врожденной лености отдавал предпочтение всякого рода скриптам, пакетным заданиям и прочим средствам автоматизации.
Однако Hyper Threading был не более чем суррогатом истинной мультипроцессорности. Своего рода мультипроцессорность для бедных, но гордых. И потому, сказавши А, производитель процессоров неизбежно должны открыть рот для произнесения Б. То есть переходить к собственно мультипроцессорным конфигурациям в пользовательском сегменте.
Разговоры о двухпроцессорных пользовательских десктопах возникали неоднократно. Кое-кому из читателей памятно, как дешевенькие Celeron’ы первого разлива можно было вставлять в относительно не очень дорогие двухпроцессорные материнские платы, получая таким образом нечто вроде «народного суперкомпьютера».
Правда, первая волна «народной мультипроцессорности» была очень быстро пресечена производителем. Однако идея мультипроцессорности для народа продолжала витать в воздухе – никаким иным способом создать впечатление прогресса уже не удавалось (к слову сказать – не удаётся и по сей день). И первый шаг в этом направлении сделала, насколько мне известно, IBM со своими процессором Power4 – в то время абсолютным рекордсменом по «чистому» (то есть тестовому) быстродействию. В том числе и благодаря тому, что имели варианты с двумя и более процессорными ядрами в едином корпусе.
Сами по себе процессоры Power4 (как и пришедшие им на смену Power5) ориентировались на индустриальный сектор. Однако на базе их были созданы процессоры G5 – сердце тогдашних Mac’ов, имевших, в том числе, и двухъядерный вариант.
Правда, пользователям PC’шек (а мы говорим в основном о них) от этого было бы ни холодно, ни жарко. Однако здесь «камнестроители» не заставили себя ждать: и AMD, и Intel очень быстро анонсировали, а затем и воплотили в реальность, свои двухъядерные решения, стоимость которых вполне вписывалась в рамки «суперкомпьютера для народа». По крайней мере, в лице лучших его представителей.
Так что пользователи оказались перед выбором между традиционными одноядерными процессорами с большей тактовой частотой или процессорами двухъядерным – с меньшей (если оставаться в рамках одного бюджета). Как я уже говорил, рост тактовых частот упёрся в потолок целесообразности: сколь бы велик он ни был (а тут имелся ещё и потолок технологический), адекватного прироста производительности он уже за собой не влёк. Но могли ли пользователи рассчитывать на хоть какой-то выигрыш в производительности от многоядерности?
Софтверная перспективаИсходя из общих соображений было очевидно, что ожидать двукратного увеличения быстродействия от самого факта удвоения числа процессоров (или их ядер) не приходится. Во-первых, на «железном» уровне два и более процессоров будут совместно использовать какие-то общие ресурсы компьютера – память, кэши, шины и так далее.
Во-вторых, неизбежны были потери быстродействия за счет «накладных расходов» – согласования операций, выполняемых на разных процессорах.
В-третьих, системные и прикладные задачи, выполняемые на многопроцессорной машине, должны допускать их распараллеливание, иначе любое увеличение количества «числодробителей» доставит мало радости пользователю.
И, наконец, в-четвертых, эффективность многопроцессорных конфигураций в значительной мере определялась стилем выполнения пользовательских задач. Очевидно, что преимущественно интерактивные методы работы от удвоения «камней» выиграют весьма мало – в любом случае тут узким местом окажется пресловутый человеческий фактор.
Решение проблем многозадачности на «железном» уровне было задачей производителей аппаратуры. А вот минимизация же «накладных расходов» и распараллеливание задач относились уже к сфере разработчиков софта, в первую очередь – системного. Хотя в последнем случае роль создателей программ прикладных ничуть не меньше. Ну а эффективное использование достижений тех и других – это уже вахта пользователей.
И нужно сказать, что пользователи UNIX-подобных операционных систем, в силу самой специфики их работы и укоренившихся привычек, казались подготовленными к многозадачности лучше других. И были способны получить от нее больший выигрыш.
Ведь что происходит на типичной пользовательской UNIX? На ней постоянно что-то компилируется, архивируется и разархивируется, кодируется и декодируется, бэкапится и восстанавливается. И все это – параллельно, и, в большей или меньшей степени, без интерактивного участия применителя. Озаботившегося, разумеется, заблаговременно, скриптами для запуска своих задач, выводом полученных данных в логи и прочие файлы, и так далее – за интерактивным режимом остается только просмотр результатов. И, конечно же, их обдумывание.
Так что вырисовывалась заманчивая картина – все это изобилие параллельно работающих задач выполнять действительно параллельно, раскидав по разным процессорам. Дело оставалось за малым – воплотить её в кодах.
Изначально создатели UNIX (и ранних его клонов) ни о какой многопроцессорности не помышляли. И один из краеугольных камней его идеологии – концепция монолитных процессов, выполняемых на одном процессоре квазипараллельно, за счет квантования времени, – казалось бы, препятствует реализации распараллеливания задач по разным «камням».
Тем не менее, когда многопроцессорные серверы и рабочие станции стали реальностью в индустриальном секторе, в дополнение концепции процесса была создана и концепция т.н. нитей, или потоков (threads). Это – части процесса, выполняемые параллельно и почти независимо друг от друга (в том числе и на отдельных процессорах), разделяющие, тем не менее, ресурсы составленного из них процесса. То есть собственного контекста, в том числе и отдельного пространства памяти, они не имеют, почему носят ещё и имя легковесных процессов (light weight process) – обычные UNIX-процессы в этом случае можно называть «тяжелыми».
Само по себе понятие нитей возникло задолго до UNIX – чуть ли не со времен Очакова и ламповой электроники. И уже тогда были выявлены существенные недостатки этой концепции. Однако за истекшие годы ничего лучшего для поддержки мультипроцессорности придумано не было.
Как уже говорилось, проблема мультипроцессорности встала в первую очередь в индустриальном секторе. Где по ряду причин (в том числе и исторических) традиционно преобладали проприетарные представители UNIX-семейства. И разработчики последних доблестно эту проблему разрешили. Можно спорить, где она была решена лучше, где – не так хорошо, однако общепризнанно: масштабируемость многие годы был главной отличительной чертой (и главным козырем) и AIX от IBM, и Solaris от Sun, и прочих их братьев-конкурентов.
Свободные UNIX-совместимые ОС, как мы помним по первой статье цикла, разрабатывались преимущественно или в университетско-академической среде, или просто энтузиастами-любителями, как правило, на подручном оборудовании. Среди которого многопроцессорные суперкомпьютеры встречались не так уж и часто (солнце народной мультипроцессорности ещё не показало из-за горизонта своих первых лучей). И потому долгое время поддержка многопроцессорности была слабой стороной и Linux, и BSD-систем (по крайней мере, для платформы Intel и совместимых).
Движение свободных операционок в корпоративный сектор, в первую очередь в качестве серверов разного рода, поставило перед ними задачи многопроцессорной поддержки и масштабируемости. И задачи эти постепенно решались: в том или ином виде многопроцессорные конфигурации давно поддерживаются ядром Linux и FreeBSD, затем такая поддержка появилась в NetBSD и OpenBSD. Тем не менее, ни одна из этих ОС не дотягивала ещё до масштабируемости проприетарных UNIX’ов.
Правда, в мире свободного софта испокон веков развивалось другое течение, косвенно связанное с многопроцессорностью – так называемые микроядерные ОС. Идея их – в том, чтобы максимально возможную часть обязанностей ядра (взаимодействие с устройствами, файловыми системами и т.д.) вынести в пользовательское пространство памяти, оставив за ядром только коммуникационные функции. Теоретически рассуждая, это должно было бы обеспечить упрощение устройства системы, легкость её портирования на новые архитектуры (в том числе и многопроцессорные), а также возможности масштабирования.
Из микроядерных решений наибольшее признание получило ядро March, разработанное в Университете Карнеги-Меллона, а затем развивавшееся в Университете Юты. Оно легло в основу ряда проектов разработки свободных ОС – самым известным из них долгое время был Hurd, разработка которого затем была переведена на другое микроядро – L4. Что, однако, не приблизило проект к состоянию, пригодному для применения. Однако существовали и другие попытки создания свободных микроядерных ОС – проекты xMach и Yamit. И оба они своё развитие прекратили.
Таким образом, можно констатировать, что судьба свободных микроядерных проектов была (и остаётся) печальной. Что, помимо их невостребованности, объясняется ещё и технологическими причинами: судя по всему, разработчики не смогли обеспечить приемлемую производительность своих систем: ведь упрощение устройства ядра влечёт за собой усложнение межпроцессных коммуникаций.
Как ни странно, удачные реализации микроядерной архитектуры имели место быть в проприетарном секторе: на ранних версиях Mach основывалась знаменитая система NEXTStep, видевшаяся лет 15 назад платформой фантастического будущего. А предпоследняя, 3-я, версия Mach легла, вместе с системными службами FreeBSD, в фундамент современной MacOS X.
Таков был исторический фон, на котором развернулись описанные далее события.
