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

[Gadzinka]

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

Registry, as an idea isn't bad. Like most things in windows, this idea is very good and implementation is horrible.

Elektra:

• isn't service that can stop responding, it's a library;
• it has no external dependencies other than libc, so it will work well in single mode/rescue situation, when most resources are not available
• it's not "one huge file that gets corrupted"; AFAIR either it's every level (folder, directory?) with its own file or every key with own file. If something gets corrupted, rest is still OK

Would you kindly go read TFM?

Robert

Maybe not the Registry

[VernonNemitz]

The description also sounds like it could be a very large .INI 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--

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.

aiming low

[jeif1k]

What these people are doing sounds little different from the next version of KDE or Gnome. Their web site has no new ideas for how to improve usability of the desktop, nothing that differs from the standard WIMP paradigm, and no interesting new functionality that they are implementing. It's unfortunate that so much energy gets wasted on trivial variations of the standard desktop paradigm. It's good to have choices in software, but only up to a point.

I actually doubt that any desktop effort based on an existing toolkit (Qt, Gtk+, etc.) will lead to significantly improved usability or functionality: those toolkits already encode a lot of assumptions and restrictions that any desktop effort based on them will be constrained by.