Submitted by The way Haiku handles package management and its alternative approach to an “immutable system” is one of those ideas I find really cool. Here’s what it looks like from a desktop user’s perspective – there’s all the usual stuff like an “app store”, package updater, repositories of packages and so on.
It’s all there and works well – it’s easily as smooth as any desktop Linux experience. However, it’s the implementation details behind the scenes that make it so interesting to me. Haiku takes a refreshingly new approach to package management.
A deep dive into Haiku’s surprisingly robust and full-featured package management system.
This is an interesting read. The idea of each user having its own set of packages is something I’m amazed hasn’t been implemented in any Linux distribution.
BeOS supposedly had much of the plumbing for multi-user built in, and I guess Haiku does to, I would like to see it implemented.
That is one of the features of Flatpak, but it’s really only for GUI applications. With shell accounts, it’s “Admins rule, Users drool!” in Linux-land unfortunately. The user has a chance if a compiler is installed or can bootstrap one, but that’s not a given.
Interestingly enough, Flatpak is one of the technologies which makes Fedora’s immutable desktop, Silverblue, possible.
The other is toolbox containers.
I remember that tool. It would be a nice feature.
And then, remote desktops!
The similar solution for CLI apps is to use distrobox or toolbox, https://github.com/containers/toolbox.
That’s much more elegant then I thought it was. I originally thought it was like Ubuntu snaps or PC-BSD’s self-contained package format.
I still like the way Flatpak handles dependencies though. It saves space when applications use the same library.
as the package is contained, modifications is rather annoying. it is a minor point on another great package system.
Las time i had difficulties with hpkg was almost ten years with a package that had the settings files in the package and thus did not save settings.
That sounds like an authoring problem. Why did the developer put a settings file inside an immutable package, rather than some other more sensible user accessible area? I’m sure there was a reason, (maybe even that there wasn’t a clearly or obviously defined alternative), as there often is in these things, but it should be treated like a bug, and fixed.
AAARRRHHH! I ran into a program like that too. Almost all the programs I installed created settings inside the setting folder where you could modify them if needed, but one used the settings inside the package ONLY. You could change the settings while the program was running. But the moment you restarted the program you found yourself back to the original settings. WHAT WERE THEY THINKING?