X-сервер в Debian GNU/Hurd и особенности системы

В комметарии к скриншоту из этого [1] поста мне задали два вопроса касательно текущего статуса GNU Hurd. Я решил опубликовать ответ здесь, так как он получился достаточно длинным и он может быть интересен ещё кому-нибудь (кого волнуют эти же вопросы).

Итак, вопрос первый:

> А X сервер на нем заводится?

На сайте Debian GNU/Hurd есть инструкция по запуску X-сервера [2] - судя по всему, сервер должен запускаться без особых проблем. У меня пока не получилось его запустить. Надо будет ещё раз попробовать - возможно, я что-нибудь упустил из виду при настройке.

В качестве подтверждения, что X-сервер действительно работает - вот обсуждение [3] Debian GNU/Hurd, где можно найти скриншоты иксов, работающих на Hurd, запущенном в QEMU.

> Ощущаются ли особенности архитектуры?

Во-первых, надо сказать, что система работает достаточно стабильно (по сравнению с тем, что я видел в Arch Hurd в начале года). Например, исправлена досадная ошибка с "замораживанием" консоли при простое системы (патч оказался достаточно тривиальным [4]).

Однако, в плане производительности Hurd всё ещё отстаёт от Linux - по собственным ощущениям, по крайней мере. При работе с разделами ext2 очень активно нагружает процессор ext2fs сервер (транслятор, в терминологии Hurd), который обеспечивает доступ к разделам с этой ФС - скажем, при aptitude upgrade он ест иногда более 40% CPU.

Вот скриншот с рабочей системы, на котором видно, что ext2fs заметно нагружает CPU (htop запущен через SSH-подключение):

Что интересно, по сути ext2fs представляет собой переписанный драйвер ext2 из Linux (насколько я понимаю), который отражает особенности Hurd - например, его i-node хранят так же информацию о трансляторах, которые являются частью Hurd. В системе даже привычный mount является ни чем иным, как скриптом, который запускает соответствующий транслятор для обслуживания запросов к монтируемому разделу.

Так что ты можешь видеть в ps/top/htop, что творится "под капотом" ОС - работу серверов, которые по сути и превращают микроядро Mach в Hurd.

На тему данную тему есть интересный обзор GNU Hurd с оценкой производительности, который был опубликован в прошлом году на Phoronix [5].

Ссылки:

• [1] http://memory-heap.blogspot.com/2012/09/gnu-emacs-debian-gnuhurd.html
• [2] http://www.debian.org/ports/hurd/hurd-install
• [3] http://www.debianuserforums.org/viewtopic.php?f=10&t=1070
• [4] http://lists.gnu.org/archive/html/bug-hurd/2011-10/msg00087.html
• [5] http://www.phoronix.com/scan.php?page=article&item=debian_gnu_hurd&num=1

По поводу концепции микроядерной ОС

Продолжаю наблюдать за развитием GNU Hurd. Напомню, что Debian GNU/Hurd стоит на одном из моих ПК как основная система. Мне интересна концепция микроядерной ОС - разработчики микроядер обещают высокую надёжность и возможность легко расширять и изменять систему под свои нужды.

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

Эта концепция напоминает деловые связи, которые возникают в обществе людей. Вот пример: Боб выращивает помидоры в теплицах. Он получает каждую неделю удобрения для помидор от Мэлори. Так же раз в месяц к нему приходит электрик Дэйв, который обслуживает автоматическую систему полива. Если, например, Мэлори заболеет и не сможет обеспечивать какое-то время Боба удобрениями, то Боб может обратиться к Джону (другому поставщику) и тот доставит ему удобрения. То есть, бизнес Боба почти не пострадает от того, что Мэлори заболел, так как он является внешним "сервисом", который Боб использует. С другой стороны, некоторая часть работы выполняется самим Бобом - например, сбор и упаковка помидор перед продажей. Так же в небольшой фирме Боба работает его супруга, Элис - она отвечает за учёт средств и поддержку web-сайта фирмы Боба.

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

Следущим важным моментом является то, что микроядра гораздо меньше по размеру (да, приставка микро- здесь используется не просто так). Так, например, ядро MINIX3 - одной из широко известных микроядерных ОС - содержит примерно 10000 строк кода [1]. Чем меньше кода, тем проще его поддерживать и вылавливать ошибки. Меньше кода, меньше ошибок, надёжнее ОС.

В современном мире уже почти каждый холодильник и телефон работает под управлением ОС и/или может быть подключён к компьютеру. Поэтому многим подобным устройствам необходим драйвер, который обеспечивает взаимодействие с устройством, с его аппаратным обеспечением. В монолитой ОС драйверы включаются в состав ядра и (очевидно) работают в пространстве ядра. Таким образом, драйверы являются "доверенными лицами" ядра. ОС полагается на них, когда нужно взаимодействовать с вашим USB-вентилятором или записать данные на жёсткий диск. Однако, если драйвер работает неправильно, то это может привести (и вероятнее всего, приведёт) к нестабильной работе ядра и всей ОС.

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

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

Одним из замечательных примеров надёжности микроядерных ОС явлется так называемый сервер реинкарнации (reincarnation server), который является частью ОС MINIX3, и который автоматически перезапускает серверы, если они по каким-то причинам сбоят и аварийно завершают свою работу [2].

Тем не менее, микроядерные ОС обладают своими недостатками - например, их намного сложнее разрабатывать, и обычно они обладают более низкой производительностью (хотя, например, микроядро L4 достаточно быстро[3]).

Исследования в области микроядер ведуться десятки лет, но на данный момент можно назвать лишь несколько успешных проектов в этой области. Микроядро MINIX и микроядро Mach (третья версия которого лежит в основе GNU Hurd и Darwin) - пожалуй, самые известные.

Всё вышесказанное не претендует на полноту и безошибочность, так как мои познания в этой области являются достаточно скромными. За дополнительной информацией вы можете обратиться к соответствующим статьям в Википедии (например, [4] хорошо написана) и другим источникам.

Ссылки:

• [1] More about MINIX 3. http://www.minix3.org/other/read-more.html
• [2] Reliability in MINIX 3. http://www.minix3.org/other/reliability.html
• [3] https://en.wikipedia.org/wiki/L4_microkernel_family
• [4] https://en.wikipedia.org/wiki/Microkernel

GNU Emacs на Debian GNU/Hurd

Сегодня наконец-то запустил GNU Emacs на Debian GNU/Hurd. Emacs версии 23 при запуске у меня выдавал следующую ошибку

$ emacs -nw
emacs: Not a tty device: /dev/tty

Различные попытки запустить Emacs 23 не увенчались успехом.

В списке рассылки нашёл патч [1], который должен был устранить эту проблему. Далее мне нужен был исходный код GNU Emacs, чтобы собрать его с данным патчем.

Однако сначала я решил попробовать более простой путь. Ранее я читал, что данная ошибка была устранена версиях Emacs старше 23.4 (у меня на тот момент была установлена версия 23.2). Поэтому я решил первым делом проверить, не появилась ли более новая версия в репозитории - и обнаружил Emacs версии 24, где ошибка была устранена.

Для меня запуск Emacs на GNU/Hurd был важным рубежом - ведь если у вас есть работающий Emacs в системе, то у вас есть практически всё, что может потребоваться - даже текстовый редактор.

Источники:

1. http://lists.debian.org/debian-hurd/2011/01/msg00023.html

C or English?

Ставлю Debian GNU/Hurd на виртуальную машину. На этапе выбора языка установки мне предлагаются следующие варианты:

Вот даже не знаю, какой язык выбрать.

Короткий отчёт за выходные дни

Перед новогодними праздниками я составил список дел на на выходные дни. Вот короткий отчёт, что удалось (или не удалось) сделать.

1. Я установил Arch Hurd на подержанный компьютер, чудом доставшийся мне ещё в прошлом году.

Почистил компьютер внутри,подключил к нему старую PS/2 клавиатуру и старый ЭЛТ-монитор, который вытащил из гардероба, а потом потратил кучу времени на установку и настройку ОС. И могу сказать, что это было достаточно интересным занятием.

Кстати, на корпусе монитора сохранились мои рисунки, выполненные механическим карандашом:

Но что же такое GNU Hurd?

Как вы знаете (а может быть, и нет) - GNU Hurd представляет собой практически легендарный проект по разработке микроядерной операционной системы на основе микроядра GNU Mach, набора серверов, реализующих отдельные компоненты ОС (файловая подсистема, сетевая подсистема и т.д.) и так называемых трансляторов. Разработкой GNU Hurd занимается проект GNU - вот уже более 20 лет - и на основе него были предприняты в разное время попытки создания дистрибутивов как для широкого, так и сугубо "just for fun" использования. Одним из таких проектов и является Arch Hurd. Другим известным проектом является Debian/Hurd. Интересующиеся люди могут найти так же упоминание Gentoo Hurd и других проектов на основе GNU Hurd.

К сожалению, Gentoo Hurd не подаёт признаков жизни, а вот Arch Hurd и Debian/Hurd живут и развиваются. Более того, я встречал на просторах Интернета информацию, что команда, занимающаяся разработкой Debian/Hurd, собирается выпустить в 2012 году первый дистрибутив на основе GNU Hurd, пригодный для повседневного использования. Дабы внести ясность - "повседневного" в понимании обычных пользователей, а не гиков и прочих помешанных на компьютерах людей.

К слову, Hurd является единственным известным мне проектом, название которого представляет собой двойной рекурсивный акроним.

За подробной информацией о GNU Hurd и дистрибутивам на его основе я отправляю вас в Интернет - за ~20 лет там накопилось достаточно информации по этому проекту. Например, в английской Википедии есть обширная статья, есть так же и официальный сайт проекта.

О GNU Hurd более подробно я постараюсь рассказать в одной из следующих заметок.

2. Поставил CyanogenMod на свой телефон, вместо штатной прошивки. Тут особо нечего говорить. Всё работает - и работает, как надо. Модифицированная ОС предоставляет большие возможности для гибкой настройки параметров работы телефона. И на телефоне теперь есть нормальная консоль с root-правами.

3. Собирался поставить куда-нибудь тайловый оконный менеджер StumpWM и попробовать его в работе. Этим "куда-нибудь" оказался подвернувшийся под руку Arch Hurd. Увы, в репозиториях StumpWM не нашлось, а собрать его из исходников оказалось не такой уж и тривиальной задачей. Но я, тем не менее, не теряю оптимизма по поводу StumpWM. Много ли вы знаете менеджеров окон, написанных на языке Lisp? А StumpWM как раз написан на Лиспе, и представляет очень интересные возможности для пользователя, в том числе, возможность "на лету" менять параметры оконного менеджера.

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