{"id":37830,"date":"2019-10-31T22:20:00","date_gmt":"2019-10-31T19:20:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/koe-chto-eshhe-pakety-prilozhenij-haiku\/"},"modified":"2019-10-31T22:20:00","modified_gmt":"2019-10-31T19:20:00","slug":"koe-chto-eshhe-pakety-prilozhenij-haiku","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/koe-chto-eshhe-pakety-prilozhenij-haiku","title":{"rendered":"Something else: Haiku application packages?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Something<\/p>\n

<\/p>\n

TL;DR<\/strong>: can Haiku receive proper support for application packages, such as application catalogs (like .app<\/code> on Mac) and\/or application images (Linux AppImage<\/code>)? I think this would be a worthy addition that is easier to implement compared to other systems, since most of the infrastructure is already in place.<\/p>\n

<\/a><\/noindex><\/p>\n

A week ago<\/a><\/noindex> I discovered Haiku, a surprisingly good system. And since I've been interested in application catalogs and images (inspired by the simplicity of Macintosh) for a long time, it\u2019s no wonder that the idea popped into my head\u2026<\/p>\n

<\/p>\n

For full disclosure: I am the creator and author of AppImage, a Linux application distribution format aimed at the simplicity of Mac, giving complete control to application authors and end-users (if you want to know more\u2014see wiki<\/a><\/noindex> and documentation<\/a><\/noindex>).<\/p>\n

<\/p>\n

What if we create AppImage for Haiku?<\/h2>\n

<\/p>\n

Let\u2019s ponder a bit, purely theoretically: what needs to be done to get AppImage<\/a><\/noindex>, or something similar, on Haiku? There\u2019s no rush to create something right away, as the system currently available in Haiku works surprisingly well, while an imagined experiment would still be interesting. It also showcases the sophistication of Haiku compared to Linux desktop environments, where such things can be incredibly difficult (I have the right to say this: I've been struggling with debugging for 10 years).<\/p>\n

<\/p>\n

\"Something
\nOn Macintosh System 1, each application was a separate file, «managed» in Finder. Using AppImage, I'm trying to recreate that same user experience on Linux.<\/em><\/p>\n

<\/p>\n

First of all, what is AppImage? It\u2019s a system for the distribution of third-party applications (for example, Ultimaker Cura<\/a><\/noindex>), allowing applications to be released whenever and however they want: there is no need to know the intricacies of various distributions, build policies, or build infrastructure, no need for support maintainers, and they don\u2019t dictate to users what (not) to install on their computers. AppImage should be understood as something akin to a package for Mac formatted .app<\/code> inside a disk image .dmg<\/code>. The main difference is that applications are not copied but remain within the AppImage at all times, similar to how Haiku packages .hpkg<\/code> are mounted and never installed in the traditional sense.<\/p>\n

<\/p>\n

AppImage has gained some appeal and popularity over its more than 10 years of existence: Linus Torvalds himself publicly endorsed it, and popular projects (for example, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) have adopted it as the primary method for distributing continuous or nightly builds without interfering with users' installed or uninstalled applications. However, desktop environments and Linux distributions often still cling to the traditional, centralized distribution model based on packages and\/or promote their own corporate business and\/or engineering programs. Flatpak<\/a><\/noindex> (RedHat, Fedora, GNOME) and Snappy<\/a><\/noindex> (Canonical, Ubuntu). It reaches the point of absurdity.<\/a><\/noindex>.<\/p>\n

<\/p>\n

How it works<\/h3>\n

<\/p>\n