Wywiad z Pawłem Dziepakiem – deweloperem Haiku

Przemysław Pintal z projektu Haiku-OS.pl przeprowadził ciekawy wywiad z Pawłem Dziepakiem, jednym z programistów systemu Haiku. Jest to 22 letni student z Opola, posiadający bogatą wiedzę i zajmujący się architekturami jąder systemowych.

Wywiad z Pawłem Dziepakiem został przeprowadzony podczas prywatnej rozmowy, na polskim kanale IRC Haiku (#haiku-pl na Freenode) i trwał łącznie dwie noce, tj. 28 i 29 kwietnia 2014 roku. Paweł posługuje się w internecie nickiem pdziepak, natomiast Przemysław Pintal, znany jest jako Premislaus. Projekt Haiku posiada wielu wspaniałych ludzi, m.in. Ingo, Axel, Stephan i w przyszłości postaramy się o wywiady również z nimi. Poruszone zostały tematy Projektu i Społeczności Haiku, a także wolnego oprogramowania.

Premislaus: Cześć Paweł! Zacznę standardowym pytaniem: napisz krótko o sobie, kim jesteś, skąd jesteś, ile masz lat, co i gdzie studiujesz?

pdziepak: Cześć. Jestem Paweł Dziepak, mam 22 lata, urodziłem się w Opolu, obecnie studiuję informatykę na Uniwersytecie Wrocławskim, co spowodowało moją przeprowadzkę do Wrocławia, jakieś cztery lata temu.

Premislaus: Jak dowiedziałeś się o Projekcie Haiku? I jakie były wtedy Twoje pierwsze myśli, wrażenia?

pdziepak: Dokładnie pierwszego spotkania z Haiku nie pamiętam, ale niewątpliwie było to podczas przeglądania Wikipedii, w poszukiwaniu alternatywnych systemów operacyjnych. Jakiś czas później szukałem jakiegoś projektu open source do którego mógłbym dołączyć, ale szczerze mówiąc odstraszył mnie fakt, że jednym z głównych celów projektu jest utrzymanie kompatybilności ze starożytnym BeOS-em. Dużo później zdecydowałem się na udział w GSoC, najlepiej w jakimś projekcie gdzie mógłbym pracować nad czymś w miarę blisko związanym z kernelem. Wtedy Haiku pojawiło się ponownie, z propozycją zaimplementowania klienta NFSv4, co wyglądało całkiem ciekawie. Był to wtedy właściwie (zaryzykuję stwierdzenie) jedyny duży kernel napisany w C++, a okazało się, że GCC2 i cała otoczka związana z kompatybilnością z BeOS-em, nie jest aż taka straszna. Interfejs użytkownika też mi się spodobał, lubię prostotę więc fakt, że system wygląda jak z końca lat 90, to dla mnie raczej zaleta.

Premislaus: Dlaczego? Czy słyszałeś wcześniej o BeOS-ie? Używałeś go może? BeOS miał trochę ciekawych rozwiązań, np. atrybuty w systemie plików, przypominało to bazę danych, typy MIME do obsługi plików, był nastawiony na wielowątkowość i soft real time. W sumie to wszystko co ma teraz Haiku.

pdziepak: Muszę przyznać, że głównym motywem było bardziej NFSv4 niż Haiku. Nie zastanawiałem się wtedy czy zostanę z projektem na dłużej czy nie. Moja wiedza na temat BeOS-a ograniczała się do tego, że byłem świadom, że coś takiego kiedyś istniało i na tym właściwie koniec. Co do ciekawych rozwiązań BeOS-a, atrybuty w systemie plików są niezwykle kłopotliwe, gdy próbuje się je zaimplementować w kliencie NFSv4, więc niestety nie kojarzą mi się zbyt dobrze. Dopiero jakiś czas temu dzięki Stephanowi i po pewnych sugestiach Ingo, opracowałem mniej więcej jak mogłoby to działać w połączeniu z NFSv4, ale niestety nie miałem jeszcze czasu zaimplementować tego w całości.

Premislaus: Mógłbyś nam coś więcej o tym opowiedzieć? Dlaczego atrybuty w Haiku są takie kłopotliwe? Pamiętam, że pisałeś kiedyś na polskim kanale IRC Haiku, że inne systemy o to nie dbają i dopiero jakaś kolejna wersja NFSv4 ma to w pełni wspierać?

pdziepak: Niestety, problem polega właśnie na tym, że jedynie BeOS i Haiku implementują atrybuty plików w tak rozbudowany sposób. W rezultacie, wszelkie protokoły pomijają ten aspekt co później bardzo utrudnia poprawną implementację. Jeśli chodzi o NFSv4 to rzeczywiście wprowadza on coś takiego jak „named attributes”, ale wiążą się z tym dwa problemy. Po pierwsze to wciąż nie jest to czego potrzebujemy, bo „named attributes” w odróżnieniu od atrybutów plików w BFS nie są typowane. Drugi problem jest jeszcze bardziej poważny, wsparcie „named attributes” jest opcjonalne i linuksowy serwer NFSv4 (który niewątpliwie jest najbardziej popularny), nie ma tego zaimplementowanego.

Premislaus: Co stoi za atrybutami, że użytkownicy Haiku tak bardzo chcą mieć te atrybuty? Mi się podoba, że możemy np. własną wideotekę posegregować tak jak chcemy i wyszukiwać filmy np. według ulubionego scenarzysty. Możemy łatwo tworzyć informacje o naszych kontaktach w programie People i wszelkie dane są przechowywane jako atrybuty pustych plików. A power user ma możliwość pisania sobie formuł służących do wyszukiwania. Może to być przydatne, gdy posiadamy kilkadziesiąt tysięcy mejli. Jakie jest Twoje zdanie? Czy w innych systemach operacyjnych są podobne rozwiązania? Czy może istnieje coś lepszego?

pdziepak: Atrybuty są w istocie bardzo wygodnym i eleganckim rozwiązaniem, ale żeby to działało jak należy to wszystko co zajmuje się plikami musi je wspierać: system plików, formaty archiwizowania danych (tar, zip, itp.), protokoły transmisji danych (HTTP, FTP, NFS, itp.). Jeśli coś po drodze gubi nam atrybuty to staje się to uciążliwe. W niektórych przypadkach jednak trudno sobie wyobrazić bardziej naturalne rozwiązanie niż atrybuty plików i ta część świata, która nie ma czegoś takiego zaimplementowanego w swoim systemie plików, musiała wymyślić rozwiązanie mniej eleganckie, ale za to lepiej działające w praktyce, czyli umieszczenie takich dodatkowych informacji w pliku. Tak działają np. tagi w plikach z muzyką i z obrazkami (ID3 i Exif).

Premislaus: To prawda, nieraz mi Windows nie chciał rozpoznać automatycznie plików jakie stworzyłem pod Haiku (głównie tekst i grafiki). Na szczęście archiwa zip przechowują atrybuty. Co do tagów w plikach mp3, to pod Haiku mamy aplikację ArmyKnife i paroma kliknięciami możemy automatycznie przerobić tagi na atrybuty. Inną rzeczą jaką lubię w atrybutach, jest wyświetlanie adresu WWW skąd pobraliśmy dany plik (jeśli oczywiście tak ustawimy). Chciałbym Cię teraz zapytać jakie inne technologie zaimplementowałeś w Haiku? Co udoskonaliłeś? Jaki jest Twój obszar zainteresowania w procesie rozwijania Haiku?

pdziepak: Mój obszar zainteresowania to szeroko rozumiany kernel development i okolice. Wiosną 2013 zaimplementowałem ASLR i DEP, co spowodowało drobne zamieszanie z racji „uaktywnienia” bugów, które dotychczas były ukryte ale myślę, że ogólnie wyszło to Haiku na dobre. Później dłubałem trochę przy RTM (Restricted Transactional Memory), nowym rozszerzeniu wprowadzonym w Haswellach, ale jeszcze daleka droga zanim będzie nadawał się ten kod do użytku. Od października do połowy stycznia byłem zatrudniony przez Haiku, Inc. do pracy nad planistą i lepszym przystosowaniem Haiku do pracy na systemach z więcej niż jednym logicznym procesorem. Między innymi pozbyłem się limitu 8 procesorów, który był dość mocno zakorzeniony w ABI odziedziczonym po BeOS. Zmiana API i wprowadzenie nowych elementów do ABI, również spowodowały trochę zamieszania, ale było to nieuniknione.

Premislaus: Czym się charakteryzuje planista Twojego autorstwa? Jakie są różnice względem poprzedniego planisty? Jak wypada on na tle innych systemów operacyjnych? Jaka jest jego główna koncepcja?

pdziepak: Przede wszystkim nowy planista ma osobną kolejkę wątków dla każdego rdzenia, zamiast jednej globalnej tak jak to było wcześniej. Poprawia to wykorzystanie cache i sprawia, że procesory mniej sobie nawzajem przeszkadzają, ale do sprawnego działania wymaga dobrego algorytmu balansowania obciążenia. Zdecydowałem się to zrealizować poprzez szacowanie ile czasu procesora dany wątek wykorzystałby, gdyby był jedynym wątkiem w systemie. Na podstawie tej informacji planista decyduje jak przydzielać rdzenie wątkom i kiedy migrować wątki na inne rdzenie. Na te decyzje ma także wpływ tryb w którym działa planista; jeśli najważniejsza jest wydajność systemu, to chcemy wykorzystać wszystkie dostępne logiczne procesory, jeśli zależy nam na ograniczeniu zużycia energii, lepiej będzie jeśli ograniczymy ilość aktywnych rdzeni, o ile tylko jest to możliwe. Jeśli chodzi o przydzielanie procesora wątkom na danym rdzeniu, to rozwiązanie jest dość klasyczne, wykorzystana jest kolejka priorytetowa działająca w czasie stałym. Odpowiednie heurystyki dbają o to, aby obniżyć priorytet wątkom które wykorzystują zbyt dużo czasu procesora.

Premislaus: Czy mógłbyś nam opowiedzieć jak wyglądała Twoja współpraca w ramach GSoC i na kontrakcie? Czy dobrze się układało Tobie z Haiku, Inc. i resztą deweloperów? Czy zdarzyły się jakieś przykre albo zabawne sytuacje?

pdziepak: Zarówno podczas GSoC jak i kontraktu nie było innego dewelopera który zajmował się tym samym, więc współpraca ograniczała się do dyskusji odnośnie konkretnych zmian, lub w przypadku API, propozycji zmian. Generalnie atmosfera pracy była dobra i nie mogę na nic narzekać.

Premislaus: Teraz padnie dla mnie arcytrudne pytanie, bo wiele energii, czasu i nerwów włożyłem w promocję i testowanie Haiku. Nie chcę nic zepsuć ale uważam, że naczelną zasadą Open Source jest transparentność. Nie chcę ukrywać wad, bo nie jestem działem marketingu jakiejś korporacji – „Jest świetnie!”. Jak oceniasz proces decyzyjny, komunikację i zarządzanie w Projekcie Haiku? Nie jest tajemnicą, że wszystko dzieje się powoli; dodawanie patchy, podejmowanie decyzji, mamy wiele in-progress na bugliście które mają kilka lat. Zgłosiliśmy błąd, że aplikacja HaikuDepot nie tłumaczy się. Wystarczy, że administrator zmieni jedną ścieżkę – trwa to już dwa tygodnie! Ogólnie deweloperzy Haiku cieszą się zaufaniem społeczności, widać to po tym, że z roku na rok mamy coraz więcej pieniędzy i wykonujemy milowe kroki w kierunku wersji R1 (planista, menedżer pakietów, HTML5, etc.). Ale czy dałoby się lepiej zarządzać obecnymi zasobami? Haiku nie posiada stałego i bogatego sponsora, poświęcamy mu swój wolny czas i oszczędności, ale nieraz mam wrażenie, że wszystko dzieje się siłą inercji. Za każdym razem jak widzę, że ktoś komuś pisze na IRC-u: „patches welcome”, „!patchwanted”, „sure, our workflow could be improved”, to mam ochotę wyjść na ulicę z karabinem i zacząć strzelać do ludzi. Dlatego rozpocząłem dyskusję na liście mailingowej, w której chciałem zasugerować potrzebę stworzenia testów jednostkowych, podczas jakiegoś kontraktu i zmianę podejścia do dodawania patchy. Jak Ty to wszystko widzisz? Czy próg wejścia dla nowego dewelopera nie jest zbyt wysoki?

pdziepak: To, że wszystko dzieje się powoli można bardzo łatwo wytłumaczyć – zdecydowanie zbyt mało deweloperów jest zatrudnianych na pełny etat. Trzeba sobie uświadomić, że Haiku to kompletny system operacyjny, a to co w przypadku konkurencyjnych rozwiązań jest samodzielnym i dużym projektem, u nas jest tylko częścią Haiku. Jakby nie patrzeć mamy „własnego Linuksa”, „własną glibc”, „własne Qt”, „własne KDE” i wiele innych. Jeśli chodzi o nasz workflow to miejmy nadzieję, że dyskusja zapoczątkowana przez Ciebie doprowadzi do czegoś dobrego, choć mam wrażenie, że inaczej rozumiemy „coś dobrego”. Przede wszystkim nie sądzę, że próg dla nowego dewelopera jest zbyt wysoki, nie ma sensu dawać dostępu do repozytorium komuś, kogo pracę trzeba będzie ciągle poprawiać. U nas raczej problemem jest w ogóle mała ilość chętnych do współpracy, a nie potencjalni deweloperzy których w jakiś sposób odstraszyliśmy. Uważam także, że dobrze by było gdyby dodawanie zmian do Haiku „utrudnić”, szczególnie w przypadku ludzi którzy mają commit access, nikt nie jest nieomylny i wymóg weryfikacji każdego patcha przez innego dewelopera z pewnością poprawi jakość kodu. Niestety tutaj ponownie pojawia się problem czasu jaki deweloperzy mogą poświecić projektowi. Jeśli przeglądanie i weryfikowanie patchy nie będzie działało dostatecznie sprawnie, taki workflow się nie sprawdzi i przyniesie więcej szkody niż pożytku.

Premislaus: A co z zasadą „Worse is better„? Haiku uskutecznia „The MIT Approach„. Osobiście uważam, że to drugie w teorii jest o wiele lepsze. Czy ceną takiego podejścia jest powolność i po prostu mniej wszystkiego? Rodzina systemów BSD na pierwszy rzut oka wypada gorzej na tle dystrybucji Linuksa.

pdziepak: Decyzje należy podejmować indywidualnie, po analizie danego problemu. Trzymanie się ślepo jakiejkolwiek zasady (łącznie z tą), do niczego dobrego nie doprowadzi. Oczywiście, zwykle proste rozwiązania są lepsze, zarówno jeśli chodzi o wydajność implementacji, jak i „elegancję” interfejsu. Problem pojawia się jednak, gdy po jakimś czasie takie proste rozwiązanie przestaje wystarczać, a poprawienie tego nie jest trywialne ze względu na konieczność zachowania kompatybilności.

Premislaus: O co tak na prawdę chodzi z tym całym GCC2? Jak wielką kulą u nogi Haiku jest kompatybilność binarna z BeOS-em? Nie trafia do mnie argument, że pozwala to np. sprawdzać błędy i zachowanie systemu i aplikacji, bo jest punkt odniesienia w postaci BeOS-a. Normalnie coś takiego załatwiają testy jednostkowe. Ja wiem, że takie jest główne założenie projektowe dla wersji R1, ale zadecydowano o tym 12 lat temu. Przez ten czas wiele się zmieniło. Wydaje się, że już dziś nie ma takiej potrzeby, by być zgodnym z BeOS-em.

pdziepak: GCC2 głównie, w mniejszym lub większym stopniu, przeszkadza, ale jednym z głównych celów projektu jest zachowanie kompatybilności ABI z BeOS-em, a zmiana głównych celów projektu to nie jest taka prosta rzecz. Z jednej strony powstrzymują one projekt przed chaosem (choć nie jestem pewien jak GCC2 w tym pomaga), z drugiej strony mogłoby się okazać, że gdzieś po drodze zgubił się sens niektórych z podjętych przedsięwzięć. Projekt GCC nie stoi w miejscu i rozwija się na wielu różnych płaszczyznach, nie tylko na tej która jest najbardziej irytująca, czyli brak pełnego wsparcia dla C++03, nie wspominając nawet o C++11. GCC4 ma dużo więcej dużo lepszych optymalizacji, których programista często wręcz oczekuje od kompilatora. Dodatkowo, GCC4 potrafi generować kod służący lepiej nowszym procesorom. Oczywiście, buildy Haiku z założenia muszą się uruchamiać na Pentium Pro (i proszę nie pytać o uzasadnienie), ale GCC4 potrafi generować kod który nie używa nowych instrukcji i uruchamia się na starych CPU, ale lepiej wykorzystuje nowsze mikroarchitektury.

Premislaus: Jakie masz najbliższe plany związane z rozwojem Haiku?

pdziepak: Mogę powiedzieć jakie mam pomysły, bo co z tego wyjdzie to zależy ile czasu będę mógł poświęcić dla Haiku. Przede wszystkim dobrze by było dokończyć zaczęte już przeze mnie dwie rzeczy, czyli wsparcie dla atrybutów plików w kliencie NFSv4 i wykorzystanie rozszerzeń TSX Intela (w tym RTM o którym wspomniałem wcześniej). Myślałem także nad sterownikami z rodziny VirtIO, które poprawiają działanie systemu gdy działa pod KVM. Ogólna infrastruktura związana z VirtIO jest już w Haiku od jakiegoś czasu. Mamy także trochę kodu sterownika karty sieciowej i dokończenie tego raczej nie wymagałoby zbyt dużego nakładu pracy. Ciekawe jest także urządzenie virtio-balloon, które pozwala na wymianę pamięci między systemem który działa w maszynie wirtualnej, a tym który jest hostem. Nie sprawdzałem jednak jak wiele pracy wymagałoby zaimplementowanie czegoś takiego.

Premislaus: Mógłbyś wymienić i pokrótce opisać jakie są według Ciebie zalety Haiku?

pdziepak: Przede wszystkim interfejs graficzny i ogólnie system jest przyjazny użytkownikowi. Haiku nie wymaga wiele od sprzętu aby być responsywne, a to w dużej mierze ma wpływ na to jakie wrażenie po sobie zostawia. Nie ma też problemów na które napotykają projekty które nie mają jasno zdefiniowanych celów i chcą być dobre w każdym zastosowaniu, co zwykle średnio wychodzi.

Premislaus: A jakie są wady?

pdziepak: Wyniki benchmarków, porównanie czasów kompilacji i innych zadań wymagających od systemu dużej wydajności, wyglądają bardzo kiepsko. Przed kontraktem Adriena WebPositive było obrazem nędzy i rozpaczy, co z pewnością nie zachęcało potencjalnych użytkowników, ale tutaj mamy spory postęp i już coraz mniej jest to problemem.

Premislaus: Czym właściwie Haiku różni się od Linuksa, systemów BSD, Windowsa i OS X okiem programisty?

pdziepak: Haiku implementuje POSIX, więc programiści uniksowi nie będą czuć się tu zbyt obco. Mamy porty wielu języków bardziej wysokopoziomowych takich jak Perl, Ruby czy Python, więc tu też sporych różnic nie będzie. Jeżeli jednak chodzi o GUI i wysokopoziomowe API w C++ (czyli Kity), to tutaj jest to alternatywne rozwiązanie do np. Qt i wymaga poświęcenia trochę czasu na naukę. Jeśli chodzi o programowanie związane z kernelem, to w odróżnieniu od wielu konkurencyjnych rozwiązań, mamy tu mieszankę C i C++, niestety ze względu na konieczność możliwości skompilowania kernela za pomocą GCC2, to nie możemy korzystać w pełni z C++03 i C++11, oczywiście to ograniczenie nie dotyczy aplikacji działających w trybie użytkownika.

Premislaus: Jakie są Twoim zdaniem główne wąskie gardła w jądrze Haiku?

pdziepak: Nowoczesne kernele wykorzystują różne, mniej lub bardziej zaawansowane techniki mające na celu poprawienie wydajności, szczególnie w przypadku gdy mamy do czynienia z więcej niż jednym logicznym procesorem (czyli obecnie to już prawie zawsze). RCU, sprytne przydzielanie obiektów konkretnemu CPU, muteksy chroniące niewielkie obiekty, algorytmy lock-free i wait-free. Kernel Haiku natomiast robi bardzo niewiele w tej kwestii, przez co jego skalowalność jest wysoce niezadowalająca.

Premislaus: Czy zastąpiłbyś jądro Haiku jakimś innym gdybyś mógł? Czy raczej stawiasz na systematyczny rozwój obecnego?

pdziepak: Rzeczywiście zastanawiałem się czy nie byłoby lepiej gdyby Haiku wykorzystywało Linuksa. Ponad 10 lat temu decyzja o napisaniu praktycznie od zera własnego kernela, prawdopodobnie była słuszna, ale sporo się zmieniło od tego czasu. Oczywiście wykorzystanie „obcego” kernela w Haiku wymagałoby sporo pracy, ale utrzymywanie własnego kernela na poziomie choć trochę zbliżonym do konkurencji, wymaga jej jeszcze więcej.

Premislaus: Jak oceniasz stan kodu źródłowego Haiku? Czy coś wymaga gruntownego przepisania?

Pdziepak: Mogę się wypowiadać tylko o kernelu. Tak jak wspomniałem wcześniej, potrzebujemy więcej sprytnych technik pozwalających polepszyć skalowalność. To z kolei wymaga większych lub mniejszych zmian (raczej to pierwsze), w większości podsystemów kernela. Co do przepisywania od zera, to raczej nie ma takiej potrzeby, lepsza będzie ewolucja pod warunkiem, że (jak na ewolucję) nagła i szybka.

Premislaus: Jaka jest Twoim zdaniem długookresowa perspektywa dla Haiku?

pdziepak: Z menedżerem pakietów i usprawnieniami w WebPositive, system o wiele bardziej nadaje się do codziennego użytku. Mam nadzieję, że niedługo uda nam się wydać coś bardziej oficjalnego niż nocne buildy. Względem długoterminowego rozwoju, to dużo zależy od tego jak długo Adrien będzie mógł pracować nad WebPositive i czy pojawi się możliwość zrealizowania innych kontraktów. Haiku ma grono wiernych fanów, ale bez zauważalnych postępów w pracach, będzie ich raczej ubywać niż przybywać.

Premislaus: Dlaczego warto wspierać Haiku?

pdziepak: Ja jestem techniczny, dział marketingu to piętro wyżej.

Premislaus: OK, ale dlaczego Ty wspierasz?

pdziepak: Początkowo była to w sporej mierze chęć poznania systemu trochę innego od standardów w postaci Windowsa, *BSD czy różnych dystrybucji Linuksa. Teraz już Haiku nie jest z mojego punktu widzenia w żaden sposób „inne” i głównym powodem stał się fakt, że jest sporo rzeczy do zrobienia w różnych dziedzinach. W zależności od tego czym się w danym momencie zainteresuję, jest (niestety) spora szansa, że w Haiku tego nie ma albo można to w znaczącym stopniu ulepszyć. W ten sposób zacząłem pracować nad ASLR i DEP oraz RTM. To jest także przyczyna dla której rozważam zaimplementowanie niektórych z brakujących sterowników VirtIO, o czym wspomniałem wcześniej.

Premislaus: Czy masz zainstalowane Haiku na jakimś komputerze i czy korzystasz z niego?

pdziepak: Tak. Mam Haiku zainstalowane na starym Eee PC. Nie licząc Windows XP, Haiku to jedyny system którego GUI działa na nim płynnie.

Premislaus: Jaki jest Twój główny system operacyjny, narzędzia i sprzęt, które są wykorzystywane przede wszystkim do rozwoju Haiku?

pdziepak: Mam „laptopa stacjonarnego” z podpiętym monitorem, klawiaturą, głośnikami, ethernetem, itd. na którym jest Fedora (ze względu na sentyment do Red Hat-ów). Oprócz tego posiadam jeden komputer stacjonarny, na którym buduję Haiku, a także inne projekty nad którymi pracuję. Mam też na nim postawionego OpenGroka i buildbota, którego używam do weryfikowania czy moje commity niczego nie psują, zanim trafią do głównego repozytorium. Obecnie zainstalowany jest na tym komputerze Debian Jessie. Jeśli chodzi o konkretne programy, to od bardzo długiego czasu gedit jest głównym narzędziem do programowania, żadnego IDE nie używam. Do tego oczywiście git, tutaj także dosyć ascetycznie, nie korzystam raczej z żadnych „pomagaczy” z GUI za wyjątkiem gitk.

Premislaus: Czego Tobie brakuje w Haiku? Jakich ważnych dla Ciebie aplikacji nie ma?

pdziepak: Przede wszystkim sprzętowego wsparcia dla wirtualizacji. Brak Wiresharka i OpenCL także jest problematyczny.

Premislaus: Jak wypada menedżer pakietów w Haiku na tle dystrybucji Linuksa?

pdziepak: Jest bardzo różny od alternatywnych rozwiązań. Zdecydowanie nie jest prosty, ale mimo wszystko uważam to rozwiązanie za eleganckie. Dzięki temu w jaki sposób został zaprojektowany, pakiety można by np. trzymać dostępne przez sieć na jakimś NAS-ie i różne instalacje Haiku, mogą mieć do nich dostęp bez wchodzenia sobie w drogę. Oszczędzałoby to zarówno miejsce na dysku, jak i czas związany z aktualizacją oprogramowania.

Premislaus: Czy poleciłbyś nadchodzące wydanie Haiku mniej wymagającemu użytkownikowi, który przede wszystkim przegląda internet i chce na starszym sprzęcie zastąpić niewspieranego już Windowsa XP? Czy raczej poleciłbyś jakąś lekką dystrybucję Linuksa?

pdziepak: Dzięki ostatnim postępom w pracach nad WebPositive myślę, że powoli można spokojnie zacząć polecać Haiku ludziom, którzy za szczyt osiągnięć w dziedzinie systemów operacyjnych uważają Windowsa XP. Niestety, wciąż są problemy ze sterownikami ale to zależy głównie od szczęścia.

Premislaus: Czy myślisz, że praca przy niszowym projekcie open source pozwoli osiągnąć Tobie sukces zawodowy?

pdziepak: Mam taką nadzieję. Myślę, że liczy się to co udało mi się zrobić i to czego się przez ten czas nauczyłem, natomiast to jak bardzo projekt jest popularny, ma raczej drugorzędne znaczenie. Każdy projekt ma swoje własne zasady współpracy między deweloperami i niewątpliwie warto doświadczyć jak najwięcej różnych modeli pracy, aby w przyszłości móc wyciągnąć z tego wnioski i wykorzystać zalety różnych rozwiązań.

Premislaus: Jakie są Twoje relacje z polską społecznością i czy robi ona co do niej należy? Jeżeli prześledzisz stare newsy na haiku-os.pl, to zauważysz, że nasza strona miała kiedyś więcej redaktorów i aktywnych użytkowników. Nawet starano się organizować konkursy deweloperskie (programy do fakturowania) z nagrodami pieniężnymi. W jednym z nich pula wynosiła bodajże 1000 zł, nie jest to dużo, ale liczy się sam fakt takiej nagrody i świadomość, że nie ma nic za darmo. Były to czasy gdy BeOS-a dało się jeszcze używać, Zeta była na rynku i zdawało się, że Haiku także już niedługo będzie. Od tamtej pory minęło wiele lat, społeczność się wykruszyła i raczej sprawia przygnębiające wrażenie. Czy mógłbyś wskazać czy coś źle robimy?

pdziepak: Nie sądzę aby polska społeczność robiła coś źle, wręcz przeciwnie, motywacja do promowania Haiku przy tak małym zainteresowaniu jest dość imponująca. Problemem jest raczej sam projekt. To całkiem naturalne, że zainteresowanie wygasa jeżeli postępy w pracach nie są wystarczające. Czasami mam wrażenie, że w Haiku w pewnym stopniu widać skutki syndromu „not invented here”. Zbyt wiele rzeczy musi być „natywnych” (cokolwiek to znaczy) i najlepiej napisanych całkowicie od zera. Niestety, w taki sposób nie da się sprawnie zbudować kompletnego systemu operacyjnego bez olbrzymich nakładów pracy. Na szczęście, dzięki menedżerowi pakietów przybywa nam „obcych” aplikacji, co jest niewątpliwie bardzo dobrym zjawiskiem.

Premislaus: Jakie są Twoje inne zainteresowania, hobby? Jakiej muzyki słuchasz, jakich autorów lubisz? Oglądasz jakieś filmy albo seriale?

pdziepak: Jeśli chodzi o muzykę to głównie ciężkie i bardzo ciężkie brzmienia, choć zdarzają się lżejsze wyjątki. W przypadku książek muszę przyznać, że sytuacja mogłaby wyglądać dużo lepiej, ale nie jest aż tak źle, żebym nie mógł wskazać ulubionych autorów – H. P. Lovecraft i J. R. R. Tolkien (nie licząc Władcy Pierścieni i Hobbita). Trudno będzie mi określić jakie filmy lubię, bo „dobre” to jest bardzo subiektywne określenie i właściwie niczego nie mówi. Nie przepadam natomiast za komediami (z nielicznymi wyjątkami) i bzdurnymi filmami akcji jakich niestety pełno.

Premislaus: Grasz może w jakieś gry komputerowe?

pdziepak: Od dawna w nic nie grałem. Zawsze jednak preferowałem cRPG różnej maści i nie mam żadnych wątpliwości, że najlepszą grą z jaką kiedykolwiek się zetknąłem jest Planescape: Torment.

Premislaus: Jakie inne projekty open source wspierałeś lub wspierasz?

pdziepak: Cóż, nie ma zbyt wielu systemów operacyjnych na rynku. W tamtym roku brałem udział w GSoC dla DragonFlyBSD, w tym roku czeka mnie GSoC dla OSv. Dawno temu pracowałem jeszcze nad FreeSpace Source Code Project, projektu powstałego po uwolnieniu przez twórców kodu źródłowego gry FreeSpace. Nie mogę jednak powiedzieć, że dobrze wspominam tamten projekt.

Premislaus: Dlaczego?

pdziepak: Subversion ;-).

A tak bardziej na serio (choć Subversion w istocie nie lubię), to całkowity brak jakiejkolwiek organizacji i brak jasno określonych celów projektu. Była to mieszanka C i C++ z przewagą tego pierwszego, pisana w taki sposób – byle tylko działało, z różnymi dziwnymi kwiatkami i kodem w sporej części napisanym w latach 1996-1998. Z nie do końca zrozumiałych powodów, musiało się to wszystko kompilować na starożytnym MSVC 6, który był nieporównywalnie bardziej uciążliwy we współpracy niż GCC2. Jakakolwiek forma code review była temu projektowi obca.

Premislaus: Czy prace jakie wykonujesz przy Haiku, były i będą przydatne w innych projektach w które się angażujesz? Ja wiem, że DragonFlyBSD i OSv to trochę inny target niż Haiku, ale czy są jakieś analogie pomiędzy tymi projektami? Z czym te projekty mogą być według Ciebie lepsze lub gorsze od Haiku, nie mam na myśli funkcjonalności typu sterowniki, czy też szerokiego wykorzystania, ale np. organizację?

pdziepak: Jeśli chodzi o OSv, to ten projekt ma bardzo niewiele wspólnego z Haiku, mimo zgodnej licencji, to nie ma za bardzo możliwości przenoszenia kodu między nimi. OSv wykorzystuje w pełni C++11 i Boost w kernelu. W przypadku DragonFlyBSD nie ma już aż takich różnic, ale kompletnie inna budowa kernela, pozbawia sensu jakiekolwiek próby przenoszenia mojej pracy z jednego projektu do drugiego. Na poziomie użytkowania OSv i Haiku są jeszcze bardziej różne. Haiku to pełnoprawny system operacyjny, podczas gdy OSv to właściwie exokernel działający jedynie na maszynach wirtualnych, więc nie widzę żadnego sensu w porównywaniu zalet i wad tych projektów. DragonFlyBSD to rzeczywiście zupełnie inny target – serwery, Haiku jest zdecydowanie bardziej przyjazne użytkownikowi.

Premislaus: Czy wyobrażasz sobie, że Microsoft mógłby przejść na model open source?

pdziepak: Trochę kodu Microsoftu jest w Linuksie na licencji GPL. Część ich własnych projektów także ma ogólnodostępny kod źródłowy (mam tu na myśli głównie Singularity), oczywiście nie jest to już licencja zatwierdzona przez Jego Ekscelencję R. M. Stallmana, ale nie zmienia to faktu, że każdy może ten kod dostać. O ile dobrze pamiętam to w ramach współpracy z niektórymi uczelniami, został także udostępniony kod źródłowy kernela Windowsa. Nie jest to więc tak, że Microsoft jest wielkim, odwiecznym wrogiem open source. Nie sądzę jednak aby w najbliższej przyszłości Windows stał się projektem open source.

Premislaus: Wewnątrz ruchu open source poświęca się wiele energii na dyskusje związane z licencjami, wolne vs. otwarte oprogramowanie, etc. Jakie masz zdanie na ten temat?

pdziepak: Szczerze mówiąc mało mnie te spory GPL vs. BSD i wolne vs. otwarte interesują. Jest jednak na świecie wielu ludzi którzy nie mogą żyć bez narzucania innym swoich poglądów, więc skoro muszą to niech się kłócą. Owszem czasem niekompatybilność licencji jest trochę irytująca, ale nie jest to aż tak częsty problem. Nie wyobrażam sobie także nieużywania danego programu tylko dlatego, że nie jest wolny.

Premislaus: Wiele rozwiązań w IT nie przyjęło się z różnych powodów, czasem coś gorszego wygrało z czymś lepszym. Czego najbardziej żałujesz? Z naszych rozmów na IRC-u wiem, że nie możesz odżałować Itanium.

pdziepak: Nie powiem, że Itanium jest lepsze ale nie ukrywam, że rzeczywiście interesujące pomysły zostały wykorzystane w tej architekturze, szczególnie VLIW i speculative execution są tam ciekawe. Szkoda też, że wspomniane przeze mnie wcześniej Singularity nie doczekało się żadnej kontynuacji. Plan 9 także mógłby być czymś więcej niż tylko ciekawostką. Szczególnie, że to system operacyjny przy którym maczali palce Ken Thompson i Dennis Ritchie.

Premislaus: Przy okazji wydania GCC 4.9 napisałeś na polskim kanale IRC Haiku, że możesz wreszcie wrócić z Clanga na GCC. Z czym Twoim zdaniem GCC jest lepsze? Ostatnio raczej obserwuje się trend krytykowania GCC i że Clang to już pewna przyszłość.

pdziepak: Mam wrażenie, że fascynacja Clangiem z którą się czasami spotykam jest przesadzona. Nie mam jakichś bardzo technicznych powodów dlaczego wolę GCC, ale po prostu Clangowi udało się bardziej zirytować mnie takimi rzeczami, jak ostrzeganiem o kodzie który jest zgodny ze standardem, lub trudną do zrozumienia interpretacją standardu w sprawie _Generic. Często też pojawia się argument, że Clang ma dużo bardziej przejrzystą wewnętrzną architekturę, niewątpliwie jest to prawda, ale szczerze mówiąc jako użytkownika kompilatora mało mnie to interesuje.

Premislaus: Dość powszechnym poglądem jest to, że Haiku brakuje dużego IDE w postaci Eclipse. Mamy edytor z podświetlaniem składni Pe, dosyć proste IDE Paladin i port edytora Vim (zapewne są jeszcze jakieś inne konsolowe narzędzia). Jak dużym zadaniem byłby port jakiegoś dużego i popularnego IDE? I czy narzędzia dostępne na Haiku są na prawdę niewystarczające, czy może jest to tylko kwestia lenistwa, niechęci przed nauką kolejnego programu?

pdziepak: Może nie tyle kwestia lenistwa co przyzwyczajenia. Jest wielu ludzi którzy tak jak ja, nie używają dużych IDE i wystarcza im w zupełności prosty edytor. Wielu innych natomiast nie potrafi sobie wyobrazić programowania bez IDE i nie sądzę aby było to coś negatywnego, jakaś oznaka lenistwa. No i jest jeszcze trzecia grupa ludzi, którzy potrzebują cały osobny system operacyjny, najlepiej napisany w Lispie, żeby móc programować. Każdy ma swoje przyzwyczajenia i ciężko oczekiwać, że nagle je porzuci. Nie sądzę jednak żeby istniała potrzeba pisania nowego IDE specjalnie dla Haiku, tak jak to niektórzy sugerują. Lepiej byłoby wykorzystać taką pracę na port np. Eclipse, z którego mogłyby skorzystać inne aplikacje java’owe.

Premislaus: Po co więc GNU/Hurd jeśli jest Emacs?

pdziepak: Interpreter Lispa trzeba na czymś uruchomić, od tego jest GNU/Hurd..