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

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

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.

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.