Иконок символизирует операционную систему gnu linux

История операционной системы GNU, или что случилось с Hurd?

Вниманию читателей предлагается перевод статьи «Whatever happened to the Hurd? — The story of the GNU OS», опубликованной в журнале Linux User & Developer в декабре прошлого года.

Работа над операционной системой GNU ведется без малого тридцать лет — с 1983 г. Впервые интерес к микроядру Mach, которое разрабатывалось в университете Карнеги-Меллон (CMU), в качестве ядра своей операционной системы Фонд свободного программного обеспечения (FSF) проявил еще в 1987 г., но его исходный код не распространялся под подходящей лицензией вплоть до 1991 г. К тому времени Линус Торвальдс уже занимался своим собственным проектом по разработке ядра для IBM-совместимых компьютеров на процессоре i386.

Если бы в свое время Linux не был написан и опубликован под GPLv2, если бы не вписался столь удачно в окружение уже существующих компонентов GNU и не захватил умы и сердца разработчиков по всей планете, — кто знает, быть может, вся «движуха» сосредоточилась бы вокруг Hurd, и мы бы сейчас жили в несколько ином мире. Но на судьбу Hurd повлияли не только стремительный рост популярности Linux или сделанная FSF ставка на микроядро Mach.

По своей сути, архитектура Hurd — это попытка воплотить в программном коде дух и перспективы движения за свободу программного обеспечения. Вот слова одного из сотрудников FSF тех времен: «Наверное, можно сказать, что когда мы проектировали Hurd, у нас дух захватывало от того, что происходило вокруг. Движение за свободу программного обеспечения всегда было (и есть) о том, чтобы пользователи перестали быть зависимы от прихотей производителей „софта“. Микроядерная архитектура Hurd, устройство и взаимодействие демонов, — если провести аналогию, — давала такую же свободу простым пользователям системы: вы больше не обязаны подчиняться системному администратору, его драконовским политикам и правилам. Каждый пользователь мог (безопасно для самой системы и других пользователей) запустить любой набор демонов, создавая нужное ему или ей рабочее окружение, ни о чем не спрашивая администратора системы.»

Просто большой чулан

Ричард Столлман заявил о намерении написать полноценную Unix-подобную операционную систему, названную им GNU (рекурсивная аббревиатура GNU’s Not Unix!), в сентябре 1983 г. За это время (до зарождения Hurd) были написаны компоненты системы и инструментарий, которые были необходимы для разработки ядра: редакторы и компиляторы, Bash, Make, Autoconf, Emacs, GCC, sed, gawk и др.

GNU окупала себя, продавая программные продукты. Когда началась работа над Hurd, FSF стала нанимать разработчиков. «Это было задолго до эры широкополосного интернета, и чаще всего люди работали на текстовых терминалах, через модем. Обычно мы делили один офис; если бы вы его увидели, то подумали, что он больше похож на большой чулан. В то время мы были гостями в MIT.»

Линус Торвальдс анонсировал свою «свободную операционную систему (просто хобби, ничего такого профессионального как GNU) для 386 (486) AT-клонов» в конференции comp.os.minix за несколько месяцев до начала работы над Hurd. Линус выбрал модель монолитного ядра, от которой воротили нос пуристы, но которая дала возможность быстро получить рабочее ядро.

Linux понравился хакерам, энтузиастам и ученым, многие из которых стали активно участвовать в разработке. Ядро привлекало их своей открытостью, свободной лицензией и тем, что его можно было запустить практически на любом имеющемся устройстве. Linux «поймал волну», сообщество разработчиков росло удивительно быстро. Работа над Hurd продолжалась, но далеко не с той же активностью. Людям было интереснее заниматься GNU/Linux, а не GNU Hurd.

Идеалистическая философия

С точки зрения пользователей, Hurd было еще расти и расти, а Linux, благодаря усилиям разработчиков, прочно занял свое место в качестве «сердца» операционной системы GNU. По началу Столлман относился к этому скептически. Ранние версии Linux работали только на IBM 386; по словам самого Столлмана, «мы слышали, что Linux практически не портируем (сейчас это не так, но тогда так говорили), и, кроме того, Linux по своей архитектуре похож на ядро Unix. Мы же пишем нечто значительно более мощное и продвинутое.»

Linux был тесно завязан на GCC и инструментарий GNU, все более развивался и «матерел», особенно с появлением дистрибутивов, и вскоре FSF стала рассматривать его в качестве приемлемой (пусть не самой оптимальной и временной) замены все еще несуществующего ядра операционной системы GNU. Столлман сразу внес ясность: «Не существует операционной системы, которая называется Linux. Операционная система Linux — это GNU. Linux это всего лишь программа: ядро. Ядро — это часть операционной системы, самая низкоуровневая программа, которая управляет другими программами, выделяя им процессорное время и другие ресурсы.»

Он настаивал, чтобы операционная система GNU с Linux в качестве ядра непременно называлась GNU/Linux, чтобы «люди понимали, что система существует благодаря идеалистической философии. Назовите ее Linux, и вы нарушите философию. Это очень серьезная проблема. Linux — это не система, а всего лишь ее часть… Именно благодаря той идеалистической позиции, на которой основывается проект GNU, у нас есть эта система.»

Работа над Hurd продолжалась, но вскоре стало очевидно, что FSF ступила на тернистый путь в своих поисках совершенства. Микроядро требовало решения ряда довольно непростых проблем, а многие из тех, кто мог бы за это взяться, были заняты в работе над Linux, которым уже можно было плодотворно пользоваться. Несмотря на известную критику, например со стороны Энди Таненбаума, выбор Линуса монолитной модели ядра позволил получить рабочую систему намного проще и быстрее.

Позже Столлман признал, что «несет всю ответственность за техническое решение разрабатывать ядро GNU на основе Mach, из-за чего так замедлилась разработка системы. Я полагал, что использование Mach позволит нам сэкономить время, но оказался неправ.» В последующие годы Hurd был портирован на различные микроядра, от L4 до Coyotos и Viengoos, но никогда не мог он похвастаться той поддержкой сообщества и теми ресурсами, которыми располагал (и располагает) Linux.

Принцип и обязательство

В конце девяностых в сообществе произошел раскол, обусловивший появление EGCS (произносится как eggs) — ответвления GCC, целью которого было отстраниться от руководства FSF разработкой, и Open Source Initiative (OSI) для продвижения менее радикальных и бескомпромиссных взглядов и идей открытого программного обеспечения.

«Главное, в чем они [OSI] стремились отличаться от FSF, это то, что они не осуждали закрытые программные продукты и не заявляли о себе как о движении за свободу, а развивали идеи о том, какие экономические преимущества может принести добровольная работа энтузиастов бесплатно, just for fun.» Но некоторые видели «ее основной целью — попытаться политически маргинализировать Столлмана; и попытке в чем-то небезуспешной.»

О выходе Hurd стали говорить в 1994 г., когда вроде бы удалось запустить Emacs; в качестве даты релиза указывался 2001 г., но этого так и не случилось. Когда в 2005 г. Hurd портировали на L4, Маркус Бринкман сказал, что «теперь мы можем с легкостью исследовать и развивать систему так, как мы захотим», но был вынужден признать, что «я могу собирать простые приложения, используя мой порт glibc, но большинство из них не запускаются, т.к. им требуются файловая система или, скажем, вызовы fork и exec, а у меня там пока только заглушки.»

В середине девяностых на сцене появляется Debian, который благодаря Debian Guidelines, написанных Брюсом Перенсом, становится носителем и выражением «общественного сознания» FOSS-движения, в то время как FSF во многом отстранилась от разработки GNU, сосредоточившись главным образом на политических проблемах движения.

С 1998 г. Debian GNU/Hurd — один из активных проектов Debian, выпускающий инсталляционный и live CD-диски, может рассматриваться как эталонная версия Hurd, однако до сих пор не имеет статуса официального релиза. Качество кода Hurd все еще не позволяет применять его для решения сколько-нибудь реальных задач, поддержка оборудования также весьма ограничена — но его можно полноценно запустить в виртуальной машине, попробуйте.

Когда-то FSF платила программистам за работу над проектами GNU, теперь же большинство из них — это волонтеры или сотрудники компаний, которые заинтересованы в проектах типа GCC и, соответственно, спонсирующие их. Hurd практически выпал из поля зрения, ведь есть Linux, который работает уже здесь и сейчас, так что особой нужды в еще одном ядре нет. Но принцип и обязательство никуда не делись, и, возможно, в будущем идеи GNU Hurd вновь окажутся востребованными.

Alix — истинное ядро GNU

Ричард рассказывает историю, что ядро GNU изначально не должно было называться Hurd.

«Сначала я назвал его Alix (Аликс), так звали мою девушку в то время. Она была системным администратором Unix и как-то обратила внимание на то, что ее имя схоже с названиями многих Unix-систем. Друзьям она в шутку сказала, что „кто-то должен назвать ядро в честь меня“. Я тогда промолчал, но решил, что сделаю ей сюрприз и назову ядро Alix.»

«Впрочем, название не прижилось. Майкл (теперь Томас) Бушнелл, главный разработчик ядра, предпочел имя Hurd, а имя Alix досталось одной из подсистем ядра — той, что перехватывала системные вызовы и обрабатывала их, обмениваясь сообщениями с серверами Hurd.»

«Какое-то время спустя Аликс и я расстались; она сменила имя. Вместе с тем (но независимо) в архитектуре Hurd произошли изменения, и библиотека C стала посылать сообщения серверам напрямую, что сделало компонент Alix ненужным, и он был удален.»

«Но прежде, чем все это произошло, кто-то из ее друзей наткнулся на ее имя в исходниках Hurd и сообщил ей об этом. Так что у нее была возможность найти ядро, названное в ее честь.»

Бушнелл выбрал имя Hurd отчасти из-за того, что получается похоже на «стадо антилоп», отчасти из-за того, что Hurd — это рекурсивная аббревиатура «Hird of Unix-Replacing Daemons», а в свою очередь Hird — это «Hurd of Interfaces Representing Depth». Он говорил, что «мы, насколько мне известно, первый программный продукт, название которого — это пара взаимно-рекурсивных аббревиатур.»

Томас Бушнелл в настоящее время — разработчик Debian и грегорианец.

На переднем крае

В отличие от Linux — монолитного ядра, Hurd использует микроядро, и почти вся функциональность вынесена из пространства ядра в пользовательское пространство. Микроядро — всего лишь прослойка между «железом» и всем остальным, чем обычно занимается монолитное ядро.

В 1996 г. Томас Бушнелл, один из основных архитекторов Hurd на раннем этапе, опубликовал свои идеи в статье «Towards a New Strategy of OS design».

«GNU Hurd, — пишет он, — спроектирован так, чтобы системный код был как можно более ограничен. Программы будут взаимодействовать только с несколькими подсистемами, все остальные части системы динамически заменяемы. Пользователи вольны задействовать их по своему усмотрению, смогут подключать новые компоненты для нужд других пользователей. Нет никакой необходимости в предварительном установлении доверия при взаимодействии между пользователями (т.е. сервисами друг-друга). Система не подвергается уязвимости, „доверяя“ сервисам произвольных пользователей.» На практике это означает, что пользователям не нужно обращаться к некоему супер-пользователю (root) и ждать, пока тот примонтирует файловую систему или загрузит нужный драйвер устройства (как это было в Linux до недавнего времени, пока там не стали появляться некоторые из полезных особенностей микроядер).

«Уже в то время было понятно, — вспоминает один из сотрудников GNU, — и это обсуждалось в академических кругах, что микроядерная архитектура будет иметь проблемы с производительностью (связанные, главным образом, с большим числом переключений контекста из-за необходимости обмена сообщениями между демонами, по сравнению с традиционной обработкой системных вызовов в монолитных ядрах). [Ричард] Рашид, исследователь из CMU, в своей работе предположил, что эта проблема не настолько серьезная. Тогда казалось, по крайней мере мне, что мы здесь в GNU, при скудном финансировании, умудряемся не только программировать и бороться за свободу, но и одними из первых воплощать в жизнь самые последние академические исследования computer science. Во всяком случае, задумка была такая, и мы очень гордились собой и вообще были рады быть в том месте и в то время.»

Hurd был замечательным приключением и экскурсом в самые выдающиеся достижения теории операционных систем своего времени. Целью GNU было стать одновременно Unix-подобной операционной системой и чем-то похожим на Лисп-машины, классические однопользовательские рабочие станции, появившиеся в AI Lab MIT, одном из главных очагов хакерской культуры, из которого вышел и Столлман. «Emacs (с его Lisp-расширениями) определил парадигму для проектирования интерактивных программ. Сначала даже предполагалось, что оконная система тоже будет основана на Lisp.»

«Одно из ранних изменений в концепции GNU произошло, когда стало ясно, что X11 работает довольно неплохо, не „загнется“ и будет свободной программой. Чисто практический вывод: надо брать и пользоваться.»

Что еще могло бы быть

Когда GNU только зарождался, очевидным решением было найти готовое ядро, которое уже находилось бы в общественном достоянии.

Первым выбором Ричарда был TRIX, который разрабатывался в его родном MIT и упоминается в манифесте GNU. «У нас есть прототип ядра, но для полноценной эмуляции Unix еще многого не хватает, — писал он в 1984 г. — Когда мы закончим ядро и компилятор, мы сможем распространять систему GNU, под которую можно будет писать программы.» В декабре 1986 г. программисты GNU все еще продолжали «допиливать TRIX», а в следующем году Столлман стал интересоваться Mach.

Рассматривались и другие идеи, например, использование операционной системы Беркли Sprite и ядра BSD. «RMS был большим и последовательным приверженцем использования как можно большего количества готового кода (как я считаю, зря)», — вспоминал позднее Томас Бушнелл.

«Я бы сразу взял BSD 4.4-Lite и собрал ядро на ее основе. Я хорошо знал этот код, знал, что и как надо делать. Теперь мне очевидно, что у нас бы все замечательно получилось, и мир сегодня был бы совсем другим. RMS хотел сотрудничать с людьми из Беркли в этом направлении. Кто-то из них в самом деле был в этом заинтересован, но были и те, кто сознательно затягивал процесс. Сейчас мне кажется, что это было из-за их собственных планов по запуску BSDI, для которой основанная на BSD 4.4-Lite GNU система была бы совсем нежелательным конкурентом.»

По словам Бушнелла, в итоге Столлман решил, что «Mach — полностью рабочее ядро, 4.4-Lite же готово только частично. Мы выбираем Mach.»

Источник

Анатомия GNU/Linux

Какое-то время назад на Хабре была небольшая волна постов на тему «Почему я [не] выбрал Linux». Как порядочный фанатик я стриггерился, однако решил, что продуктивнее что-нибудь рассказать о своей любимой системе, чем ломать копии в комментариях.

У меня сложилось впечатление, что многие пользователи GNU/Linux слабо представляют, из чего сделана эта операционная система, поэтому утверждают, что она сляпана из попавшихся под руку кусков. В то же время, архитектура большинства дистрибутивов является устоявшейся и регламентируется рядом стандартов, включая стандарт графического окружения freedesktop.org и Linux Standard Base, расширяющий стандарты Unix. Мне при знакомстве с GNU/Linux несколько лет назад для погружения не хватало простой анатомической карты типичного дистрибутива, поэтому я попробую рассказать об этом сам.

Загрузчик

Сеанс операционной системы начинается с загрузчика, как театр с вешалки. Дефолтным загрузчиком сегодня является GNU GRUB, известный так же как GRUB 2. По-прежнему доступна первая ветка, называемая теперь «GRUB Legacy». Другой загрузчик с давней историей — Syslinux.

Задача загрузчика — инициализировать ядро Linux. Для этого, в общем случае, нужно знать, где ядро лежит, и уметь прочитать это место (раздел Ext4, скажем). Ядру в помощь загрузчик обычно так же подтягивает начальный образ загрузки, о котором скажем позже. GRUB умеет много прочего, типа построения весьма сложных меню и чейнлоадинга других загрузчиков (Windows Boot Manager например). GRUB имеет конфигурационный синтаксис, отдалённо напоминающий шелл, и расширяется модулями.

GRUB велик и могуч, порой даже слишком, и встраиваемые системы часто используют компактный Das U-Boot.

Могучий Linux («не оставляй нас, монолит!»). Ядро операционной системы, созданное, чтобы работать с POSIX-совместимыми окружениями. Обычно лежит в /boot/ и содержит в названии слово vmlinuz , где «vm» напоминает нам о поддержке виртуальной памяти, а «z» указывает, что файл сжат.

В рамках одного дистрибутива может поддерживаться несколько вариантов ядра, например:

mainline («основное»);

LTS (с расширенной поддержкой);

rt (патченное для поддержки исполнения в режиме реального времени);

с различными патчами для повышения производительности или защищённости (zen, hardened etc);

libre (почищенное от проприетарных блобов ядро, ожидаемо поддерживающее мало оборудования).

совсем экзотичные варианты с не-Linux ядром типа Debian GNU/Hurd (с ядром GNU Hurd) и Debian GNU/kFreeBSD (с ядром FreeBSD соответственно). Это уже, конечно, не GNU/Linux.

Начальный образ загрузки

Начальный образ загрузки известен так же как initrd и initramfs. Представляет собой архив с образом файловой системы, развёртываемой в оперативную память в начале процесса загрузки. Несёт в себе различные драйверы и скрипты, позволяющие инициализировать оборудование и смонтировать файловые системы.

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

initramfs-tools — детище Debian.

Dracut (произносится созвучно с сушёной кошкой) — в RHEL и производных (CentOS, Scientific Linux etc.). Наиболее гибкий и современный инструмент из перечисленных, если спросите меня.

mkinitcpio поставляется в Archlinux, хотя мейнтейнеры подумывают о Dracut, который уже включён в репозиторий и установочные образы.

make-initrd — свой путь у замечательного отечественного дистрибутива Alt Linux.

Тут же упомянем Plymouth, размещаемый в начальном образе. Это заставка (сплэш-скрин), позволяющая заменить вывод ядра при загрузке на произвольную анимированную картинку, например логотип дистрибутива, что принято в «дружелюбных к пользователю»™ дистрибутивах типа Ubuntu и Fedora.

Система инициализации — это пастырь процессов. Она стартует раньше всех и имеет PID 1. Она определяет уровень запуска системы и жизненный цикл большинства служб. Независмо от того, что за система инициализации представлена, она предлагает исполняемые файлы /sbin/init (или /usr/bin/init , или в том же духе, ну вы поняли).

Холиварный элемент. Много лет с нами была Sysvinit, пришедшая из варианта ОС Unix System V. Sysvinit полагалась в огромной степени на скрипты инициализации. Служил этот инит, в общем, исправно, но постепенно некоторым инженерам стало мозолить глаза последовательное исполнение скриптов и собственно скрипты, известные в жарких спорах за свою распростёртость как «баш-портянки». В конце 00-ых-начале 10-ых как грибы после дождя расплодились альтернативные системы инициализации: OpenRC от Gentoo, Upstart от Canonical, Systemd от Red Hat за авторством Леннарта Поттеринга. В конце концов по причинам техническим и политическим всех сожрала Systemd. Её восхваляют и ненавидят. Восхваляют в основном за простой и лаконичный синтаксис служб. Так, скрипт запуска веб-сервера Apache для классического инита занимает 153 строки включая комментарии, а файл службы из пакета apache в Arch Linux — 15 строк. Недолюбливают в основном за то, что эта система инициализации подрабатывает ещё и резолвером, планировщиком, менеджером сети, менеджером монтирования и Бог весть ещё чем, попирая дзен Unix.

Командная оболочка

Командная оболочка, она же командный интерпретатор или просто шелл. Неискушённый пользователь скажет — «в гробу я этот шелл видал, можно в графическом режиме жить», и будет неправ, поскольку шелл прописан в стандарте POSIX и необходим для работоспособности системы. Есть понятие «оболочка входа» (login shell) — это первый процесс, запускамый при входе пользователя. Он подтягивает опции и переменные окружения из конфигурационных файлов, все последующие процессы запускаются в контексте этого шелла. Что будет запущено в качестве оболочки входа, определяется в /etc/passwd .

Наиболее распространены сегодня следующие оболочки:

Bourne shell (sh) — «тот самый шелл», сложно найти дистрибутив без него.

Bourne again shell (bash) — принят по умолчанию в качестве пользователькой оболочки в большинстве GNU/Linux дистрибутивов и предлагает ряд удобств по сравнению с sh.

Debian Almquist shell (dash) — компактная облочка, совместимая с sh. Традиционно используется в Debian, где /usr/bin/sh на неё ссылается.

Z shell (zsh) — похож на bash, но предлагает оригинальные фишечки для интерактивного ввода. Редко идёт из коробки, но обычно поставляется в репозитории.

BusyBox — утилита для встраиваемых систем, которая предоставляет целое пользовательское окружение, в том числе — POSIX-совместимый шелл (вызывается так: $ busybox sh ).

Графический сервер

Демон, отвечающий за отрисовку окошек. Золотой стандарт графического сервера — X Window System с нами аж с 1984 года. Это именно стандарт, архитектура и набор протоколов. Реализаций за прошедшие годы была уйма, в каждой собственнической Unix-системе была своя. В GNU/Linux (и BSD) долгое время применялся Xfree86. Теперь с нами X.Org Server, или просто Xorg, он отпочковался от XFree86.

X Window System — мощная и богатая система, так, одна из возможностей — сетевая прозрачность. Вы можете запустить на своём хосте графическое приложение с другой машины, даже когда на той машине графический сервер не запущен. При помощи SSH это можно сделать, например, так (может потребоваться небольшая донастройка sshd):

Надо сказать, терминология X Window System контринтуитивна: клиентом называется графическое приложение, а сервером — отрисовывающее. На этот счёт прошлись в классической монографии «The UNIX-HATERS Handbook».

Другая возможность X, отрисовка графических примитивов и текстовых глифов, использовалась в старые времена, когда мужчины были мужчинами и рисовали окошки сами, без тулкитов.

В окружениях рабочих столов активно используется X keyboard extension, расширение, отображающее нажатие клавиш на различные раскладки.

«Иксам» пророчат скорую кончину. Именно обширность и сложность стандарта побудила разработчиков СПО начать работу над новым стандартом — протоколом Wayland. Wayland достиг определённой стадии зрелости и с переменным успехом внедряется дистрибутивами как графический сервер по умолчанию. Тем не менее, проект Wayland начат в 2008 году, а стандарт X ещё не спешит уходить с голубых экранов.

Оконный менеджер Weston

На скриншоте Weston — эталонная реализация композитного менеджера Wayland. Умеет крутить окошки. А ещё его можно запустить внутри другого рабочего стола, просто выполнив в терминале weston .

После старта графический сервер обслуживает иерархию окон. Существует понятие «корневое окно» (root window), оно, в свою очередь, «владеет» окнами панелей, приложений. Окна приложений «владеют» своими модальными окнами. Обычно обои рабочего стола отрисовываются в корневом окне.

Дисплейный менеджер

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

/.xinitrc на запуск необходимого сеанса рабочего стола. Это позволит входить через ядерную консоль и запускать рабочий стол командой startx .

Жизнь без DM Жизнь c SDDM

Типичные представители дисплейных менеджеров:

GDM из набора GNOME;

SDDM из комплекта KDE;

LightDM — универсальный вариант;

FlyDM — из поставки Astra Linux.

Окружение рабочего стола

Окружения рабочего стола (DE) состоит из ряда стандартных компонентов, таких, как:

панель с треем и меню запуска приложений;

хранитель экрана, он же блокировщик экрана;

браузер, которым никто не пользуется;

почтовый клиент (у зажиточных окружений);

Два могучих окружения, GNOME и KDE, сражаются за сердца простых пользователей, а остальные массовые десктопы им завидуют нередко пользуются их наработками. Некоторые хардкорные пользователи предпочитают собирать окружение рабочего стола самостоятельно на базе оконных менеджеров типа Awesome и i3.

Оконный менеджер Window Maker

На скриншоте оконный менеджер Window Maker из состава GNUstep. GNUstep воспроизводит окружение NeXTSTEP. Поставляется в репозиториях большинства дистрибутивов.

Графические тулкиты

Графический тулкит — библиотека или фреймворк, упрощающая рисование формочек и кнопочек, причём в едином стиле. То, чем занимается Windows Forms на ОС другого производителя, а так же занимался некогда полулярный Motif на старых юниксах (Open Motif доступен поныне).

Флагманами в этой категории долгое время были и остаются GTK и Qt. GTK родился как тулкит для свободного графического редактора GIMP и позже переполз под крыло GNOME. Написан на чистом C с классами, имеет официальные байндинги к Python и C++, а ещё породил целый язык общего назначения Vala. Qt — изначально коммерческий проприетарный тулкит, сейчас является свободным ПО (но по-прежнему коммерческим). Написан на C++ с размахом, заменяя стандартную библиотеку и кучу других библиотек и предлагая метаобъектный компилятор (кодогенератор). Имеет байндинги к куче языков. KDE гордо зиждется на этом великолепии.

Графическое API

Mesa — это каркас для видеовывода. Меза предоставляет API OpenGL и, с не столь давних пор, Vulkan (и несколько других API типа VDPAU и VAAPI). Можно сказать, что Mesa берёт на себя вопросы графики, которыми обычно занимается DirectX в ОС другого производителя.

Безопасность

Обширная часть системы, и я недостаточно компетентен, чтобы в неё углубляться, тем не менее, обзорно рассмотрим.

PAM — Pluggable Authentication Modules — модульная система авторизации. Отвечает, как понятно из названия, за авторизацию пользователей в системе, причём разными способами. Через PAM авторизуются в том числе доменные пользователи, в таком случае PAM действует в связке с имплементацией Kerberos (обычно MIT’овский krb5), поскольку сам по себе PAM не работает с удалёнными клиентами. Модули представляют собой разделяемые библиотеки (исполняемые файлы с суффиксом so ) и позволяют делать интересные штуки при входе пользователя. Например, можно создавать домашнюю директорию при первом входе ( pam_mkhomedir.so ) или монтировать файловые системы ( pam_mount.so ).

Классическая утилита su и более молодая sudo предназначены для исполнения комманд от имени другого пользователя (по умолчанию root ). Наиболее значимая разница — su требует пароль пользователя, из-под которого вы хотите работать, а sudo — ваш пароль. sudo гибко настраивается, позволяя запускать только определённые команды определённым пользователям из-под других определённых пользователей, как-то так.

Менеджер авторизации Polkit позволяет непривилегированным процессам взаимодействовать с привилегированными. По сути он похож на sudo, но обладает превосходящей гибкостью и предназначен в первую очередь для приложений, в то время как sudo — утилита для пользователя. Правила пишутся, внезапно, на JavaScript’е.

Linux Security Modules (LSM) — фреймворк внутри ядра Linux, позволяющий накладывать на систему дополнительные моде́ли безопасности. Это достигается при помощи мо́дулей безопасности, не путать с модулями ядра. Наиболее популярные модули безопасности — SELinux и AppArmor. Первый явлен миру АНБ и развивается Red Hat, второй рождён в рамках ОС Immunix и сегодня развивается Canonical Ltd. Соответственно, SELinux поставляется в RHEL и производных, а AppArmor — в Ubuntu. Оба модуля имеют сходное назначение и привносят в систему мандатное управление доступом. Оба модуля повышают безопасность системы, не позволяя приложениям делать то, что от них не ожидается. Так, сконфигурированные модули безопасности не дадут веб-серверу шариться по диску вне нескольких ожидаемых директорий. Обратной стороной является необходимость конфигурировать систему безопасности для каждого мало-мальски нестандартно настроенного приложения. Не у многих на это хватает энтузиазма, так что обычно модуль безопасности просто переключается в разрешающий режим.

Антивирусные программы для GNU/Linux существуют, но мне не встречались дистрибутивы, где бы они шли из коробки, кроме специализированных решений для сканирования системы.

Подсистема печати

CUPS — «общая система печати UNIX», рождённая компанией Apple. Система модульная, поддерживает огромное количество устройств и, насколько мне известно, на сегодня не имеет альтернатив. А ещё CUPS имеет веб-интерфейс (по умолчанию на localhost:631).

Морда CUPS

CUPS работает только с печатающими устройствами, сканеры поддерживаются фреймворком SANE. К сожалению, спектр поддерживаемых устройств у SANE не очень широк. Некоторые вендорские драйверы для МФУ обеспечивают одновременно работоспособность сканера и работоспособность принтера через CUPS. Так, например, делает HPLIP от HP Inc. Благдаря HPLIP GNU/Linux может похвастаться отличной поддержкой печатающих устройств от HP. В то же время, HPLIP прикручен к CUPS немного сбоку, и часто проблематично настроить устройства HP только утилитами CUPS, как многие другие принтеры. Приходится использовать hp-setup .

Звуковая подсистема

Продолжительное время основной звуковой подсистемой ядра является ALSA. Некоторые пользователи ошибочно считают, что PulseAudio заменил ALSA. Это не так, PulseAudio — это звуковой сервер, являющийся лишь слоем абстракции, упрощающим управление аудиопотоками. Другим аудиосервером является JACK, который предназначен для профессиональной работы с аудио. Он не столь удобен для пользователя, но обеспечивает низкие задержки и предоставляет гибкую маршрутизацию MIDI-потоков.

Red Hat готовит нам PipeWire на замену PulseAudio и JACK. Следим за событиями.

Межпроцессное взаимодействие

Здесь речь не про низкоуровневые POSIX-штуки типа разделяемой памяти и сокеты. За свой век GNU/Linux повидал несколько подсистем, призванных упростить межпроцессное взаимодействие (IPC) десктоп-приложений. Сейчас правит бал шина сообщений D-Bus, а об остальных позабыли. Для чего это нужно? Например, некая служба посылает в шину сообщение об изменении своего состояния, а апплет панели слушает его и изменяет свой индикатор. Так обычно работают апплеты громкости и клавиатурной раскладки.

Традиционно в различных дистрибутивах GNU/Linux сеть настраивалась скриптами (причём различными). NetworkManager — детище Red Hat, созданное, чтобы править всеми интерфейсами. В годы юности NM вызывал приступы фрустрации у пользователей, но потом всё стало неплохо. NetworkManager позволяет управлять проводными и беспроводными интерфейсами, всевозможными тунелями, виртуальными мостами, VLAN’ами и аггрегированными каналами, причём как при помощи графических фронтендов, так и псевдографического nmtui и текстового nmcli . Вещь удобная и универсальная, в дистрибутивах Red Hat, ожидаемо идёт по умолчанию, в Debian и производных идёт только с рабочим столом, а в «безголовом исполнении» NM опционален. Есть альтернативы попроще, например — Wicd.

Работоспособность WiFi-устройств, как правило, обеспечивает демон WPA supplicant, у которого есть конкурент iwd, написанный ни много ни мало, компанией Intel.

Тут же хочется упомянуть демон Bluez, обеспечивающий работу с Bluetooth-устройствами.

Межсетевой экран

Слава iptables гремит далеко за узким кругом бородатых админов. Это не фильтр сам по себе, а лишь набор утилит в пространстве пользователя, работающий с подсистемой Linux Netfilter. Недавно (в историческом масштабе) добавилась подсистема ядра nftables и соответствующая пользовательская утилита nft. Это было сделано, в первую очередь, для унификации интерфейсов таблиц маршрутизации IPv4, IPv6, ARP и софтовых L2-коммутаторов. В современных дистрибутивах команды iptables являются лишь обёрткой для nftables и не рекомендуются к использованию. В целом, конфиг nft выглядит опрятнее дампа iptables.

Существует пачка высокоуровневых фаерволлов-обёрток над nftables (в том числе графических), так в RHEL и производых из коробки идёт firewalld, а в Ubuntu — UFW.

Пакетный менеджер

Пакетный менеджер — это сердце дистрибутива. Наиболее именитые и с длинной историей — это RPM из мира Red Hat и dpkg из семества Debian. Пример более современного — pacman из Arch Linux. Старожилы RPM и dpkg работают только с локальными пакетами: они их распаковывают, устанавливают и проверяют, что все зависимости удовлетворены. Работой с репозиториями занимаются другие утилиты, являющиеся как бы фронтендом к самому пакетному менеджеру. В RHEL ранее поставлялась утилита yum, на замену которой пришла dnf, в Debian раньше были apt-get и apt-cache, затем их увязали в одну команду apt. Более молодой pacman не имеет видимого пользователю разделения на несколько утилит и предлагает очень простой формат пакетов, которые можно собирать буквально на коленке. Есть и множество других, со своими особенностями. Например nix, который позволяет иметь в системе несколько версий одного пакета.

Новое в исторических масштабах явление — кросс-дистрибутивные системы поставки приложений. Появились в попытке преодолеть ад зависимостей, облегчить труд разработчиков и мейнтейнеров (избавив их от необходимости создавать десятки пакетов под разные версии и ветки GNU/Linux). Наиболее популярные проекты: Flatpack от Gnome, Snap от Canonical и AppImage сам по себе. Они несколько отличаются подходами, но в общем случае обеспечивают установку приложений со всем рантаймом и некоторой степенью изоляции от системы. Штуки удобные, однако подход несколько напоминает традиции тащить все зависимости с устанавливаемой программой в популярной ОС другого производителя. Простоты и порядка в систему не добавляют.

Для перечисленного добра есть красивые обёртки в виде магазинов приложений, два самых ходовых — GNOME Software и KDE Discover.

KDE Discover GNOME Software с фирменной кнопочкой в заголовке окна

Заключение

Краткая результирующая диаграмма:

Современный GNU/Linux в представлении художника

Если присмотреться к перечисленным составляющим GNU/Linux, можно заметить, что львиная доля технологий привносится несколькими крупными организациями. К ним относятся:

проект GNU под эгидой Free Software Foundation;

Red Hat, производитель коммерческого дистрибутива, недавно вошедший в состав IBM;

сообщество kernel.org при поддержке Linux Foundation.

В интернете ради флейма часто вкидывают, мол, поглядите — эти ваши линуксы делают клятые корпорации, где ваше хвалёное сообщество? Я думаю, не стоит противопоставлять отдельных энтузиастов и организации: все они вращают колесо open source. В конце концов, в больших организациях трудятся обычные люди. В итоге мы имеем очень динамичную систему, в которой не без причины компоненты сменяются один за другим, всё это куда-то движется, и, в общем-то, год от года хорошеет. Я надеюсь, в этом очерке удалось дать представление об анатомии GNU/Linux, а может быть и заинтересовать кого-нибудь закопаться поглубже.

Большое спасибо @ajijiadduh, который отловил огромное количество опечаток сразу после публикации, и всем прочим пользователям, указавшим на ошибки.

Правки и предложения вы можете присылать по адресу https://gitlab.com/bergentroll/gnu-linux-anatomy.

Copyright © 2020 Антон «bergentroll» Карманов.

Источник