Wywiad z Grzegorzem Dąbrowskim

1. Witaj. Na wstępie napisz kilka słów o sobie jeśli możesz.

Nazywam się Grzegorz Dąbrowski, mam 29 lat, skończyłem studia informatyczne.

2. Czy interesowałeś się BeOSem? Od kiedy Twoje zainteresowanie Haiku i z jakiego powodu?

Pierwszy raz z BeOS miałem styczność wtedy gdy został on udostępniony za darmo w postaci BeOS 5 Personal Edition. Zainstalowałem go, pobawiłem się i porzuciłem po jakimś czasie. Nie stał on się moim podstawowym systemem operacyjnym.

Później usłyszałem o pojawieniu się Haiku. W 2003 roku rozpocząłem dosyć duży projekt, stworzenie dystrybucji linuksa - Pingwinek. Dystrybucja nie zyskała popularności, nie wytrzymała dużej konkurencji. Już wtedy było ich ponad 300 dostępnych dystrubucji linuksa. Dlatego postanowiłem porzucić rozwijanie "Pingwinek GNU/Linux". W ramach pingwinka powstało ponad 2500 opisów pakietów oraz system pakietów "box". Praca która została wykonana nie mogła zostać zmarnowana. Dlatego wtedy postanowiłem zmienić system bazowy z linuksa na inny, tylko na jaki? Na początku brałem pod uwagę inne duże popularne systemy, *BSD, OpenSolaris. Jednak zdecydowałem się dać szansę mniej popularnych systemom, Haiku, Hurd, Minix, Syllable. Po kilku miesięcznej obserwacji tych projektów, wybór padł na Haiku, była to druga połowa 2006 roku. Mimo, że wtedy Haiku było kompletnie niestabilne, nie potrafiło zwalniać poprawnie zaalokowanej pamięci, natywny kompilator nie potrafił skompilować "Hello World", to wybrałem Haiku bo widziałem w nim przyszłość. Był to trudny wybór ponieważ inne systemy były bardziej stabilne w tym momencie, np. na Syllable działał bez problemów kompilator. Patrząc z perspektywy czasu wydaje się, że wybór Haiku był trafiony, chociaż ostatnio inne systemy również zaczęły się dynamicznie rozwijać. Mam tu na myśli Minix i Hurd. W marcu 2007 wydałem "Pingwinek GNU/Haiku". Potem z powodów licencyjnych zmieniłem nazwę na TiltOS i poszedłem w kierunku tworzenia pakietów.

3. Jesteś twórcą "dystrybucji" Haiku gcc4 TiltOS - choć w kontekście licencji zwłaszcza gcc4 nie bardzo można użyć słowa Haiku - piszę w cudzysłowie, bo to dystrybucja(jak to linuksowo brzmi ;)) systemu, który jeszcze nie ma oficjalnego pełnego wydania a dokładniej na razie jest to tak naprawdę systemu paczek dla Haiku gcc4/gcc4h. Czy uważasz, że Haiku w wersji gcc4 hybrid jest tą lepszą drogą mimo zerwania kompatybilności z pewną częścią softu dla BeOSa - wymagania typu media server gcc2 etc. A jeśli tak to wypowiedz się szerzej na ten temat.

Kompatybilność ze starymi aplikacjami jest bardzo ważna. Patrzeć należy też w przyszłość. Nowsze aplikacje wymagają nowszych kompilatorów. Wiele aplikacji dawno temu porzuciło wsparcie dla GCC2 (standard C89). Nie wiem nic na temat aplikacji które działają na gcc2, a nie działają na gcc4h. Jeśli tak jest, to problem jest zapewne rozwiązywalny w mniej lub bardziej skomplikowany sposób. Na przykład poradzono sobie z translatorami w wersji gcc2 na systemie gcc4h poprzez umieszczenie ich w podkatalogu gcc2 i specjalnej obsłudze.

Skoro jesteśmy przy tematyce kompilatorów chciałbym wspomnieć, że ostatnimi tygodniami pracowałem na skompilowanie Haiku za pomocą kompilatora clang. Cel z minimalnym stopniu został osiągnięty, tzn. całe Haiku zostało skompilowane i uruchomiło się. Przy okazji zgłosiłem kilka błędów do kompilatora oraz do samego Haiku wraz z poprawkami. Zostało jeszcze kilka problemów do rozwiązania, np. zrezygnowanie z obejść w kodzie jakie musiałem wykonać aby skompilować Haiku. Niektóre fragmenty trzeba przepisać itp., niektóre aplikacje zachowują się inaczej. Przyczyną tego mogą być obejścia które zrobiłem lub błędy w Haiku, które ujawniły się w przypadku użycia kompilatora clang.

4. Pomagasz również przy pracach nad Qt, czy mimo wielu plusów typu łatwiejsze portowanie znanych aplikacji typu VLC Media Player, które w najnowszych odsłonach korzystają z Qt nie obawiasz się, że Haiku mogą zalać porty robionych na szybko i niedopracowanych portów?

Zgadza się, był czas w którym zajmowałem się Qt, a także kompilowaniem aplikacji Qt na Haiku, np. KOffice, KDE. Słowo porty jest bardzo niejednoznaczne. Przykładowo aplikacja używająca Qt, może zostać skompilowana na systemie Haiku i po prostu działać, bo Qt jest przeportowane mniej lub bardziej. Poziom portu może być bardzo różny. Weźmy pod uwagę Qt. Najbardziej trywialny port może być taki, że Qt zostanie skompilowane aby używało X serwera na Haiku. Będzie to działać, tylko że wolno, bo przez dodatkową warstwę i będzie niewygodne z powodu wyświetlanie okna w X serwerze. Kolejnym poziomem portu dla Qt jest używanie serwera aplikacji i multimediów z Haiku. Jest to mniej więcej aktualny stan. Najwyższym poziomem przeportowania jest zrezygnowanie z warstwy Qt i przepisanie aplikacji tak aby bezpośrednio korzystała z API Haiku. Nikt tego nie będzie robił, bo zajmuje to dużo czasu i jest trochę bez sensu, no chyba że ktoś z powodów ideologicznych chce mieć w pełni natywną aplikację.
Nie sądzę, aby Haiku zostało zalane niedopracowanymi portami. Nawet jeśli, to nie jest to żaden problem. To użytkownicy decydują z jakich aplikacji chcą korzystać. Jeśli port jest kiepskiej jakości to mogą wydarzyć się tylko dwie rzeczy, albo ktoś poprawi go, albo umrze on śmiercią naturalną. Wielu ludzi ciągle sądzi, że pojawianie się popularnych aplikacji z innych systemów na Haiku jest czymś złym. Ja uważam, że to pozytywnie wpływa na popularność systemu i potwierdza jego stabilność i dojrzałość.

5. Kiedyś VLC tworzono tak by był multiplatformowy - a przynajmniej dosyć łatwo było zrobić port - i był dostępny na różne systemy: BeOS, Syllable, QNX i oczywiście różnorakie Linuksy i *nixy. Dziś autorzy tego programu wykorzystują qt, żeby "uprościć sobie multiplatformowość". Jest to Twoim zdaniem iście na łatwiznę twórców VLC czy tylko brak motywacji kogoś by zrobić port najnowszego VLC nie korzystającego z qt na systemie, który nie posiadał by tego środowiska?

Programiści VLC w pewnym sensie poszli na łatwiznę, ale ich rozumiem. Utrzymywanie różnego kodu na różne platformy może spowalniać rozwój całego projektu. Wystarczy, że pojawią się niekompatybilne zmiany w rdzeniu aplikacji i wtedy trzeba uaktualniać wszystkie porty. Niestety nie zawsze są chętni do szybkiego poprawienia takiego kodu na daną platformę. Wtedy programiści mają problem przy wydaniu kolejnej wersji, bo albo czekają aż ktoś poprawi kod, albo wyłączają obsługę danej platformy. Utrzymywanie wspólnego kodu dla wielu platform jest po prostu prostsze. Jeżeli danej społeczności zależy na natywnym kodzie, to zawsze może napisać niezależnie klienta VLC, podejrzewam, że VLC udostępnia odpowiednie API.

6. Jesteś odpowiedzialny również za port pakietu biurowego KOffice - co wymagało przeportowania najpierw KDE Applications i KDE Development Platform - w tym momencie najnowocześniejszego i umożliwiającego wygodny import plików w popularnych formatach pakietu biurowego dla Haiku. Analogicznie następnym krokiem powinien być port OpenOffice. Pisałeś, że nikt nie będzie bawił się w natywny port bo to bez sensu, jednak port OO.org na MacOSX mimo, ze na początku był oparty na ixach w końcu został portem natywnym. Zresztą tej klasy program napisany natywnie byłby dobrą wizytówką dla systemu operacyjnego. Nie uważasz, że w pewnych przypadkach powinno się poświecić trochę czasu, żeby port był w pełni przepisany pod system? Dodatkowo biorąc pod uwagę, że Haiku nie ma w tym momencie ani jednego natywnego pakietu biurowego spełniającego dzisiejsze standardy, nawet z procesorem tekstu AbiWord są olbrzymie problemy przy porcie, dalej istnieje problem choćby z polskimi znakami etc. Czym jest to spowodowane Twoim zdaniem?

Jak już pewnie dało się zauważyć, lubię podejmować trudne wyzwania. Prace na OpenOffice dla Haiku rozpocząłem wiele miesięcy temu, ale po kilku tygodniach porzuciłem. Zanim wspomnę o szczegółach, to chciałbym zwrócić uwagę na to że port aplikacji na Haiku nie koniecznie jest zawsze bez sensu jak to wcześniej powiedziałem. Ogólnie aplikacje można podzielić na dwie grupy. Pierwsza grupa to taka w której aplikacja była zaprojektowana w ten sposób aby łatwo można było używać alternatywnych komponentów, na przykład dla GUI. Druga grupa to aplikacje monolityczne, które nie przewidują takiej możliwości. Do tej pierwszej grupy można zaliczyć OpenOffice (gtk+, qt, win, os2, aqua), Firefox, Abiword (cocoa, gtk+, win, beos), Transmission (gtk+, qt, beos). Portowanie aplikacji z pierwszej grupy ma jakiś sens, a z drugiej raczej nie.
Odnosząc się do problemu przeportowania Abiword, to trudność zapewne polega na tym, że jest sporo kodu do napisania. Mimo wszystko jest tego trochę mniej niż np. przeportowanie np. Gtk+ czy Qt. Niestety napisany kod jest specyficzny dla Abiword w odróżnieniu na przykład do Gtk+, więc koszt inwestycji jest bardzo duży.
Wracając do OpenOffice, portowanie tej ogromnej aplikacji podzieliłem na kilka etapów. Etap pierwszy to skompilowanie i uruchomienie używając Gtk+ (przy użyciu X serwera). Etap drugi to skompilowanie i uruchomienie używając Qt (bez X serwera). Etap trzeci i ostatni to port natywny, analogicznie jak to się dzieje z Abiword. Po cięzkiej walce pierwszy etap udało się osiągnąć, czyli mamy dostępne OpenOffice uruchamiane na Haiku w oknie X serwera.
Po zakończeniu zabawy z clang planuję wrócić do tematu OpenOffice i rozpocząć etap drugi. Do etapu trzeciego nawet nie będę próbował podchodzić, bo według mnie jest to orientacyjnie kilka miesięcy pracy na pełnym etacie i to nie dla jednej osoby.

.

7. Czy Twoim zdaniem menadżer pakietów, który jest przygotowywany dla Haiku, a który ma spełniać założenia podane tu: http://dev.haiku-os.org/wiki/PackageManagerIdeas, jest rozwiązaniem, które pozwoli w końcu na oficjalnym Haiku gcc2h, instalować soft bez znaczenia czy będzie dla gcc2 czy gcc4 bez groźby bałaganu w bibliotekach i poczuciem pewności, że wszystko będzie na swoim miejscu w systemie po zainstalowaniu dowolnego programu, nawet jeśli będziemy chcieli zainstalować jakiś pakiet z TiltOSa?

W powyższym dokumencie zaprezentowane jest kilka pomysłów odnośnie obsługi pakietów. Niestety wybór nie jest tutaj prosty, ścierają się tutaj dwie główne koncepcje. Z jednej strony dobrze byłoby aby aplikacje były samowystarczalne i instalowalne w apps, a z drugiej strony przydałoby się centralne repozytorium w którym występują zależności między pakietami. Takie repozytorium po części wymusza instalowanie aplikacji w jedno miejsce, np. do /boot/common. Co ciekawe w tym dokumencie nikt nie wspomina o problemie który Ty poruszyłeś - gcc2/gcc4, który jeszcze bardziej komplikuje sprawę obsługi pakietów. Aktualne rozwiązanie hybrydowe nie jest zbyt dobre, myślę, że przed wydaniem Haiku R1 deweloperzy przemyślą tę sprawę i zaproponują lepsze rozwiązanie. Ja osobiście widziałbym rozwiązanie w postaci różnych przestrzeni nazw dla gcc2 i gcc4. Załóżmy, że mamy system gcc2h, uruchomienie aplikacji gcc4 powinno odbywać się w ten sposób, aby widziała ona bazowy system oraz biblioteki gcc4. Można by to osiągnąć poprzez "UnionFS" i "chroot". Fizycznie pliki gcc4 byłyby odseparowane od głównej struktury systemu plików i mogły by się znajdować np. w /boot/abi/gcc4.

Nawiązując do ostatniego pytania, to pakiety z TiltOS znajdują się w centralnym repozytorium. Idea ta jest w sprzeczności ze współpracą z innymi źródłami plików, takimi jak ręcznie instalowane aplikacje w to samo miejsce na dysku, czy inny system pakietów. Analogicznie jest w świecie dystrybucji linuksa. Na przykład w systemie Ubuntu (pakiety deb) nie powinniśmy instalować pakietów z Fedory (rpm). Co prawda jest to zapewne możliwe, ale grozi nadpisywaniem plików i niespójną informacją i potencjalną niekompatybilnością.

8. Piszesz kilku miejscach jakoby potrzeba natywnych aplikacji przez użytkowników miałaby być spowodowana ze względów ideologicznych ale czy nie uważasz, że samo powstanie Haiku czy nawet BeOS to było posunięcie ideologiczne spowodowane chęcią stworzenia alternatywy dla komercyjnych systemów typu Windows czy MacOS jednocześnie nie będącego opartym na istniejących rozwiązaniach typu Linuks często z bagażem starych rozwiązań? Stworzenie systemu od zera opartego na nowoczesnych rozwiązaniach przygotowanego do pewnych zastosowań, w których istniejące rozwiązania miały problemy. I właśnie może przez to programiści i testerzy zajmują się Haiku, że stara się on jak najbardziej posiadać własne rozwiązania zamiast ściągać gotowe elementy z innych systemów, inaczej mogliby nie być wcale zainteresowani tym systemem.

Nie wiem jaki cel przyświecał twórcom BeOS, ale podejrzewam, że był on bardziej komercyjny niż ideologiczny. Natomiast powstanie Haiku powstało ze względów ideologicznych i myślę, że jest to motorem napędowym do ciągłego rozwijania systemu mimo dużej konkurencji innych systemów.
Jedną z głównych zalet Haiku według mnie jest spójność systemu i sensownie zaprojektowane API. Mamy jedno API do obsługi sieci, multimediów, GUI itp. W świecie linuksa jest zupełnie inaczej. Panuje tam chaos, do multimediów mamy np. GStreamer, Phonon, ffmpeg, do obsługi dźwięku szkoda wymieniać, do obsługi GUI np. Gtk+, Qt, fltk, podsystem graficzny też ciągle się zmienia.

9. Jak widzisz przyszłość TiltOS, będzie się oddalać od Haiku jeśli chodzi o rozwiązania czy będą jednak podążać podobną drogą? Czy może ujrzymy za jakiś czas TiltOSa jako system oparty na Haiku ale mocno zintegrowany ze środowiskiem Qt?

W obecnym stanie, TiltOS jako system operacyjny różni się od Haiku głównie tym, że większość kodu źródłowego która jest zaimportowana do repozytorium Haiku i pochodząca oryginalnie z innych źródeł jest zastąpiona właściwymi binarnymi pakietami box. Czyli przykładowo elementy takie jak bash, coreutils, libpng, libjpeg są instalowane z pakietów, jest ich ponad 30. Dzięki takiemu zabiegowi system można uaktualniać. Docelowo kod Haiku chciałbym zmodularyzować tak aby można było jądro i poszczególne kity uaktualniać przez sieć zamiast instalowania nowej wersji systemu. O integracji z Qt nie myślałem, bardziej bym widział TiltOS jako modularny system, kompatybilny binarnie z BeOS i Haiku (po ustabilizowaniu ABI gcc4) z dostępem do obszernego repozytorium pakietów. System prawdopodobnie jako hybryda gcc4/gcc2 lub clang/gcc2.

10. Chciałbyś coś przekazać naszym czytelnikom?

Drodzy czytelnicy promujcie system Haiku na tyle ile potraficie bo jest tego wart :). Jeśli jesteś użytkownikiem to zawsze możesz pisać o Haiku, tłumaczyć go na język polski, zgłaszać błędy, czy też wspierać finansowo. Jeśli jesteś programistą zawsze możesz pomóc rozwijać system, czekają na Ciebie Gallium3d, java, wine, OpenOffice i inne. Więc do roboty :)