Introducing the Mockup Project

Pier Luigi Fiorini writes "The Mockup project is a desktop operating system based on GNU/Linux. It has recently released new source code and published both screenshots and mockups. Read the announcement to know where are the source code tarballs and how to compile them. Mockup uses a new lightweight and modern graphical user interface that supports both pixel and vector based graphics. The GUI is based on bleeding edge technologies like Qt 4.0 beta, Elektra, HAL and DBUS. Elektra is a new backend for text configuration files. Instead of each program to have its own text configuration files, with a variety of formats, Elektra tries to provide a universal, hierarchical, fast and consistent namespace and infrastructure to access configuration parameters through a key-value pair mechanism. This way any software can read/save its configuration/state using a consistent API."

Comments

Sounds like the windows registry

[n1ywb]

Elektra tries to provide a universal, hierarchical, fast and consistent namespace and infrastructure to access configuration parameters through a key-value pair mechanism. This way any software can read/save its configuration/state using a consistent API.

How is this any different from the Windows registry, one of it's most hated "features"?

Re:Sounds like the windows registry

[fuck nwbvt]

Sounds to me more like Mac OS X's preferences system (accessed on the command line through the defaults utility).

Re:Sounds like the windows registry

[mr_rattles]

It does sound like the Windows Registry or gconf but I don't think it's a bad idea as long as they can implement it well and get people to use it in the right way.... or maybe that's just asking too much. ;)

Personally I don't think there's a problem with every application using its own configuration file. Being able to make a backup by burning a file to CD is a lot nicer than having to export a preference branch from a tree into a file and then have to import that branch when I want to restore the preferences. It would be nice to see a common API for writing to individual preference files that also controls permissions and locations of the files. That way you don't have preference files in every possible location on your filesystem. They're in a global config folder or they're in your home directory.

Re:Sounds like the windows registry

[Earlybird]

• How is this any different from the Windows registry, one of it's most hated "features"?

Not a whole lot. Elektra's essential improvement over the Windows registry is that Elektra is inherently text-based. They also provide a console program that lets you programmatically access the database, either interactively or from scripts, which is a nice touch that avoids the binary opacity of the registry.

Aside from that, Elektra suffers from the exact same problems as the registry. The main problem with this sort of hierarchical key/value database -- and that's what it is -- is that it's just a mass of data, inherently structured but semantically shapeless; the context of any key/value pair is the parent node, and the context of any node is its parent node. As such, it's no better or worse than a bunch of files in a file system.

The reason the Windows registry is such a mess is precisely because anyone can do anything to it. Delete an application and its data remains. Delete the files belonging to a COM component, and its registration information will still be there, and things like context menu entries will be dead ends pointing into the thin air. Even if you're a careful gardener, the registry grows indefinitely.

Even a good package system like APT leaves files behind in /etc. You might say that, without constant weeding, even /etc grows indefinitely. It just grows much slower, and is comparatively easy to keep in shape due to its much simpler structure.

The problem, then, is not the registry's binary nature, nor its weak hierarchical model, nor the lack of scripting tools (although the latter impairs its usefulness). It is that there's no glue between the owner of the information and the information itself; the ideal situation, a registry with no orphaned information, is architecturally not a bad design.

Instead of a single monolithic database, I suggest an aggregated database. Install a piece of software Foo into /usr and its database goes into /etc/foo, then mount it logically under a well-known named node. Thus the "registry", or whatever you call it, is the product of all known sub-registries. Delete an app, and its database can go away as well.

As a personal side note, I think the hierchical, shapeless key/value database design is an incredibly inelegant kludge. People are still blatantly ignoring (and misunderstanding) the best theoretical model for information storage ever invented, Codd's relational model, which is also pretty much the only theoretical model invented.

Fortunately, some people "get" it; the relational nature of RDF triples is one such recent example, and I would rather see RDF (although not necessarily its XML syntax) adopted, because it's such a simple, elegant, extensible system.

Re:Sounds like the windows registry

[stevey]

Even a good package system like APT leaves files behind in /etc

Not if you purge a package instead of removing it.

When you remove a package you remove the binaries, but when you purge it you remove the configuration files too.

Re:Sounds like the windows registry

[Hard_Code]

How about try reading about it: elektra documentation

The concept of centralizing and standardizing the most common case of configuration files is the same. The implementation of course is different. Each key is stored as a file on disk. There is no daemon. There is no "corruption" (other than corrupting one key which will not affect other keys). The keys are still able to be hand-edited like any text file.

No ACLs?

[ka9dgx]

I looked at the mockup of the permissions page for a folder, and I see Owner/Group/World instead of an Access Control List (ACL). This is not what a modern Operating System would support.

--Mike--

Looks positively innovative

[youknowmewell]

I haven't seen an interface like that since yesterday.

So why is this special?

[pilot1]

Let me see, it's a Linux kernel (modified maybe), with the latest beta version of a predominantly GNU/Linux app: QT. Oh, and they're trying to add a nice Desktop Enviroment, based on QT.
Basically, this is a Linux distribution with it's own desktop enviroment and a different config file system that's trying to pose as a brand new OS.

Could someone please explain to me why it wouldn't be better to submit the kernel patches to the Linux devs and just make a distribution that uses Elektra? Calling it a new OS only causes fragmentation, IMHO.

Electra almost there

[spitzak]

They almost get it. In electra it appears all the keys are stored in individual files. However there is still some screwiness in the filenames and a serious problem in that the file contents are still not raw.

Here is how it should work:

1. There is NO library. You use libc functions like open() to read the "configuration"

2. The filename is the key, just like electra. Programs use simple rules to find the actual file from a keyname: prefix $HOME/configuration/ and if not found prefix /configuration. Electra seems to use "$HOME/.kdb" and "/etc/kdb" which seems to be rather cryptic.

3. The contents of the file are the "value". There is no "comment" or other data stuck in it that requires a parser. A "comment" can just be another key, ie app/key can be described in app/key.comment.

4. The value is a string of bytes with a length. It is not UTF-8. UTF-8 is highly recommended but there is no reason to enforce it. Any "registry editor" is required to preserve the bytes exactly as-is if the user does not change it, but if it thinks it's UTF-8 text it can present it to the user that way and let the user edit it. If the "registry editor" needs to figure out the "type" it could be standardized as being stored in the file key.type, but I don't think it is necessary. It is pretty easy to guess the type of data with 99.9999% accuracy.

Things Electra got right:

1. No XML or any other type of file requiring a parser

2. Ability to "comment out" a line (they rename the key by putting a period before it). Finally somebody has realized why text configuration files are still 100 times easier to use than the fanciest GUI.

The evolution of config files

[Anonymous Coward]

(Pardon my little rant here.. but this is a general problem and not directed toward this project in particular)

Instead of each program to have its own text configuration files, with a variety of formats, Elektra tries to provide a universal, hierarchical, fast and consistent namespace and infrastructure to access configuration parameters through a key-value pair mechanism.

You mean like.. THE FILESYSTEM?

This always amazes me. The most simple way to store data on a modern machine is to put it in the filesystem. Which is a universal, hierarchical, fast, and consistent namespace and infrastructure to access configuration paramaters (and ANYTHING ELSE) through a key(=path) value(=file) mechanism.

You can also use environment variables for "global" settings.

Most software goes through these stages:

1. ad-hoc monolithic config file (the author is very proud when he's finally debugged it all). Full of settings like "dir = /foo" and "email = me@localhost"
2. introduction of namespaces once he realizes a flat namespace is no good: "global.dir = /foo" and "other.dir = /bar" and "admin.email = me@localhost" and "debug.email = you@localhost"
3. introduction of "include" mechanism once he realizes that monolithic config files are impossible to edit programatically and using "sed" is getting really old. Now the main config file is "include conf.d/*.conf" and the settings have migrated into indivual conf files.
4. realization that not every setting is a simple one-line value. so he moves to XML or some other ungodly thing
5. realization that, hey, wouldn't it be cool if *all* software was like this?

If you are writing a program save yourself a lot of trouble and just cut to the chase. Please don't invent another file format. Please don't write another broken parser. Please don't use XML for anything a human has to edit. Please please don't make me link in an API just to read/write the config settings. Please don't try and prove what big programmer muscles you have.

djb's software is a great example of how powerful and simple this can be.