- 2.1. Устройство операционной системы Hurd
- 2.2. Hurd, с точки зрения пользователя
- 2.3. Установка Hurd
Слово "Hurd" читается примерно как английское слово "heard" и представляет собой один из акронимов, вроде "GNU" (Gnu's not Unix). В 1991 году руководитель проекта Hurd, Майкл Бушнел <mib@prep.ai.mit.edu> объяснял, что "Hurd" значит "Hird of Unix-Replacing Daemons", в то время как "Hird" означает "Hurd of Interfaces Representing Depth". Эту игру слов, намекающую на слово "hoard" (орда или куча), я перевести затрудняюсь, однако, как пишет Бушнел, "мы имеем здесь, насколько мне известно, первый программный продукт, название которого является парой взаимно рекурсивных акронимов".
Hurd - это операционная система проекта GNU [1]. Hurd совместим с Unix сверху: все, что имеется в Unix, есть и в Hurd, а все программы, написанные для Unix, можно скомпилировать и использовать при работе с Hurd, который, как и все программные продукты GNU, свободно доступны на условиях GNU Public License. Хотя бы по тому, насколько распространились другие программы проекта GNU, можно ожидать, что Hurd получит весьма широкое распространение. Hurd написан на основе микроядра Mach, знакомого пользователям, программистам и системным администраторам по ОС OSF/1, AIX (начиная с версии 3.1) и Net-BSD, и имеет все преимущества систем на основе микроядра; к тому же полные исходные тексты Hurd свободно доступны. Hurd является первой ОС, где последовательно проводится принцип модульности ядра. Все это делает данную операционную систему исключительно гибкой и весьма привлекательной для разработчиков, администраторов и пользователей.
1. Понятие микроядра: как и зачем
1.1. Основная идея
Основная цель ОС - позволить многим программам эффективно выполняться на одном компьютере. Это требует, как минимум, защиты памяти, системы разделения времени, некоего механизма коммуникаций между процессами, а также системы скоординированного доступа к устройствам ввода/вывода. Кроме того, ОС может предоставлять возможность работать на компьютере нескольким пользователям одновременно, что требует защиты их программ друг от друга. На современных компьютерах эти цели обычно достигаются посредством написания и запуска одной большой программы, ядра ОС. Поскольку к ядру должны иметь возможность обращаться все программы, то становится естественным добавлять к нему разнообразные сервисы (работу с сетью, файловые системы и др.). Никаких других способов для этого не создается, и ядро все разрастается и разрастается.
Внесение изменений в ядро - задача сложная, и справится с нею далеко не каждый; кроме того, необходимо, чтобы ядро, постоянно загруженное в память, имело разумный размер, поэтому в ядре оказываются только те компоненты, которые там совершенно необходимы. Нельзя воплотить все хорошие идеи из области системного программирования в одном монолитном ядре. Более того, только тот, кто является привилегированным пользователем на своем компьютере, может заниматься системным программированием. Отсутствие же исходных текстов ядра делает и это невозможным.
Возможен, однако, другой подход к созданию ОС, который становится все более популярным: подход, основанный на идее микроядра (рис. 1). Микроядро предоставляет только самые базовые функции: управление памятью, ввод/вывод, управление задачами и межпроцессная коммуникация. Все остальное - файловые системы, работа высокого уровня с периферийными устройствами и сетью и т. д., не спрятано в ядро, а предоставляется отдельными демонами.
Рисунок 1.
Простейшая модель построения системы на базе микроядра.
1.2. Преимущества по сравнению с традиционным подходом
Операционная система, построенная "поверх" микроядра, может быть с относительной легкостью перенесена на другую архитектуру из-за того, что все, зависящее от машины, "спрятано" в микроядре (и, естественно, компиляторе). Подобная мобильность недостижима для систем с монолитным ядром; одно это уже заставляет обратить внимание на такой подход. Сама идея микроядра, насколько мне известно, появилась у компании IBM, специалисты которой, выдвигая эту идею, имели в виду в первую очередь соображения переносимости ОС.
Сейчас, однако, стало ясно, что микроядро предоставляет и другие, не менее важные, преимущества. Одним из них является возможность построения по-настоящему открытых ОС, систем, которые смогут одновременно и эффективно исполнять программы, написанные для отличных друг от друга или даже совсем разных ОС. Все дело просто в наборе запущенных в данный момент демонов, который можно менять динамически и безболезненно.
Кроме того, неоценимы преимущества концепции микроядра при разработке системного программного обеспечения: после того как само (небольшое) микроядро делается стабильным, процесс отладки остальных частей системы становится гораздо проще (системная паника всегда имеет ясную причину и, главное, не возникает необъяснимых сбоев и зависаний).
2. Hurd: новый подход к разработке операционных систем
Hurd разработан на основе микроядра Mach. Полезно заметить, что первоначально использовалось микроядро Mach 3.0, замененное впоследствии на Mach 4.0, которое легче скомпилировать. FSF специально не начинало разработку ядра операционной системы GNU до того момента, как появился Mach, о разработке которого было, естественно, известно Ричарду Столлману (rms@prep.ai.mit.edu) - вдохновителю и руководителю проекта GNU, автору пакета Emacs. Hurd, будучи надстройкой над Mach, где нет ничего подобного вызовам вроде fork(), sleep(), wait(), execve() и пр., предоставляет пользовательским программам интерфейс Unix со всеми привычными системными вызовами, и, таким образом, Hurd может исполнять программы, написанные для Unix (рис. 2). На самом деле значительная часть того, что было частью ядра в Unix, становится частью библиотеки C-GNU с Library.
Рисунок 2.
Схема взаимодействия пользовательской программы с системой в ОС Hurd.
Сам же Hurd высокомодулярен и может перестраиваться в зависимости от потребностей пользователя. Обычно, чтобы вносить какие-либо изменения в ядро (помимо обладания исходными текстами ядра), нужно:
(1) понимать, как работает ядро или, по крайней мере, большая его часть, и разбираться в основных принципах построения операционных систем;
(2) быть привилегированным пользователем.
Процесс редактирования/компиляции/отладки, в случае с традиционным монолитным ядром, весьма болезненный и существенно отличается от написания программ пользовательского уровня. Система в это время закрыта для пользователей, и даже большинство администраторов не отваживается "лезть в систему". В случае Hurd написание и отладка частей системы ничем принципиально не отличается от создания обычных программ пользовательского уровня. Каждый системный администратор будет в состоянии легко изменить свою систему, и каждый (достаточно квалифицированный) пользователь сможет подстроить части системы под свои нужды, если это облегчает выполнение его задач.
Большинство проектов ОС на основе Mach наследуют все ту же традицию, возникшую при создании монолитных ОС: пользователь отделен от системы стеной; для любых пользовательских программ система - это "черный ящик". По сути, в коммерческих проектах на основе Mach части ядра Unix, обращавшиеся к машине, просто заменены на обращения к Mach. Мало того, что это неэффективно, поскольку не используются все возможности самой Mach, но остается невостребованным также и потенциал самой идеи микроядра. В Hurd собственно системного кода очень немного: пользователь видит и может менять поведение большинства частей системы.
2.1. Устройство операционной системы Hurd
Как уже отмечалось, Hurd предоставляет все возможности ОС Unix, как и собственные дополнительные возможности [2, 3]. К числу самых интересных расширений относятся файловые трансляторы и разрабатываемые "коллективы". Трансляторы позволяют в простейшем применении связать с данным файлом "фильтр", осуществляющий произвольные манипуляции и преобразования содержимого файла перед тем, как это содержимое станет видимым для пользовательских программ, а коллективы дают возможность связать несколько компьютеров, грубо говоря, в один.
2.1.1. Файловые системы
В операционной системе Unix впервые в истории развития ОС появился удобный механизм работы с устройствами - они стали файлами. Позднее этот метод был заимствован при разработке других ОС (и даже не ОС, а таких изделий, как, например, MS-DOS - вспомним prn, con, lpt и nul) и получил широкое толкование и развитие. В частности, в ОС Plan 9 [4] такие сервисы, как ftp, представлены в виде файловых иерархий.
Файловая система Hurd, благодаря механизму трансляторов, является воплощением и кульминацией этого подхода. Любой сервис, предоставляющий доступ к иерархически организованной информации (любая база данных, ftp, Usenet, WWW), может быть представлен в виде файловой иерархии. При этом разработка, отладка и добавление новых сервисов такого рода происходит на пользовательском уровне, не требует перекомпиляции ядра, перезагрузки и тому подобных болезненных процедур - необязательно даже быть привилегированным пользователем. Даже при отладке этих, по существу системных, драйверов нельзя вызвать системной паники или зависания.
Как показывают результаты некоторых тестов производительности, самой эффективной дисковой файловой системой для компьютеров с архитектурой Intel PC оказалась ext2fs (Second Extended File System). Hurd берет ее в качестве основы собственной дисковой файловой системы. Однако в ext2fs вносятся расширения, отражающие факт наличия трансляторов, дополнительного файлового атрибута author, появляющегося в ОС Hurd, и тому подобных полезных вещей. Hurd не будет вносить этих дополнительных элементов в файловую систему, созданную другой ОС (скажем Linux или FreeBSD); это осуществляется проверкой поля владельца (ownership) файловой системы, которое является строкой символов вроде "linux", "hurd", "freebsd". Файловая система Hurd может быть смонтирована из Linux, FreeBSD или Net-BSD, но нельзя запускать на ней fsck (иначе будут обнаружены и уничтожены расширения, внесенные Hurd); Hurd же может свободно монтировать и использовать файловые системы, созданные другой ОС.
Кроме того, Hurd поддерживает 4.4 BSD UFS, которая может использоваться при установке системы в качестве базовой (native), и "мелкие" файловые системы вроде файловой системы MS-DOS и т. п. для облегчения переноса файлов.
2.1.2. Миграция процессов: что в перспективе?
Современные компьютеры не существуют сами по себе: они обычно являются частью сети; разумно было бы иметь какой-либо механизм, позволяющий эффективно распределять ресурсы внутри локальной сети. Следуя установившейся терминологии, назовем совокупность доверяющих друг другу компьютеров, которые, будучи связаны сетью, делят ресурсы (оперативную память, процессорное время, дисковое пространство) и распределяют между собой загрузку сбалансированным образом - коллективом.
В идеале (и, таким образом, в перспективе) коллектив компьютеров должен, с точки зрения пользователя и даже с точки зрения большинства драйверов операционной системы, выглядеть как одна машина. Процесс должен будет иметь возможность "не замечать", на каком компьютере коллектива он в данный момент реально исполняется. В коллектив могут быть включены как машины, связанные одной локальной сетью, так и компьютеры, очень далеко разнесенные территориально, как, например, машины, находящиеся в разных странах, но, скажем, принадлежащие одной корпорации. В этом случае алгоритм, определяющий миграцию процессов и кэширование данных, должен будет принимать во внимание затраты времени на передачу информации по сети.
Задачи, которые предстоит решить на пути встраивания понятия коллектива в ОС, сводятся к следующим:
1) созданию общего пространства идентификаторов процессов (process id, Unix pid);
2) коллективному пространству дескрипторов открытых файлов (file descriptors). Чтобы осознать важность и сложность этого, нужно вспомнить, что, скажем, после вызова fork() - который в Unix всегда является системным вызовом, а в ОС Hurd будет частью GNU C Library и станет воплощаться средствами пользовательского уровня поверх машины Mach - порожденный процесс наследует все дескрипторы открытых файлов процесса-родителя [в частности программы-оболочки (shells) создают конвейеры (pipes), используя именно это свойство Unix]; однако нужно не забывать о том, что процесс, порожденный вызовом fork(), может мигрировать и исполняться на другом компьютере;
3) созданию надежного механизма аутентификации, который должен будет сделать эту схему еще более "безопасной" - защищенной от несанкционированного проникновения, - чем существующие реализации Unix (ничто не мешает сделать ОС, управляющую таким коллективом, соответствующей классификации по типу C1 или B2).
Первая и вторая задачи проще всего решаются путем назначения машины-координатора, которой остальные компьютеры докладывают о системных событиях (system events) и которая аккумулирует всю необходимую информацию. Для больших коллективов такой подход будет все же малоэффективен; разумнее было бы распространять информацию о системных событиях по протоколу типа протокола ihave/sendme, используемому Usenet. Придется, однако, внести в него механизмы синхронизации и немедленной доставки при миграции, поскольку иначе возникнет ситуация "гонки".
Для решения третьей задачи существуют хорошо разработанные криптографические методы, основанные на шифровании с открытым ключом и цифровой подписи.
2.2. Hurd, с точки зрения пользователя
Всякий волен пользоваться Hurd так, словно это обыкновенный и привычный Unix. Даже разработчик программного обеспечения может не принимать во внимание, что он имеет дело с особой ОС GNU. Однако Hurd наряду с тем, что он не является системой с монолитным ядром, содержит многие расширения по сравнению с Unix, наиболее, с моей точки зрения, примечательные из которых описаны ниже.
2.2.1. Механизм трансляторов
Транслятор в ОС Hurd - это что-то вроде программы-фильтра, ассоциированной с данным файлом и исполняемой всякий раз при открытии файла. Эта программа имеет доступ к реальному содержимому файла и обрабатывает его произвольным образом перед тем, как данные попадут в пользовательскую программу. Владелец файла может связать с ним любую программу в качестве транслятора. К примеру, самым тривиальным применением этого механизма станет связывание с tar- (или gzip-) архивом транслятора, который будет читать его на ходу и представлять дело так, будто это обыкновенный каталог (или файл в случае с gzip). Такой подход (в случае с tar и gzip) будет потреблять некоторые дополнительные ресурсы, однако он удобен.
Порты машины Mach являются точками коммуникации, ассоциированными с задачей Mach. Используя порт Mach, можно посылать и получать сообщения; таким образом, для тех, кто знаком с внутренним устройством Unix, порт Mach в определенном смысле является аналогом очереди сообщений из System V. В Hurd порты машины Mach используются, в основном, как средство коммуникации между клиентом и сервером, а также для реализации других видов IPC (Inter-Process Communications, межпроцессовые коммуникации). Здесь будет уместно напомнить, что к классическим методам IPC относятся конвейеры (pipes), очереди сообщений (message queues), семафоры, общая память (shared memory) и сокеты типа A_Unix (файлы, ведущие себя как сетевые сокеты, но предназначенные для IPC в пределах одного компьютера); иногда используются UDP-сокеты, а для примитивных форм IPC зачастую применяются сигналы. Все эти методы IPC должны поддерживаться в Hurd, причем с их стандартным интерфейсом системных вызовов Unix, которые в Hurd перестанут, естественно, быть системными. Некоторые протоколы, вводимые в ОС Hurd, являются протоколами обобщенного ввода/вывода: файловый протокол, используемый для выполнения операций файловой системы, протокол TCP/IP сокетов, используемый для работы с сетью, и протокол процессов, применяемый в Hurd для манипуляции процессами (посылка сигналов, установка пределов использования ресурсов, приоритетов в выделении таких ресурсов, как оперативная память и процессорное время, и т. п.).
Обращения к большинству серверов осуществляются путем открытия определенных файлов. Это является далеко идущим обобщением и развитием понятия пользовательской файловой системы (user filesystem), как она присутствует в таких операционных системах, как Linux. Имеется два фундаментальных отличия подхода Hurd от пользовательской файловой системы:
1) для создания пользовательской файловой системы необходима перекомпиляция ядра и перезагрузка системы, в то время как в Hurd файловые трансляторы могут свободно, как пользовательские программы, добавляться, изыматься или изменяться в работающей системе - не нужно даже быть привилегированным пользователем, чтобы делать это;
2) любой драйвер пользовательской файловой системы будет исполняться в режиме ядра, имея полный доступ к ресурсам (как пользователь root), и, более того, планировщик не сможет инактивировать такой драйвер, поскольку тот является частью ядра. В то же время трансляторы исполняются как пользовательские процессы; им обыкновенным образом назначаются приоритеты (вроде значений nice) и пределы использования ресурсов (resourse limits). Права доступа этих процессов к системным ресурсам определяются стандартным образом, что позволяет лучше выполнять задачи операционной системы, отделяя не только пользовательские процессы друг от друга и систему от пользовательских процессов, но и части системы друг от друга.
Обычно при открытии файла создается порт Mach, принадлежащий серверу, владеющему каталогом с этим файлом. (Говорят, что сервер владеет каталогом, если он назначен его обслуживать; в этом случае сервер, владеющий портом Mach, ассоциированным с неким (открытым) файлом, называется транслятором этого файла.) Например, дисковая файловая система будет обычно обслуживать большое количество портов, каждый из которых представляет открытый файл или каталог. Когда приходит запрос на открытие файла, сервер (в данном случае файловая система) создает порт, ассоциированный с данным файлом, и возвращает его программе, пославшей запрос.
Однако у файла может быть ассоциированный с ним транслятор (рис. 3, 4). В этом случае файловая система выполняет этот транслятор, передавая ему - а не программе, пославшей запрос на открытие файла, - порт, соответствующий реальному содержимому файла. Транслятор же сообщает файловой системе порт, который та передает первоначально пославшему запрос процессу.
Рисунок 3.
Схема предоставления доступа к файлу, имеющему транслятор.
Рисунок 4.
Схема доступа к уже открытому файлу с транслятором.
Этот механизм используется в том числе для монтирования (mount): c каждой точкой монтирования (mount point), в частности с каждым устройством, которое можно смонтировать, таким как раздел на диске (partition), ассоциирован специальный транслятор. Когда программа открывает какую-либо точку монтирования, выполняется соответствующий транслятор (в данном случае программа, понимающая формат диска монтируемой файловой системы), который возвращает некий порт. После того как транслятор выполнен, его не нужно запускать снова и снова при каждом обращении к соответствующей файловой системе, поскольку родительская файловая система помнит порт, который вернул транслятор при своем запуске, и передает его в ответ на дальнейшие запросы. Таким образом, все, что должна будет сделать команда mount - это открыть соответствующий файл и затем выполнить системный вызов _exit(), семантика которой подразумевает неизменность дескрипторов открытых файлов процесса.
Владелец файла всегда может ассоциировать с ним любой транслятор безо всякого специального разрешения. Любая программа может использоваться как транслятор. В такой ситуации система, очевидно, не будет правильно работать, если используемый для открываемого файла транслятор не работает в соответствии с принятыми соглашениями (не воплощает стандартный файловый протокол Hurd - не отвечает правильно сформатированным образом на стандартные запросы). Однако Hurd сделан так, что наихудшим возможным последствием этого может быть прерываемое зависание - в то время как ошибка в системном драйвере приведет, в лучшем случае, к системной панике (system panic).
2.2.2. Преимущества трансляторов с точки зрения пользователя
Один из способов пользоваться трансляторами - получение доступа к любым иерархически структурированным данным посредством файлового протокола. Например, хотя в Hurd и остается команда ftp, она больше не нужна. Весь пользовательский интерфейс ftp заменен привычным интерфейсом файловой системы. Нужно знать, что каталог /ftp представляет собой интерфейс к ftp и можно пользоваться обыкновенными командами (cd, cp, ls, more) из командной строки или стандартными функциями (open(), read() и т. д. или их аналогами из библиотеки stdio) из программы на языке Си. Например, команда
cp/ftp/prep.ai.mit.edu/ pub/ gnu/emacs.tar.gz ~ &
позволит скопировать указанный файл на локальный диск, а
mail -f /ftp/alpha: shalunov: passwd/mbox
позволит читать и редактировать mail folder на удаленной машине alpha в домашнем каталоге пользователя shalunov.
Можно ассоциировать с .tar.gz-файлами транслятор, позволяющий просматривать и менять их содержимое прозрачным образом. Любой пользователь может создать каталог send-compressed, позволяющий командой вроде
cp filename send-compressed/
user@host.name
файл filename упаковать посредством gzip, разбить на части длиной 700 Кбайт, закодировать uuencode и послать по электронной почте по адресу user@host.name (все параметры легко сделать конфигурируемыми). Если пользователь часто работает, скажем, с неким WWW-сервером, можно сделать, чтобы он был подкаталогом домашнего каталога пользователя.
В связи с быстрым развитием технологий создания емких и дешевых магнитных дисков необходимость в файловых системах, осуществляющих автоматическое сжатие на лету, постепенно отпадает (с использованием файловых трансляторов подобные вещи очень легко осуществить). Однако все более актуальными становятся файловые системы, хранящие информацию в зашифрованном виде. При наличии трансляторов написание такой системы становится вполне по силам среднему программисту, знающему алгоритмы шифрования, но незнакомому с системным программированием в его современном понимании.
Файловые трансляторы исключительно удобны для создания файловых систем с произвольно сложной и произвольно конфигурируемой системой доступа (возможно, полностью отличающейся от системы доступа Unix, основанной на механизме допуска для автора, группы и для всех остальных, и достаточно бедной для многих приложений).
С помощью файловых трансляторов легко создавать файловые системы, которые невозможно изменить сами по себе, но все измененные версии файлов записываются в другое место. Такие файловые системы полезны для контроля версий разрабатываемых программ. Можно создать каталоги-объединения других каталогов со сколь угодно сложными правилами решения вопроса, какой именно файл предоставить при запросе при наличии нескольких одноименных файлов, что полезно в процессе создания каталога типа /bin, или, скажем, если нужно внести изменения в исходные тексты, хранящиеся на CD-ROM, не переписывая их целиком на магнитный диск.
Для машин, где необходима особая надежность, можно было бы файловую систему из каталога /home сделать идентичной обыкновенной дисковой, за одним исключением: при уничтожении или изменении файла прежняя версия записывается в файловую систему, которая является очередью для копирования на медленный носитель очень большой емкости (такой как устройство автоматической смены дисков WORM).
Кроме того, транслятор файловой системы - естественное место для кодирования надежного автоматического резервного копирования без замораживания всей файловой системы.
Надеюсь, все это дает почувствовать гибкость механизма трансляторов и немедленно придумать приложения этого механизма, которые помогли бы в работе.
2.3. Установка Hurd
В нашей статье не ставилась цель написать руководство по инсталляции. На эту тему вполне достаточно материалов, которые содержатся в дистрибутиве, где даны весьма подробные пошаговые инструкции.
Hurd может быть установлен на ПК с процессором, начиная от Intel 80386, памятью 4 Мбайт и пары сотен мегабайт свободного места на диске. При этом для Hurd нужен собственный раздел на диске. Существует бинарный дистрибутив (ftp://prep.ai.mit.edu/pub/gnu/gnu-0.0/gnu-0.0-stripped.tar.gz), где можно ничего не компилировать. Если захочется самим перекомпилировать ядро, оптимизировав его, скажем, под специальный тип процессора, то для осуществления компиляции понадобится работающий Hurd.
В дистрибутиве описано, как установить Hurd, если на компьютере уже имеется Net-BSD. Можно также установить Hurd на машину, где есть Linux [5]. Чтобы установить Hurd на машину с ОС Linux, нужно будет получить еще четыре коротких файла с http://www.serv.net.
Заключение
Можно ожидать, что Hurd с выходом стабильной версии (хотя бы 1.0) очень сильно потеснит другие свободно распространяемые операционные системы. По всей видимости, первоначально главной нишей его распространения станет замещение Linux: для конечных пользователей этот процесс будет "прозрачен" - они могут просто не заметить отличий от Linux. Для разработчиков же и программирующих пользователей Hurd предпочтительнее за счет его гибкости и мощи, в отличие от ОС, имеющих традиционное монолитное ядро.
Дополнительным преимуществом Hurd является то, что он гораздо эффективнее монолитных ядер на многопроцессорных системах. Это связано с тем, что микроядро Mach разработано, а не просто приспособлено, специально для работы со многими процессорами и для предельного облегчения миграции процессов. На многопроцессорных машинах Hurd будет гораздо эффективнее, чем, скажем, ОС Linux или FreeBSD.
Сейчас все программные продукты GNU легко переносимы в любую среду Unix, а со временем можно ожидать, что для увеличения эффективности разработчики, занятые в проекте GNU, станут использовать труднопереносимые конструкции, начиная с активного применения файловых трансляторов в больших программных комплексах, что облегчит их написание, но затруднит перенос на другие ОС, и заканчивая непосредственными обращениями к Mach. Желающие пользоваться привычными, удобными и эффективными продуктами GNU станут переходить на Hurd, поскольку сегодня не видно его недостатков по сравнению с монолитными ядрами. Подход, связанный с использованием микроядра, становится все более популярным и для коммерческих ОС. И это неудивительно: чтобы перенести ОС, например, на новую архитектуру, достаточно перенести на нее лишь небольшое по размерам микроядро, все остальное пойдет без изменений.
Особых сомнений по поводу распространения Hurd среди пользователей, уже сейчас предпочитающих свободные программные продукты, нет. Станет ли он распространяться в корпоративной среде, зависит от того, найдутся ли компании, согласные за плату устанавливать и сопровождать его на уровне, на котором сейчас обслуживаются приличные коммерческие ОС. При том, что Hurd, как свободно распространяемая система, стоит дешево и обладает гибкостью программного продукта, использующего новейшие идеи построения операционных систем, а также эффективностью программы, написанной университетскими специалистами, высококвалифицированными и работающими для поддержания своего личного реноме, можно ожидать высокой конкурентоспособности Hurd по сравнению с дорогими, громоздкими, зачастую полными ошибок и морально устаревшими ОС.
Литература
[1] The GNU Manifesto, см. http://www.gnu.ai.mit.edu/.
[2] Towards a New Strategy of OS Design, the GNU Bulletin, January 1994.
[3] Martin Michlmayr, J. Schmidt, Zukun-ftsmusik, UNIXopen, pp. 108-109, January 1996.
[4] Plan 9 от Bell Laboratories, Открытые системы, N 6 (14), 1995.
[5] Installing the Hurd from a Linux box, Derek Uphem, http://www.serv.net/~sand/hurd/.
