Dodatek B

B.1 Jak pomóc w dalszym rozwoju podręcznika?

Wersja „źródłowa” podręcznika znajduje się pod adresem: http://www.stardust.webpages.pl/ltg/files/handbook-current.tar.bz2 (przed przystąpieniem do modyfikacji warto sprawdzić, czy posiadamy najnowszą). Po wprowadzeniu modyfikacji wystarczy zrobić

$ diff -uprN wersja-oryginalna/handbook.tex wersja-zmodyfikowana/handbook.tex > łatka.patch

i wysłać ją na adres moc.liamg|ikswortoip.k.k.lahcim#moc.liamg|ikswortoip.k.k.lahcim (przy większych zmianach proszę też dodać CC na listę dyskusyjną LTG).

B.2 Gdzie uzyskać pomoc w testowaniu?

Jeśli potrzebujesz pomocy przy rozwiązaniu jakiegoś problemu związanego z jądrem Linux, masz wątpliwości czy znalazłeś(aś) błąd, to śmiało zadawaj pytania!

Strona pomocy w wiki: http://www.stardust.webpages.pl/ltg/wiki/index.php/Pomoc
Strona listy dyskusyjnej: http://groups.google.com/group/linux-testers-group-pl

B.3 Trochę o Linux Testers Group

Czyli odpowiedzi na wcześniej niezadane pytania.
P: Czym się zajmuje LTG?
O: Testowaniem jądra Linux.

P: Jak można dołączyć do LTG?
O: Wystarczy zacząć testować…

P: Gdzie jest jakaś strona domowa?
O: Pod adresem http://www.stardust.webpages.pl/ltg/

P: Jest jakaś lista dyskusyjna?
O: Jasne - pod adresem http://groups.google.com/group/linux-testers-group-pl

B.4 Przyczyny propagacji błędów do stabilnych wersji Linuksa

Poniższy artykuł został napisany dla Dragonia Magazine Nie będzie to odkrywczym stwierdzeniem jak napiszę, że w Linuksie jest dużo błędów. Jednak skąd się one konkretnie biorą i jak można zapobiegać ich propagacji do stabilnych wersji systemu? Na to pytanie postaram się odpowiedzieć w poniższym artykule. Na początku musimy sobie odpowiedzieć na proste pytanie - co to jest błąd w programie? Błąd w programie jest niezamierzoną (zdarzają się przypadki, że zamierzoną) pomyłką programisty, której skutkiem jest nieprawidłowe działanie programu. To nieprawidłowe działanie może się objawiać na kilka różnych sposobów:

• zawieszanie się programu
• podawanie niepoprawnych wyników obliczeń
• możliwość przejęcia kontroli nad programem przez włamywacza
• zafałszowywanie/uszkadzanie danych wejściowych i/lub wyjściowych
• niewydajne/nieefektywne algorytmy
• wycieki pamięci, sytuacje wyścigowe etc.

Błąd może wynikać z pomyłki podczas pisania kodu źródłowego programu, jak i na etapie planowania jego modelu. Zdarzają się również sytuacje, w których błąd powstaje za sprawą niepoprawnego działania narzędzi służących do kompilacji programu. Błędy, które powstają na etapie pisania kodu źródłowego są często dużo łatwiejsze do wyeliminowania niż te, które powstają na etapie planowania modelu programu. Niewłaściwe decyzje podjęte w tej fazie mogą powodować występowanie bardzo trudnych do wyeliminowania błędów.
Jakie są główne przyczyny powstawania błędów w Linuksie? Zasadniczą przyczyną jest to, że jest to projekt duży i skomplikowany, dlatego większość ludzi pracujących nad systemem skupia się na swoich ulubionych podsystemach, które są im dobrze znane. Problem pojawia się wtedy, gdy ktoś próbuje zmodyfikować kod, którego dobrze nie zna i do końca nie rozumie. Dlatego też za sporą część błędów są odpowiedzialni ludzie, którzy Linuksem zajmują się dorywczo.
Kolejną przyczyną jest coś co się nazywa Nowy Model Rozwoju http://www.stardust.webpages.pl/ltg/wiki/index.php/Proces_rozwoju_j%C4%85dra_Linux. Dawniej Linux był rozwijany na zasadach podobnych do tych, na jakich jest rozwijane normalne oprogramowanie:

• wydanie wersji stabilnej i usuwanie błędów, które się do niej przedostały (np. wersje 2.2.x)
• cykl rozwojowy w którym jest dodawana nowa funkcjonalność, następnie następowała próba stabilizacji (np. wersje 2.3.x)
• kolejne wydania stabilne (np. wersje 2.4.x)

Jednak od wersji 2.6.8 model rozwoju uległ zmianie i teraz wygląda tak (na przykładzie wersji 2.6.20 i 2.6.21):

• wydanie wersji stabilnej 2.6.20, następnie są publikowane poprawki oznaczane jako 2.6.20.x
• praca nad nową wersją, dodawanie nowej funkcjonalności - 2.6.20-gitX (przeważnie około dwóch tygodni)
• zakończenie prac nad wersją rozwojową, rozpoczęcie cyklu stabilizacyjnego - 2.6.21-rcX
• wydanie stabilnej wersji 2.6.21

Taki przyspieszony model rozwoju ma swoje wady i zalety. Do wad można zaliczyć to, że postępuje on naprawdę bardzo szybko, więc dużo błędów może przejść z wersji rozwojowej do stabilnej. Do zalet powinniśmy zaliczyć to, że nie trzeba czekać na nową funkcjonalność przez długi okres czasu (dawne wersje niestabilne były rozwijane bardzo długo, a pierwsze wersje stabilne przeważnie trudno było za takie uznać).

Jaka jest przyczyna wprowadzania w Linuksie błędów związanych z bezpieczeństwem systemu? W doskonałej książce „Secure Programming for Linux and Unix HOWTO” David A. Wheeler wymienił kilka powodów dla których w programach powstają błędy, które mogą zostać wykorzystane przez włamywaczy. Ze swojej strony dorzucę tylko jeden powód, który nie znalazł się na tej liście - mała ilość odpowiednich programów (lub ich mała skuteczność) ułatwiających wykrywanie potencjalnych luk.

Deweloperzy Linuksa przywiązują bardzo duże znaczenie do jakości kodu. Przed zgłoszeniem do przeglądu nowego kodu, deweloper powinien upewnić się, że spełnia on wszystkie wymogi wymienione w Documentation/SubmitChecklist. Następnie kod jest czytany przez innych deweloperów, którzy zgłaszają swoje uwagi - najczęściej odnośnie:

• stylu kodowania - styl kodowania w Linuksie powinien być jednolity - jest to bardzo ważna sprawa, ponieważ ułatwia czytanie i rozumienie kodu (można się z nim zapoznać czytając Documentation/CodingStyle)
• zastosowanych algorytmów - każdemu zależy na tym, aby były one jak najwydajniejsze
• poprawności i przejrzystości struktur danych - nie ma gorszej rzeczy, niż nieprzemyślane struktury danych

W zasadzie trudno jest określić, jaka konkretnie część błędów (lub potencjalnych błędów) jest eliminowana na etapie przeglądania kodu. Kolejnym krokiem jest testowanie kodu w drzewie danego podsystemu lub -mm, gdzie jest on sprawdzany pod względem współgrania z innymi częściami jądra systemu. Jest to bardzo ważny etap, ponieważ w nim powinny zostać wyłapane wszystkie poważniejsze błędy. Następnie kod jest włączany do rozwojowej wersji drzewa Linusa i tam następuje ostateczna próba jego stabilizacji.
Włączenie kodu do Linuksa nie jest takie proste - musi on spełniać narzucone standardy. Najczęściej następuje to za pośrednictwem tak zwanej „sieci zaufania” - kod jest włączany do drzewa danego podsystemu i dopiero z niego trafia do mainline. Przyczyną takiego stanu rzeczy jest to, że Linus Torvalds nie ma czasu czytać każdej wprowadzanej poprawki i wychodzi z założenia, że opiekunowie podsystemów wiedzą lepiej jak powinny one wyglądać oraz, że włączone do nich łatki zostały już odpowiednio przetestowane.
Proces dbania o jakość kodu w Linuksie jest bardzo rygorystyczny - dużo bardziej niż w innych projektach. Dlaczego więc do wersji stabilnych przedostaje się tak dużo błędów? Ostatnia poprawka „stable” 2.6.20.2 składa się z ponad stu łatek poprawiających konkretne problemy. Odpowiedź jest bardzo prosta - niewystarczająca ilość osób poświęca czas na testowanie i poprawianie błędów w nowej funkcjonalności. Niektórzy uważają, że remedium na te problemy powinien być powrót do starego modelu rozwoju, jednak ma on bardzo poważne wady:

• na nową funkcjonalność trzeba czekać bardzo długo (ostatni duży cykl rozwojowy 2.5.x - trwał ponad dwa lata!)
• deweloperzy ponoszą dodatkowe koszty czasowe związane z przenoszeniem nowej funkcjonalności do stabilnych jąder dystrybucyjnych - ten czas mogliby poświęcić na jej tworzenie, poprawianie błędów etc.
• długi czas potrzebny na stabilizacje po długim cyklu rozwojowym

Jak widać nowy model rozwoju ma poważne zalety, jednak bez wystarczającej ilości ludzi testujących wydania rozwojowe nie będzie się sprawdzał. Sprawa jest bardzo skomplikowana, ponieważ deweloperzy nie mogą poprawiać błędów o których istnieniu nie wiedzą. Większość problemów wychodzi dopiero, gdy inni ludzie zaczynają używać danego kodu. Sytuacja może się pogorszyć do tego stopnia, że nowe stabilne wersje Linuksa będą działały dobrze tylko na maszynach o zbliżonej konfiguracji do tych, na jakich były testowane ich wersje rozwojowe. Dobrym rozwiązaniem obok zwiększenia liczby osób testujących kod, może być zmniejszenie szybkości wprowadzania zmian. Jednak czy naprawdę tego chcemy? Z jednej strony zahamowanie rozwoju Linuksa może mieć bardzo pozytywny wpływ na jego stabilność, z drugiej strony trzeba się liczyć z tym, że wszystkie potrzebne nowe funkcje będą wchodzić do niego z coraz większym opóźnieniem. Wszystkich zainteresowanych zmianą tego stanu rzeczy zapraszam do współpracy oraz dyskusji na naszej liście http://groups.google.com/group/linux-testers-group-pl.

B.5 Licencja

Uznanie autorstwa 2.5 Polska

Wolno:

• kopiować, rozpowszechniać, odtwarzać i wykonywać utwór
• tworzyć utwory zależne
• użytkować utwór w sposób komercyjny

Na następujących warunkach:

• Uznanie autorstwa. Utwór należy oznaczyć w sposób określony przez Twórcę lub Licencjodawcę
• W celu ponownego użycia utworu lub rozpowszechniania utworu należy wyjaśnić innym warunki licencji, na której udostępnia się utwór.
• Każdy z tych warunków może zostać uchylony, jeśli uzyska się zezwolenie właściciela praw autorskich.

Powyższe postanowienia w żaden sposób nie naruszają uprawnień wynikających z dozwolonego użytku ani żadnych innych praw. http://creativecommons.org/licenses/by/2.5/pl/legalcode

Oczywiście, jeżeli licencja CC uznanie autorstwa Ci nie odpowiada, to możesz użyć dowolnej licencji uznanej za licencje Open Source http://www.opensource.org/licenses/, jeśli tylko zachowasz informacje o autorach, oraz ludziach, którzy przyczynili się do powstania tego podręcznika.

O ile nie zaznaczono inaczej, treść tej strony objęta jest licencją Creative Commons Attribution-Share Alike 2.5 License.