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.

1 Like

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

2 Likes

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

1 Like

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.

2 Likes

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

2 Likes

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:

2 Likes

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

1 Like

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.

2 Likes

(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.)

2 Likes

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:

1 Like

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.
1 Like

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.

1 Like

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.

1 Like