I was refering to the fact that HPKGs aren’t unpacked, but mounted from the package file system. Thus they are un/installed almost instantly and, as they are read-only, protected from any interference (virus, user-error etc).
7 Likes
It also means you can just move a package file from one of the packages directories and it is uninstalled. Or drop one in to install it. If it has missing dependencies then you will be asked if you want to install them automatically (if they can be found in the repos).
The magic of it has been somewhat dimmed by the lack of automated package builds, but now that these are in place it will really come into its own.
3 Likes
I think, and found it already to BeOS and Zeta times, tiresome argumentations and discussions to read about the alleged major problems of the system, of people who are not active themselves, but only occasionally look in the forum over.
Why do not leave this work to those who are actively involved with haiku and stay away if you do not like it?
Yes it was also in my eyes a mistake, rather than after the alpha 4 bring out a first release, because at this point a replica of BeOS was done. But this is already so long gone that one should no longer talk about it.
And yes, for most, haiku is a hobby.
1 Like
And this gives you the right to decide what the “BeOS way” is?
Let’s see. I used BeOS as my main OS full-time for about a year, that was around 2005 or so. I then moved on to Linux, and later on switched to Haiku in 2009, as I joined the team of developers. I have run Haiku as my main OS since then. So that’s 8 years of using Haiku full-time. I think I know its architecture and design quite well, and I do my best to keep it running and improving. I invest a lot of time and energy doing that. I spent a year working full-time on the web browser. I wrote video card drivers to keep it running on my hardware. I debugged problems in libusb, fixed many small things in apps all around, ported libraries, etc. And you come here and complain that “nothing much happens except more package management”.
As a Haiku user, I find the package management system very enjoyable and one of the things that makes it reasonable for me to use Haiku. It made it possible to port software in a sustainable way. It made it possible for me to get a decent web browser, and the many tools I need to get things done (mostly around embedded software development). I don’t care that it drifts away from the BeOS legacy. What’s the point? If you think BeOS was perfect, you can continue using it. We have to stay relevant in these modern times and this means the OS has to evolve. I think it achieves very well, by remaining a flexible tool and the only platform I don’t feel getting in the way when I try to get things done. Writing apps is easy. Porting apps and writing recipes is relatively easy (much easier than on Debian where I could never figure out how to make a package - we even have 13 year old kids who never touched Haiku doing this during the Google Code-In).
So, you’re not even using it, and you’re complaining. I don’t get it. If you think the project is not interesting, just keep your BeOS nostalgia and move along.
13 Likes
I’m also a long time BeOS user. As recently as last year, I purchased an old PIII desktop so I could install and run BeOS again. The nostalgia ran pretty thin after less than 2 weeks due to a variety of issues ranging from software bugs to dodgy harware support. In many ways we are well ahead of BeOS, and the package management is one area that I am particularly impressed by. Updating, installing and removing software is as easy as a mouse click. Once the developers fix some of the more annoying bugs and polish up certain areas of the UI, Haiku will leave BeOS in the dust.
4 Likes
I am also a long time BeOS user (R4). I am amazed at the progress of Haiku. Is it BeOS? No, it is better. Despite what many have said, the time to develop package management has been worth it. X64 & EFI support is worth it. It can be scary to care since there is little visible process to control the “roadmap” of Haiku. But as you point out, this is individual’s hobby (passion). They will develop as they see fit.
The great thing is also that anyone can contribute. Time, Talent and Money are always welcome by open source projects. Contributors have louder voices.
I am excited about the prospects of Beta 1. A real feature freeze. A R1 release. I really cannot wait until X64 is the absolute primary programming focus and the community starts on R2.
I may have missed it earlier, but THANK YOU HAIKU team. You guys are doing great work. Now its time for us applications developers to start.
9 Likes
Since it’s testimonial time … I started with a BeBox back around '96, and used BeOS for my primary OS for years - even at work.
I’ve never been able to use Haiku for a primary OS for long, but that isn’t Haiku’s fault - Haiku is better than BeOS was, by a good margin.
The problem has been software, and particularly the web browser. I find cause for optimism here, though - I’m using WebPositive as I write this, and while it has a bunch of issues, it performs pretty well compared to the mainstream browsers I’ve been trying to use on FreeBSD lately.
So I’m really looking forward to a Haiku release, which ought to help get application development on firmer ground.
Thanks for everyone’s responses. I’ll take them to heart and keep looking in.
About package management: is it guaranteed to remove everything it puts on the system if the user chooses to uninstall something? Also, what does package “file system” mean? The server? How are shared component conflicts dealt with?
At one point it seemed that the plan was to make virtual packages out of special folders like on Mac OS. Is that what happened? Is an application self contained and relocatable by the user?
If you install using a haiku package will installed virtual. Only things the package builder include as post-install-script will be installed to writeable system folders.
I does not know if there is a good plan to make this uninstallable.
Why you does not test it by yourself.
Why some people don’t like Haiku’s package system? Why I do not like it?
(Note: I am not against managing packages by it self as idea.)
Haiku’s package system is outdated technology, because it is based on ideas for dealing with problems of slow storige media and fast CPU and RAM. In todays it is not needed and is a waste of computer resourses, and system less eficient than system without virtual file system, also it is complicating system without need.
Virtual file system it is what is wrong with Haiku’s package system. This system brakes file system structure by inserting itself in first place and puting aside real file sytem (it is not good for perfomance on fast storige media).
Point of this (Haiku’s package system) only one it is to remove power user from dealing with system, for bad or for good. If something wrong with packages your system is brocken and no easy way for you by itself to fix it (this already hapened).
How this problem can be fixed? – remove virtual file system, lets packages installs in real file system, packages by itself can be stored in “packages” folder in “system”, content of “nonpackaged” must be return to it’s rightfull place. Power user must have full controll of the system.
2 Likes
Haiku’s HPKG packages are like little disk images. Their contents are not unpacked and copied when you install them, they merely get “mounted” the moment they are moved to the packages folder. The contents of all HPKGs are then merged together. This “mounting” and merging, and other things, are done by packagefs, a virtual file system which is mounted in two places by default (/boot/system for system-wide packages, and another one in /boot/home/config for single-user packages - for a future in which we might have multi-user). When you uninstall a package, it is simply “unmounted”, and the files it contains vanish instantly. It’s quite fun to watch if you’ve not seen it yet: move a package in and out of the packages folder and watch in Tracker the application files appear and disappear from your system live and instantly. You can also easily see where something comes from: the packagefs adds an attribute to each file/folder with the package name which contains it.
If the application created things like settings files, these are generally not removed automatically when you uninstall the package. While that’d have some upsides to clean up automatically, there’s also too many risks with just deleting user data like that. So only the packages contents disappear.
And anticipating another question: no, application developers and users are not forced to use HPKGs for applications. It has many advantages to use HPKGs, but if you prefer to distribute/install your applications by unpacking ZIP files like in the past, of course that still works too. You can put your applications wherever you like, and it still “just works” like it always did. (I myself have an applications folder with a bunch of old BeOS apps that I simply copy around from Haiku installation to installation.) And for add-ons there’s a whole separate “non-packaged” hierarchy in the /boot/system and /boot/home/config folders, which you can use however you like for these things too.
6 Likes
Have you ever had corrupted data on linux machines? One have the power to repair it, that’s great. One can build linux with LFS too, pieces by pieces, that’s also nice. But is that modern? They made the same on PDP’s too.
You want to change things? Great!
Then go and make an action plan, work out the details, how the whole system needs to work under the hood. Define the basics, how the small pieces will work together.
Because telling: “the day-night cycle must be changed” is easy if one omits all the small but important details, that’s why you should create a clearly defined plan, make a proposal and start working on it. Not just talk a about it, but prove your right.
Somebody told here: Haiku went too unixy, you say, Haiku isn’t enough unixy.
I say: you guys have opinions.
But formulating your opinions like “this and that must be changed” is disrespectful as it looks like you know everything better. You like to forgot about it, that the PM developers made an action plan, they analized different existing and non-existent solutions, made a proposal, the devs accepted it.
You haven’t did that yet, you just told, we loosing cpu power because PM. True.
You told we loosing performance because packaged fs. True.
But does it means: the absolute true and best solution is: revert everything?
In my professional work i met with the same ideas all the time:
We have an simple solution for something. It isn’t nice. It isn’t good. It doesn’t covers all the things. It actually works only in this and that case. It provides bad results in other times.
I went ahead and implemented a completely new solution, massive abstraction in every strategical point to be able to handle the rapid changing under layers.
I worked 2 days long without sleep on this because, you know, deadlines.
It was ready to rock, worked in every case, provided excellent results.
Why do am i telling this?
Because a workmate told: Umm, i don’t understand this, so we need to revert back to the earlier state.
I cannot accept reverting, if it means we loose proved technology against a simple, but terrible solution. We can however make it simpler, we don’t have to do everything so, as i thought, we arent’t chained by deadlines, we can rework it partially to make it easier understandable, we can work on it to provide better performance. We can invent compressed packages what gets repackaged without compression on the end-user site for performance. We can change all the things.
But you meant, we must remove all these things.
So: mate, go and prove! Your turn. Just don’t forget to have fun! 
5 Likes
Being a software developer myself, I am always amused by comments from the people who are trying to go into technical details without really knowing how things work =)
Seriously, what problems do you guys have with Haiku’s package management? How exactly does it make the system slower? If you state that it’s a waste of system resources and introduces any noticeable performance overhead, please do care to grab a build right before package management was merged and do some benchmarking.
What sort of power does it remove from power users and what problems do you have with non-packaged folder? If you want to dive into dependency hell, feel free to unpack everything there and configure everything as you like. The system does not really prevent you from messing things up, it just tries to warn…
There is indeed an easy way to fix everything - pkgman full-sync. Was it ever broken because of packages? If you are referring to the latest ABI breackage, it had nothing to do with package management. In fact, you would really end up in despair trying to fix everything if the package management wasn’t around.
Package management is implemented in all modern operating systems in one way or another and the way it’s done in Haiku, in my opinion, is a state of art.
You can either agree or disagree, but please don’t tell developers they did something wrong when you have no idea what they actually did. Developing an OS is not all unicorns, rainbows and Obama. Believe me, they have enough hassle to deal with without your highly arguable ideas.
4 Likes
Not all, I said:
How this problem can be fixed? – remove virtual file system, lets packages installs in real file system, packages by itself can be stored in “packages” folder in “system”, content of “nonpackaged” must be return to it’s rightfull place.
HPKG’s, HaikuDepot, pkgman can stay and do what they do (only without virtual file system part).
Yes, in this way software install-removall will be slower, but, system and apps will load faster, CPU and RAM wiil be less occupaed, and source code of Haiku will be simpler. And of course in this way it is simpler to manage and fix system by hand (in good BeOS way).
1 Like
@damoklas: there is no “good BeOS way” in managing ports.
Do your homework first, publish the results, how the porting would be affected, how the Haiku bootstrap would be affected, and so on.
1 Like
Ports are a different topic, and to virtual file system unrelated.
1 Like
True. Sorry.
You however still needs to do your homework.
Let us know if it is ready, help Haiku evolve into the future!
pkgman is just an userland frontend that tells the package filesystem what to do. If you remove the filesystem, pkgman wouldn’t work anymore.
Anyway, this way of working has the agreement of all Haiku devs and a large part of the community. And, you did not make any proof of your statements for reduced performance. So please bring in the benchmarks, and we’ll see what can be done. Otherwise you are only spreading FUD, and that won’t help anyone.
There are known ways to improve performance already, one of them is not compressing the packages using zlib, and either leaving them uncompressed (already possible) or switching to a more CPU-efficient compression like zstd (this is work in progress). As you can see, we are aware of the issues, however we don’t think throwing away the whole package filesystem is the right solution.
If you break things with the package filesystem, it’s super easy to go to the boot menu and boot an older state of your system. This means installing a package is not a very risky operation (it is very easy to remove it). That would be impossible without the package filesystem, and it is great to have a safety net like that.
You say that installing some packages can break everything, and yes, that is true and it happened to me in the early days (now people understand better how to make good packages). However, it also happened to me, many many more times, on old versions of Haiku and also on BeOS, so back then I became very reluctant to installing new software - I always feared it would break something and I would have to do a clean install.
Package management actually improved the situation a lot, in that aspect and also in others. For example, it is only thanks to it that we got Qt running reliably. Yes, it was broken for some time recently. But in just a few weeks, all libraries and applications were rebuilt and everything was up and running again. Imagine what would have happened if we did not have recipes and a reliable tool to build them. People would still be messing around, trying to figure out who compiled this or that lib for the last time and where they stored their patches and why their readme with compilation instructions doesn’t work anymore.
9 Likes
Nope. If the user can move packages in and out of the package directory then virus just need to pull the package, modify it and push it back to get themselves spread over the system on the next boot. So no, it’s not safer… just differently unsafe.
I made fresh install of Haiku (hrev51675 x86_gcc2 hybrid) with virtual packages and without them (just installed packages old way, note: this Haiku can’t boot on it’s own).
And made some quick test (“Activity monitor” app: used memory / cached memory), just boot and running Haiku:
Haiku with virtual packages: 348.5 Mib / 656.7 Mib
Haiku without virtual packages: 303.0 Mib / 302.2 Mib
CPU (2) usage similar (1-4%), maybe little less on system without installed virtual packages.
No additional packages on system’s were added.
…can some one tell me were is phisically ‘cached memory’?
…and why Haiku “about” know nothing about it?