TL; DR: Czy Haiku może uzyskać odpowiednie wsparcie dla pakietów aplikacji, takich jak katalogi aplikacji (np .app na komputerze Mac) i/lub obrazy aplikacji (Linux AppImage)? Myślę, że byłby to godny dodatek, który jest łatwiejszy do prawidłowego wdrożenia niż inne systemy, ponieważ większość infrastruktury jest już na miejscu.
Odkryłem Haiku, niespodziewanie dobry system. No cóż, skoro od dawna interesują mnie katalogi i obrazy aplikacji (inspirowane prostotą Macintosha), nic dziwnego, że przyszedł mi do głowy pomysł...
Dla pełnego zrozumienia jestem twórcą i autorem AppImage, formatu dystrybucji aplikacji dla systemu Linux, który ma na celu prostotę komputerów Mac i daje pełną kontrolę autorom aplikacji i użytkownikom końcowym (jeśli chcesz dowiedzieć się więcej, zobacz и ).
A co jeśli stworzymy AppImage dla Haiku?
Zastanówmy się trochę, czysto teoretycznie: co trzeba zrobić, żeby dostać lub coś podobnego na Haiku? Nie trzeba od razu czegoś tworzyć, bo system, który już istnieje w Haiku, działa niesamowicie, ale przydałby się wyimaginowany eksperyment. Pokazuje to także wyrafinowanie Haiku w porównaniu do środowisk desktopowych Linux, gdzie takie rzeczy są strasznie trudne (mam prawo tak twierdzić: walczę z debugowaniem od 10 lat).
Na komputerze Macintosh System 1 każda aplikacja była oddzielnym plikiem „zarządzanym” w Finderze. Używając AppImage Próbuję odtworzyć to samo doświadczenie użytkownika w systemie Linux.
Po pierwsze, czym jest AppImage? Jest to system udostępniania aplikacji innych firm (np. ), umożliwiając wydawanie aplikacji kiedy chcą i jak chcą: nie trzeba znać specyfiki różnych dystrybucji, budować polityk ani budować infrastruktury, nie jest potrzebne wsparcie opiekuna i nie mówią użytkownikom, co (nie) mogą zainstalować na swoich komputerach. Przez AppImage należy rozumieć coś na wzór pakietu Mac w formacie .app wewnątrz obrazu dysku .dmg. Główną różnicą jest to, że aplikacje nie są kopiowane, lecz pozostają na zawsze w AppImage, podobnie jak pakiety Haiku .hpkg zamontowane i nigdy nie zainstalowane w zwykłym tego słowa znaczeniu.
W ciągu ponad 10 lat istnienia AppImage zyskał pewien urok i popularność: sam Linus Torvalds publicznie go poparł, a popularne projekty (na przykład LibreOffice, Krita, Inkscape, Scribus, ImageMagick) przyjęły go jako główny sposób do dystrybucji kompilacji ciągłych lub nocnych, bez zakłócania zainstalowanych lub odinstalowanych aplikacji użytkownika. Jednak środowiska graficzne i dystrybucje Linuksa najczęściej nadal trzymają się tradycyjnego, scentralizowanego modelu dystrybucji opartego na opiekunach i/lub promują własne programy biznesowe i/lub inżynieryjne dla przedsiębiorstw oparte na (RedHat, Fedora, GNOME) i (Kanoniczny, Ubuntu). Nadchodzi .
Jak to działa
- Każdy AppImage składa się z 2 części: małego ELF z podwójnym kliknięciem (tzw.
runtime.c), po którym następuje obraz systemu plików .
- System plików SquashFS zawiera ładunek aplikacji i wszystko, co potrzebne do jej uruchomienia, czego przy zdrowych zmysłach nie można uważać za część domyślnej instalacji dla każdego całkiem nowego systemu docelowego (dystrybucja Linuksa). Zawiera także metadane, takie jak nazwa aplikacji, ikony, typy MIME itp. itp.
- Uruchomione przez użytkownika środowisko wykonawcze używa FUSE i squashfuse do zamontowania systemu plików, a następnie obsługuje uruchomienie punktu wejścia (inaczej AppRun) wewnątrz zamontowanego AppImage.
System plików zostanie odmontowany po zakończeniu procesu.
Wszystko wydaje się proste.
A te rzeczy wszystko komplikują:
- Przy tak dużej różnorodności dystrybucji Linuksa niczego „przy zdrowych zmysłach” nie można nazwać „częścią domyślnej instalacji każdego nowego systemu docelowego”. Obchodzimy ten problem, budując , co pozwala określić, co zostanie spakowane w AppImage, a co trzeba będzie zabrać gdzie indziej. Jednocześnie czasami tęsknimy, mimo że generalnie wszystko działa świetnie. Z tego powodu zalecamy twórcom pakietów przetestowanie AppImages na wszystkich systemach docelowych (dystrybucjach).
- Ładunki aplikacji muszą umożliwiać relokację w całym systemie plików. Niestety wiele aplikacji ma zakodowane na stałe ścieżki bezwzględne do, na przykład, zasobów w
/usr/share. Trzeba to jakoś naprawić. Ponadto musisz albo wyeksportowaćLD_LIBRARY_PATHlub naprawrpathaby moduł ładujący mógł znaleźć powiązane biblioteki. Pierwsza metoda ma swoje wady (które można pokonać w skomplikowany sposób), druga jest po prostu uciążliwa. - Największą pułapką UX dla użytkowników jest to Plik AppImage po pobraniu. Wierzcie lub nie, ale dla niektórych jest to prawdziwa bariera. Konieczność ustawienia bitu wykonywalności jest uciążliwa nawet dla doświadczonych użytkowników. Jako obejście zasugerowaliśmy zainstalowanie małej usługi, która monitoruje pliki AppImage i ustawia ich bit wykonywalności. W czystej postaci nie jest to najlepsze rozwiązanie, ponieważ nie będzie działać od razu po wyjęciu z pudełka. Dystrybucje Linuksa nie zapewniają tej usługi, dlatego użytkownicy mają złe doświadczenia po wyjęciu z pudełka.
- Użytkownicy Linuksa oczekują, że nowa aplikacja będzie miała ikonę w menu startowym. Nie możesz powiedzieć systemowi: „Słuchaj, jest nowa aplikacja, działajmy”. Zamiast tego, zgodnie ze specyfikacją XDG, należy skopiować plik
.desktopwe właściwym miejscu/usrw przypadku instalacji obejmującej cały system lub w$HOMEdla indywidualnych. Ikony o określonych rozmiarach, zgodnie ze specyfikacją XDG, należy umieścić w określonych miejscachusrlub$HOME, a następnie uruchom polecenia w środowisku roboczym, aby zaktualizować pamięć podręczną ikon, lub miej nadzieję, że menedżer środowiska pracy to rozwiąże i automatycznie wszystko wykryje. To samo z typami MIME. Jako obejście proponuje się skorzystanie z tej samej usługi, która oprócz ustawienia flagi wykonywalności, jeśli będą ikony itp. w AppImage skopiuj je z AppImage w odpowiednie miejsca zgodnie z XDG. Oczekuje się, że po usunięciu lub przeniesieniu usługa wszystko wyczyści. Oczywiście istnieją różnice w zachowaniu każdego środowiska pracy, w formatach plików graficznych, ich rozmiarach, lokalizacjach przechowywania i metodach aktualizacji pamięci podręcznych, co stwarza problem. Krótko mówiąc, ta metoda jest kulą. - Jeśli powyższe nie wystarczy, w menedżerze plików nadal nie ma ikony AppImage. Świat Linuksa nie zdecydował się jeszcze na wdrożenie elficon (pomimo и ), dlatego nie ma możliwości osadzenia ikony bezpośrednio w aplikacji. Okazuje się więc, że aplikacje w menedżerze plików nie mają własnych ikon (bez różnicy, AppImage czy coś innego), są one jedynie w menu startowym. Jako obejście tego problemu używamy miniatur – mechanizmu, który pierwotnie został zaprojektowany, aby umożliwić menedżerom komputerów wyświetlanie miniaturowych obrazów podglądu plików graficznych jako ich ikon. W związku z tym usługa ustawiania bitu wykonywalności działa również jako „miniaturyzator”, tworząc i zapisując miniatury ikon w odpowiednich lokalizacjach
/usrи$HOME. Ta usługa wykonuje również czyszczenie, jeśli AppImage zostanie usunięty lub przeniesiony. Z uwagi na to, że każdy menedżer pulpitu zachowuje się nieco inaczej, np. w jakich formatach akceptuje ikony, w jakich rozmiarach czy miejscach, jest to wszystko naprawdę bolesne. - Aplikacja po prostu zawiesza się podczas wykonywania, jeśli wystąpią błędy (na przykład istnieje biblioteka, która nie jest częścią systemu bazowego i nie jest dostarczana w AppImage) i nikt nie mówi użytkownikowi w interfejsie GUI, co dokładnie się dzieje. Zaczęliśmy sobie z tym radzić, używając na pulpicie, co oznacza, że musimy wyłapać błędy z linii poleceń, przekonwertować je na zrozumiałe dla użytkownika komunikaty, które następnie trzeba wyświetlić na pulpicie. I oczywiście każde środowisko graficzne obsługuje je nieco inaczej.
- W tej chwili (wrzesień 2019 - przyp. tłumacza) nie znalazłem prostego sposobu, aby poinformować system, że plik
1.pngnależy otworzyć za pomocą Krita i2.png- za pomocą GIMP-a.
Miejsce przechowywania specyfikacji dla różnych komputerów używanych w , и to freedesktop.org
Osiągnięcie poziomu wyrafinowania głęboko wplecionego w środowisko pracy Haiku jest trudne, jeśli nie niemożliwe, ze względu na specyfikacje dla komputerów typu cross-desktop, a także implementacje menedżerów komputerów stacjonarnych oparte na tych specyfikacjach. Jako przykład możemy przytoczyć jedną ogólnosystemową ikonę Firefoksa: najwyraźniej autorzy XDG nawet nie pomyśleli, że użytkownik może mieć zainstalowanych kilka wersji tej samej aplikacji.
Ikony dla różnych wersji Firefoksa
Zastanawiałem się, czego świat Linuksa mógłby się nauczyć od Mac OS X, aby uniknąć schrzanienia integracji systemu. Jeśli masz czas i interesujesz się tym, koniecznie przeczytaj, co powiedział Arnaud 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 skądś (serwer, dysk zewnętrzny) na dysk komputera. Aby to zrobić, pakiet aplikacji przechowuje wszystkie informacje, w tym ikony, wersję, typ przetwarzanego pliku, typ schematów adresów URL, które system musi znać, aby przetworzyć aplikację. Obejmuje to również informacje dotyczące „centralnego magazynu” w bazie danych Icon Services i Launch Services. Aby zwiększyć wydajność, aplikacje są „wykrywane” w kilku „dobrze znanych” miejscach: w katalogach aplikacji systemu i użytkownika, a także w innych automatycznie, jeśli użytkownik przejdzie do Findera w katalogu zawierającym aplikację. W praktyce sprawdziło się to bardzo dobrze.
Sesja 2000 Apple WWDC 144 – Mac OS X: pakowanie aplikacji i drukowanie dokumentów.
Nie ma nic podobnego do tej infrastruktury na komputerach stacjonarnych z systemem Linux, dlatego szukamy obejść ograniczeń strukturalnych w projekcie AppImage.
Czy Haiku przyjdzie na ratunek?
I jeszcze jedno: platformy Linux stanowiące podstawę środowisk graficznych są zwykle tak niedookreślone, że wiele rzeczy, które są całkiem proste w spójnym systemie z pełnym stosem, w Linuksie są frustrująco fragmentaryczne i złożone. Cały raport poświęciłem zagadnieniom związanym z platformą Linux dla środowisk desktopowych (doświadczony programiści potwierdzili, że wszystko tak pozostanie przez bardzo długi czas).
Mój raport na temat problemów środowisk desktopowych Linux w 2018 roku
Nawet Linus Torvalds przyznał, że fragmentacja była przyczyną niepowodzenia pomysłu na przestrzeń roboczą.
Miło zobaczyć Haiku!
Haiku sprawia, że wszystko jest niesamowicie proste
Choć naiwnym podejściem do „portowania” AppImage do Haiku jest po prostu próba zbudowania (głównie runtime.c i usługi) jego komponentów (co może być nawet możliwe!), nie przyniesie to Haiku zbyt wielu korzyści. Ponieważ tak naprawdę większość tych problemów została rozwiązana w Haiku i są one koncepcyjnie rozsądne. Haiku zapewnia dokładnie te elementy infrastruktury systemowej, których od tak dawna szukałem w środowiskach graficznych Linuksa i nie mogłem uwierzyć, że ich tam nie ma. Mianowicie:
Wierzcie lub nie, jest to coś, czego wielu użytkowników Linuksa nie jest w stanie pokonać. W Haiku wszystko dzieje się automatycznie!
- Pliki ELF, które nie mają bitu wykonywalności, otrzymują go automatycznie po dwukrotnym kliknięciu w menedżerze plików.
- Aplikacje mogą mieć wbudowane zasoby, takie jak ikony, które są wyświetlane w menedżerze plików. Nie ma potrzeby kopiowania serii obrazów do specjalnych katalogów z ikonami, a co za tym idzie, nie ma potrzeby ich czyszczenia po usunięciu lub przeniesieniu aplikacji.
- Istnieje baza danych umożliwiająca powiązanie wniosków z dokumentami, nie ma potrzeby kopiowania w tym celu żadnych plików.
- W katalogu lib/ obok pliku wykonywalnego domyślnie przeszukiwane są biblioteki.
- Nie ma wielu dystrybucji i środowisk graficznych; cokolwiek działa, działa wszędzie.
- Nie ma osobnego modułu do uruchomienia, różniącego się od katalogu Aplikacje.
- Aplikacje nie mają wbudowanych ścieżek bezwzględnych do swoich zasobów; posiadają specjalne funkcje umożliwiające określenie lokalizacji w czasie wykonywania.
- Wprowadzono pomysł skompresowanych obrazów systemów plików: jest to dowolny pakiet hpkg. Wszystkie są montowane przez jądro.
- Każdy plik jest otwierany przez aplikację, która go utworzyła, chyba że wyraźnie określisz inaczej. Jak fajne to jest!
Dwa pliki png. Zwróć uwagę na różne ikony wskazujące, że po dwukrotnym kliknięciu zostaną otwarte w różnych aplikacjach. Zwróć także uwagę na menu rozwijane „Otwórz za pomocą:”, w którym użytkownik może wybrać pojedynczą aplikację. Jakie to proste!
Wygląda na to, że wiele podpór i obejść wymaganych przez AppImage w systemie Linux stało się niepotrzebnych w Haiku, którego podstawą jest prostota i wyrafinowanie, dzięki którym zaspokaja większość naszych potrzeb.
Czy w ogóle Haiku potrzebuje pakietów aplikacji?
Prowadzi to do dużego pytania. Gdyby stworzenie systemu takiego jak AppImage na Haiku było o rząd wielkości łatwiejsze niż na Linuksie, czy warto byłoby to zrobić? A może Haiku, dzięki systemowi pakietów hpkg, skutecznie wyeliminowało potrzebę rozwijania takiego pomysłu? Cóż, aby odpowiedzieć, musimy przyjrzeć się motywacji stojącej za istnieniem AppImages.
Perspektywa użytkownika
Przyjrzyjmy się naszemu użytkownikowi końcowemu:
- Chcę zainstalować aplikację bez pytania o hasło administratora (root). W Haiku nie ma koncepcji administratora, użytkownik ma pełną kontrolę, ponieważ jest to system osobisty! (Zasadniczo możesz to sobie wyobrazić w trybie wieloosobowym, mam nadzieję, że programiści utrzymają to w prostocie)
- Chcę otrzymywać najnowsze i najlepsze wersje aplikacji, nie czekając, aż pojawią się w mojej dystrybucji (najczęściej oznacza to „nigdy”, przynajmniej jeśli nie zaktualizuję całego systemu operacyjnego). W Haiku problem ten jest „rozwiązany” poprzez wydanie pływające. Oznacza to, że możliwe jest uzyskanie najnowszych i najlepszych wersji aplikacji, ale aby to zrobić, należy stale aktualizować resztę systemu, skutecznie zamieniając go w „ruchomy cel”.
- Chcę kilka wersji tej samej aplikacji obok siebie, ponieważ nie ma sposobu, aby dowiedzieć się, co zostało zepsute w najnowszej wersji, lub, powiedzmy, jako twórca stron internetowych muszę przetestować swoją pracę w różnych wersjach przeglądarki. Haiku rozwiązuje pierwszy problem, ale nie drugi. Aktualizacje są wycofywane, ale tylko dla całego systemu, nie da się (o ile mi wiadomo) uruchomić na przykład kilku wersji WebPositive czy LibreOffice jednocześnie.
Jeden z twórców pisze:
Zasadniczo uzasadnienie jest następujące: przypadek użycia jest tak rzadki, że optymalizacja pod jego kątem nie ma sensu; traktowanie tego jako szczególnego przypadku w HaikuPorts wydaje się więcej niż akceptowalne.
- Muszę przechowywać aplikacje tam, gdzie mi się podobają, a nie na dysku startowym. Często brakuje mi miejsca na dysku, więc muszę podłączyć dysk zewnętrzny lub katalog sieciowy, aby przechowywać aplikacje (wszystkie wersje, które pobrałem). Jeżeli podłączę taki dysk to muszę uruchamiać aplikacje poprzez dwukrotne kliknięcie. Haiku zapisuje stare wersje pakietów, jednak nie wiem jak je przenieść na dysk zewnętrzny, ani jak później uruchomić stamtąd aplikacje.
Komentarz dewelopera:
Technicznie jest to już możliwe za pomocą polecenia mount. Oczywiście stworzymy do tego GUI, gdy tylko będziemy mieć wystarczającą liczbę zainteresowanych użytkowników.
- Nie potrzebuję milionów plików rozproszonych po całym systemie plików, którymi nie mogę ręcznie zarządzać. Chcę mieć jeden plik na aplikację, który mogę łatwo pobrać, przenieść i usunąć. W Haiku problem ten rozwiązano za pomocą pakietów
.hpkg, które przenoszą na przykład Pythona z tysięcy plików do jednego. Ale jeśli jest na przykład Scribus korzystający z Pythona, to mam do czynienia z co najmniej dwoma plikami. Muszę też zadbać o to, aby zachować ich wersje, które ze sobą współpracują.
Wiele wersji AppImages działających obok siebie w tym samym systemie Linux
Perspektywa programisty aplikacji
Spójrzmy z punktu widzenia programisty aplikacji:
- Chcę kontrolować całe doświadczenie użytkownika. Nie chcę polegać na systemie operacyjnym, który będzie mi mówił, kiedy i jak mam udostępniać aplikacje. Haiku umożliwia programistom pracę z ich własnymi repozytoriami hpkg, ale oznacza to, że użytkownicy będą musieli je konfigurować ręcznie, co czyni pomysł „mniej atrakcyjnym”.
- Mam stronę pobierania na mojej stronie internetowej, gdzie rozpowszechniam
.exedla Windowsa,.dmgdla komputerów Mac i.AppImagedla Linuksa. A może chcę zarabiać na dostępie do tej strony, wszystko jest możliwe? Co mam tam umieścić do Haiku? Plik wystarczy.hpkgz zależnościami tylko od HaikuPorts - Moje oprogramowanie wymaga określonych wersji innego oprogramowania. Na przykład wiadomo, że Krita wymaga poprawionej wersji Qt lub Qt, która jest dostosowana do konkretnej wersji Krity, przynajmniej do czasu, aż łatki zostaną przeniesione z powrotem do Qt. Możesz spakować własny Qt dla swojej aplikacji w pakiecie
.hpkg, ale najprawdopodobniej nie jest to mile widziane.
Zwykła strona pobierania aplikacji. Co mam tu zamieścić w związku z Haiku?
Czy pakiety (istniejące jako katalogi aplikacji, takie jak AppDir lub .app w stylu Apple) i/lub obrazy (w postaci mocno zmodyfikowanych AppImages lub .dmg od Apple) są użytecznym dodatkiem do środowiska graficznego Haiku? A może rozmyje cały obraz i doprowadzi do fragmentacji, a co za tym idzie, doda złożoności? Jestem rozdarty: z jednej strony piękno i wyrafinowanie Haiku opiera się na fakcie, że zazwyczaj można coś zrobić w jeden sposób, a nie na wiele. Z drugiej strony większość infrastruktury katalogów i/lub pakietów aplikacji jest już gotowa, więc system woła o ułożenie pozostałych kilku procent.
Według dewelopera
W systemie Linux one (katalogi i zestawy aplikacyjne, - ok. tłumacz) są najprawdopodobniej technicznym rozwiązaniem problemów systemowych. W Haiku wolimy po prostu rozwiązywać problemy systemowe.
Co myślisz?
Zanim odpowiesz...
Czekaj, zróbmy szybki sprawdzian rzeczywistości: faktycznie katalogi aplikacji - już część Haiku:
Katalogi aplikacji już istnieją w Haiku, ale nie są jeszcze obsługiwane w menedżerze plików
Po prostu nie są tak dobrze obsługiwane, jak na przykład Macintosh Finder. Jak fajnie byłoby, gdyby katalog QtCreator miał nazwę i ikonę „QtCreator” w lewym górnym rogu, uruchamiającą aplikację po dwukrotnym kliknięciu?
Już trochę wcześniej :
Czy na pewno możesz dziś uruchamiać aplikacje sprzed dziesięciu lat, gdy wszystkie sklepy z aplikacjami i repozytoria dystrybucji zapomniały o nich i ich zależnościach? Czy masz pewność, że w przyszłości nadal będziesz mieć dostęp do swojej obecnej pracy?
Czy jest już odpowiedź od Haiku, czy mogą tu pomóc katalogi i pakiety aplikacji? Myślę, że mogą.
Według pana. plusk wody:
Tak, mamy odpowiedź na pytanie: będziemy po prostu wspierać te aplikacje tak długo, jak będzie to konieczne, dopóki ktoś nie będzie w stanie poprawnie odczytać ich formatów plików lub zapewnić funkcjonalność one-to-one. Nasze zaangażowanie we wspieranie aplikacji BeOS R5 na platformie Haiku jest tego dowodem…
To na pewno!
Jaki kierunek działania powinno obrać Haiku?
Mogę sobie wyobrazić pokojowe współistnienie hpkg, katalogów i obrazów aplikacji:
- Oprogramowanie systemowe wykorzystuje
.hpkg - W przypadku najczęściej używanego oprogramowania (szczególnie tego, które wymaga planowania wydań ciągłych), użyj
.hpkg(około 80% wszystkich przypadków) - Niektóre zainstalowane przez
.hpkg, aplikacje odniosą korzyści z przeniesienia do infrastruktury katalogów aplikacji (np. QtCreator): będą dystrybuowane jako.hpkg, jak wcześniej.
Pan. waddlesplash pisze:
Jeśli potrzebujesz tylko przeglądania aplikacji w
/system/apps, zamiast tego powinniśmy sprawić, aby katalogi w Deskbarze były łatwiejsze w zarządzaniu dla użytkowników, ponieważ/system/appsnie jest przeznaczony do regularnego otwierania i przeglądania przez użytkowników (w przeciwieństwie do MacOS). W takich sytuacjach Haiku ma inny paradygmat, ale ta opcja jest teoretycznie akceptowalna.
- Haiku otrzymuje infrastrukturę do uruchamiania obrazów aplikacji, nocnych, ciągłych i testowych kompilacji oprogramowania, a także na wypadek, gdy użytkownik chce „zamrozić w czasie”, dla oprogramowania prywatnego i wewnętrznego oraz innych specjalnych przypadków użycia (około 20% ze wszystkich). Obrazy te zawierają pliki niezbędne do uruchomienia aplikacji
.hpkg, montowane przez system, a po zakończeniu aplikacji - odmontowywane. (Być może menedżer plików mógłby umieścić pliki.hpkgdo obrazów aplikacji, automatycznie lub na żądanie użytkownika - cóż, tak jak podczas przeciągania aplikacji do katalogu sieciowego lub dysku zewnętrznego. To tylko piosenka! A raczej poezja – haiku.) Z drugiej strony użytkownik może chcieć zainstalować zawartość obrazu w postaci plików.hpkg, po czym zostaną zaktualizowane i przetworzone w taki sam sposób, jakby zostały zainstalowane przez HaikuDepot... Musimy przeprowadzić burzę mózgów).
Cytat od pana. plusk wody:
Uruchamianie aplikacji z dysków zewnętrznych lub katalogów sieciowych może być potencjalnie przydatne. A dodanie możliwości konfigurowania większej liczby „stref” dla pkgmana z pewnością byłoby fajną funkcją.
Taki system wykorzystywałby hpkg, katalogi i obrazy aplikacji. Są dobrzy indywidualnie, ale razem staną się niepokonani.
wniosek
Haiku ma strukturę, która zapewnia proste i wyrafinowane doświadczenie użytkownika na komputerze PC i wykracza daleko poza to, co jest zwykle dostarczane dla komputerów PC z systemem Linux. System pakietów .hpkg to jeden z takich przykładów, ale reszta systemu również jest przesiąknięta wyrafinowaniem. Jednak Haiku zyskałoby na odpowiedniej obsłudze katalogów i obrazów aplikacji. Jak najlepiej to zrobić, warto omówić z ludźmi, którzy znają Haiku, jego filozofię i architekturę znacznie lepiej niż ja. W końcu używam Haiku od nieco ponad tygodnia. Niemniej jednak wierzę, że projektanci, programiści i architekci Haiku skorzystają z tej świeżej perspektywy. Przynajmniej byłbym szczęśliwy, mogąc być ich „partnerem sparingowym”. Mam ponad 10 lat praktycznego doświadczenia z katalogami i pakietami aplikacji dla systemu Linux i chciałbym znaleźć dla nich zastosowanie w Haiku, do czego myślę, że idealnie pasują. Potencjalne rozwiązania, które zaproponowałem, nie są bynajmniej jedynymi właściwymi w przypadku opisanych przeze mnie problemów i jeśli zespół Haiku zdecyduje się znaleźć inne, bardziej eleganckie, jestem jak najbardziej za. W zasadzie już myślę o pomyśle jak zrobić system hpkg jeszcze bardziej niesamowite bez zmiany sposobu działania. Okazuje się, że zespół Haiku już od dawna myślał o pakietach aplikacji przy wdrażaniu systemu zarządzania pakietami, ale niestety (chyba) pomysł stał się „przestarzały”. Może czas go ożywić?
Spróbuj sam! W końcu projekt Haiku udostępnia generowane obrazy do rozruchu z DVD lub USB .
Czy masz jakieś pytania? Zapraszamy na zajęcia rosyjskojęzyczne .
Przegląd błędów:
Od tłumaczenie: to ósmy i ostatni artykuł z serii o Haiku.
Lista artykułów:
W ankiecie mogą brać udział tylko zarejestrowani użytkownicy. , Proszę.
Czy jest sens przenosić system hpkg na Linuksa?
-
Tak
-
Nie
-
Już wdrożone, napiszę w komentarzach
Głosowało 20 użytkowników. 5 użytkowników wstrzymało się od głosu.
Źródło: www.habr.com