Download: NewsKernel

Jądro
NOWOŚCI
NOWOŚCI W JĄDRZE
GIT
W ostatnim miesiącu kierunek kontroli wersji jądra stał się bardziej niepewny niż kiedykolwiek, a to z powodu odejścia BitKeepera i rozważania przez Linusa najprzeróżniejszych
opcji, z których żadna nie była jednak satysfakcjonująca. W krótkim okresie kilku tygodni krajobraz zmienił się diametralnie, a git (wymawiaj
pierwszy dźwięk jako ‘g’) stał się nie tylko ulubieńcem Linusa, lecz także wielkim zwycięzcą
w dziedzinie bezpłatnego oprogramowania służącego do kontroli wersji, pozostawiającym
wszystkich konkurentów daleko w tyle. Nawet
istniejące narzędzia do wersjonowania, takie jak
arch czy darcs są integrowane z git. Dzieje się
coś niezwykle ważnego.
Gdy Linus rozpoczynał pracę nad git, zaprojektował go jako system plików wyposażony
w polecenia niskiego poziomu, przeznaczone
do śledzenia zawartości danego katalogu. Opisywał je raczej jako „polecenia systemowe”,
służące do wykonywania podstawowych operacji, a nie jako zestaw narzędzi do kontroli wersji. Miał nadzieję, że git zostanie przykryty
„prawdziwym” systemem wersjonowania, zrealizowanym na wyższym poziomie w postaci
skryptów pełniących rolę poleceń oczekiwanych przez większość użytkowników.
Obecnie projekt Cogito Petera Baudis'a przypomina bardziej oparte na git narzę-
dzie wysokiego poziomu, przygotowane przez
Linusa do rozwijania jądra. Jednakże, na tym
etapie, wszystko może się zdarzyć. Jedyne, co
wydaje się być mniej więcej pewne, to świetlana przyszłość git w rozwoju jądra i wielu innych miejscach.
Może pojawić się pytanie, co się właściwie
dzieje? Przez cały czas, gdy Linus wykorzystywał BitKeepera, wszędzie pełno było oburzonych apostołów bezpłatnego oprogramowania,
będących jednocześnie świetnymi programistami, pracujących jak szaleni, aby stworzyć
bezpłatną alternatywę dla BitKeepera. A mimo
to nie przybliżyli się nawet do celu. Teraz,
w dzień po tym jak BitKeeper zniknął ze sceny,
pojawił się solidny i sprawny zastępca. Co się
stało? Odpowiedź brzmi: wiele różnych rzeczy.
Żadne z bezpłatnych rozwiązań alternatywnych nie wykorzystywało wiedzy o tym, czego
naprawdę chciał Linus. Od czasu do czasu Linus omawiał niedostatki poszczególnych, bezpłatnych systemów, lecz tylko programiści pracujący nad BitKeeperem potrafili wykorzystać
analizy i wykaz pożądanych funkcji, przygotowane przez Linusa. Wiele alternatywnych rozwiązań zakończyło swe istnienie, gdyż zbyt
dużo czasu poświęcono na implementowanie
zbędnych funkcji, podczas gdy prawdziwe niedostatki pozostały niepoprawione.
Linus opracował system plików git tak, by
działał on szybko i zezwolił na rozproszone prace projektowe. Nie rozdrabniał się i nie zgłębiał
MENTORZY JĄDRA
Projekt, którego czas z pewnością nadszedł.
Matt Mackall utworzył nową listę mailngową
'mentorzy jądra', której zadaniem jest nauczyć
nowicjuszy jak mają postępować, aby ich kod
wpisywał się w główną linię rozwojową jądra.
Matt twierdzi, że techniczne i obyczajowe
przeszkody mogą być bardzo zniechęcające.
Jest to niewątpliwie prawdą, ale większość
trudności nie jest zbyt wyszukana. Najgłębiej
ukrywane problemy pojawiają się wtedy, gdy
starzy wyjadacze wypowiadają się na temat
„właściwych” sposobów implementowania danych fragmentów kodu. Osoby początkujące
nie spodziewają się tak ukierunkowanej krytyki swego kodu i nie potrafią dostrzec logiki
w stawianych żądaniach, które często powodują konieczność wykonania dodatkowej pracy.
Inne problemy, takie jak brak pewności kto
powinien zatwierdzić daną łatę i podzielić ją
na mniejsze fragmenty, wywołują nie tak silną frustrację, mimo że poprawny podział dużych łat może być zadaniem bardzo skomplikowanym, a tym samym bardzo stresującym.
Bez względu na to, co można by jeszcze na
ten temat powiedzieć, zasady obowiązujące
podczas tworzenia jądra są bardzo mętne.
Projekt Mentorzy Jądra jest bardzo pożądanym dodatkiem w świecie Linuksa i z pewnością pomoże odnaleźć drogę nowym programistom.
w zbyt skomplikowane funkcje, które uważał za
zbędne. Ponadto zablokował swój projekt i nie
pozwolił programistom wymknąć się spod kontroli. Dzięki temu projekt posuwał się szybko na
przód, w ściśle określonym kierunku.
Wszyscy toczyli zażarte boje. Gdy Linus
oznajmił, że przerwał prace nad jądrem, aby
zająć się git, setki utalentowanych programistów podążyło za nim, pracując dzień i noc,
aby zrozumieć i stworzyć narzędzia otaczające
bazowy projekt.
Jeden z dyrektorów zarządzających BitMover, Larry McVoy twierdzi, że na korzyść BitKeepera zadziałał fakt, iż model tworzenia oprogramowania Open Source nie przystawał do realiów przygotowywania złożonych narzędzi.
Przez lata wskazywał popularność BitKeepera
wśród twórców jądra jako dowód na to, że metody stosowane podczas tworzenia bezpłatnego
oprogramowania są niezadawalające. Przez lata
nikt nie potrafił wykazać, że się mylił.
Nawet teraz, gdy tempo rozwoju git jest
w znacznej mierze zasługą znajomości cech
BitKeepera. I, oczywiście, niezdolność wszystkich rozwiązań alternatywnych do osiągnięcia
postaci chociażby zbliżonej do tego, co prezentuje bitKeeper, nadal zaprząta myśli apostołów Open Source i kierowników projektów.
Mimo to, nadejście git było szokującym fenomenem i przekroczyło najśmielsze oczekiwania. Jeśli historia git i BitKeepra czegoś nas
nauczy, to będzie to niewątpliwie dobra lekcja.
NOWOCZESNY
SPRZĘT
W KERNEL.ORG
Hewlett-Packard podarował kernel.org
dwa serwery DL585 quad Opteron,
z 24 GB RAM i dyskami 10 TB, wykorzystujące macierze MSA-30. Wymiana sprzętu jest odpowiedzią na narastające problemy z przepustowością, wynikające z tego,
że po pojawieniu się każdej nowej wersji
Linuksa, kernel.org jest wręcz bombardowana z całego świata. Oba nowe serwery
weszły do użycia na początku kwietnia bez
większej pompy.
NUMER 18 LIPIEC 2005
11
NOWOŚCI
Jądro
ŁĄCZENIE
PROJEKTÓW
SCSI
Projekty linux-iscsi i open-iscsi zostały połączone w jeden projekt iSCSI, wykorzystujący jako punkt wyjścia kod iscsi. Najwidoczniej, toczące się przez pewien czas między dwoma grupami programistów spory dobiegły końca i wszyscy doszli do wniosku, że razem mają
większe szansę na stworzenie naprawdę
dobrego stosu SCSI do Linuksa.
Po podjęciu decyzji, który z kodów bazowych ma być wykorzystany jako punkt
wyjścia, należy także zadecydować, jaki
system kontroli wersji zostanie użyty:
open-iscsi's Subversion czy linux-iscsi's CVS. Wszystko wskazuje na to, że
przynajmniej w najbliższym czasie, wykorzystywany będzie Subversion, ale wobec ciągłego naporu BitKeepera i git
wszystko jest możliwe.
12
NUMER 18 LIPIEC 2005
NOWY SYSTEM PLIKÓW CONFIGFS
Joel Becker stworzył nowy system plików ConfigFS – jeszcze jeden interfejs funkcjonujący
obok ioctls, ProcFS, udev, SysFS i DebugFS. Joel twierdzi, że „configfs nie ma na celu wyparcia
sysfs ani procfs, lecz ma wraz z nimi współistnieć.” Jednym z głównych zadań ConfigFS jest dostarczenie przejrzystego interfejsu, umożliwiającego korzystanie ze skryptów.
ConfigFS znajduje się ciągle we wczesnym stadium rozwoju, a niektóre szczegóły implementacyjne dopiero powstają.
Nie jest jasne, czy rzeczywiście istnieje potrzeba tworzenia jeszcze jednego intefejsu jądra opartego
o system plików. Najwyraźniej ConfigFS został zainspirowany brakiem rozwiązań, nawet jeśli wziąć
pod uwagę, że ostatnia próba, SysFS, jest całkiem satysfakcjonująca.
FUSE ZRYWA Z KOMPATYBILNOŚCIĄ
WSTECZNĄ
Miklos Szeredi wysłał szereg aktualizacji do FUSE (Filesystem in USEr-space), zmieniających
interfejs użytkownika, zrywając tym samym z kompatybilnością wsteczną. Zmiany były niezbędne
ze względu na konieczność zapewnienia zgodności obsługi trybu 32- i 64-bitowego. Franco Broi
pomaga podczas testowania łaty.
Burzliwe istnienie FUSE pozostaje niepewne, lecz nadal jest obecne w drzewie -mm Anrew
Mortona, dając mu tym samym co najmniej solidną bazę użytkowników. Zmiany wprowadzone
przez Miklosa wydają się być łatą typu „lekarstwo na narastający ból”, konsolidującą infrastrukturę w sposób, którego nie da się na dłuższą metę ominąć.
WWW.LINUX-MAGAZINE.PL