HAKILO (ex HUPE) + HakiPKG by s40in


Yes, the package mount points are /system and /home/config in the current Haiku. We left everything else free for the user.

But a clean hierarchy in /system would be great already, don’t you think?


We’ve replaced /boot/apps with /boot/system/apps for a cleaner hierarchy, as @PulkoMandy said. But you can install packages in ~/config already, or mount them outside of /system using mount -t packagefs file.hpkg path/to/... – in fact this is how HaikuPorter constructs chroots.


non-packaged is kind of a misfeature… it makes me cringe every time I hear someone mention it.

It’s the thing that bothers me the most…As far as I know there is no reason the packaged files couldn’t have been put into a special “packaged” directory and the normal file system paths remained R/W. Basically non-pacakged puts the burden on the user… with something that the package management system should have been designed to handle transparently.

Runtime overhead is also bad, not terrible but bad, but I expect that will get fixed. One thing to consider is most software for Haiku is small… but most software on other OSes is gigantic, and the packagefs may not like that, it isn’t uncommon for windows software to be several to tens of GB. A bit off topic but perhaps a worst case scenario 100GB+ package would be worthwhile to test… just to see if it breaks anything. Or thousands of fake packages etc…

On the upside this month’s report was pretty awesome. Edited: to not give people grammar siezures.


Because non-packaged is intended to be a second-class citizen, with packaged as the first-class one.

AFAICT, the packagefs memory consumption is due to its internal stat cache. So file size is largely irrelevant; number of files is the key here.


I’m supprised you don’t see how serious a problem that is. That’s a severe design problem.

As far as the stat cache… that makes sense at least. I looked at the packagefs code but it couldn’t quite follow all of it, it seems like a lot of it is handled at runtime and so that shows up as runtime bloat when it could just be statically cached in the package itself rather than ending up on the heap… but that probably goes against how it’s designed/written currently. I’m sure if I go back and look at it again I’ll understand it a bit better…

I guess a if KiCad is packaged someday… it would be a rather severe case then, actually not entirely sure you’d want the symbol and footprint libraries to be in the package though… since they are intended to be potentially updatable via git.


The initial design was that there would be an overlay between the packaged and non-packaged directories. This was implemented at some point, but we found two big limitations:

  • Performance was not acceptable. It was just too slow as any file access would need to check the writable parts first, and then the packages. So, a 2x speed penalty basically
  • And the more important problem, it was confusing. It is not clear if a file belongs to a package or has been modified. It is not clear what happens if you modify a file and then update or uninstall the package it belongs to. It is not clear how to accurately represent this in DiskUsage.

This is why we introduced the non-packaged directories. They are not second-class, they are the way for the user (or sysadmin, in the case of /system) to customize their system. They should always be used in priority to the packaged ones (if that’s not the case for something, please open a bugreport).


Perhaps there is an idea that can suit everyone. But it is natural for those who are not 100% satisfied with the current situation.

  1. What are “system files” should be stored in hpkg packages in the/system folder. These are all the packages that are stored in the Haiku repository (not HaikuPorts). Auto updates are working. The Haiku system remains unchanged.

  2. Turn off HaikuPorts and other third-party repositories if they install programs in the /system folder.

  3. We set all other programs as we want: unpacked in /apps, in subfolders in /apps, GoboLike folders etc. Perhaps this would require “another user space package system,” or scripts like HakiPKG, or replacing the HaikuPorts build script engine.

I like this compromise solution.

P.S. We will always have the opportunity to fully unpack the system, in extreme cases :slight_smile:


But in this case, all those packages that Haiku needs should be mainly repositories.
Now the important components are in HaikuPorts. It is not right.


Why not? They are not managed by the haiku team, so eventually we kept things simple with a single repo. We could do more repos, but the Haiku team has no time for managing their own (we thought about it, and we gave up).

There are some other repositories already, for various reasons, the main one is they are not building package from recipes using haikuports. The initial idea was that there would be a lot of repositories like this, for example we expected something would replace haikuware (or haikuware itself would serve software in a repo). So far we don’t have a clear winner on that aspect, so haikuports it is. And since it does a reasonable job of keeping up with available software, it seems most users are happy enough with this.

I still don’t get why you would need to modify the files from distributed software directly. To me, if you need this, the software is probably badly designed or badly packaged. And in that case, the solution is to fix it! Which you can do easily by extracting the packages, making the changes, and then repackaging it. Of course it’s a bit annoying for testing, but that’s why we have non-packaged so you can put temporary versions there. Or just use haikuports to create a temporary packaged dir for testing, in an automated way.

This is the essence of what works with this package system. It forces people to make package clean and share their changes. It allowed us to build a working haikuports repo, with properly declared dependencies. One may think dependencies are a bad idea. I agree. For Haiku native apps there shouldn’t be any dependencies. But it opened the way for ported apps, like it or not. Things like Qt and LibreOffice wouldn’t be possible in a sustainable way without this. And let’s be honest, in the current state of native apps, we wouldn’t be a serious OS without them.


I want to understand that there is a minimum Haiku. That without which it can not work. Now it is not very clear. There is no system repository where all the important components would be.

  1. I love that each program is in its own folder, and not in the one folder with /bin, /lib.
  2. Sometimes it’s convenient for me to have multiple versions of the same program.
  3. I like the experience of using BeOS. I do not want to change it. And perhaps this is the most important thing for me.

In this sense, I like the developers of RISCOS. An OS with a long history is being developed open source, and they do not change their traditions.
This is not a reproach to the haiku team. Simply, there are options for development, regardless of current trends.


The first attempt to create a decorator.
Simple HakiDecorator


Download HakiDecorator 1.0 (32bit only)







Just an attempt to simplify, or make something little different.


Zeta OS Decorators Looks kinda like the bottom one.


Of the five designs, my favorite is the third one. It’s clear the left is close and the right is zoom or expand. The second and fifth designs kinda sit well with me too. :slightly_smiling_face:


Cool, can we have a x64 version please?


Great options. The middle version is good. Maybe I will do this later

A bit later. Now there is no possibility to install haiku x64


Another decor that I started to do earlier, but finished later :slight_smile:

CDE like (unix DE )

Variant with colors from CDE

Download HakiCDEdecorator for 32bit


Ordinary colors



Standard warning about downloading binaries from some site on the internet applies.


Very strange. probably you have very tough policies in the web browser.