Fundamentalne są także zmiany w rdzeniu jądra v2.6. Większość aplikacji funkcjonujących na v2.4 będzie pracować także na jądrze v2.6. Jednakże kilka większych zmian może dotyczyć już wdrożonych aplikacji. Z tego powodu Red Hat, dominujący dystrybutor Linuksa, zrezygnował z oficjalnego wsparcia jądra v2.6 w najnowszych produktach Advanced Server i Enterprise Server, pozostając przy w znacznym stopniu przystosowanym jądrze pochodzącym z v2.4.21.

Budując architektury serwerowe, które mogą używać rozszerzeń jądra v2.6, administratorzy będą musieli konfigurować i budować jądra dostrojone do specyficznych zastosowań. Problem ze specyficznymi jądrami dystrybucji Linuksa polega na tym, że często znacznie one odbiegają od oficjalnych wydań - zarówno w opcjach domyślnych, jak i łatkach, które zawierają.

Z drugiej strony, jądra te obsługują zazwyczaj duży wybór sprzętu, ponieważ są konfigurowane z prawie każdym modułem, który mógłby być użyty do zapewnienia kompatybilności sprzętowej w docelowym systemie. Zawierają też zazwyczaj łatki, co może zwiększać lub zmniejszać wydajność (w zależności od pracy, jaką wykonuje serwer). Administratorzy obsługujący takie serwery zazwyczaj skupiają się na dobrej obsłudze łatek, konfigurowaniu i budowaniu przystosowanych jąder, zapewniających kompatybilność sprzętową oraz na zapobieganiu obniżeniu wydajności (jeśli jest to możliwe). Bazowa dystrybucja pracująca na serwerze może wymagać pewnych modyfikacji potrzebnych do akceptacji jądra v2.6, takich jak dodanie nowych narzędzi modutils i mkinitrd.

Droga do centrów danych

Z chwilą pojawienia się jądra v2.6 przedsiębiorstwa nie mogą dłużej ignorować systemów operacyjnych open source. Główni dostawcy Linuksa przygotowują nowe wydania oprogramowania dla przedsiębiorstw, oparte na jądrze v2.6. Nowy system operacyjny open source wydaje się więc przygotowany do znaczącego zmniejszenia luki dzielącej go od możliwości jego starszego kuzyna Uniksa.

Linux 2.6 jest skalowalny na duże systemy z większa pamięcią i dużo większą liczbą urządzeń niż jego poprzednik v2.4. Obsługuje większy zakres procesorów zagnieżdżanych. Wydaje się więc, że w jądrze tym upakowano wystarczającą liczbę mechanizmów, aby zwrócił on uwagę decydentów IT w przedsiębiorstwach.

Firmy używające dużych serwerów także zapewne zwrócą uwagę na Linux 2.6 ze względu na wsparcie NUMA (Non-Uniform Memory Access) na maszynach wieloprocesorowych.

Wsparcie SMP (Symmetric MultiProcessing) w Linuksie wraz z jądrem 2.6 nabiera całkiem nowego wymiaru. Co prawda v2.4 mogła teoretycznie obsługiwać do 64 procesorów w jednym systemie, ale w praktyce mogła być użyteczna jedynie w konfiguracjach z maksimum ośmioma procesorami. W jądrze v2.6 ta teoretyczna granica wzrosła do 256 procesorów, w praktyce natomiast - w opinii wielu projektantów - stabilny powinien być 32-procesorowy system SMP (Intel x86). Przy zapewnieniu obsługi procesorów 64-bitowych, takich jak Itanium czy IBM Power Architecture, ten limit pozwoli na stosowanie Linuksa na procesorach 64-bitowych.

Linux z nowym jądrem może pracować szybciej na dużych serwerach, a także lepiej z dużymi zestawami pamięci masowych. Projektanci jądra pokonali techniczne ograniczenia związane z liczbą urządzeń pamięciowych, jakie mogą być podłączone do Linuksa, i uzyskali lepszą obsługę zarządzania woluminami pamięci masowych. Co więcej mają teraz do dyspozycji kompletnie przeprogramowany podsystem we/wy z obsługą asynchronicznego we/wy, pozwalający na szybszą i bardziej efektywną pracę aplikacji na styku z pamięcią masową.

Linuks przebył długą drogę od momentu, kiedy Linus Torvalds zapowiedział w roku 1991 jego wersję 0.1. Jądro v2.6 wnosi wiele nowych mechanizmów, a także większe usprawnienia w zakresie wydajności w porównaniu z wersją 2.4. Było ono przygotowywane z myślą o zapewnieniu Linuksowi awansu do wyższego etapu rozgrywek: rzeczywistej obecności w sieciach przedsiębiorstw. Kontynuując swoją drogę do centrów danych, Linux musi się rozwijać wraz z potrzebami swojej bazy użytkowników. Musi też odpowiadać na wyzwania tych, którzy poszukują nowych rozwiązań. Jądro v2.6 wydaje się przygotowane do tych zadań

<hr size=1 noshade>Linux - krótka historia

W procesie projektowania kolejnych wersji przyjęto zasadę rozróżniania ich numerami parzystymi i nieparzystymi. Parzyste (v2.0, v2.2, v2.4) są wersjami stabilnymi, natomiast nieparzyste - niestabilnymi, czy inaczej roboczymi. Z chwilą, gdy jądro zostanie wydane z numerem parzystym, powstaje również wersja o numerze nieparzystym, a poprzednie jądro o numerze parzystym wchodzi w tryb konserwacji.

Tak więc z chwilą powstania wersji v2.6 Linux kernel v2.4 będzie konserwowany w zakresie łatek bezpieczeństwa i łatek błędów, ale oficjalne wydanie jądra v2.4 nie będzie zawierać nowych mechanizmów - większe uaktualnienia będą wykonywane w ramach odgałęzień jądra 2.6. Wraz z 2.6 narodziło się wydanie robocze v2.7, stając się podstawą projektowania jądra v2.8, którego zakres nie został jeszcze ściśle sprecyzowany.

W procesie projektowania głównym forum wymiany poglądów dla projektantów jądra jest LKML - Linux Kernel Mailing List (http://kernel.org ). Lista ta nie jest zastrzeżona i każdy użytkownik Linuksa może wysłać tam pytanie lub komentarz odnośnie do jądra Linuksa. Ponieważ każde pytanie z listy mogło być już zadane wcześniej, archiwa LKML są olbrzymim rezerwuarem wiedzy dla tych, którzy pracują nad jądrem Linuksa lub próbują rozwiązać jakiś problem związany z Linuksem.

Parzysta wersja jądra Linuksa jest cały czas rozwijana i "odpluskwiana". Jednocześnie podobny proces odbywa się w stosunku do jądra nieparzystego (roboczego).

Obsługa nowych architektur, takich jak AMD Opteron, powstaje zazwyczaj w formie projektów zewnętrznych, które zasilają kod oficjalnego jądra. W praktyce obsługa sprzętu niemasowego jest często dostępna jedynie w postaci łatek do jądra produkcyjnego. To dlatego kompilacja wersji v2.4 i v2.6 na Opterona wymaga odpowiednich łatek. Z chwilą, gdy zostaną one sprawdzone, łatki te są włączane do oficjalnego jądra produkcyjnego i zawarte w kolejnym oficjalnym wydaniu. Łatki mogą być także dostępne dla jądra niestabilnego i przeznaczone do włączenia do następnych wydań jądra.

Decyzja o tym, jakie mechanizmy i łatki będą zawarte w oficjalnym wydaniu jądra, jest poprzedzana szeroką debatą wśród projektantów, ale ostatecznie jest podejmowana przez jego konserwatora - główny autorytet, biorący na siebie trud codziennej konserwacji, jak również odpowiedzialność za oficjalne wydania. Z powodu rozmiaru i zakresu funkcji jądra żaden z konserwatorów, nawet sam Linus Torvalds, nie może w pełni znać i rozumieć wszystkich składowych jądra. Aby rozwiązać ten problem, pieczę nad wybranymi sekcjami kodu i zasilaniem kolejnych wydań sprawdzonymi zestawami łatek, powierzono kilku nieoficjalnym konserwatorom podsystemów.

Nowe wydania stabilnego jądra są weryfikowane przez proces wydania "wersji kandydującej" (release candidate), podczas którego łatki jądra są testowane przez społeczność linuksową. Poza wydaniem kandydującym, łatki dla jądra stabilnego i niestabilnego są dystrybuowane przez kilku wybranych projektantów. Łatki takie zawierają zazwyczaj kod eksperymentalny, który nie został oficjalnie wprowadzony do źródła przez Linusa Torvaldsa, a także oprogramowanie usuwające błędy lub zapewniające obsługę sprzętu przewidywaną do włączenia w następnym wydaniu.

Konserwatorzy jądra są odpowiedzialni za fragmenty będące pod ich opieką, ale Linus Torvalds nadal jest postacią pierwszoplanową. Oficjalnie jest on stałym konserwatorem na bieżąco projektowanego jądra i wybiera konserwatorów nowych stabilnych wersji z chwilą, gdy zbliża się czas ich wydania. Kierowany przez setki projektantów, kilku konserwatorów i zespół pytań i odpowiedzi, liczony w tysiącach, projekt jądra Linuksa utrzymuje się na stałej ścieżce rozwoju.