Історія ядра Linux: рішення, що визначили систему

Коротка історія ядра Linux

Історія ядра Linux охоплює період від версії 0.01 у вересні 1991 року до серії 7.x, яка сьогодні завантажується на серверах. Список релізів — найменш цікава її частина. Форму системи визначила невелика кількість рішень, і кожне з них досі впливає на машину, яку ви можете орендувати сьогодні.

Дати та номери версій у цьому матеріалі взято з kernel.org і опублікованої там історії релізів. Поточний станом на серпень 2026 року: версія 7.0 вийшла 12 квітня 2026 року, версія 7.1 — 14 червня 2026 року, а версія 7.2 перебуває на етапі release candidate.

Чому вибір GPL у 1992 році досі має значення

Версію 0.01 опубліковано 17 вересня 1991 року за ліцензією, яку Torvalds написав сам. Вона вимагала поширювати вихідний код і містила ще важливіше положення: "You may not distribute this for a fee, not even 'handling' costs." У 1991 році програмне забезпечення постачали на дискетах, а копіювання та відправлення дискет коштували грошей. Це положення унеможливлювало комерційний дистрибутив Linux.

Він змінив ліцензію. Про перехід на GNU General Public License (GPL) оголосили в примітках до випуску 0.12 у січні 1992 року, а чинності він набув 1 лютого 1992 року. Версія 0.95, випущена в березні 1992 року, стала першим випуском, опублікованим за цією ліцензією. На цій зміні ґрунтується кожен бізнес, створений згодом на базі Linux.

Ядро ліцензовано лише за GPL version 2 і ніколи не переходило на version 3. У 2007 році Torvalds відмовився від такого переходу, здебільшого через правило anti-tivoisation у GPLv3. Воно вимагає, щоб пристрій, який постачається з кодом під GPL, також приймав змінену копію цього коду. Він вважав заблоковане обладнання власною комерційною справою виробника. У 2017 році розробники ядра опублікували Kernel Enforcement Statement, який все ж запозичує один елемент GPLv3: той, хто виправляє порушення після повідомлення про нього, зберігає свою ліцензію, а не втрачає її назавжди через перше порушення.

На сервері це має два наслідки. Бінарний файл ядра, з якого ви завантажуєте систему, дає право отримати відповідний вихідний код. Тому ніхто не може передати вам ядро Linux, яке ви не маєте права перевірити або зібрати повторно. А повідомлення про авторські права на ядрі зазначає, що ліцензія не поширюється на користувацькі програми, які звертаються до служб ядра через звичайні системні виклики. Саме тому пропрієтарні бази даних і агенти моніторингу постачаються для Linux без порушення ліцензії. Permissive licence створює протилежний підхід, і цю різницю варто зрозуміти, перш ніж обирати платформу: див. Linux і FreeBSD як серверні платформи.

Чому монолітне ядро перемогло на практиці

29 січня 1992 року Andrew Tanenbaum опублікував у групі новин comp.os.minix повідомлення із заголовком "LINUX is obsolete". Він висунув дві тези. Монолітні ядра, у яких драйвери та файлові системи працюють в одному привілейованому адресному просторі, були концепцією 1970-х років, тоді як мікроядра, у яких ці компоненти працюють як звичайні процеси, належали майбутньому. Linux також був жорстко прив’язаний до Intel 386, тому ніколи не міг би працювати на інших платформах.

Тезу про переносимість спростували портовані версії. Version 1.2 у березні 1995 року додала Alpha, SPARC і MIPS. Version 2.0 у червні 1996 року додала 64-бітний порт Alpha.

Тезу про архітектуру спростував компроміс. Linux ніколи не став мікроядром. Натомість у ньому з’явилися завантажувані модулі ядра: об’єктні файли, які можна вставити у запущене ядро, а потім видалити, тому драйвер можна постачати окремо від бінарного файлу ядра.

lsmod | head
modinfo virtio_net | head -5

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

Модулі дали цю гнучкість без витрат, притаманних архітектурі мікроядра. Ізоляція драйвера в окремому процесі означає перемикання контексту та передавання повідомлення під час кожного виклику, а в 1992 році ці витрати були значними.

Витрата, яка залишилася в Linux, потребує окремого планування: модуль працює з повними привілеями ядра, тому несправний модуль виводить з ладу всю машину, а не один процес. Найчастіше це проявляється зі сторонніми модулями. Драйвер постачальника, якого немає в mainline, потрібно перебудовувати для кожного нового ядра. Під час оновлення це робить DKMS. Якщо збирання завершується помилкою, після перезавантаження пристрій просто відсутній.

Чому підтримку SMP завершували п’ятнадцять років

Linux 2.0 у червні 1996 року став першим ядром із підтримкою симетричної багатопроцесорності (SMP), тобто можливістю запускати одне ядро на кількох CPU. У першій реалізації використовувалося одне блокування — велике блокування ядра (BKL), тому лише один процесор міг одночасно виконувати код ядра. Другий CPU допомагав у робочих навантаженнях, які виконують обчислення в просторі користувача, але майже не допомагав у навантаженнях із системними викликами, оскільки вони ставали в чергу за тим самим блокуванням.

На видалення цього блокування знадобилося п’ятнадцять років. Код, який ще використовував BKL, поступово перевели на дрібнозернисті блокування, значною мірою завдяки Arnd Bergmann, а в 2.6.39 BKL видалили. Цю версію випустили 18 травня 2011 року. Планувальник розвивався приблизно такими самими повільними темпами: планувальник O(1) з’явився в 2.6.0, Completely Fair Scheduler (CFS) — починаючи з 2.6.23 у 2007 році, а EEVDF замінив CFS у 6.6 у жовтні 2023 року.

Саме завдяки цій роботі тариф із 4 vCPU сьогодні не є чимось незвичайним. Водночас це показує важливе обмеження. На спільному віртуальному сервері ваше ядро планує виконання потоків, а гіпервізор — виконання вашого ядра. Виконайте top і перегляньте поле %st. Steal time — це час CPU, протягом якого ваше ядро було готове виконувати роботу, але хост передав процесор іншій гостьовій системі. Жодне налаштування всередині вашого ядра не може це компенсувати.

Чому серія 2.6 змінила принцип збирання ядра

До версії 2.6 номери версій складалися з пар. Парний другий номер означав стабільну серію (2.4), а непарний — розробницьку (2.5). Версію 2.4 випустили 4 January 2001, а 2.6 — 17 December 2003, тому користувачі чекали майже три роки на наступну стабільну серію. Дистрибутиви не могли чекати, тому переносили зміни з новіших версій назад. Два постачальники, які випускали версію "2.4", могли постачати ядра, що відрізнялися на тисячі патчів.

Після 2.6 цей поділ скасували. Тепер mainline відкриває приблизно на два тижні merge window, приймає нові зміни, а потім випускає release candidate, доки код не стабілізується. Новий реліз виходить кожні 9–10 тижнів — саме таку періодичність і далі документує kernel.org. Друга частина цієї моделі з’явилася 4 March 2005 із першим випуском stable tree — оновленням 2.6.11, що містило лише виправлення. Його підтримували Greg Kroah-Hartman і Chris Wright. Stable tree приймає виправлення та відхиляє функціональні зміни.

Один із наслідків: номер версії більше не є гарантією. Версії 3.0, 4.0, 5.0 і 7.0 не означають повного переписування коду. Torvalds збільшує перший номер, коли другий стає достатньо великим, щоб його це турбувало. Саме тому після 6.19 у April 2026 вийшла версія 7.0. Для сервера важливо, яку гілку відстежує ваш дистрибутив і чи отримує ця гілка виправлення.

Як розрив із BitKeeper привів до появи git у квітні 2005 року

Із лютого 2002 року розробку ядра вели в BitKeeper — пропрієтарній розподіленій системі керування версіями від компанії BitMover, заснованої Larry McVoy, — починаючи з серії 2.5. BitMover надала розробникам ядра безкоштовну ліцензію з певними умовами: не можна було працювати над конкуруючим інструментом керування версіями та виконувати зворотне інженерне дослідження BitKeeper. Багатьом розробникам не подобалося створювати вільне ядро за допомогою інструмента, вихідний код якого їм було заборонено вивчати.

Усе змінилося у квітні 2005 року після того, як Andrew Tridgell продемонстрував програму, що взаємодіяла зі сховищами BitKeeper. BitMover назвала це зворотним інженерним дослідженням і відкликала безкоштовну ліцензію. Ядро втратило систему керування версіями в середині циклу розробки.

Роботу над git розпочали 3 April 2005 року. Torvalds оголосив про нього 6 April. 7 April git уже використовувався для власної розробки, тобто власна історія git уже зберігалася в git. Перше злиття кількох гілок виконали 18 April. У June 2005 року git забезпечив випуск 2.6.12. Незабаром після цього Torvalds передав супровід Junio Hamano і повернувся до роботи над ядром.

Проєктування безпосередньо випливало з проблеми: тисячі учасників і супроводжувачі, які отримують зміни один від одного через мережу, якій ніхто не довіряє. Кожен об’єкт ідентифікується хешем свого вмісту, тому зміна одного байта в старій історії змінює ідентифікатор кожного наступного коміту. Саме тому клон є доказом, а не твердженням. Кожен pipeline розгортання, кожен репозиторій конфігурації, хост коду, до якого надсилає зміни більшість команд і git-сервер, який можна запустити самостійно виникли з ліцензійної суперечки навколо ядра.

Що гарантує модель LTS, а чого вона не гарантує

Mainline — це не те, що запускають на серверах. Реліз mainline замінюється новим через 9–10 тижнів. Stable tree отримує виправлення ще кілька тижнів після кожного релізу. Гілки longterm, які зазвичай позначають як LTS, отримують виправлення протягом років. Саме на них базуються дистрибутиви.

Версія 2.6.32, випущена в December 2009, стала практичним підтвердженням цієї моделі. RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1 і Ubuntu 10.04 LTS постачалися з нею, а цю гілку підтримували до February 2016 — понад шість років після її випуску.

Тривалість підтримки змінювалася неодноразово. Спочатку вона становила два роки, а для деяких гілок — шість років. У 2023 році мейнтейнеры stable скоротили стандартний період до двох років, оскільки перенесення виправлень у старі дерева потребує часу мейнтейнерів, а старі гілки проходять мало реального тестування. On 25 February 2026 Greg Kroah-Hartman знову опублікував довші прогнози після обговорення з компаніями, які залежать від цих гілок. Поточна модель передбачає підтримку від трьох до шести років.

[
  {
    "kernel": "5.10",
    "released": "2020-12-13",
    "eol_projected": "Dec 2026",
    "maintained_for": 6.0
  },
  {
    "kernel": "5.15",
    "released": "2021-10-31",
    "eol_projected": "Dec 2026",
    "maintained_for": 5.1
  },
  {
    "kernel": "6.1",
    "released": "2022-12-11",
    "eol_projected": "Dec 2027",
    "maintained_for": 5.0
  },
  {
    "kernel": "6.6",
    "released": "2023-10-29",
    "eol_projected": "Dec 2027",
    "maintained_for": 4.2
  },
  {
    "kernel": "6.12",
    "released": "2024-11-17",
    "eol_projected": "Dec 2028",
    "maintained_for": 4.1
  },
  {
    "kernel": "6.18",
    "released": "2025-11-30",
    "eol_projected": "Dec 2028",
    "maintained_for": 3.1
  }
]

Станом на August 2026 kernel.org перелічує 6 гілок longterm. Найстаріша, 5.10, отримає виправлення протягом 6.0 років, коли її підтримка завершиться в Dec 2026. Для найновішої, 6.18, підтримку прогнозують до Dec 2028, тобто вона отримуватиме виправлення протягом 3.1 років.

Сприймайте ці дати як мінімальний орієнтир, а не як гарантію. Прогнозовані строки завершення підтримки версій 6.6 і 6.12 обидва були продовжені в February 2026, але гілку, якою ніхто не користується, можуть натомість закрити раніше. Зазвичай вибір за вас робить дистрибутив: Debian 13 постачається з версією 6.12, а Ubuntu 26.04 LTS — з 7.0. Саме в цьому полягає практичний зміст питання про LTS та проміжний реліз на сервері. Це також визначає, що фактично змінюється під час оновлення Ubuntu 24.04 до 26.04.

З цього випливає одна типова пастка. uname -r в Ubuntu 24.04 виводить щось на кшталт 6.8.0-51-generic. Це upstream-база з власними backport-виправленнями дистрибутива. Тому номер показує, з якої гілки почалася збірка, але не визначає, які саме виправлення до неї входять. Сканери, які оцінюють kernel лише за рядком його версії, саме з цієї причини створюють хибні попередження для kernel дистрибутива.

Про що зараз сперечаються в ядрі

Зараз тривають дві дискусії, і обидві стосуються того, хто має виконувати роботу.

Rust став частиною інфраструктури в 6.1 у грудні 2022 року. У 7.0 експериментальний статус було скасовано, тому основними мовами ядра є C, assembly і Rust, а для збирання більше не потрібен nightly compiler. Дискусія стосується супроводу. Супровідник C, який змінює інтерфейс, може порушити Rust bindings, з якими він не працює. Питання полягає в тому, хто має їх виправляти.

Друга дискусія стосується внеску AI. Sasha Levin запропонував політику в липні 2025 року після того, як до списків розсилки почала надходити дедалі більша кількість патчів, підготовлених за допомогою машинних засобів. Документ було зафіксовано 23 грудня 2025 року. Тепер він міститься у власній документації kernel щодо процесів за адресою docs.kernel.org/process/coding-assistants.html. AI agent не повинен додавати тег Signed-off-by, оскільки цей рядок засвідчує Developer Certificate of Origin (DCO), а засвідчити його може лише людина. Використання допоміжних засобів позначають тегом Assisted-by:. Під час review його було змінено з Co-developed-by:, оскільки tool не є author. Згенерований код має бути сумісним із GPL-2.0-only. Людина, яка надсилає patch, перевіряє його та несе за нього відповідальність.

Причина появи цієї політики — навантаження на review. Генерування patch займає секунди, а його перевірка може забрати весь день у maintainer. Тег не усуває цей дисбаланс. Проте він зберігає provenance: в історії й надалі фіксується, хто підписав кожну зміну. Саме цю властивість DCO було запроваджено для захисту у 2004 році.

Що ця історія означає для орендованого вами сервера

• Ліцензія дає змогу переглядати й повторно збирати kernel, який запускає ваш провайдер, а також пояснює, чому на ньому працює proprietary software.
• Монолітна архітектура пояснює, чому помилка в одному driver перезавантажує всю машину та чому out-of-tree module потрібно повторно збирати після кожного оновлення kernel.
• Модель випуску пояснює, чому номер версії мало що повідомляє, тоді як branch і дата його завершення підтримки дають майже всю потрібну інформацію.
• Тип virtualisation визначає, що саме ви можете робити: у KVM ви запускаєте власний kernel і завантажуєте modules, а в container virtualisation, яка використовує спільний kernel хоста, uname -r показує версію хоста, modprobe завершується помилкою, а деякі sysctl доступні лише для читання.

FAQ

Чому ядро Linux досі використовує GPLv2, а не GPLv3?

У 2007 році Торвальдс виступив проти GPLv3, головним чином через вимогу щодо anti-tivoisation. Вона зобов’язує пристрій, який постачається з кодом під GPL, також приймати змінену версію цього коду. Він вважає заблоковане апаратне забезпечення сферою відповідальності виробника. Практично повторне ліцензування також майже неможливе, оскільки авторські права на ядро належать тисячам учасників, а угоди про передачу прав, на яку можна було б послатися, немає. Ядро поширюється лише за GPL-2.0-only, тому код, запропонований лише за GPLv3, не можна додати до ядра.

Ядро Linux монолітне чи мікроядерне?

Монолітне, з підтримкою завантажуваних модулів. Драйвери та файлові системи працюють в адресному просторі ядра, а lsmod показує модулі, завантажені зараз. Це дає вищу швидкодію, але збільшує радіус ураження: помилковий модуль може спричинити kernel panic на всій машині, тоді як у мікроядерній системі було б втрачено лише один процес. Відмінність стала менш вираженою після 1992 року завдяки файловим системам FUSE у просторі користувача та програмам eBPF, які ядро перевіряє перед запуском.

У чому різниця між ядрами mainline, stable і longterm?

Mainline — це дерево Торвальдса, яке випускають кожні 9–10 тижнів. Нові функції спочатку потрапляють саме туди. Stable бере найновіший випуск mainline і протягом кількох тижнів отримує виправлення помилок. Гілки longterm продовжують отримувати виправлення роками, і саме на них дистрибутиви будують свої ядра. На kernel.org наведено поточні гілки longterm із прогнозованою датою завершення підтримки для кожної.

Чи приймає ядро Linux код, написаний AI?

Так, відповідно до політики, затвердженої в грудні 2025 року. Інструмент потрібно вказати в тегу Assisted-by:, AI-агент не повинен додавати рядок Signed-off-by, а згенерований код має бути сумісним із GPL-2.0-only. Людина, яка надсилає код, підписує зміни. Це означає, що вона перевірила патч і бере на себе відповідальність за нього відповідно до Developer Certificate of Origin.

Яку версію ядра слід використовувати на сервері?

Майже завжди — ту, яку підтримує ваш дистрибутив. Ядро дистрибутива — це гілка longterm із портованими виправленнями та результатами тестування постачальника. Саме на нього розраховані образи вашого провайдера та умови підтримки. Збирайте новіше ядро mainline, якщо вам потрібен певний драйвер або функція. Перед переходом перевірте дату завершення підтримки гілки, яку плануєте використовувати.