Where is Haiku R1? | Haiku Project

Blog
93

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
94

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
95

@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
96

Ports are a different topic, and to virtual file system unrelated.

1 Like
97

True. Sorry.

You however still needs to do your homework.
Let us know if it is ready, help Haiku evolve into the future!

98

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
99

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.

100

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?

101

What did you mean by “Haiku without virtual packages”?

102

Packages are extracted and installed in real file system. Than packages in “packages” directory removed, removed aditional links to the files in the packages. “non-packaged” removed. In that way Haiku not using virtual file system for installed packages (that are “virtual packages").

1 Like
103

“cache memory” is used to store data from file systems in RAM, and limit I/O access to disks. This memory can be reclaimed by any app which needs the memory for other purposes.

We implement two levels of caching:

  • A “block cache”, which stores sectors as read from block devices (ie. disks)
  • A “file cache”, which stores data from files.

The file cache is particularly relevant here, because it will be used to store file content. Because of the package filesystem, it will store them uncompressed. As a result, the decompression of package files is done much less often because the uncompressed data can be stored in RAM. And since an Haiku install is usually quite small (mine is about 3GB), and RAM on modern machines is large, it means that after some time, all the data from packages is loaded in RAM (we can do this because Haiku does not use much RAM for other things). This compensates for the extra work that would occur if we were always reading data from disk and decompressing it over and over again.

3 Likes
104

Signing the package files and having the package filesystem check the signatures at boot is on the long-term roadmap. However, there is already enough pushback from users complaining that the package management get in their way for now, so this will have to wait a little. Maybe until users start to be attacked by such viruses :frowning:

105

“Who” signs these packages?

If it’s you (haiku) alone then yes, it can be protected but then users are unable to “side-load” their system, which is a necessity to get a system moving forward.

If it’s developers only then every virus can replace a package file with a malicious one signed by some random key and getting the file up and running in the system.

Put simple you can’t prevent malicious packages to be injected while at the same time allow users to side-load their system. If side-loading is forbidden them I’m quicker gone than you can think.

106

How is that cashed data is protected from unauthorised access from side way app?

1 Like
107

The MMU (memory management unit) protects memory between applications, like in any other recent OS design including BeOS. So an application trying to access memory it is not allowed to will just trigger a segmentation fault.

108

The goal is certainly not to prevent installing 3rd-party packages. The whole system was designed with this in mind: allowing install of locally downloaded (or built) packages, and allowing 3rd-party repositories. These features are not going away.

I have not put a lot of thought in how the key verification would work. Maybe something like GPG, where you could individually trust developer keys. Of course this once again only moves the problem of viruses, as a virus could add its own key and then patch any key management software to make it invisible or something. We’ll have to think about this carefully and I’m not a cryptography/security expert. Also it is probably not worth doing as long as we are running everything as the root user anyway.

109

This means, that system erases data in memory before providing it to another app or not?

110

You can try for yourself, make an app that calls malloc() and see if you can spot anything in the returned RAM?

111

Granted, if you are root (or baron as it has been named in BeOS :smiley: ) then anything on the system can be changed. Without user management you can not protect the system in any usable way.

The only solution that works (from a professionals point of view) is to have an own user with write access to the package directory. for changing packages the user (or an application) needs to wheel into this user to make a change to the packages directory. this way a virus can not gain access to the files unless it successfully tricked the user into wheeling into the required user, which should involve a big fat warning dialog asking to enter the root password to grant the request.

2 Likes
112

Hehehe! I see all this arguing over security against viruses and malware corrupting packages and causing havok, and I keep saying… if only they listened to me…

It could be so easily stopped. But it must be stopped from the ground up. Gotta change all the rules of how the OS interacts with the users and programs. Too late for Haiku anyways, in its current incarnation. You might be able to create a workable solution, but never a truly secure one.

But never mind me… I don’t know anything. Go about yer fussing and fidgeting. Have fun. :smiley:

1 Like