Tags Posts tagged with "haiku"

haiku

Projekt Haiku - slider

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

przez -
32 2074
Haiku

Efektem ich prac jest w pełni działające zarządzanie pakietami w Haiku, nowy planista oraz ulepszona, natywna przeglądarka internetowa oparta na WebKicie – WebPositive. Dodatkowo firma Google dwa razy wpłaciła po 5 000 dolarów na rzecz systemu Haiku.

Styczeń

Styczeń przywitaliśmy bardzo cieple, informacją o zasileniu konta Haiku, Inc. kwotą 5 tys. dolarów przez firmę Google. W serwisie Ars Technica ukazała się recenzja Haiku Alpha 4. Deweloperzy racowali głównie nad natywnym debuggerem autorstwa Rene Gollenta, który zastąpił długo wysłużonego GDB. Jérôme Duval zaktualizował sterowniki sieciowe do wersji z FreeBSD 9.1. Axel Dörfler skupił się na usprawnieniu obsługi dysków GPT. Dokonano szeregu poprawek. Łącznie 23 osoby poświęciły swój prywatny czas na rozwój Haiku.

Projekt Haiku w 2013 roku -  Debugger zwraca wartość

Luty

W lutym nie działo się nic szczególnego, przez co trudno jest wskazać jakąś większą funkcjonalność, nad którą by się bardziej zaangażowano. Deweloperzy poprawiali błędy, doskonalili to, co wypracowali do tej pory. François Revol poprawił nasz kod odpowiedzialny za U-Boot na platformie PowerPC. Alexander von Gluck dla wersji gcc4h dodał pakiet Mesa 9.0.2. John Scipione, który jest odpowiedzialny u nas za wiele poprawek w interfejsie użytkownika, rozpoczął prace nad kolejnymi dokumentacjami API Haiku. Ponownie włączono Services Kit które zostało opracowane podczas GSoC 2010. W wielkim skrócie Services Kit jest natywnym odpowiednikiem cURL. Hamish Morrison usprawnił obsługę ciasteczek w Haiku. Włączono sterownik cpu_idle (oszczędzanie energii przez procesor), autorstwa chińskiego studenta Yongcong Du z GSoC. A Giovanni Mugnai powiadomił społeczność, że dzięki portowi biblioteki Qt, udało mu się skompilować i uruchomić profesjonalną aplikację Scribus, służącą do składu tekstu. W lutym 15 ludzi pracowało nad Haiku.

Marzec

W marcu Paweł Dziepak ogłosił, że jego zadanie z GSoC 2012, czyli stworzenie klienta NFSv4 dla Haiku, zostało dodane do kodu źródłowego Haiku. Przede wszystkim to Oliver Tappe i Ingo Weinhold, rozpoczęli swoje ostateczne prace nad stworzeniem systemu zarządzania pakietami dla Haiku. Każdy z nich został zakontraktowany na 320 godzin i otrzymał po 4 000 Euro za swoją pracę. Był to już trzeci kontrakt w tym temacie, tym razem podwójny. Kolejnym newsem miesiąca było to, że TuneTracker Systems ostatecznie przeniosło swoje produkty z BeOSa na Haiku! TuneTracker Systems sprzedaje gotowe rozwiązania dla rozgłośni radiowych. Postanowiono, że do kodu źródłowego Haiku zostanie dołączone KeyStore API autorstwa Michaela Lotza, które służy do bezpiecznego zarządzania kluczami, hasłami i certyfikatami. Niestety Michael nie dokończył swojej pracy, gdyż uległ wypadkowi. Siarzhuk Zharski doskonalił aplikację Terminal, tak by nie odstawała od konkurencyjnych rozwiązań (kodowanie znaków, formatowanie, poprawa błędów, etc.). Dodano Mesa 9.1.1 (build gcc4h). Oprócz tego poprawiano błędy i wprowadzano konieczne zmiany. W marcu pracowało nad Haiku 18 osób.

Projekt Haiku w 2013 roku - Command Center System 5

Kwiecień

W kwietniu okazało się, że nie zostaliśmy zaakceptowani na GSoC 2013. Dla wielu z nas było to dziwne, bo uczestniczyliśmy już w kilku edycjach GSoC, Google Code In i otrzymywaliśmy dotację od Google. Paweł Dziepak zaimplementował w Haiku ASLR i DEP, Rene Gollent zaś wprowadził nowe funkcje do natywnego debuggera. A Chris Jones z serwisu unixmen.com poinformował na liście mailingowej Haiku, że poszukują redaktora, który by pisał o naszym systemie operacyjnym. Jak zwykle wprowadzono liczne poprawki i udoskonalenia. W kwietniu w rozwój Haiku było zaangażowanych 20 osób.

Maj

W maju Matthew Madia który jest odpowiedzialny za organizację non profit Haiku, Inc. postarał się o to, by dotacje na rzecz Haiku dało się wpłacać za pomocą Goodsearch, Flattr i Bitcoin. Jérôme Duval dodał wsparcie dla Virtio i usunął całą masę problemów, zgłaszanych przez kompilator dla 64-bitowej wersji systemu. Rene Gollent dalej rozwijał swoją aplikację Debugger. John Scipione oczyszczał kod źródłowy Haiku i wprowadzał drobne poprawki w interfejsie użytkownika. Siarzhuk Zharski podczas swoich prac nad aplikacją Terminal postanowił, że porzuci Termcap na rzecz TermInfo. Zakończyły się także pierwsze dwa kontrakty dotyczące menedżera pakietów. W sumie to cały miesiąc upłynął na naprawie błędów i usprawnieniach wewnątrz Haiku. W maju było aktywnych 20 deweloperów.

Czerwiec

Czerwiec rozpoczęliśmy od informacji, że Oliver Tappe i Ingo Weinhold wystartowali z kolejnymi kontraktami dotyczącymi zarządzania pakietami w Haiku. Oliver zgodził się przepracować 320 godzin za 4000€, a Ingo otrzymał 19.200€ za 480 godzin. Jérôme Duval usprawniał obsługę PCI, PCI-E, ACPI, etc. Rene Gollent kontynuował swoje postępy nad Debuggerem. Z ciekawostek to na YouTube można obejrzeć, że systemowy kalkulator w Haiku radzi sobie z długimi obliczeniami. Próbowałem tego samego na Windows 8.1 64-bit, niestety wyskakuje okienko z informacją, że obliczenia mogą potrwać bardzo długo i kiedy nacisnę kontynuuj, to program zwraca błąd przepełnienia. Ogólna aktywność spadła, jedynie 13 programistów znalazło czas dla Haiku.

Lipiec

W lipcu Stephan Aßmus postanowił, że system operacyjny zorientowany na desktop, musi posiadać graficzną aplikację przeznaczoną do zarządzania pakietami. Tym samym rozpoczął swoją wielomiesięczną pracę, skutkującą powstaniem HaikuDepot. Jérôme Duval był na fali! Pracował nad Virtio, lepszą obsługą PCI, SCSI, MSI-X i HyperTransport. Włączył też MSI (Message Signaled Interrupts) dla AHCI, EHCI, OHCI, UHCI, XHCI i warstwy kompatybilności ze sterownikami sieciowymi z FreeBSD. Rene Gollent poza usprawnianiem Debuggera dodał kolejne pakiety dla 64-bitowego Haiku. Użytkownik waddlesplash utworzył na GitHubie konto, na którym zamieścił wszystkie znane sobie kody źródłowe aplikacji pisanych z myślą o BeOSie i Haiku, które zostały porzucone i nie mają aktualnie opiekunów. François Revol prócz swoich prac dotyczących portu Haiku na platformę PowerPC i komputer Sam460ex, odwiedził imprezę open source RMLL która odbyła się w Brukseli i zadał pytanie na panelu jednej z komisji Parlamentu Europejskiego (pytanie pada o czasie 17:57:40, można włączyć polskiego lektora, niestety nie udało mi się uruchomić filmiku pod Firefoxem, działa pod Internet Explorerem…). Pytanie dotyczyło sprzedaży sprzętu ze sterownikami tylko dla Windows i bez dokumentacji umożliwiającej napisanie wolnego sterownika. W lipcu Haiku rozwijało 15 osób.

Sierpień

W sierpniu Siarzhuk Zharski połączył swój prywatny branch z gałęzią master kodu źródłowego Haiku. Siarzhuk dodał kod odpowiedzialny za karty dźwiękowe USB i włączył asynchroniczne transfery dla OHCI. Stephan Aßmus rozwijał HaikuDepot. Jérôme Duval dodał wsparcie dla x2APIC i generatora liczb losowych (RNG), włączył także MSI dla sterowników intel_extreme i hd audio. Mesa3D została zaktualizowana do wersji 9.2 (gcc4h). Pete Goodeve dołączył do Haiku aplikację PatchBay (podobne do Cortex, ale przeznaczone dla MIDI).

Projekt Haiku w 2013 roku - przeglądarka WebPositive

30 sierpnia ogłoszono dwa zupełnie nowe kontrakty. Adrien Destugues wziął na swoje barki rozwój natywnej przeglądarki WebPositive która jest oparta na WebKicie. Do jego zadań należy aktualizacja kodu WebKita do najnowszych rewizji, naprawa błędów, rozszerzanie przeglądarki o nowe funkcjonalności (np. tag audio i video html5). A także doprowadzenie Services Kit do stanu używalności. Kontrakt Adriena opiewa na sumę 2000€ za każdy miesiąc pracy i będzie trwał tak długo, dopóki starczy nam pieniędzy (trwa do dziś tj. styczeń 2014 r.). Adrien od rozpoczęcia kontraktu stara się co tydzień pisać notki blogowe o postępach swoich prac, do tej pory ukazało się 15 wpisów. Drugi kontrakt przypadł naszemu rodakowi, Pawłowi Dziepakowi. Paweł jest znany z tego, że pisze solidny kod i lubi niskopoziome rzeczy. Dlatego Paweł chciał zaimplementować zupełnie nowy scheduler, bo nasz dotychczasowy był bardzo prymitywny. Paweł za każdy miesiąc pracy otrzymał 2500$.

Projekt Haiku w 2013 roku - planista systemu

Nowy planista został dodany do kodu źródłowego Haiku 17 stycznia 2014 roku. Jego algorytm szeregowania można w skrócie opisać następującymi słowami kluczowymi; O(1), cache affinity, wsparcie dla SMT, niskie opóźnienia, soft real time. Planista był także projektowany z myślą o energooszczędności. Paweł usunął także limit 8 logicznych procesorów, teraz Haiku będzie potrafiło skalować się do 64 procesorów logicznych. Limit ten będzie można w przyszłości o wiele prościej rozszerzać, niż to było możliwe dotychczas. Niestety stare aplikacje pisane z myślą o BeOSie nadal będą widzieć jedynie 8 procesorów. Chyba, że kod źródłowy danego programu został uwolniony i dzięki temu można go uaktualnić. Limit 64 procesorów logicznych został ustawiony sztucznie, gdyż podczas inicjalizacji procesorów alokowana jest pamięć dla każdego z nich. Jako, że dziś trudno w rozsądnych cenach dostać procesor mający więcej niż 4 rdzenie, a główni dostawcy procesorów x86 jeszcze nie wyszli powyżej dwudziestu kilku procesorów logicznych (nadchodzący Xeon E5-4657L v2 posiada 24 procesory logiczne – 12 rdzeni plus HT), to ten limit wydaje się słuszny. Dzięki niemu zostanie zaoszczędzona pamięć. Limit można zmienić przez proste uaktualnienie jądra. Pawłowi zostało trochę płatnego czasu na naprawę ewentualnych błędów i dalsze poprawki. Jeszcze nie opublikował swojego raportu kończącego kontrakt. Oba kontrakty wystartowały w październiku. Ingo Weinhold zakończył swój kontrakt dotyczący menedżera pakietów. 18 sierpnia Projekt Haiku obchodził dwunaste urodziny. Na sierpień przypadło 20 aktywnych deweloperów.

Wrzesień

Wrzesień był bardzo ważnym miesiącem dla rozwoju Haiku. To wtedy połączono kod odpowiedzialny za zarządzanie pakietami z główną gałęzią kodu Haiku. Wiele razy zastanawiałem się w jaki krótki i zwięzły sposób opisać ten ogrom pracy, bez uciekania się do dużego artykułu na ten temat. Główną różnicą pomiędzy Haiku a tym, z czym możemy się spotkać w dystrybucjach Linuksa jest to, że w Haiku pakiety nie są rozpakowywane, ale montowane w wirtualnym systemie plików. Pakiet może zostać zainstalowany poprzez zwyczajne przeciągnięcie ikony do odpowiedniego, monitorowanego katalogu. Jeżeli będzie brakować jakichś zależności, to pojawi się komunikat z możliwością ich pobrania. Usunąć wybrany pakiet można po prostu przenosząc go do innego miejsca, np. do kosza. Montowanie nad rozpakowywaniem ma tę przewagę, że pakiet zawiera w sobie coś na kształt listy plików, dzięki czemu możemy właśnie łatwo usuwać pakiety i menedżer pakietów nie musi „pamiętać” tego, gdzie jakie pliki są obecne. Dodatkową funkcjonalnością jest to, że pakiety są skompresowane, pozwala to zaoszczędzić miejsce na dysku. Powoduje to także niższą fragmentacją i narzut na system plików, zwłaszcza gdy będziemy instalować coraz więcej pakietów. Ponieważ pakiety są dekompresowane w pamięci RAM, a cała wolna pamięć jest wykorzystywana jako cache dla systemu plików. Nie ma to wpływu na ogólną wydajność (nasz schemat kompresji zapewnia losowy dostęp). Format HPKG pozwala też na to, by tylko część plików w pakiecie była skompresowana, co pozwoli zmniejszyć narzut w przypadku gdy mamy pakiet z olbrzymią ilością jakichś dodatkowych danych (np. tekstury i modele do gry). Kolejną funkcjonalnością jest też blacklistowanie pakietów lub jego części, jest to przydatne gdy jakiś program lub sterownik sprawia problemy. Obok tego nasz system zarządzania pakietami zapewnia to co inne menedżery pakietów, czyli obsługa zależności (wykorzystywana jest biblioteka libsolv z openSUSE), pobieranie z repozytorium, konsolowe i graficzne narzędzia.

Projekt Haiku w 2013 roku - pkgman

Wrzesień obfitował też w inne wydarzenia. Odbyła się impreza BeGeistert 027 podczas której dyskutowano o Haiku, tradycyjnie po BeGeistert nastąpił 5-dniowy Code Sprint, kiedy to część deweloperów wspólnie pracowała nad kodem źródłowym Haiku. Właśnie podczas BeGeistert ostatecznie zaimplementowano menedżera pakietów. Prócz tego to Ithamar Adema pracował nad portem ARM, Ingo Weinhold poprawił różne błędy w obsłudze PAE, Jérôme Duval skupił się na dyskach USB i zapewnił wstępna obsługę touchpadów Elantech. Stephan Aßmus z początkiem miesiąca usprawniał sterownik USB HID tak żeby nowsze tablety Wacoma były lepiej obsługiwane. Dodano też usbdevs 1.653 z NetBSD. A Clemens Zeidler opublikował wyniki ankiety przeprowadzonej wśród użytkowników Haiku, na temat Stack and Tile. Jest to jedna z funkcjonalności Haiku umożliwiająca grupowanie okien w kartach, tak jak to jest w przeglądarkach internetowych. Można też „sklejać” okna bokami do siebie. Ankieta potrzebna była mu do pracy doktorskiej i badań jakie przeprowadzają na Uniwersytecie w Auckland. We wrześniu w rozwój Haiku zaangażowało się 19 deweloperów.

Październik

Październik to przede wszystkim start kontraktów Pawła i Adriena, o których była mowa wcześniej. Julian Harnath to kolejny deweloper który otrzymał prawo bezpośredniego zamieszczania swoich patchy, w głównym kodzie źródłowym Haiku. Julian Harnath jest znany głównie z natywnego portu MilkyTrackera. Julian dodał swoje dwa patche dotyczące responsywności Haiku i dzięki temu naprawił legendarny błąd #8007. Jérôme Duval zaktualizował sterowniki sieciowe do wersji z FreeBSD 9.2 i poszerzył obsługę kodeków Realteka o kolejne. François Revol pracował nad kodem dla PPC, ARM i m68k. W październiku Haiku było rozwijane przez 19 dewloperów.

MilkyTracker

Listopad

Listopad przywitaliśmy nową wersją ACPICA 20130823, przeprowadzoną przez Jérômego Duvala, który potem zajął się lepszą obsługą ACPI. Axel Dörfler dodał wsparcie dla komendy TRIM, póki co trzeba ją ręcznie wywoływać z konsoli i może nie działać na niektórych pamięciach masowych SSD. Ingo Weinhold zaimplementował prosty sterownik ramdysku, później wprowadził możliwość blacklistowania pakietów i skupił się na różnych poprawkach. Adrien Destugues dodał do Haiku aplikację z interfejsem graficznym SerialConnect, służącą do zarządzania komunikacją poprzez port szeregowy. Oliver Tappe zakończył swój kontrakt dotyczący menedżera pakietów. Google przekazało nam kolejne 5000 dolarów, co uratowało kontrakty Pawła i Adriena. Miejmy nadzieję, że nie jest to w ramach przeprosin za naszą hipotetyczną nieobecność na GSoC 2014. François Revol odwiedził demoparty Alchimie X, gdzie prezentował ostatnie wieści z Haiku. W listopadzie 25 deweloperów poświęciło swój czas dla Haiku.

Grudzień

Na koniec roku dostaliśmy prezent pod choinkę od Gerasima Troeglazova, zaktualizował sterownik ntfs3g i napisał translator dla plików PSD. Ingo Weinhold pracował nad trybem Safe Mode. Jonathan Schleifer umożliwił kompilowanie Haiku za pomocą Clanga. Alexander von Gluck usunął OpenGL Kit, za jego funkcjonalność odpowiada teraz pakiet Mesa3D (odpowiednie patche zostały zaakceptowane przez zespół Mesa3D). Zaktualizował też parser AtomBIOS dla sterownika radeon_hd. Na dodatek pojawiła się Mesa 10.0.1 dla gcc4h, a dla gcc2h dodano Mesa 7.9.2. W grudniu było aktywnych 23 deweloperów.

Projekt Haiku w 2013 roku - PSDTranslator Layers

Podsumowując, to rok 2013 był bardzo udany dla Projektu Haiku. Było zaangażowanych 56 różnych deweloperów. Zaimplementowano menedżer pakietów i nowego planistę, dwa niesłychanie ważne elementy nowoczesnego systemu operacyjnego. Haiku zostało usprawnione na każdym polu! Ten tekst liczy 17865 znaków, celowo pominąłem wiele rzeczy, bym mógł w rozsądnym czasie ukończyć ten artykuł. Nie napisałem np. o ciągłym poprawianiu zgodności z POSIX, o błędach wykrytych i naprawionych dzięki Coverity i statycznemu analizatorowi Clanga. O naszym już czwartym uczestnictwie w Google Code-In. Nie zostało ujęte to co działo się na prywatnych githubach deweloperów Haiku, np. implementowanie wsparcia dla EFI. I tak dalej… Wymieniałem głównie to nad czym ktoś w miarę ciągle pracował, opisywanie każdego commitu i każdego załatanego błędu nie ma sensu. Z powodów osobistych nie byłem w stanie na bieżąco informować o postępach w Haiku w poprzednim roku. Ostatni mój wpis na OSWorld jest sprzed roku, dlatego zdecydowałem się na taką formę. Chciałem pokazać czytelnikom OSWorld, że społeczność Haiku żyje, rozwija się i idzie ku lepszemu.

Czego możemy spodziewać się w 2014 roku? Na pewno kolejnego stabilnego wydania, które będzie niezłym szokiem dla tych osób które ciągle siedzą na czwartej wersji alfa i nie korzystają z nocnych budowań. Na wiki buglisty Haiku znajduje się niekompletna lista zmian dokonanych od czasu wydania czwartej wersji alfa. Wiele osób narzeka, że już czas na kolejne wydanie, bo naprawdę dużo zrobiono, a Haiku R1\Alpha4 miało swoją premierę 14 miesięcy temu. Co nas więc blokuje? Przede wszystkim błędy, z tego kilka krytycznych. Ingo Weinhold w kolejnym wydaniu chciałby mieć aktualizacje systemu za pomocą menedżera pakietów, jak sam twierdzi to powinien być to „nisko wiszący owoc”. HaikuPorts (wzorowane na Portage z Gentoo) systematycznie zapełnia się recepturami kolejnych programów, ale potrzeba nam jeszcze trochę więcej oprogramowania i trzeba porobić repozytoria. Dzięki portom Qt i OpenJDK, możemy o wiele prościej skrócić listę braków w dostępnym oprogramowaniu dla Haiku. Pod znakiem zapytania pozostaje kontrakt Adriena Destuguesa, wydaliśmy praktycznie wszystkie pieniądze na kontrakty w 2013 roku i nie wiadomo, czy kolejne darowizny pokryją obiecaną mu sumę pieniędzy. Adrien każdego dnia ulepsza naszą przeglądarkę internetową WebPositive, ale nie jest pewne czy zdąży z tagami audio i video html5, przed wydaniem kolejnej stabilnej wersji systemu.

Projekt Haiku w 2013 roku - QtCreator

Przyłączyłem się do społeczności Haiku prawie 5 lat temu, gdy poszukiwałem alternatywy dla Windows. Podzielam z nimi pogląd na to jak powinien wyglądać desktop. Jestem głęboko przekonany o sukcesie Haiku, o tym, że ciężka praca wkładana w ten projekt, pewnego dnia urodzi obfite owoce.

przez -
16 824
Haiku

Projekt Haiku otrzymał 5 000 dolarów w ramach pierwszej darowizny od firmy Google. Pieniądze te pozwolą na zapewnienie finansowania dodatkowych godzin pracy dla programistów, którzy są na kontraktach. Nie jest to pierwsze wsparcie ze strony Google, ponieważ w przeszłości firma opłaciła koszta podróży dwóm mentorom na Google Summer of Code Mentor Summit. Dodatkowo Projekt Haiku od kilku lat uczestniczy w programie Google Summer of Code i Google Code In.

Kondycja finansowana projektu na przestrzeni lat wykazuje tendencję wzrostową i cały czas się poprawia. W poniższej tabeli zostały przedstawione proste dane na temat liczby osób wspierających finansowo Projekt Haiku i liczby wszystkich dotacji.

Rok Liczb darczyńców Liczba wszystkich dotacji
2005 115 142
2006 57 74
2007 43 76
2008 140 248
2009 66 174
2010 194 412
2011 351 654
2012 506 885

Jak widzimy powyżej pierwsze dotacje były akceptowane od 2005 roku, jednakże zbieranie pieniędzy na opłacanie deweloperów zaczęło się w 2008 roku – Haiku Code Drive. Poproszono wtedy społeczność o wpłacanie pieniędzy, aby sfinansować studentów którzy nie zostali zaakceptowani w ramach Google Summer of Code. Dzięki temu udało się zebrać kilka tysięcy dolarów w ciągu miesiąca, ale rezultaty prac były mniejsze, niż oczekiwano. Postanowiono, że kontrakty deweloperskie będą podpisywane tylko z programistami, którzy mają już pewną reputację wśród społeczności.

Od 2010 roku na kontrakty deweloperskie wydano 29.000 dolarów, co pozwoliło opłacić 2010 godzin, średnio 14 dolarów za godzinę. Obecnie finanse prezentują się w następujący sposób:

  • 44 000 dolarów dostępnych środków.
  • Minus 11 000 dolarów na poczet nadchodzących kontraktów (menedżer pakietów).
  • Daje nam to 33 000 dolarów na pensje dla deweloperów.

Pojawiają się propozycje, aby skorzystać z crowdfundingu, co pozwoli zaoferować bardziej konkurencyjne stawki za dłuższy kontrakt, jednakże obecnie bardzo trudno jest znaleźć wykwalifikowaną osobę, która miałaby czas na krótkoterminowy kontrakt w swoim harmonogramie.

przez -
5 861
Haiku

Ogłoszono wydanie Haiku Release 1 Alpha 4, który to projekt jest inicjatywą stworzenia systemu operacyjnego, wzorowanego na architekturze systemu BeOS. Minęło szesnaście miesięcy od ukazania się wersji Haiku Release 1 Alpha 3 i przez ten czas nie próżnowano. Głównym celem tego wydania, jest zapewnienie stabilnej wersji dla zewnętrznych deweloperów, którzy są zainteresowani rozwijaniem oprogramowania i testowaniem.

Naprawiono ponad 1000 błędów. Dodano nową, natywną aplikację Debugger, a także możliwość generowania kodów QR w KDL. Udoskonalono system plików BFS, poprawiono obsługę NTFS oraz wsparcie dla dysków Blu-ray. Ulepszono sterowniki USB OHCI, poprawiono identyfikację CPU oraz tłumaczenia. Pojawiła się nowa aplikacja do przełączania układów klawiatury, nowy 10 pasmowy equalizer, sterownik pcnet oraz wczesne wsparcie dla IPv6. Udoskonalono sterowniki kart sieciowych i bezprzewodowych. Dodano wsparcie dla nowych chipów Radeon HD i Intel Extreme, wsparcie dla WPA/WPA2, a także Mesa 7.8.2 i Mesa 8.1.0-devel.

przez -
0 530
Haiku

Alexander von Gluck ogłosił, że tryb gościa dla Haiku, został dodany do głównego repozytorium Subversion, maszyny wirtualnej VirtualBox. Nie oznacza to, że pojawi się dla Haiku natywny VirtualBox, ale to, że wirtualizowane Haiku będzie działać wydajniej na innych platformach. Jest to duże zwycięstwo i docenienie naszego projektu. Tak czy inaczej, korporacja Oracle będzie dzięki temu udzielać wsparcia Projektowi Haiku. Warto także wspomnieć, że było to możliwe dzięki sponsorowanemu przez Google programowi Google Summer of Code 2012, bo właśnie w ubiegłym roku, student Mike Smith pracował nad tym zadaniem.

Haiku

KDL (Kernel Debugging Land) oferuje nam wiele konsolowych narzędzi, które służą do analizowania przyczyn problemu z systemem. Jeżeli pojawi się KDL, to znaczy, że dzieje się coś niedobrego z Haiku i należy zgłosić to na bugliście. Istnieje to do tego kilka wbudowanych narzędzi i sposobów. Jednym z nich jest posiadanie dwóch komputerów z kablem i portami szeregowymi. Praktykują go z reguły deweloperzy, ponieważ potrzeba poprawnie skopiować plik syslog z /common/var/log/. Innym sposobem jest zrobienie zdjęcia ekranu z monitora z wyświetlanymi informacjami. Bardzo pomocne jest też wykonanie kolejnej fotografii, po użyciu polecenia bt (backtrace).

Oczywiście nie zawsze odpowiednie informacje zapiszą się w syslogu, mogą się też nadpisać po ponownym starcie Haiku, a zdjęcia potrafią być niewyraźne, zwłaszcza gdy ktoś ma monitor CRT. Często trudno jest zrobić fotkę bez ucięcia jakiejś informacji, czasem robi się przez to ich kilka, albo gdy je zbytnio skompresujemy, to wyglądają jak byśmy je robili za pomocą camera obscura.

Aby zaradzić tej sytuacji, Michael Lotz wprowadził generowanie kodów QR, bezpośrednio przez KDL. Pomysł swój oparł na bibliotece qrencode.

qrencode - KDL

Kody QR to alfanumeryczne, dwuwymiarowe, matrycowe i kwadratowe kody kreskowe. Posiadają one zakodowane na przemian informacje, za pomocą czarnych i białych bloków. Zawierają także wzorce wyrównania i korekcję błędów, dzięki czemu są łatwo odczytywane maszynowo. Nawet niskiej jakości kod QR, może być łatwo przechwycony i zdekodowany. Kolejną ważną informacją jest to, że coraz bardziej popularne smartfony, są je w stanie odczytać za pomocą aparatu w telefonie komórkowym. Poza tym programy potrafiące rozszyfrować kody QR, są dostępne na niemal każdej platformie. Oznacza to, że zamiast zrobić szereg fotografii, czy nawet czasochłonnie przepisać, można po prostu zeskanować kilka kodów QR.

Ma to oczywiście wadę w ilości zapisanych danych na daneh przestrzeni. Stała wielkość bloku która jest obecnie wspierana przez KDL, pozwala szybko wypełnić ekran, ale można uzyskać jedynie kilkaset bajtów. Domyślna konfiguracja wytwarza kod QR w wersji 19, z niskim poziomem odzyskiwania i umożliwia przechowanie 792 bajtów danych. Jeśli by wziąć więcej miejsca na ekranie, to można by skonfigurować większe kody QR, z maksymalnym, teoretycznym rozmiarem 177×177 bloków, co by nam dało 2953 bajtów informacji. Ze względu na ograniczenia pamięci w KDL, te wyższe rozdzielczości mogą nie działać poprawnie. Nie będąc w stanie przechować wielu informacji w jednym QR kodzie, oznacza to, że będzie trzeba generować kolejne QR kody dla zabezpieczenia wszystkich danych.

Obecne ograniczenia

Add-on debuggera jądra qrencode, jest ładowalnym modułem który używa publicznego API jądra, do instalowania poleceń debuggera. Podczas gdy KDL implementuje potok w niektórych poleceniach, to qrencode nie, bo nie jest to częścią publicznego API. Dodatkowo buforowanie danych i opróżnianie pamięci z danych, muszą być wywoływane ręcznie, co niweluje zalety potoku.

Generowanie kodów QR

Istnieją dwa ogólne sposoby generowania kodów QR:

  1. Użycie polecenia qrencode, które bezpośrednio wygeneruje QR kody dla jednego wiersza wejścia
  2. Można też buforować wiele wierszy z danymi wyjściowymi, używając polecenia qrappend, a następnie wygenerować kody QR z wykorzystaniem komendy qrflush

Polecenie qrencode jest zwykle mało pomocne, ponieważ zawsze będzie tylko generować kod QR, wyświetlać go i powracać. To oznacza, że jeśli nasz potok zawiera wiele linii tekstu z danymi wyjściowymi, to pokaże się kilka kodów QR, a my nie będziemy mieli czasu na ich zeskanowanie. Również każdy z tych poszczególnych kodów QR będzie zawierać tylko jedną linię i marnować resztę miejsca w macierzy.

Można jednak wykorzystać qrencode, dla pojedynczego wiersza wejścia, które dostarczymy jako argument. Może to być przydatne w dwóch sytuacjach. Aby dowiedzieć się jaki jest najbardziej odpowiedni rozmiar kodu QR i gdy chcemy szybko dostać się do ostatniego wiersza danych wyjściowych, np. wyniku polecenia. Możemy także uruchomić komendę qrencode wraz z ciągiem jako argumentem:

kdebug> qrencode test

Lub jako cel potoku:

kdebug> call 10 - 3 | qrencode

Aby uzyskać więcej funkcji, można użyć bufora QR, który to może być manipulowany za pomocą poleceń: qrappend, qrflush i qrclear. Pierwsza komenda załącza wiersz do bufora QR. Dlatego też idealnie się nadaje do odbierania końca potoku. Uruchommy jakąś komendę i wykonajmy potokowanie do qrappend:

kdebug> sc | qrappend

Wyniki na wyjściu polecenia (sc, w tym przypadku realizuje stos wywołań bieżącego wątku) zostaną dołączone do bufora QR. Bufor QR ma ograniczony rozmiar, co oznacza, że wypełnienie go przez qrappend może powodować osiągnięcie końca zakresu działania. Kiedy tak się stanie, to zostaną automatycznie wygenerowane kody QR, aby opróżnić bufor QR i zrobić wolne miejsce dla wprowadzenia nowych danych. Jeśli dane wyjściowe są na tyle krótkie, że nie dojdą do limitu bufora, to polecenie zakończy się bez wydrukowania rezultatu i oznacza to, że wiersze z powodzeniem zostały załączone do bufora QR. Następnie należy użyć komendy qrflush, która opróżni ze wszystkiego bufor QR i wygeneruje kod QR.

Zauważ, że z powodu ograniczeń wymienionych powyżej, polecenie qrappend początkowo nie wie kiedy potok jest zrobiony, dlatego nie można automatycznie opróżnić bufora QR. Nawet jeśli użycie qrappend spowodowało ukryte opróżnienie bufora, to ostatnia zawartość bufora nadal pozostaje. Trzeba użyć polecenia qrflush po każdym zastosowaniu komendy qrappend.

Jeśli chcemy usunąć bufor QR bez generowania kodów, lub upewnić się zawczasu, że jest on pusty przed uruchomieniem polecenia qrappend, powinniśmy użyć komendy qrclear. To polecenie nie przyjmuje żadnych argumentów, po prostu resetuje bufor QR, by był on pusty.

Generowanie adresów URL z danymi

Do tej pory wyprodukowane kody QR, zawierają tylko zwykły tekst. W zależności od sytuacji jest to w pełni wystarczające. A czytnik kodów QR którego używasz, może dostarczać wygodne funkcje, do dalszego przetwarzania informacji. Jednak kiedy trzeba zebrać wiele kodów QR, czyli gdy chcesz przenieść dużo danych wyjściowych poza KDL(np. cały syslog), to zebranie w całość wszystkich kodów, które są partiami tekstu, może być uciążliwe. Na szczęście add-on debuggera jądra qrencode przychodzi tutaj z pomocą. Mianowicie, możemy wykorzystać polecenie qrwebpost, które generuje kod QR z adresem URL zamiast czystego tekstu. Komenda qrwebpost stosuje “start” lub “stop” jako pierwszy argument. Argument “start” oznacza, że chcesz rozpocząć generowanie adresu URL i wymaga drugiego argumentu “id”, którego chcesz użyć. Id jest krótkim ciągiem znaków służącym do identyfikacji danych wyjściowych po stronie serwera, gdzie dane są później gromadzone. Nie ma żadnej logiki wbudowanej w serwer, co oznacza, że może nastąpić kolizja identyfikatorów i dane przesyłane od różnych ludzi nadpiszą się. Dlatego należy stosować unikatowe identyfikatory.

Aby rozpocząć generowanie adresów URL za pomocą polecenia qrwebpost, możesz postąpić w podobny sposób:

kdebug> qrwebpost start test

Spowoduje to natychmiastowe wygenerowanie początkowego kodu QR, z samym adresem URL. Jeśli zeskanujesz ten kod QR, to powinieneś otrzymać link zamiast czystego tekstu. Większość czytników pozwala otwierać linki bezpośrednio po skanowaniu, co czyni ten sposób pracy dość wygodnym. Jeśli otworzysz początkowy link, to poprzednie przechowywane treści mające to samo id, zostaną usunięte. Kiedy zaczynasz od nowa to ma to sens, bo upewnia Cię to, że nie są przechowywany na serwerze jakieś stare dane. Jeśli chcesz by były one przechowane, to po prostu nie skanuj nowego kodu QR, albo nie otwieraj linka.

Kiedy masz już wszystko ustawione, to możesz rozpocząć generowanie kodów QR tak jak poprzednio (używając qrencode lub qrappend i qrflush). Wszystkie generowane kody QR będą formatowane jako adres URL i zawierać blok danych w ciągu zapytania (query string – inaczej kwerenda, np. służy do uzyskania odpowiedzi z bazy danych). Otwarcie takiego adresu URL przeniesie Cię na stronę serwera, gdzie dane zawarte w ciągu zapytania są automatycznie dołączane do bufora o podanym identyfikatorze. Usługa będzie również wyświetlać link, byś mógł ponownie odebrać dane. Jeśli klikniesz w link to zobaczysz stronę z nagromadzonymi danymi dla tego id i skąd będziesz mógł je pobrać w formacie RAW, albo usunąć jeśli Ci nie są już potrzebne.

Jeśli chcemy z powrotem przełączyć wygenerowane kody QR na zwykły tekst, wydajemy polecenia qrwebpost z argumentem stop.

Minimalizowanie ilości danych wyjściowych

Przechwytywanie wielu kodów QR jest żmudną pracą, która wymaga zaplanowania, jak wielu danych potrzebujemy. W tym celu możemy użyć komend head, tail i grep do filtrowania danych wyjściowych swoich poleceń, np. do odpowiednich sekcji, punktów.

Konfigurowanie wersji kodów QR

Domyślną wersję generowanych kodów jest wariant 19, co przekłada się na macierz o rozmiarach 93×93 bloków. Ten rozmiar idealnie pasuje na ekranie o rozdzielczości 800×600, ale to może być nieoptymalne dla nas. Jeśli mamy więcej miejsca do wykorzystania na ekranie, to możemy zwiększyć rozmiar do wersji 40 (macierz 177×177 bloków). Należy jednak pamiętać, że z powodu ograniczeń pamięci, może być niemożliwe użycie wyższych wersji, bez dostosowania debuggera i jego ponownej kompilacji. Użyjemy polecenia qrencode z dołączonym ciągiem tekstowym test, by sprawdzić czy kody QR działają poprawnie po zmianie wersji. Możemy także obniżyć wersję, jeśli przechwycenie naszym urządzeniem dużego kodu QR, stanie się problematyczne.

Podsumowanie

Korzystanie z kodów QR pozwala wyodrębnić dane tekstowe z KDL, za pomocą smartfona lub podobnego urządzenia. Ograniczenia w gęstości zapisu może nie uczyniły tej metody zbyt wygodnej, ale może pozwoli ona pokonać konieczność eksperymentowania z fotografiami, czy o zgrozo ręczne przepisywanie.

przez -
7 762
Voptop

Voptop – komunikator VoIP działający we własnej sieci p2p, zbudowanej z klientów Voptopa, która swoim działaniem przypomina sieć TOR. Zależy ona od swoich użytkowników, co może powodować niestabilne, bądź powolne jej działanie. Im więcej będzie podłączonych klientów, tym sieć będzie działać szybciej. Jeżeli ktoś chcę wesprzeć tę sieć to wystarczy, że jego Voptop będzie stale uruchomiony.

Autorem aplikacji jest Robert Stiehler, która to jest jego pracą licencjacką: Voice over Peer to Peer.

Voptop - komunikator internetowy dla Haiku

Do działania programu niezbędny jest otwarty port 48617, natomiast komunikacjia z serwerem odbywa się na porcie 48616. Instrukcja użycia programu znajduje się w katalogu /boot/apps/Voptop.

Voptop - komunikator internetowy dla Haiku

Możliwości programu:

  • Rozmowy VoIP
  • Rozmowy tekstowe
  • Bezpieczna transmisja z szyfrowaniem
  • Komunikacja klienta do serwera jest szyfrowana z użyciem RSA (klucz prywatny/publiczny)
  • Komunikacja klienta do klienta(rozmowy głosowe i tekstowe) jest szyfrowana z użyciem algorytmu XTEA.
  • Rozmowa “telefoniczna” z innym użytkownikiem sieci nie odbywa się bezpośrednio. Czyli połączenie jest kierowane przez szereg innych klientów, podobnie jak jest w sieci TOR – trasowanie cebulowe.
  • Kontakty są przechowywane z użyciem systemowej (Haiku) aplikacji People( atrybuty pustego pliku).
  • BQuery służy do administrowania kontaktami.

Do zrobienia pozostają:

  • Konferencje telefoniczne
  • Rozmowy video
  • Konferencje video

Na razie jest dostępny jedynie klient dla systemu operacyjnego Haiku. W przyszłości zostanie dodany na inne platformy: Android, iPhone, Windows, MacOS X, Linux.

przez -
2 524
Haiku

16 stycznia br. zakończył się turniej Google Code-In, skierowany do uczniów szkół. W tym czasie wolontariusze ukończyli 208 zadań na rzecz Haiku. W większości polegały one na tłumaczeniach systemu, prezentowania Haiku podczas spotkań lokalnych grup linuksowych, sprawdzaniu zgłoszonych błędów, czy nadal są aktualne, bądź projektowaniu różnych grafik na potrzeby marketingowe projektu Haiku.

W kwestii programowania to jeden z uczestników konkursu – Aleksas Pantechovskis, napisał narzędzie writembr, przydatne gdy Haiku jest jedynym zainstalowanym systemem operacyjnym na komputerze. Dzięki niemu można uruchomić system bez potrzeby instalowania bootmanagera. Ten sam programista napisał też klona BeOSowej aplikacji setmime, która pozwala z poziomu terminala, na sprawdzanie i modyfikowanie zarejestrowanych typów MIME w systemie. Ułatwia również niektóre sprawy, np. automatyzacja instalacji skryptów. Za ogólny wkład w Haiku (ukończył też “mniejsze” zadania), został dodany do listy współtwórców Haiku, jako osoba wnosząca wkład (contributor).

Inni zaś testowali powiązanie (zbindowanie) różnych języków z API Haiku, głównie pythona. Opracowano kilka plików .bep dla paru nieprzepisanych jeszcze programów, jak np. TOR. Pliki .bep wchodzą w skład narzędzia HaikuPorter, zawierają one informacje zapisane w ASCII, o tym jak i gdzie pobierać, instalować, patchować i budować pakiety z programami.

Wszystkie rzeczy dodane do kodu źródłowego Haiku, można przejrzeć na stronie git projektu Haiku.

Niestety nie było żadnych zadań związanych z tłumaczeniem Haiku na język polski. Możliwe, że nie zgłosił się żaden mentor znający nasz ojczysty język. Na tym polu wypadamy blado w porównaniu z sąsiadami zza wschodniej granicy. Na szczęście w tym przypadku można pomóc w każdej chwili, za pomocą Haiku Translation Assistant – które służy to tłumaczenia systemu i systemowych aplikacji, bądź skorzystać z innego narzędzia online, ale w tym przypadku tłumaczy się dokumentację, instrukcję obsługi Haiku dla zwykłych użytkowników.

Trzeba mieć na uwadze, że od jakiegoś czasu nie ma osoby zarządzającej polską lokalizacją, przez co zmiany nie mogą być dodawane do kodu źródłowego i recenzowane. Następnie co jakiś czas zwiększa się ilość tekstu do tłumaczenia, co ma związek z postępami wykonanymi podczas prac przy Haiku.

Polecane

CrossOver

0 139
CrossOver 17 został wydany i jest w stanie uruchomić Microsoft Office 2016 na Linuksie oraz MacOs. CrossOver 17 to najnowsza wersja komercyjnego narzędzia sterowania...