TL;DR: Haiku — system operacyjna zaprojektowana specjalnie dla komputerów PC, dlatego ma kilka sztuczek, które sprawiają, że jej środowisko pracy jest znacznie lepsze niż inne. Jak to działa?
Odkryłem Haiku, zaskakująco dobrą system. Nadal jestem pod wrażeniem, jak gładko działa, szczególnie w porównaniu z środowiskami pracy w Linuksie. Dziś zajrzę pod maskę. Tam, gdzie będzie to konieczne dla głębszego zrozumienia, porównam je z oryginalnym Macintosh, Mac OS X i środowiskami pracy Linuxa (standard XDG od freedesktop.org).
Zasoby w plikach ELF
Wczoraj dowiedziałem się, że IconOMatic potrafi zapisywać ikony w zasobach rdef w plikach wykonywalnych ELF. Dziś chcę zobaczyć, jak to naprawdę działa.
Zasoby? od , pierwotny twórca programu Macintosh Finder i „ojciec” Macintosh Resource Manager:
Niepokoi mnie sztywny charakter tradycyjnego pisania kodu. Dla mnie sama idea aplikacji zamkniętej w kodzie, bez możliwości zmiany czegokolwiek dynamicznie — to ogromny absurd. Powinna istnieć możliwość zmiany jak największej liczby elementów w czasie wykonywania. Oczywiście sam kod aplikacji nie może być zmieniony, ale przecież coś można zmienić bez ponownego kompilowania kodu?
W oryginalnym Macintoshie zrobiono tak, że te pliki mają „sekcję danych” i „sekcję zasobów”, co niezwykle ułatwiło przechowywanie różnych rzeczy, na przykład ikon, tłumaczeń itp. w plikach wykonywalnych.
Na Macu do tego używa się , graficznego programu do — niespodzianka — edytowania zasobów.
ResEdit na oryginalnym Macintoshu
Dzięki temu możliwe stało się łatwe edytowanie ikon, pozycji w menu, tłumaczeń itp., jednak nadal „podróżują” one z aplikacjami.
W każdym razie takie podejście miało poważną wadę: działało tylko na systemach plików Apple, co było jedną z przyczyn, dla których Apple zrezygnowało z „sekcji zasobów” przy przejściu na Mac OS X.
Na Mac OS X Apple chciało rozwiązania niezależnego od systemu plików, dlatego zastosowano koncepcję pakietów (z NeXT), katalogów, które menedżer plików traktuje jako „nieprzezroczyste obiekty”, podobnie jak pliki, a nie katalogi. Każdy pakiet z aplikacją w formacie .app zawiera, między innymi, plik Info.plist (w pewnym odpowiedniku JSON lub YAML od Apple), zawierający metadane aplikacji.
Klucze pliku Info.plist z pakietu aplikacji Mac OS X.
Zasoby, takie jak ikony, pliki UI i inne, są przechowywane w pakiecie w postaci plików. Koncepcja ta w zasadzie powróciła do swoich korzeni w NeXT.
Mathematica.app na NeXTSTEP 1.0 w 1989 roku: wyświetlana jako katalog z plikami w terminalu, ale jako jeden obiekt w graficznym menedżerze plików.
Wracamy do BeOS, na podstawie którego oparta jest Haiku. Jej twórcy, przy przejściu z PEF (PowerPC) na ELF (x86) (ten sam, który używany jest w Linuksie), postanowili dodać sekcję zasobów na końcu plików ELF. Nie używano do tego własnej odpowiedniej sekcji ELF, po prostu dopisywano ją na końcu pliku ELF. W rezultacie programy strip i inne z binutils, nieświadome tego, po prostu ją przycinały. Dlatego lepiej nie pracować z plikami ELF na BeOS, dodając zasoby przy użyciu narzędzi Linuksa.
A co teraz dzieje się z Haiku? Ogólnie rzecz biorąc, dzieje się mniej więcej to samo.
Teoretycznie możliwe byłoby umieszczanie zasobów w odpowiedniej sekcji ELF. Zgodnie z twórcami na kanale #haiku w sieci irc.freenode.net:
W przypadku ELF sekcja miałaby więcej sensu... jedynym powodem, dla którego tego nie robimy, jest to, że takie było podejście w BeOS.
I teraz nie ma sensu tego zmieniać.
Zarządzanie zasobami
Zasoby są zapisane w usystematyzowanym formacie „zasobów”: w zasadzie jest to lista zasobów z rozmiarami, a potem ich zawartość. Przypomniał mi się .
Jak można sprawdzić zasoby w Haiku? Czy istnieje coś w rodzaju ResEdit?
Zgodnie z :
Aby zobaczyć zasoby dostarczane w pakiecie aplikacji, można przeciągnąć plik wykonywalny do programu takiego jak . Można też otworzyć terminal i uruchomić polecenie
listres nazwa_pliku.
Resourcer jest dostępny w HaikuDepot, ale u mnie po prostu się zawiesza.
Jak zarządzać zasobami w plikach ELF? Używając rsrc i rdef. rdef plików, które są zbierane w rsrc. Plik rdef jest przechowywany w zwykłym formacie tekstowym, co ułatwia jego obsługę. Plik w formacie rsrc jest dopisywany na końcu pliku ELF. Spróbujmy poeksperymentować:
~> rc -h
Haiku Resource Compiler 1.1Aby skompilować skrypt rdef do pliku zasobów:
rc [opcje] [-o ] ...Aby przekształcić plik zasobów z powrotem do skryptu rdef:
rc [opcje] [-o ] -d ...Opcje:
-d --decompile utwórz skrypt rdef z pliku zasobów
--auto-names skonstruuj nazwy zasobów z symboli ID
-h --help wyświetl tę wiadomość
-I --include dodaj do listy ścieżek dołączania
-m --merge nie kasuj istniejącej zawartości pliku wyjściowego
-o --output określ nazwę pliku wyjściowego, domyślnie jest out.xxx
-q --quiet nie wyświetlaj żadnych komunikatów o błędach
-V --version wyświetl wersję oprogramowania i licencjęMożna użyć programu xres do sprawdzenia i zarządzania:
/> xres
Usage: xres ( -h | --help )
xres -l <file> ...
xres <command> ...The first form prints this help text and exits.The second form lists the resources of all given files.The third form manipulates the resources of one or more files according to
the given commands.
(...)Dobrze, spróbujmy?
/> xres -l /Haiku/system/apps/WebPositive/Haiku/system/apps/WebPositive resources:type ID size name
------ ----------- ----------- --------------------
'MIMS' 1 36 BEOS:APP_SIG
'APPF' 1 4 BEOS:APP_FLAGS
'MSGG' 1 421 BEOS:FILE_TYPES
'VICN' 101 7025 BEOS:ICON
'VICN' 201 91 kActionBack
'VICN' 202 91 kActionForward
'VICN' 203 300 kActionForward2
'VICN' 204 101 kActionStop
'VICN' 206 243 kActionGoStart
'MSGG' 205 1342 kActionGo
'APPV' 1 680 BEOS:APP_VERSIONWięcej o zasobach i formacie rdef można przeczytać .
Standardowe typy zasobów
Chociaż można umieścić w zasobach cokolwiek, istnieje kilka określonych standardowych typów:
app_signature: typ MIME aplikacji, używany do dopasowania otwieranych plików, uruchamiania, IPC itd.app_name_catalog_entry: Ponieważ nazwa aplikacji jest zazwyczaj w języku angielskim, można tutaj wskazać miejsca, w których znajdują się przetłumaczone nazwy, dzięki czemu użytkownicy różnych języków będą mogli zobaczyć przetłumaczoną nazwę aplikacji, jeśli będą chcieli.app_version: dokładnie to, co myśliszapp_flags: wskazujeregistrarjak obsługiwać aplikację. Myślę, że jest coś więcej, niż wydaje się na pierwszy rzut oka. Na przykład jestB_SINGLE_LAUNCH, który powoduje, że system uruchamia nowy proces aplikacji za każdym razem, na żądanie użytkownika (ten sam sposób działania jest stosowany w większości aplikacji na Linuxie). JestB_MULTIPLE_LAUNCH, który zmusza do uruchamiania procesu dla każdego pliku.Wreszcie jestB_EXCLUSIVE_LAUNCH, który zmusza system do uruchomienia tylko jednego procesu w tym samym czasie, niezależnie od tego, jak często użytkownicy go uruchamiają (na przykład tak działa Firefox na Linuxie; ten sam wynik można osiągnąć w aplikacjach Qt, używając funkcji ). Aplikacje zB_EXCLUSIVE_LAUNCHsą informowane, gdy użytkownik próbuje uruchomić je ponownie: na przykład otrzymują ścieżkę do pliku, który użytkownik chce otworzyć za ich pomocą.vector_icon: Wektorowa ikona aplikacji (W BeOS nie było wektorowych ikon, większość aplikacji miała zamiast nich dwie rastrowe ikony w plikach wykonywalnych).
Oczywiście można dodać zasoby z dowolnymi pożądanymi ID i typami, a następnie odczytać je w samej aplikacji lub innych aplikacjach za pomocą klasy BResources. Ale najpierw zatrzymajmy się na pasjonującym temacie ikon.
Wektorowe ikony w stylu Haiku
Oczywiście nie tylko Haiku wybrało najlepszy format ikon, w tej części sytuacja z środowiskami graficznymi Linuxa jest daleka od ideału:
me@host:~$ ls /usr/share/icons/hicolor/
128x128 256x256 512x512 index.theme
160x160 28x28 64x64 scalable
16x16 32x32 72x72 symbolic
192x192 36x36 8x8
22x22 42x42 96x96
24x24 48x48 icon-theme.cachePatrząc na coś takiego, można już poczuć, co to za kawałek.
Oczywiście, są skalowalne, zawierające, jak można zrozumieć, wektorowe ikony. Dlaczego więc istnieje coś jeszcze? Ponieważ jakość renderowania grafiki wektorowej w małych rozmiarach może być gorsza niż idealna. Chciałoby się mieć różne warianty, zoptymalizowane dla różnych rozmiarów. W środowiskach roboczych Linux osiąga się to, rozmieszczając ikony o różnych rozmiarach w systemie plików.
me@host:~$ find /usr/share/icons/ -name 'firefox.*'
/usr/share/icons/HighContrast/16x16/apps/firefox.png
/usr/share/icons/HighContrast/22x22/apps/firefox.png
/usr/share/icons/HighContrast/24x24/apps/firefox.png
/usr/share/icons/HighContrast/256x256/apps/firefox.png
/usr/share/icons/HighContrast/32x32/apps/firefox.png
/usr/share/icons/HighContrast/48x48/apps/firefox.png
/usr/share/icons/elementary-xfce/apps/128/firefox.png
/usr/share/icons/elementary-xfce/apps/16/firefox.png
/usr/share/icons/elementary-xfce/apps/22/firefox.png
/usr/share/icons/elementary-xfce/apps/24/firefox.png
/usr/share/icons/elementary-xfce/apps/32/firefox.png
/usr/share/icons/elementary-xfce/apps/48/firefox.png
/usr/share/icons/elementary-xfce/apps/64/firefox.png
/usr/share/icons/elementary-xfce/apps/96/firefox.png
/usr/share/icons/hicolor/128x128/apps/firefox.pngUwaga: nie ma pojęcia różnych wersji Firefox. W związku z tym nie można subtelnie rozwiązać sytuacji z obecnością wielu wersji aplikacji w systemie.
Różne ikony Firefox w różnych wersjach. Jak na razie niemożliwe jest ich obsłużenie w Linuxie bez różnych obejść.
Mac OS X obsługuje to nieco bardziej subtelnie:
Mac:~ me$ find /Applications/Firefox.app | grep icns
/Applications/Firefox.app/Contents/MacOS/crashreporter.app
/Contents/Resources/crashreporter.icns
/Applications/Firefox.app/Contents/MacOS/updater.app/Contents/Resources/updater.icns
/Applications/Firefox.app/Contents/Resources/document.icns
/Applications/Firefox.app/Contents/Resources/firefox.icnsWidać, że jest jeden plik firefox.icns w pakiecie Firefox.app, zawierający wszystkie rozmiary, więc różne wersje tej samej aplikacji mają różne ikony.
O wiele lepiej! Ikony podróżują razem z aplikacją, wszystkie zasoby w jednym pliku.
Wracając do Haiku. Niesamowite rozwiązanie, bez wyjątków. Zgodnie z :
Opracowano specjalny, wysokooptymalizowany do małych rozmiarów i szybkiej renderowania, format HVIF. Dlatego nasze ikony są w większości znacznie mniejsze niż w rastrowym czy powszechnie używanym formacie SVG.
I zostały zoptymalizowane:
Rozmiary ikony w HVIF w porównaniu z innymi formatami.
Różnica o rząd wielkości!
Ale magia tutaj się nie kończy. Ten sam HVIF może pokazać różne poziomy szczegółowości w zależności od wyświetlanego rozmiaru, mimo że jest to format wektorowy.
Różne poziomy szczegółowości (LOD) w zależności od rozmiaru renderowania
Teraz o wadach: nie można wziąć SVG, wrzucić do ImageMagick i na tym skończyć, trzeba przejść przez kilka cykli, aby stworzyć ikonę w formacie HVIF. objaśnień. Jednak IconOMatic może dość niedoskonale importować SVG; około 90% szczegółów SVG jest importowanych z pewnym prawdopodobieństwem, pozostałe 10% trzeba będzie dostosować i zmienić ręcznie. Więcej informacji na temat tego, jak HVIF czyni swoją magię w blogu
Dodanie ikony do aplikacji
Teraz mogę dodać ikonę do pakietu, który utworzyłem , biorąc pod uwagę wszystkie zebrane informacje.
A ponieważ obecnie nie mam specjalnej ochoty na rysowanie własnej ikony dla mojej aplikacji QtQuickApp „Cześć, Świecie” — wyciągam ją z Qt Creator.
/Haiku/home> xres /Haiku/system/apps/QtCreator/bin/Qt Creator -o /Haiku/home/QtQuickApp/QtQuickApp -a VICN:101:BEOS:ICON /Haiku/system/apps/QtCreator/bin/Qt CreatorSprawdźmy, czy ikona została skopiowana:
/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type ID size name
------ ----------- ----------- --------------------
'VICN' 101 152238 BEOS:ICONWygląda dobrze, jednak dlaczego, kiedy nowa ikona została skopiowana, nie wyświetla się?
Skopiowany VICN:101:BEOS:ICONs nadal nie jest używany jako ikona aplikacji w menedżerze plików.
Co przeoczyłem?
Komentarz dewelopera:
Muszę stworzyć plik
rdefze wszystkimi zasobami, a następnie wykonać polecenierc nazwa.rdef, to stworzy plik.rsrc. Następnie trzeba wykonać polecenieresattr -o nazwa_binarnego plik.rsrc. Przynajmniej ja używam takich poleceń do dodawania ikon do moich skryptów.
Cóż, chciałem stworzyć zasób, a nie atrybut. Jestem kompletnie zdezorientowany.
Inteligentne buforowanie z wykorzystaniem systemu plików.
Otwieranie i odczytywanie atrybutów ELF działa wolno. Jak już wspomniałem wcześniej, ikona jest zapisywana jako zasób w samym pliku. Ten sposób jest bardziej niezawodny, pozwala przetrwać kopiowanie na inny system plików. Jednak później jest również kopiowana do atrybutu systemu plików, na przykład BEOS:ICON. Działa to tylko na określonych systemach plików, na przykład BFS. Ikony wyświetlane przez system (w Tracker i Deskbar) są odczytywane z tego rozszerzonego atrybutu, ponieważ takie rozwiązanie działa szybko. W niektórych miejscach (gdzie prędkość nie ma znaczenia, na przykład w typowym oknie „O programie”) system otrzymuje ikonę bezpośrednio z zasobu w pliku. Ale to jeszcze nie koniec. Pamiętaj, że na Macu użytkownicy mogli wymieniać ikony aplikacji, katalogów, dokumentów na swoje, ponieważ na Macu istnieje możliwość dokonywania tych „ważnych” rzeczy, na przykład Na Haiku należy traktować zasób (w pliku) jako oryginalną ikonę dostarczaną z aplikacją, a atrybut (w systemie plików BFS) jako coś, co pozwala użytkownikowi wprowadzać zmiany według uznania (choć, podpowiedź, interfejs graficzny do wstawiania własnej ikony ponad domyślną ikoną jeszcze nie został zrealizowany).
Sprawdzanie atrybutów systemu plików.
Dzięki resaddr jest możliwość sprawdzenia i ustawienia atrybutów systemu plików.
/> resattr
Usage: resattr [ <options> ] -o <outFile> [ <inFile> ... ]
Reads resources from zero or more input files and adds them as attributes
to the specified output file, or (in reverse mode) reads attributes from
zero or more input files and adds them as resources to the specified output
file. If not existent the output file is created as an empty file.
(...)W zasadzie to rodzaj 'kleju', który wykonuje transformację w obie strony między (niezawodnymi) zasobami a (szybkimi) atrybutami systemu plików. Ponieważ system zakłada pozyskiwanie zasobów i automatycznie wykonuje kopiowanie, nie będę się już tym martwić.
Czarodziejstwo pakietów hpkg
Obecnie (najczęściej) do uzyskiwania programów na Haiku używane są pakiety. .hpkg. Nie daj się zwieść prostą nazwą: format .hpkg działa zupełnie inaczej niż inne formaty o podobnych nazwach, z którymi miało się do czynienia, ma prawdziwe supermoce.
Długo frustrowałem się z tradycyjnymi formatami pakietów z powodu takiego faktu: pobierasz jeden (pakiet), a w systemie instalowane jest coś innego (pliki wewnątrz pakietu). Trudno jest zarządzać plikami (na przykład, usunąć je), gdy pakiet jest instalowany w tradycyjny sposób. Wszystko dlatego, że zawartość pakietu rozprasza się po całym systemie plików, w tym miejscach, do których zwykły użytkownik może nie mieć dostępu do zapisu. To generuje cały typ programów — menedżerów pakietów. A przeniesienie już zainstalowanego oprogramowania, na przykład, na inną maszynę, nośnik wymienny lub serwer plików staje się jeszcze trudniejsze, jeśli nie wręcz niemożliwe. W zwykłym systemie opartym na Linuxie może łatwo istnieć od kilku setek tysięcy do milionów odizolowanych plików. Oczywiście, to jest jednocześnie kruchą i wolną, na przykład przy początkowej instalacji systemu, przy instalacji, aktualizacji i usuwaniu zwykłych pakietów, a także przy kopiowaniu rozruchowej partycji (działu root) na inny nośnik.
Pracuję nad projektem AppImage, częściowym obejściem dla aplikacji końcowych. To format dystrybucji oprogramowania, który łączy aplikację i wszystkie jej zależności w jeden obraz systemu plików, montowany przy uruchamianiu aplikacji. Znacznie to upraszcza sprawy, ponieważ ten sam ImageMagick nagle staje się jednym plikiem, zarządzanym przez zwykłych śmiertelników w menedżerze plików. Zaproponowany sposób działa tylko dla oprogramowania, jak wskazuje nazwa projektu, i ma również swój własny zestaw problemów, ponieważ osoby zajmujące się dystrybucją oprogramowania dla systemu Linux zawsze zwalają winę na mnie.
Wróćmy do Haiku. Czy udało się znaleźć optymalną równowagę między tradycyjnymi systemami pakietowymi a dostarczaniem oprogramowania opartego na obrazach? Jej pakiety .hpkg faktycznie skompresowane obrazy systemu plików. Podczas uruchamiania systemu jądro montuje wszystkie zainstalowane i aktywne pakiety, generując mniej więcej następujące komunikaty jądra:
KERN: package_daemon [16042853: 924] aktywny pakiet: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023: 924] aktywny pakiet: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232: 924] aktywny pakiet: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405: 924] aktywny pakiet: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611: 924] aktywny pakiet: "llvm_libs-5.0.0-3-x86_64.hpkg"Fajnie, prawda? Trzymajcie się, dalej będzie jeszcze lepiej!
Jest jeden wyjątkowy pakiet:
KERN: package_daemon [16040020: 924] aktywny pakiet: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"Zawiera dość minimalistyczny system operacyjny, w tym jądro. Wierzcie lub nie, ale nawet jądro samo w sobie nie jest wydobywane z woluminu rozruchowego (partycji root), tylko starannie ładowane na swoje miejsce z pakietu .hpkg. O rany! Już wspominałem, że według mnie część ogólnej finezji i spójności Haiku wynika z tego, że cały system, od jądra i podstawowej przestrzeni użytkowej, aż po zarządzanie pakietami i infrastrukturę środowiska roboczego, jest opracowywana wspólnie przez jeden zespół. Wyobraźcie sobie, ile różnych grup i zespołów byłoby potrzeba, aby uruchomić coś takiego na bazie Linuxa [wyobrażam sobie projekt PuppyLinux, — przyp. tłum.]. A teraz wyobraźcie sobie, ile czasu zajmie wdrożenie tego podejścia w dystrybucjach. Powiadają, że weź prostą kwestię, podziel ją pomiędzy różnych wykonawców, a skomplikuje się na tyle, że nie będzie już można jej rozwiązać. Haiku w tym przypadku otworzyło mi oczy. Myślę, że dokładnie to dzieje się na Linuxie teraz (Linux w tym przypadku to termin zbiorczy, oznaczający stos Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu).
Przywracanie systemu przy użyciu hpkg
Jak często zdarza się, że aktualizacja przebiega pomyślnie, a potem okazuje się, że coś nie działa tak, jak powinno? Używając standardowych menedżerów pakietów, trudno jest przywrócić stan systemu do momentu sprzed instalacji nowych pakietów (na przykład, gdy coś poszło nie tak). Niektóre systemy oferują obejścia w postaci migawek systemu plików, ale są one dość nieporęczne i nie są stosowane we wszystkich systemach. W Haiku rozwiązano to przy pomocy pakietów .hpkg. Za każdym razem, gdy zmieniają się pakiety w systemie, stare pakiety nie są usuwane, lecz przechowywane w systemie w podkatalogach typu /Haiku/system/packages/administrative/state-<...>/ na stałe. Niedokończone operacje przechowują swoje dane w podkatalogach /Haiku/system/packages/administrative/transaction-<...>/.
Zawartość /Haiku/system/packages/administrative. Katalogi „state…” zawierają pliki tekstowe z nazwami aktywnych pakietów, „transaction…” — same pakiety.
„Stare aktywne stany”, tzn. lista .hpkg pakietów, aktywnych przed zmianami, jest zapisywana po każdej operacji w menedżerze plików w pliku tekstowym /Haiku/system/packages/administrative/state-<...>/activated-packages. Nowe „aktywne stany” są w podobny sposób zapisywane w pliku tekstowym /Haiku/system/packages/administrative/activated-packages.
Katalog /Haiku/system/packages/administrative/state-<...>/ zawiera tylko plik tekstowy z listą aktywnych pakietów tego stanu (w przypadku instalacji pakietów bez usuwania), a jeśli pakiety były usuwane lub aktualizowane — katalog state zawiera stare wersje pakietów.
Podczas uruchamiania systemu na podstawie listy pakietów podejmuje się decyzję o aktywacji (zamontowaniu) pakietów. I to takie proste! Jeśli podczas uruchamiania coś pójdzie nie tak — można wskazać menedżerowi rozruchu, aby użył innej, starszej listy. Problem rozwiązany!
Loader Haiku. Każdy punkt wejścia reprezentuje odpowiadające „aktywne stany”
Podoba mi się podejście z prostymi plikami tekstowymi jako listą „aktywnych stanów”, w których zapisane są zrozumiałe nazwy .hpkg. To wyraźnie kontrastuje z tworzonymi dla maszyn, a nie dla ludzi z OSTree lub Flatpaka w systemie plików (na tym samym poziomie, co Microsoft GUID).
Lista aktywnych pakietów dla każdego momentu czasu
Dane konfiguracyjne
Wygląda na to, że w katalogu /Haiku/system/packages/administrative/writable-files znajdują się pliki konfiguracyjne dla pakietów, które są dostępne do zapisu. Jak pamiętniesz, .hpkg są montowane tylko do odczytu. Dlatego te pliki muszą być kopiowane z pakietów przed zapisem. Ma to sens.
Integracja GUI dla systemu .hpkg
Spójrzmy teraz, jak te błyszczące pakiety .hpkg z radzeniem sobie z integracją w użytkownicze środowisko pracy (UX). W końcu Haiku jest zaprojektowane do użytku osobistego. Osobiście podniosłem poprzeczkę, porównując doświadczenie użytkownika z pakietami .app na Macintoshu z tym samym doświadczeniem na .hpkg. Nie będę nawet porównywał sytuacji z środowiskami roboczymi na Linuxie, ponieważ jest to absolutnie przerażające w porównaniu do jakiegokolwiek innego.
Na myśl przychodzą następujące scenariusze:
- Chcę zobaczyć zawartość pakietu
.hpkg - Chcę zainstalować pakiet
- Chcę usunąć pakiet
- Chcę usunąć coś, co przyszło do systemu jako część pakietu
- Chcę skopiować coś, co przyszło do systemu jako część pakietu
- Chcę pobrać wszystkie zależności pakietu, które mogą nie być częścią każdej instalacji Haiku (na przykład, mam fizycznie odizolowaną maszynę bez dostępu do Internetu.)
- Chcę przenieść moje pakiety (lub ich część) osobno w inne miejsce, oddzielone od woluminu startowego (partycji root) (ponieważ na przykład brakuje mi na nim miejsca).
To powinno obejmować większość głównych przypadków z mojego codziennego użytku. No to zaczynajmy.
Sprawdzanie zawartości pakietu
Na Macu po prostu klikam prawym przyciskiem na pakiet, aby go otworzyć i sprawdzić zawartość w Finderze. W końcu to tylko zamaskowany katalog! (Wiem, że są pakiety .pkg dla części systemu, które nie są aplikacjami, ale przeciętni użytkownicy rzadko z nimi współpracują).
Na Haiku klikam prawym przyciskiem myszy na pakiet, następnie klikam „Contents”, aby sprawdzić, co jest w środku. Ale tutaj jest tylko lista plików bez możliwości otwarcia ich podwójnym kliknięciem.
Byłoby znacznie lepiej, gdyby istniał sposób (tymczasowy) montowania pakietu .hpkg do przeglądania przez menedżera plików, a użytkownik nie musiałby martwić się o szczegóły realizacji. (Tak przy okazji, można otworzyć .hpkg pakiet w Expander, który może go rozpakować jak każdy inny archiwum).
W interfejsie HaikuDepot można zobaczyć listę plików pakietu, ale nie ma sposobu na przeglądanie zawartości, na przykład podwójnym kliknięciem na README.md.
W tej kategorii Mac wygrywa, ale dodanie potrzebnej funkcjonalności HaikuDepot nie powinno nastręczać dużych trudności.
Instalacja pakietu przez GUI
Na Macu, większość obrazów dysków .dmg zawiera pakiety .app. Otwieramy obraz dysku podwójnym kliknięciem, a następnie kopiujemy pakiet, na przykład, przeciągając go do /Applications w Finderze. Dla mnie to jest oczywiste, ale słyszałem, że niektórzy nowicjusze mogą mieć z tym problem. Domyślnie Apple „oferuje” systemowy katalog /Applications (na NeXT był to katalog sieciowy, jak również indywidualny), ale można łatwo umieścić swoje aplikacje na serwerze plików lub w podkatalogu $HOME/Applications, jeśli tak wolisz.
Na Haiku, podwójne kliknięcie na pakiet, a następnie kliknięcie „Install”, prościej się nie da. Zastanawiam się, co się stanie, jeśli pakiet ma zależności dostępne w HaikuPorts, ale nie jest jeszcze zainstalowany. Na Linuxie nie wiedzą, co zrobić w takiej sytuacji, ale rozwiązanie jest oczywiste — zapytać użytkownika, czy należy pobrać i zainstalować zależności. Dokładnie to robi Haiku.
Ręcznie pobrałem pakiet 'sanity' i kliknąłem na niego, menedżer pakietów wie, skąd wziąć jego zależności (pod warunkiem, że repozytoria są już zapisane w systemie). Nie każdy dystrybucja Linuxa to potrafi.
Kolejnym sposobem jest użycie menedżera plików, wystarczy przeciągnąć .hpkg pakiet albo do /Haiku/system/packages (dla instalacji systemowej, domyślnie), lub do /Haiku/home/config/packages (dla instalacji indywidualnej; niedostępne przy podwójnym kliknięciu — nadal irytuje mnie słowo „config” w tym miejscu, które w tym przypadku jest dla mnie synonimem „ustawienia”). A przecież koncepcja wielu użytkowników jeszcze nie jest dostępna dla Haiku (może dlatego wszystko jest takie proste — nie wiem, może możliwości wieloużytkowe zbytnio skomplikują sprawy dla środowiska roboczego personalnego komputera).
W tej kategorii Haiku wygrywa, ponieważ potrafi radzić sobie nie tylko z aplikacjami, ale i z programami systemowymi.
Usuwanie pakietu z GUI
Na Macu, wystarczy przeciągnąć ikonę aplikacji do kosza i to wszystko. Łatwe!
Na Haiku, po pierwsze, trzeba znaleźć, gdzie pakiet znajduje się w systemie, ponieważ rzadko kiedy instalujesz go tam, gdzie trzeba (wszystko robi system). Zwykle trzeba szukać w /Haiku/system/packages (przy domyślnej instalacji systemowej), lub w /Haiku/home/config/packages (już mówiłem, że „config” to niewłaściwa nazwa?). Potem aplikacja po prostu przeciągana jest do kosza i to wszystko.
Łatwe! Jednak nie powiedziałbym tak. Oto co się w rzeczywistości dzieje:
Oto co się dzieje, gdy przeciągniesz aplikację do kosza z /Haiku/system/packages
Po prostu próbowałem przenieść do kosza moją wczorajszą aplikację „Witaj, świecie” w QtQuickApp. Nie próbowałem przenieść katalogu systemowego, a ponieważ wszystkie pakiety są instalowane w katalogu systemowym — nie można usunąć pakietu .hpkg bez zmiany „jego zawartości”. Zwykły użytkownik przeraziłby się, naciskając przycisk „Anuluj”, przypisany jako domyślny.
Wyjaśnia :
To powiadomienie ma już ponad 10 lat. Prawdopodobnie powinniśmy je tak skonfigurować, aby ostrzeżenie wyświetlało się tylko podczas przenoszenia samego pakietu. Zwykłym użytkownikom w każdym razie nie jest to potrzebne.
Dobrze, może warto to zrobić, używając HaikuDepot? Klikam dwukrotnie na pakiecie w /Haiku/system/packages, czekając na przycisk „Odinstaluj”. Nie ma, jest tylko „Zainstaluj”. „Odinstaluj”, gdzie jesteś?
Dla żartu spróbowałem zobaczyć, co się stanie, gdy kliknę „Zainstaluj” dla już zainstalowanego pakietu. Oto co się dzieje:
Jest tak, jeśli próbujesz zainstalować już zainstalowany pakiet.
Następnie pojawia się:
Jeśli klikniesz „Zastosuj zmiany” w poprzednim oknie — to wyjdzie tak
Zakładam, że to błąd programowy, już jest link do zgłoszenia. [autor nie dostarczył linku, — przyp. tłumacza]
Szybkie rozwiązanie: Dodać przycisk „Odinstaluj”, jeśli pakiet już jest w
/Haiku/system/packages, lub w/Haiku/home/config/packages.
Podczas przeglądania listy pakietów zainstalowanych w HaikuDepot, widzę mój pakiet na liście i mogę go usunąć.
W tej kategorii wygrywa Mac. Ale mogę sobie wyobrazić, że przy odpowiedniej konfiguracji doświadczenie użytkownika na Haiku będzie lepsze niż na Macu. (Jeden z deweloperów ocenił to tak: „Mniej niż godzinę na dodanie wskazanej funkcjonalności do HaikuDepot, jeśli trochę znasz C++”, są ochotnicy?)
Usunięcie czegokolwiek z pakietu
Spróbujmy usunąć samo aplikację, a nie pakiet .hpkg, z którego pochodzi (wątpię, czy dla „zwykłych śmiertelników” jest jakakolwiek różnica).
Na Macu, użytkownik zwykle pracuje z plikiem .dmg, z którego pochodzi pakiet aplikacji .app. Zwykle obrazy .dmg gromadzą się w katalogu pobierania, pakiety są natomiast kopiowane przez użytkownika do /ApplicationsIstnieje opinia, że wielu użytkowników samodzielnie nie wie, co robi, a ta hipoteza znajduje potwierdzenie w słowach byłego pracownika Apple. (Jedną z rzeczy, które mi się nie podobają na Macu, jest to, że na przykład z AppImage nie ma różnicy między aplikacją a pakietem, w którym się znajduje. Przeciągnięcie ikony do kosza = to wszystko. Łatwe!)
Na Haiku, istnieje również podział między aplikacjami/ i pakietami/, więc wątpię, czy użytkownicy będą z tego bardziej zrozumiali. A oto, co się dzieje, jeśli przeciągniesz aplikację z aplikacjami/ do kosza:
Oto co się dzieje podczas próby usunięcia aplikacji pobranej z pliku .hpkg
Technicznie to poprawne (w końcu aplikacja jest umieszczona w systemie plików tylko do odczytu przede wszystkim), ale nie jest to dla użytkownika szczególnie pomocne.
Szybkie rozwiązanie: zamiast tego proponować usunięcie przez GUI
.hpkg
Na próbę spróbowałem zduplikować aplikację, naciskając Alt+D. Otrzymałem komunikat "Nie można przenieść ani skopiować obiektów na woluminie tylko do odczytu". A to dlatego, że /system oprócz /system/packages i /system/settings) jest punktem montowania packagefs (pamiętaj, jak pojawia się w wynikach df?). К сожалению, вывод команды mount nie wyjaśnia sytuacji (jak już wspomniano w jednym z poprzednich artykułów), mountvolume nie pokazuje poszukiwanego (najwyraźniej montowane przez loop pakiety .hpkg nie są kwalifikowane jako "woluminy"), a także zapomniałem o alternatywnych poleceniach.
W tej kategorii nikt nie wygrał, poza AppImage (ale szczerze mówiąc, to stronnicza opinia). Jednak można sobie wyobrazić, że po dostosowaniu doświadczenie użytkownika na Haiku będzie lepsze niż na Macu.
Uwaga: muszę wyjaśnić, czym jest "wolumin" w odniesieniu do "partycji". Prawdopodobnie jest to zbliżone do relacji "foldera" do "katalogu": większość katalogów wyświetla się w menedżerze plików jako foldery, ale nie wszystkie z nich (na przykład pakiety traktowane jak pliki). Czy takie analizy czynią mnie nerdem oficjalnie?
Kopiowanie zawartości pakietu na inny system
Na Macu, po prostu przeciągam pakiet .app, a ponieważ zależności w pakiecie — przenoszą się razem.
Na Haiku, przeciągam aplikację, ale zależności nie są w ogóle przetwarzane.
Szybkie rozwiązanie: niech zamiast tego proponuje przeciągnięcie pakietu "`.hpkg` w całości, wraz z zależnościami, jeśli są.
W tej kategorii zdecydowanie wygrywa Mac. Przynajmniej dla mnie, fana ich paradygmatu. Na Haiku trzeba by to skopiować. .hpkg zamiast aplikacji, ale system nie oferuje mi czegoś takiego…
Pobieranie pakietu ze wszystkimi jego zależnościami
Nie każda maszyna jest cały czas podłączona do sieci. Wręcz przeciwnie, niektóre maszyny (tak, patrzę na was, nowoczesne Windows, Mac i Linux) o tym zapominają. Dla mnie ważne jest, że mogę na przykład pójść do internetu, pobrać oprogramowanie na nośnik USB, włożyć ten nośnik do domowego komputera i być pewnym, że wszystko zadziała [ryzykowny facet, robiąc to na Windowsie… — przyp. tłumacza].
W rezultacie, nieco częściej niż zazwyczaj, zazwyczaj otrzymuję niezadowalające zależności na Windowsie i Linuxie.
Na Macu to zazwyczaj jeden plik, wszystko co potrzeba — to pobrać .dmg. Najczęściej nie ma on żadnych zależności, poza tymi, które są dostarczane domyślnie przez MacOS. Jako wyjątek można podać skomplikowane aplikacje, które wymagają odpowiedniego środowiska wykonawczego, na przykład java.
Na Haiku pobierz pakiet .hpkg dla, powiedzmy, tej samej aplikacji na java, może okazać się niewystarczające, ponieważ java może być zarówno obecna, jak i nieobecna na docelowej maszynie. Czy istnieje sposób na pobranie wszystkich zależności dla tego pakietu .hpkg, poza tymi, które są instalowane w Haiku domyślnie i dlatego powinny być w każdym systemie Haiku?
W tej kategorii nieznacznie wygrywa Mac.
Komentuje mr. waddlesplash:
Aby napisać program do zbierania wszystkich zależności aplikacji w postaci zestawu pakietów
.hpkgdla kogoś, kto zna wewnętrzną budowę Haiku, wystarczy około 15 minut. Dodanie wsparcia dla tego nie jest takie trudne, jeśli istnieje rzeczywista potrzeba. Ale dla mnie to rzadka sytuacja.
Wstrzymujemy oddech do następnego artykułu w tym cyklu.
Przenoszenie pakietów w wydzielone miejsce
Jak już wcześniej napisałem, chcę umieścić moje pakiety .hpkg (no, lub część z nich) w szczególnym miejscu, oddzielonym od zwyczajnego miejsca na dysku startowym (partycji głównej). W normalnym przypadku (nie tak teoretycznym) powodem tego jest to, że ciągle brakuje wolnego miejsca na moich (wbudowanych) dyskach, nieważne jak dużych. Zwykle podłączam zewnętrzne dyski lub zasoby sieciowe, gdzie znajdują się moje aplikacje.
Na Macu po prostu przenoszę pakiety .app na dysk przenośny lub katalog sieciowy w Finderze i na tym koniec. Wciąż mogę otworzyć aplikację podwójnym kliknięciem, tak jak to robiłem na dysku rozruchowym. Proste!
Na Haiku, jak mi powiedziano, można to osiągnąć poprzez przeniesienie moich .hpkg pakietów na dysk przenośny lub katalog sieciowy, ale potem trzeba użyć kilku niedokumentowanych poleceń w konsoli, aby zamontować je w systemie. Nie wiem, jak to zrobić, używając tylko GUI.
W tej kategorii zyskuje Mac.
Według pana waddlesplasha:
Tutaj optymalizacja jest oparta na typowym użyciu. Jeśli jednak popyt będzie większy niż od jednego użytkownika, zaimplementujemy to. W każdym razie istnieje możliwość realizacji przez osoby trzecie.
O tym opowiemy w następnym artykule.
Jeśli chodzi o katalogi sieciowe: byłoby wspaniale (domyślam się, że LAN party) mieć proste, wykrywalne, ogólnosieciowe aplikacje (na przykład dzięki Zeroconf), które można skopiować na lokalny komputer lub uruchomić od razu z sieci lokalnej. Oczywiście, deweloperzy mają możliwość odmowy przez app_flags.
Końcowy raport o integracji systemu hpkg z GUI
Myślę, że przede wszystkim z powodu względnej nowości integracja .hpkg z GUI nadal pozostawia wiele do życzenia. W każdym razie jest kilka rzeczy, które można poprawić pod względem UX…
Jeszcze jedna rzecz: Kernel Debug Land
Byłoby świetnie w przypadku kernel panic mieć możliwość wprowadzania poleceń, na przykład syslog | grep usb. Cóż, na Haiku jest to możliwe dzięki Kernel Debug Land. Jak zobaczyć tę magię w akcji, jeśli wszystko działa prawidłowo bez występowania kernel panic? Łatwo, naciskając Alt+PrintScn+D (mnemonika Debug). Od razu przypominają mi się , które pozwalało pierwotnym deweloperom Macintosh wchodzić do debuggera (jeśli był zainstalowany, oczywiście).
Podsumowanie
Zaczynam rozumieć, że wyrafinowanie systemu Haiku wynika z tego, że prace prowadzi mały zespół z wyraźnym ukierunkowaniem na środowisko robocze, przy dostępności wszystkich warstw systemu.
Ostry kontrast z światem Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, gdzie wszystko jest rozbite na małe kawałki do tego stopnia, że abstrakcja siedzi na abstrakcji, a łatanie rozwiązań.
Również pojawiło się zrozumienie tego, jak system .hpkg łączy najlepsze praktyki tradycyjnych menedżerów pakietów, Snappy, Flatpak, AppImage, nawet btrfs, i łączy je z zasadą 'po prostu działa' z Maca.
Jakby coś „przełączyło się” w mojej głowie, i zrozumiałem, jak system .hpkg potrafi się cofnąć, — wystarczy na niego spojrzeć. Ale to nie ja, to piękno i prostota systemu. Wiele tutaj przesiąknięte jest duchem pierwotnego Maca.
Tak, przeglądanie stron w przeglądarce może być skokowe i działać jak ślimak, może brakować aplikacji (brak Gtk, Electron — programiści doszli do wniosku, że źle współpracują z wyrafinowaniem), przyspieszenie wideo i 3D może całkowicie nie działać, ale mimo tego podoba mi się ten system. W końcu te rzeczy można poprawić i prędzej czy później się pojawią. To tylko kwestia czasu i być może trochę czerwonych oczu.
Nie mogę zaproponować pomocy, ale myślę, że od tego momentu zacznie się rok Haiku na pulpicie.
Przypadkowe problemy
Może są już zgłoszenia, czy powinienem je otworzyć?
- BeScreenCapture powinien mieć możliwość eksportu do GIF, jak w Peek. Można to zrobić za pomocą ffmpeg, który już jest dostępny dla Haiku. .
- Program do robienia zrzutów ekranu nie może uchwycić obrazu okna modalnego, zamiast tego robi zrzut całego ekranu.
- Nie można przycinać zrzutów ekranu za pomocą narzędzia do przycinania w WonderBrush, a następnie zapisać wyniku w pliku.
- Nie szczególnie podoba mi się kursor w kształcie ręki w Haiku, ale myślę, że to związane z ciepłymi uczuciami nostalgii. To szczególnie irytujące podczas korzystania z narzędzia do przycinania w Krita, ponieważ prowadzi to do niedokładnego przycinania (zobacz zrzuty ekranu z oknami modalnymi w tym artykule). Kursor w kształcie krzyża byłby wspaniały. .
Spróbuj sam! Projekt Haiku udostępnia obrazy do uruchamiania z DVD lub USB, tworzone . Aby zainstalować, wystarczy pobrać obraz i nagrać go na pendrive'a za pomocą
Masz pytania? Zapraszamy do naszego rosyjskojęzycznego .
Przegląd błędów:
Od tłumaczenia: to szósty artykuł z cyklu o Haiku.
Lista artykułów:
Źródło: habr.com
