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

[punkrockguy318]

Read the fine website: http://elektra.sourceforge.net/
It explains the reasoning behind this registry, and how it won't fall into the same holes that the Windows registry did.

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.

Re:Sounds like the windows registry

[Hard_Code]

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

No, it is better in that it is in ONE PLACE (or rather, one API or "contract" to access), and ONE FORMAT (you decry this as misdesign but I'll address that later).

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

Aside from "things like context menu entries...pointing into thin air" being entirely an application-domain problem, not a configuration problem, how is the case you cite different from the CURRENT situation with lots of *different* types of files? As you immediately mention, the case still applies with bespoke file formats. In fact, I could argue it's *worse* because you don't know a priori where to go to *fix* the problem, whereas with a centralized config area you at least know where to go first, without having to read through reams of documentation to find out where some arbitrary application reads its settings, just to make sure the file has been removed. Lastly, what exactly is the problem here? So some config info remains...OH NO! The world is going to end! Actually, short of apps all being well-written to provide the user a prompt or preference as to what to do with config info, I'd prefer that it *remain* be default. I don't want to lose all my config info if I decide to uninstall, and then reinstall something. Or upgrade and then decide to downgrade. Etc. etc. Hard drive capacity is enormous. Nobody balks at storing movies on their hard drives but little TEXT FILES!?! OH NO CALL THE POLICE!

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

I think this is a good idea. For that matter, "virtual hives" which are implemented by plugins instead of being file-system- or data-backed would be cool. Then, e.g., you could have a hardware probe that provided real-time hardware data in the form of keys. I don't see how this would be precluded by elektra. As is mentioned in the docs elektra is 99% contractual agreement and 1% software.

"As a personal side note, I think the hierchical, shapeless key/value database design is an incredibly inelegant kludge."

Yes, it is an "incredibly inelegant kludge" except for the "astonishingly incredibly inelegant kludge" which is to store the same (often semantically similar) data in individual arbitrary files, in arbitrary formats, in arbitrary places on the file system.

"the best theoretical model for information storage ever"

Gee that's nice. But the mass of applications we are talking about can be served best by a simple namespace/key/value format. I don't know what software you use, but the vast majority of command line and gui applications I use not only CAN suffice with key/value pair format, but DO currently, except in their own idiosyncratic fashion. They don't need theoretical models for storing directed graphs of relational data. The most good for the most people (or apps as it were).

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

EGADS! Have you gone m

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

Re:Sounds like the windows registry

[uradu]

He had me at "The Elektra Project tries to upgrade a '1+1=2' system into a '1*1=1' one." That's positively poetic--what does it mean?!

Re:Sounds like the windows registry

[tom's a-cold]

This seems an odd discussion.

It seems to me that what you're really doing is persisting object properties, but not using object semantics to do it. THAT's why you get "zombie properties" in Registry-like designs: some object properties are realized on the heap, and some in the persistent store. And when you have the same object realized or partially replicated in multiple places, you need to use transactional semantics to make sure that everything is kept consistent. It's essentially just the garbage-collection problem, except that because of the need to persist properties for so long, part of it has leaked out of your runtime and into persistent storage.

Note that this can be the case whether the designer thought that they were creating objects or not. Even when they're not embodied in an OO design, there are still things out there that behave like objects. Unless they're managed as such, you end up with dangling references, properties without objects, and other artifacts that result from incomplete garbage collection.

Hard_code's comments about the same information being scattered in numerous flat files or relations sounds to me like a plea for refactorization (or maybe just the mechanism to enable it as you're using a system).

The other thing I would urge is to be sure that the API follows, doesn't drive, the object model, and that, where object semantics exist, they're exposed as such. This gives users maximum flexibility and really takes advantage of scripting languages with OO capabilities.

I used to develop system internals, so I am not naive enough to argue that objects are the only abstractions you need to consider during design. But for a large part of the application layer, it often makes a lot of sense to look at things this way. And this has been a historic weakness in *nix app architectures and their integration with OS services.

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

Looks positively innovative

[youknowmewell]

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

More BeOS than OS X

[gwion]

The tabbed windows, the desktop shell called 'Tracker', and the style of the icons all seem to come directly from BeOS, not OS X.

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.

Re:Mac OS X

[dr.badass]

It looks like they're basically building a better GUI engine for Mac OS X.

This has absolutely nothing to do with Mac OS X. Nor is there any new GUI engine here. It's just yet another clone of the BeOS UI, and a bad one at that.

The GUI in OS X is currently a mess. Ask any Mac themer. I hope Apple buys this from these guys and fixes Aqua.

You have no idea what you're talking about. Mac themers? Do those even exist? If so, what do they do, sit around and talk about how they wish Mac OS X supported theming? As if that would make a better UI?

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.

ACLs are not a step forward

[jeif1k]

Good operating system design is not about throwing ever more flexibility at the user or adding every possible gimmick under the sun.

The UNIX permission system has survived for so long because it works. There have been numerous attempts at adding ACLs to the UNIX file system, and they have not had a lot of success. In practice, ACLs cause numerous problems, in user interfaces, in usability, in system security, and in system management.

Given the way UNIX systems are used today, the real question is not whether one should move to ACLs but whether one can simplify the system further; group permissions and execute permissions perhaps should be eliminated, leaving us with just read/write and user/world permissions (plus setuid).

Re:ACLs are not a step forward

[jeif1k]

A well-designed ACL system is leaps and bounds better than Unix permissions. The problem is mostly that people implement ACLS very, very poorly, scattering permissions all over the filesystem where they are hard to find.

Yes, quite right: the problem with providing ACLs is that most people use them poorly. But people have been using them poorly for decades. Since people aren't changing, we have to conclude that ACLs are a poor mechanism for managing permissions in the real world.

[long-winded description of NT groups]

None of what you describe requires ACLs; in fact, the UNIX group system covers those cases very well. Perhaps you should try to understand them.

What ACLs make possible is ad-hoc, per-file permissions, and those create enormous security and adminstrative problems.

I haven't seen ANYTHING in Unix that will let me both have that kind of granularity and sweeping power.

Yes, and those restrictions are deliberate. They are the reason why UNIX permissions lead to more secure systems in practice than ACL-based systems.

ACLS are both far more elegant and far more powerful.

ACLs may be more elegant and more powerful, but they are not more secure or more usable in real-world scenarios. And what matters, in the end, is security and usability in the real world, not some operating system designer's wet dream.

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.