🥇Coś jeszcze: pakiety aplikacji Haiku?

TL;DR: czy Haiku może otrzymać odpowiednie wsparcie dla pakietów aplikacji, na przykład katalogów aplikacji (jak .app w Mac) i/lub obrazów aplikacji (Linux AppImage)? Wydaje mi się, że byłoby to wartościowe uzupełnienie, które łatwiej zrealizować niż w innych systemach, ponieważ większość infrastruktury już istnieje.

Tydzień temu odkryłem Haiku, niespodziewanie dobrą system. A ponieważ od dawna interesuję się katalogami i obrazami aplikacji (inspirowany prostotą Macintosh), nie jest zaskoczeniem, że wpadłem na pomysł…

Dla pełniejszego zrozumienia: jestem twórcą i autorem AppImage, formatu dystrybucji aplikacji Linux, który koncentruje się na prostocie Mac i zapewnia pełną kontrolę autorom aplikacji i użytkownikom końcowym (chcesz wiedzieć więcej — zob. wiki i dokumentację).

Co jeśli zrobimy AppImage dla Haiku?

Przyjrzyjmy się nieco, czysto teoretycznie, co trzeba by zrobić, aby uzyskać AppImage, lub coś podobnego, w Haiku? Nie trzeba tworzyć czegoś od razu, ponieważ system, który już istnieje w Haiku, działa niezwykle dobrze, a wyimaginowany eksperyment byłby interesujący. Dodatkowo pokazuje on wyrafinowanie Haiku w porównaniu do środowisk pracy Linux, gdzie podobne rzeczy są strasznie trudne (mam prawo tak mówić: od 10 lat męczę się z debugowaniem).

W Macintosh System 1 każda aplikacja była oddzielnym plikiem, „zarządzanym” w Finderze. Używając AppImage staram się odtworzyć to samo doświadczenie użytkownika w Linux.

Przede wszystkim, co to jest AppImage? To system do wydawania aplikacji od zewnętrznych deweloperów (na przykład Ultimaker Cura), pozwalający na wydawanie aplikacji, kiedy i jak mają ochotę: nie trzeba znać specyfiki różnych dystrybucji, polityki budowy ani infrastruktury budowy, nie potrzebują wsparcia opiekunów, i nie mówią użytkownikom, co (nie) mogą instalować na swoich komputerach. AppImage należy rozumieć jako coś podobnego do pakietu dla Mac w formacie .app wewnątrz obrazu dysku .dmg. Główna różnica polega na tym, że aplikacje nie są kopiowane, a pozostają zawsze w AppImage, mniej więcej tak jak pakiety Haiku .hpkg są montowane, a nigdy nie są instalowane w zwykłym sensie.

AppImage przez ponad 10 lat swojego istnienia zdobył pewną popularność: sam Linus Torvalds publicznie go zatwierdził, a znane projekty (takie jak LibreOffice, Krita, Inkscape, Scribus, ImageMagick) przyjęły go jako główny sposób dystrybucji wersji ciągłych lub nocnych, które nie kolidują z zainstalowanymi lub niezainstalowanymi aplikacjami użytkowników. Jednak środowiska robocze i dystrybucje Linuxa wciąż najczęściej trzymają się tradycyjnego, scentralizowanego modelu dystrybucji opartego na dostarczaniu i/lub promują własne programy biznesowe i/lub inżynieryjne. Flatpak (RedHat, Fedora, GNOME) oraz Snappy (Canonical, Ubuntu). Czasami to prowadzi do śmiesznych sytuacji..

Jak to działa

Każdy AppImage zawiera 2 części: niewielki wykonawczy plik ELF (tzw. runtime.c), wraz z obrazem systemu plików SquashFS..

System plików SquashFS zawiera ładunek w postaci aplikacji oraz wszystkiego, co potrzebne do jej uruchomienia, co nie może być uznane za część standardowej instalacji dla każdej nowoczesnej dystrybucji Linuxa. Zawiera również metadane, takie jak nazwa aplikacji, ikony, typy MIME itd.

Podczas uruchamiania plik runtime wykorzystuje FUSE i squashfuse do zamontowania systemu plików, po czym przetwarza uruchomienie określonego punktu wejścia (tzw. AppRun) wewnątrz zamontowanego AppImage.
System plików jest odmontowywany po zakończeniu procesu.

Wydaje się, że to proste.

A to wszystko komplikuje:

z takim zróżnicowaniem dystrybucji Linuxa nic, co można uznać za ,,normalne”, nie może być określane jako ,,część standardowej instalacji dla każdej nowej dystrybucji”. Omijamy ten problem przez budowanie excludelist,która pozwala określić, co zostanie spakowane w AppImage, a co należy pobrać z innego miejsca. Mimo to czasami się mylimy, chociaż w ogóle wszystko działa świetnie. Z tego powodu zalecamy twórcom pakietów testowanie AppImages na wszystkich docelowych systemach (dystrybucjach).
Aplikacje w postaci ładunku muszą być przenośne w systemie plików. Niestety, w wielu aplikacjach sztywno określono absolutne ścieżki do, na przykład, zasobów w /usr/share. Trzeba to jakoś naprawić. Ponadto należy albo wyeksportować LD_LIBRARY_PATH, albo naprawić rpath. Aby rozruchowiec mógł znaleźć powiązane biblioteki. Pierwsza metoda ma swoje wady (które są omijane skomplikowanymi sposobami), a druga jest po prostu niepraktyczna.
Największą pułapką UX dla użytkowników jest to, że trzeba ustawić bit wykonywalności plikowi AppImage po jego pobraniu. Chcieć wierzyć, chcieć nie, ale dla niektórych to naprawdę stanowi barierę. Konieczność ustawienia bitu wykonywalności jest uciążliwa nawet dla doświadczonych użytkowników. Jako obejście zaproponowaliśmy instalację niewielkiej usługi, która monitoruje pliki AppImage i ustawia im bit wykonywalności. W czystej postaci, nie jest to najlepsze rozwiązanie, ponieważ nie będzie działać „out-of-the-box”. Dystrybucje systemu Linux nie dostarczają tej usługi, co oznacza, że użytkownicy „out-of-the-box” mają duży problem.
Użytkownicy Linuxa oczekują, że nowa aplikacja pojawi się w menu uruchamiania. Systemu nie można powiedzieć: „Patrz, nowa aplikacja, zajmij się tym”. Zamiast tego, zgodnie ze specyfikacją XDG, trzeba skopiować plik .desktop do odpowiedniego miejsca w /usr dla instalacji systemowej, lub w $HOME dla instalacji lokalnej. Ikony określonych rozmiarów, zgodnie ze specyfikacją XDG, muszą być umieszczone w określonych miejscach w usr lub $HOME, po czym trzeba uruchomić polecenia w środowisku roboczym, aby zaktualizować pamięć podręczną ikon lub liczyć na to, że menedżer środowiska roboczego zadziała i wszystko automatycznie wykryje. Podobnie z typami MIME. Jako obejście proponuje się użycie tej samej usługi, która poza ustawieniem atrybutu wykonywalności będzie, przy dostępności ikon itp. w AppImage, kopiować je z AppImage do odpowiednich miejsc zgodnie z XDG. Przy usunięciu lub przeniesieniu usługa zakłada, że wszystko posprząta. Oczywiście, istnieją różnice w zachowaniu w każdym środowisku roboczym, w formatach plików graficznych, ich rozmiarach, miejscach przechowywania i metodach aktualizacji pamięci podręcznych, co rodzi problem. Krótko mówiąc, ta metoda to taki „tryb awaryjny”.
Jeśli powyższe jest niewystarczające, w menedżerze plików wciąż brakuje ikony AppImage. W świecie Linuxa do tej pory nie podjęto decyzji o wdrożeniu elficon (mimo że omawianie i implementacji), więc nie można bezpośrednio wstawić ikony do aplikacji. W ten sposób aplikacje w menedżerze plików nie mają własnych ikon (bez względu na to, czy to AppImage, czy coś innego), istnieją one tylko w menu uruchamiania. Zamiast tego stosujemy miniatury — mechanizm zaprojektowany pierwotnie w celu umożliwienia menedżerom pulpitu wyświetlania zmniejszonych obrazów do podglądu plików graficznych jako ich ikon. W związku z tym usługa do ustawiania bitu wykonywalności działa również jako „miniaturyzator”, tworząc i zapisując miniatury ikon w odpowiednich miejscach /usr i $HOME. Ta usługa wykonuje również czyszczenie, gdy AppImage jest usuwane lub przenoszone. Ponieważ każdy menedżer pulpitu zachowuje się nieco inaczej, na przykład w jakich formatach akceptuje ikony, w jakich rozmiarach lub miejscach, to wszystko jest naprawdę męczące.
Aplikacja po prostu się zawiesza, jeśli wystąpią błędy (na przykład, jeśli występuje biblioteka, która nie jest częścią systemu bazowego i nie jest dostarczana z AppImage), a nikt nie informuje użytkownika w GUI, co się dzieje. Zaczęliśmy to omijać, używając powiadomienia na pulpicie, co oznacza, że musimy łapać błędy z wiersza poleceń, przekształcać je w zrozumiałe dla użytkownika komunikaty, które następnie musimy wyświetlić na pulpicie. Oczywiście każde środowisko graficzne obsługuje je nieco inaczej.
Na chwilę obecną (wrzesień 2019 r. — przyp. tłumacza) nie znalazłem prostego sposobu, aby powiedzieć systemowi, że plik 1.png powinien być otwierany za pomocą Krita, a 2.png — za pomocą GIMP.

Miejscem przechowywania specyfikacji cross-desktop, stosowanych w GNOME, KDE i Xfce jest freedesktop.org

Osiągnięcie wyrafinowania, głęboko wpisanego w środowisko Haiku, jest utrudnione, jeśli nie powiedzieć „niemożliwe”, z powodu specyfikacji XDG od freedesktop.org dla cross-desktop oraz realizacji menedżerów pulpitu opartych na tych specyfikacjach. Na przykład, wspólna ikona systemowa Firefox: wydaje się, że autorzy XDG nie pomyśleli, że użytkownik może mieć zainstalowane kilka wersji tej samej aplikacji.

Ikony różnych wersji Firefox

Zastanawiało mnie, czego świat Linux mógłby nauczyć się od Mac OS X, aby uniknąć problemów przy integracji systemów. Jeśli masz czas i zajmujesz się tym — koniecznie przeczytaj, co powiedział Arno Gurdol, jeden z pierwszych inżynierów Mac OS X:

Chcieliśmy, aby instalacja aplikacji była tak prosta, jak przeciągnięcie ikony aplikacji z dowolnego miejsca (serwer, dysk zewnętrzny) na dysk twojego komputera. W tym celu w paczce aplikacji zawarta jest cała informacja, w tym ikony, wersja, obsługiwany typ pliku, typ schematu URL, który system musi znać do obsługi aplikacji. Dotyczy to także informacji dla 'centralnego magazynu' w bazie danych Icon Services i Launch Services. Aby wspierać wydajność aplikacji, 'rozpoznawane' są w kilku 'dobrze znanych' miejscach: w katalogach systemowych i użytkownika Applications, oraz w niektórych innych automatycznie, jeśli użytkownik przeszedł do Findera w katalogu, który zawiera aplikację. W praktyce działa to bardzo dobrze.

https://youtu.be/qQsnqWJ8D2c
Sesja 144 Apple WWDC 2000 — Mac OS X: pakowanie aplikacji i drukowanie dokumentów.

Nie ma nic podobnego z tej infrastruktury w środowiskach roboczych Linux, dlatego szukamy obejść dla ograniczeń strukturalnych w projekcie AppImage.

Czy Haiku spieszy na ratunek?

I jeszcze: platformy Linux jako baza środowisk roboczych są na ogół tak niedostatecznie określone, że wiele rzeczy, które są stosunkowo proste w spójnym systemie z pełnym stosem, rozczarowują fragmentacją i złożonością w Linuxie. Poświęciłem całe wystąpienie zagadnieniom związanym z platformą Linux dla środowisk roboczych (znający deweloperzy potwierdzili: tak pozostanie jeszcze przez długi czas).

Moje wystąpienie na temat problemów środowisk roboczych Linux w 2018 roku

Nawet Linus Torvalds przyznał, że to właśnie przez fragmentację pomysł na środowiska robocze się nie powiódł.

Miło widzieć Haiku!

Z Haiku wszystko staje się niesamowicie proste

Choć naiwne podejście do przenoszenia AppImage na Haiku polega na prostym próbie kompilacji (głównie runtime.c i usługi) jego komponentów (co może być nawet możliwe!), to nie przyniesie to specjalnych korzyści dla Haiku. Ponieważ w rzeczywistości większość tych problemów została rozwiązana w Haiku i jest koncepcyjnie uzasadniona. Haiku dostarcza dokładnie tych składników do infrastruktury systemowej, których tak długo szukałem w środowiskach roboczych na Linuxie i nie mogłem uwierzyć, że ich tam nie ma. A konkretnie:

Uwierz lub nie, ale wielu użytkowników Linuxa nie potrafi się z tym uporać. W Haiku wszystko dzieje się automagicznie!

Pliki ELF, które nie mają bitu wykonywalności, otrzymują go automatycznie przy podwójnym kliknięciu w menedżerze plików.
Aplikacje mogą mieć wbudowane zasoby, takie jak ikony, które wyświetlane są w menedżerze plików. Nie trzeba kopiować mnóstwa obrazów do specjalnych katalogów z ikonami, a więc nie ma potrzeby ich sprzątania po usunięciu lub przeniesieniu aplikacji.
Istnieje baza danych do powiązania aplikacji z dokumentami, nie ma potrzeby kopiowania jakichkolwiek plików dla tego.
W katalogu lib/ obok pliku wykonywalnego biblioteki są domyślnie poszukiwane.
Nie ma wielu dystrybucji i środowisk graficznych, wszystko, co działa — działa wszędzie.
Nie ma osobnego modułu do uruchamiania, który różniłby się od katalogu Applications.
Aplikacje nie mają wbudowanych absolutnych ścieżek do swoich zasobów, są specjalne funkcje do określania lokalizacji w czasie wykonywania.
Wprowadzona idea skompresowanych obrazów systemów plików: to każdy pakiet hpkg. Wszystkie są montowane przez jądro.
Każdy plik jest otwierany przez aplikację, która go stworzyła, o ile wyraźnie nie zaznaczono inaczej. Jakże to wspaniałe!

Dwa pliki png. Zwróć uwagę na różne ikony, które pokazują, że będą otwierane przez różne aplikacje po podwójnym kliknięciu. Zwróć także uwagę na rozwijane menu „Otwórz za pomocą:”, gdzie użytkownik może wybrać konkretną aplikację. Jak prosto!

Wydaje się, że wiele sztuczek i obejść, które są potrzebne AppImage na Linuxie, staje się zbędnych na Haiku, posiadając prostotę i wyrafinowanie, dzięki którym spełnia większość naszych potrzeb.

Czy Haiku potrzebuje w końcu pakietów aplikacji?

To prowadzi do dużego pytania. Jeśli stworzenie systemu podobnego do AppImage na Haiku byłoby znacznie prostsze niż na Linuxie, czy warto się tym zająć? A może Haiku ze swoim systemem pakietów hpkg faktycznie wyeliminowało potrzebę rozwijania podobnej idei? Cóż, aby odpowiedzieć, trzeba spojrzeć na motywację istnienia AppImages.

Perspektywa użytkownika

Przyjrzyjmy się naszemu końcowemu użytkownikowi:

Chcę zainstalować aplikację bez żądania hasła administratora (root). Na Haiku nie ma pojęcia administratora, użytkownik ma pełną kontrolę, ponieważ jest to system osobisty! (W zasadzie można to sobie wyobrazić także w trybie wieloużytkownikowym, mam nadzieję, że programiści zachowają prostotę)
Chcę otrzymywać najnowsze i najlepsze wersje aplikacji, nie czekać, aż pojawią się w moim dystrybucji (zazwyczaj oznacza to "nigdy", przynajmniej jeśli nie zaktualizuję całego systemu operacyjnego). Na Haiku to jest „rozwiązane” za pomocą wersji pływających. Oznacza to, że istnieje możliwość otrzymywania najnowszych i najlepszych wersji aplikacji, ale wymaga to ciągłego aktualizowania reszty systemu, faktycznie zmieniając go w „ruchomy cel”..
Chciałbym mieć kilka wersji tej samej aplikacji obok siebie, ponieważ nie można wiedzieć, co zostało zepsute w najnowszej wersji, lub na przykład, jako web developer, muszę sprawdzić swoją pracę w różnych wersjach przeglądarki. Na Haiku rozwiązano pierwszy problem, ale nie drugi. Aktualizacje można cofnąć, ale tylko dla całego systemu, nie można (o ile mi wiadomo) uruchomić na przykład kilku wersji WebPositive lub LibreOffice jednocześnie.

Jeden z programistów pisze:

W zasadzie uzasadnienie jest takie: scenariusz użycia jest na tyle rzadki, że optymalizacja pod niego nie ma sensu; obsługa go jako przypadku szczególnego w HaikuPorts wydaje się więcej niż akceptowalna.

Muszę przechowywać aplikacje tam, gdzie mi się podoba, a nie na dysku rozruchowym. Na dyskach często brakuje mi miejsca, więc muszę podłączyć zewnętrzny dysk lub katalog sieciowy do przechowywania aplikacji (wszystkich wersji, które pobrałem). Jeśli podłączam taki dysk — muszę, aby aplikacje uruchamiały się po podwójnym kliknięciu. Haiku przechowuje stare wersje pakietów, ale nie wiem, jak je przenieść na zewnętrzny dysk i jak później uruchamiać aplikacje stamtąd.

Komentarz dewelopera:

Technicznie, to już możliwe z użyciem polecenia mount. Oczywiście, stworzymy GUI do tego, gdy tylko zbierze się wystarczająco zainteresowanych użytkowników.

Nie potrzebuję milionów plików rozsianych po systemie plików, którymi nie mogę zarządzać samodzielnie. Chcę jeden plik na aplikację, który mogę łatwo pobrać, przenieść lub usunąć. Na Haiku ten problem rozwiązano za pomocą paczek .hpkg, które przenoszą na przykład Python z tysięcy plików do jednego. Ale jeśli jest na przykład Scribus, który używa Pythona, to muszę mieć do czynienia przynajmniej z dwoma plikami. I muszę zadbać o to, aby zachować ich działające wersje.

Wielokrotne wersje AppImages uruchomione obok siebie na jednym Linuksie

Perspektywa dewelopera aplikacji

Przyjrzyjmy się z perspektywy dewelopera aplikacji:

Chcę w pełni zarządzać doświadczeniem użytkownika. Nie chcę polegać na systemie operacyjnym, który powie mi, kiedy i jak powinienem wydawać aplikacje. Na Haiku deweloperzy mogą pracować ze swoimi własnymi repozytoriami hpkg, ale oznacza to, że użytkownicy będą musieli skonfigurować je ręcznie, co sprawia, że ta idea jest „mniej atrakcyjna”.
Mam stronę pobierania na mojej stronie internetowej, gdzie dystrybuuję .exe dla Windows, .dmg dla Maca i .AppImage dla Linuxa. A może zechcę zmonetyzować dostęp do tej strony, wszystko może się zdarzyć? Co powinienem tam umieścić dla Haiku? Wystarczy plik .hpkg z zależnościami tylko od HaikuPorts
Moje oprogramowanie wymaga określonych wersji innego oprogramowania. Na przykład wiadomo, że dla Krita potrzebna jest poprawiona wersja Qt lub Qt, która jest dokładnie dostosowana do konkretnej wersji Krita, przynajmniej dopóki poprawki nie wrócą do Qt. Można zapakować własne Qt dla aplikacji w pakiecie .hpkg, ale prawdopodobnie czegoś takiego nie przyjmuje się zbyt entuzjastycznie.

Zwykła strona pobierania aplikacji. Co powinno się tutaj znaleźć dla Haiku?

Czy zestawy (istniejące w postaci katalogów aplikacji, jak AppDir lub .app w stylu Apple) i/lub obrazy (w postaci mocno zmodyfikowanych AppImages lub .dmg Czy aplikacje od Apple będą przydatnym dodatkiem do środowiska roboczego Haiku? A może zaburzą spójną wizję i doprowadzą do fragmentacji, co z kolei skomplikuje całość? Jestem rozdarty: z jednej strony, piękno i wyrafinowanie Haiku opierają się na tym, że zazwyczaj istnieje jeden sposób na zrobienie czegoś, a nie wiele. Z drugiej strony, znaczna część infrastruktury dla katalogów i/lub zestawów aplikacji jest już na miejscu, więc system wzywa do uzupełnienia pozostałych kilku procent.

Według dewelopera mr. waddlesplash

Na Linuxie one (katalogi i zestawy aplikacji — przyp. tłumacza) są prawdopodobnie technicznym rozwiązaniem problemów systemowych. W Haiku wolimy po prostu rozwiązywać problemy systemowe.

A co wy myślicie?

Zanim odpowiecie…

Poczekajcie, zróbmy szybki test rzeczywistości: w rzeczywistości katalogi aplikacji — są już częścią Haiku:

Katalogi aplikacji już istnieją w Haiku, ale na razie nie są wspierane w menedżerze plików.

Nie są tak dobrze wspierane, jak na przykład w Finderze Macintosh. Jakby to było super, gdyby katalog QtCreator miał w lewym górnym rogu nazwę i ikonę 'QtCreator', uruchamiającą aplikację podwójnym kliknięciem?

Trochę wcześniej już pytałem:

Czy jesteście pewni, że uruchomicie swoje aplikacje sprzed dekady dzisiaj, kiedy wszystkie sklepy z aplikacjami i repozytoria dystrybucji zapomną o nich i ich zależnościach? Czy jesteście pewni, że w przyszłości wciąż będziecie mieć dostęp do swojej obecnej pracy?

Czy już jest odpowiedź ze strony Haiku, czy katalogi i zestawy aplikacji mogą w tym pomóc? Myślę, że mogą.

Według pana waddlesplasha:

Tak, mamy odpowiedź na to pytanie: po prostu będziemy wspierać te aplikacje tak długo, jak to konieczne, aż ktoś będzie w stanie właściwie odczytać ich formaty plików lub zapewnić funkcjonalność jeden do jednego. Nasze dążenie do wsparcia aplikacji BeOS R5 na Haiku jest tego bezpośrednim dowodem…

Dokładnie!

Jaki plan działania powinna przyjąć Haiku?

Mogę sobie wyobrazić pokojowe współistnienie hpkg, katalogów i obrazów aplikacji:

Oprogramowanie systemowe korzysta z .hpkg
Najczęściej używane oprogramowanie (szczególnie to, które musi planować płynne wydania) korzysta z .hpkg (około 80% wszystkich przypadków)
Niektóre, zainstalowane przez .hpkg, aplikacje zyskają na przejściu na infrastrukturę z katalogami aplikacji (na przykład, QtCreator): będą one dystrybuowane w formie .hpkg, tak jak wcześniej.

mr. waddlesplash pisze:

Jeśli wszystko, czego potrzebujesz, to przeglądanie aplikacji w /system/apps, zamiast tego należy uczynić katalogi w Deskbar bardziej zarządzalnymi dla użytkowników, ponieważ /system/apps nie jest przeznaczony do tego, aby użytkownicy regularnie go otwierali i oglądali (w przeciwieństwie do MacOS). W takich sytuacjach Haiku ma inną paradygmat, ale ta opcja jest, w teorii, akceptowalna.

Haiku zyskuje infrastrukturę do uruchamiania obrazów aplikacji, nocnych, ciągłych i testowych kompilacji oprogramowania, a także w sytuacjach, gdy użytkownik chce je 'zamrozić w czasie', dla prywatnych i wewnętrznych aplikacji oraz innych szczególnych przypadków użycia (około 20% ze wszystkich). Te obrazy zawierają pliki niezbędne do uruchamiania aplikacji .hpkg, montowane za pomocą systemu, a po zakończeniu aplikacji — odmontowywane. (Możliwe, że menedżer plików mógłby umieszczać pliki .hpkg w obrazach aplikacji, automatycznie lub na żądanie użytkownika — no, jak podczas przeciągania aplikacji do katalogu sieciowego lub na dysk zewnętrzny. To po prostu pieśń! A dokładniej poezja — haiku.) Z drugiej strony, użytkownik może zechcieć zainstalować zawartość obrazu jako pliki.hpkg, po czym będą one aktualizowane i przetwarzane dokładnie tak, jakby zostały zainstalowane przez HaikuDepot… Trzeba przeprowadzić burzę mózgów).

Cytat od mr. waddlesplash:

Uruchamianie aplikacji z dysków zewnętrznych lub katalogów sieciowych może być potencjalnie przydatne. A dodanie możliwości dostosowania większej liczby 'stref' dla pkgman z pewnością będzie dobrą funkcją.

Taki system będzie wykorzystywał zalety hpkg, katalogów i obrazów aplikacji. One są dobre osobno, ale razem staną się niepokonane.

Podsumowanie

Dla Haiku istnieje infrastruktura, która zapewnia prosty i wyszukany interfejs użytkownika dla komputerów PC, znacznie wykraczający poza to, co zazwyczaj oferuje się dla komputerów PC pracujących na Linuksie. System pakietów .hpkg — jeden z takich przykładów, ale pozostałe części systemu również są pełne wyrafinowania. Niemniej jednak, Haiku zyskałoby na odpowiednim wsparciu dla katalogów i pakietów aplikacji. Jak najlepiej to zrobić — warto przedyskutować z osobami, które znają Haiku, jej filozofię i architekturę znacznie lepiej niż ja. W końcu korzystam z Haiku nieco ponad tydzień. Niemniej jednak, jestem przekonany, że to świeże spojrzenie okaże się przydatne dla projektantów, programistów i architektów Haiku. Przynajmniej chętnie zostanę ich „sparingpartnerem”. Mam ponad 10-letnie doświadczenie w pracy z katalogami i zestawami aplikacji dla Linuxa, i chciałbym znaleźć dla nich zastosowanie w Haiku, dla którego, moim zdaniem, pasują idealnie. Proponowane przeze mnie potencjalne rozwiązania wcale nie są jedynymi słusznymi dla problemów, które opisałem, a jeśli zespół Haiku zdecyduje się znaleźć inne, bardziej eleganckie — jestem tylko za. W zasadzie już rozważam pomysł, jak stworzyć system hpkg jeszcze bardziej niezwykłym, nie zmieniając jego działania. Okazuje się, że zespół Haiku od dawna myślał o zestawach aplikacji przy wdrażaniu systemu zarządzania pakietami, ale niestety, (jak mi się wydaje) pomysł ten przeszedł w „zapomnienie”. Może nadszedł czas, aby go ożywić?

Spróbuj sam! Projekt Haiku udostępnia obrazy do uruchamiania z DVD lub USB, tworzone codziennie.
Masz pytania? Zapraszamy do naszego rosyjskojęzycznego kanału telegramowego..

Przegląd błędów: Jak strzelić sobie w stopę w C i C++. Zbiór przepisów Haiku OS

Od autora tłumaczenia: to ósmy i ostatni artykuł z cyklu o Haiku.

Lista artykułów: Pierwsza Drugi Trzeci Czwarty Piąty Szósty Siódmy

Tylko zarejestrowani użytkownicy mogą brać udział w ankiecie. Zaloguj się, proszę.