This would make only sense if this function is for the admin only. But it is not possible, because all packages are virtual, that means they are hanging in by startup the system, so you does not can copy things there without installing it. There are the non-packaged folders to install by hand.
The Bug #1902 addresses only one of the 16 possible sound assignments.
I created a new bug ticket at https://dev.haiku-os.org/ticket/15295#ticket to address the system sounds not being played/activated/triggered when a one of 15 trigger events occur.
Haiku is not a Mac OS…system directory should be open for updates,etc.
Moreover, it is amazing how you all developed and deployed a unique ‘multitenancy concept with pluggables’ paradigm. I do not think any group has done that at this OS level. Pretty cool really!!
From my reading so far, this is how I understand what is going on.
--------
| H {=|===========}
| a { Haiku OS Virtual File System } <== LOADED FROM HaikuOS.hpkg
| i {=|===========}
| k |
| u {=|===========}
| { Home VFS } <== LOADED FROM Home.hpkg
| B {=|===========}
| O |
| O {=|===========}
| T { Tracker VFS } <== LOADED FROM Tracker.hpkg
| {=|===========}
| |
| {=|===========}
| { Deskbar VFS } <== LOADED FROM Deskbar.hpkg
| {=|===========}
| |
| ... | <== many other hpkg's
|vvvvvv|
All these ‘pluggable’ VFS’s should be ‘live’ (including SYSTEM) and not ‘read-only’ as in a real virtual environment.
Haiku should have active system processor running when the OS is open/operating so that:
- “plugs-in” these VFS’s into the OS system on startup [,which it currently does]
- monitors changes to each VFS (whatever it may be)
- backups the VFS prior to saving “updated” VFS [introduce a version control process for possible recovery]
- saves a “new” VFS with the user’s changes on shutdown
Why? Because from an UX experience for new potential Haiku converts and Haikuphiles alike, no Haiku user should ever experience or see the dreaded “read-only filesystem” message!
It all should just work and be transparent “under the hood”, per se.
That way…we can easily personalize/customize/use Haiku as we see fit as with the other OS’es.
The ThemeManager is probably what I was looking for. After playing with it more, I was able to capture the screenshot:
As I worked through all the other panels, I realized it is an aggregator of many options and assigments. So if I use graphics and sound applications to create new sounds and backgrounds, I can incorporate these new pieces via the Theme Manager into new theme(s):
I would like to create new screensavers that would be specific for my themes…so I bet that would be a learning experience in how to do those.
More to learn…
Well, the ‘menu-sorter’ app was not available for me to download–probably only 32-bit(?). Anyway, I used the article you cited and it took some time but I now have what I wanted:
Thank you!!
Oh… good Info. I will do this then on the weekend
1 Like
But it is open for it using the mon-packaged Folder. They have a hoher priority, first Non-packaged and them system files, iirc.
I like it, better for support, better for description.
- If you copy corrupt files to non-packaged you does not destroy the complete system.
- bad software who want to write data to a binarie or other file in the program folder does not have any chance, because read only.
- installing on beos was Chaos, because every people copy files there they want. So many doubled files, driver s, libs…
- yes to bring up old compiled program files are tricky to include a package, but new one will be clean
It is OK if you don’t like how the things are currently, but do not reason like “THEY should not see this.” is not the correct way. Explain why YOU want to change it.
THEY probably already met with the read-only FS using other OS, for example on macOS the system files also read only, and one need to boot it in recovery mode to disable SIP. Would you recommend for a user to disable SIP?
If they want to change system files, they doing either something from muscle memory or they doing something advanced thing, and for this a standardized way already exists in Haiku.
Study the user guide for more information.
This guy’s confusion is just another example of why non-packaged doesn’t make sense… it’s completely user unfriendly. And from what I understand is just an arbitrary bad design decision.
I does not think so. Non-packaged is for backward compatiblity and testing. No one wants to create every time testing something, to build a package before. And a user use HaikuDepot to install things if he was good informed by starting haiku first time. He does not come in contact with non-packaged in any way. Its only a problem by old beos users who does not want to go the new way. Old hardliner Who sah “I have installed everything in every position in the past, and now I want it do again”.
On the specific point of editing menus we definitely need to create a better solution.
In general, there should be no reason a user needs to edit a system file or place something into non-packaged. Ideally the average user will not even know they exist.
2 Likes
I am definitely guilty of being a long-time BeOS and Zeta user.
The last time I evaluated Haiku that I reported on was Alpha 1; however, I did not evaluate A2, A3 & A4 because I could never install it cleanly on any of my systems that I had at the time–nor did I have the extra time to do deep dives then either. But for the Beta 1, I bought new hardware that I predicted would be favorable for a clean install–I was lucky. I only had sound issues, which seems to be a common issue.
My points of contention are as I stated throughout this discourse. The average new user should never have to face and to resolve system related personalization/customization challenges that should be simple or one-click events: i.e. drag-and-drop personal fonts into system font area, set-up system menus, update/create system themes, assign system sounds, and so forth because of limitations of ‘read-only’ file systems. I understand that many current Haikuphiles have learned to live with it since they have “grown up” with the many changes throughout the years, but that does not make it right either (from a basic user experience perspective).
But as lelldorin, extrowerk, and diver have previously stated their counter-points, which I do not really disagree with them. I am a professional database engineer and system administrator–so I undertand their points about protecting the system resources. However, the ‘read-only filesystems’ that prevent the simple user activities will not meet the new user expectations of a great OS! It will only frustrate them and they will simply not become a Haiku convert because of a bad first impression!!
Don’t get me wrong–I love what has been produced and I have a very good Haiku system to be a daily user now!! I REALLY have missed my BeOS/Zeta systems, which I lost everything when I lived overseas.
So I will be an active participant henceforth…by testing and evaluating and so forth. I cannot wait to see what Beta 2 will deliver…
2 Likes
Unfortunately it is a problem that didn’t really exist before and it will crop up again in other areas… the fact that the packages are not overlaid onto a writable FS makes that pretty much inevitable.
I intend at some point go go back and thoroughly read through the discussion of all this… since I know it’s been talked about at length. And I hope I haven’t missed some serious flaw in my thoughts on this. I think the problem was that if you have BeFS and overlay packages on it… you would accumulate cruft in BeFS over time as writable files got strewn around over time? Obviously making most of the FS R/O fixed that issue but causes new ones also.
This would be the case you have BeFS with highest priority, and overlay with lower priority with packages shining through instead of the other way around. You’d potentially accumulate files that shouldn’t be in BeFS preventing updated packaged files from showing up.
The other alternative is all BeFS paths say the same, but new paths are added to be checked in read only ./packaged folders that you can’t mess up. But the rest of the usual paths are complete writable as before. config files would be shine through to the normal paths though since you would want to be able to edit them or delete the BeFS copy and let the RO package file shine through.
The latter solution would mean you have much fewer shine through files… and still retain normal folder writability and hierarchy albeit with packaged folders now.
I think implementing it that way would still remain fairly orthogonal to the versioning feature yes? And not be terribly different from how it is now, mostly an organizational change doable from haikuports.
The other day I replied to a previous response as I began to understand what everyone was talking about where I stated:
I am still learning how things function under the hood. I agree with your thoughts for possible improvement…Haiku can only get better. Too bad that I am not a kernal specialist and virtualization programmer…as I still do not quite undertand the full implementation of what is really happening “underneath the Haiku hood” yet though I think I see it from a high-level. Ingenious stuff!!
I actually found one use case for non-packaged folder. Basically I’m using LaunchBox as a desktop “widget”, but since its panels are essentially windows and not replicants, I have to run LaunchBox at system startup. This adds a deskbar entry for it, which I don’t need because the panels are always on my desktop, so it’s just wasting my deskbar space. The problem is solved by ticking “Background app” in Filetype add-on, but this attribute is not preserved due to the executable being in read-only location. I had to put LaunchBox binary into non-packaged just to hide it from deskbar 
I am totally fine with it though (come on guys, everyone should be able to read the user guide) 
2 Likes
Can we please stop rehashing this read-only FS argument over and over again. extrowerk said it, you can find pleinty of material on the forums about it already. But since no one bothers to search, here is the TL;DR version:
- We did not do this to annoy users, we are aware it is a bit “unexpected”
- Writable system dirs was part of the original plan but couldn’t be done for performance reasons (it was actually implemented, then dropped because it was just too slow)
- The non-packaged directories are a compromise which allows to still do some customization, combined with the blacklist system
- After doing things this way, we found out it also makes system updates safer and easier (no risk of erasing user customizations, which are in a clearly separate place), which makes it unlikely for us to want to go back
- Thinking about it more, it turns out faking a writable directory with some kind of overlay would behave in a more unexpected than what we do now, so it is not all that of a great idea.
Unless you have a solution that solves all the previous point, we will not reconsider this. This means your solution:
- Must solve the initial problem of allowing safe system updates without messing up user customizations
- Have good performance (at least as good as the current implementation)
- Is not confusing in terms of where the data is actually stored
- Preserves most of the cool features of the package system: being able to rollback to an older version, managing dependencies, allowing updates and not crashing the OS while doing so.
If you do not come with a proposal fitting this, please spend more time studying the history and design of the current solution.
4 Likes
On most other OSes, opening a font opens an app that gives an option to “install” the font. We should do that on Haiku, and then eliminate the need for someone to go into the system directories here.
All of these should be working, if they aren’t, it’s a bug (and indeed you opened a ticket about sounds.)
Dunno why you have scare quotes, the system directories really are read only…
Of the items you have listed here, only one (fonts) currently requires you know something about non-packaged. If we implement the “install fonts app” ticket, then that won’t require it either. We need to streamline menu editing, for sure. But there is no reason that the best solutions to any of these involve changing the system folder behavior.
As other replies have noted, macOS (among other operating systems) does not allow you to change the “system” directories without turning stuff off that most users don’t, and you really should not in general. Haiku is not as drastic here, you can install/uninstall packages from the “system” area just as you can on Linux, but the package manager certainly behaves differently than on Linux.
Well, in fact many long-time Haiku users had to adapt when we merged the package manager in 2013. But I think most of them realize its benefits at this point, and have adapted their “muscle memory” appropriately.
Because, after all, that’s what we’re talking about here, right? You want to use “muscle memory” that you built up using BeOS and Zeta as to how certain things are done. Well, Haiku may be the inheritor of the BeOS and Zeta legacies, but we are not BeOS or Zeta, and we are allowed to make changes where they make sense. This is one of those times, and we thing the benefits our package manager design brings are much greater than the time it takes to retrain your muscle memory.
Don’t forget that the developers who wrote the package manager were themselves long-time BeOS and then Haiku users, and they had to retrain their muscle memory just like everyone else…
In practice I’ve found this is just not true. BeOS or Zeta users have to retrain their muscle memory, yes, but users coming from Linux are already used to e.g. /usr/bin being controlled by the package manager, and custom things going into /usr/local/bin. Same for macOS users, and also to some degree Windows users.
(Being “more like Linux/macOS/Windows/etc.” is not in of itself good, but if in designing what we think is a better system, we create something more “familiar” to users of those systems, that side effect seems good.)
1 Like
That is part of it. But the largest part is the technical side of things: Doing an “overlay” would probably incur another 10% memory usage on packagefs’ part (and you have already complained before about packagefs’ memory usage, or will you think another 10% here is worth it?), and also make certain optimizations that I’ve been investigating for packagefs memory usage impossible due to the need for the current bookkeeping “and then some.”
I have asked this time and time again: what do you use non-packaged for?
If you have a “I am in non-packaged on a daily basis because X”, well, let’s see how we can optimize X. But if your complaint is just “I think the writable directories should have shorter paths”, then, well, we aren’t going to change things just for that. As I noted in my previous comment, /usr/local/ is where things outside the package manager go on Linux. non-packaged is just our equivalent of that. What’s the problem here?
Maybe, but there is a crucial feature of the system you may have missed: the Disable user add-ons boot option. This completely disables reading binaries/etc. from the non-packaged and ~/config hierarchies altogether, and so if the reason you cannot boot was due to a bad driver, settings file, etc., it is possible to bypass that directory altogether and just boot from the package hierarchy. This way, you can “unbrick” systems that could not otherwise be un-bricked without using a separate installation to edit the directories. (I have personally used this during driver development, as you may have guessed!)
I don’t know how you would preserved this feature if the packaged hierarchy were secondary to the “non-packaged” hierarchy.
(Sorry for not noticing this earlier post earlier, I should have replied to it in combination with your second reply…)
It already is: you update it by updating the packages in /system/packages. That’s how pkgman update (or SoftwareUpdater) already work.
HPKG files are block-compressed and indexed, for fast random access (and querying) while using minimal disk space. So they really are “create once, read-only after”; the file format really does not support writing after creation. Writing inside these directories would then require some kind of unionfs, but this would require a lot of memory/performance overhead with little benefit (see my replies to cb88.)
So saving a “new VFS” is both technically prohibitive, and also not really desired. If you need to override a driver, or a file, or something like that, put it in non-packaged. But most users should not need to do this, or even know about it.