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

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) и пъргав (Canonical, Ubuntu). Идва абсурдно.

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

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

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

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

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

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

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

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

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

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

Радвам се да видя Хайку!

Хайку прави всичко невероятно просто

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

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

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

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

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

Все пак има ли Haiku нужда от пакети за приложения?

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

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

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

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

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

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

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

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

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

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

Множество версии на AppImages, работещи една до друга на един и същи Linux

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

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

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

Страница за редовно изтегляне на приложение. Какво трябва да публикувам тук за хайку?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

г-н. waddlesplash пише:

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

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

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

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

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

Заключение

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

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

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

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

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

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

Има ли смисъл системата hpkg да се пренася към Linux?

• Да

• Не

• Вече е изпълнено, ще пиша в коментарите

20 потребители гласуваха. 5 потребители се въздържаха.

Източник: www.habr.com