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..

Podobne artykuły

  • sprae

    Nie rozumiem w jaki sposób metadane w systemie plików są wygodniejsze, skoro cały świat musi się do nich dostosowywać. “Overengineering”

    • Premislaus

      Jeśli czytasz po angielsku to ten dokument naświetli Ci sprawę – http://dcevents.dublincore.org/IntConf/dc-2011/paper/view/53/10

      Nie będę streszczał całości (to krótki dokument), można stworzyć uniwersalny schemat ze wspólną przestrzenią nazw i wtedy Linux nie musi dbać o to jak to jest w Haiku rozwiązane. I na odwrót.

      Na Linuksie xattr ma różne rozmiary, zależnie czy używasz systemu plików ext23 czy XFS.

    • sprae

      Tyle, że dziś liczy się integracja z siecią. Mac OS (przed X) już przeszedł przez piekło metadanych (ludzie bluzgali, że do każdego pliku z zewnątrz musieli ręcznie ustawiać mime). W Windows też pozbyli się Named Pipelines.
      Przez sieć przesyła się pliki, które mają w sobie metadane. Rozdzielenie metadanych i pliku to tylko niepotrzebne utrudnienia.
      Dziś nawet ciężko czasem zachować datę pliku (git), co dopiero inne metadane oddzielone od fizycznych danych w pliku.

    • Premislaus

      Bo się wygodnie tego używa, zwłaszcza gdy system plików przypomina bazę danych. Nie jest też tak, że każdy chce odejść od tej idei, istnieją ciekawe pomysły:

      http://lod-cloud.net/
      http://vimeo.com/36752317

      Tak wiem, że trzeba ręcznie ustawiać, ale nie dla każdego pliku. Haiku popularne formaty na ogół rozpoznaje automatycznie. Nie miałem problemów z PDF, plikami graficznymi, filmami i muzyką. Kwestia dobrej implementacji. Czy OS X nadal nie ma wektorowych ikon?

      Tam gdzie Windows i OS X dają ciała, tam Linux, Haiku i inne otwartoźródłowe systemy mają pole do popisu.

    • gość

      Nie zaszkodzi wprowadzić jakiś format, jakim na Mac’ach był SEA albo wcześniej Compact, który umożliwia spakowanie plików wraz z atrybutami do jednego nawet nie pliku, ale ciągu bajtów. Taki ciąg można przesyłać przez windowsowe sieci czy w najgorszym razie przekonwertować na 7 bit i wydziurkować na taśmie :).
      Może być np. 7Z, znam ten format i jego potencjał do trzymania bloków metadanych. Potencjał z resztą zupełnie zmarnowany nawet jeżeli chodzi o trzymanie linuksowych uprawnień.

  • Krystian Juskowiak

    Jestem za Haiku – głównie dlatego, że w 2000 roku śliniłem się na myśl o BeOSie (Windows nigdy mnie nie przyspawał do siebie, więc z czystej inności podobał mi się ten system).

    Niestety dobijam do 30’stki i zastanawiam się, kiedy mógłbym Haiku używać tak swobodnie jak dziś Linuksa, i ile będę miał wtedy lat :-) Podobnie kibicuję ReactOS, ale dręczy mnie to samo w jego kierunku :-) Kwestia aplikacji też ma niebagatelne znaczenie – dziś na Linuksie są nadal jakieś braki, a co dopiero Haiku czy ReactOS… :-( Ale interfejs Haiku – dla mnie to też zajebiaszczy plus :-) Takie połączenie tamtych lat, z ascetycznością, funkcjonalnością i estetyką. Jest w miarę transparentny.

    Być może Haiku z czasem znajdzie swoje miejsce w określonych zastosowaniach, tak jak niegdyś BeOS bo nie wiem, czy myślenie o Haiku jako normalnym systemie desktopowym kiedyś tam, jest sensowne :-/

    • Premislaus

      Jako, że Haiku jest zgodne z POSIX, to można teoretycznie mieć wszystko co jest na Linuksie. Gorzej z GUI ale zawsze można rysować za pomocą Qt.

      Ważne żeby kontrakt Adriena trwał jak najdłużej, bo to oznacza coraz lepszą przeglądarkę WWW. A wiele braków będzie można z czasem obejść aplikacjami webowymi. Tak samo doprowadzenie do końca portu Javy spowoduje zalew oprogramowania. Nie wiem jak teraz działa OpenJDK na Haiku, ale przed dodaniem menedżera pakietów dało się pobrać demo ThinkFree Office i odpalić na Haiku. Na HaikuPorts póki co lądują porty różnych bibliotek, których obecność przybliża moment sportowania tych wielkich aplikacji w stylu LibreOffice.

      Wszystko się rozbija o pieniądze. Na szczęście chyba nadal trwa trend, że z roku na rok mamy ich więcej.

      Haiku ma wiele problemów, ale im będzie większa popularność systemu, to poza wzrostem zgłoszonych błędów, będą pojawiać się inicjatywy które zaczną minimalizować braki. Od czasu ostatniej alphy dokonano ogromnego postępu.

    • Krystian Juskowiak

      To rodzi pewne nadzieje :-) Natomiast przyda się dopracować przeglądarkę WWW. Na 3 odwiedzone witryny, 2 wyświetlały się kompletnie niepoprawnie (z czego 1, czyli webowy mail, nawet się nie załadował po logowaniu) :-) Szkoda tylko, że nie mam możliwości pokombinować dłużej – Haiku pod VirtualBoxem zawsze po instalacji uparcie twierdzi, że no bootable device forund :-)

    • Premislaus

      Używasz wersji alpha czy najnowsze nightly?

      Źle działające strony możesz zgłaszać tutaj – https://dev.haiku-os.org

      Adrien głównie siedzi nad testami jednostkowymi których w WebKicie jest od groma. Web+ coraz więcej ich przechodzi. Jak spojrzysz na mój poprzedni artykuł o Haiku, ten podsumowujący 2013 rok, to jest tam zrzut ekranu w Web+ przedstawiający OSWorld.pl. I ta belka z menu nawigacyjnym strony jest kwadratowa. Teraz ładnie rysuje zaokrąglone rogi :-).

      W jaki sposób instalujesz? Z tego co rozumiem to nie wgrałeś bootloadera, albo nie wpisałeś Haiku do istniejącego, bądź nie nadpisałeś MBR. Jeżeli Haiku bootuje Ci z nośnika (pisałeś, że zainstalowałeś), to zanim zacznie się bootować, przytrzymaj shift. Włączy Ci się takie menu i w pierwszej pozycji możesz wybrać dysk.

      https://www.haiku-os.org/docs/userguide/en/bootloader.html

      W Haiku powinno dać się zrobić kopię MBR przed nadpisaniem tego.

    • Krystian Juskowiak

      Dzięki za info. Zatem muszą zgłosić parę witryn ;-)

      Instaluję pod VirtualBoxem – teoretycznie na końcu instalacji była informacja, iż przeszła ona pomyślnie. Niemniej była to wersja alpha, sprawdziłem wersję nightly i bootuje się ona bez problemu po instalacji na VM. Niemniej na nightly uparcie nie ma internetu ;-) Ale to detal, od moich przypadłości są Haikowe fora :-) Niemniej chyba częściej zacznę testować Haiku – ten interface po prostu do mnie przemawia :-)

    • Premislaus

      Jeśli w VM nie ma neta, to raczej jest to problem VM a nie Haiku. Myślę, że musisz pogrzebać w opcjach. Zwłaszcza, że masa ludzi korzysta z VirtualBoxa i im działa :).

      https://www.haiku-os.org/guides/virtualizing/virtualbox – nie wiem na ile to jest aktualne.

    • gość

      A jak wygląda kwestia programów X’owych? z tego, co pamiętam było pod Haiku lub może nawet BeOS’a coś takiego, co emulowało X’y, i wystarczył prosty port by uruchamiać X’owe programy.

    • Premislaus

      Na Haikuware wisi cała masa crapu, w tym X serwer. Pewnie to już nie działa i całe szczęście, bo było to strasznie powolne. Widziałem jak działał Blender.

      Inna rzecz jest taka, że do portów programów konsolowych X serwer jest zbędny. Do tych z GUI wystarczy to, że mamy Qt i OpenJDK (nie wiem w jakim stanie, dawno się tym nie interesowałem). Jeśli ktoś nie chce portować natywnie.

    • gość

      Dzięki za odpowiedź.
      Myślałem o portowaniu jakichś killer-app’ów z Pingwina. Powiedzmy szczerze, X’y kiedyś również były KOSZMARNIE powolne, i to nie tyle X’y przyspieszyły, co komputery. Aktualnie mocno uwiera brak wolnego pakietu biurowego i programu graficznego w stylu GIMP’a, co nie jest oparte na Qt.

    • Premislaus

      Sporo zależności wymaganych przez LibreOffice jest już spełnione ;). Pozostaje jeszcze natywny backend i kilka bibliotek.

      W przypadku GUI to albo musisz mieć port biblioteki odpowiedzialnej za GUI np. Qt, albo musisz przepisać GUI pod systemowe API.

      WonderBrush jest spoko, autor tej aplikacji na którymś BeGeistert pokazywał działającą wersję z nowymi funkcjonalnościami. W tym wersje na Ubuntu. I jest translator plików PSD. Muszę się dopytać czy siedzi nad tym dalej.

      BTW w repo wisi jakiś prosty arkusz kalkulacyjny Sum-It, nie wiem jakie ma możliwości (pewnie dosyć proste). Na razie go tylko raz włączyłem.

    • gość

      Możliwości mniej więcej odpowiadające SIAG’owi, choć gorsze formatowanie.

  • Dominik Grzywak

    Czy Haiku jest chociaż dalej rozwijany? bo mam wrażenie że ciągle najnowszą wersją jest ta jeszcze z 2012 roku?

    • gość

      Masz “source activity” – dziać się dzieje. Teraz powinno coś być robione z oprogramowaniem. Aktualnie portowany jest silnik renderowania stron z prawdziwego zdarzenia, więc są szanse na coś lepszego niż FF2.0 i słaby Web+.
      Ja natomiast próbuję zbudować swój program w Qt na Haiku i szczerze mówiąc nie wiem jak się za to zabrać.
      Do rozwoju oprogramowanie przydałaby się biblioteka typu Qt, ale z dodatkiem możliwości systemu: np. dostęp do bazodanowego systemu plików czy replikanty (replikantów chyba w Qt nie można zrobić).