🥇Нещо още: пакети приложения 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 файловете и задава им изпълнимост. В чист вид, не е най-доброто решение, тъй като няма да работи "изкара кутията". Linux дистрибуции не предоставят този сървис, следователно, за потребителите "изкара кутията" всичко е лошо.
Потребителите на Linux очакват новото приложение да има икона в менюто за стартиране. На системата не може да се каже: "Виж, ново приложение, нека работи". Вместо това, съгласно спецификацията XDG, трябва да копирате файла .desktop в необходимото място в /usr за обща система инсталация или в $HOME за индивидуална. Иконите с определени размери, съгласно спецификацията XDG, трябва да се поставят в определени места в usr или $HOME, след което трябва да стартирате команди в работната среда за обновяване на кеша на иконите или да се надявате, че мениджърът на работната среда ще разбере и автоматично всичко ще открие. Подобно е и с MIME типовете. Като обходен вариант, се предлага да се използва същият сървис, който освен задаването на индикатора за изпълнимост, ще копира иконите и други неща от AppImage в необходимите места, съгласно XDG. При изтриване или преместване, сървисът предполагаемо ще почиства всичко. Разбира се, има разлики в поведението на всяка работна среда, в графичните файлови формати, размери, места на съхранение и методи за обновяване на кешовете, което създава проблем. Съкращено, този метод - е „костил“.
Ако горепосоченото не е достатъчно, в файловия мениджър все още няма икона за AppImage. В света на Linux все още не е взето решение за внедряване на 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:

Да, имаме отговор на въпроса: просто ще поддържаме тези приложения толкова дълго, колкото е необходимо, докато някой не успее да прочете правилно файловите им формати или да осигури функционалност 1:1. Нашето желание да поддържаме работата на приложенията от 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 има инфраструктура, която предоставя прост и изтънчен потребителски интерфейс за ПК, и далеч надхвърля това, което обикновено се предоставя за ПК в Linux. Системата за пакети .hpkg — един от тези примери, но останалите части на системата също са пропити с изтънченост. Все пак, Haiku би спечелила от правилната поддръжка на каталозите и образите на приложенията. Как най-добре да се направи това — струва си да се обсъди с хора, които познават Haiku, нейното философия и архитектура много по-добре от мен. В крайна сметка използвам Haiku малко повече от седмица. Но все пак смятам, че този свеж поглед ще бъде полезен за дизайнерите, разработчиците и архитектите на Haiku. Най-малкото, с радост ще бъда „sparring partner“ за тях. Имам над 10 години практически опит с каталозите и комплектите приложения за Linux и бих искал да намеря приложение за тях в Haiku, за концепцията на която, според мен, те подхождат идеално. Предложените от мен потенциални решения не са единствено правилни за проблемите, които описах, и ако екипът на Haiku реши да намери други, по-елегантни, — само ще се радвам. hpkg още по-удивителна, без да променя начина й на работа. Оказва се, че екипът на Haiku отдавна е мислил за комплектите приложения при внедряването на системата за управление на пакети, но за съжаление, (изглежда) идеята е отишла в „остарели“. Може би е време да я възродим?

Опитайте сами! В края на краищата проектът Haiku предлага образи за зареждане от DVD или USB, генерирани ежедневно.
Имате въпроси? Каним ви в рускоезичния телеграм канал.

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

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

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

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