Personalization frustrations

[PulkoMandy]

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.

[waddlesplash]

@ArDrakho

i.e. drag-and-drop personal fonts into system font area

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.

@ArDrakho

set-up system menus, update/create system themes, assign system sounds

All of these should be working, if they aren’t, it’s a bug (and indeed you opened a ticket about sounds.)

@ArDrakho

and so forth because of limitations of ‘read-only’ file systems

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.

@ArDrakho

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

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.

@ArDrakho

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

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…

@ArDrakho

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!!

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

@ArDrakho

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…

[waddlesplash]

@cb88

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.

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.”

@cb88

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 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?

@cb88

I think implementing it that way would still remain fairly orthogonal to the versioning feature yes?

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.

[waddlesplash]

(Sorry for not noticing this earlier post earlier, I should have replied to it in combination with your second reply…)

@ArDrakho

Haiku is not a Mac OS…system directory should be open for updates,etc.

It already is: you update it by updating the packages in /system/packages. That’s how pkgman update (or SoftwareUpdater) already work.

@ArDrakho

All these ‘pluggable’ VFS’s should be ‘live’ (including SYSTEM) and not ‘read-only’ as in a real virtual environment.

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.