Is there a reason for “non-packaged” directory?
Why that folder contents can not be in the level together with “packages”.
And why “fonts” in “data” directory?
And what purpose of “data” directory after all?
And, why “develop” not in /boot/develop? like in BeOS.
Best file system layout for Haiku (in my opinion):
apps (3th party apps accesible to all users, can be restricted with sudo)
develop (can be restricted with sudo)
home
–config (can be resticted with sudo)
––add-ons
––apps (for user apps)
––bin
––cache
––fonts (users fonts)
––lib
––packages
––settings
––var
system (only access with sudo)
–add-ons
–apps (only for system apps)
–bin
–cache
–fonts
–lib
–packages
–settings
–var
trash
The initial plan was to have packaged and non-packaged data mixed together, but it was not done. There are several reasons, some I can think of are:
- Merging packaged and non-packaged data would be slower than the simpler solution used now
- It was found to be quite complex to manage for users (hard to tell if a file comes from a package or not, impredictible bahavior if you modify a file from a package and then uninstall the package, etc).
In the end, a little complexity in the directory hierarchy makes for a much simpler code and more expected behavior for the users.
The data directory is required by the BeOS API, in the form of the B_SYSTEM_DATA_DIRECTORY constant that is accepted by find_directory. We have to provide it for BeOS compatibility. Its purpose is to store all kind of data: (text) fonts, soundfonts, and any assets that may be provided with software (sample pictures, videos, …).
The develop directory is inside system for symetry with the other directories (data, app, bin, …) and also because it is managed by the package manager. In BeOS it was a separate package from the system designed to live independantly, but in Haiku, it is made from the contents of hpkg files, so it is inside /boot/system where such packages are mounted.
In general we try to have a symetry between “home” and “system” because that matches the constants passed to find_directory. This may change again, however, for two reasons:
- find_directory will probably be removed in R2. The new find_paths and BPathFinder APIs replace it with a more flexible solution.
- We will someday implement a multi user system, which means there will be several “home” directories (one for each user).
It is recommended for apps to use find_directory or find_paths to locate their files, and never hard-code paths. Most BeOS apps either did this or ran self-contained from a single directory, which you could put anywhere you want. Going through this API allows us to change the directory layout as needed.
I would also like to remind you that there is no “sudo” in Haiku, and I don’t think we plan on adding one. I personally don’t think the way UNIX misuses multi-user support as a security solution is the right way to go. I would rather separate multi-user support (for actual users, with their own home dir, settings, desktop, apps, etc) from privilege elevation (which can be granted to an user automatically, with a prompt, with a password, with a fingerprint reader, etc). Privilege elevation implemented by “switch to the administrator account” is a hack (it is what “sudo” does in Linux).
1 Like
Thanks for clearing situation…
I guess packages when loads and expands in RAM creates virtual directories (bin, lib …) in RAM? And these goes in conflict with real ones. And real ones moved to “non-packaged”. Why not created virtual directories in “packages” directory or some other special place (/)?
Another question, how work with them (virtual directories and files) disk utilities, check bfs, check for virus and etc? They (virtual directories and files) cannot be checked?
And also, I think, it is no problem with small in size packages, but what happens with big, for etc with games with big data files?
The /system (and /home/config) directory is mounted from “packagefs”. This is a filesystem that stores its data inside packages, rather than directly on disk. It has the following consequences:
- The data is extracted from package when it is read by an application. The extracted data is stored in a RAM cache, exactly as it is done for any other filesystem in Haiku (and in Linux as well - I don’t know how other OSes do it but I suspect it is similar). The cache can be freed if the memory is needed for something else, in that case, when the data is accessed again, it will be read from the packages again. This is exactly like any other filesystem, and the package file format was designed to allow random access, so there is not a big performance overhead or increase in RAM use (this is why we are not using plain zip or tar files for packages)
- The package filesystem is read-only. It is not possible to modify the files inside packages using it. As a result, there is no need for a “checkfs”. A virus checker can browse through it as it would with any other volume, however, it could not remove viruses: the only way to do that would be to uninstall the malicious packages.
- As an exception, some directories in a package volume are “shine-through”. This allows to “see” the content of the underlying BFS volume. This includes the “non-packaged” directory, the “packages” directory, the “settings” directory, and the “cache” directory, for example.
The decision to put non packaged things in non-packaged is because it is expected that everything will come into packages. As such, “non-packaged” is the special case, and it is moved to a separate directory. In a normal situation you shouldn’t need to use non-packaged at all. There are of course some exceptions:
- You are using an app that wasn’t packaged yet, but needs to reside inside /boot/system for some reason (and can’t be in /boot/apps or somewhere else) - I think these are very rare by now, some users have made a great work of re-packaging BeOS apps in HPKG files, and most things don’t need to be installed in /boot/system anyway,
- You are developping something that needs to be in /boot/system (library, driver, …). In that case, you are a developer, you are supposed to be able to understand how these things work, you can deal with the directory layout.
- You need to replace some part of the system (a misbehaving driver, for example) with an older version or an experimental version. At the moment, this is a bit difficult, it requires installing the new driver in non-packaged, and blacklisting the existing one from the boot menu or the blacklist package settings file. We could try to simplify this. It is nice that the original file is kept and easy to restore if things don’t go as expected, however.
For all other cases, the “shine-through” directories are writable so you can put your files there. This include settings files (with a special trick to handle package updates), cache, temp directory.
Pulkomandy has explained the why. But if you are compiling a lot of old stuff that expects to find /boot/develop, here’s a simple workaround
ln -s /boot/system/develop /boot/develop
Also, non-packaged/bin is a great place to put scripts that are for your personal workflow, not for sharing with everybody. You can even put links to those scripts in non-packaged/data/deskbar/menu/Applications for instant access. So I would hope that non-packaged has a long future ahead of it. If it didn’t exist, I’d have to recreate it and that means fiddling with PATH settings.
Thanks.
…another question: Haiku gives priority to /home/config over /system in all cases?
Yes, the priority order is:
- home, non-packaged
- home, packages
- system, non-packaged
- system, packages
We may have missed some cases in Haiku, and some things are dependant on applications to do the right thing (for example, to list fonts, an app would need to look in all 4 directories). We have added new APIs to Haiku (BPathFinder, find_path, as I mentionned earlier), which can search for a file in the right order, but it is up to applications to use the APIs properly, and not all of them have been updated yet. You can report bugs if you discover problems with this.
2 Likes
The clarity of the explanations are appreciated.
Interesting thoughts about an eventual implementation of multi-user support in Haiku. I like the idea of a privilege elevation for every user. However, I think that there should be only one “administrative user” allowed to make changes impacting the system such as installation of drivers, software packages, or system updates for all users. Using an approach similar to the Portable Apps for Windows or Zero Install for RiscOS could allow every user to have their own preferred applications.
One thing though - if pursuing the concept of an “administrative user” - would the user name still be “baron”?
There could be one or more users allowed to get privilege elevation. It depends on how you set up your user accounts. In that setup, there would be no equivalent to the “root” user of UNIX systems. You could still name your privileged user “baron”, and we can make that the default and allow you to create more users.
Note that none of this is set in stone, it is only the way I see things. There will be lots of discussions and drafting before anything is implemented, I think, in order to cater for all usage patterns.