how about a registry

A registry IMO is a bad idea, with Windows being the primary example. Windows needs to be reinstalled every so often because the registry gets bloated. With the increase in size comes slower lookups and, thus, system slowdown. IIRC, it was designed to solve the problems Windows had with storing configuration data and settings. We don't have that problem because we have a semi-definite idea of where things should go.

Interprocess communication is already taken care of -- the API already handles this in a very elegant way.

Linux runs into most of its problems because there is no real unified effort to make it all work together in a cohesive way, unlike Haiku.

I agree. I would be very sad if any other OS EVER tries to use a registry. It really makes very little sense with all of the other less convoluted alternatives.

The exchange of information is often made over complicated — moving data can be don't very elegantly with flat files — linux, os x, and other handle it quite well. The reason windows used it was because they don't figure out that flat files should be stored centrally (or at least logically). Granted, A FEW VERY CHOICE, LIMITED things, like users, groups, and aliases would be acceptable in a database. But it shouldn't even be called a registry. Preference files are more efficient, less bloating to the system ,easier to access and maintain, and more open.

I think you missed the point. Linux uses all kinds of RPM/yum/etc installation tree logging and the whole stupid /etc/ directory as its its registry. It's a convoluted, disorganized mess. The Windows registry, despite being "wrapped" in a container file, gets really messy, as well, particularly where COM objects and proprietary registrations are "documented". However, there are elements of the Windows registry that are very interesting and ideal. For example, if the registry was not abused by Microsoft, it would be about 1/500th the size that it is in a complete Windows Vista 64-bit installation with Windows SDK, MS Office, and Visual Studio installed. That small, unbloated registry would be a hugely helpful resource for managing system settings in one place.

I personally love the Microsoft Windows registry. I hate Microsoft's bloat-junk, but I love knowing that I can go straight to HKCU/Software/{App}/@appsetting=value to tweak some obvious setting, all in one place, and I don't have to worry about some .ini file or .config file or some proprietary setting file, or worst of all a binary one. And with PowerShell I can traverse the registry not unlike Linux users traverse /etc/, so handiness of calling up some editor from a path to reconfigure something doesn't necessarily mean losing out on quick and terse console commands.

I'd love to see the Windows registry idea applied with Be / Haiku's clean, terse, and sensible naming and path convention applied to it.

My $0.02.

jon

I wanted to expand on this thought. I already stated I think standardizing and consolidating integration configuration with a common store, API, and interface is important for a proper, modern OS. Not to mention, as I previously noted, having a consistent configuration store / API / interface gives users of all levels the ability to go in and change both system and application settings in one place.

The reason why there is a registry for Windows is because there are so many apps that actually integrate with the operating system--having a consistent uninstall path for end users (Add/Remove Programs control panel), adding file type icons and MIME types (yes, Be/Haiku has its own API for this), having the ability to load up an OS-registered COM server by CLSID (a GUID) or by name (Haiku doesn't support COM so this is moot), having shell extensions so that you can do things like right-click an icon and special context menu options show up, etc. But I agree that putting EVERYTHING in the Registry as Microsoft makes a habit of doing is just stupid, particularly if it is spaghetti where dependency settings are left unmapped and undocumented.

Secondly, I am as disgusted as everyone else with the mess that the Windows Registry has become. But I really don't think that the problem is the presence of the registry itself. I think the problem is inadequate standards and crappy structure design. For example, if an installed app MUST put its installation log into the registry, it should be forked in an "Installations" branch that someone doing a manual uninstall should be able to just right-click "Installations/MyApp" and choose "Delete", and then all of the setup-related information is removed. Shared libraries should be the same, and not accessed solely through a GUID (I HATE trying to find GUID-ified registry keys!!). Figuring out how to completely manually uninstall a corrupted Windows component installation takes me a couple hours of searching values that contain the old file path, and then I have to delete one randomly generated GUID named registry branch after another, at least a hundred times, before Windows itself will acknowledge that the thing isn't installed.

So in other words, the suggestion of a registry also infers a suggestion of a halfway decent structure / design, unlike the mess that the Windows registry is. Get the structures cleanly designed and standardize on it, and then most of the arguments against the registry become moot.

As for the arguments about having one big, bloated file managing configurations, that will break the OS if the one file gets corrupted, I would argue that that's what makes it reliable. Build the store accessor on SQLLite or something, do transactional logging, and make regular backups. It's much more of a pain in the neck to restore broken RPM history chains, and config files inside individual app directories don't befit OS integration requirements, nor, for that matter, consistency in the real user experience.

On the other hand, if the OP (original post) was more along the lines of inter-process communication, using the registry for that is abuse. That's not what a registry is for. The registry is just a database for the local computer for persisting configuration data, not for memory swappage from one app to another.

I like the BeOS way. Settings are in /boot/home/config/settings. If you need to remove a program, delete the app - usually in /boot/apps - or wherever you placed it and remove the settings from /boot/home/config/settings. say you installed Opera ... it installs in /boot/apps/Opera and adds /boot/home/config/settings/Opera. jsut delete these two folders and the program is removed. This is what the uninstaller in /boot/apps/Opera does. No REGISTRY PLEASE !!! we all hate REGISTRY SETTINGS.

still going with the flow and thinking inside the box? yeah, databases are cool, fast, have indexes, structures, interfaces, standards, APIs, versions, maintainers, bugs, code... beos didn't need any of that - it had ONE (now THAT'S what i call 'cool') database system - BFS and that was all that was needed. this is SO ADVANCED and outside-the-box that some people still can't grasp how advanced and awesome the concept was/is. the simpler the system the less prone it is to errors. why would we need an extra API if we already have an APi to FS? why would we create an interface (like kdbedit) if we already have a gui - a filemanager (or more like 10 of them)...
imho if this (BFS-like approach) is not implemented in haiku then there's no point of doing a haiku. haiku would be just another in the line of bsds and linuxeae. like building a kit car - yeah, it's fun and fulfilling to build but in the end you used same parts as everyone else and you ended up with boring crap that has been done by thousands before... i think that haiku should be more. not just pieces of windows and linux (and from maybe some other existing os).

Has anyone of you looked at openWRT?

K Scott. Thanks for an informative reply.

As a user (and developer), I absolutely prefer the method employed by Mac OS X. On Windows and Linux there is no standard used by developers; Windows developers often use several registry keys and/or INI files with basically no organizational pattern, and Linux developers are no better with their conf files.

The Windows registry doesn't bother me, it never has... though I certainly don't believe that system information and settings should be stored in the same place as user info & settings. I'm certain that if Windows users opening regedit.exe were asked if they wanted to load the system (HKLM) or user [HKU, HKCU, etc] hives vs. showing all of them on the left, then half of the forum posts you saw from people warning, "ZOMG! STAY AWAY FROM THE REGISTRY!!!!1!" at various web sites would never have been made, as the user would have been able to select the appropriate hive, and any adverse affects could be constrained to user hives only.

The only problem then is applications that don't clean up after themselves when installing, but that is not the system's fault. If an application isn't removing registry keys for itself then you can be 99.999% positive that it's also leaving behind files in you system and programs directory... again, not the system's fault.

Yep, SkyOS is using Haiku's MIT licensed BFS implementation. Has done so for quite some time and has even contributed back some improvements a while back, IIRC. Everything's how it's supposed to be. :)

Rest assured, no active developer in the project is considering that. OTOH, "They" could be plotting something sinister... :)

I also remember that they did a Windows application that could read SkyOS/Haiku BFS partition :)

I like the idea of using BFS as a settings storehouse; however, I wonder if there is an even more intuitive way to use it.

Why not place all program settings as attributes to the executable itself (i.e. no /config folder)? When a user runs the program from the executable or has not customized settings, the attributes of the executable are used for the settings. If the user runs the program from a link; however, the meta-data settings of the link would override the meta-data settings of the executable. When a user modifies settings to a program, the attributes of the file/link ran from would be modified.

(Does Haiku know 'where' a program is launched from or is this hidden by the FS implementation of soft/hard links?)

Why not place all program settings as attributes to the executable itself (i.e. no /config folder)? When a user runs the program from the executable or has not customized settings, the attributes of the executable are used for the settings.

There are several scopes for app settings, and two primary ones: one is global for all users, the other is on behalf of the current user who is invoking the app (or rather who the app is running on behalf of).

You cannot manage user-level settings with executable file metadata, even if it was broken up by user such as with XML nodes. What if you have 20 users and 2000 settings? The metadata would grow out of control, not to mention the security and stability implications of all users having access to the same physical metadata to access their settings.

In all the major OSs (*nix, OS X, even, yes, Vista), the user's app settings settings are stored in the /Users/{user}/ or /home/{user}/ directory.

On the other hand, BeOS / Haiku in the snapshot version / context we're currently dealing with is not really a multi-user system. I would assume that the *next* version of Haiku would add more multi-user functionality, but proper planning for such things as this ahead of time would be necessary.

Jon