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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Постигането на нивото на сложност, дълбоко вплетено в работната среда на Haiku, е трудно, ако не и невъзможно, поради спецификациите. XDG от freedesktop.org за крос-десктоп, както и за имплементации на десктоп мениджъри, базирани на тези спецификации. Една единствена системна икона на 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.

Хайку идва ли на помощ?

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

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

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

Хубаво е да видя Хайку!

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

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

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

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

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

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

Нуждае ли се Haiku изобщо от пакети с приложения?

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

Перспективата на потребителя

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

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

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

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

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

Коментар на програмиста:

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

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

Няколко версии на AppImages, работещи една до друга на една Linux

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

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

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

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

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

Според разработчика г-н. waddlesplash

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

Какво мислиш?

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

Чакай, нека направим бърза проверка на реалността: директории на приложения — вече е част от Хайку:

Директориите с приложения вече съществуват в Haiku, но все още не се поддържат във файловия мениджър.

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

Малко по-рано аз вече попита:

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

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

Според г-н. waddlesplash:

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

Това е със сигурност!

Какъв курс на действие трябва да предприеме Хайку?

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

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

Г-н Уодълсплаш пише:

Ако всичко, което искате, е да преглеждате приложения в /system/apps, вместо това трябва да направим директориите в Deskbar по-лесни за управление от потребителите, защото /system/apps Не е предназначен за редовно отваряне и преглеждане от потребителите (за разлика от macOS). Haiku има различна парадигма за подобни ситуации, но все пак е приемлив вариант.

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

Цитат от г-н Уодълсплаш:

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

Такава система би се възползвала от силните страни на hpkg, каталозите и изображенията на приложенията. Въпреки че всеки от тях е добър сам по себе си, заедно те биха били непобедими.

Заключение

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

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

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

От автор Превод: Това е осмата и последна статия от поредицата „Хайку“.

Списък на статиите: Първи Вторият Третият четвърти пети шести Седмо

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