Просматривая статьи для перевода на translated.by я наткнулся на предложение перевести статью GNU or Linux? за авторством David Chisnall. Автор предлагает разобраться чего же больше в ОС — GNU или же Linux? Собственно перевод этой статьи и предлагается Вашему вниманию.
GNU или Linux?
Ни одна другая система не испытывала таких споров вокруг своего имени. Огромное количество флейм войн началось после заявление FSF о том, что такие дистрибутивы как Ubuntu и Fedora должны называться GNU/Linux, вместо Linux. Пытались ли они просто заработать на чужом труде, или их аргументы имеют место быть?
Чтобы разобраться в этом вопросе давайте взглянем на то, что происходит, когда вы запускаете GNU/Linux систему — сколько используется GNU кода, а сколько Linux кода. Разработчик использует огромное количество GNU кода, к примеру GCC и GNU Make, но насколько это справедливо и для конечного пользователя?
Что делает Ядро?
Перед тем как начать разбираться где же GNU биты, а где Linux, важно понять, что именно делает ядро. Ядро выполняет две главные задачи:
* Освобождает разработчиков от необходимости изучать низкоуровневую архитектуру. Для этого необходимо наличие большого количества драйверов к устройствам и единых интерфейсов к этим драйверам. Хорошим примером служит Сокет-интерфейс. Когда вы пишете сетевой код, вы просто открываете сокет и пишите в него данные. Вам не надо заботится о типе сетевого оборудования пользователя и низлежащих протоколах.
* Изолирует запущенные программы друг от друга. Изолировать процессы платформо-независимым методом просто: Позволить процессам использовать только непривилегированные инструкции процессора. К сожалению, такой подход сделает невозможным любые операции ввода/вывода для программ, что делает все программы бессмысленными. Для снятия этого ограничения существует системный вызов — механизм, который позволяет запущенному процессу запрашивать ядро для совершения привилегированной операции от имени запрашивающего процесса. Обычные примеры — запись в файл (виртуальный диск), выделение памяти, или доступ к экрану или клавиатуре.
Механизм, который используется системным вызовом, платформо-зависим. На x86 платформе распространенным методом был вызов исключения, хотя новые процессоры от AMD и Intel предоставляют инструкции, позволяющие выполнить это еще быстрее. При этом управление переходит к ядру, которое решает, как интерпретировать значения в регистрах и на стеке, а также, какие действия предпринять.
Взгляд со стороны разработчика.
Важным стандартом при программировании для *NIX или в *NIX является единая спецификация UNIX — супермножество POSIX, которое включает всё, что должно быть в UNIX системе. Код, написанный согласно этому стандарту, переносим среди ряда UNIX-подобных систем.
Стандарт не описывает системные вызовы. Наоборот, он описывает Cи-функции, которые служат оберткой для системных вызовов. Когда программист хочет вызвать функцию open (), ему не надо знать, что он поместит указатель в EBX и значение 2 в EAX, а затем вызовет прерывание 8oh; стандартная библиотека Cи реализует все эти функции. Любая нетривиальная программа на Linux будет обращаться к библиотеке Си (libc, для краткости). Существует несколько вариантов реализации стандартной библиотеки Си. У каждого члена семейства BSD есть своя реализация, впрочем как и у любой коммерческой UNIX системы. Какой вариант стандартной библиотеки С используется в Linux зависит от использования; существует несколько версий для встроенных систем, но большинство декстоп дистрибутивов Linux используют GNU libc.
По количеству кода ядро и libc практически равны. На двоих они предоставляют интерфейс разработчика к системе. Поскольку стандарт определяет только Cи-интерфейсы, а не системные вызовы, то и большинство кода написано с использованием стандартное библиотеки Cи. Это правило справедливо и для других языков; если вы, к примеру, запускаете некий java или python код, то он будет получать доступ к ядру через библиотеку Cи. Для некоторых языков существует своя стандартная библиотека от GNU Project. Например, любой С++ код будет использовать GNU libstc++ на GNU/Linux платформах. Некоторые дистрибутивы также включают GNU-реализации для Java библиотек, хотя такая практика уже не так популярна, учитывая, что Sun-версии стали open source. Даже если вы используете Sun Java библиотеки, вы по-прежнему используете GNU libc на этих платформах для любого Java приложения.
C C++ нюансов еще больше, чем с другими языками. Когда вы линкуете два модуля (к примеру, исполняемый файл и библиотеку), то сразу несколько стандартов описывают модель взаимодействия этих двух модулей. При вызове функции из другого модуля необходимо явно определить порядок аргументов на стеке и в регистрах, кто очистит память впоследствии и так далее. В С++ много чего должно быть явно определено для использования классов в различных модулях. Этот набор стандартов называется Бинарный Интерфейс Приложений (Application Binary Interface, ABI). В Linux, С++ ABI определен в GCC, который является пакетом GNU, как упоминалось ранее. Скомпилированный С++ код, независимо от того, какой компилятор использовался, должен подчиняться стандартам GNU, в противном случае такой код не сможет быть повторно использован другим С++ кодом.
Загрузка системы.
Современные GNU/Linux дистрибутивы начинают процесс загрузки с GRUB (GRand Unified Bootloader), который также является частью проекта GNU. (Хотя, технчиески, загрузка начинается в BIOS или другой прошивке, и это применимо для всех систем, которые запускаются на аппаратной платформе.) GRUB не создавался специально для Linux. Он может запускать и другие ОС и является стандартом для запуска некоторых систем на архитектуре x86, включая OpenSolaris и гипервизор Xen.
Затем GRUB передает управление ядру, которое продолжает инициализировать систему и конфигурирование драйверов. Ядро в свою очередь передает управление процессу init. Этот процесс отвечает за создание других процессов.
На Linux системах, init это очень маленькая программа, которая делает нечто большее, чем просто запуск скрипта. В некоторых дистрибутивах init заменен на Upstart, программу, которая не является ни частью Linux, ни частью GNU, и имеющая более сложную управляемую событиями модель. Скрипты, запущенный init’ом или Upstart’ом — это просто набор команд, интерпретируемых командной оболочкой (shell).
Спецификация POSIX содержит описание минимальной функциональности оболочки. Если вы хотите писать портативные shell-скрипты, то можете оставаться в рамках данной ограниченной функциональности, и, в итоге, получите скрипты, которые будут идти на всех UNIX-подобных системах.
Однако, большинство init скриптов не портируемы. Они используют расширенную функциональность командной оболочки, присутствующей в большинстве Linux дистрибутивов — Bash, командная оболочка от GNU.
Что в стандарте?
Единая Спецификация UNIX содержит намного больше, чем просто набор Cи-функций. В частности, стандарт определяет набор пользовательских утилит, которые обязаны присутствовать в UNIX-подобных системах. Многие программы используют эти утилиты через shell-скрипты или другие вызовы. Большинство из них содержатся в пакете корневых утилит GNU. Опять-таки, сравнивая количество строк кода, размер корневых утилит сравним с размером ядра.
Можно предположить, что эти утилиты не столь важная часть системы, однако это не так. Без утилит большинство init скриптов просто не запустятся (даже при наличии Bash), а система будет непригодна к использованию. Большинство инсталляторов также не запустятся, а это значит, что вы не сможете установить ни одной программы. Даже базовая функциональность, такая как копирование файлов использует корневые утилиты.
Единая UNIX Спецификация предоставляет список из 175 программ, которые должны присутствовать в каждой UNIX системе. Большинство из которых (с некоторыми исключениями, типа vi) созданы GNU и присутствуют в большинстве Linux дистрибутивов. Часть из них никогда не используются обычными пользователями; к примеру, стандарт предписывает наличие c99 и fort77 утилит для компилирования программ написанных на C и Fortran (обе утилиты предоставляются GNU).
На что еще следует обратить внимание?
Ранее я говорил, что у ядра две роли. Главная роль в предоставлении программам пользователя доступ к аппаратной части. Поэтому большинство Linux кода (и кода большинства других ядер) состоит из драйверов устройств. Но, отдельно стоит упомянуть о графике.
Старая модель драйвера XFree86 слабо зависела от ядра. Х-сервер запускался как привилегированный процесс и получал прямой доступ к аппаратной части. Я сам видел живой пример этого при попытке использования бинарного Linux драйвера Matrox под FreeBSD. Хоть драйвер и был написан для Linux, он прекрасно встал на FreeBSD, т.к. он напрямую взаимодействовал с Х-сервером и железом, а вовсе не с ядром FreeBSD.
Новые драйвера используют Инфраструктуру прямого рендеринга (Direct Rendering Infrastructure (DRI)). Эта система состоит из двух компонентов, называемых DRI и DRM. DRI — это драйвер пользовательского окружения, который снабжает командами аппаратную часть и предоставляет API другим пользовательским программам. DRM, в свою очередь, является маленьким модулем ядра, который проверяет команды и передает их аппаратной части.
Часто при холиварах на тему «готов ли Linux для десктопа» люди спрашивают, а как хорошо работает 3D в Linux? Вообще-то, обработка 3D это не задача Linux на большинстве системах. Linux всего-лишь предоставляет прямой интерфейс к аппаратной части, а уже X.Org пишет драйвера. Эти же драйвера могут быть запущены на FreeBSD, OpenBSD и еще ряде систем. В мире GNU/Linux систем Linux не занимается разработкой драйверов для одной из сложнейших частей аппаратной составляющей современного дектопа/лэптопа.
С изобретением FUSE, которая также работает на FreeBSD, NetBSD, and Mac OS X, ядро часто перестает предоставлять все драйвера для файловых систем, что еще больше умаляет роль «Linux» в системе.
Удаление GNU или Linux.
Возможно самый правдивый тест на важность того или иного компонента системы состоит в том, насколько просто обойтись без данного компонента в системе. Некоторые Linux платформы используют не так много GNU программ; например использование busybox для утилит командной строки и uclibc для стандартной библиотеки. Часть GNU платформ, такие как Nexenta или Debian GNU/kFreeBSD не используют ядро Linux.
Чтобы оценить важность Linux, давайте взглянем на Linux совместимое окружение в FreeBSD. При запуске Linux программ на FreeBSD, происходит установка модифицированного обработчика системного вызова, который вызывает функции ядра FreeBSD, в ответ на системные вызовы Linux. Этот поход позволяет запускать программы, написанные под Linux, без их изменения.
Для того чтобы данный метод работал, часто устанавливают урезанную версию Linux в отдельном окружении. Программы написанные под Linux в итоге смогут найти все необходимые библиотеки и утилиты, включая GNU утилиты, GNU grep, Bash и другие пакеты.
О чем это говорит? Это говорит о том, что если вы хотите запустить GNU/Linux программу на другой системе, то это легко выполнимо без Linux, а вот без GNU обойтись не так-то просто.
Безусловно, большинство программ успешно запустятся без всяких режимом совместимости, если вы их перекомпилируете. В этом случае они не будут использовать GNU libc, GNU утилиты или bash. Некоторые программы для успешной компиляции требуют GNU компилятор или GNU Make, однако, после компиляции эти программы больше не потребуют никаких GNU утилит, кроме:
программ, использующих С++, которые скорее всего будут использовать GNU libstdc++. программ, явно использующих одну из многих GNU библиотек.
Так что удаление GNU из GNU/Linux видится намного более сложным, нежели удаление Linux. PC-BSD или Nexenta — это хорошие десктопные ОС без капли Linux кода внутри, но с большим количеством GNU кода. Те Linux системы, которые не так сильно зависят от GNU кода — это сплошь интегрированные системы, названия которых не знакомы пользователям десктопных и серверных вариантов Linux.
Так как же стоит говорить, Linux, GNU или GNU/Linux? Я называю GNU, потому что, как программист и пользователь, я пользуюсь, в большинстве своем, теми инструментами, которые разработаны GNU. Когда я портирую код из FreeBSD, проблемы возникают только в корневых утилитах или в стандартной библиотеке Си. Если бы я хотел запустить этот же код на HURD или любой другой GNU системе, то я бы использовал те же самые интерфейсы.
В общем, я предпочитаю выделять дистрибутивы, типа Fedora или Ubuntu, и не упомянать GNU или Linux. Система включает в себя огромное количество кода из различных источников. Среди самых больших поставщиков кода фигурируют Проект GNU и X.org, но Ubuntu GNOME/X.Org/GNU/Linux звучит слегка длинновато. А включая в названия системы такую небольшую и без проблем удаляемую часть, как Linux, поступают несправедливо по отношению к множеству разработчиков, чей код также присутствует в системе.
