Is /boot/home a good idea?

1

Hi,

I think Haiku should take the good ideas and the right community standards at its first days otherwise it will know the same insuccess story than Syllable or Linux. It should be an OS built over a clean, unified, solid and tidy base structure.

I think the /boot/home/config folder is not really so good because there are more clean alternatives.

Actually the future /boot/home/ tree will look like this :

The personal folder of each user is encumbered with a “config” folder that should definitely not be deleted (the novice user don’t know anything about that!)

An alternative is to separate between “config” and user directories :

But my definitively prefered alternative is to put “config” at the root (“Configuration” is more clean) (use of autocompletion at command line) + renaming “home” to “Personal” (at the root also) :

And I think the definite good choice for configuration storage is a database like libelektra.
Without a such database, Haiku will be a “command line oriented” operating system as Linux is, because of many “non-standard” config files.
So in our near future we will have to deal with many commands like this :
sudo notepad /boot/home/config/foobar
Really not so “easy to use” for dummies.

2

“sudo notepad /boot/home/config/foobar”

I don’t know where you got the impression that one would need to open a text file in one’s home folder with sudo from the command line, but this is wrong in so many ways. You can just double click it from the file manager on Linux distributions as well as on Haiku. Not a single visit to CLI land is necessary for that.

Also the config folder does not only contain settings, but a whole bunch of other stuff. You should take a look at it when you get a chance. Your suggested solution has several problems too. It clutters user-owned files in the filesystem, makes owner ship management and backups harder and doesn’t add any real benefit other than hiding a folder.

You do have a point, though, and although I don’t agree with your reasons, I think Haiku should have a unified and endorsed way for programmers to save application preferences. That’s something almost every program needs and yet on many platforms there is no simple API for that. Mac OS X has NSUserDefaults [1] for it and Android uses SharedPreferences [2]. Systems like GSettings in the Gnome world and the Windows registry got the premises wrong and are thus not nearly as comfortable to use.

However, Haiku is “almost there” and doesn’t need something like libelektra or a “registry”. There is BMessage, which can be flattened (stored) to and unflattened (restored) from files. This is sufficient for almost any kind of preferences.

What I’d like to see on top of that would be roughly something like a be_app->GetPreferences(), which would return a BMessage and be_app->StorePreferences(BMessage). This way the OS could decide where and how to store the actual physical data. Which would mean 2 things: a) application programmers don’t need to think about tedious stuff like storing preferences and can concentrate on more important things and b) it allows for something like OS X’s defaults system [3].

The important thing here is, that the application does not decide the where and how, but the OS does, e. g. by using the app signature.

Once applications would use such a system, moving the settings without breaking app compatibility would be an easy thing to do. If one would really want to do that.

Also, calling Linux an “insuccess story” comes across slightly disrespectful, considering it runs on a majority of the world’s smartphones and an increasingly large number of desktop computers. Valve is planning a game console running Linux and it’s in more embedded electronics than you’d think.

[1] http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/Reference/Reference.html
[2] http://developer.android.com/reference/android/content/SharedPreferences.html
[3] https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/defaults.1.html

3

foobear, could you file that idea as an enhancement ticket?

4

sniff-sniffs the air

Hey, I smell the rotten smell of Windows 95!

A Google search for “Registry problem” returns over 118 million results.

Config databases are prone to becoming bloated and corrupted, and because they can only be managed via scary “registry editor” type software, the average user has to reinstall the OS when it goes wrong (or even buy a whole new computer)

BeOS/Haiku (aside from Syllable) are unique in having a database file system. The very thing the user works with from day-to-day and knows how to manage is actually a database. This means they already know how to fix registry-like problems.
If an application refuses to start or is messed up in some way, they can find its config file (by a query or manual navigation into the config folder) and delete it. They can make backup copies of config files before making changes or upgrading. Everything is a file, and it is intuitive.

“sudo notepad /boot/home/config/foobar”

On the BeOS/Haiku platform, writing a plain text configuration file is punishable by being hung upside-down from ropes for 10 years while a machine rips the developer’s pubic hair out.

Expecting the user to edit the plain text configuration file is punishable by skinning the developer alive. I’m not kidding.

Three methods to save the configuration of an application without incurring this painful demise are:

  1. Flatten a BMessage and write it to a file.
  2. Keep your settings in a struct and write it out to disk in binary.
  3. Save your settings as attributes on an empty file, each setting represented as its own named attribute.

Method (1) is the Haiku-suggested method, method (3) has the advantage of being easy to edit in Tracker or other attribute-editing software, for users that might want to mess around with settings.

However, in all three cases the application must absolutely provide a GUI-based method for editing its configuration!
This is not 1970s Unix beard-fest!

Sorry if this comes across as harsh, but for the sake of the users developers must be made to suffer when they try and shove their beards places they don’t belong.