Ten tekst jest tłumaczeniem wywiadu z Conem Kolivasem deweloperem jądra przeprowadzonego przez serwis Apcmag.com

Kim jest Con Kolivas?

Con Kolivas jest wiodącym deweloperem jądra i rzecznikiem Linuksa na systemy biurkowe. Ostatnio postanowił zrezygnować z rozwoju jądra. Dlaczego?

W wywiadzie z APCMag.com, Con daje wnikliwą odpowiedź, zgłębiając naturę: rynku hardware’u i software’u oraz problemów, które jądro Linuksa musi przezwyciężyć, i co najważniejsze dlaczego postanowił odejść.

Mało kto wie, spoglądając na działania Cona, że hakowanie jądra to tylko jego hobby. W życiu codziennym Con Kolivas pracuje jako anestezjolog w szpitalu w Melbourne.

Con jest jednym z bardziej znanych osób uczestniczących w rozwoju jądra. W swojej działalności skupił się na zwiększeniu wydajności jądra dla komputerów domowych, co przyniosło mu rzeszę fanów. Swój zestaw łatek, który miały duży wpływ na ulepszanie jądra, sygnował monogramem -ck. Niektóre z łatek włączono do głównej linii jądra, a jego inne pomysły nadal inspirują zmiany zachodzące w jądrze.

Ostatnio jednak Con ogłosił, że nie będzie już dłużej deweloperem jądra. Zainteresowany tym co skłoniło Cona do takiej decyzji, skontaktowałem się z nim żeby porozmawiać o byciu deweloperem i o przyszłości komputerów.

Odpowiedzi jakie uzyskałem przerosły moje oczekiwania, Con nie tylko opowiedział o tym dlaczego odszedł ale również o zmaganiach jakie stoją przed jądrem Linuksa. Con wyraził również swój pogląd na naturę rynku hardware’u i software’u, który doprowadził komputery do takiego stanu jakie znamy. Nie ważne jest czy jesteś użytkownikiem Windowsa czy Linuksa, przeczytaj ten artykuł, bo Con stawia diagnozę temu, co trapi wszystkich użytkowników.

Jak Microsoft zniszczył innowacyjność architektury komputerów PC

APC: Jak doszło do tego, że zacząłeś rozwijać jądro? Sprawiało Ci to przyjemność? I skąd się bierze ta pasja, która Cię do tego nakręcała?

CK

Zazwyczaj odpowiedziałbym na to pytanie prosto z mostu, ale ostatnio miałem możliwość, żeby spojrzeć na to co wciągnęło mnie do rozwoju jądra. Dzięki temu potrafię lepiej odpowiedzieć na to pytanie. Jeśli dasz mi dość swobody odpowiem również na inne twoje możliwe pytania. Przedstawię ci swoją interpretację historii rozwoju komputerów osobistych.

Pierwszy komputer, który posiadałem to było ze 24 lata temu. Miałem to szczęście towarzyszyć scenie komputerowej, niedługo po tym jak powstała. Od tego czasu byłem świadkiem rozwoju komputerów. Najpierw z podnieceniem nieznając kierunku w jakim pójdą twórcy komputerów, później niecierpliwie oczekując ich działań, bo znałem już trend rozwoju.

Pod koniec lat osiemdziesiątych rozpoczęła się złota era komputerów. W tym czasie było mnóstwo producentów sprzętu, wchodzących na rynek komputerów osobistych. Każdy z nich oferował nowe i fascynujące zarazem rozwiązania sprzętowe, oraz unikalne cechy systemu operacyjnego. Ogromny wybór i przede wszystkim współzawodnictwo. Oczywiście, producenci mieli podobne pomysły co do software’u i hardware’u. Prawie niewyobrażalne jest jak przypomnę sobie, że w tym czasie w Australii wiodącym rozwiązaniem na rynku komputerów osobistych była Amiga sprzedana w setkach egzemplarzy.

Każdy kto żył w epoce pierwszych komputerów Amigi przypomni sobie jak unikalne było podejście do informatyki, oraz jak bardzo ta firma posunęła naprzód rozwój komputerów domowych. Od tego czasu było wiele prób reanimacji tego podniecenia. Ale miało być nie o Amidze, której ostatecznie nie powiodło się z innych powodów. Jeszcze podsumowując moją myśl o Amidze chciałem uzmysłowić jak bardzo radykalne projekty sprzętu komputerowego kierowały rozwojem. Osiągnęły to czego oprogramowanie na tamtych założeniach projektowych nie było w stanie dokonać.

W tamtym czasie komputery osobiste i zgodne z IBMem były nadal nędznymi i drogimi maszynami z gloryfikowanym trybem tekstowym - DOSem.
Wejdźmy do ciemnej epoki, w której stworzenie komputerów kierowanych sprzętowo nie powiodło się z powodu słabego marketingu, a także ich rozwoju oraz wielu innych problemów. Właśnie wtedy oprogramowanie zwycięża, zamiast wzajemnego współzawodnictwa, rozwój sprzętu ustępuje przed oprogramowaniem i dostosowuje się do niego, jak również do systemu operacyjnego.

Wszyscy jesteśmy świadomi co de facto stało się standardem systemu operacyjnego w tamtym czasie. Jako rezultat nie było rynku zbytu dla sprzętu, który nie był kompatybilny z konstrukcją systemu operacyjnego. Jedyny słuszny system operacyjny zwyciężył, a inne systemy operacyjne poległy jedne za drugim. Producenci sprzętu zmuszeni sytuacją rynkową zaczęli tworzyć rozwiązania tylko dla kurczącego się rynku oprogramowania.

Sprzęt od tego czasu stał się niewolnikiem systemu operacyjnego. Rozpoczęło się to około 1994 roku i trwa po dziś dzień. Co najgorsze producenci sprzętu powoli zaczęli wykupywać siebie nawzajem, coraz bardziej zawężając rynek nowych rozwiązań. Obecnie producenci sprzętu tworzą tylko szybsze i większe wersje wszystkiego co zostało już wynalezione. Nadal dokupujemy szybsze procesory, więcej ramu, większe twarde dyski, szybsze karty graficzne tylko po to by obsłużyć system operacyjny. Rynku nie stać na odrodzenie innowacyjności, z tego nie będzie pieniędzy, bo nikt tego nie kupi. Komputery stały się nudne.

Otwórz świat Linuksa/GNU. Wszyscy wiemy, że zaczęło się to jako hobby. Wszyscy wiemy, że Linux stał się większy niż ktokolwiek wtedy przypuszczał. Trzeba powiedzieć fair, że jest teraz jednym z najważniejszych rozwiązań, wśród nielicznych konkurujących graczy oprogramowania i systemów operacyjnych. Dzięki Linuksowi/GNU rozwój odbywa się również w systemie operacyjnym, który jest de facto standardem - Windowsie. Jednak uważam, że nie zasługiwał by stać się tym czym jest dziś. Jeśli konkurencja między innowacyjnym sprzętem a oprogramowaniem nadal trwałaby, deweloperzy nie zostaliby przyciągnięci tak bardzo, a Linux nie wyewoluowałaby do dzisiejszej postaci. Sprzęt komputerowy prawie się nie zmienił w ciągu tego czasu. Pecety stały się stały się potężne do granic absurdu, w porównaniu do tego czym były kiedy po raz pierwszy uruchomiono Linuksa w 1991 roku, ale ta potęga nie jest kwestią zwiększenia użyteczności czy innowacyjności, lecz tylko prędkości.

No więc co z PC? Komputer osobisty według wszystkich rachub, które miały miejsce 20 lat temu umiera. Wszyscy wiemy, że jest to badziewie. Przez jakiś określony czas będzie nadal obejmował przetwarzanie informacji i komunikację, wbrew narastającej frustracji. Internet z całą pewnością ugruntował pozycję komputera osobistego jaką dziś zajmuje.

Linux został stworzony by obsłużyć architekturę komputerów osobistych. Tym, którzy szukają pewnej przyjemności i ciekawych doświadczeń podczas użytkowania komputera, jedyny słuszny system po prostu nie odpowiada. Chcemy podłubać, chcemy mieć kontrolę i władzę nad każdym elementem systemu operacyjnego lub wierzymy w pewnego rodzaju wolność, którą oferuje Linux, dlatego właśnie z niego korzystamy. To jest z pewnością powód dlaczego wciągnął mnie Linux, pragnąłem czegoś, czego mógłbym używać na domowym komputerze.

Komputer PC jest badziewiem. To tandeta. W ciągu wielu lat użytkowania komputery stały się przeładowane i zwalniały we wszystkich rzeczach, które miały dla nas największe znaczenie. Wszyscy posiadamy dziś komputery, które uznano by za superkomputery 10 lat temu itd. Dlaczego wszystko jest nadal tak spowolnione? Jeśli są w postępie geometrycznym coraz szybsze dlaczego musimy czekać coraz dłużej na uruchomienie systemu operacyjnego i innych aplikacji? Oczywiście kiedy pozwolimy komputerom dobrać się do działania na liczbach, komputery je wręcz miażdżą, w tej dziedzinie są zachwycające (tylko enkoduj sobie plik wideo a będziesz pełen podziwu). Ale we wszystkim innym muszą być znacznie wolniejsze niż kiedykolwiek.

Dzisiejsze komputery mogą być 1000 razy szybsze niż 10 lat temu, jednak rzeczy, na których nam zależy by były szybsze, wciąż nie są obsługiwane przez komputery szybciej.

Standardową odpowiedzią jaką słyszę od ludzi jest “ale zauważ, że komputery robią znacznie więcej rzeczy niż 10 lat temu, te porównanie nie jest fair”. Komputery są 10 razy wolniejsze, pomimo że mają być 1000 razy szybsze, w takim razie musiałyby wykonywać 10,000 razy tyle rzeczy. Jest dla mnie oczywiste, że te 10,000 rzeczy więcej, które muszą wykonać są zbędne.

APC: Czy problemy związane z wydajnością na systemach osobistych stały się motorem napędowym dla ciebie?

CK

Tak. Zacząłem dłubać i ulepszać Linuksa na biurka. Pomyślałem: “jasne jeśli będę miał całkowitą kontrolę nad oprogramowaniem, będę w stanie przyspieszyć działanie systemu”. Musi być sposób by ulepszyć to, podrasować tamto i zoptymalizować jeszcze co innego żeby przyspieszyć. Jednak ulepszenia w warstwie użytkownika wydawały się tak ograniczone kiedy zacząłem przygodę z Linuksem. Jądro działał na biurku na pół gwizdka, a co dopiero starać się wydostać większy priorytet reakcji od aplikacji, które działają na powierzchni jądra. Spadek po uniksach był oczywisty. Próbowaliśmy nadać inny kształt systemowi, który nigdy nie był projektowany z myślą o komputerach osobistych, to musiało boleć.

Jedynym miejscem gdzie zauważałem jakąś poprawę w prędkości był rozwój jądra. Zmiany te nigdy nie były olbrzymie, ale dało się zobaczyć mniejsze przycinanie podczas intensywnej pracy procesora itd. Pierwszy zestaw łatek, które ujrzały światło dzienne nie zawierały żadnej linii mojego kodu i zostały stworzone dla jądra 2.4.18, to był luty 2002 roku. Wtedy nawet nie wiedziałem jak wygląda język programowania C, nigdy nie byłem na studiach informatycznych. Tak tkwiłem, aż do początku rozwoju jądra 2.6 (jesteśmy nadal w czasach jądra 2.5). Obserwowałem tworzenie jądra i żeby być szczerym muszę powiedzieć, że byłem przerażony. Wszystkich hakerów pracujących nad jądrem, których darzyłem szacunkiem, widziałem jak rozpaczliwie pracowali jakby poza tym nowym i ulepszonym jądrem. Prawie każdy opracowywał fragment kodu, na którym zależało wielkim przedsiębiorstwom, użytkownik końcowy ich nie obchodził.

Co gorsze, mimo że oczywiście chciałbym zobaczyć Linuksa na 1024 procesorach 1000 twardych dysków, nie znoszę faktu, żeby wprowadzić te implementacje musieliśmy zabić wydajność na komputerach osobistych. Czy ja się aby nie przesłyszałem? Zabić wydajność? Tak, właśnie to mam na myśli.

Jeśli mielibyśmy określić liczbowo wydajność, to wymiernie jest ona lepsza niż kiedykolwiek. Mimo to, wystarczyło uruchomić aplikację audio i okazuje się, że muzyka przycina się. Po prostu przycina się! Procesor tryliardo - miliardohercowy a my nie możemy odtworzyć muzyki? Spróbuj przeciągnąć okno, zacznie się krztusić i skakać. Albo zapisz duży plik na dysk i zobacz jak porusza się twój kursor, podczas gdy cały twój pulpit jest bezużyteczny przez minutę.

Zachciało mi się płakać.

Przypominam sobie nawet sytuację kiedy staraliśmy się przedstawić te problemy jednemu developerowi powiedział, że nie wie o co nam chodzi bo nie może odtworzyć tego problemu na jego komputerze z 4 procesorami, 4 GB ramu i 4 dyskami połączonymi w macierz RAID… Pomyślcie sobie o sprzęcie jaki miał wtedy przeciętny użytkownik cztery lata temu. Nadal się dziwicie dlaczego jądro na komputerze osobistym było do bani? Developerzy rozwijali jądro dla czegoś co nie było komputerem osobistym. Byli zatrudnieni przez wielkie korporacje, których nie obchodziły zwykłe pecety (i nadal nie obchodzą) te firmy chciały przynajmniej 1% przyrostu w bazach danych lub przepustowości w benchmarkach.

Linux wygrał… Jesteśmy bezkonkurencyjni na rynku serwerów i baz danych, ponieważ wszystkim wielkim markom zależało na Linuksie. Pieniądze płynęły na rozwój jądra, by ulepszyć wydajność w ważnych dla tych firm obszarach.

…użytkownicy przegrali. Komputer osobisty, na którym Linux był początkowo projektowany i dla niego przeznaczony, przestał być tak ważny. Wydajność tak jak rozumie ją użytkownik końcowy przestała istnieć. Jedyne miejsce, w którym liczyłem na wzrost wydajności na zwykłych pecetach, czyli kernel, zaczął być tworzony w zupełnie innym kierunku.

Próby Cona ulepszenia wydajności Linuksa na komputerach biurkowych

APC: Co w takim razie starałeś się zrobić, żeby przekonać developerów jądra do poświęcenia większej uwagi użytkownikom końcowym?

CK

Zająłem się tworzeniem pewnego benchmarku, który miał określić ilościowo jakie problemy z wydajnością są obecne na komputerach klasy PC. Pierwszy benchmark jaki stworzyłem nazwałem “Contest” (zawody, jak również zakwestionować - przyp. tłum.) (gra słów była zamierzona). Ten benchmark był strasznie skomplikowany. W użyciu był bardzo trudny, zwłaszcza jeśli chodzi o odpowiednie ustawienie go i zinterpretowanie wyników, ale przynajmniej próbowałem. Trochę to pomogło. Pewne zmiany zaszły jako rezultat tego benchmarku, głównie na polu usprawnienia operacji We/Wy dysku. Nadal trzeba było poprawić obniżającego wydajność planistę zadań procesora.

Miałem pewne doświadczenie we włączaniu łatek w poprzednich jądrach i o ironio większość z nich związana była z planistą zadań procesora. Pomimo tego, że nigdy nie nauczyłem się programować, zacząłem spoglądać w kod i powoli wszystko zaczęło tworzyć jakiś sens.

Zacząłem wskazywać ludziom miejsca w kodzie, w których jak myślałem był problem. Grzmiałem i piekliłem się, mówiąc w czym tkwi problem. W końcu wymyśliłem, że sam muszę zacząć dłubać w jądrze i ulepszyć to co trzeba.

Po kilku nieudanych eksperymentach zacząłem pisać kod, który pomógł, nawet bardzo. Jak się okazało, ludzie zwrócili uwagę na moje wysiłki i ostatecznie mój kod włączono do jądra. Nigdy do końca nie byłem zadowolony z tego, jak planista procesora zmagał się z interaktywnością, ale przynajmniej jądro było już używalne na komputerach domowych.

Nie będąc usatysfakcjonowany z tego jak obecny mechanizm stanowiący podłoże planisty działał, postanowiłem napisać go od nowa. Tak powstał drugi zestaw łatek opatrzonych “-ck”. Z tą różnicą, że kod włączony do jądra był w większości mój. Tak zaczęła się moja przygoda z pisaniem kodu źródłowego.

W skrócie, znalazłem się w sytuacji, w której pisałem kod jaki pomógł wielu użytkownikom ale nie było sposobu, żeby obliczyć jak duże były to zmiany. Zawsze istniał efekt placebo. Sprawiał on, że użytkownikowi trudno było jasno określić i poświadczyć czy zaszła poprawa, czy też nie.

Starałem się bardzo, być odporny na ten efekt placebo w ciągu lat testowania. Ale trzeba powiedzieć, że skoro moją stronę odwiedziło blisko 1 milion użytkowników, to chyba są ludzie, którzy twierdzą, iż zachodzi różnica. Nieumiejętność udowodnienia ilościowo zysku wydajności jaki oferowały łatki -ck, wpłynęła na śmierć projektu.

APC: Jaki kod został włączony w główną linię jądra?

CK

Patrząc wstecz, kiedy zbiór łatek był dobrze znany, mała ilość kodu trafiła z nich do oficjalnego jądra. Większość tego co jest w jądrze to zmiany dotyczące planisty - zwiększające interaktywność, sprawiedliwość w rozdzielaniu zadań dla SMP i wielowątkowości itd. Było też wiele mniejszych poprawek, które obecne są w innych obszarach takich jak podsystem pamięci wirtualnej, programowa hibernacja, planista We/Wy dysku twardego i inne poprawki.

Główny nacisk jaki położyłem, jest ciągle związany z obszarem łatek dostępnych w ostatnim wydaniu 2.6.22-ck1. Łatki, które nie zostały włączone do oficjalnego wydania jądra odzwierciedlają wielki problem jaki ciągle istnieje na komputerach osobistych. O ironio, mimo mojego przeciwdziałania, wydaje mi się, że problem powiększa się z roku na rok.

Wydaje się, że pojawiającym się wyzwaniom nigdy nie poświęcił wiele uwagi pełnoetatowy developer. Problem zostaje zauważony dopiero wtedy, gdy zdaje się nazbyt oczywiste jego istnienie. Wtedy nawet na liście mailowej jądra narzeka się na słabą wydajność systemu.

APC: Czy odbiło się na tobie te społeczne zaangażowanie w rozwoju jądra?

CK

Tak. Bez wątpienia, ilekroć byłem bardzo zaangażowany w rozwój jądra nie przesypiałem nocy, myśląc nad rozwiązaniem. Brakowało mi snu i prawdopodobnie odbiło się to na mojej pracy i moim życiu rodzinnym. Starałem się bardzo mocno, nigdy nie poświęcać tych dwóch spraw na rzecz rozwoju jądra. Ale chyba przeholowałem. Ważne jest dla mnie żeby nigdy nie żałować tego co robiłem, dlatego mogę powiedzieć, że nadal jestem zadowolony z mojego wkładu w jądro.

APC: Czy była jakaś siła, która sprawiła, że odstawiłeś klawiaturę i zaprzestałeś pisania łatek -ck?

CK

Większość ludzi jest świadomych jaki był mój udział w rozwoju jądra. Był motywowany na trzech frontach. Moje odejście nie ma nic wspólnego z pracą i życiem osobistym.

Po pierwsze, to była zawsze zabawa. Odkąd pamiętam byłem geekiem komputerowym i lubiłem spędzać godziny przed komputerem robiąc … no właściwie cokolwiek. Poświęcanie się czemuś co zawsze było pasją, było dla mnie źródłem radości.

Po drugie, to było wyzwanie intelektualne. Istniały rzeczy, które zawsze chciałem zrobić z jądrem, a z którymi nikt inny się nie chciał zmierzyć. Rzuciwszy wyzwanie, dokonałem czegoś z czym nie miałem styczności wcześniej - programowanie na wysokim poziomie. Nauczyłem się od cholery o systemach operacyjnych, a także o innych podstawowych rzeczach, które dla większości studentów informatyki są nudne.

To było dla mnie wszystko nowe. Jest bardzo mało (inni będą się kłócić, że nie ma wcale) nowych poszukiwań w projektowaniu systemów operacyjnych. Patrząc na Linuksa istnieje innowacja w podejściu do radzenia sobie z różnymi rzeczami ale nie odkryto niczego nowego jak naprawić te problemy. Te same kwestie istniały zawsze - konflikt między projektami sprzętu i oprogramowania. Poznałem wielu ludzi, którzy ogłaszali, że wynalazłem uczciwy sposób planowania dla procesora. Chciałem to sprostować, ja sam nie wydaje tak niedorzecznych sądów.

To co zrobiłem, to próba umieszczenia tego, co było już znane w ograniczonych ramach sprzętu komputerowego i struktury jądra. Podczas gdy ogólny zarys tych problemów i ich rozwiązań jest znany od wielu lat, ciągle zawęża się dręczące problemy dotyczące hardware’u w opozycji do software’u. Innowacyjność leży tylko w zastosowaniu tych pomysłów. Podejście akademickie do tych problemów jest bezużyteczne w rzeczywistym świecie. Z drugiej strony czysty haking, na dłuższą metę również cechuje katastrofa. Odnalezienie równowagi między hakingiem a nie ignorowaniem wielu akademickich osiągnięć, to jest właśnie potrzebne.

APC: Czy odnalazłeś tą równowagę?

CK

Właśnie, że nie. To było to do czego dążyłem. Uważam, że jest bardzo mało developerów, którzy to potrafią. Jeżeli jedna osoba popełni błąd w wyborze miejsca i rodzaju kodu, wtedy jest to niemożliwe do wykrycia (i wcale nie mówię, że to był mój kod!)

Po trzecie, to była wycieczka w świat własnego “ja”. Jeśli ulepszyłem coś na czym mi zależało, odkryłem, że wielu ludziom zależało na tym. Powód tego jest oczywisty, byłem zwykłym użytkownikiem pecetów, który udawał że jest potrafi hakować jądro. Gdy tylko ulepszałem coś co dotyczyło zwykłych użytkowników, to i zaczęło im zależeć na poprawkach. Przypominam sobie hakera, którego bardzo szanuje, żartował z moich “fanów” i pytał jak może przyciągnąć do siebie tłum. Wniósł do jądra prawdopodobnie 1000 razy więcej linii kodu do jądra ode mnie, mimo to ja miałem wyznawców.

Przyciągnąłem do siebie wyznawców, ponieważ hakowałem rzeczy, na którym zależało ludziom. Jedną z rzeczy, która motywowała mój wkład w jądro przez tyle lat było “dziękuje” od użytkowników zestawu łatek -ck.

Nadal chyba nie odpowiedziałem na twoje pytanie co sprawiło, że zaprzestałem rozwoju jądra? Wydaje mi się, że wyjaśnienie moich motywów pośrednio tłumaczy dlaczego skończyłem z tym.

Głos użytkowników nadal jest obecny. To użytkownicy głośno powiedzieli, że odchodzę.

Wyzwanie intelektualne? Oczywiście ono nadal istnieje.

Zabawa? Tak, to właśnie zostało we mnie zabite. To przestało być zabawą. W moim opublikowanym emailu, w którym ogłosiłem, że odchodzę wyjaśniłem to pokrótce. Zbiór łatek -ck był przez pewien czas bez znaczenia, poza główną linią jądra, był tylko piaskownicą dla moich eksperymentów. Jak tylko zakres zmian powiększał się, ulepszenia stały się bardziej drastyczne i były doskonale dostrzegalne. To doprowadziło, do tego że coraz więcej ludzi pytało kiedy łatki -ck zostaną włączone do oficjalnego jądra. Ilość próśb rosła, a moja determinacja włączenia się w główny nurt jądra malała. Od czasu do czasu wysyłałem łatki na http://lkml.org/. Zainteresowanie rosło, więc zwiększyła się ilość próśb o wejście łatek do oficjalnego jądra. No to próbowałem.

Spytałeś wcześniej jakie łatki dostały się do głównego nurtu, a ja wymieniłem Ci listę różnych, pomniejszych łatek. Znaczenie łatek, które nie weszły do jądra jest znacznie większa niż tych które są już w jądrze.

APC: Co tak właściwie dopełniło miary

CK

Pierwszą odmową było odrzucenie oryginalnego stopniowego planisty procesora. Wyróżniał się zdecydowanie lepszą interaktywnością niż planista obecny w jądrze ale również tak, jak planista z jądra nie był idealny. Podczas gdy ciągle rozwijałem ten projekt, zainteresowanie developerów w tym czasie zwróciło się w inną stronę. Mianowicie, Andrew Morton (druga i ostatnia brama przed wejściem do oficjalnego jądra) powiedział, że jądro ma wiele innych palących kwestii i poprawek, którym należało poświęcić uwagę.

Oczywiście, że tak było. W jądrze było tak wiele podsystemów przepisywanych od nowa, że ciągle się coś psuło. A przepisywanie działających podsystemów i psucie ich, jest dalece bardziej istotnie niż ulepszanie obsługi na komputerach osobistych, co nie? Wkradła się we mnie gorycz. Postaram się powstrzymać emocje i dokończyć historię tak obiektywnie, jak tylko potrafię.

Głównym problemem był brak przekonywującego dowodu, że planista stopniowy lepiej sprawuje się na komputerach biurkowych. Sprawozdania użytkowników nie wystarczały. Nie było benchmarku, więc nie było dowodu na to, że jest lepszy, a raporty użytkowników tylko złościły osoby odpowiedzialne za jądro, ponieważ brakowało im obiektywizmu. Nawet spróbowałem napisać benchmark, nazywał się Interbench. Zauważ, że interaktywność nie oznacza czegoś sprawniej działającego. To była znacznie lepsza aplikacja niż Contest ale mimo to nie mogłem zademonstrować przewagi mojego planisty na Interbenchu. Ilość różnic była trudna do określenia, jeśli nie niemożliwa do uzyskania tylko z suchych liczb wygenerowanych przez Interbencha.

Dzięki ogromnej pomocy uzyskanej od Williama Lee Irwina III (który stworzył podstawową architekturę) zamieściłem szkielet wbudowany w jądro, który umożliwiał korzystanie z tylu planistów ile byś sobie życzył, na zasadzie odpowiednich wtyczek (jako parametr w linii jądra podczas rozruchu systemu). Planowałem również rozszerzyć ten projekt, żeby można było zmieniać planistę już podczas włączonego systemu. Założenie było podobne do systemu modułowego jaki ma zarządca operacji We/Wy dla dysków twardych. Linus i Ingo (który utrzymuje kod obecnego planisty procesora) odrzucili go w przedbiegach, woleli żeby istniał jeden planista, który jest dobry we wszystkim.

Celem Plugscheda (plug - wtyczka moduł, scheduler planista) było dostarczenie bez zarzutu planistę stopniowego do oficjalnego jądra. Nie popierałem zbytnio pomysłu obecności modułowego planisty w jądrze ale Peter Williams, który do tej pory utrzymuje kod, tak.

Później doszła jeszcze sprawa przechwytywania pamięci wymiany. Spędziłem długie godziny nad utrzymywaniem kodu i ulepszaniem go. 18 miesięcy temu włączono go w linię jądra -mm. Andrew po dziś dzień jest nieprzekonany, że ten kod cokolwiek poprawił, zastanawia się czy czasem czegoś nie pogorszył. Nie zgłoszono żadnych wad, ani skarg dotyczących wydajności od 9 miesięcy. Stworzyłem nawet benchmark, który pokazywał jak to wszystko działało i wreszcie potrafił policzyć zysk! W przezabawny sposób Linus zmieniając stanowisko zapytał mnie poza listami dyskusyjnymi “ale czy to naprawdę w czymś pomaga?”. Sprawozdania użytkowników i benchmark, to ciągle za mało. Projekt przechwytujący pamięć wymiany znajduje się teraz w stanie zawieszenia, deweloperzy nie będą mieli wyjścia tylko pozbędą się go, bo nikt nie będzie się nim zajmował

I w końcu gwóźdź do trumny - planista procesora Staircase Deadline. Początkowo był rozwijany z boku projektu planisty stopniowego, lecz okazało się, że nie można oczekiwać wspaniałej interaktywności, kiedy ma się do czynienia z planistą, który ma pierwszorzędne znaczenie dla serwerów i systemów wielodostępnych - planistą sprawiedliwym.

Mnóstwo użytkowników i developerów, odkryło, że wiele długo nie poruszanych problemów odnośnie oficjalnego planisty w jądrze przestało istnieć za sprawą SD. Niektórzy niemal błagali mnie żebym przyspieszył sprawę włączenia całego kodu, jeden użytkownik domagał się nawet żeby Linus włączył mój kod nie jako ulepszenie obecnego planisty ale jako łatkę na błędy w jądrze. Utrzymywałem ten kod ciągle go naprawiając i ulepszając, tak by załatać inne “błędy” w jądrze.

Nagle pojawił się impas. Jeden hałaśliwy użytkownik odkrył, że planista, powinien zachowywać się sprawiedliwie, było to coś czego on oczekiwał od jądra. Rozpoczęła się wojna. Staraliśmy się naprawić naglące kwestie ale tym samym musieliśmy poświęcić kwestię interaktywności na rzecz sprawiedliwego zachowania planisty. Nie była to duża strata interaktywności, ale jednak. Ten użytkownik zamiast uruchomić program ze zmienionym priorytetem za pomocą `nice`, uznał że to kernel powinien sam zgadnąć kiedy jak ma działać. Nie ważne jak bardzo mądrego stworzysz planistę czy dobrze odgadującego intencje i tak zaistnieje sytuacja kiedy zadziała źle. Im więcej będzie zgadywał tym częściej będzie się mylił.

Są dwie opcje albo możesz włączyć zgadywanie, albo nie. Jeśli włączysz, musisz przejść przez trudy tworzenia planisty, który w 95% działa poprawnie ustalając priorytety i regulując opóźnienia procesora. Jeśli nie włączysz zgadywania jego zachowanie będzie w 100% poprawne, ponieważ planista ten działa tak jak ty mu rozkażesz. Wydawało mi się to tak oczywiste, że interaktywność była lepsza z oficjalnym planistą, który był sprawiedliwy. Mimo to projektanci jądra chcieli żebym ponownie podszedł do tego problemu i stworzył nowe rozwiązanie. Odmówiłem. Nalegałem żeby poświęcić małą stratę, a zyskać znacznie więcej. Planistę, którego podejście było deterministyczne i zawsze do przewidzenia, a zarazem ciągle był interaktywny, uważam za znacznie lepsze rozwiązanie niż to czego żądali ode mnie babrania się w hakowanie czegoś nowego.

Trochę później miałem problemy ze zdrowiem. Wypadł mi dysk na odcinku szyjnym, co oznaczało że muszę leżeć na wznak w łóżku przez 6 tygodni. Tak, rozwój jądra również przyczynił się do tego stanu rzeczy. Byłem do nieprzytomności nafaszerowany środkami odurzającymi i spędzałem dnie i noce leżąc. Nie mając nic lepszego do roboty denerwowałem się w związku z jądrem. Gdy tylko mogłem zakradałem się do komputera żeby móc wesprzeć kod nowymi pomysłami. Zrezygnowałem z tworzenia nowej wizji sprawiedliwego planisty, uznając że jest to błąd projektowy, którego nie da się naprawić.

Pewnego dnia, Ingo prawdopodobnie zdecydował, że byłoby niezłym pomysłem napisanie własnego planisty. Tak też zrobił, stworzył sprawiedliwego i zarazem interaktywnego planistę jako moduł do jądra. Otrzymał również pomoc od osoby, która rozpoczęła całą wojnę, ponieważ nie akceptowała mojego pomysłu na uczciwego planistę.

Miałem mnóstwo czasu leżąc w łóżku i zastanawiając się nad tym co robię i dlaczego. Zastanawiałem się również nad tym czy będę żałował decyzji jakiej zamierzałem dokonać. Chciałem skończyć pracę nad planistą Staircase Deadline, Ingo mógł porównywać swojego planistę z moim kodem, aniżeli ze starym obecnym w jądrze. Potem zamierzałem odejść na zawsze.

APC: Czy problemy z ego developerów są nieodłącznym problemem rozwoju projektów open-source?

CK

Wydaję mi się, na każdy problem w różnych modelach rozwoju oprogramowania ma wpływ wiele czynników. Ostatecznie to ludzie podejmują decyzje ale ja nie zamierzam tego komentować.

Istnieje jeden duży problem z rozwojem jądra. Rozwój Linuksa jest zupełnie odłączony od komunikacji ze osobami korzystającymi z niego na co dzień. No wiesz to są te osoby, o których się mówi, że stanowią bazę 99,9% użytkowników Linuksa.

Lista dyskusyjna na lkml.org jest sposobem dotarcia do developerów. Ale mówiąc umiarkowanie, lkml odstrasza użytkowników. Większość ludzi boi się napisać coś na listę, bo od razu uzna się ich za niekompetentnych albo wręcz głupich. Przeważnie mają rację, bo nie ma przyjaznego sposobu komunikowania się z developerami odnośnie kwestii związanych z jądrem. Bez wątpienia deweloperzy to ludzie pełni zabawy i przyjaźnie nastawieni ludzi. Zobaczcie tylko wywiad z Linusem.

Wydaje mi się, że większość developerów nie ma najmniejszego pojęcia jakie kwestie są ważne dla użytkowników. Tylko nieliczni odważni użytkownicy dzielą się swoimi spostrzeżeniami na lkml, czasami docierały one do mnie przez irca, moją listę dyskusyjną a nawet osobiście. Niektórzy z nich nawet się mnie obawiali, mimo że sam nigdy nie postrzegałem się jako developera jądra.

Przeszukaj różne fora wsparcia linuksowych dystrybucji (co sam robiłem, pytałem użytkowników Gentoo osobiście ponieważ sami z siebie bali się powiedzieć) żeby przekonać się ile jest tam poruszonych kwestii związanych z jądrem. Uwielbiam im mówić żeby nagle zaczęli zalewać lkml swoimi raportami dotyczącymi: nieudanych rozruchów systemu na różnych jądrach, znikania sprzętu czy pamięci, niepowodzenia w użyciu hibernacji itd.

To wszystko są oczywiste raporty błędów. Boją się o tym wspomnieć. Wiesz, jak ciężko komuś wspomnieć, że otwieranie nowych zakładek w Firefoksie jest wolniejsze od czasu zmiany planisty CPU? Z użytkownikami korporacyjnymi jest zupełnie na odwrót. Przyjrzyj się każdemu wydaniu jądra, po którym ktoś z nich niemal natychmiast raportuje: g*** benchmark wskazał 1% spadek za sprawą łatki Y. Zobaczysz też jak szybko deweloperzy poświęcają temu uwagę.

APC: A co robisz teraz kiedy masz tyle wolnego czasu, masz jakieś nowe plany projektów?

CK

Miałem, były to drobne zabawki, oprogramowanie w warstwie użytkownika z którym eksperymentowałem (narzędzia do kompresji, narzędzia do edycji wideo i kilka innych) myślałem, że do tego wrócę. Jednak gdy tylko spojrzałem na kod źródłowy, zrobiło mi się niedobrze, więc pewnie do tego nie wrócę.

W kręgu moich obecnych zainteresowań jest nauka języka japońskiego. To niezła zabawa i ogromne wyzwanie intelektualne, które pozwoli mi rozwinąć inne zainteresowania, takie jak oglądanie japońskiej kultury medialnej w oryginale - filmów, krótkich historyjek, mangi i anime). Nigdy do końca nie wiem jakie hobby “wpadnie mi w ręce”, ale obojętnie cokolwiek by to było, zawsze się bardzo angażuje.

APC: Dziękuje za poświęcony czas Con.

Korekta: t_ziel