::gREMliN:: saJt: BSD

::gREMliN:: saJt
kot, który wie

Systemy z rodziny BSD mają swoją ustaloną renomę, a to, że są mniej popularne od Linuksa niekoniecznie musi być ich wadą. Repozytorium portów ciągle się rozrasta, myślę, że każdy znajdzie coś dla siebie. Ostatnio BSD próbuje też (wzorem Linuksa) "wcisnąć" nam się na biurka. Dobrze to czy źle? Zobaczymy ;-)

PCBSD - FreeBSD na Twoje biurko

Poniżej ciekawa rozmowa z twórcami systemów BSD stanowiąca naturalną konsekwencję wywiadu przeprowadzonego wcześniej na ten sam temat z Linusem - czytaj tu.

Jeśli Twoim zdaniem to tłumaczenie jest do bani to napisz lepsze ;-), a poważnie: jeśli widzisz jakieś błędy, daj znać.
pawel {dot} dlugosz {at} mp72 {dot} net

Artykuł ukazał się w serwisie NewsForge.

Jeśli chcesz wykorzystać to tłumaczenie (lub jego fragment) skontaktuj się z info {at} newsforge {dot} com.

Zapraszam do lektury.

Środa, 15. czerwca 2005 (09:00 AM GMT)
Rozmawiał: Jem Matzan

Ostatnio opublikowaliśmy rozmowę z Linusem Torvaldsem, podczas której pytaliśmy go o podobieństwa i różnice pomiędzy jądrem Linuksa a systemami operacyjnymi BSD. Naturalną konsekwencją tego wydarzenia było zadanie tych samych pytań Theo de Raadt'owi z OpenBSD i Christos'owi Zoulas'owi z NetBSD.

NewsForge: Jakie widzicie podobieństwa, różnice czy elementy wspólne - o ile takie istnieją - pomiędzy jądrem Linuksa a systemami BSD?

Theo de Raadt: Cóż, jak zapewne wszyscy wiecie Linux to tak naprawdę tylko jądro podczas gdy OpenBSD to kompletny system uniksowy: jądro, sterowniki do urządzeń, biblioteki, przestrzeń użytkownika, środowisko deweloperskie, dokumentacja i pełny zestaw narzędzi niezbędnych do kontynuacji rozwoju systemu. Jeśli spojrzymy na to jak na kompletne, funkcjonalne dzieło to jasno widać, że nasz model jest zupełnie inny od tego jaki prezentują dystrybucje Linuksa.

Kiedy nadchodzi moment, w którym musimy dokonać zmian (czy to ze względu na bezpieczeństwo czy z innego powodu) możemy takiej modyfikacji dokonać zmieniając przy tym cały system począwszy od przestrzeni użytkownika, przez biblioteki, na samym jądrze kończąc. Możemy zmieniać interfejsy tak jak uznamy to za stosowne. Możemy działać szybko. Czasem niektóre modyfikacje powodują uszkodzenie oryginalnych plików wykonywalnych;ale jeśli jest taka konieczność - możemy podejmować takie decyzje.

Daje nam to niesamowitą elastyczność by posuwać się szybko do przodu. Jeśli coś zostało źle zaprojektowane a nałożenie łaty wiąże się ze zmianami poza jądrem, możemy to poprawić. Modyfikujemy wszystkie niezbędne elementy układanki w odpowiednich miejscach. By dany problem rozwiązać nie musimy uciekać się do "hakowania" w miejscach do tego nie przeznaczonych.

Christos Zoulas: Istnieje sporo różnic pomiędzy tymi dwoma jądrami, które wynikają z tego jak i gdzie owe jądra zostały stworzone. Części kodu NetBSD można doszukiwać się w źródłach sprzed 30 lat, w tym czasie zaszło w nim wiele zmian. Ich negatywnym skutkiem jest nieprzejrzystość i zawiłość kodu w niektórych podsystemach (takich jak przesył sygnału [signal delivery] czy bufory sieciowe) a to z kolei opóźnia tempo rozwoju ponieważ kod jest niezrozumiały i ciężko go modyfikować. Jednocześnie inne części kodu są znacznie nowsze (takie jak podsystem VM czy API sterowników) i łatwo się z nimi pracuje. Przy tym wszystkim kod jest stabilny (większość błędów została usunięta) i w sumie wygląda na spójny i czysty. "Odpluskwione" sterowniki urządzeń z ich możliwością współdzielenia to rezultat podejścia zespołu NetBSD do tego aby system był niezależny od architektury a także szyny systemowej i modułu I/O.

Główne bolączki jądra NetBSD to moim zdaniem:

kwestia systemów wieloprocesorowych: mimo, że NetBSD wspiera SMP i wielowątkowość to wątki jednego procesu nie mogą wykorzystywać więcej niż jednego procesora,
tylko jeden proces może być przetwarzany przez jądro w danej jednostce czasu,
brak obsługi systemu plików z księgowaniem i brak wsparcia dla bardzo dużych systemów plików,
dostępność sterowników tylko do typowych urządzeń

Kod jądra Linuksa jest znacznie młodszy i podlega nieustannym przemianom. Miłym tego efektem ubocznym jest jego czytelność i przejrzystość (na poziomie warstw systemowych takich jak VM i FS), jednak stabilność jest pod znakiem zapytania. Podczas gdy jądra z gałęzi 2.4.x pięły się systematycznie w kierunku utrzymania stabilności to droga rozwoju serii 2.6.x jest usłana wieloma dziurami.

Główne bolączki jądra Linuksa to moim zdaniem:

OOM killer (wycieki z pamięci?),
stabilność systemu plików: Linux obsługuje ich zdecydowanie za dużo, a każda dystrybucja zdaje się promować swojego własnego faworyta (głównie ze względów "politycznych", nie technicznych). Większość tych FS obsługuje księgowanie i ma wsparcie dla dużych plików. Niestety, niektóre z nich nie są bezpieczne, ale brakuje testów z prawdziwego zdarzenia dostępnych dla szerokiej publiczności co mogłoby ułatwić jej wybór,
stabilność sterowników dla typowych urządzeń.

Jądro NetBSD ma te same API niezależnie od platformy. W NetBSD wywołanie systemowe #n jest jednakowe na każdej platformie i przyjmuje te same argumenty. Jądro Linuksa stara się naśladować rdzenny system operacyjny na każdej z platform, więc dla każdej z nich wywołania są inne. To powoduje konieczność używania plików nagłówkowych właściwych dla danej platformy sprzętowej, a programy skompilowane i działające na i386 mogą dać się skompilować i używać na SPARC64.

Ważne jest aby pamiętać, że nasza rozmowa skupia się wokół jąder systemów. NetBSD jest kompletnym systemem operacyjnym, którego dystrybucje są spójne dla wszystkich obsługiwanych platform, podczas gdy różne dystrybucje Linuksa działające na tej samej platformie nie są ze sobą zgodne.

NF: Systemy z rodziny BSD ciągle są uznawane za bardziej "poprawne technicznie" niż jądro Linuksa. Linus Torvalds powiedział kiedyś, że to nie jest kwestia technologii. Czy sądzicie, że projekty BSD, nad którymi pracujecie są lepsze technicznie w niektórych (lub wszystkich) zastosowaniach od ogólnie pojętego Linuksa?

Theo de Raadt: Nie wiem. Nigdy nie używałem Linuksa.

Christos Zoulas: Kod NetBSD jest czystszy i lepiej udokumentowany. Wszystko ma swoje podręczniki man łącznie z funkcjami jądra. Natomiast Linux polega głównie na zbiorach FAQ, HOWTO i rozsianej dokumentacji dostępnej w różnych formatach. Z drugiej strony NetBSD brakuje funkcjonalności, którą ma Linux jak na przykład obsługi trybu suspend/resume dla ACPI i sterowników dla akceleratorów graficznych.

Jeśli chodzi o samą integrację to NetBSD jest łatwo dostępne z repozytorium CVS co pozwala Ci samemu zbudować kompletny system "pod klucz", Linux inaczej, tu tryb instalacji systemu polega na ściągnięciu binarek przygotowanych wcześniej przez jakąś przypadkową osobę. Możemy też przeprowadzić kompilację skrośną dowolnej wersji NetBSD z naszego systemu pracującego na innej platformie, a nawet zupełnie dowolny system jak Linux czy Windows. To pozwala nam budować binarki przeznaczone dla wolniejszych platform a całość zajmuje parę godzin a nie kilka dni.

Wreszcie dystrybucje Linuksa to cały zbiór zbudowanych i zainstalowanych programów, natomiast NetBSD używa pkgsrc a dodatkowe paczki budowane są w miarę potrzeb. Z tego powodu dystrybucje Linuksa wydają się nadmiernie rozdęte, ale przy obecnych wielkościach dysków nie jest to duży problem. Dodatkowe pobranie i przebudowa potrzebnych paczek to dla zwykłego użytkownika niepotrzebne obciążenie.

Twierdzę, że dla programisty system NetBSD jest lepszy, ale dla użytkownika końcowego, który potrzebuje wszystkich tych różnych "wodotrysków" to Linux będzie właściwym wyborem.

Myślę, że oba projekty, zwłaszcza Linux, powinny usprawnić testowanie i system kontroli jakości. Jak dotąd każda z wersji 2.6.x miała jakieś błędy, które były usuwane w kolejnych edycjach, ale jednocześnie pojawiały się nowe. Jak na razie NetBSD nie miało tego typu problemów być może dlatego, że nasz kod nie jest tak intensywnie przebudowywany. Podczas gdy trwają wzmożone prace nad dodaniem testów regresyjnych do Linuksa, NetBSD posiada je już od jakiegoś czasu i ciągle dodajemy nowe. Mając to na uwadze obydwa projekty powinny bardziej przykładać się do testowania swojego kodu pod kątem stabilności. Przeprowadzanie testów wydajności I/O i systemów plików oraz dodanie dużej liczby testów regresyjnych niesamowicie pomogłoby w rozwijaniu systemu.

NF: Jeśli przyjmiemy, że systemy BSD były lepsze pięć lat temu czy to oznacza, że od tamtej pory poziom został wyrównany?

Christos Zoulas: Linux bardzo nadgonił, zwłaszcza w linii 2.6. W serii 2.4 było czymś zwyczajnym, że jądro systemu miało 12 kopii jednego sterownika urządzenia - po jednym dla każdej wspieranej kombinacji architektury i szyny systemowej. Teraz większość sterowników ma jedną swoją kopię. Kwestia I/O w gałęzi 2.4 została mocno zaadresowana w serii 2.6. Głównym powodem umocnienia pozycji Linuksa na rynku jest wsparcie sprzedawców na poziomie podstawowej funkcjonalności jądra (IBM), systemu plików (XFS od SGI) i sterowników firm trzecich.

Scheduler w NetBSD 2.0 oparty na aktywowanych wątkach wygląda bardzo obiecująco a osiągnięcie przez niego doskonałej wydajności jest kwestią rozwiązania problemu obsługi systemów wieloprocesorowych. Trudno powiedzieć, które jądro jest lepsze. Myślę, że odpowiedź zależy od tego jakiej konkretnie funkcjonalności poszukujemy. Sądzę, że najlepszym sposobem oceny jest przeprowadzenie wszechstronnych testów wydajnościowych i zadaniowych.

NF: Czy współdzielenie kodu pomiędzy systemami Free/Open/NetBSD i Linuksem jest czymś powszechnym? A jeśli tak to czy działa to w obie strony?

Theo de Raadt: Z tego co wiem nic takiego w ogóle się nie dzieje. Nasz kod jest zupełnie wolno dostępny dla każdego i można dowolnie nim manipulować (pod warunkiem, że notka o prawach autorskich pozostanie na swoim miejscu - co ma tak naprawdę znaczenie tylko w komercyjnych zastosowaniach), mimo to ludzie od Linuksa nie używają naszego kodu.

Christos Zoulas: Myślę, że to działa w obie strony, zwłaszcza wszędzie tam gdzie tworzony jest port Linuksa na architekturę, którą obsługuje już NetBSD lub odwrotnie. Ze względu na rozmiary obu projektów oraz dużą liczbę sterowników dla Linuksa twierdzę, że w tej sytuacji to deweloperzy NetBSD częściej odwołują sie do linuksowego kodu sterowników urządzeń w poszukiwaniu pewnych anomalii czy z powodu braku odpowiedniej dokumentacji. To konieczne, bo producenci sprzętu nie zawsze udostępniają stosowną dokumentację do danego produktu (z pełnym wykazem błędów), w takiej sytuacji stworzenie działającego sterownika następuje metodami prób i błędów, inżynierii wstecznej lub uzyskaniu odpowiedniej informacji od sprzedawcy urządzenia. Sytuacja staje się nawet jeszcze gorsza, bo wszyscy z kręgu open source (z wyjątkiem OpenBSD) tolerują produkty bez dokumentacji, które działają dzięki dostarczonym przez sprzedawcę - czasem tylko w wersji binarnej - sterownikom. Nie sądzę, aby nieprzejednana kampania jaką prowadzi tu OpenBSD była dobrym wyjściem aczkolwiek zdaje się przynosić jakieś rezultaty. Wierzę, że producenci sprzętu mogą zostać przekonani, że publikacja odpowiedniej dokumentacji jest dla nich korzystna, ale żeby to się udało cały ruch open source powinien działać wspólnie. Rękami i nogami powinniśmy głosować przeciw opornym producentom i wykluczać nasze wsparcie dla nich z naszych systemów.

NF: Czy istnieją obecnie jakieś części Linuksa, które widzielibyście w jądrze Free/Open/NetBSD?

Theo de Raadt: Nie. Nasze źródła są kompletnie otwarte; ktokolwiek może ich dowolnie używać tak długo jak w kodzie znajduje się stosowna notka. Z tego powodu nie możemy akceptować komercyjnego kodu w naszym systemie. Z tego samego powodu odrzucamy też kod na licencji GPL, ponieważ jego restrykcje wykraczają poza kwestię "pozostawienia informacji o prawach autorskich".

Christos Zoulas: Ja widziałbym niektóre rozwiązania z Linuksa (symetryczna wieloprocesorowość, obsługa czasu rzeczywistego, więcej sterowników) w jądrze NetBSD, ale tak naprawdę nie możemy zaadoptować kodu Linuksa, bo to bardzo trudne technicznie. Przepisanie kodu od samego początku zajęłoby prawdopodobnie mniej czasu niż skompensowanie różnic pomiędzy API obu jąder. Nawet jeśli ten problem by odpadł nie moglibyśmy użyć takiego kodu ponieważ chcemy utrzymać nasz system wolny od licencji GPL.

Od redakcji: Poprosiliśmy również zespół FreeBSD o udział w tej rozmowie, ale do czasu publikacji nie otrzymaliśmy od nich żadnej odpowiedzi.

http://os.newsforge.com/article.pl?sid=05/06/09/2132233

Co o tym wszystkim sądzi Linus Torvalds znajdziesz tu.

Znawcy BSD rozmawiają o Linuksie