HAKILO (ex HUPE) + HakiPKG by s40in


There is nothing strange in it. You know, the password database is currently not-encoded, so a malicious code can leak all the passwords. Thus we always try to notify the users about it.

There was talk about disabling attachements and links to external sites, but that would be way too draconic.


Hey, @s40in, I’m curious, though will you eventually release the source for these decorators? Or are they exclusively going to be packages?


Hi, @CodeforEvolution. I did not plan to do it now. My source code is not very good :slight_smile:


But we can learn with it.


Doesnt matter…release early release often and if you get hit by a bus, someone can carry on.

I really like the CDE decorator… need to get crackin on that Sparc port lol.


You have always had three great examples in the Haiku code. Start with BeDecorator

Haiku decorators


But would be great to understand how to make the graphic work and converting it as code


You should all draw lines and rectangles. I did not use external bmp images. In the BeDecorator source, everything is perfectly make.


Decors for Haiku 64-bit

HakiCDEDecorator for 64-bit
HakiDecorator for 64-bit


OMFG CDE! That thing that was so slow on Solaris on the SparcStations at school that I rewrote my xinitrc to run TWM + xterm instead. At the pauses I had finished reading my mails when others were still waiting for the desktop to load :smiley:


@jscipione The last one was called Smoke btw :wink:


Well, seems they use a lot of symlinks. Which does work (we actually also use them in packagefs), but having to maintain them when installing/updating on a real fs is going to slow things down.

LOL, nice one :smiley:

I think most of the wastage comes from the fact that we have the data twice in the filesystem / block caches : once compressed (HPKGs are files we read from BFS), and once uncompressed when exposing the content as packagefs. Unless we already open the HPKG uncached in some way…

Indeed, that and dependency handling. You have no idea what it was back then to develop on BeOS. I remember resuming work on XEmacs after a few months, and trying to recall which library I had to use with it and where on the disk it was.

Yeah, and even though apt works quite well, it’s painfully slow on Debian here. Last night it too two hours to do an upgrade because it has to puts files everywhere.

Indeed, if you have issues with the current way packagefs and the rest works, please file bug reports, come on IRC to see how you can help fix it…

As @PulkoMandy in most cases if you have to install things manually then it’s broken and must be fixed. It’s already possible to install two versions of an app using the user packagefs if needs be.


(and yes, I do like how it worked on BeOS, I spent 10 years using it, but it’s still painful when you have to manage hundreds of software whatever you do.)


So, to sum up, and to paraphrase what was once written in the Be Newsletter, come tell us why you don’t need packagefs, we’ll tell you why you do. :smiley:


maybe he is only asking for features:

  • remove a package ignoring dependants packages. This will break the dependency tree, but maybe dependant packages can work without it (i.e. optional dependency)
  • remove a package leaving unused dependencies installed.


Symlinks in GoboLinux are for compatibility with standard unix directory structure. I was talking about another feature: each software in GoboLinux has its own folder (even version). Thats all.
Yes in this case install/uninstall of software will be slower, but starting and managing software will be faster (on modern hardware) and simpler .


If a package has useless dependencies, complain to the lazy people at haikuports who added useless dependencies to their packages. I doubt you can find much places where this is the case, however.


There will always be a problem with dependencies, so I suggest adding the “blackpackage” function. Block installation (and update) of packages by its name.

  1. About dependencies, I have already indicated above. And I would like to see the “blackpackage” feature.

  2. If I want to edit something in the Haiku system library, I need to make a blacklist, make my own package with the necessary file, etc. Before, I could just take and overwrite any file with my version. (This is only for development)

  3. Optional. If there is a crazy person who wants to port Haiku to some kind of Nintendo Wii device (96mb ram), then he will need additional RAM. And removing packagefs will help him. (crazy developer only)

  4. Installing other software can be without packagefs. As a user, I can choose how I like. I can use haikuports, but I can make something other. I just need to know what is minimum for a haiku and what is not.


You don’t have to create an own package.