Що ще: пакети додатків Haiku?

TL, д-р: чи може 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 монтуються, і ніколи не встановлюються у звичайному розумінні.

AppImage за більш ніж 10 років існування отримав деяку привабливість і популярність: сам Лінус Торвальдс публічно схвалив його, а поширені проекти (наприклад, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) прийняли його як основний спосіб поширення безперервних чи нічних збірок, не що заважають встановленим або не встановленим програмам користувачів. Однак робочі оточення та дистрибутиви Linux найчастіше як і раніше чіпляються за традиційну, централізовану модель поширення на основі супроводжуючих та/або просувають власні корпоративні бізнес та/або інженерні програми на основі Flatpak (RedHat, Fedora, GNOME) та Швидко (Canonical, Ubuntu). Доходить до смішного.

Як все працює

• Кожен AppImage містить у собі 2 частини: маленький виконується по подвійному клацанню 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, копіювати їх з 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 пакети додатків, зрештою?

Це підводить до великого питання. Якби на Haiku створити систему типу AppImage виявилося набагато простіше, ніж на 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, чи каталоги та комплекти додатків зможуть тут допомогти? Я гадаю, зможуть.

Відповідно до mr. waddlesplash:

Так, у нас є відповідь на питання: ми просто будемо підтримувати ці програми стільки, скільки потрібно, поки хтось не зможе правильним способом прочитати їх формати файлів або забезпечити функціональність один до одного. Наше прагнення підтримувати роботу додатків BeOS R5 на Haiku — прямий доказ цього…

Це точно!

Який план дій має ухвалити Haiku?

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

• Системне ПЗ використовує .hpkg
• Для ПЗ, що найчастіше використовується (особливо для того, якому треба запланувати плаваючі випуски) використовується .hpkg (Приблизно 80% всіх випадків)
• Деякі, встановлені через .hpkg, програми виграють під час переходу на інфраструктуру з каталогами додатків (наприклад, QtCreator): вони поширюватимуться як .hpkg, як і раніше.

mr. waddlesplash пише:

Якщо все, що потрібно, це перегляд програм у /system/apps, натомість треба зробити каталоги в Deskbar більш керованими для користувачів, оскільки /system/apps не призначений для того, щоб користувачі регулярно відкривали та дивилися його (на відміну від MacOS). Для таких ситуацій у Haiku інша парадигма, але цей варіант, за ідеєю, є прийнятним.

• Haiku отримує інфраструктуру для запуску образів додатків, нічних, безперервних та тестових збірок програмного забезпечення, а також на випадки, коли користувач бажає його «заморозити в часі», для приватного та внутрішнього програмного забезпечення, та інших особливих випадків використання (близько 20% від усіх). Ці образи містять необхідні для запуску програми файли .hpkg, що монтуються засобами системи, а після завершення програми - що розмонтовуються. (Можливо, файловий менеджер міг би поміщати файли .hpkg в образи програм, автоматично або на вимогу користувача — ну, як коли перетягуєш програму на мережевий каталог або зовнішній диск. Це просто пісня! А точніше, поезія — хайку.) З іншого боку, користувач може захотіти встановити вміст образу у вигляді файлів.hpkg, Після чого вони будуть оновлюватися і оброблятися так само, як би були встановлені через HaikuDepot ... Треба провести мозковий штурм).

Цитата від mr. waddlesplash:

Запуск програм із зовнішніх дисків або мережевих каталогів потенційно може бути корисним. А додавання можливості налаштування більшої кількості «зон» для pkgman безперечно стане гарною функцією.

Подібна система використовуватиме переваги hpkg, каталогів та образів додатків. Вони гарні і окремо, але разом стануть непереможними.

Висновок

Для Haiku є інфраструктура, що надає простий і витончений інтерфейс для ПК, і далеко виходить за рамки того, що зазвичай надається для ПК на Linux. Система пакетів .hpkg — один із таких прикладів, але решта систем також просочена витонченістю. Тим не менш, від правильної підтримки каталогів та образів додатків Haiku би виграла. Як це найкраще зробити — варто обговорити з людьми, які знають Haiku, її філософію та архітектуру набагато краще за мене. Зрештою я користуюсь Haiku трохи більше тижня. Проте, я вважаю, що цей свіжий погляд виявиться корисним дизайнерам, розробникам та архітекторам Haiku. Принаймні я з радістю спонукаю для них «спаринг-партнером». У мене більше 10 років практичного досвіду роботи з каталогами та комплектами додатків для Linux, і мені хотілося б знайти їм застосування для Haiku, для концепції якої, на мою думку, вони ідеально підходять. Запропоновані мною потенційні рішення не є єдино вірними для проблем, які я описав, і якщо команда Haiku вирішить знайти інші, більш витончені, — я тільки всіма руками за. В принципі, я вже обмірковую ідею того, як створити систему hpkg ще дивовижнішою, не змінюючи способу її роботи. Виявляється, команда Haiku давно думала про комплекти додатків при впровадженні системи керування пакетами, але, на жаль, (на мою думку) ідея пішла в «застарілі». Можливо, настав час відродити її?

Спробуйте самі! Адже проект Haiku надає образи для завантаження з DVD або USB, що формуються щодня.
Постали питання? Запрошуємо вас до російськомовної telegram-канал.

Огляд помилок: Як вистрілити собі в ногу у C та C++. Збірник рецептів Haiku OS

Від автора перекладу: це восьма та заключна стаття з циклу про Haiku.

Список статей: перша Друга третя четверта п'ята шоста Сьома

Тільки зареєстровані користувачі можуть брати участь в опитуванні. Увійдіть, будь ласка.

Чи є сенс портувати систему hpkg для Linux?

• Так

• Ні

• Вже реалізовано, напишу у коментарях

Проголосували 20 користувачів. Утрималися 5 користувачів.

Джерело: habr.com