i think for the communication between apps and haiku, the operating system will surely need a registry-like system.
Because today on linux, it’s a big challenge for creating system apps and of course always UPDATE them to match distros and new config files.
Will Haiku need a registry or a system like Elektra http://www.libelektra.org (Another registry model for linux but not yet implemented on it) ?
Coming from a Windows background, the word “registry” scares the hell out of me. It’s scarred me for life.
/me huddles in corner
But seriously, I have no idea 
How BeOS did it will probably have to be the way for R1, for backwards compatability, but after that?
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.
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.
This is Haiku’s major selling point for me. I like Linux (Debian in my case) a lot, but sometimes it just feels very cobbled together. I’m hoping that Haiku won’t have that problem.
A registry IMO is a bad idea
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.
That is the question. I think there ought to be a SYSTEM registry with read-only access for apps. But a registry for apps, no way.
Too often I have found that apps use the registry to hide things, or use it as temporary storage for run-time values. The most annoying and troublesome factor I have encountered with registry use is during an uninstall.
More times than not, an uninstall, which is dependent on an app’s install log as well as an app’s uninstall routine, fails to eliminate all traces of an app’s presence. This is due to an app failing to record all installed elements, whether from the initial install, updates or run-time.
Although apps may proliferate their details throughout a system, not just the registy, the registry is the most difficult location from which to eliminate left-overs.
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 just took a peek at elektra. I think Eletrka is a fantastic idea for Linux, and the concept of a clean and unified configuration system is one that any modern and clean operating system should strive for. (Just don’t abuse it like Microsoft does.)
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.
Does anyone here remember how old BeOS handled the tasks that are proposed for the Haiku and registry?
I personally like more gconf like approach. I can use special utility (like a regedit eg gconf-editor, 'tho i don’t like that they chose .xml for gconf, there’s nothing wrong with plaintext and ‘Keep It Simple,Stupid - KISS’) and i can browse it with any filemanager or from plain old shell…
btw, imho a regular BeOS filesystem IS structured, hierarchical and searchable, so why re-invent the wheel? and BeoS had an AMAZING filesystem, imho. and with all the journaling (i think it was journaling?) and all the attributes, it was all tested and working - why not use that (approach)?
maybe: just 1 folder - config (?), and in that 0-byte files named after the owner-application and all these files have attached attributes which are the configuration information - keys and values. simple, imho. and ANY tracker window can become a ‘regedit’.
-config (folder)
|-hterm (file=application name)
| -window.width=1000 (attributes=keys and values)
| -window.height=700
|
|-foobarN
| -parameter=X
etc
those keys and values could be also INSIDE those files, but then there’s always the question of linefeeds, case, formatting etc and one would need to use a text editor.
most of the times more is less, more or less…
I like your Christ, I do not like your Christians. Your Christians are so unlike your Christ.
Mahatma GandhiI 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.
A registry, as a database which is loaded each time the system starts, is obviously a bad idea. But it will be nice if Haiku standardizes on 2 locations for storing conf. files : one for the user prefs and one for system wide prefs. I suppose Haiku already does this.
Now, there could be a system API which provides direct and easy access to these settings (think extremely simple calls like store(key, value) and get(key)). The default method of storage can be either XML files, or a small, fast database like SQLite (in that case, a more advanced API might be required to harness the full power of SQLite).
If this API is well designed and works for the most common applications, then it will be taken up by the app devs. For more advanced storage and retrieval of conf. data, the devs can still use their own APIs and methods of storage, but the location for these config. files must be a universal standard (as it is now, AFAIK).
I don’t think that anybody will need to do more than store and retrieve simple values from the registry, anyway.
Don’t go the Linux way, though, where there has been a severe lack of standards until very recently.
[quote=General Maximus]The default method of storage can be either XML files, or a small, fast database like SQLite (in that case, a more advanced API might be required to harness the full power of SQLite).
[/quote]
I think there is a way for using libelektra with XML files (when importing or exporting an apps config) :
Why not take the best from the two approaches.
Let each app use settings files, but the system will track these files and keep an updated copy in a centralized lightweight database.
Deleteing the settings file will remove it’s data from the database.
Changing it - will change the database accordingly.
If the database becomes corrupt - it can easily be recreated.
Only data that is needed by more than one application should be stored in the database. Maybe the setting files can contain info about which keys/sections should be public.
I think haiku should avoid having a /boot/home/config folder similar to
the /etc linux folder.
Here are some true facts about the Elektra library (taken from this page) :
I think the better way is at least keeping the library available into the system in order to promote a clean programming method.
http://www.libelektra.org/Why_Linux_Needs_to_be_Elektrified
Why too many people hates an unified database called a “registry” ?
Don’t look only at the registry side-effects, just compare the boring things between linux and windows (and don’t forget what is the operating system you are daily using).
I think if Haiku would like to be a great alternative to Windows, It should have AT LEAST the same advantages (the same weapons) as Windows…
Tony, don’t get hung up over terms and society’s hatred of them. Everyone hates the Windows registry as it exists in Windows, no one in this thread has stated otherwise. They hate it, though, because of the lack of consistency and the abuse on Microsoft’s part, not because the registry itself is bad. The frustrations people have with the Windows registry are due to the bulk that’s in the registry and how it’s used, not due to its existence.
The concept of a configuration database or at least a thorough but strict convention for storing configuration settings (flat files, SQLite, whatever), including OS integration settings, should be explicitly and carefully designed before the OS develops into its own. Otherwise, you get a mish-mash of disorganized config files scattered everywhere with very little or no consistency.
‘Registry’ is a BAD words,and it is a Karma in my life.if Haiku wanna be a perfect software.It will never need ‘Registry’!
The most important is that ‘Registry’ will bring some junk keys which needed to clear,if not,the PC will become very slow and MORE ERROR!!
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).
What’s so special about BFS in this context?
Like I said–if you had read my post you replied to in full I wouldn’t need to repeat myself–even if Haiku used flat files, that’s fine, as long as there is a specific pattern around which ALL software is expected to conform for both global settings and for OS integration, and as such as long as an API can be built around it that enforces both conformity and multi-process / thread safety (no corruption from two processes editing the same file at the same time, and no system exceptions due to file locking, either).
Jon