Журнал LinuxFormat - перейти на главную

LXF150:Ядро

Материал из Linuxformat
(Различия между версиями)
Перейти к: навигация, поиск
(Новая страница: «==Ядро 3.0== :От 10 000 строк кода — до 15 000 000. '''Нейл Ботвик''' заглядывает в прошлое и в будущее.…»)
 

Текущая версия на 14:26, 28 августа 2014

Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)

Содержание

[править] Ядро 3.0

От 10 000 строк кода — до 15 000 000. Нейл Ботвик заглядывает в прошлое и в будущее.
Оно здесь! Новое ядро Linux 3.0 во всем своем великолепии со дня на день появится в вашем любимом дистрибутиве. За что же данный конкретный релиз удостоен смены номера версии? Короткий ответ — да в общем ни за что: это всего лишь переименование ядра 2.6.40. Линус Торвальдс подумал, что номера версий сделались чересчур длинными и обозначение 2.6.* перестало быть удобным, а Linux вошел в свое третье десятилетие; вот он и ввел новый номер.


Торвальдс сказал: «Это никак не KDE 4 и не Gnome 3: никаких прорывов, никаких особенных нововведений, ничего такого. Мы выпускали регулярные релизы много лет, безотносительно к новым функциям. Если вы ищете повод для смены номера, лучше вспомните о знаменательной (20 лет) дате релиза».

В старой системе нумерации первая цифра означала основной релиз – чуть ли не вечность это была 2; а вторая – второстепенный релиз, причем нечетные цифры означали версии в разработке, а четные – стабильные релизы. Пока основным действующим ядром было 2.4, 2.5 было версией разработки 2.6. Третья цифра представляла собой номер малой версии. Затем добавили четвертую цифру – для обратных поправок к стабильным релизам, и начался беспорядок, особенно из-за того, что первые две цифры версии перестали меняться.

Теперь основной релиз – 3, второе число – второстепенный релиз, а исправления для стабильных релизов при необходимости получают третью цифру. В данный момент мы находимся в точке 3.0 – по словам самого Торвальдса, «дни версий 2.6.<большое число> прошли». Основная причина увеличения номера (не считая того факта, что линейке 2.6 почти восемь лет) – изменение в философии релизов.

Ранее выпуск релизов основывался на новых функциях; когда удавалось добиться их стабильной работы, они тестировались, и выпускалось новое ядро – подход «по мере готовности».

Например, в версии 1.0 появилась поддержка сети (современный Linux без нее и представить трудно); в 1.2 появилась поддержка множества платформ – к исходной i386 добавились Alpha и m68k; а в версии 2.0 появилась поддержка SMP – многопроцессорности. Последний пример показывает, что пейзаж постоянно меняется, но Linux идет в ногу с жизнью; поддержка SMP добавлялась для «больших железяк», многопроцессорных серверов, а ныне двуядерные процессоры не редкость и в мобильных телефонах.

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

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

Список новых устройств, поддерживаемых ядром, заполнил бы весь журнал. С поощрения и под руководством соратников Грега Кроа-Хартмана [Greg Kroah-Hartman], все больше изготовителей устройств сотрудничают с разработчиками ядра, чтобы обеспечить хорошую поддержку своих продуктов.

Драйверы и поддержка устройств добавляются почти что в момент появления устройств на полках магазинов. От беспроводных карт до web-камер и даже Microsoft Kinect в Linux 3.0, диапазон поддерживаемых устройств огромен.

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

[править] Диво-строки

Когда в ноябре 2010 года в новостях появился заголовок «200-строчная заплатка ядра Linux творит чудеса», в сети вспыхнули дискуссии и споры.

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

На практике это означает, что высокоинтенсивная фоновая задача, вроде компиляции программы (Линус, естественно, пробовал это на компиляции ядра) или перекодирования видео, не швырнет ваш браузер на колени – то есть дни перегрузки системы, с дерганием окон и срывами текста, ушли в прошлое.

Это интересно еще и потому (кроме самого факта, что столь важное изменение уложилось всего в пару сотен строк кода), что ничего не требует от пользователя, если этот код включен в его ядро, то есть в любом дистрибутиве с версией ядра от 2.6.38. Этот код также распознает устройства любого типа, от нетбука на базе Atom до шестиядерного монстра.

С годами ядро существенно разрослось. Один из методов измерения объема программы – SLOC, число строк исходного кода [source lines of code]. Понятно, что этот показатель растет с каждым релизом, но общий рост буквально ошеломляет:

  • В версии 0.01 было 10 239 строк кода
  • В 1.0.0 было 176 250 строк кода
  • В 2.2.0 было 1 800 847 строк кода
  • В 2.4.0 было 3 377 902 строки кода
  • В 2.6.0 было 5 929 913 строк кода
  • В 3.0 – 14 647 033 строки кода

Да, все верно: ядро Linux выросло с 10 000 до 15 000 000 строк кода. С декабря 2003 года, когда вышло первое ядро 2.6, объем кода более чем удвоился. Сюда входит суммарное количество строк во всех файлах в архивах исходников, включая документацию. А поскольку большинство программистов считает написание документации гораздо более тяжким трудом по сравнению с написанием кода, этот показатель выглядит достоверным.

Прежде чем кричать «Раздули!», вспомните, что Linux – не монолитное ядро: драйверы для большинства устройств поставляются в виде загружаемых модулей, которые в большинстве систем даже не нужно компилировать, не говоря уже об установке или загрузке. Рост размера исходников по большей части происходит за счет все более полной поддержки устройств.

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

Анализ кода, написанного за 2009 год – это около 2,8 млн строк и 55 000 крупных изменений – показал, что три четверти изменений внесены профессиональными разработчиками.

Неудивительно, что наибольший вклад внес Red Hat (12 %), за ним следовали Intel (8 %), IBM и Novell (по 6 %). Несмотря на взаимную конкуренцию, эти компании также осознают важность взаимодействия. Каждая компания, конечно, разрабатывает области, прибыльные для себя, но от их работы выигрывают все.


[править] Важность Microsoft

А вот что вас удивит – это что самый плодовитый индивидуальный поставщик кода в 3.0 работал на несколько иную компанию, Microsoft. Это отнюдь не означает, что компания «прозрела»: ей понадобилось вносить изменения в ядро, чтобы виртуальные машины Linux могли запускаться на ее платформе Windows Server. Таким образом, она стремилась не улучшить Linux, а добыть возможность продать побольше своих продуктов.

Какова бы ни была реальная причина, Microsoft теперь сложнее критиковать открытое ПО и ПО по лицензии GPL. И раз уж речь зашла о Microsoft – ядро 3.0 также поддерживает кинетический контроллер Xbox, нашедший отличное применение во всех неигровых сферах.

Есть две вещи, которых в Linux множество: файловые системы и программы с непонятными названиями. Btrfs входит в обе категории, как ее ни называй: «Better F S», «Butter F S» или «B-Tree F S».

Это сложная файловая система, которая реализует ряд идей ReiserFS и ряд идей ZFS от Sun, а также обладает некоторыми функциям менеджеров логических томов, таких как LVM. Даже Теодор Цо [Theodore Ts’o], основной разработчик файловой системы ядра ext3/4, считает Btrfs шагом вперед.

Когда Btrfs впервые ввели в ядро (версия 2.6.29), она считалась во многом экспериментальной, но с тех пор созрела, и Fedora объявила, что они хотели бы сделать ее файловой системой по умолчанию в Fedora 16.

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

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

[править] Обещание выполнено

Еще в 2006 году появился сайт, провозглашавший целью создание открытых 3D-драйверов для видеокарт Nvidia. Многие из нас заинтересовались этой идей, но ожидали, что она уйдет не дальше, чем многие проекты на Sourceforge. Иногда приятно ошибаться в прогнозах! В ядре Linux теперь есть драйверы Nouveau для видеокарт Nvidia.

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

Хотя они не дают той же производительности 3D-графики, как собственные драйверы Nvidia, их более чем достаточно для большинства неигровых применений, и они позволяют избежать проблем, способных появиться при смешении проприетарного, скомпилированного кода с открытым.

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

AppArmor (Application Armor – броня приложения) – модуль безопасности ядра. Он позволяет ограничить возможности отдельных программ посредством профилей. Назначение профиля программе или набору программ определяет допустимые для них действия. Это означает, что даже если для запуска программы необходимы привилегии суперпользователя (root), она не сможет делать все, что захочет – это ограничение поверх стандартной системы доступа на основе прав пользователей.

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

[править] Рожденные в пламени

(thumbnail)
Временная шкала развития ядра Linux показывает, что серия 2.6 была «самой свежей и передовой» добрых восемь лет. Переход к 3.0 явно припозднился.

AppArmor создан уже давно. Его предыдущее воплощение, известное как SubDomain, появилось в Immunix Linux в 1998 году. В 2005 он был выпущен под названием AppArmor компанией Novell и включен в OpenSUSE и SLES. Но только в октябре 2010 года, начиная с релиза 2.6.36, он вошел в ядро как встроенный его компонент.

Если вы хотите почитать о тонкостях разработки ядра, есть только одно место, куда пойти: LKML (Linux Kernel Mailing List – рассылка ядра Linux). Здесь кипят работа и важные дискуссии, но это место не для слабонервных. Трафик довольно большой, около 200 – 300 писем в день, причем глубоко технических. Также стоит сказать, что многие разработчики известны благодаря способностям скорее к написанию кода, чем к общению.

Да и общение по электронной почте подразумевает более резкие манеры по сравнению с личным – «галантности в Интернете никто не поймет» – плюс фактор «эго» при обсуждении достоинств или недостатков собственного детища; получается среда, которая скорее продуктивна, чем дружелюбна.

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

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

Или – спор между Линусом и разработчиками ARM об их в чем-то изоляционистской позиции. Он разрешился удачно, и больший объем кода, относящегося к ARM, был перенесен в «основное древо», а не укрылся в своем углу. А так как сегодня устройств с Linux на ARM (предпочтительный процессор для встроенных систем и смартфонов), пожалуй, больше, чем на x86, это решение было благоразумным – даже если (или – потому что) родилось в пламени споров.

Виртуализация проникла повсюду, от компьютеров читателей Linux Format, пользующихся VirtualBox или KVM для тестирования дистрибутивов с LXFDVD, до крупных информационных центров, предоставляющих хостинг на виртуальных машинах.

В ядре есть поддержка систем виртуализации KVM (Kernel-based Virtual Machine – виртуальная машина на основе ядра) и Xen. Также всесторонне поддерживаются проприетарные системы, такие как системы от VMware и Microsoft, поэтому виртуальные машины Linux можно запускать почти везде.

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

Взаимодействие между гостевой ОС и главным компьютером или другой гостевой системой осуществляется через сетевое соединение, и виртуальные машины традиционно эмулируют настоящую сетевую карту для более широкой совместимости. В Linux недавно появился сетевой драйвер vhost, ликвидировавший максимум устаревшей аппаратной эмуляции и достигший скоростей до 10 ГБ/с, а также меньшего времени задержки.

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

[править] Подъем Android

Одна компания сумела резко увеличить число пользователей систем на базе Linux, и речь не о Canonical. Операционная система Android от Google (буквально) вложила Linux в руки миллионам людей, которые до этого вообще не знали, что такое ОС, не говоря уже о Linux. Хорошо ли это? Время покажет, но тут есть что обсудить.

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

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

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

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

С нетерпением ждем новых функций в ядре 4.0, которое выйдет в 2021 году – даже если это будет всего лишь переименованное 3.99.

Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF150:%D0%AF%D0%B4%D1%80%D0%BE&oldid=15502»
Персональные инструменты
купить
подписаться
Яндекс.Метрика