Нешто друго: пакети со апликации за Хаику?

TL; ДР: Дали Хаику може да добие соодветна поддршка за пакетите со апликации, како што се директориумите со апликации (како .app на Mac) и/или слики од апликации (Linux AppImage)? Мислам дека ова би било достојно дополнување што е полесно да се имплементира правилно од другите системи бидејќи поголемиот дел од инфраструктурата е веќе поставена.

Пред една недела Го открив Хаику, неочекувано добар систем. Па, бидејќи долго време ме интересираат директориуми и слики од апликации (инспирирани од едноставноста на Macintosh), не е чудно што ми дојде идеја...

За целосно разбирање, јас сум креатор и автор на AppImage, формат за дистрибуција на апликации на Linux кој има за цел едноставност на Mac и дава целосна контрола на авторите на апликациите и крајните корисници (ако сакате да дознаете повеќе, видете вики и документација).

Што ако направиме AppImage за хаику?

Да размислиме малку, чисто теоретски: што треба да се направи за да се добие AppImage, или нешто слично, на хаику? Не е неопходно да се создаде нешто во моментов, бидејќи системот што веќе постои во Хаику работи неверојатно, но имагинарен експеримент би бил убав. Исто така, ја покажува софистицираноста на Хаику, во споредба со десктоп околините на Linux, каде што таквите работи се ужасно тешки (имам право да го кажам тоа: се борам со дебагирање 10 години).

На Macintosh System 1, секоја апликација беше посебна датотека „управувана“ во Finder. Користење на AppImage Се обидувам да го рекреирам истото корисничко искуство на Linux.

Прво, што е AppImage? Ова е систем за ослободување апликации од трети страни (на пример, Ултимајкер Кура), дозволувајќи им на апликациите да се објавуваат кога и како сакаат: нема потреба да се знаат спецификите на различни дистрибуции, да се градат политики или да се изгради инфраструктура, не е потребна поддршка за одржување и тие не им кажуваат на корисниците што (не) можат да инсталираат на нивните компјутери. 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 го содржи товарот на апликацијата и сè што е потребно за нејзино извршување, што не може да се смета за дел од стандардната инсталација за секој прилично неодамнешен целен систем (дистрибуција на Линукс). Исто така, содржи метаподатоци, како што се името на апликацијата, иконите, типовите MIME, итн., итн.

• Кога го работи корисникот, траењето користи FUSE и squashfuse за да го монтира датотечен систем, а потоа се справува со извршување на некоја влезна точка (наречена AppRun) во монтираниот AppImage.
  Датотечниот систем се демонтира откако ќе заврши процесот.

Се чини дека сè е едноставно.

И овие работи комплицираат сè:

• Со таква разновидност на дистрибуции на Линукс, ништо „во правилниот ум“ не може да се нарече „дел од стандардната инсталација за секој нов целен систем“. Работиме околу ова прашање преку градење исклучена листа, овозможувајќи ви да одредите што ќе биде спакувано во 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

Постигнувањето на нивото на софистицираност длабоко вткаено во работната средина на Хаику е тешко, ако не и невозможно, поради спецификациите XDG од freedesktop.org за вкрстена работна површина, како и имплементации на менаџери за работна површина врз основа на овие спецификации. Како пример, можеме да наведеме една икона за Firefox низ целиот систем: очигледно, авторите на XDG не ни помислувале дека корисникот може да има инсталирано неколку верзии на истата апликација.

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

Се прашував што светот на Линукс може да научи од Mac OS X за да избегне заебување на системската интеграција. Ако имате време и се занимавате со ова, задолжително прочитајте што рече Арнауд Гурдол, еден од првите инженери на Mac OS X:

Сакавме да го направиме инсталирањето на апликацијата лесно како влечење на иконата на апликацијата од некаде (сервер, надворешен диск) на дискот на вашиот компјутер. За да го направите ова, пакетот со апликации ги складира сите информации, вклучувајќи ги иконите, верзијата, типот на датотека што се обработува, типот на шеми за URL што системот треба да ги знае за да ја обработи апликацијата. Ова исто така вклучува информации за „централно складирање“ во базата на податоци за услуги на икони и услуги за стартување. За поддршка на перформансите, апликациите се „откриени“ на неколку „добро познати“ места: системски и кориснички директориуми со апликации, и некои други автоматски ако корисникот се движи до Пронаоѓачот во директориумот што ја содржи апликацијата. Во пракса ова функционираше многу добро.

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

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

Дали Хаику доаѓа на помош?

И уште нешто: Linux платформите како основа на десктоп околините имаат тенденција да бидат толку недоволно специфицирани што многу работи кои се прилично едноставни во конзистентен систем со целосен стак се фрустрирачки фрагментирани и сложени во Linux. Посветив цел извештај на прашања поврзани со платформата Линукс за десктоп околини (упатените програмери потврдија дека сè ќе остане вака уште долго време).

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

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

Мило ми е што гледам хаику!

Хаику прави сè неверојатно едноставно

Иако наивниот пристап за „пренесување“ на AppImage на Хаику е едноставно да се обидеме да изградиме (главно runtime.c и сервисирање) неговите компоненти (што можеби е дури и возможно!), ова нема да обезбеди голема корист за Хаику. Затоа што, всушност, повеќето од овие проблеми се решаваат во Хаику и се концептуално издржани. Хаику ги обезбедува токму градежните блокови на системската инфраструктура што толку долго ги барав во десктоп околините на Linux и не можев да верувам дека ги нема. Имено:

Верувале или не, ова е нешто што многу корисници на Линукс не можат да го надминат. На Хаику сè се прави автоматски!

• ELF-датотеките кои немаат бит за извршност добиваат автоматски кога ќе се кликнат двапати во менаџерот на датотеки.
• Апликациите може да имаат вградени ресурси, како што се иконите, кои се прикажани во менаџерот на датотеки. Нема потреба да копирате куп слики во посебни директориуми со икони и затоа нема потреба да ги чистите по бришењето или преместувањето на апликацијата.
• Постои база на податоци за поврзување на апликации со документи, нема потреба да копирате датотеки за ова.
• Во директориумот lib/ до извршната датотека, библиотеките стандардно се пребаруваат.
• Нема бројни дистрибуции и десктоп околини; што и да работи, функционира насекаде.
• Не постои посебен модул за извршување што е различен од директориумот Апликации.
• Апликациите немаат вградени апсолутни патеки до нивните ресурси; тие имаат посебни функции за одредување на локацијата при извршување.
• Воведена е идејата за слики од компресирани датотечен систем: ова е кој било hpkg пакет. Сите тие се монтирани од кернелот.
• Секоја датотека се отвора од апликацијата што ја создала, освен ако експлицитно не наведете поинаку. Колку е ова кул!

Две png датотеки. Забележете ги различните икони што покажуваат дека тие ќе бидат отворени од различни апликации кога ќе се кликнат двапати. Забележете го и паѓачкото мени „Отвори со:“ каде што корисникот може да избере индивидуална апликација. Колку едноставно!

Изгледа дека многу од патериците и решенијата што ги бара AppImage на Linux стануваат непотребни на Haiku, кој ја има едноставноста и софистицираноста во својата суштина што го прави да се справи со повеќето од нашите потреби.

Дали на Хаику сепак му требаат пакети со апликации?

Ова води до големо прашање. Кога би било полесно да се создаде систем како AppImage на Хаику отколку на Линукс, дали би вредело да се направи? Или Хаику, со својот систем на пакети hpkg, ефикасно ја елиминира потребата да се развие таква идеја? Па, за да одговориме, треба да ја разгледаме мотивацијата зад постоењето на AppImages.

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

Ајде да го погледнеме нашиот краен корисник:

• Сакам да инсталирам апликација без да барам администраторска (root) лозинка. Нема концепт на администратор на Хаику, корисникот има целосна контрола бидејќи тоа е личен систем! (Во принцип, можете да го замислите ова во режим на мултиплеер, се надевам дека програмерите го прават едноставно)
• Сакам да ги добивам најновите и најдобри верзии на апликации, без да чекам да се појават во мојата дистрибуција (најчесто тоа значи „никогаш“, барем освен ако не го ажурирам целиот оперативен систем). На Хаику тоа се „реши“ со пловечки изданија. Ова значи дека е можно да се добијат најновите и најдобри верзии на апликации, но за да го направите ова треба постојано да го ажурирате остатокот од системот, ефикасно претворајќи го во „подвижна цел“..
• Сакам неколку верзии на истата апликација рамо до рамо, бидејќи не постои начин да се знае што е скршено во најновата верзија, или, да речеме, јас, како веб-развивач, треба да ја тестирам мојата работа под различни верзии на прелистувачот. Хаику го решава првиот проблем, но не и вториот. Ажурирањата се враќаат назад, но само за целиот систем; невозможно е (колку што знам) да се извршуваат, на пример, неколку верзии на WebPositive или LibreOffice во исто време.

Еден од програмерите пишува:

Во суштина, образложението е ова: случајот на употреба е толку редок што оптимизирањето за него нема смисла; третирањето како посебен случај во HaikuPorts изгледа повеќе од прифатливо.

• Треба да ги чувам апликациите таму каде што ми се допаѓаат, а не на мојот диск за стартување. Честопати ми снемува простор на дискот, па треба да поврзам надворешен диск или мрежен директориум за складирање на апликации (сите верзии што ги имам преземено). Ако поврзам таков диск, ми треба апликациите да се стартуваат со двоен клик. Хаику зачувува стари верзии на пакети, но не знам како да ги преместам на надворешен диск или како подоцна да стартувам апликации од таму.

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

Технички, ова е веќе возможно со командата mount. Секако, ќе направиме GUI за ова штом ќе имаме доволно заинтересирани корисници.

• Не ми требаат милиони датотеки расфрлани низ датотечниот систем со кои не можам рачно да управувам. Сакам една датотека по апликација која лесно можам да ја преземам, преместувам, избришам. На Хаику овој проблем се решава со помош на пакети .hpkg, кои пренесуваат, на пример, python, од илјадници датотеки во една. Но, ако постои, на пример, Scribus кој користи python, тогаш треба да се справам со најмалку две датотеки. И морам да се грижам да чувам верзии од нив што функционираат една со друга.

Повеќе верзии на AppImages работат рамо до рамо на истиот Linux

Перспектива на развивач на апликации

Ајде да погледнеме од гледна точка на развивач на апликации:

• Сакам да го контролирам целото корисничко искуство. Не сакам да зависам од оперативен систем за да ми каже кога и како треба да објавувам апликации. Хаику им овозможува на програмерите да работат со сопствените складишта за hpkg, но тоа значи дека корисниците ќе мора да ги постават рачно, што ја прави идејата „понепривлечна“.
• Имам страница за преземање на мојата веб-страница каде што дистрибурам .exe за Windows, .dmg за Mac и .AppImage за Linux. Или можеби сакам да го монетизирам пристапот до оваа страница, сè е можно? Што да ставам таму за хаику? Датотеката е доволна .hpkg со зависности само од HaikuPorts
• Мојот софтвер бара специфични верзии на друг софтвер. На пример, познато е дека Krita бара закрпена верзија на Qt, или Qt што е фино подесена на одредена верзија на Krita, барем додека закрпите не се вратат назад во Qt. Можете да го спакувате вашиот сопствен Qt за вашата апликација во пакет .hpkg, но најверојатно ова не е добредојдено.

Редовна страница за преземање апликации. Што да објавам овде за хаику?

Пакети со тестаменти (постои како директориуми за апликации како AppDir или .app во стил на Apple) и/или слики (во форма на силно модифицирани AppImages или .dmg од Apple) апликации корисен додаток на десктоп околината Haiku? Или ќе ја разреди целата слика и ќе доведе до фрагментација, па затоа ќе додаде сложеност? Јас сум растргнат: од една страна, убавината и софистицираноста на Хаику се засноваат на фактот дека обично постои еден начин да се направи нешто, а не многу. Од друга страна, поголемиот дел од инфраструктурата за каталози и/или пакети за апликации е веќе поставена, па системот вика за преостанатите неколку проценти да се снајдат.

Според инвеститорот г. прскање

На Linux тие (каталози и комплети за апликации, - прибл. преведувач) се најверојатно техничко решение за системски проблеми. Во Хаику претпочитаме едноставно да ги решаваме системските проблеми.

Што мислиш?

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

Чекај, ајде да направиме брза проверка на реалноста: всушност директориуми со апликации - веќе дел од Хаику:

Директориумите со апликации веќе постојат на Хаику, но сè уште не се поддржани во менаџерот на датотеки

Тие едноставно не се толку добро поддржани како, на пример, Macintosh Finder. Колку би било кул ако директориумот QtCreator има име и икона „QtCreator“ во горниот лев агол, што ја стартува апликацијата со двоен клик?

Малку порано јас веќе праша:

Дали сте сигурни дека можете да ги стартувате вашите децениски апликации денес кога сите продавници за апликации и складишта за дистрибуција заборавиле на нив и на нивните зависности? Дали сте уверени дека сè уште ќе можете да пристапите до вашата моментална работа во иднина?

Дали веќе има одговор од Хаику или дали каталозите и пакетите со апликации можат да помогнат овде? Мислам дека можат.

Според г. прскање со вода:

Да, го имаме одговорот на прашањето: ние едноставно ќе ги поддржуваме овие апликации онолку долго колку што е потребно додека некој не може да ги прочита нивните формати на датотеки на вистински начин или да обезбеди функционалност еден-на-еден. Нашата посветеност да ги поддржуваме апликациите BeOS R5 на Хаику е доказ за ова...

Ова е сигурно!

Каков курс на дејствување треба да преземе Хаику?

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

• Системски софтвер користи .hpkg
• За најчесто користениот софтвер (особено оние што треба да закажат повторливи изданија), користете .hpkg (приближно 80% од сите случаи)
• Некои инсталирани преку .hpkg, апликациите ќе имаат корист од преместувањето во инфраструктура на директориумот на апликации (на пр. QtCreator): тие ќе бидат дистрибуирани како .hpkg, како и досега.

г. Waddlesplash пишува:

Ако се што ви треба е да ги видите апликациите во /system/apps, наместо тоа, треба да ги направиме директориумите во Deskbar податливи за корисниците, бидејќи /system/apps не е наменет за редовно отворање и прегледување од корисниците (за разлика од MacOS). За такви ситуации, Хаику има поинаква парадигма, но оваа опција е, теоретски, прифатлива.

• Хаику добива инфраструктура за извршување слики од апликации, ноќни, континуирани и тест-изградби на софтвер, како и за случаи кога корисникот сака да го „замрзне навреме“, за приватен и внатрешен софтвер и други случаи за специјална употреба (околу 20% од сите). Овие слики ги содржат датотеките неопходни за извршување на апликацијата .hpkg, монтиран од системот, а откако ќе заврши апликацијата - демонтиран. (Можеби менаџерот на датотеки може да стави датотеки .hpkg во сликите на апликациите, автоматски или на барање на корисникот - добро, како кога влечете апликација во мрежен директориум или надворешен диск. Тоа е само песна! Или подобро кажано, поезија - хаику.) Од друга страна, корисникот можеби ќе сака да ја инсталира содржината на сликата во форма на датотеки.hpkg, по што ќе се ажурираат и обработуваат на ист начин како да се инсталирани преку HaikuDepot... Треба да направиме бреинсторм).

Цитат од г. прскање со вода:

Вклучувањето на апликации од надворешни дискови или мрежни директориуми може да биде потенцијално корисно. И додавањето на способноста за конфигурирање на повеќе „зони“ за pkgman дефинитивно ќе биде убава карактеристика.

Таквиот систем ќе ги искористи предностите на hpkg, директориуми и слики од апликации. Поединечно се добри, но заедно ќе станат непобедливи.

Заклучок

Хаику има рамка која обезбедува едноставно и софистицирано корисничко искуство за компјутерот, и оди многу подалеку од она што вообичаено се обезбедува за компјутерот со Linux. Пакет систем .hpkg е еден таков пример, но и остатокот од системот е проткаен со софистицираност. Сепак, Хаику ќе има корист од соодветната поддршка за директориуми и слики од апликацијата. Како најдобро да се направи ова, вреди да се разговара со луѓе кои го познаваат Хаику, неговата филозофија и архитектура многу подобро од мене. На крајот на краиштата, јас користам хаику нешто повеќе од една недела. Сепак, верувам дека дизајнерите, програмерите и архитектите на Хаику ќе имаат корист од оваа нова перспектива. Во најмала рака, би бил среќен да бидам нивен „спаринг партнер“. Имам повеќе од 10 години практично искуство со каталози и пакети на апликации за Linux, и би сакал да најдам употреба за нив во Хаику, за што мислам дека совршено се вклопуваат. Потенцијалните решенија што ги предложив во никој случај не се единствените точни за проблемите што ги опишав, и ако тимот на Хаику одлучи да најде други, поелегантни, јас сум за тоа. Во суштина, веќе размислувам за идејата како да направам систем hpkg уште поневеројатно без промена на начинот на кој функционира. Излегува дека тимот на Хаику долго време размислувал за пакети на апликации при имплементирање на систем за управување со пакети, но за жал (мислам) идејата стана „застарена“. Можеби е време да го оживееме?

Пробајте го сами! На крајот на краиштата, проектот Хаику обезбедува слики за подигање од ДВД или USB, генерирани секојдневно.
Дали имате прашања? Ве покануваме на рускиот јазик телеграмски канал.

Преглед на грешка: Како да си пукате во стапалото во C и C++. Колекција на рецепти за Хаику ОС

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

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

Само регистрирани корисници можат да учествуваат во анкетата. Најави се, вие сте добредојдени.

Дали има смисла да се пренесе системот hpkg на Linux?

• Да

• Не

• Веќе имплементиран, ќе напишам во коментарите

Гласаа 20 корисници. 5 корисници беа воздржани.

Извор: www.habr.com