🥇Нещо друго: приложения на пакети Haiku?

TL;DR: може ли Haiku да получи адекватна поддръжка за пакети с приложения, например каталози на приложения (както .app в Mac) и/или изображения на приложения (Linux AppImage)? Струва ми се, че това би било достойно допълнение, което е по-лесно да се интегрира, отколкото в други системи, тъй като голяма част от инфраструктурата вече е налична.

Преди седмица открих Haiku, неочаквано добра система. И тъй като отдавна се интересувам от каталози и изображения на приложения (вдъхновен от простотата на Macintosh), не е изненадващо, че ми дойде в ума идеята…

За пълно разбиране: аз съм създателят и авторът на AppImage, формат за разпространение на приложения в Linux, насочен към простотата на Mac и предоставящ пълен контрол на авторите на приложения и крайните потребители (искате да научите повече — вижте. wiki и документацията).

Какво ако направим AppImage за Haiku?

Нека малко, чисто теоретично, помислим: какво трябва да се направи, за да получим AppImage, или нещо подобно, на Haiku? Не е необходимо да създаваме нещо веднага, тъй като системата, която вече е налична в Haiku, работи удивително, а въображаемият експеримент би бил добър. Освен това, той демонстрира елегантността на Haiku в сравнение с работните среди на Linux, където подобни неща са ужасно трудни (имам право да говоря така: вече 10 години се мъча с отстраняването на грешки).

На Macintosh System 1 всяко приложение беше отделен файл, „управляван“ в Finder. Използвайки AppImage, опитвам се да възпроизведа същото потребителско изживяване в Linux.

На първо място, какво е AppImage? Това е система за публикуване на приложения на трети страни (например, Ultimaker Cura), която позволява публикуването на приложения, когато и както желаят: няма нужда да знаят особеностите на различните дистрибуции, политиките за компилиране или инфраструктурата за компилиране, няма нужда от поддръжка от поддръжници, и не им казват на потребителите какво (не) могат да инсталират на компютрите си. AppImage трябва да се разбира като нещо, подобно на пакет за Mac в формат .app вътре в образа на диска .dmg. Основната разлика е, че приложенията не се копират, а остават вътре в AppImage винаги, по подобен начин, по който пакетите на Haiku .hpkg се монтират и никога не се инсталират в обикновения смисъл.

AppImage придоби известност и популярност през повече от 10 години: самият Линус Торвалдс го одобри публично, а известни проекти (например LibreOffice, Krita, Inkscape, Scribus, ImageMagick) го приемат като основен метод за разпространение на непрекъснати или нощни версии, които не пречат на инсталираните или неинсталираните приложения на потребителите. Въпреки това, работни среди и дистрибуции на Linux често продължават да се придържат към традиционния, централизирани модел на разпространение, основан на съпътстващи и/или популяризиращи собствени корпоративни бизнес и/или инженерингови програми на базата на Flatpak (RedHat, Fedora, GNOME) и Snappy (Canonical, Ubuntu). Процесът стига до смешно.

Как всичко работи

Всеки AppImage съдържа две части: малко изпълнимо ELF (наречен runtime.c), с последваща образна файлова система SquashFS.

Файловата система SquashFS съдържа полезната част под формата на приложение и всичко необходимо за неговото стартиране, което разумно не може да се счита за част от стандартната инсталация за всяка достатъчно актуална целева система (дистрибуция на Linux). Тя също така съдържа метаданни, например името на приложението, иконите, MIME типове и др.

При стартиране, runtime използва FUSE и squashfuse за монтиране на файловата система, след което обработва стартиране на определена точка на влизане (т.н. AppRun) вътре в монтирания AppImage.
Файловата система се размонтира след приключване на процеса.

Изглежда всичко е просто.

А тези неща усложняват ситуацията:

с такова разнообразие на дистрибуции на Linux нищо „разумно“ не може да се нарече „част от стандартна инсталация за всяка нова целева система“. Преодоляваме този проблем, като изграждаме excludelist, която определя какво ще бъде опаковано в AppImage и какво трябва да вземем отнякъде другаде. Понякога обаче грешим, въпреки че в общи линии всичко работи отлично. Поради тази причина препоръчваме на създателите на пакети да проверяват AppImages на всички целеви системи (дистрибуции).
Приложенията, включени в полезната част, трябва да бъдат премествани във файловата система. За съжаление, в много приложения са зададени абсолютни пътища към, например, ресурси в /usr/share. Това трябва да се коригира. Освен това трябва или да експортираме LD_LIBRARY_PATH, или да коригираме rpath за да може зареждачът да намери свързаните библиотеки. Първият метод има своите недостатъци (които се преодоляват по сложни начини), а вторият е просто тромав.
Най-голямото UX предизвикателство за потребителите е, че трябва да зададат изпълним бит на файла AppImage след изтегляне. Искате да вярвате или не, но за някои хора това е реална преграда. Необходимостта от задаване на изпълнимост е тромава дори за опитни потребители. Като обходен вариант, предложихме инсталирането на малък сервис, който следи файловете AppImage и задава изпълнимостта им. В чист вид, не е най-доброто решение, тъй като няма да работи „из коробки“. Линукс дистрибуциите не предлагат този сервис, следователно, за потребителите „из коробки“ всичко е лошо.
Потребителите на Линукс очакват новото приложение да има икона в менюто за стартиране. На системата не можеш да кажеш: „Слушай, ето новото приложение, давай да работим“. Вместо това, съгласно спецификацията XDG, трябва да копираш файла .desktop на нужното място в /usr за системна инсталация, или в $HOME за индивидуална. Иконите с определени размери, съгласно спецификацията XDG, трябва да се поставят на определени места в usr или $HOME, след което да стартираш командите в работната среда за обновяване на кеша на иконите, или да се надяваш, че мениджърът на работната среда ще се досети и автоматично ще ги открие. Подобно е и с MIME типовете. Като обходен вариант се предлага да се използва същият сервис, който, освен задаването на изпълнимост, ще копира иконите и т.н. от AppImage в нужните места според XDG. При изтриването или преместването сервисът предполагаемо ще почиства всичко. Разбира се, има различия в поведението на всяка работна среда, в графичните файлови формати, техните размери, места на съхранение и методи за обновяване на кешовете, което поражда проблема. С две думи, този метод е временно решение.
Ако горепосоченото не е достатъчно, в файловия мениджър все още няма икона за AppImage. В света на Линукс все още не е взето решение за внедряване на elficon (въпреки че дискусията и реализация), така че е невъзможно да вградим иконата директно в приложението. Така се оказва, че приложенията в файловия мениджър нямат собствени икони (без значение дали са AppImage или нещо друго), те съществуват само в менюто за стартиране. Като заобиколно решение използваме миниатюри — механизмът, който първоначално е бил проектиран, за да позволи на мениджърите на работния плот да показват намалени изображения за преглед на графични файлове като техни икони. Следователно, услугата за настройка на изпълняемост също работи като „миниатюризатор“, създавайки и записвайки миниатюри на иконите в съответните места. /usr и $HOME. Също така, тази услуга извършва почистване, ако AppImage бъде изтрит или преместен. Поради факта, че всеки мениджър на работен плот реагира малко по-различно, например, в какви формати приема иконите, в какви размери или места, това наистина е болезнено.
Приложението просто се срине при изпълнение, ако възникнат грешки (например, ако има библиотека, която не е част от базовата система и не се доставя с AppImage), и никой не информира потребителя в GUI какво точно се случва. Започнахме да заобикаляме това, като използваме известие на работния плот, така че трябва да улавяме грешките от командния ред, да ги превръщаме в съобщения, разбираеми за потребителя, които след това трябва да бъдат показани на работния плот. И разбира се, всяка работна среда ги обработва малко по различен начин.
Към момента (септември 2019 г., — бележка на преводача) не намерих лесен начин да кажа на системата, че файлът 1.png трябва да се отвори с Krita, а 2.png — с GIMP.

Мястото за съхранение на cross-desktop спецификациите, използвани в GNOME, KDE и Xfce е freedesktop.org.

Постигането на ниво елегантност, дълбоко вплетено в работната среда на Haiku, е затруднено, ако не и 'невъзможно', поради спецификациите на XDG от freedesktop.org за cross-desktop, както и реализациите на мениджърите на работния плот, базирани на тези спецификации. Например, можем да посочим една обща икона на Firefox: явно, на авторите на XDG не им е дошло на ум, че потребителят може да има инсталирани няколко версии на едно и също приложение.

Иконите на различни версии на Firefox.

Интересно ми е какво може да научи светът на Linux от Mac OS X, за да не допусне грешки при системната интеграция. Ако имате време и се занимавате с това — непременно прочетете какво е казал Арно Гурдол, един от първите инженери на Mac OS X:

Искахме инсталирането на приложението да е толкова просто, колкото да преместите иконата на приложението отнякъде (сървър, външен диск) на диска на вашия компютър. За целта в пакета на приложението е запазена цялата информация, включително иконите, версията, обработвания тип файл, типа URL схеми, която системата трябва да знае за обработка на приложението. Сюда също така влиза информация за 'централизираното съхранение' в базата данни Icon Services и Launch Services. За поддържане на производителността приложението 'се открива' на няколко 'добре познати' места: в системния и потребителския каталог Applications, както и в някои други автоматично, ако потребителят е преминал в Finder в каталог, съдържащ приложението. На практика това проработи много добре.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 сесия 144 — Mac OS X: опаковане на приложения и печат на документи.

Нищо подобно от тази инфраструктура няма в работните среди на Linux, така че търсим алтернативни решения за структурните ограничения в проекта AppImage.

Дали Haiku се втурва на помощ?

И още нещо: платформите на Linux като основа на работни среди обикновено са толкова недоспецифицирани, че много неща, които са доста прости в последователна система с пълен стек, разочароват с фрагментираността и сложността си в Linux. Посветих цяла лекция на въпросите, свързани с платформата Linux за работни среди (знаещи разработчици потвърдиха: така ще остане още дълго време).

Моята лекция по проблемите на работните среди на Linux през 2018

Дори Линус Торвалдс призна, че именно заради фрагментацията идеята за работни среди не успя.

Приятно е да видя Haiku!

С Haiku всичко става удивително просто

Въпреки че наивният подход към „пренасянето“ на AppImage на Haiku се състои в прост опит за компилиране (в основния runtime.c и услугите) на неговите компоненти (което може да е възможно!), това няма да донесе особена полза за Haiku. Защото всъщност повечето от тези проблеми са разрешени на Haiku и концептуално обосновани. Haiku предоставя точно тези блокчета за системна инфраструктура, които дълго време търсех в работни среди на Linux и не можех да повярвам, че ги няма там. А именно:

Вярвайте или не, но много потребители на Linux не могат да се справят с това. На Haiku всичко става автоматично!

Файловете ELF, които нямат изпълнителен бит, получават такъв автоматично при двойно щракване в файловия мениджър.
Приложенията могат да имат вградени ресурси, например икони, които се показват във файловия мениджър. Няма нужда да копирате купища изображения в специални каталози с икони, следователно, не е нужно да ги изчиствате след изтриване или преместване на приложението.
Има база данни за свързване на приложения с документи, нямате нужда да копирате каквито и да било файлове за това.
В каталога lib/ до изпълнимия файл библиотеките се търсят по подразбиране.
Няма множество дистрибуции и работни среди, всичко, което работи — работи навсякъде.
Няма отделен модул за стартиране, който да се различава от каталога Applications.
В приложенията няма вградени абсолютни пътища до техните ресурси, има специални функции за определяне на местоположението по време на изпълнение.
Внедрена е идеята за компресирани образи на файлови системи: това е всеки пакет hpkg. Всички те се монтират от ядрото.
Всеки файл се отваря от приложението, което го е създало, освен ако не е изрично посочено нещо друго. Колко готино е това!

Два файла png. Обърнете внимание на различните икони, показващи, че ще бъдат отваряни от различни приложения при двойно щракване. Също така обърнете внимание на падащото меню „Отвори с помощта на:“, където потребителят може да избере отделно приложение. Колко лесно!

Изглежда, че много от допълнителните решения и заобиколни пътища, нужни на AppImage в Linux, стават ненужни на Haiku, която в основата си притежава простота и изтънченост, благодарение на които се справя с повечето от нашите нужди.

Нужни ли са на Haiku пакети с приложения, в крайна сметка?

Това води до един важен въпрос. Ако създаването на система, подобна на AppImage за Haiku, се окаже много по-лесно отколкото за Linux, би ли си струвало да се направи? Или Haiku с нейната система за пакети hpkg всъщност е премахнала необходимостта от разработване на подобна идея? За да отговорим, трябва да погледнем мотивацията зад съществуването на AppImages.

Поглед от страна на потребителя

Нека да разгледаме нашия краен потребител:

Искам да инсталирам приложение без да ми се иска администраторска парола (root). В Haiku няма концепция за администратор, потребителят има пълен контрол, защото това е лична система! (Всъщност, възможно е да си го представим и в много потребителски режим, надявам се разработчиците да запазят простотата)
Искам да получавам най-новите и най-добрите версии на приложенията, без да чакам, когато те станат налични в моя дистрибутив (това в най-често случаи означава "никога", поне ако не обновя цялата операционна система). В Haiku това е "решено" чрез плаващи издания. Това означава, че има възможност да получавате най-новите и най-добри версии на приложения, но за това е необходимо постоянно обновяване и на останалата част от системата, превръщайки я в "движеща се цел"..
Искам да имам няколко версии на едно и също приложение до мен, тъй като е невъзможно да се разбере какво е счупено в последната версия, или например, аз, като уеб разработчик, трябва да проверя работата си под различни версии на браузъра. В Haiku първият, но не и вторият проблем е решен. Актуализациите могат да се върнат, но само за системата като цяло, невъзможно е (доколкото знам) да стартирам, да речем, няколко версии на WebPositive или LibreOffice едновременно.

Един от разработчиците пише:

По същество, обосновката е: сценарият за използване е толкова рядък, че оптимизацията за него не е смислена; обработката му като специален случай в HaikuPorts изглежда повече от приемлива.

Трябва да мога да запазвам приложенията там, където ми харесва, а не на зареждащия диск. Често ми свършва мястото на дисковете, така че трябва да свържа външен диск или мрежова папка за съхранение на приложения (всички версии, които съм изтеглил). Ако свържа такъв диск — искам приложенията да стартират с двоен клик. Haiku запазва стари версии на пакетите, но не знам как да ги преместя на външен диск, нито как да стартирам приложения от там.

Коментар на разработчика:

Технически, това вече е възможно с екипа mount. Разбира се, ще направим GUI за това, щом се съберат достатъчно заинтересовани потребители.

Не ми трябват милиони файлове, разпръснати в файловата система, с които не мога да управлявам ръчно. Искам един файл на приложение, който лесно да мога да сваля, преместя или изтрия. На Haiku този проблем е решен с помощта на пакети .hpkg, които пренасят, например, python, от хиляди файлове в един. Но ако има, например, Scribus, използващ python, тогава имам работа с минимум два файла. И трябва да се погрижа да запазя работещите версии помежду им.

Многобройни версии на AppImages, стартирани паралелно на една Linux

Поглед от страна на разработчика на приложения

Нека погледнем от гледната точка на разработчика на приложения:

Искам да управлявам потребителския опит изцяло. Не искам да завися от операционната система, която ще ми указва кога и как да пускам приложения. В Haiku разработчиците могат да работят със свои собствени репозитории hpkg, но това означава, че потребителите ще трябва да ги настроят ръчно, което прави тази идея „по-малко привлекателна“.
Имам страница за сваляне на моя уебсайт, където разпространявам .exe за Windows, .dmg за Mac и .AppImage за Linux. А може би ще искам да монетизирам достъпа до тази страница, всичко може да стане? Какво трябва да поставя там за Haiku? Достатъчен е файл .hpkg с зависимости само от HaikuPorts
Моят софтуер изисква определени версии на друг софтуер. Например, известно е, че за Krita е необходима коригирана версия на Qt, или Qt, която е точно настроена на конкретна версия на Krita, поне докато поправките не се върнат обратно в Qt. Може да се опакова собствен Qt за приложението в пакета .hpkg, но най-вероятно това не се приветства.

Обикновена страница за сваляне на приложение. Какво да поставя тук за Haiku?

Ще станат ли комплектите (съществуващи под формата на директории на приложения, като AppDir или .app в стил Apple) и/или изображения (във вид на силно модифицирани AppImages или .dmg от Apple) приложения полезно допълнение за работната среда Haiku? Или ще разкъса цялостната картина и ще доведе до фрагментация, а следователно ще добави сложност? Разкъсвам се: от една страна, красотата и изтъкаността на Haiku се основават на факта, че обикновено има един начин да се направи нещо, а не много. От друга страна, голяма част от инфраструктурата за каталози и/или комплекти приложения вече е на мястото си, така че системата призовава останалите няколко процента да заемат местата си.

Според разработчика mr. waddlesplash

На Linux те (каталози и комплекти приложения, — бележка на преводача) най-вероятно представляват техническо решение на системни проблеми. На Haiku предпочитаме просто да решаваме системните проблеми.

Какво мислите вие?

Преди да отговорите…

Изчакайте, нека направим бърза проверка на реалността: всъщност каталози на приложения — вече са част от Haiku:

Каталозите на приложения вече съществуват на Haiku, но засега не се поддържат в файловия мениджър

Просто не се поддържат толкова добре, колкото, да речем, в Macintosh Finder. Колко би било страхотно ако каталогът QtCreator имаше в горния ляв ъгъл име и икона „QtCreator“, които стартират приложението с двойно щракване?

Преди малко вече питах:

Сигурни ли сте, че ще успеете да стартирате своите приложения от преди десет години днес, когато всички магазини на приложения и репозитории на дистрибуции ще забравят за тях и техните зависимости? Сигурни ли сте, че все още можете да получите достъп до текущата си работа в бъдеще?

Има ли вече отговор от страна на Haiku, или каталозите и комплектите приложения могат да помогнат тук? Мисля, че могат.

Според г-н waddlesplash:

Да, имаме отговор на въпроса: просто ще поддържаме тези приложения толкова дълго, колкото е необходимо, докато някой не успее по правилен начин да прочете техните файлови формати или да осигури функционалност един към един. Нашето желание да поддържаме работата на приложения BeOS R5 на Haiku е пряко доказателство за това…

Точно така!

Какъв план за действие трябва да предприеме Haiku?

Мога да си представя мирно съществуване на hpkg, каталози и образи на приложения:

Системното ПО използва .hpkg
За най-често използваното ПО (особено за такова, което трябва да планира плаващи издания) се използва .hpkg (около 80% от всички случаи)
Някои, инсталирани чрез .hpkg, приложенията ще спечелят от преминаването към инфраструктура с каталози на приложения (например, QtCreator): те ще се разпространяват в вида .hpkg, както преди.

г-н waddlesplash пише:

Ако всичко, което е необходимо, е — преглед на приложенията в /system/apps, вместо това трябва да се направят каталогите в Deskbar по-управляеми за потребителите, тъй като /system/apps не е предназначен за редовно отваряне и преглеждане от потребителите (за разлика от MacOS). За такива ситуации Haiku има друга парадигма, но този вариант, в идеята, е приемлив.

Haiku получава инфраструктура за стартиране на образи на приложения, нощни, непрекъснати и тестови сборки на софтуер, а също и за случаи, когато потребителят иска да го „замрази във времето“, за частен и вътрешен софтуер, и други специални случаи на употреба (около 20% от всичките). Тези образи съдържат необходимите файлове за стартиране на приложенията, .hpkg, монтирани със средствата на системата, а след завършване на приложението — демонтирани. (Може би файловият мениджър би могъл да поставя файлове .hpkg в образи на приложения, автоматично или по искане на потребителя — подобно на когато прехвърляш приложение в мрежов каталог или външен диск. Това наистина е песен! Или по-точно поезия — хайку.) От друга страна, потребителят може да пожелае да инсталира съдържанието на образа под формата на файлове.hpkg, след което те ще се обновяват и обработват точно както ако бяха инсталирани чрез HaikuDepot… Нужна е мозъчна атака).

Цитата от г-н waddlesplash:

Стартирането на приложения от външни дискове или мрежови каталози потенциално може да бъде полезно. А добавянето на възможността за конфигуриране на повече „зони“ за pkgman определено ще бъде добра функция.

Подобна система ще използва предимствата на hpkg, каталогите и образите на приложения. Те са добри и поотделно, но заедно ще станат непобедими.

Заключение

За Haiku има инфраструктура, предоставяща прост и изтънчен потребителски интерфейс за PC, и далеч надхвърляща това, което обикновено се предоставя за PC на Linux. Системата за пакети .hpkg — един от тези примери, но останалите части на системата също са пронизани от изтънченост. Въпреки това, правилната поддръжка на каталогите и образите на приложенията биха били от полза за Haiku. Как да го направим най-добре — заслужава да се обсъди с хора, които познават Haiku, нейната философия и архитектура много по-добре от мен. В края на краищата ползвам Haiku малко над седмица. Но все пак, вярвам, че този свеж поглед ще бъде полезен за дизайнерите, разработчиците и архитектите на Haiku. Поне аз с радост ще бъда за тях „спаринг-партньор“. Имам над 10 години практически опит с каталози и комплекти приложения за Linux и бих искал да намеря приложение за тях в Haiku, за концепция, която, по мое мнение, е идеална за тях. Предложените от мен потенциални решения не са единствено верните за проблемите, които описах, и ако екипът на Haiku реши да намери други, по-елегантни — абсолютно съм за. По принцип, вече обмислям идея как да направя системата hpkg още по-вълнуваща, без да променям начина, по който работи. Оказва се, че екипът на Haiku отдавна е мислил за комплектите приложения при внедряване на системата за управление на пакети, но за съжаление, (както ми се струва) идеята е станала „остаряла“. Може би е време да я възродим?

Опитайте сами! Проектът Haiku предоставя образи за зареждане от DVD или USB, генерирани ежедневно.
Имате ли въпроси? Присъединете се към нашия руски telegram-канал.

Преглед на грешките: Как да си простреляте крака в C и C++. Сборник рецепти Haiku OS

От автора превод: това е осмата и последна статия от цикъла за Haiku.

Списък на статии: Първата Втора Трети Четвърта Пета Шеста Седма

Само регистрирани потребители могат да участват в анкетата. Влезте, моля.