HAKILO (ex HUPE) + HakiPKG by s40in

Broken links were pointing to files in ‘package’ directory.

To develop further this idea, there is need to modify package demon (or something), that installs from packages software in to ‘package’ directory, instead it must extract them to file system.
RAM usage with package virtual file system doubles because it uses RAM and also running app using RAM.
Also, I think, if you have on machine less than 1GB RAM it is very useful to ditch out package virtual file system.

*Если непонятно выражаюсь на бусурманском языке, то дайте знать. Повторять буду по русски.

9 posts were split to a new topic: Naming of OpenBeOS and Haiku

For now is no need in separate distribution. I think, what is needed is some tool (“HUPE”) to modify standard Haiku into system without virtual package file system, which will be able update and install software from standard Haiku repositories.
Even, I hope, in the future this feature can be a part of standard Haiku.

This will not happen. All devs who commented here are very clear about it. Packages are great the way they work. We are aware of the RAM use problem, we will investigate and fix that. But we will not cut back on the features.

There has been days and days of discussion to reach the current solution. If you want to counter it, you have to come up with something that handles:

  • Installing package (that’s the easy part)
  • Upgrading packages
  • Uninstalling packages without leaving traces everywhere
  • Rolling back to a previous state of your install when you break things
  • Allows to work without a package repo, you can double click a package to install it
  • Allows to work with a package repo, you can use a command line tool to install quckly whatever you need by downloading from a safe and trusted source

If you can do all this without a packagefs and no RAM use, maybe we will consider it, but if the solution does not cover these basic use cases, we don’t want it in Haiku.

5 Likes

It is done in Gobo Linux “the filesystem is the database”:
https://www.gobolinux.org/
It is doable in Haiku.

Then do it. Don’t count on me to waste my time on it.

Your time to waste.

Sorry to interrupt but where is the difference between this and the current package system using pak files?

I mean even Quake1 back then used a basic form of packaging (*.pak{num} containing individual packages) and ran on low RAM systems.

Isn’t all this a bit “luxury problems” today?

These are different file formats. We are talking about pkg BeOS for installing programs.

I am talking about that that using ‘package virtual file system’ you double RAM and CPU usage by the system to run software. It is unnecessary.
And there also problem with really big packages in the RAM (in the ‘package virtual file system’), for example some package of 4GB: one package will eat all or a good enough portion of your PC RAM even if it not runs.

That would be a bad VFS. In a good VFS you do not load all files into RAM. You only load relevant book-keeping information in RAM (tiny, just a table actually). When the file is actually read you load it into RAM as the OS would do too without a VFS in between.

1 Like

I moved the derail to Naming of OpenBeOS and Haiku
Please everyone stay on-topic wrt HUPE.

1 Like

CPU usage? Maybe because the current packages are compressed, but we have two ways to improve this:

  • Disable compression (already possible, just some settings to change on haikuporter)
  • Switch to a better algorithm (we support Zstd now, but didn’t start making use of it yet)

RAM is definitely a bug in the implementation, because the package bookkeeping shouldn’t cost that much. We are aware of it and we will look into it.

5 Likes

Anyway, I like to see optional package install feature with unpacked (uncompressed) packages in main file system (as in BeOS was), compressed packages can stay in package directory as a backup.
Also, this means: option for Haiku to work with disabled virtual file system in Haiku’s package system.
It would be useful for machines with less RAM or fast ssd’s (or other current/future fast storage devices) or for developers and power users.

Haiku is a open source system with copyrighted name and Logos.

If one creates a distribution, and Hupe is nothing more like this, it needs a separate name that is not similar to haiku main system.

In this case people could come to this forum and asking for Support about Hupe problems. But here they does not get the help they need in system things, because it is not the way of haiku.

Hupe is an interesting idea and if people around to use and Support it why not. But it is not haiku anymore.

Take care about All haiku related stuff like welcome text and User guide, you need a own one.

1 Like

You right.
If I have enough strength to create a distribution, it will be called HAKILO (word in Esperanto language).

I had time and I sketched a mockup

2 Likes

I think this Name is to similar, and the boot screen should be Look different too

1 Like

This is a different name. Similarity != the same. Bootscreen redesigned better

Great start! I think as far as similarity goes, only the font is too close. I don’t see issue using the boot icons. There is nothing in the trade mark policy about those except maybe the leaf on the HDD. Im not sure about that part.

It’s just that using the same or barely distinguishible font makes it hard to distinguish it as a separate project. I do agree that Hakilo is a different name and does indeed portray the nature of the project.