Historia rozwoju jądra Linux: kluczowe decyzje projektowe

Skrócona historia jądra Linux

Historia jądra Linux obejmuje okres od wersji 0.01 we wrześniu 1991 roku do serii 7.x, która uruchamia dzisiejsze serwery. Lista wydań jest najmniej istotnym elementem tej historii. Niewielka liczba decyzji ukształtowała ten projekt, a każda z nich ma do dziś wpływ na maszynę, którą wynajmujesz tego popołudnia.

Daty i numery wersji pochodzą z kernel.org oraz publikowanej tam historii wydań. Stan na sierpień 2026 roku: wersja 7.0 ukazała się 12 kwietnia 2026 roku, 7.1 pojawiła się 14 czerwca 2026 roku, a wersja 7.2 znajduje się w fazie kandydatów do wydania (release candidates).

Dlaczego wybór GPL w 1992 roku nadal ma znaczenie

Wersja 0.01 została opublikowana 17 września 1991 roku na licencji napisanej samodzielnie przez Torvaldsa. Wymagała ona udostępniania kodu źródłowego i zawierała zapis o kluczowym znaczeniu: „Nie wolno rozpowszechniać tego za opłatą, nawet w ramach kosztów obsługi”. W 1991 roku oprogramowanie było dostarczane na dyskietkach, a ich kopiowanie i wysyłka generowały koszty. Ta klauzula uniemożliwiała tworzenie komercyjnych dystrybucji Linux.

Autor zmienił licencję. Przejście na GNU General Public License (GPL) ogłoszono w informacjach o wydaniu 0.12 w styczniu 1992 roku, a weszło ono w życie 1 lutego 1992 roku. Wersja 0.95, wydana w marcu 1992 roku, była pierwszą opublikowaną na tych zasadach. Każdy biznes zbudowany później na bazie Linux opiera się na tej zmianie.

Jądro systemu jest objęte wyłącznie licencją GPL w wersji 2 i nigdy nie przeszło na wersję 3. Torvalds odmówił w 2007 roku, głównie ze względu na zapis o „anti-tivoisation” w GPLv3, który wymaga, aby urządzenie dostarczane z kodem GPL akceptowało również jego zmodyfikowaną kopię. Uznał on zablokowany sprzęt za prywatną sprawę producenta. W 2017 roku twórcy jądra opublikowali Kernel Enforcement Statement, który i tak zapożycza jeden element z GPLv3: osoba, która naprawi naruszenie po otrzymaniu powiadomienia, zachowuje licencję, zamiast tracić ją bezpowrotnie przy pierwszym incydencie.

Dla serwera wynikają z tego dwie konsekwencje. Binarny plik jądra, który uruchamiasz, niesie ze sobą prawo do dostępu do odpowiadającego mu kodu źródłowego, więc nikt nie może dostarczyć Ci jądra Linux, którego nie mógłbyś sprawdzić lub samodzielnie skompilować. Ponadto informacja o prawach autorskich w jądrze stwierdza, że licencja nie obejmuje programów użytkownika, które korzystają z usług jądra poprzez standardowe wywołania systemowe. Dlatego własnościowe bazy danych i agenci monitorujący mogą być dostarczani dla Linux bez naruszania licencji. Licencja permisywna tworzy odwrotną presję, a tę różnicę warto zrozumieć przed wyborem platformy: zobacz Linux i FreeBSD jako platformy serwerowe.

Dlaczego jądro monolityczne wygrało w praktyce

29 stycznia 1992 roku Andrew Tanenbaum opublikował w grupie dyskusyjnej comp.os.minix wiadomość zatytułowaną "LINUX is obsolete". Postawił w niej dwie tezy. Jądra monolityczne, w których sterowniki i systemy plików działają w jednej uprzywilejowanej przestrzeni adresowej, uznał za konstrukcję z lat 70., natomiast mikrojądra, w których te elementy działają jako zwykłe procesy, za przyszłość. Twierdził również, że Linux jest na stałe związany z architekturą Intel 386, więc nigdy nie stanie się przenośny.

Na kwestię przenośności odpowiedziano poprzez portowanie. Wersja 1.2 z marca 1995 roku dodała wsparcie dla Alpha, SPARC i MIPS. Wersja 2.0 z czerwca 1996 roku wprowadziła port dla 64-bitowej architektury Alpha.

Na kwestię projektu odpowiedziano kompromisem. Linux nigdy nie stał się mikrojądrem. Zyskał natomiast ładowalne moduły jądra: pliki obiektowe, które można wstawić do działającego jądra i ponownie usunąć, dzięki czemu sterownik jest dostarczany oddzielnie od pliku binarnego jądra.

lsmod | head
modinfo virtio_net | head -5

lsmod wyświetla listę aktualnie załadowanych modułów. modinfo wskazuje plik, z którego pochodzi moduł, oraz parametry, które akceptuje. Na serwerze wirtualnym większość ścieżki dyskowej i sieciowej stanowią moduły, dlatego jeden obraz jądra uruchamia się na sprzęcie, z którym nigdy wcześniej nie współpracował.

Moduły zapewniły tę elastyczność bez kosztów, jakie niosła ze sobą architektura mikrojądra. Izolowanie sterownika we własnym procesie oznacza konieczność opłacenia przełączenia kontekstu i przesyłania komunikatu przy każdym wywołaniu, a w 1992 roku koszt ten był wysoki.

Koszt, który Linux zachował i z którym należy się liczyć, jest następujący: moduł działa z pełnymi uprawnieniami jądra, więc wadliwy moduł powoduje awarię całego systemu, a nie tylko jednego procesu. Problem ten dotyczy głównie modułów spoza głównego drzewa źródeł (out-of-tree). Sterownik producenta, który nie znajduje się w głównym nurcie, musi być przebudowywany przy każdej aktualizacji jądra, co wykonuje DKMS podczas procesu upgrade'u. Gdy taka kompilacja kończy się niepowodzeniem, urządzenie po restarcie jest po prostu niedostępne.

Dlaczego wdrożenie SMP trwało piętnaście lat

Jądro Linux 2.0 z czerwca 1996 roku było pierwszym, które obsługiwało symetryczne wieloprocesorowe przetwarzanie (SMP), co oznacza możliwość pracy wielu procesorów CPU pod kontrolą jednego jądra. Pierwsza implementacja wykorzystywała pojedynczą blokadę, tzw. big kernel lock (BKL), przez co w kodzie jądra mógł przebywać w danej chwili tylko jeden procesor. Drugi procesor wspomagał zatem obciążenia obliczeniowe w przestrzeni użytkownika, ale w niewielkim stopniu pomagał przy wywołaniach systemowych, ponieważ ustawiały się one w kolejce do tej samej blokady.

Usunięcie tej blokady zajęło piętnaście lat. Pozostali użytkownicy zostali przeniesieni na mechanizm blokad o drobnej ziarnistości (fine-grained locking), głównie dzięki pracy Arnda Bergmanna, a BKL został usunięty w wersji 2.6.39, wydanej 18 maja 2011 roku. Harmonogram zadań (scheduler) rozwijał się w podobnie powolnym tempie: harmonogram O(1) w wersji 2.6.0, Completely Fair Scheduler (CFS) od wersji 2.6.23 w 2007 roku oraz EEVDF, który zastąpił CFS w wersji 6.6 w październiku 2023 roku.

Dzięki tej pracy plan z 4 vCPU jest obecnie standardem. Wyznacza on również limit, o którym warto wiedzieć. Na współdzielonym serwerze wirtualnym jądro systemu zarządza wątkami, a hypervisor zarządza jądrem. Uruchom top i sprawdź pole %st. Wartość steal time oznacza czas procesora, który jądro było gotowe wykorzystać, ale host przydzielił go innej maszynie wirtualnej, więc żadna optymalizacja wewnątrz jądra nie pozwoli go odzyskać.

Dlaczego seria 2.6 zmieniła sposób budowania jądra

Przed wersją 2.6 numery wersji występowały w parach. Parzysta druga liczba oznaczała serię stabilną (2.4), a nieparzysta – rozwojową (2.5). Wersja 2.4 została wydana 4 stycznia 2001 roku, a 2.6 – 17 grudnia 2003 roku, więc użytkownicy czekali prawie trzy lata na kolejną stabilną serię. Dystrybucje nie mogły czekać, więc stosowały backporty. Dwóch dostawców wydających "2.4" dostarczało jądra różniące się tysiącami łatek.

Podział ten porzucono po wersji 2.6. Główna linia rozwojowa (mainline) otwiera teraz okno scalania (merge window) na około dwa tygodnie, przyjmuje nowe prace, a następnie publikuje kandydatów do wydania (release candidates), aż do momentu wyciszenia. Wydania następują co 9 do 10 tygodni, zgodnie z cyklem dokumentowanym przez kernel.org. Druga część modelu pojawiła się 4 marca 2005 roku wraz z pierwszym wydaniem drzewa stabilnego (stable tree), będącego aktualizacją zawierającą wyłącznie poprawki do wersji 2.6.11, utrzymywaną przez Grega Kroah-Hartmana i Chrisa Wrighta. Drzewo stabilne przyjmuje poprawki i odrzuca nowe funkcje.

Skutkiem ubocznym jest to, że numer wersji przestał być obietnicą. Wersje 3.0, 4.0, 5.0 oraz 7.0 nie są przepisaniem kodu od nowa. Torvalds zwiększa pierwszą liczbę, gdy druga staje się na tyle duża, że zaczyna mu przeszkadzać, dlatego w kwietniu 2026 roku po wersji 6.19 pojawiła się wersja 7.0. Z punktu widzenia serwera istotne jest to, którą gałąź śledzi dana dystrybucja oraz czy ta gałąź nadal otrzymuje poprawki.

Jak awaria BitKeeper doprowadziła do powstania git w kwietniu 2005 roku

Od lutego 2002 roku jądro systemu było rozwijane w BitKeeper, własnościowym rozproszonym systemie kontroli wersji firmy BitMover należącej do Larry'ego McVoya, począwszy od serii 2.5. Firma BitMover przyznała programistom jądra darmową licencję z określonymi warunkami: zakaz pracy nad konkurencyjnym narzędziem kontroli wersji oraz zakaz inżynierii wstecznej BitKeeper. Wielu programistów nie akceptowało tworzenia wolnego jądra przy użyciu narzędzia, którego kodu nie mogli analizować.

Sytuacja załamała się w kwietniu 2005 roku, gdy Andrew Tridgell zaprezentował program komunikujący się z repozytoriami BitKeeper. Firma BitMover uznała to za inżynierię wsteczną i wycofała darmową licencję. Jądro straciło system kontroli wersji w trakcie cyklu wydawniczego.

Prace nad git rozpoczęły się 3 kwietnia 2005 roku. Torvalds ogłosił projekt 6 kwietnia. Już 7 kwietnia git był w stanie hostować własny kod, co oznacza, że historia samego git była przechowywana w git. Pierwsze scalenie kilku gałęzi przeprowadzono 18 kwietnia. W czerwcu 2005 roku git zarządzał wydaniem 2.6.12. Niedługo później Torvalds przekazał opiekę nad projektem Junio Hamano i powrócił do prac nad jądrem.

Projekt narzędzia wynikał bezpośrednio z napotkanych problemów: tysięcy współtwórców oraz opiekunów pobierających zmiany od siebie nawzajem przez sieć, której nikt nie ufa. Każdy obiekt jest identyfikowany przez skrót swojej zawartości, więc zmiana choćby jednego bajtu w historii zmienia nazwę każdego kolejnego commita. Dlatego klon repozytorium stanowi dowód, a nie tylko deklarację. Każdy potok wdrażania, każde repozytorium konfiguracji, serwis hostingowy kodu, do którego wypycha zmiany większość zespołów oraz serwer git, który można uruchomić samodzielnie, wyrosły z licencyjnego sporu dotyczącego jądra systemu.

Co gwarantuje model LTS, a czego nie gwarantuje

Wersja Mainline nie jest przeznaczona do środowisk produkcyjnych. Wydanie mainline jest zastępowane nowym po 9 do 10 tygodniach. Gałąź stable otrzymuje poprawki przez kilka tygodni po każdym wydaniu. Gałęzie Longterm, określane jako LTS, otrzymują wsparcie przez lata i to na nich opierają się dystrybucje.

Wersja 2.6.32, wydana w grudniu 2009 roku, była momentem, w którym model ten potwierdził swoją skuteczność. RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1 oraz Ubuntu 10.04 LTS korzystały z tego jądra, a gałąź była utrzymywana do lutego 2016 roku, czyli ponad sześć lat od momentu jej pojawienia się.

Obietnica wsparcia zmieniała się kilkukrotnie. Początkowo wynosiła dwa lata, później dla niektórych gałęzi wzrosła do sześciu lat. W 2023 roku opiekunowie gałęzi stable skrócili domyślny okres wsparcia do dwóch lat, ponieważ przenoszenie poprawek (backporting) do starych drzew jądra pochłania czas opiekunów, a stare gałęzie są w niewielkim stopniu testowane w rzeczywistych warunkach. 25 lutego 2026 roku Greg Kroah-Hartman ponownie opublikował dłuższe prognozy po konsultacjach z firmami zależnymi od tych gałęzi, a obecne ramy czasowe wynoszą od trzech do sześciu lat.

[
  {
    "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
  }
]

Strona kernel.org wymienia 6 gałęzi longterm według stanu na sierpień 2026 roku. Najstarsza z nich, 5.10, otrzyma poprawki obejmujące 6.0 lat, kończąc wsparcie w Dec 2026. Najnowsza, 6.18, ma być wspierana do Dec 2028, co oznacza 3.1 lat poprawek.

Daty te należy traktować jako wartość minimalną, a nie jako sztywną umowę. Prognozy dla wersji 6.6 oraz 6.12 zostały wydłużone w lutym 2026 roku, jednak gałąź, z której nikt nie korzysta, może zostać porzucona wcześniej. Dystrybucja zazwyczaj podejmuje decyzję za użytkownika: Debian 13 dostarcza jądro 6.12, a Ubuntu 26.04 LTS jądro 7.0. Ta różnica stanowi praktyczną treść pytania o wybór między LTS a wydaniem tymczasowym na serwerze i jest tym, co faktycznie zmienia się w systemie podczas aktualizacji Ubuntu 24.04 do 26.04.

Z tego faktu wynika pewna pułapka. Polecenie uname -r w systemie Ubuntu 24.04 wyświetla wynik zbliżony do 6.8.0-51-generic. Jest to bazowa wersja upstream powiększona o własne poprawki dystrybucji, więc numer ten wskazuje jedynie punkt startowy gałęzi, a nie listę zawartych w niej poprawek. Skanery bezpieczeństwa, które oceniają jądro wyłącznie na podstawie ciągu wersji, generują w tym przypadku fałszywe alarmy dla jąder dostarczanych przez dystrybucje.

O co obecnie toczy się spór w jądrze

Trwają dwa spory, oba dotyczą tego, kto wykonuje pracę.

Rust trafił do infrastruktury w wersji 6.1 w grudniu 2022 roku. W wersji 7.0 usunięto etykietę eksperymentalną, więc podstawowymi językami jądra są C, asembler oraz Rust, a proces budowania nie wymaga już kompilatora w wersji nightly. Spór dotyczy utrzymania kodu. Konserwator kodu w C, który zmienia interfejs, może uszkodzić powiązania (bindings) w języku Rust, których nie czyta, a dyskusja toczy się wokół tego, czyim obowiązkiem jest ich naprawa.

Drugi spór dotyczy wkładu sztucznej inteligencji. Sasha Levin zaproponował politykę w lipcu 2025 roku, po tym jak na listy dyskusyjne trafiła rosnąca liczba łatek wspomaganych maszynowo. Dokument został zatwierdzony 23 grudnia 2025 roku i znajduje się obecnie w dokumentacji procesowej jądra pod adresem docs.kernel.org/process/coding-assistants.html. Agent AI nie może dodawać znacznika Signed-off-by, ponieważ ten wiersz poświadcza Developer Certificate of Origin (DCO), a poświadczyć go może tylko człowiek. Wsparcie narzędziowe deklaruje się znacznikiem Assisted-by:, zmienionym z Co-developed-by: podczas przeglądu, ponieważ narzędzie nie jest autorem. Wygenerowany kod musi być zgodny z licencją GPL-2.0-only. Człowiek, który przesyła łatkę, dokonuje jej przeglądu i ponosi za nią odpowiedzialność.

Presja stojąca za tą polityką wynika z czasu potrzebnego na przegląd. Wygenerowanie łatki zajmuje sekundy, a jej sprawdzenie zajmuje konserwatorowi całe popołudnie. Znacznik nie rozwiązuje tej nierównowagi. Pozwala jednak zachować pochodzenie kodu: historia nadal rejestruje, kto podpisał się pod każdą zmianą, co jest wartością, którą DCO miało chronić od 2004 roku.

Co ta historia oznacza dla wynajmowanego serwera

• Licencja jest powodem, dla którego można odczytać i przebudować jądro uruchamiane przez dostawcę oraz dlaczego oprogramowanie własnościowe nadal na nim działa.
• Monolityczna architektura sprawia, że jeden błąd sterownika powoduje restart całego urządzenia, a moduł spoza głównego drzewa źródeł musi być przebudowywany przy każdej aktualizacji jądra.
• Model wydawniczy sprawia, że numer wersji mówi niewiele, podczas gdy gałąź i data zakończenia wsparcia (EOL) mówią niemal wszystko.
• Typ wirtualizacji decyduje o dostępnych możliwościach: w przypadku KVM można uruchomić własne jądro i ładować moduły, podczas gdy w wirtualizacji kontenerowej współdzielącej jądro hosta, uname -r wyświetla wersję hosta, modprobe kończy się niepowodzeniem, a niektóre parametry sysctl są dostępne tylko do odczytu.

FAQ

Dlaczego jądro Linux nadal korzysta z licencji GPLv2, a nie GPLv3?

Torvalds w 2007 roku odrzucił przejście na GPLv3, głównie ze względu na wymóg przeciwdziałania tivoizacji, który zmusza producenta urządzenia dostarczającego kod GPL do akceptowania zmodyfikowanych wersji tego kodu. Traktuje on zablokowany sprzęt jako wewnętrzną sprawę producenta. Zmiana licencji jest również w praktyce niemal niemożliwa, ponieważ prawa autorskie do jądra należą do tysięcy współtwórców, a nie istnieje żadna umowa o przeniesieniu praw, na której można by się oprzeć. Jądro jest objęte licencją GPL-2.0-only, więc kod oferowany wyłącznie na warunkach GPLv3 nie może zostać scalony.

Czy jądro Linux jest jądrem monolitycznym czy mikrojądrem?

Jest to jądro monolityczne z ładowalnymi modułami. Sterowniki i systemy plików działają w przestrzeni adresowej jądra, a lsmod pokazuje te aktualnie załadowane. Skutkuje to szybkością z jednej strony i większym ryzykiem awarii z drugiej: wadliwy moduł może spowodować panikę całego systemu, podczas gdy w przypadku mikrojądra utracony zostałby tylko jeden proces. Obraz ten złagodniał od 1992 roku dzięki systemom plików FUSE działającym w przestrzeni użytkownika oraz programom eBPF, które jądro weryfikuje przed ich uruchomieniem.

Jaka jest różnica między jądrami mainline, stable i longterm?

Mainline to drzewo Torvaldsa, wydawane co 9 do 10 tygodni, w którym jako pierwsze pojawiają się nowe funkcje. Wersja stable bazuje na najnowszym wydaniu mainline i otrzymuje poprawki błędów przez kilka tygodni. Gałęzie longterm otrzymują poprawki przez lata i to na nich dystrybucje budują swoje jądra. Strona kernel.org wymienia bieżące gałęzie longterm wraz z przewidywaną datą zakończenia wsparcia dla każdej z nich.

Czy jądro Linux akceptuje kod napisany przez AI?

Tak, zgodnie z polityką przyjętą w grudniu 2025 roku. Narzędzie musi zostać wskazane w tagu Assisted-by:, agent AI nie może dodawać linii Signed-off-by, a wygenerowany kod musi być zgodny z licencją GPL-2.0-only. Człowiek przesyłający kod składa podpis, co oznacza, że sprawdził poprawkę i bierze za nią odpowiedzialność zgodnie z Developer Certificate of Origin.

Którą wersję jądra należy uruchomić na serwerze?

W niemal każdym przypadku tę, którą utrzymuje Twoja dystrybucja. Jądro dystrybucyjne to gałąź longterm z backportowanymi poprawkami oraz testami dostawcy; to na nim opierają się obrazy Twojego dostawcy i umowy wsparcia technicznego. Buduj nowsze jądro mainline tylko wtedy, gdy potrzebujesz konkretnego sterownika lub funkcji, i sprawdź datę zakończenia wsparcia gałęzi, na którą przechodzisz, zanim podejmiesz decyzję.