Download: CommunityInterview

Wywiady
SPOŁECZNOŚĆ
ROZMOWA
Z MARIUSZEM MAZUREM
LINUX MAGAZINE: Od czasu do czasu na
LKML wysyłasz informacje o nagłówkach
glibc dla jądra. Skąd pomysł przygotowania takich nagłówków i kto może z nich skorzystać?
MARIUSZ MAZUR: Pod koniec 2003 roku,
gdy byłem jeszcze Release Managerem wersji
2.0 PLD (tzw. Ac), stało się jasne, że jądro
2.6 zostanie niedługo oficjalnie wydane i trzeba się zacząć przygotowywać do zastąpienia
nim serii 2.4. Niestety, był jeden poważny
problem – podczas gdy kompilowanie programów w oparciu o nagłówki zawarte w jądrach
2.2 czy 2.4 prawie nigdy nie sprawiało żadnych problemów, to już w przypadku 2.6 nie
dało się zbudować nawet najbardziej podstawowych rzeczy. Na dodatek oficjalna polityka
deweloperów Linuksa była taka, że nie powinno się używać nagłówków jądra do kompilowania programów przestrzeni użytkownika
(tzw. userlandu), ale nic nie wskazywało na to,
żeby ktoś pracował nad alternatywnym rozwiązaniem. Ponieważ problem był na mojej
głowie, więc rozejrzałem się w sytuacji,
i stwierdziwszy, że nie mam innego wyjścia,
praktycznie po omacku zacząłem przygotowywać oczyszczoną wersję nagłówków, do użycia
w PLD. A skoro robiłem to na potrzeby własnej dystrybucji, to minimalnym nakładem
pracy mogłem swoje wysiłki udostępniać innym. No i tak to się ciągnie od ponad roku,
mimo że o samym jądrze nie mam praktycznie żadnego pojęcia (nawet nie wiem jak się
teraz kompiluje kernel; nigdy nie robię tego
ręcznie). W międzyczasie tych nagłówków zaczęły używać różne mniejsze i większe projekty, a ostatnio zgłosił się do mnie jeden z deweloperów Debiana (opiekun ich glibca) i powiedział, że po wprowadzeniu odpowiednich
poprawek prawdopodobnie użyje ich jako
podstawy następnej wersji Debiana.
LINUX MAGAZINE: Jak oceniasz tempo rozwoju PLD po rozstaniu z Tomkiem Kłoczko?
Czy – z perspektywy czasu – nie żałujesz, że
sprawy potoczyły się tak, a nie inaczej?
MARIUSZ MAZUR: Prawdę mówiąc, kloczek
funkcjonuje obecnie już tylko jako odległe
wspomnienie i wdzięczny temat do żartów.
Można powiedzieć, że straszy się nim nowych deweloperów :) A na poważnie, to pożegnanie się z nim miało swoje dobre i złe strony. Zła jest taka, że straciliśmy kogoś, kto
dysponował wręcz niesamowitymi ilościami
wolnego czasu i poświęcał go nie tylko na zagadnienia techniczne, ale także, a może
przede wszystkim, organizacyjne (a takich
osób nigdy za wiele, czego dowodem są obecne zastoje w rozwoju Ac). No i sposób rozstania pozostawia wiele do życzenia.
Jednak więcej jest plusów – deweloperzy
wreszcie mają poczucie, że są na swoim i nie
muszą walić głową w mur, gdy wymusza się
na nich rozwiązania, z którymi się nie zgadzają. Flejmy przestały być codziennością
i ludzie wreszcie nie poświęcają na nie nie
wiadomo jakich ilości czasu. I, co najważniejsze, obecnie nikt nie ma w PLD władzy
absolutnej, gdyż każdą decyzję może unieważnić powołana do tego grupa deweloperów. Przy czym, od odejścia kloczka nie było
właściwie poważniejszych spięć.
LINUX MAGAZINE: A w jaki sposób te wydarzenia wpłynęły na kwestie pozatechniczne,
takie jak osobowość prawna PLD, prawo do
korzystania z nazwy i logo itd.?
MARIUSZ MAZUR: W zasadzie nijak. Osobiście uważam, że gdybyśmy chcieli z kloczkiem
w Polsce walczyć o prawo do używania nazwy,
to byśmy przegrali (aczkolwiek nie jest to zdanie wszystkich deweloperów). Z drugiej strony
ostatnio mówiono w telewizji o tym, jak Partii
Demokratycznej ktoś zakosił nazwę sprzed nosa, bo złożył wcześniej wniosek o rejestrację
w sądzie, więc wygląda mi na to, że kto pierwszy założy stowarzyszenie PLD, ten będzie
miał oficjalnie prawo do nazwy. Jednak nie ma
mnie co cytować, bo nie jestem prawnikiem.
W praktyce co jakiś czas pojawia się ktoś bardzo chętny na formalizowanie się, ale i tak
nigdy nic z tego nie wychodzi. Już od dosyć
dawna ignoruję tego typu inicjatywy. Wśród
deweloperów nie mają specjalnie aktywnego
poparcia, a wręcz niektórzy są niechętni,
WWW.LINUX-MAGAZINE.PL
gdyż nie chcą zmieniać obecnego sposobu organizacji projektu, a formalizacja mogłaby
wymusić zmiany. Więc skoro jest ryzyko wymuszania zmian, to OK, można zakładać stowarzyszenie, ale nie może ono mieć właściwie żadnego wpływu na sam projekt (a przynajmniej na początku, zanim deweloperzy
nie zobaczą jakichś rzeczywistych korzyści
i sami nie zdecydują, że chcą się przyłączyć).
Tylko jaki jest sens powoływać formalną
strukturę, która w statucie ma zapisane, że
nic nie może w stosunku do projektu, który
teoretycznie ma reprezentować?
LINUX MAGAZINE: Mówiąc o PLD, nie da
się uciec od porównań do innych dystrybucji.
Jak przekonałbyś kogoś, kto zastanawia się
nad wyborem dystrybucji, do wyboru PLD,
a nie np. Debiana czy Gentoo?
MARIUSZ MAZUR: Nigdy nikogo do PLD nie
przekonywałem i tym razem też tego nie zrobię. Powód jest prosty – nie chcę, żeby ktoś
miał później do mnie pretensje, że naobiecywałem gruszek na wierzbie (celem istnienia
PLD nie jest zdobycie jak największej ilości
użytkowników; nie jesteśmy firmą). Jedyne, co
mogę zrobić, to opisać powody, dla których
PLD istnieje. Niestety, to jest większy temat,
a miejsca jest niewiele, więc jeśli ktoś jest zainteresowany, to napisałem już jeden tekst wyjaśniający te sprawy, a drugi jest od dłuższego
czasu „w drodze” (no cóż, leń jestem). Zakładam, że z punktu widzenia użytkowników,
PLD jest jak połączenie Debiana z Gentoo
(warunkowe budowanie programów to nie jest
wynalazek zarezerwowany dla Gentoo, mimo
że używamy RPM), a jednak głowy nie dam,
gdyż ze zbyt dużą ilością nie rozmawiałem na
ten temat.
LINUX MAGAZINE: Jakiś czas temu jako zalety PLD wymieniano Poldka, możliwość samodzielnej (tj. szybkiej) naprawy znalezionych
błędów, czy nawet szybki czas uruchamiania
systemu (owo słynne sh zamiast basha w skryptach startowych). Na co wskazałbyś dziś?
MARIUSZ MAZUR: Poldek to jest chyba tzw.
killer-app, czyli coś, co się ludziom po prostu
NUMER 16 MAJ 2005
101
SPOŁECZNOŚĆ
Wywiady
bardzo podoba, ale właściwie nie jestem w stanie powiedzieć, dlaczego. Zgaduję, że jego shellowy interfejs połączony z bardzo dużą ilością
dostępnych paczek powoduje, że użytkownicy
wreszcie nie muszą się męczyć z własnoręczną
kompilacją paczek, a i tak mają dostęp do najnowszych wersji prawie każdego oprogramowania i mogą tym wygodnie zarządzać (takie
Gentoo, tyle że bez konieczności oczekiwania
na zakończeni kompilacji). I to by było chyba
na tyle, jeśli chodzi o zwykłych użytkowników,
choć w zasadzie trzeba by ich samych o to zapytać. Osobiście mnie prawie zawsze dziwiło, że
nie-deweloperzy chcą PLD używać. Zapewne
nie doceniam ich entuzjazmu...
Łatwe poprawianie błędów i owszem, ale to
przychodzi ze znajomością pewnie dowolnej
technologii, więc w PLD, jest, ale dla deweloperów – ze względu na sposób organizacji
pracy nad dystrybucją, a nie dla użytkowników ze względu na jakieś specyficzne rozwiązania techniczne.
Na koniec mogę chyba dodać, że jeśli ktoś
chce mieć dostęp do tych organizacyjnych
ułatwień dla deweloperów, to zostanie takowym jest stosunkowo proste...
LINUX MAGAZINE: PLD korzysta zarówno
z CVS jak i SVN: dlaczego nie zrezygnowano
całkowicie z CVS na rzecz – podobno – ulepszonego następcy?
MARIUSZ MAZUR: SVN w wielu miejscach
naprawia niedociągnięcia CVS, ale nie oznacza to, że wszyscy powinni prędko migrować.
Podstawowa infrastruktura PLD (służąca do
pracy nad pakietami) jest mocno zintegrowana z naszym repozytorium CVS i choć migracja na nowe rozwiązanie pewnie wprowadziłaby kilka usprawnień, to po pierwsze wymagałaby sporego nakładu pracy, a po drugie
zmian w sposobie rozwoju dystrybucji, do którego wszyscy się już przyzwyczaili. Deweloperzy najwyraźniej są całkiem zadowoleni
z obecnego stanu rzeczy i nie ma zbytnich nacisków na tak radykalne kroki. Po prostu akurat w przypadku pracy nad pakietami, CVS
sprawdza się bardzo dobrze, przy czym praktycznie wszystkie podprojekty tworzone w ramach PLD już przeszły na używanie SVN (ja
z moimi nagłówkami dosyć niedawno też).
LINUX MAGAZINE: Czego można się spodziewać w PLD 3.0? Czy w ogóle jest sens
wydawania wersji – być może wszyscy są zadowoleni z używania takiego zestawu pakietów, jaki jest dostępny, oznaczenie go „.0” to
tylko formalizm?
MARIUSZ MAZUR: Deweloperzy muszą jeść
i przeważnie zarabiają na chleb, administrując serwerami, na których mają zainstalowa-
102
NUMER 16 MAJ 2005
ne PLD. I chcą z nimi mieć jak najmniej kłopotów, gdyż testowanie nowego oprogramowania jest fajne, ale nie na maszynie produkcyjnej. Dlatego zawsze mieliśmy problem
z zapewnieniem z jednej strony stabilności,
a z drugiej umożliwienia deweloperom swobodnego wprowadzania zmian (zresztą Linus
też ma obecnie ten kłopot z jądrami serii
2.6). Przy tworzeniu PLD 2.0 nadal są niedociągnięcia, ale mam nadzieję, że zmiany, jakie wprowadzam przy tworzeniu linii 3.0,
spełnią pokładane w nich nadzieje.
LINUX MAGAZINE: Swego czasu popularne
były wojny usenetowe dotyczące wyższości
RPM nad DPKG (i odwrotnie). Dziś temat
ten nie wzbudza zbytniego zainteresowania,
choć oba narzędzia stale się rozwijają. Jakie
cechy RPM-a są Twoim zdaniem najbardziej
przydatne?
MARIUSZ MAZUR: Znowu jest to obszerniejszy temat (o którym traktuje mój jeszcze nieukończony tekst). Zasadniczo większych różnic
w funkcjonalności pomiędzy paczkami RPM
a DEB zapewne nie ma, jednak jako deweloper
PLD powiem, że wyciąganie z debianowych pakietów potrzebnych łatek jest dosyć niewygodne. Ale to już jest pewnie kwestia organizacji
pracy nad dystrybucją, a nie ograniczeń technicznych (z Fedorą, czy komercyjnymi dystrybucjami RPM-owymi, też jest ten problem).
Rzeczywiście, ciekawe porównanie pod
względem technicznym jest z Gentoo i ich
sposobem dystrybucji oprogramowania. Zapewne mało osób zdaje sobie sprawę z tego,
że RPM oferuje warunkową kompilację pakietów i jest to coś, co zostało stworzone
przez deweloperów PLD i chyba tylko u nas
jest używane (nie trzeba się opierać na zawartości serwera FTP). Oczywiście, nigdy
nie daje to takich możliwości, jakie dają tzw.
dystrybucje źródłowe (jak Gentoo), ale naszym zdaniem rozwiązania PLD są bardzo
rozsądnym kompromisem
LINUX MAGAZINE: Co jakiś czas różne organizacje publikują rozmaite standardy, mające ujednolicić różne aspekty systemu. Jak
w PLD traktuje się Linux Standard Base,
Desktop Linux Capabilities itp.?
MARIUSZ MAZUR: Są standardy, które są dla
nas podstawą, czyli głównie Filesystem Hierarchy Standard, ale jest też mnóstwo takich,
do których praktycznie nikt nie zagląda. Nie
czytałem ani LSB, ani właściwie niczego innego i nie mam pojęcia, czy jest tam cokolwiek ciekawego. I o ile mi wiadomo, deweloperzy PLD też nie czują żadnej potrzeby, żeby tam zaglądać. Bo i po co? Te rekomendacje
(„standardy”) zaczną być rzeczywiście coś
WWW.LINUX-MAGAZINE.PL
warte, gdy będą nam do czegoś potrzebne,
czyli wtedy, gdy jakieś ważne kawałki oprogramowania będą ich wymagały. Zanim to się
nie stanie, to próby ich zastosowania w dystrybucji są właściwie sztuką dla sztuki, gdyż
nie ma z nich, póki co, żadnego pożytku. Mi
się LSB kojarzy z potwornie nieaktualnymi
wymaganiami (jakieś prehistoryczne kompilatory, biblioteki, dziwne formaty binarne,
etc.). Pomóc tu może ogłoszona jakiś czas temu modularyzacja standardu, czyli podział
na mniejsze części, których można używać
według uznania. Od jakiegoś czasu noszę się
z zamiarem dokładniejszego przyjrzenia się
LSB, może rzeczywiście jest tam coś wartego
uwagi, a PLD ma to do siebie, że jeśli postanowi zaadaptować jakieś rozwiązanie, to ma
ono właściwie zapewnione przeżycie, gdyż
w razie czego sami zajmujemy się rozwijaniem tego, co jest nam potrzebne (moje nagłówki są jednym z bardziej widocznym przykładów). Jest to taka cecha projektu, która nigdy nie przestanie mnie zadziwiać. Jeśliby
np. ktoś napisał uniwersalny system obsługi
demonów (żeby w każdej dystrybucji nie trzeba było przygotowywać własnych skryptów
startowych) i wprowadził go w PLD, to prędzej czy później stworzylibyśmy odpowiednie
poprawki do praktycznie dowolnego programu (i moglibyśmy je podsyłać autorom). To
jest niesamowity potencjał, który można wykorzystać do robienia różnych ciekawych rzeczy w skali globalnej, jeśli się wie, jak.
LINUX MAGAZINE: Utrzymywanie kilku architektur nie jest łatwe - nawet w tak dużym
projekcie jak Debian, nad którym pracują
setki osób, rozważa się możliwość znacznego
ograniczenia ich oficjalnie wspieranej liczby.
Jak to wygląda w PLD?
MARIUSZ MAZUR: Dosłownie kilka dni temu
zapadła decyzja (tzn. zaproponowałem takie
rozwiązanie i nie było sprzeciwów), żeby
w PLD 3.0 jako podstawowe traktować tylko
architektury PowerPC, AMD64 i x86 (kompilacje dla Athlona, i486, i686). Możliwe, że gdyby było zainteresowanie i maszyna, to pokusilibyśmy się też o obsługę PowerPC64. No,
i ewentualnie IA64, ale to już kwestia dyskusyjna, gdyż Intel obecnie nie ma za dużo do powiedzenia na rynku 64-bitowym. I na tym się
właściwie podstawowe architektury kończą.
Sparc, Alpha i i386 będę w 3.0 obsługiwane,
gdyż deweloperzy nadal ich używają, ale jako
tzw. AIDA – dodatkowe, niezależnie rozwijane
architektury (Additional, Independently Developed Architectures), czyli takie, których rozwój nie będzie bezpośrednio zsynchronizowany z rozwojem architektur podstawowych. ■