Кто создатель ядра linux

Что такое ядро Linux

Ядро Linux за авторством Линуса Торвальдса недавно отметило юбилей, вот уже три десятилетия оно используется в компьютерах по всему миру. Благодаря тому, что оно перенесено на множество платформ, его можно встретить практически везде, в персональных компьютерах, смартфонах, носимой электронике, бытовой технике и сетевых устройствах.

Так что же делает ядро Linux и почему оно так востребовано? Мы рассмторим архитектуру ядра, его основные задачи и интерфейсы. Это поможет понять его преимущества и недостатки.

Что такое ядро Linux

1. На чём написано ядро

Несмотря на то, что ассемблерный код позволяет достичь наилучшей производительности, его возможности весьма ограничены, поэтому большая часть кода написана на языке C, его доля достигает 98%. На ассемблере написаны только небольшие вставки, повышающие производительность, архитектурно-зависимые функции и загрузчик.

2. Архитектура ядра

Уровень доступа к ресурсам компьютера зависит от того, какое ядро использует операционная система. Привилегии ядра выше остальных приложений, а работает оно в едином адресном пространстве. В зависимости от того, сколько задач выполняется на уровне ядра, различают несколько типов ядер. Самые популярные – это монолитное (Linux), микроядро (macOS) и гибридное (Windows).

Ядро Linux монолитное, большая его часть хранится в одном файле. Однако, это не признак монолитного ядра, модули вполне могут храниться отдельно. Основная его особенность заключается в том, что оно обрабатывает все процессы, кроме пользовательских приложений. То есть управление процессами и памятью, драйверы, виртуальная файловая система, сетевой стек и многое другое – это всё заботы ядра, которые к тому же имеют самый высокий уровень доступа к аппаратной части компьютера.

Однако, это не означает то, что пользовательские приложения не могут выполнять схожие функции. Например, система инициализации Systemd помимо прочего выстраивает иерархию процессов поверх групп ядра cgroups, а демоны, вроде PulseAudio, контролируют работу устройств, расширяя функциональность драйверов.

Также стоит понимать, что ядро хоть и монолитное, но состоит из внутренних модулей, которые загружаются только по необходимости, а не все сразу. Некоторые модули хранятся отдельно от ядра, в основном это дополнительные драйверы устройств.

Интерфейсы, имена переменных и структура каталогов системы определяются стандартами POSIX, что делает Linux UNIX-подобной системой. Линус Торвальдс, создатель ядра, выбрал UNIX по той причине, что имелась база приложений, необходимых для функционирования операционной системы, утилиты GNU. Однако, он не разделяет идеи философии UNIX, одна программа – одно действие, текстовый вывод информации как универсальный интерфейс. По его мнению они не отражают запросы современных пользователей.

3. Что делает ядро

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

На обработке прерываний задачи ядра не заканчиваются, оно содержит в себе драйверы устройств. Драйверы нужны для того, чтобы обработать поступающие с устройств сигналы, а команды приложений перевести в машинный код.

Драйверы занимают большую часть ядра. Некоторые из них представлены сразу в виде бинарных файлов, что противоречит идеям фонда СПО. Версия ядра без закрытых драйверов называется Linux-libre, на практике его использование крайне затруднительно, так как собрать компьютер на основе комплектующих только с открытыми драйверами у вас едва ли получится.

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

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

Со стороны пользовательских приложений всё это выглядит как настоящее оборудование, с той лишь разницей, что общение с процессором и памятью происходит не напрямую, а с помощью системных вызовов. Для периферийных устройств имеются символьные и блочные ссылки в каталоге /dev, последние отличает то, что ни работают с блоками фиксированного размера.

Несмотря на то, что ядро контролирует все процессы, само по себе оно ничего не делает, ему нужны пользовательские программы и их процессы. Среди базовых приложений стоит отметить утилиты проекта GNU, без них не обходится ни один дистрибутив Linux. Например, командная оболочка Bash позволит вам вводить команды в консоли.

4. Версии ядра

Запись версии ядра можно представить в виде: A.B.C-D.

• A – это версия ядра, изначально планировалось повышать номер только после значительной переработки ядра, но сейчас это делают после достаточного количества правок и нововведений примерно два раза за десятилетие.
• B – это ревизия ядра, обновление происходит каждые 2-3 месяца. Некоторые из них получают долгосрочную поддержку (LTS – long term support). Последним таким ядром стало 5.10. Каждая ревизия имеет большой список изменений, которые сначала проверяют тестировщики.
• C и D отвечают за небольшие правки в коде ядра. С увеличивается в том случае, если были обновлены драйверы устройств, а D – когда вышел очередной патч безопасности. Эти номера могут меняться практически каждый день.

Узнать версию ядра можно с помощью команды:

5. Где хранятся файлы ядра

Файлы ядра хранятся в каталоге /boot. Непосредственно само ядро находится в запакованном виде в файле vmlinuz, где z как раз и указывает на то, что ядро сжато для экономии места. Файл initrd.img – это первичная файловая система, которая монтируется перед тем, как подключить реальные накопители к виртуальной файловой системе VFS. Там же содержатся дополнительные модули ядра, поэтому этот файл может быть больше самого ядра. В файле system.map можно найти адреса функций и процедур ядра, что будет полезно при отладке.

Выводы

Подведём итоги. Теперь вы знаете что такое ядро Linux. Ядро — это самая привилегированная программа на компьютере. Если говорить конкретно о ядре Linux, то оно монолитное. Иными словами, в режиме ядра работает всё необходимое для управления ресурсами компьютера. В пользовательском режиме также имеются программы для управления, но они лишь расширяют возможности ядра.

Соответствие стандартам POSIX позволило перенести ядро на множество платформ. Но следование философии UNIX во многих аспектах дистрибутивов Linux имеет как плюсы, так и минусы. Простые приложения с выводом в терминал хорошо подходят для серверов, но для домашнего использования такой подход едва ли может привлечь широкие массы.

К примеру, Android использует ядро Linux, но не утилиты GNU и в целом не пытается стать похожим на UNIX, что во многом обеспечило его популярность. Так что ядро – это лишь инструмент, а цели могут быть любыми, от запуска терминала и до создания суперкомпьютеров.

Ядру Linux исполнилось 30 лет ⁠ ⁠

25 августа 1991 года после пяти месяцев разработки 21-летний студент Линус Торвальдс объявил в телеконференции comp.os.minix о создании рабочего прототипа новой операционной системы Linux, для которой было отмечено завершение портирования bash 1.08 и gcc 1.40. Первый публичный выпуск ядра Linux был представлен 17 сентября. Ядро 0.0.1 имело размер 62 Кб в сжатом виде и содержало около 10 тысяч строк исходного кода. Современное ядро Linux насчитывает более 28 млн строк кода. По данным исследования, проведённого в 2010 году по заказу Евросоюза, приблизительная стоимость разработки с нуля проекта, аналогичного современному ядру Linux, составила бы более миллиарда долларов США (расчёт производился, когда в ядре было 13 млн строк кода), по другим оценкам — более 3 миллиардов.

Ядро Linux было создано под впечатлением от операционной системы MINIX, которая не устраивала Линуса своей ограниченной лицензией. Впоследствии, когда Linux стал известным проектом, недоброжелатели пытались обвинить Линуса в прямом копировании кода некоторых подсистем MINIX. Нападение отразил Эндрю Таненбаум, автор MINIX, который поручил одному из студентов провести детальное сравнение кода Minix и первых публичных версий Linux. Результаты исследования показали наличие только четырёх несущественных совпадений блоков кода, обусловленных требованиями POSIX и ANSI C.

Первоначально Линус задумал назвать ядро Freax, от слов «free», «freak» и X (Unix). Но имя «Linux» ядро получило с лёгкой руки Ари Лемке (Ari Lemmke), который по просьбе Линуса разместил ядро на FTP-сервере университета, назвав директорию с архивом не «freax», как просил Торвальдс, а «linux». Примечательно, что предприимчивый делец Вильям Делло Крок (William Della Croce) сумел зарегистрировать торговую марку Linux и хотел со временем собирать отчисления, но позднее передумал и передал все права на торговую марку Линусу. Официальный талисман Linux-ядра, пингвин Tux, был выбран в результате соревнования, состоявшегося в 1996 году. Имя Tux расшифровывается как Torvalds UniX.

Динамика роста кодовой базы (количество строк исходного кода) ядра:

0.0.1 — сентябрь 1991, 10 тыс. строк кода;

1.0.0 — март 1994, 176 тыс. строк кода;

1.2.0 — март 1995, 311 тыс. строк кода;

2.0.0 — июнь 1996, 778 тыс. строк кода;

2.2.0 — январь 1999, 1.8 млн. строк кода;

2.4.0 — январь 2001, 3.4 млн. строк кода;

2.6.0 — декабрь 2003, 5.9 млн. строк кода;

2.6.28 — декабрь 2008, 10.2 млн. строк кода;

2.6.35 — август 2010, 13.4 млн. строк кода;

3.0 — август 2011, 14.6 млн. строк кода.

3.5 — июль 2012, 15.5 млн. строк кода.

3.10 — июль 2013, 15.8 млн. строк кода;

3.16 — август 2014, 17.5 млн. строк кода;

4.1 — июнь 2015, 19.5 млн. строк кода;

4.7 — июль 2016, 21.7 млн. строк кода;

4.12 — июль 2017, 24.1 млн. строк кода;

4.18 — август 2018, 25.3 млн. строк кода.

5.2 — июль 2019, 26.55 млн. строк кода.

5.8 — август 2020, 28.4 млн. строк кода.

5.13 — июнь 2021, 29.2 млн. строк кода.

Прогресс развития ядра:

Linux 0.0.1 — сентябрь 1991, первый публичный выпуск, поддерживающий только CPU i386 и загружающийся с дискеты;

Linux 0.12 — январь 1992, код начал распространяться под лицензией GPLv2;

Linux 0.95 — март 1992, обеспечена возможность запуска X Window System, реализована поддержка виртуальной памяти и раздела подкачки.

Linux 0.96-0.99 — 1992-1993, началась работа над сетевым стеком. Представлена файловая система Ext2, добавлена поддержка формата файлов ELF, представлены драйверы для звуковых карт и контроллеров SCSI, реализована загрузка модулей ядра и файловой системы /proc.

В 1992 году появились первые дистрибутивы SLS и Yggdrasil. Летом 1993 года были основаны проекты Slackware и Debian.

Linux 1.0 — март 1994, первый официально стабильный релиз;

Linux 1.2 — март 1995, существенное увеличение числа драйверов, поддержка платформ Alpha, MIPS и SPARC, расширение возможностей сетевого стека, появление пакетного фильтра, поддержка NFS;

Linux 2.0 — июнь 1996 года, поддержка многопроцессорных систем;

Март 1997: основан LKML, список рассылки разработчиков ядра Linux;

1998 год: запущен первый попавший в список Top500 кластер на базе Linux, состоящий из 68 узлов с CPU Alpha;

Linux 2.2 — январь 1999, увеличена эффективность системы управления памятью, добавлена поддержка IPv6, реализован новый межсетевой экран, представлена новая звуковая подсистема;

Linux 2.4 — февраль 2001, обеспечена поддержка 8-процессорных систем и 64 Гб ОЗУ, файловая система Ext3, поддержка USB, ACPI;

Linux 2.6 — декабрь 2003, поддержка SELinux, средства автоматического тюнинга параметров ядра, sysfs, переработанная система управления памятью;

В 2005 году представлен гипервизор Xen, который открыл эру виртуализации;

В сентябре 2008 года сформирован первый релиз платформы Android, основанной на ядре Linux;

В июле 2011 года после 10 лет развития ветки 2.6.x осуществлён переход к нумерации 3.x. Число объектов в Git-репозитории достигло 2 млн;

В 2015 году состоялся выпуск ядра Linux 4.0. Число git-объектов в репозитории достигло 4 млн;

В апреле 2018 года преодолён рубеж в 6 млн git-объектов в репозитории ядра.

В январе 2019 года сформирована ветка ядра Linux 5.0. Репозиторий достиг уровня 6.5 млн git-объектов.

Опубликованное в августе 2020 года ядро 5.8 стало самым крупным по числу изменений из всех ядер за всё время существования проекта.

В ядре 5.13 был поставлен рекорд по числу разработчиков (2150), изменения от которых вошли в состав ядра.

В 2021 году в ветку ядра Linux-next добавлен код для разработки драйверов на языке Rust. Ведётся работа по включению компонентов для поддержки Rust в основной состав ядра.

68% всех изменений в ядро внесены 20 наиболее активными компаниями. Например, при разработке ядра 5.13 10% всех изменений подготовлено компанией Intel, 6.5% — Huawei, 5.9% — Red Hat, 5.7% — Linaro, 4.9% — Google, 4.8% — AMD, 3.1% — NVIDIA, 2.8% — Facebook, 2.3% — SUSE, 2.1% — IBM, 1.9% — Oracle, 1.5% — ARM, 1.4% — Canonical. 13.2% изменений подготовлены независимым участниками или разработчиками, явно не заявившим о своей работе на определённые компании. 1.3% изменений подготовлены студентами, аспирантами и представителями учебных заведений. По числу добавленных в ядро 5.13 строк кода лидирует компания AMD, доля которой составила 20.2% (драйвер amdgpu насчитывает около 3 млн строк кода, что примерно 10% от общего размера ядра — 2.4 млн строк приходится на сгенерированные автоматически заголовочные файлы с данными для регистров GPU).

919 постов 15K подписчиков

Правила сообщества

Все дистрибутивы хороши.

Ура ура ура! Великолепное ядро, великолепная ось!

Спасибо GNU Linux, долгих и продуктивных лет жизни проекту.

Ой, а помните кубунту по почте? Ностальгия мляяя.

Поздравления всем причастным. Купайтесь в море а не в фонтанах. У нас открылась вакансия для линуксоида. @moderator, вчера вы сказали что в комментарии можно

В ядре Linux найдена забытая заплата, влияющая на производительность CPU AMD⁠ ⁠

В ядро Linux 6.0, релиз которого ожидается в следующий понедельник, принято изменение, решающее проблемы с производительностью систем на процессорах AMD Zen. Источником падения производительности оказался код, добавленный 20 лет назад для обхода аппаратной проблемы в некоторых чипсетах. Аппаратная проблема давно устранена и не проявляется в актуальных чипсетах, но старый обход проблемы был забыт и стал источником снижения производительности на системах на базе современных CPU AMD. Новые системы с CPU Intel старый обходной манёвр не затрагивает, так как доступ к ACPI в них осуществляется при помощи отдельного драйвера intel_idle, а не общего драйвера processor_idle.

Обходной манёвр был добавлен в ядро в марте 2002 года для блокирования проявления ошибки в чипсетах, связанной с отсутствием должной установки состояние простоя (idle) из-за задержки обработки сигнала STPCLK#. Для обхода проблемы в реализации ACPI добавлялась дополнительная инструкция WAIT, замедляющая процессор чтобы чипсет успевал перейти в состояние простоя. При проведении профилирования с использованием инструкций IBS (Instruction-Based Sampling) на процессорах AMD Zen3 было выявлено, что процессор проводит значительное время, выполняя заглушку, которая приводит к неверной трактовке состояния нагрузки на процессор и выставлению более глубоких режимов сна (C-State) обработчиком cpuidle.

Подобное поведение отражается в снижении производительности при нагрузках, в которых часто чередуются состояния простоя (idle) и активности (busy). Например, при использовании патча, отключающего обходной манёвр, средние показатели теста tbench увеличиваются с 32191 MB/s до 33805 MB/s.

О документации⁠ ⁠

Разработчики: Документация должна быть понятной, по делу и в официальном стиле
Так же разработчики:

Наименование «tasklet» вводит в заблуждение: оно не имеет ничего общего с «tasks», скорее всего оно связано с плохой водкой, которую в то время выпил Алексей Кузнецов(один из мэйнтейнеров ядра linux).

В ядро Linux 5.4 приняты патчи для ограничения доступа root к внутренностям ядра⁠ ⁠

Линус Торвальдс принял в состав будущего выпуска ядра Linux 5.4 набор патчей «lockdown», предложенный Дэвидом Хоуэллсом (David Howells, работает в Red Hat) и Мэтью Гарретом (Matthew Garrett, работает в Google) для ограничения доступа пользователя root к ядру. Связанная с «lockdown» функциональность вынесена в опционально загружаемый LSM-модуль (Linux Security Module), устанавливающий барьер между UID 0 и ядром, ограничивая определённую низкоуровневую функциональность.

Если злоумышленник в результате атаки добился выполнения кода с правами root, то он может выполнить свой код и на уровне ядра, напирмер, через замену ядра при помощи kexec или чтения/записи памяти через /dev/kmem. Наиболее очевидным следствием подобной активности может стать обход UEFI Secure Boot или извлечение конфиденциальных данных, хранящихся на уровне ядра.

Изначально функции ограничения root развивались в контексте усиления защиты верифицированной загрузки и в дистрибутивах уже достаточно давно для блокирования обхода UEFI Secure Boot применяются сторонние патчи с ограничениями. При этом в основной состав ядра подобные ограничения не включались из-за разногласий в их реализации и опасений нарушения работы существующих систем. Модуль «lockdown» вобрал в себя уже используемые в дистрибутивах патчи, которые были переработаны в форме отдельной подсистемы, не привязанной к UEFI Secure Boot.

В режиме lockdown ограничивается доступ к /dev/mem, /dev/kmem, /dev/port, /proc/kcore, debugfs, отладочному режиму kprobes, mmiotrace, tracefs, BPF, PCMCIA CIS (Card Information Structure), некоторым интерфейсам ACPI и MSR-регистрам CPU, блокируются вызовы kexec_file и kexec_load, запрещается переход в спящий и ждущий режимы, лимитируется использование DMA для PCI-устройств, запрещается импорт кода ACPI из переменных EFI, недопускаются манипуляции с портами ввода/вывода, в том числе изменение номера прерывания и порта ввода/вывода для последовательного порта.

По умолчанию модуль lockdown не активен, собирается при указании в kconfig опции SECURITY_LOCKDOWN_LSM и активируется через параметр ядра «lockdown=», управляющий файл «/sys/kernel/security/lockdown» или сборочные опции LOCK_DOWN_KERNEL_FORCE_*, которые могут принимать значения «integrity» и «confidentiality». В первом случае блокируются возможности, позволяющие вносить изменения в работающее ядро из пространства пользователя, а во втором случае отключается функциональность, которую можно использовать для извлечения конфиденциальной информации из ядра.

При этом важно отметить, что lockdown лишь ограничивает штатные возможности доступа к ядру, но не защищает от модификаций в результате эксплуатации уязвимостей. Для блокирования внесения изменений в работающее ядро при применении эксплоитов проектом Openwall развивается отдельный модуль LKRG (Linux Kernel Runtime Guard).

30 лет Линукса. Интервью с Линусом Торвальдсом. Часть 1

Тридцать лет назад Линусу Торвальдсу был 21 год, он был студентом Хельсинского университета. Именно тогда он впервые выпустил ядро Linux. Анонс этого события начинался так: «Я делаю (свободную) операционную систему (просто в качестве хобби, большой и профессиональной она не будет…)». Три десятилетия спустя все топ-500 суперкомпьютеров в мире работают под Linux, равно как и более 70% всех смартфонов. Linux явно стал и большим, и профессиональным.

В течение тридцати лет Линус Торвальдс руководил разработкой ядра Linux, вдохновив бесчисленное множество других разработчиков и опенсорсных проектов. В 2005 году Линус также создал Git, чтобы было проще управлять процессом разработки ядра, с тех пор Git превратился в популярную систему контроля версий, которой доверяют бесчисленные опенсорсные и проприетарные проекты.

Следующее интервью – одна из серии бесед с лидерами опенсорса. Линус Торвальдс ответил на вопросы по электронной почте, поразмышляв о том, что он узнал за годы руководства большим опенсорсным проектом. В первой части акцент сделан на разработке ядра Linux и Git. «[Linux] был личным проектом, который вырос не из какой-нибудь большой мечты создать новую операционную систему,« — объясняет Линус, — «а в буквальном смысле несколько спонтанно, ведь я изначально просто сам хотел разобраться во входах и выходах моего нового железа для ПК.«

Что касается создания Git и его последующей передачи Джунио Хамано для дальнейшей доработки и поддержки, Линус отметил: «Не собираюсь утверждать, что программирование – это искусство, поскольку на самом деле это большей частью просто хорошая «инженерия». Я горячо верю в мантру Томаса Эдисона об «одном проценте таланта и девяноста девяти процентах упорного труда»: почти все зависит от мелких деталей и ежедневной рутинной работы. Но есть и эта эпизодическая составляющая, называемая «талант», этот «хороший вкус», который сводится не только к решению какой-либо задачи, но и к стремлению решить ее чисто, аккуратно и да, даже красиво. У Джунио есть как раз такой «хороший вкус».

Итак, читайте первую часть этого интервью (есть и вторая). В оригинале она выходит через неделю после первой, и во второй части Линус исследует те уроки и озарения, которые приобрел за три десятилетия во главе разработки ядра Linux.

Разработка ядра Linux

Джереми Эндрюс: Linux повсюду, он вдохновил целый мир опенсорса. Разумеется, так было не всегда. Вы прославились тем, что выпустили ядро Linux еще в 1991 году, скромно сообщив об этом в Usenet в разделе comp.os.minix. Десять лет спустя вы написали увлекательную и глубоко личную книгу под названием «Ради удовольствия: Рассказ нечаянного революционера«, где разобрали большую часть этой истории. В августе этого года Linux празднует тридцатилетие! Это захватывающе, поздравляем! В какой момент на вашем пути вы осознали, что Linux – это уже гораздо больше, чем «просто хобби»?

Линус Торвальдс: возможно, прозвучит слегка потешно, но, на самом деле, это произошло очень рано. Уже к концу девяносто первого (и определенно к началу девяносто второго) Linux вырос значительно сильнее, чем я ожидал.

Да, на тот момент у Linux было, пожалуй, всего несколько сотен пользователей (и даже «пользователей» слишком громко сказано – люди просто возились с ним), и это, возможно, звучит странно, учитывая, насколько Linux вырос впоследствии. Но во многих отношениях, для меня лично, большой поворотный момент наступил, когда я осознал, что другие люди в самом деле пользуются Linux, заинтересованы им, и операционная система начала жить своей жизнью. Люди начали присылать патчи, и система начала делать гораздо больше, чем я изначально мог представить.

Думаю, X11 была портирована на Linux где-то в апреле девяносто второго (не верьте мне на слово, когда я припоминаю даты – слиииишком давно дело было), а еще один серьезный шаг свершился, когда у системы вдруг появился GUI и целый новый набор возможностей.

Чтобы дать широкий контекст – скажу, что в самом деле не начинал с наполеоновских планов или больших ожиданий. Это был личный проект, который вырос не из какой-нибудь большой мечты создать новую операционную систему, а в буквальном смысле несколько спонтанно, ведь я изначально просто сам хотел разобраться во входах и выходах моего нового железа для ПК.

Поэтому, когда я выпустил ту самую первую версию, посыл в самом деле был «смотрите, что у меня получилось» и, разумеется, я надеялся, что другие найдут мою работу интересной, но это не была по-настоящему серьезная, практически-ориентированная ОС. Это была скорее «проверка концепции» и просто личный проект, который я к тому моменту разрабатывал уже несколько месяцев.

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

Просто пример одного по-настоящему фундаментального аспекта: исходная лицензия на копирайт формулировалась примерно так: «допускается распространение в виде исходников, но не за деньги».

Дело в том, что для меня одна из проблем заключалась в реальной дороговизне коммерческого Unix (да, для бедного студента, потратившего все деньги на новый ПК, так и было), поэтому для меня было серьезно и важно обеспечить доступность исходного кода (так, чтобы люди могли с ним пошаманить), и я хотел, чтобы проект оставался открытым для людей вроде меня, которые просто не могли позволить себе альтернатив.

И я изменил лицензию в конце девяносто первого (или, может быть, в самом начале девяносто второго), поскольку нашлись те, кто хотел распространять систему на дискетах в локальных группах пользователей Unix, но при этом хотя бы отбить расходы на дискеты и компенсировать себе время, потраченное на копирование. Причем, я понял, что это, очевидно, совершенно оправданно, и что важнее всего было обеспечить не «полную бесплатность», а «свободную доступность исходников».

К чему это привело: мало того, что люди стали распространять Linux на собраниях в группах пользователей Unix, но и в считанные месяцы появились первые дистрибутивы для дискет, например, SLS и Slackware.

По сравнению с теми первыми, по-настоящему фундаментальными изменениями, все дальнейшие можно считать «пошаговыми». Разумеется, некоторые из этих шагов были весьма велики (систему взяла на вооружение IBM, под мою систему портировали Oracle DB, состоялись первичные коммерческие предложения Red Hat, Android расцвел на смартфонах, т.д.), но лично мне эти события все равно казались не столь революционными, как «люди, которых я даже не знаю, уже используют Linux».

Дж. А.: Вы когда-нибудь сожалели, что выбрали именно такую лицензию, либо завидовали тому, какие деньги сделали другие люди и компании на вашем детище?

Во-первых, мне вполне хватает. Я не баснословно богат, но я – хорошо оплачиваемый программист, занимаюсь любимым делом, сам составляю себе расписание. Не бедствую.

Но не менее важно, что я на 100% уверен: именно такая лицензия во многом определила успех Linux (и Git, если уж на то пошло). Думаю, всем причастным гораздо приятнее знать, что все в равных правах, и никого такая лицензия не выделяет.

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

Думаю, в такой ситуации действительно сложно выстроить сообщество, так как те, кто занимается опенсорсом, всегда будут сознавать, что они «второй сорт». Плюс такая ситуация порождает массу лицензионной бумажной волокиты, чтобы избранные всегда сохраняли свои особые права. Таким образом, в проекте возникает серьезная пробуксовка.

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

Итак, я считаю, что GPLv2 дает практически идеальный баланс «все работают, и правила для всех одинаковы», но при этом все равно требует от людей отдачи сообществу (»долг платежом красен»). Причем, каждый знает, что все остальные люди, вовлеченные в проект, подчиняются одним и тем же правилам, поэтому весь процесс очень равноправный и честный.

Разумеется, обратный эффект заключается в том, что и вы получаете что-то от проекта, в который вложили силы. Разумеется, можно попытаться «запрыгнуть на хвост» проекту и оставаться обычным пользователем, почему нет. Но, избрав такой путь, вы нисколько не будете контролировать проект. Это также может быть вполне нормально, если вам нужна всего лишь непритязательная операционная система, а Linux уже делает все, что вам надо. Но, если у вас есть особые требования, то единственный реальный способ влиять на проект – это участвовать в нем.

При таком подходе все честны. Включая меня. Каждый может сделать форк проекта и пойти своим путем, сказать: «пока, Линус, у меня есть своя версия Linux, и ее поддержку я беру на себя». Я «особенный» только потому что и только до тех пор, пока люди доверяют мне за хорошо сделанную работу. Именно так и должно быть.

То, что «каждый может поддерживать собственную версию» вызывало у некоторых беспокойство по поводу версии GPLv2, но я вижу в этом достоинство, а не недостаток этой лицензии. Несколько парадоксально, но я считаю, что именно это и уберегло Linux от фрагментации: ведь каждый может сделать собственный форк проекта, и это нормально. На самом деле, именно в этом заключается один из ключевых принципов, на основе которых спроектирован «Git» – каждый клон репозитория — это самостоятельный маленький форк, и люди (а также компании) ответвляют собственные версии, именно так и совершается весь процесс разработки.

Итак, форки – не проблема, если потом при слиянии вы добавите в основную ветку только то, что получилось хорошо. Именно здесь вступает в дело GPLv2. Право сделать форк и развивать собственный проект очень важное, но в равной степени важна и другая сторона медали – право впоследствии снова объединиться, если форк показал себя успешным.

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

Итак, отвечая на вопрос, я немного ушел в сторону, но считаю, что это важное отступление. Я решительно не жалею о том, какую лицензию выбрал, поскольку действительно считаю, что в GPLv2 заключается огромная часть успешности Linux.

На самом деле, деньги – не столь серьезный мотиватор. Они не сплачивают людей. Думаю, что, если работаешь над общим проектом и чувствуешь, что реально можешь быть полноправным партнером в рамках этого проекта, то именно это и мотивирует людей.

Дж.А.: В наши дни, если кто-то выпускает исходный код по лицензии GPLv2, то делает это в основном ради работы с Linux. Как вы нашли лицензию, и сколько времени и сил у вас ушло на изучение других существующих лицензий?

ЛТ: В те времена в сообществе еще бушевали серьезные флеймы по поводу BSD и GPL (думаю, отчасти они разжигались из-за того, что у rms настоящий талант бесить людей), так что я встречал разные дискуссии на тему лицензирования только в разных новостных группах usenet, которые я читал (такие источники, как comp.arch, comp.os.minix и т.д.).

Но двумя основными поводами были, пожалуй, банальный gcc – который очень и очень поспособствовал тому, чтобы Linux набрал ход, поскольку мне был абсолютно необходим компилятор для C — и Ларс Виржениус (»Ласу»), другой шведскоязычный студент с факультета компьютерных наук, с которым мы учились в университете на одном курсе (шведскоязычное меньшинство в Финляндии очень невелико).

Ласу гораздо активнее участвовал в дискуссиях по лицензированию и т.п., чем я.

Для меня выбор GPLv2 не был огромной дипломатической проблемой, а был обусловлен в основном тем фактом, что моя изначальная лицензия была столь импровизированной, и ее требовалось обновить, а еще я чувствовал себя в долгу перед gcc, и GPLv2 соответствовала моим ожиданиям «исходники нужно отдавать».

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

Дж. А.: Каков ваш обычный день? Сколько времени вы тратите на написание кода, по сравнению с ревью кода и чтением/написанием электронной почты? Как вы находите баланс между личной жизнью и разработкой ядра Linux?

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

Иными словами, основной объем кода, который я пишу, скорее сводится к «посмотри, а мы это делаем вот так« и в данном случае патч — очень конкретный пример. Легко увязнуть в какой-нибудь теоретической высокоуровневой дискуссии о том, как решить какую-нибудь задачу, и, на мой взгляд, что наилучший способ описать решение — просто привести фрагмент кода, может быть, не весь код – и максимально выпятить его именно таким образом.

Вот почему вся моя реальная работа сводится к чтению и написанию электронной почты. Это в основном коммуникация, а не написание кода. На самом деле, я считаю именно такую коммуникацию с журналистами и техническими блогерами, т.д., самой настоящей частью моего рабочего дня. Возможно, приоритет у этой работы ниже, чем у технических дискуссий как таковых, но я трачу немало времени и на решение таких вопросов.

Да, я уделяю время и ревью кода, но, честно говоря, к тому времени, как я получаю пул-реквест, код, вызвавший вопросы, уже успевает просмотреть множество других людей. Поэтому, хотя я и просматриваю патчи, больше внимания я уделяю объяснениям и истории патча, как он пришел ко мне. Причем, с людьми, с которыми мы работаем достаточно давно, я обхожусь даже без этого: все они занимаются поддержкой тех подсистем, за которые отвечают, и микроменеджмент по контролю их работы – не мое дело.

Итак, весьма часто моя работа заключается в том, чтобы «просто присутствовать», играть роль концентратора, того человека, который управляет релизами и следит за соблюдением правил. Иными словами, моя работа в большей степени связана с процессом поддержки, а не с низкоуровневым кодом.

Дж.А.: Какова ваша рабочая обстановка? Например, комфортнее ли вам работать в затемненной комнате, где ничего не отвлекает, либо в комнате с видовым окном? Вы склонны работать в тишине или под музыку? Какое аппаратное обеспечение вы обычно используете? Выполняете ревью кода в vi, в окне терминала или в навороченной IDE? И есть ли такой дистрибутив Linux, который вы предпочитаете для данной работы?

ЛТ: не могу сказать, что у меня в комнате «темно», но я действительно прикрываю шторами окно у рабочего места, поскольку яркий солнечный свет мне не нравится (правда, в этот сезон в Орегоне его и так не слишком много;). Так что никаких панорам, только (заваленный) стол с двумя 4k мониторами и мощным ПК под столом. И еще пара ноутбуков под рукой, для тестирования и на случай, если какая-то работа прилетит мне в дороге.

И я хочу работать в тишине. Возненавидел щелканье механических винчестеров, к счастью, они давно отправлены в утиль, поскольку я давно переключился на работу исключительно с SSD, вот уже более десяти лет как. Шумные процессорные вентиляторы для меня также неприемлемы.

Вся работа делается в традиционном терминале, хотя, я и не пользуюсь ‘vi’. Я работаю с этим убогим «micro-emacs», который не имеет ничего общего с emacs от GNU, с той оговоркой, что некоторые привязки клавиш у них похожи. Я привык работать с этим редактором еще в Хельсинском университете, будучи юнцом, и так и не смог от него отучиться, хотя, подозреваю, вскоре мне придется это сделать. Несколько лет назад я сварганил для него (очень ограниченную) поддержку utf-8, но редактор уже старый, и во всех его аспектах сквозит, что написан он был в 1980-е, а та версия, которой пользуюсь я – это форк, не поддерживаемый с середины 90-х.

В Хельсинском университете этот редактор использовался, поскольку он работал под DOS, VAX/VMS и Unix, почему и мне довелось с ним познакомиться. А теперь он просто вшит мне в пальцы. На самом деле, давно пора переключиться на какую-то альтернативу, которая исправно поддерживается и как следует воспринимает utf-8. Пожалуй, попробую ‘nano’. Мой же наспех слепленный антикварный мусор работает на том уровне «вполне приемлемо», что у меня не возникало острой нужды переучивать мои старые пальцы на новые фокусы.

Итак, моя настольная рабочая среда весьма безыскусна: открыто несколько текстовых терминалов, еще браузер с почтой (плюс еще несколько вкладок, в основном с техническими и новостными сайтами). Я хочу, чтобы значительная часть рабочего стола была свободна, поскольку привык работать с достаточно большими окнами терминалов (100×40 – можно сказать, таков у меня исходный размер окна по умолчанию), и у меня бок о бок открыто несколько окон терминала. Поэтому работаю с двумя мониторами по 4k.

На всех моих машинах я использую Fedora, не потому, что этот дистрибутив для меня однозначно «предпочтителен», а потому, что я к нему привык. Меня не особо волнует выбор дистрибутива, я расцениваю дистрибутив в основном как вариант установки Linux на машине, как среду, в которой настроены все мои инструменты, так, чтобы я мог просто заменить ядро и сосредоточиться на работе с ним.

Дж. А.: Публичное обсуждение разработки ядра происходит в почтовой рассылке по ядру Linux, и трафик там запредельный. Как вы успеваете разгребать столько почты? Вы исследовали другие решения для совместной работы и коммуникации вне почтовой рассылки, либо простая почтовая рассылка чем-то идеально подходит для той работы, которую вы делаете?

ЛТ: О, я не читаю саму рассылку, посвященную разработке ядра, годами не читал. Там слишком много всего.

Нет, суть рассылки по разработке ядра в том, что она ставится в копию во всех дискуссиях (ладно — некоторых рассылок по разработке ядра это касается, ведь их много – и тогда традиционная lkml используется в качестве резервного варианта, если для заданного вопроса не находится более узконаправленная рассылка). Таким образом, когда к дискуссии подключается новичок, он может посмотреть историю и контекст проблемы, просто изучив рассылку, посвященную разработке ядра.

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

В настоящее время я предпочитаю использовать функционал lore.kernel.org, так как работает он очень хорошо, и вокруг него уже выстроены некоторые другие инструменты. Поэтому дискуссии можно не автоматически упаковывать в мои собственные почтовые архивы, а сохранять вот таким образом – тогда они видны. Но общий поток задач концептуально остается прежним.

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

Причем, модель с почтовой рассылкой (и сопровождающими ее инструментами) в самом деле работает очень хорошо. Я не о том, что люди не пользуются иными средствами коммуникации кроме электронной почты (имею в виду и личные переговоры, и участие в почтовых рассылках): многим очень нравятся различные чаты в режиме реального времени (традиционный вариант — IRC). Причем, хотя это и никогда не было моим коньком, очевидно, что многим нравится метод мозгового штурма. Но модель с «списком рассылки, используемым в качестве архива» работает очень хорошо, и бесшовно сшивается как с «рассылкой патчей от разработчика к разработчику в электронных сообщениях», так и с «отправкой отчетов по проблемам в виде электронной почты».

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

Дж.А.: Я пристально следил за разработкой ядра на протяжении примерно десяти лет, вел на эту тему блог в KernelTrap и писал о новых возможностях по мере их развития. Бросил заниматься этим примерно к моменту выхода версии ядра 3.0, выпущенной спустя 8 лет, когда выходили версии с номерами 2.6.x. Можете ли резюмировать, какие наиболее интересные события произошли с ядром после релиза версии 3.0?

ЛТ: Эх. Это было так давно, что я даже не знаю, с чего начать резюмировать. Прошло уже десять лет с момента выхода версии 3.0, и за это десятилетие мы успели внести много технических изменений. Архитектура ARM выросла, и ARM64 стала одной из наших основных архитектур. Много-много новых драйверов и новая базовая функциональность.

В любом случае, что самое интересное за последнее десятилетие – как нам удалось удержать действующую модель разработки по-настоящему ровной, и что в ней не изменилось.

За десятилетия мы попробовали много разных схем версионирования, у нас были разные модели разработки, но релиз 3.0 фактически оказался именно тем, в котором окончательно оформилась модель, используемая нами с тех пор по сей день. В этой версии мы, так сказать, официально заявили, что «релизы выпускаются по времени, номера версий – это просто номера, и в них нет никаких зависимостей компонентов».

Мы затеяли всю историю с привязкой релизов ко времени и с окном по сведению патчей (merge window) во времена 2.6.x, поэтому сама эта инициатива не нова. Но именно в 3.0 последние реликты «у номера есть значение» были выброшены на свалку.

У нас была и случайная схема нумерации (в основном до версии 1.0), у нас была целая модель «нечетные минорные номера соответствует версии ядра, которая находится в разработке, четные означают стабильное ядро, готовое к продакшену», после чего в версиях 2.6.x мы перешли к модели с привязкой релизов по времени. Но у людей по-прежнему оставался вопрос «Что должно произойти, чтобы увеличился мажорный номер». И в версии 3.0 было официально объявлено, что четный мажорный номер версии не несет никакой семантики, и что мы всего лишь стараемся придерживаться простой нумерации, с которой было бы удобно обращаться, и которая бы чрезмерно не разрасталась.

Итак, за последние десятилетия мы внесли совершенно колоссальные изменения (в Git легко посмотреть некоторую статистику в числовом выражении: примерно три четверти миллиона коммитов, сделанных 17 тысячами участников). Но сама модель разработки остается весьма ровной и стабильной.

Так, конечно, было не всегда. Первые двадцать лет в истории разработки ядра были полны поистине болезненных перемен в модели разработки. Последнее десятилетие получилось гораздо более предсказуемым в плане выхода релизов.

Дж.А.: На настоящий момент последний релиз — 5.12-rc5. Как стандартизирован процесс релизов? Например, изменения какого рода попадают в -rc1, по сравнению с -rc2 и так далее? И в какой момент вы решаете, что очередной релиз готов к официальному выходу? Что происходит, если вы ошиблись, и после финального релиза приходится серьезно отойти назад, и как часто это случается? Как этот процесс развивался с годами?

ЛТ: Выше я на это уже указывал: сам процесс в самом деле хорошо стандартизирован, и остается таким на протяжении последнего десятилетия. Перед этим произошло несколько серьезных потрясений, но с 3.0 он работает практически как часы (на самом деле, это началось еще на несколько лет ранее – во многих отношениях переход на Git положил начало современным процессам, и потребовалось время, прежде, чем все к этому привыкли).

Поэтому у нас была такая каденция с «двухнедельным окном по сведению патчей», за которым следует примерно 6-8 недель, затрачиваемых на изучение кандидатов для релиза; думаю, такие циклы поддерживаются уже на протяжении примерно 15 лет.

Правила тоже всегда были одни и те же, хотя, их не всегда требовалось соблюдать со всей строгостью: окно по сведению патчей предназначено для нового кода, который предположительно «протестирован и готов», а затем в течение примерно двух последующих месяцев вносятся правки, и мы убеждаемся, что все проблемы действительно утрясены. Да, это происходит не всегда, и бывает, что предположительно «готовый» код приходится отключать или вообще выбрасывать прямо перед релизом.

Затем цикл повторяется – поэтому релизы у нас происходят примерно с десятинедельным интервалом.

А критерии для релиза для меня заключаются в ощущении достаточной уверенности, которая, очевидно, в свою очередь основана на том, какие сообщения о проблемах по-прежнему продолжают приходить. Если в какой-нибудь области проблемы продолжают сохраняться на поздних этапах релизного цикла, то я весьма настойчиво требую все откатить и говорю «займемся этим в одном из следующих релизов, когда как следует разберемся, что к чему», но в целом прибегать к таким мерам требуется достаточно редко.

Всегда ли такой процесс дает нужный результат? Нет. Как только релиз ядра состоялся, и особенно, когда релиз подхвачен ядром – у вас появляются новые пользователи, люди, не тестировавшие релиз на этапе разработки, и они находят какие-то вещи, которые не работают, или которые мы не отловили в ходе подготовки релиза. Это во многом неизбежно. Отчасти именно поэтому мы держим целые деревья «стабильных ядер», в которые после релиза продолжаем вносить правки. Причем, срок поддержки у одних стабильных ядер дольше, чем у других, такие долгоживущие ядра обозначаются аббревиатурой LTS (»долгосрочная поддержка»).

Все эти аспекты на протяжении последних десяти лет практически не менялись, хотя, мы действительно значительно шире стали применять автоматизацию. Автоматизация тестирования ядра – дело вообще сложное, отчасти потому, что значительная часть ядра приходится на драйверы, которые, очевидно, зависят от доступности аппаратного обеспечения. Но у нас есть несколько «ферм», тестирующих как загрузку, так и производительность, а еще мы выполняем различные варианты рандомизированного нагрузочного тестирования. Все это за годы работы улучшилось.

Дж.А.: В прошлом ноябре, по вашим словам, вас впечатлили новые чипсеты ARM64 от Apple, поставленные в некоторых из их новых компьютеров. Вы следите за этими разработками, чтобы поддерживать их под Linux? Вижу, work была добавлена в for-next. Вероятно ли, что Linux будет грузиться на оборудовании Apple MacBook уже с появлением готовящегося ядра 5.13? Станете ли вы одним из ранних пользователей? Насколько велика для вас важность ARM64?

ЛТ: я очень эпизодически проверяю, как с этим дела, но пока там все на очень раннем этапе. Как вы правильно отметили, самый ранний вариант поддержки, вероятно, будет добавлен в ядро 5.13, но учитывайте пожалуйста, что мы в самом начале пути, и аппаратное обеспечение Apple пока еще не годится для полезной работы под Linux.

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

Но улучшилось не только аппаратное обеспечение Apple – сама инфраструктура для arm64 значительно выросла, и ядра процессора изменились от «ни о чем» до вполне конкурентоспособной альтернативы для серверного пространства. Еще не так давно серверное пространство arm64 представляло собой весьма унылое зрелище, но процессоры Graviton2 от Amazon и Altra от Ampere – оба основаны на значительно улучшенной версии ARM Neoverse IP – гораздо лучше альтернатив, имевшихся на рынке несколько лет назад.

Я уже более десяти лет дожидался, пока появится удобная машина с ARM, и ее до сих пор нет, но сейчас до нее гораздо ближе, чем было когда-то.

На самом деле могу сказать, что хотел машину с ARM гораздо дольше, еще в подростковые годы, причем, по-настоящему желанна была Acorn Archimedes, но из соображений цены и доступности пришлось удовлетвориться Sinclair QL (процессор M68008), а затем, конечно же, через несколько лет я сменил ее на i386 PC.

Несколько десятилетий казалось, что такая машина уже не за горами, но в широкой доступности ее по-прежнему не было, а также я не мог предпочесть ее другим компьютерам по соображениям производительности/цены. Когда-нибудь она появится. Надеюсь, не в столь отдаленном будущем.

Дж.А.: есть ли в ядре какие-то аспекты, которые сделаны не лучшим образом, но, чтобы поправить их как следует, пришлось бы полностью переписывать код? Иными словами, ядру 30 лет, и за эти 30 лет значительно изменились наши знания, языки программирования аппаратное обеспечение. Если бы сейчас вы переписывали ядро с нуля, то что бы вы в нем изменили?

ЛТ: на самом деле, нам весьма хорошо удавалось даже целиком переписывать некоторые вещи, если была такая необходимость, поэтому все детали, которые казались необезвреженными бомбами, давным-давно переписаны.

Естественно, у нас есть изрядное количество слоев, которые оставлены для обеспечения «совместимости», но обычно там не «ужас-ужас». Причем, неясно, а исчезнут ли эти слои для совместимости, если переписать все с нуля – ведь они нужны для обратной совместимости со старыми бинарными файлами (а зачастую и для обратной совместимости со старыми архитектурами, например, для запуска 32-битных приложений для x86 на x86-64). Поскольку я считаю обратную совместимость очень важной, я хотел бы сохранить их даже в переписанной версии.

Итак, очевидно, что у нас много вещей, которые реализованы «не оптимально», в том смысле, что улучшить можно что угодно, но, учитывая, как вы сформулировали вопрос, я отвечу на него отрицательно – в ядре нет ничего, чем я бы гнушался. Есть унаследованные драйверы, которыми никогда никто не озаботится хотя бы настолько, чтобы их подчистить, есть и другие уродливые вещи, но ключевой момент в том, что они «никого особо не волнуют». Это все не проблемы, а если они превратятся в проблемы, то мы активно избавляемся от поддержки по-настоящему старого унаследованного кода, до тех пор, пока ситуация вновь не начинает всех устраивать. Так, с годами мы избавились от множества драйверов, и мы откажемся от поддержки целой архитектуры, если ее поддержка утратит какой-либо смысл.

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

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

Дж.А.: Как насчет хотя бы частично переписать ядро на Rust, языке, который разрабатывался именно с прицелом на производительность и безопасность? Есть ли пространство для улучшения в таком ключе? Как вы считаете, возможно ли, чтобы другой язык, например, Rust, заменил C в ядре?

ЛТ: Увидим. Не думаю, что Rust закрепится в самой основе ядра, но писать на нем отдельные драйверы (или, может быть, целые подсистемы драйверов) – не скажу, что это совершенно невероятно. Может быть, он и для файловых систем подойдет. Поэтому, скорее не «заменить C», а «дополнить наш код на C там, где это целесообразно «.

Разумеется, на драйверы как таковые приходится примерно половина кода ядра, поэтому места для таких разработок много, но я не думаю, что кто-то в самом деле рассчитывает, что уже существующие драйверы будут переписаны на Rust целиком. Может быть, «есть люди, желающие писать новые драйверы на Rust, а некоторые драйверы мы на нем действительно можем переписать, если это будет целесообразно».

Но прямо сейчас ситуация дошла только до «люди пробуют его, играют с ним», не более. Легко подчеркивать преимущества, но здесь определенно есть и сложности. Поэтому я очень склонен подождать и понаблюдать, действительно ли обещанные сильные стороны Rust себя оправдают.

Дж.А.: Есть ли в ядре какие-либо конкретные элементы, которыми вы лично особенно гордитесь?

ЛТ: выдающиеся части, которые мне хочется лишний раз подчеркнуть – это уровень VFS (»виртуальная файловая система») (и поиск имени пути в частности) и наш код виртуальной машины. Первое – просто потому, что в Linux некоторые из этих фундаментальных вещей (поиск имени файла – по-настоящему базовая функциональность в операционной системе) выполнимы намного лучше, чем во многих других ОС. А второе – в основном потому, что мы поддерживаем более 20 архитектур, и по-прежнему делаем это при помощи в основном унифицированного уровня виртуальной машины, что, на мой взгляд, весьма впечатляет.

Но, в то же время, все это во многом проистекает из «какая из частей ядра вам наиболее интересна». Ядро достаточно велико, чтобы разные разработчики (и разные пользователи) просто придерживались разных мнений по поводу того, что в нем наиболее важно. Некоторым кажется, что планирование задач – наиболее захватывающая функция ядра. Другим нравится вникать в тонкости драйверов устройств (а у нас таких много). Лично я сильнее вовлечен в работу над VM и VFS, поэтому, естественно, указываю на них.

Дж.А.: Я нашел вот такое описание поиска имени пути, и он сложнее, чем я ожидал. Почему реализация этой функции в Linux настолько лучше, чем в любых других операционных системах? И что для вас означает «лучше»?

ЛТ: Поиск имени пути – это поистине настолько обычная и фундаментальная вещь, что почти никто вне круга разработчиков ядра не считает, что это проблема. Они просто открывают файлы и принимают это как должное.

Но на самом деле очень сложно добиться, чтобы это работало как следует. Именно потому, что поиск имени пути все время происходит буквально везде, и поэтому данная задача критически сказывается на производительности; кроме того, это именно та область, в которой требуется хорошо масштабироваться при работе в средах SMP, блокировки при выполнении таких задач сопряжены с немалой сложностью. А вы хотите свести к минимуму какие-либо операции ввода/вывода, поэтому кэширование – это очень важно. На самом деле, поиск имени пути настолько важен, что его нельзя выполнять на низком уровне файловой системы, ведь у нас более 20 различных файловых систем, и реализация в каждой из них собственных механизмов кэширования и блокировок стала бы подлинной катастрофой.

Итак, одна из основных задач, решаемых на уровне VFS – это обработка всего кэширования и всех блокировок, связанных с компонентами имени пути, а также с обработкой всех операций, касающихся сериализации и обхода точек монтирования, причем, все это делается в основном при помощи неблокирующих алгоритмов (RCU), а также с применением весьма умных сущностей, напоминающих блокировки (блокировка «lockref», предусмотренная в Linux – это очень особенная «спин-блокировка с подсчетом ссылок», буквально предназначенная для кэширования dcache, и, в принципе, это специализированный механизм подсчета ссылок, учитывающий блокировки, который в определенных типичных ситуациях может выполнять исключение блокировок).

В итоге: низкоуровневые файловые системы все равно должны искать вещи, которые не кэшированы, но на их уровне не приходится беспокоиться о кэшировании и соблюдении правил согласованности и атомарности, которые должны соблюдаться при поиске имени пути. Уровень VFS все это обрабатывает за них.

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

Поэтому, здесь в Linux все не просто «лучше», но даже «Лучше» с большой буквы «Л». Ни одна другая система в этом и близко не сравнится с Linux. Механизм dcache просто единственный в своем роде.

Дж.А.: Прошлый год тяжело дался всему миру. Как пандемия COVID-19 повлияла на процесс разработки ядра Linux?

ЛТ: на самом деле, минимально, поскольку мы привыкли к такому режиму работы. Все-таки, электронная почта – чудесный инструмент, позволяющий обходиться без оффлайновых совещаний.

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

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

Облачные серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Операционная система Unix

ТомпсонигрядаUnix был впервые разработан в Bell Labs. В течение следующих 10 лет Unix широко использовался в академических учреждениях и на крупных предприятиях.В то время владелец UNIX, AT & T, лицензировал исходный код Unix для академических учреждений с низкими или даже бесплатными лицензиями. Для исследовательских или преподавательских целей многие учреждения были расширены и улучшены на основе этого исходного кода, образуя так называемые «варианты Unix». Эти варианты, в свою очередь, способствовали развитию Unix. Одним из наиболее известных вариантов является Калифорнийский университет Продукты BSD, разработанные Clay.

Позже AT & T осознала коммерческую ценность Unix, больше не разрешала исходный код Unix для академических учреждений и объявила авторские права на предыдущий Unix и его варианты. Вариант BSD Unix имеет значительное влияние в историческом развитии Unix, принят многими коммерческими производителями и становится основой многих коммерческих Unix. BSD использует основную версию плюс идентификацию метода вспомогательной версии, такую ​​как 4.2BSD, 4.3BSD, существуют производные версии, основанные на исходной версии, эти версии обычно имеют свои собственные имена, такие как 4.3BSD-Net / 1, 4.3BSD-Net / 2 и т. Д. Его постоянно растущее влияние, наконец, привлекло внимание AT & T, поэтому начался затяжной судебный процесс по авторскому праву. Этот иск продолжался до тех пор, пока AT & T не продала свою лабораторию системы Unix. Более просвещенный подход позволяет Berkeley свободно выпускать свои собственные BSD, но предпосылка заключается в том, что код от AT & T должен быть полностью удален, поэтому родилась версия 4.4 BSD Lite, поскольку у этой версии нет юридических проблем, 4.4BSD Lite стала Базовая версия современной системы BSD. Хотя позже, некоммерческая система Unix претерпела много изменений, но в конечном итоге она была создана в версии BSD (за исключением Linux). Таким образом, с этой точки зрения 4.4 BSD является основой всех бесплатных версий Unix, и вместе с System V и Linux они образуют яркое звездное небо операционной системы Unix.

В своем развитии BSD постепенно основала три основных направления: FreeBSD, OpenBSD и NetBSD.

В последующие десятилетия Unix все еще меняется, его владельцы авторских прав постоянно меняются, и число авторизаторов также увеличивается. Авторские права на Unix когда-то принадлежали AT & T, а затем Novell принадлежала Unix, а затем Novell продала авторские права SCO, исключая права интеллектуальной собственности и патентные права (этот факт все еще оспаривается обеими сторонами). Многие крупные компании разработали свои собственные продукты Unix после получения авторизации Unix, такие как IBM AIX, HP HP-UX, SUN Solaris и SGI IRIX.

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

Полная история UNIX

Начальная стадия

Рождение Unix имеет определенные отношения с Multics (Мультиплексная информационно-вычислительная система). Multics — это проект операционной системы, совместно реализуемый MIT, AT & T Bell Labs и General Electric. Он предназначен для работы на мэйнфрейме GE-645, но, поскольку вся цель слишком велика, слишком много функций смешано. Хотя Multics выпущен Некоторые продукты, но производительность очень низкая, и в конечном итоге закончилась неудачей.

В конечном итоге AT & T изъяла ресурсы, вложенные в проект Multics, и один из разработчиков, Кен Томпсон, продолжил разработку программного обеспечения для GE-645 и в итоге написал игру для космических путешествий. После фактической операции он обнаружил, что игра была медленной и дорогой — каждый раз она стоила 75 долларов.

С помощью Денниса Рича Томпсон переписал игру на ассемблере PDP-7 и запустил ее на DEC PDP-7. Этот опыт плюс опыт проекта Multics побудил Томпсона начать проект новой операционной системы на DEC PDP-7. Томпсон и Рич возглавили группу разработчиков для разработки новой многозадачной операционной системы. Эта система включает в себя интерпретатор команд и некоторые служебные программы. Multics — это аббревиатура от «Мультиплексной информационно-вычислительной системы». В 1970 году PDP-7 мог поддерживать только двух пользователей. В то время Брайан Керниган в шутку назвал их На самом деле эта система называется «Информационная и вычислительная система с униплексом», сокращенно «УНИКС». Так что этот проект называется UnICS (Uniplexed Information and Computing System). Позже имя омофонического имени было изменено на UNIX.

Период разработки

Оригинальный Unix был написан на ассемблере, а некоторые приложения были написаны на смеси интерпретируемого языка, называемого ассемблером и ассемблером. Язык B не был достаточно мощным для системного программирования, поэтому Томпсон и Рич заново его изобрели и изобрели язык C вместе с 1971 годом. В 1973 году Томпсон и Рич переписали Unix на языке Си. В то время, чтобы достичь максимальной эффективности, системные программы были написаны на ассемблере, поэтому ход Томпсона и Рича был чрезвычайно инновационным и революционным. Код Unix, написанный на языке C, является лаконичным и компактным, его легко трансплантировать, легко читать и легко модифицировать, что заложило прочную основу для разработки Unix.

В 1974 году Томпсон и Рич совместно опубликовали статью о UNIX в ACM Communications, и впервые UNIX появилась за пределами Bell Labs. С тех пор UNIX был замечен правительственными учреждениями, исследовательскими институтами, предприятиями и университетами и постепенно стал популярным.

В 1975 году UNIX выпустила три версии: 4, 5 и 6. В 1978 году уже было около 600 компьютеров под управлением UNIX. В 1979 году была выпущена версия 7, которая была последней широко выпущенной исследовательской версией UNIX. 8, 9 и 10 версии, выпущенные в 1980-х годах, были лицензированы только для нескольких университетов. С тех пор исследования в этом направлении привели к появлению Project 9, который является новой распределенной операционной системой.

В 1982 году AT & T разработала первую версию UNIX System III на основе версии 7, которая является коммерческой версией только для продажи. Чтобы разрешить хаотическую ситуацию с версией UNIX, AT & T интегрировала различные UNIX, разработанные другими университетами и компаниями, и разработала UNIX System V Release 1.

Новый коммерческий выпуск UNIX больше не содержит исходный код, поэтому UC Berkeley продолжает разрабатывать BSD UNIX в качестве альтернативы UNIX System III и V. Одним из наиболее важных вкладов BSD в UNIX является TCP / IP. BSD имеет 8 основных дистрибутивов, которые включают TCP / IP: 4.1c, 4.2, 4.3, 4.3-Tahoe, 4.3-Reno, Net2, 4.4 и 4.4-lite. Код TCP / IP в этих выпусках является предшественником практически всех реализаций TCP / IP в современных системах, включая AT & T System V UNIX и Microsoft Windows.

Некоторые другие компании также начали предоставлять коммерческие версии систем UNIX для своих собственных миникомпьютеров или рабочих станций: некоторые выбирают System V в качестве базовой версии, а другие выбирают BSD. Один из главных разработчиков BSD, Билл Джой, разработал SunOS на основе BSD и в конечном итоге основал Sun Computer Systems.

В 1991 году группа разработчиков BSD (Донн Сили, Майк Карелс, Билл Джолиц и Трент Хейн) покинули Калифорнийский университет и основали Berkeley Software Design, Inc (BSDI). BSDI является первым поставщиком, предоставившим полнофункциональную коммерческую BSD UNIX на дешевой и распространенной платформе Intel. Позже Билл Джолиц покинул BSDI и начал работу над 386BSD. 386BSD считается предшественником FreeBSD, OpenBSD и NetBSD, DragonFlyBSD.

AT & T продолжает добавлять блокировку файлов, управление системой, управление заданиями, потоковую передачу и удаленные файловые системы в UNIX System V. С 1987 по 1989 год AT & T решила объединить Xenix (версию UNIX для x86-pc, разработанную Microsoft), BSD, SunOS и System V с System V Release 4 (SVR4). Этот новый выпуск объединяет несколько функций в одну, что завершает хаотическое соревнование

После 1993 года большинство коммерческих издателей UNIX разработали свои собственные варианты UNIX на основе SVR4.

статус

Вскоре после выпуска UNIX System V Release 4 AT & T продала все свои права UNIX на Novell. Novell надеется использовать это для борьбы с Microsoft Windows NT, но ее основной рынок серьезно пострадал, и, наконец, Novell продала права SVR4 консорциуму X / OPEN, отраслевой группе, которая определяет стандарт UNIX. Наконец, X / OPEN и OSF / 1 объединились, чтобы создать Open Group. Несколько стандартов, определенных Open Group, определяют, что является и не является UNIX.

Фактический код UNIX был передан в Операцию Санта-Крус, которая впоследствии была продана Caldera Systems. Изначально Caldera продавала системы Linux. После завершения сделки новая компания была переименована в SCO Group.

Роспуск кафедры

Согласно отчету, отдел Bell Laboratory 1127, который отвечал за R & D UNIX и последующие работы по техническому обслуживанию, был официально расформирован в августе 2005 года. Кен Томпсон ушел на пенсию и теперь живет в Калифорнии, Деннис Ридж перешел в другое отделение, а Дуглас Макилрой — профессор Дартмутского колледжа.

Unix культура

UNIX — это не только операционная система, но и образ жизни. (UNIX — это не просто операционная система, но и образ жизни.) После десятилетий разработки UNIX стала уникальной в процессе развития технологий. Философия дизайна и эстетика также глубоко привлекли большое количество технического персонала, поскольку UNIX поддерживает, развивает и использует UNIX, а также влияет на их образ мышления и взгляды на мир. Эти люди естественно сформировали общество.

Важные принципы проектирования UNIX:

• 1
• 2
• 3

Ричард Столлман и его проект свободного программного обеспечения (GNU)

В 1983 году Ричард Столлман создал проект GNU с целью создания свободного программного обеспечения, Unix-подобной и POSIX-совместимой операционной системы. В рамках этого плана он написал Стандартную общественную лицензию GNU (GPL). В начале 1990-х уже было достаточно программного обеспечения для создания полноценной операционной системы. Но потому что в 1987 году Ричард Столлман решил разработать с микроядром Mach, полагая, что это может ускорить разработку операционной системы, а потому что было неясно, когда Университет Карнеги-Меллона станет основным исходным кодом Вышел, что привело к медленному продвижению проекта в течение трех лет. Ядро GNU, GNU Mach и GNU Hurd не смогли полностью привлечь разработчиков, что привело к неудаче завершения GNU.

В 1980-х годах был еще один проект по бесплатным операционным системам, Berkeley Software Suite. Он был разработан UC Berkeley из шестого издания Unix от AT & T. Поскольку он содержал код Unix, принадлежащий AT & T, AT & T подала иск против Калифорнийского университета в начале 1990-х годов. Это серьезно ограничивает разработку и применение BSD.

MINIX — это Unix-подобная система, выпущенная Эндрю Стюартом Танненбаумом в 1987 году для архитектуры микроядра для обучения. Хотя исходный код системы легко доступен, изменение и распространение исходного кода ограничены. Кроме того, 16-разрядный дизайн MINIX плохо совместим с архитектурой Intel 80386, которая в то время становилась все более дешевой и популярной для персональных компьютеров.

Эти факторы привели Торвальдса к запуску своего проекта. Однажды он сказал, что если бы в то время было доступно ядро ​​GNU или 386BSD, он, вероятно, не написал бы свое собственное ядро.

Операционная система Linux

Рождение Linux

В 1991 году в Хельсинки Линус Торвальдс начал проект, который впоследствии стал ядром Linux. Первоначально это был только виртуальный терминал Торвальдса, который использовался для доступа к большим серверам Unix в университетах. Он написал программу специально для используемого оборудования, которое не имело ничего общего с операционной системой, потому что он хотел использовать функции своего нового ПК с процессором 80386. Разработка выполняется на Minix с использованием компилятора, который все еще предпочитается сегодня — GCC — для завершения.

Торвальдс сказал в своей книге только от радости, что наконец понял, что написал ядро ​​операционной системы. 25 августа 1991 года он выпустил систему в Usenet, опубликованную в новостной группе «comp.os.minix»:

• 1
• 2
• 3
• 4
• 5
• 6

Происхождение названия

Линус Торвальдс первоначально назвал свое время Freax — смесь «fread», «free» и «x» (подразумевается, Unix). В первой половине системы разработки он хранил файл под именем «Freax». Торвальдс обдумывал название Linux, но бросил его, потому что чувствовал, что оно слишком эгоистично [6].

Чтобы облегчить разработку, в сентябре 1991 года он загрузил эти файлы на FTP-сервер (ftp.funet.fi) Хельсинкского технологического университета (HUT). Коллега Торвальдса Ари Леммке, управляющий сервером в HUT, почувствовал, что имя «Freax» было не очень хорошим, и изменил название проекта на «Linux», не посоветовавшись с Торвальдсом. Но после этого Торвальдс также согласился с именем «Linux»: «После многих обсуждений он признал, что имя Linux лучше. Имя« Freax »по-прежнему используется в make-файле исходного кода версии 0.01 для Linux, а затем« Linux ». Это имя используется только. Поэтому имя Linux не является предвзятым, но оно широко принято ".

Спор о присвоении имен GNU / Linux

Название «Linux» изначально использовалось Торвальдсом только для ядра Linux. Но это ядро ​​часто используется с другим программным обеспечением, особенно с проектом GNU. Это скоро стало самым популярным программным обеспечением GNU. В июне 1994 года в журнале GNU Linux назывался «свободный клон Unix», и проект Debian также начал называть свой продукт «Debian GNU / Linux». В мае 1996 года Ричард Столлман выпустил версию 19.31 редактора Emacs, в которой название системы изменилось с Linux на Lignux. Это написание должно четко указывать на сочетание GNU и Linux. Но это вскоре было заменено на «GNU / Linux».

Разные люди по-разному реагируют на это имя. Проекты GNU и Debian используют это имя, но большинство разработчиков все еще просто используют «Linux» для обозначения их комбинации.

Официальный талисман

Tux
В 1996 году Торвальдс выбрал Penguin в качестве талисмана для Linux. Ларри Юинг представил первый набросок талисмана. Знаменитый талисман, который используется сейчас, основан на этом первом проекте. Джеймс Хьюз назвал его Tux на основе «Unix Торвальдса».

Новая разработка

Помимо Торвальдса, есть много известных разработчиков ядра Linux, таких как Алан Кокс и Марсело Тосатти, Марсело Тосатти. Кокс поддерживал версию ядра 2.2 до конца 2003 года. Тосатти поддерживал версию ядра 2.4 до середины 2006 года. Программист Эндрю Мортон руководил разработкой и выпуском первой стабильной версии ядра 2.6, выпущенной 18 декабря 2003 года. техническое обслуживание. Старая версия постоянно совершенствуется.

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

Сообщество

Большая часть работы над Linux выполняется сообществом: программисты, использующие Linux по всему миру, посылают предлагаемые улучшения сопровождающему. Многие компании не только участвовали в разработке ядра, но также участвовали в подготовке некоторых вспомогательных программ, выпущенных с Linux.

Среди версий Linux есть как самоорганизующиеся выпуски, такие как Debian, так и выпуски, напрямую связанные с некоторыми компаниями, такими как openSUSE и Fedora. Чтобы обменяться мнениями, участники различных проектов часто встречаются на различных конференциях. Одним из крупнейших обменов был LinuxTag, проводимый в Германии (в настоящее время Берлин). Ежегодно около 10 000 человек собираются для обсуждения проектов, связанных с Linux и Linux.

Лаборатория разработки с открытым исходным кодом и Linux Foundation

Open Source Development Lab была основана в 2000 году. Это независимая некоммерческая организация. Его цель — оптимизировать Linux для приложений ЦОД и операторов связи. Это источник спонсорства для работ Линуса Торвальдса и Эндрю Мортона. В середине 2006 года Мортон перешел в Google (Google также использует ядро ​​Linux), а Торвальдс разработал ядро ​​Linux для OSDL на полную ставку. Средства на некоммерческий операционный механизм в основном поступают от нескольких крупных компаний, таких как Red Hat, Novell, Mitsubishi, Intel, IBM, Dell и HP.

22 января 2007 года OSDL и Организация свободных стандартов объединились в Linux Foundation, сосредоточив свою работу на улучшении GNU / Linux для конкуренции с Windows.

Связанные компании

Хотя это проект с открытым исходным кодом, некоторые компании выиграли от него. Большинство из этих компаний также являются членами лаборатории разработки с открытым исходным кодом. Они вложили много ресурсов в улучшение и развитие Linux, чтобы они могли адаптироваться к приложениям в различных областях. К ним относятся аппаратное обеспечение, предоставляемое драйверами, денежные пожертвования людям, разрабатывающим программное обеспечение Linux, и работа программистов на Linux. Например, IBM и HP, которые впервые использовали Linux на своих серверах, и, например, Red Hat, которая поддерживает свою собственную версию. Аналогичным образом, Trolltech поддерживает Linux, разрабатывая Qt и лицензируя его GPL, а также предоставляя возможность некоторым разработчикам X и KDE. Первое делает возможным разработку KDE.

Спор о Linux

Linux вызвал неоднократные противоречия с момента его появления.

«Linux устарел»

Танненбаум-Товазская дискуссия
В 1992 году известный специалист по компьютерам, автор Minix и микроядер Эндрю Стюарт Танненбаум написал статью под названием «Linux» в группе новостей comp.os.minix. «Устаревшая» статья. Эта статья знаменует собой начало знаменитой большой дискуссии о ядре Linux. Основная критика Linux:

• 1
• 2
• 3
• 4
• 5

Публикация против документов с открытым исходным кодом

Конкурс от Microsoft
Хотя Торвальдс сказал, что угроза со стороны Linux, которую, по мнению Microsoft, не имеет к нему никакого отношения, в период с 1997 по 2001 год Microsoft и лагерь Linux испытывали большую враждебность. Эта ситуация стала очевидной, когда Эрик С. Рэймонд опубликовал «Документ Хэллоуина» в 1998 году. Вот статья инженера Microsoft, посвященная поиску стратегий для устранения угрозы свободного программного обеспечения для Microsoft.

Спор о SCO-Linux

В марте 2003 года SCO Group обвинила IBM в нарушении их авторских прав путем переноса кода UNIX в Linux. SCO заявила, что им принадлежит авторское право на код, а IBM подала иск. Red Hat подала встречный иск, поэтому SCO подала другие связанные с этим иски. В то же время, когда продолжались эти судебные процессы, SCO начала продавать лицензионные права на Linux пользователям, которые не хотели рисковать жалобами SCO. Поскольку Novell также утверждала, что владеет авторскими правами на UNIX, она снова подала иск против SCO. Тогда ШОС объявила о банкротстве.

Торговая марка имени

Linux является зарегистрированным товарным знаком Линуса Торвальдса.

Права на товарный знак
В 1994 и 1995 годах несколько человек из разных стран хотели зарегистрировать Linux в качестве товарного знака, чтобы некоторые компании Linux могли получать от него роялти. Многие разработчики и пользователи Linux не согласны. Торвальдс получил торговую марку Linux с помощью Linux International, а затем передал торговую марку Linux International. Защита этого товарного знака позднее осуществлялась некоммерческим объединением Linux Logo. В 2000 году Линус Торвальдс определил основные правила назначения разрешений. Это означает, что любой, кто хочет выпускать продукты и услуги под именем Linux, должен иметь лицензию. Лицензия получена путем покупки.

Хронология событий

1983: Ричард Столлман создал проект GNU с целью создания бесплатной операционной системы.
1989: Ричард Столлман написал первую версию GNU GPL.
1991: ядро ​​Linux было публично выпущено 25 августа 21-летним финским студентом Линусом Бенедиктом Торвальдсом.
1992: ядро ​​Linux было повторно авторизовано в соответствии с GNU GPL, в результате чего был получен первый «дистрибутив Linux».
1993: более 100 разработчиков посвятили себя разработке ядра Linux. Благодаря их усилиям ядро ​​постепенно адаптировалось к среде GNU, обширной среде, которая создала огромное пространство для приложений для Linux. Slackware был впервые выпущен. Позже, в том же году, был создан проект Debian, ставший крупнейшим проектом для сообщества.
1994: В марте Торвальдс полагал, что все компоненты ядра были полностью зрелыми, и выпустил версию 1.0 Linux. Команда проекта XFree86 предоставляет графический интерфейс пользователя (GUI). В том же году Red Hat и SUSE выпустили соответствующие дистрибутивы Linux 1.0.
1995: Linux был портирован на платформы SPARC DEC Alpha и Sun, и в последующие несколько лет он был широко портирован на большее количество платформ.
1996: выпущено ядро ​​Linux версии 2.0. На данный момент ядро ​​уже поддерживает несколько процессоров, что делает его отличным выбором для крупных компаний.
1998: многие крупные компании, такие как IBM, Compaq, Oracle заявили, что поддерживают системы Linux. Кроме того, некоторые программисты начали разработку графического интерфейса пользователя KDE.
1999: Некоторые программисты начали работать над графической средой GNOME, которая может заменить KDE, которая зависит от используемого инструментария Qt. В течение этого года IBM объявила о широком проекте по поддержке Linux.
2004: команда XFree86 разделила и основала X.Org Foundation с существующей организацией стандартов X Windows, которая способствовала чрезвычайно быстрой и быстрой разработке версии X Window ServerLinux.

ежегодник

1960MIT разрабатывает совместимую систему обмена данными, которая поддерживает 30 терминалов для доступа к хосту, хост отвечает за вычисления, а терминал отвечает за ввод и вывод;

В 1965 годуBell Labs, MIT, GE (General Electric Company) готовятся к разработке системы Multics, чтобы одновременно поддерживать 300 терминалов для доступа к хосту, но в 1969 году это не удалось;
В начале не было мыши или клавиатуры, а устройство ввода было только карточным устройством, поэтому, если вы хотите протестировать программу, вам нужно вставить устройство чтения карточек в карточный автомат. Если возникла ошибка, попробуйте еще раз тоже;
Multics：Multiplexed Information and Computing Service

В 1969 годуКен Томпсон (отец языка Си) разработал FILE Server System (Unics, прототип Unix) с использованием ассемблера.
Поскольку язык ассемблера зависит от аппаратного обеспечения, он может ориентироваться только на конкретное оборудование;
просто для того, чтобы перенести игру в "космическое путешествие";

В 1973 годуДеннис Ритчи и Кен Томпсон изобрели язык C, а затем написали ядро ​​Unix
Изменен язык B на язык C, что привело к появлению отца языка C;
90% кода написано на языке C, а 10% кода написано на языке хуэй, поэтому вам нужно изменить только 10% кода при пересадке

В 1977 годуБилл Джой из Университета Беркли изменил исходный код Unix для своего компьютера, который называется BSD (Berkeley Software Distribution)
Билл Джой — основатель Sun;
В 1979 годуUnix выпустила System V для персональных компьютеров;
В 1984 годуПоскольку Unix предусматривает: «Исходный код не может быть предоставлен учащимся», Учитель Таненбаум написал Minix, совместимый с Unix для обучения;
В 1984 годуСтоллман начал проект GNU (Not Unix) и основал фонд FSF (Фонд свободного программного обеспечения);
Продукты: GCC, Emacs, Bash Shell, GLIBC;
Защита "свободного программного обеспечения";
Программному обеспечению GNU не хватает открытой платформы для работы, и она может работать только в Unix;
Свободное программное обеспечение означает, что пользователь может вносить любые изменения в программное обеспечение и даже распространять его, но авторские права на GPL всегда должны сохраняться;
Бесплатное программное обеспечение можно продавать, но не только программное обеспечение, но и услуги, руководства и т. д .;
В 1985Чтобы избежать использования свободного программного обеспечения, разработанного GNU, другими лицами в качестве запатентованного программного обеспечения, было создано заявление об авторских правах GPL (General Public License);
В 1988Для разработки графического интерфейса MIT создала организацию XFree86;
В 1991Линус Торвальдс, аспирант Университета Хельсинки, Финляндия, разработал ядро ​​Lniux для 386 машин на основе gcc и bash;
1994Торвальдс выпускает Linux-v1.0;
1996Торвальдс выпустил Linux-v2.0 и определил талисман Linux: Penguin;