Nie jest żadną nowością, że wieloletni programiści jądra potrafią ostro skrytykować patche innych twórców kodu na liście dyskusyjnej Linux Kernel Mailing List (LKML) – najwyraźniej jednak coraz bardziej zaczyna to irytować Andrew Mortona, który w ostatnim czasie stanowczo reagował na tego typu wpisy. Ostatnio spotkało to znanego ze swojej bezpośredniości Ala Viro, kiedy w niewybredny sposób skrytykował on pewną trywialną łatę, nie zawierającą żadnej sensownej funkcjonalności, lecz jedynie zmiany stylistyczne w kodzie źródłowym. Andrew Morton odpisał na to, że Al Viro może się wypowiadać wyłącznie za siebie i podziękował ironicznie za "wspaniały sposób" dyskutowania z nowymi interlokutorami.
Rozwinęła się z tego dłuższa dyskusja, w której Morton i inni programiści zaprezentowali bliżej swoje stanowiska. Morton wspomniał przy tym, że szczególnie programiści z niektórych państw azjatyckich są bardzo wrażliwi na to, jak przyjmowane są ich patche w społeczności programistów jądra. Jest to też powodem, dla którego niektórzy w ogóle nie chcą udostępniać wyników swojej pracy.
Wielu programistów jądra i systemu X pracuje obecnie nad patchami omawianymi na LKML podczas rozwoju wersji kernela 2.6.22, które mają umożliwić jądru OS-u przejęcie zadania inicjalizacji kart graficznych i obsługi ekranu – jest to tzw. kernel-based modesetting. Ma to zapewnić jednolite zasady dostępu do karty graficznej – w obecnie stosowanym modelu dochodzi od czasu do czasu do konfliktów między sterownikiem bufora ramki, Direct Rendering Managerem oraz X serwerem. Ponadto serwer X-ów powinien móc pracować bez praw użytkownika root, lepiej funkcjonować ma również tryb czuwania (standby), ponieważ po wspomnianej aktualizacji jądro będzie w stanie lepiej inicjować system graficzny po wyjściu z tego trybu. Również przełączanie między konsolą tekstową oraz X-serwerem powinno działać płynniej i bez zakłóceń obrazu.
Zaprezentowana ostatnio Fedora 9 zawiera te rozszerzenia jądra i uwzględniającą je wersję X serwera – całość ma jednak charakter mocno eksperymentalny i działa jedynie z nowszymi zintegrowanymi na płycie głównej układami graficznymi Intela. W oficjalnym jądrze patche te powinny się pojawić wraz z ukazaniem się wersji 2.6.27 bądź 2.6.28, tak aby do tego czasu programiści zdążyli wszystko właściwie ogarnąć – początkowo ten zestaw aktualizacji miał być gotowy już teraz. Jesse Barnes opublikował na LKML patch, który powoduje, iż w przypadku ciężkich błędów (tzw. Ooops) system automatycznie przełącza się na konsolę tekstową, aby móc pokazać informacje z debugera. Do tej pory przy tego rodzaju błędach środowisko graficzne po prostu zawieszało się i poza miganiem diod klawiatury użytkownik nie otrzymywał w zasadzie żadnych informacji, co się właściwie stało. Programiści dowcipkowali na ten temat w ubiegłym roku i obecnie nie wiadomo, czy na serio jednak rozważają pomysł prezentowania informacji o błędach o załamaniu systemu na niebieskim tle. Byłoby to zachowanie analogiczne do windowsowego Blue Screen of Death nazwane żartobliwie – Blue Penguin of Death.
Przy okazji publikacji trzeciej wersji RC jądra 2.6.26 Linus Torvalds zauważył, że system zarządzania kodem źródłowym Git jest używany już mniej więcej tak długo, jak wcześniej komercyjny BitKeeper. Z tego ostatniego zrezygnowano po pewnych perturbacjach na początku 2005 roku i wybrano Git. Jednak mimo licznych poprawek w ubiegłych latach, narzędzie to jest uznawane za trudne do używania. wielu programistów jądra narzeka na jego toporność objawiającą się np. przy próbie łączenia różnych gałęzi rozwojowych – dopiero niedawno Torvalds w ramach dyskusji na grupie gmane.linux.kernel wyjaśnił, gdzie stosowanie Git jest sensowne i w jaki sposób najlepiej go używać przy rozwoju jądra Linux.
W skrócie:
* Po wspomnianych w poprzednim tekście o zmianach w jądrze dyskusjach na temat usunięcia z kernela krytycznego dla wydajności BKL (Big Kernel Lock) wielu programistów udostępniło swoje aktualizacje, które przygotowują kod do usunięcia BKL bądź ograniczają jego użycie. Pierwsze z nich powinny zostać uwzględnione już w zapowiadanym na późne lato kernelu 2.6.27.
* Programiści X.org udostępnili w ostatnich dniach kilka nowych wersji komponentów X.org. Nie jest jednak jasne, czy planowana początkowo na koniec kwietnia, a następnie przesunięta na maj publikacja wersji X.org 7.4 rzeczywiście nastąpi jeszcze w tym miesiącu.
* AMD opublikował wersję 8.5 graficznego sterownika fglrx dla 32- i 64-bitowych systemów x86.
* Programiści kompilatora GCC (GNU Compiler Collection) udostępnili wersję 4.2.3.
* Diomidis D. Spinellis w interesującym artykule "A Tale of Four Kernels" porównał jądra systemów Free BSD, GNU/Linux, Solaris i Windows.
* Matthew Garret opublikował w tym miesiącu trzy wpisy w swoim blogu (1, 2, 3), których tematyka dotyczy zastosowania technologii oszczędzania energii nowoczesnych procesorów pod Linuksem. Wpisy objaśniają między innymi, dlaczego najczęściej nie ma sensu zmuszać procesorów do pracy w wolniejszym trybie przy zastosowaniu funkcji takich jak Cool'n'Quiet albo Enhanced Intel Speedstep (EIST).
* Dave Airlie i Matthias Hopf opublikowali w swoich blogach kilka informacji na temat stanu prac nad obsługą grafiki 3D dla układów AMD r500 (seria Radeon X1000) w sterownikach graficznych radeon i radeonhd.
* Ukazała się wersja 3.0.2 pakietu Lm_sensors, zawierającego sterowniki i narzędzia do odczytu informacji monitoringu sprzętu.
* Deweloperzy odmiany Linuksa działającej w czasie rzeczywistym przenieśli drzewo RT na wersję 2.6.25; nieco później pojawiły się też kolejne aktualizacje: 2.6.24.7-rt[7-9] oraz 2.6.25.4-rt2, poprawiające kilka błędów z poprzednich wersji.