Slashdot Mirror
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."
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.
Erik http://yakko.cs.wmich.edu/~rattles
The tabbed windows, the desktop shell called 'Tracker', and the style of the icons all seem to come directly from BeOS, not OS X.
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.
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).
"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."
/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."
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
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
It's 10 PM. Do you know if you're un-American?
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.
Get your teeth into a small slice: the cake of liberty