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

[schestowitz]

The registry in Window$ keeps separate values for separate programs, much as is done in all these dot (.) settings files...

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

[alyosha1]

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.

I agree completely. A vast number of programming and systems maintainence problems basically come down to poorly thought out data models, and especially lack of proper referential integrity enforcement. All these questions about software installation/de-installation, orphanned entries and so on would simply not be an issue in a system based on a relational database with well thought-out CASCADEs and so on.

It's been 20 years since Codd's rules - you'd think we would have got it by now. (Although I have no idea how his concepts map to a networked world where there's no single arbiter of 'truth', and data is spread across multiple systems. I suppose RDF is a step in that direction, but I'm not very familiar with it yet.)

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

[Anonymous Coward]

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.

I'm sorry but your whole post is "semantically shapeless". We're talking about *config files* here. A handful of key-value pairs (less than 100 usually). And we want our systems to be simple and secure and easy to debug. We want them to work. So we should use the simplest mechanism available to solve our problem. Which is the filesystem on most machines.

Why use the filesystem instead of a "database"? Because you can edit files with almost any common Unix tool. You can read and view with any common Unix tool. You can create guaranteed atomic updates using any POSIX filesystem (just edit foo.new and rename to foo atomically). You can backup and restore easily. You can guarantee correct functionality because your computer wouldn't even boot if it wasn't functioning.

A hierarchy should be imposed only to create namespaces, not to imply any *meaning*. The key "/app/foo/bar" is a *single atomic key*, don't think of it as being in any context.

The reason the Windows registry is such a mess is precisely because anyone can do anything to it.

No it's a mess because it's not just files on a filesystem that anyone could explore, backup, restore, repair, etc. It's also a mess because Microsoft puts too much stuff in it! If it was an RDF database, it would be just as bad.

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.

Sometimes you want settings to remain. What if you delete the COM component and re-install later? This has nothing to do with the rest of your argument though, it is an implementation detail. For instance maybe all package should install in "/config/packagename" only, and an automated process deletes anything that doesn't belong to an installed package, after 90 days.

even /etc ... is comparatively easy to keep in shape due to its much simpler structure.

You have the answer before your eyes!

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.

There you go. Write a script that removes anything not in "/config/installed-package-name" and watch your problem disappear.

Instead of a single monolithic database, I suggest an aggregated database.

Your words have no precise meaning. What's the difference between the two? Are you sure you aren't confusing *implementation* with *logical interpretation*?

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.

Your solution apparently is the same as mine but you have a much more complicated way of speaking and thinking about it.

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.

I agree with the sentiment but fear you don't understand it either. If you model config files relationally (which you can of course s

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.

Re:Sounds like the windows registry

[Rysc]

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.

Did you RTFA? Elektra IS just a bunch of files in the filesystem. WHat elektra provides over just random files is: A standard C API for accessing the files, for those who don't like doing so directly, and a standard naming scheme for the hierarchy of files, something /etc does not have across distros. They also go on a bit about effectively standardizing file formats, but I don't consider that to be such a virtue.

Don't get me wrong, I went in very not-thrilled with yet another "Let's make a registry for Linux!!" effort, but I came out more or less pleased. The elektra project people seem to get what it is that makes /etc so well liked and have gone to lengths to preserve as much as possible. I'll be curious to see what they can get done. Maybe a whole rebuilt-for-elektra distro will be forthcoming; maybe GoboLinux will adopt it first. It will be fun to watch.

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.

You didn't RTFA? Elektra seems to solve this with their naming scheme, such that system/sw/Foo always contains everything you can change about Foo. I am not an expert in elektra, but from reading their page that's what it looks like to me.

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.

Could you expand on that?

Re:Sounds like the windows registry

[coaxial]

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

It's text based. So they're not exactly reimpleneting windows' registry, but rather GNOME's gconf, which is of course, windows' registry only xml based.

GConf means well. It's something that makes sense for the GNOME as a system (e.g. being able to query what is the default web browser for instance). I'm just not convinced for its use for individual apps, especially since state information is meant to be stored outside of gconf. Also, while GConf isn't explicitly tied to GNOME, I doubt it will be used by anything besides GNOME. Just like every other platform invented tool.

Re:Sounds like the windows registry

[coaxial]

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.

GConf, which is exactly what Elektra is reimplenting, has these same problems. (Most likely because gconf is pretty much an xml registry.) When keys change or become defunct many applications (GNOME Panel! I'm talking to you!) just simply leave them.

Right now my gconf has droppings from every instance of every applet I've ever added to my panel. I'm never going to readd keyboard indicator, yet there it is. Infact if I ever do readd keyboard indicator, it will create a new hierarchy.

I have /desktop/gnome/applications/browser and /desktop/gnome/url-handlers/http. They both semantically do the same thing, but browser is defunct, but still there. Hell, under /desktop/gnome/url-handlers/http, I've keys needs_terminal and need-terminal. One of these is wrong. I have no idea which because some url-handlers only have needs_terminal, but others only have need-terminal.

Applications should clean up after themselves.

Re:Sounds like the windows registry

[kevingc]

There must be a good reason to have "a universal, hierarchical, fast and consistent namespace and infrastructure to access configuration parameters through a key-value pair mechanism" since Microsoft AND Apple use it...

It can't just be a coincidence, can it?

Re:Sounds like the windows registry

[Anonymous Coward]

apt is able to remove those files:
apt-get remove --purge foo
without the purge option all settings remain in place.. however what isn't deleted are user-settings in $HOME - which isn't too bad..

Re:Sounds like the windows registry

[MemoryDragon]

Actually Elektra is not like the registry, it is more like the config file mechanism which exists in java. The registry is problematic, but the reason is different. That thing is an absymal data junkyard, ever program can dump its data into any position without caring anything, and there is no real structure behind it. The Windows registry is sort of like a unix filesystem (there are huge similarites) you can dump your data into 5 different places and in the end nobody can figure out anymore where the data is. Add to that the problematic editability and that the whole thing mostly is stored in ram, and you have a bigger mess than the config files (which the registry should have been a solution from) ever were. Having some kind of middle layer which allows unified access on application level and having config files in the backend to store the data has been a wise approach in the past, and works in Java really well. Java has many problems, but the config file mechanism definitely is not, you dont even have to care where to store the files to, no parsing nothing, just a plain dom like tree to work on.

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.

EW

[FLAGGR]

I've heard of Elektra before, its an evil attemp to make a windows-registry clone in Linux. Ew ew ew ew.

Re:EW

[ZephyrXero]

Can we get a "troll" mod here?

Re:EW

[ZephyrXero]

Umm... I was talking about the parent, not my post...lol

Re:EW

[Anonymous Coward]

someone mod this funny it sure made me laugh

Re:EW

[Anonymous Coward]

it does sound from the user page as it could be an attempt to make a windows-registry clone.

This is a bad thing in windows since a windows reinstall because of the registry often results in a programs reinstall.

Bringing this to linux doesn't seem to be a good idea. perhaps I misunderstand the project but I do not see how this benefits linux.

having a unified resource for configuration files a folder full of textfiles saying for example in foo.txt
foo.app has configuration files in bar/foo/cfg.
that could be useful to administrators wanting to configure an application.

but the loss of foo.txt shouldnt mean the loss of the actual configuration files for foo.app that is foo.app knows where its config is and
will continue to run regardless what happens to foo.txt

see the difference? one place to look for where the config files is a great thing for admins. but not for an individual application.
possibly a single tool could be written to rebuild the text files stored in this location. thats useful knowing what programs you have on you system.
but definately not a windows registry.
and if foo.txt was simply path information to foo.app config files that would be machine readable for any tool to find the path to a particular programs config files.

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.

Re:More BeOS than OS X

[ZephyrXero]

If you look at the screens, they call their system "BeFree" ;)

Mac OS X

[falcon203e]

It looks like they're basically building a better GUI engine for Mac OS X. The GUI in OS X is currently a mess. Ask any Mac themer. I hope Apple buys this from these guys and fixes Aqua.

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?

Re:Mac OS X

[WMD_88]

You can theme OS X:
http://www.maxthemes.com/themes/

Re:Mac OS X

[sl3xd]

It's just yet another clone of the BeOS UI, and a bad one at that.

Not being that familiar with the BeOS UI (I played with BeOS, but that's about as far as it went, since it didn't support most of my hardware). Just exactly what makes it a bad clone of the BeOS UI?

Or, perhaps a bit more clearly: What about the BeOS UI is so different (and wonderful) compared to any of the other GUI's I've used (Mac, Win, CDE, KDE, GNOME, Photon, etc. The BeOS GUI didn't seem to have anything that set it apart from the others, other than instead of a full window title, it had a tab...

Re:Mac OS X

[dr.badass]

Just exactly what makes it a bad clone of the BeOS UI?

I guess what I meant to say was that of the far-too-many BeOS clones I've seen, this one looks the least interesting, because it's only a clone of the look and feel. That said, most others do the opposite -- trying to reimplement BeOS from the ground up, or build new AppKit on top of Linux, with no UI yet.

I don't know about anyone else, but the things I remember fondly from BeOS were not the icons and widgets, or the pervasive multithreading -- they were the things I could do with it, that I couldn't elsewhere.

The ability to do extremely fast metadata searches, and save queries as folders that update in realtime is the only thing that kept me on BeOS for more than a month, and was definitely the hardest thing to leave behind. (There were other nice things, like the 10-second boot times, but the above is what stuck out after three months of full-time use.)

Most open source hackers would tell you that this was possible thanks to the 64-bit journaled database-like filesystem, but I think you'd get that response because most open source hackers know more about coding concrete things like filesystems with easily quantifiable goals (bigger, better, faster) than more mysterious things like interfaces, where the goal of "more useful" is often fairly subjective. Consequently, more time is spent concerned with implementation than capability. (Witness many of the comments on this article, trouncing the Elecktra configuration system because of it's resemblance to the Windows registry, with little regard to whether or not it might be more useful.)

Enter Apple's (I know this is getting a little OT, but bear with me) Spotlight, which lets you do extremely fast metadata (and content) searches, and save them as folders that update in realtime, without a specialized filesystem. So, yes, it is possible. Be's implementation wasn't perfect, nor is Apple's, but the idea is sound, it works, and it's incredibly useful.

So, what I'm saying is that Mockup is a bad clone (and most clones are bad) because it overlooks the truly useful and innovative aspects of the UI in favor of the ever-mutable visual and behavioral aspects. Furthermore, I suspect this is due to a naive understanding of interface design that's pervasive in the OSS community.

Re:Mac OS X

[plfiorini]

Mockup is not a BeOS clone, what are you saying?
BeOS clones are dead, even yT can't make a polished and stable product having what could be BeOS R6.

Mockup it's about graphical user interface design, ok I know there's a lack of documents but remember this is an alpha release.

Re:Mac OS X

[dr.badass]

Mockup is not a BeOS clone, what are you saying?

I know you're not cloning the OS as a whole, but you are quite clearly taking from the GUI, and that of Mac OS X. Copying is not bad in and of itself, but you're copying the least important parts. Window tabs, for instance -- yes, they look kind of cool, but they don't make a better interface. What other reason is there for them than to look like BeOS?

I'm not trying to trash your project -- please work on whatever you want to work on -- but I really think your efforts would be better spent involved in an existing project than branching off into a new, incompatable, project.

Re:Mac OS X

[plfiorini]

Never thought that I might like the title bar as a tab? The title bar uses the space it needs just like windows. Size should be adjusted to contents. I'm neither copying MacOS X. Just because there's a panel, it doesn't mean it's the same as OSX dock. OK, it's pretty hard to explain how ti should work only with an image. The panel should only show icons of minimized windows, and when the mouse pointer go on it a popup lists the windows that belong to the application with some items to minimize all the windows and close them all. Yes, it's like OSX and BeOS except for the fact that works in a different way :)

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.

Re:Electra almost there

[ZephyrXero]

Why not give these suggestions to the Elektra coders rather than bitch about it on a Slashdot thread? Isn't that the whole purpose of open source? And if you don't like it, fork off! ;P

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

[Anonymous Coward]

The UNIX permission system can only be seen as a failure from a security point of view, and you want to weaken it? Brilliant.

Re:ACLs are not a step forward

[ka9dgx]

The UNIX permission system IS a failure. It forces everyone to try to accomidate reality with a very bad data model. It expects everything and everyone fit into a single 2 layer model (Everyone, My Group, Me)

The last 30 years have shown that this just doesn't work. ACL systems are far more powerful, not to mention intuitive. ACL systems can NOT be replaced by this model, and any real world system just won't fit. (Especially when you're constrained to 256 possible groups)

--Mike--

Re:ACLs are not a step forward

[La Camiseta]

It expects everything and everyone fit into a single 2 layer model (Everyone, My Group, Me)

Looks like 3 layers there to me...

Anyways, people can belong to multiple groups, so there's a lot of flexability in that, it's not just your group that the permissions can be set for. Now if only there was some way to provide group inheritance, then it'd provide just a huge ammount of flexability.

Re:ACLs are not a step forward

[Malor]

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.

Microsoft has been doing this right for a long time, and they were pushing the AGLP standard in the NT 4.0 days (the last Windows I truly administered in a very complex environment.) AGLP means:

A)ccounts go in G)lobal groups; (the ones on your domain controller)
Global groups go in L)ocal groups; (the ones sitting on your fileservers)
Local groups get P)ermissions. (the actual filesystems)

How this translated for me was this:

Global groups, ones on the domain controller, specify GROUPS OF PEOPLE;
Local groups, ones on physical servers, describe SETS OF PERMISSIONS
(at least) three groups are made for each share on a server: Share RO, Share RW, Share Admin. Additional Local groups might be needed if you had weird permissions requirements, but I never did.
Permissions are assigned ONCE EVER to the filesystem, children inheriting from their parents.

So, when you're building a server, you decide what shares you want. You create 3 groups for each share, and assign the correct rights to each group on each share. You then load Domain groups into your local groups. If I'm building a machine for Accounting, I might put the "Accounting Staff" domain group in the "Accounting Share RW" local group. I'd probably put the Domain group of "Accounting Managers" (even if there was only one manager, I'd still name it plural and put him in it) into "Accounting Share Admin" group. And I might put the "Upper Management" domain group in the RO group.

You just always, always stick with this standard. If you need a specific person to have specific access to a specific share, you *create a special domain group for them*. If you can't think of anything better, perhaps "People with RO Access to Accounting Share". You then put that group in the server's local group. From then on, if you need to give that specific permission to others, you just stick them in that special Domain group. Note that it's better to have Global groups be more functional descriptions rather than permissions descriptions, but no model handles 100% of all possible permissions weirdness perfectly.

By creating sensible groups at the Domain level, and putting individual accounts in the proper Domain groups, you remove all need to EVER change permission on files. You don't ever, ever have to touch a filesystem again to change permissions, assuming you were sufficiently granular with your Local groups and filesystem permissions to begin with. You can manage literally MILLIONS OF FILES with just a few clicks in User Manager. What used to take hours (reassigning permissions on a zillion files) now takes only seconds... just swapping people into and out of groups. (or, perhaps, swapping Global groups in and out of Local groups.)

NT's ACL system, in other words, can let you abstract your information policy, even make it somewhat visual, so that at each level you're only dealing one thing. You can make vast, sweeping security policy changes with just a few clicks and WITHOUT BUGS.

(Note: there are some additions to this model that are necessitated by how Active Directory works, so don't take this as literal gospel. It's still a good model, but it needs some adjustment to work properly with AD. I'm not familiar enough with the specifics to tell you, but I know 2K has added a couple more group types, so it may require another level of abstraction.)

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

Unix permissions, in other words, SUCK ROCKS. They're HORRIBLE. ACLS are both far more elegant and far more powerful.

Re:ACLs are not a step forward

[Anonymous Coward]

The UNIX permission system can only be seen as a failure from a security point of view,

You're confusing security performance with security features. UNIX has performed very well on security, precisely because it offers few security features.

Microsoft offers many security features, which is the reason why their security is so poor.

and you want to weaken it?

Simplifying permission systems strengthens security.

Brilliant.

Quite right.

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.

Re:ACLs are not a step forward

[Malor]

You, sir, are out of your mind. Some people are stupid, therefore all complexity is to be removed. You make vague generalities about how some people somewhere (no actual proof, mind you) blew it on ACLs, so ACLs are bad. Argument by assertion is not proof.

A good ACL system is more powerful, more flexible, and conceptually one heck of a lot easier than the very primitive Unix permissions. The Byzantine workarounds required to implement a truly complex permissions setup in Unix make it far, FAR easier to make mistakes.

If we grant your assertion that people are stupid, then a very precise permissions system is much to be desired, since there is far more of a chance to make a bad mistake mapping a knotty permissions problem onto the simplistic Unix design.

Like it or not, some people NEED complex permissions sets. Unix wasn't designed the way it was designed 'to be secure', Unix was designed the way it was because that's ALL THEY THOUGHT THEY NEEDED THIRTY YEARS AGO.

There's a REASON groups like the NSA are pushing the complex permission structures like SELinux... it's because what we have now is grossly inadequate. Just as the Unixy OSes don't have the language to describe precisely enough what sorts of permissions programs should have, the Unixy filesystems (mostly) don't have permissions structures that easily cover real-world scenarios.

ACLs have that power, and just because some people use them badly is no reason to dismiss them. In the real world, they WORK BETTER.

Re:ACLs are not a step forward

[Xross_Ied]

Windows style ACLs are n-way permissions (n = # of files + directories + users + groups)
UNIX ugo/rwx is 3 way permissions

Both have pros and cons.

I don't like either..
Unix:
- 3 way is limiting on systems where non-primary groups are limited to a few users (Redhat Enterprise 3, at least it is broken on 3 servers I have).

MS-ACLs:
- Very hard to audit from a security prespective.

A better solution is what Novell Netware has..
+ ownership of a directory or file does not give you rights to that dir/file.
+ file ownership only counts towards you diskquota.
+ a file can have rights assigned for an arbitrary number of users and/or groups (rarely needed).
+ a directory can have rights assigned to an arbitrary number of users and/or groups.
+ directory rights cascade down into the subtree.
+ if you want to block cascaded rights you can place an inherited rights filter on a sub-file or sub-directory.
+ Supervisor right: equivalent of root for the file or directory.
+ Read right: can read the file
+ FileScan right: can get file/directory listing
+ Write right: can write to file/directory
+ Erase right: can erase/delete a file/directory
+ Create right: can create a file in a directory
+ Modify right: can modify a file/directory
+ Access right: can assign permissions/rights to other users/groups (delegated administration)

IF you create usergroups for each set of users that need specific permissions, the set of rights assigned to the filesystem is minimized.

Yes you have many user groups but you would have at least the same number of groups with MS-Style ACLs and with UNIX (more groups).

I can give a concrete example of where UNIX style permissions fail..

A Linux server with students and instructors (college). Each user has a webspace (~/public_html) where they need to be able to run cgi, jsp, etc. How to set permissions such that..
a) apache user can read contents of ~/public_html b) no student can read contents of other students or staff's ~/public_html as cgi, jsp, which contain database connection information (should not be visible to anyone except owner).

Upto this point all staff and students should be in primary group "users" and user apache is NOT in users.
public_html rwx---r-x "users"

Now what if some students need to work together in a group for a group project? You can't do it with one of the student's accounts, you have to create a special project group user for them to share. This is plain silly..
a) I should be able to assign rights for students in that group to one of the student's /public_html/group_project directory

OR if I am really lazy (or if there are thousands of students)..
b) I should be able to delegate permission assignment to each student, i.e. each student can assign rights to other stuednts/groups to files under their own homedirectory.

Re:ACLs are not a step forward

[spitzak]

Although I agree that ACL's are a good idea, your description of NT sounds EXACTLY like Unix groups. In fact your post could be considered an argument against ACL's and for Unix groups. This does not lead me to believe you really know what you are talking about.

Re:ACLs are not a step forward

[jeif1k]

You, sir, are out of your mind. Some people are stupid, therefore all complexity is to be removed. You make vague generalities about how some people somewhere (no actual proof, mind you) blew it on ACLs, so ACLs are bad.

No, you make vague generalities asserting that ACLs are somehow better, yet you fail to provide any proof for that assertion.

In fact, there is some evidence that we have. UNIX permissions have been used successfully for decades on multiuser timesharing systems. Windows isn't even capable of timesharing, its local security has never been demonstrated, and it ships full of security and permission problems. I'd say it's pretty clear who gets it right and who gets it wrong. The burden of proof is clearly on you if you want to argue that the Windows permission system is "better".

Argument by assertion is not proof.

Yes, and don't you forget it. So, where is your data? Where is your proof?

Re:ACLs are not a step forward

[jeif1k]

Windows style ACLs are n-way permissions (n = # of files + directories + users + groups) UNIX ugo/rwx is 3 way permissions

You seem to be missing a crucial fact about UNIX groups: every user can be in multiple groups. That gives you the same flexibility as ACLs.

I can give a concrete example of where UNIX style permissions fail.. A Linux server with students and instructors (college). Each user has a webspace (~/public_html) where they need to be able to run cgi, jsp, etc. How to set permissions such that.. a) apache user can read contents of ~/public_html b) no student can read contents of other students or staff's ~/public_html as cgi, jsp, which contain database connection information (should not be visible to anyone except owner).

Just configure the Apache web server to do what you want; it has an option to handle exactly that case.

Now what if some students need to work together in a group for a group project? You can't do it with one of the student's accounts, you have to create a special project group user for them to share. This is plain silly..

Of course, the students can do it with their own accounts. If you want students to work on a project in a group, you create a UNIX group for that project and put all the students into it. You don't need a "project user".

OR if I am really lazy (or if there are thousands of students).. b) I should be able to delegate permission assignment to each student, i.e. each student can assign rights to other stuednts/groups to files under their own homedirectory.

You can: delegation of privileges in UNIX is handled via setuid/setgid. There are various existing tools to handle specific kinds of delegation (e.g., sudo). If none of those meet your needs, you have far more flexibility to create your own than if you were stuck with ACLs.

Re:ACLs are not a step forward

[Xross_Ied]

You seem to be missing a crucial fact about UNIX groups: every user can be in multiple groups. That gives you the same flexibility as ACLs.

How about a non-primary group of a thousand users? This does not work for me on Redhat Enterprise 3 update 3 release; utilities segfault around 100 users. I have asked redhat and they don't have an answer (its been 4 months).

Also, how about a directory where a large group of users have read/write access and the application is such that files are created and deleted frequently. On OSX 10.3.7, only owner can delete files, how does one go about allowing anyone in the group to delete files? Aside from making a completely separate share one can't do that.

Also, (on OSX same situtation as above) how about when the workflow is such that a file is created in a directory by one user and then another user works on it and then another user works on it and so on. Why should the files' ownership remain with the first user? How would you handle disk quotas? What if the first user isn't just one user but a subset of users that you don't know ahead of time (fluid workflow in dynamic teams).

Just configure the Apache web server to do what you want; it has an option to handle exactly that case.

Please elaborate.

Of course, the students can do it with their own accounts. If you want students to work on a project in a group, you create a UNIX group for that project and put all the students into it. You don't need a "project user".

For small course projects of 3 students for 2months (roughly 60 groups across multiple sections of the course), you want me to create unique groups and preconfigure a sub-directory for each group? Instead of delegating right assignment permission to each student; they manage access to their group and their own file structure?

You can: delegation of privileges in UNIX is handled via setuid/setgid. There are various existing tools to handle specific kinds of delegation (e.g., sudo). If none of those meet your needs, you have far more flexibility to create your own than if you were stuck with ACLs.

You want me to setuid/setgid different utilities on a server where students have shell access? What are you a noob or something? Sudo would be slightly more secure but still not much of an improvement.

Why should I create my own delegation tools when ACLs (which delegation of permissions support) is all I really need?

Re:ACLs are not a step forward

[jeif1k]

This does not work for me on Redhat Enterprise 3 update 3 release; utilities segfault around 100 users. I have asked redhat and they don't have an answer (its been 4 months).

Submit bugs to the creators of those utilities not to RedHat; RedHat just bundles the stuff.

Also, (on OSX same situtation as above)

OSX isn't UNIX, it has a cumbersome, hard-to-program, and non-standard administrative database, and it doesn't have UNIX file systems semantics, so these kinds of things may be a lot harder to do on OSX.

how about when the workflow is such that a file is created in a directory by one user and then another user works on it and then another user works on it and so on. Why should the files' ownership remain with the first user? How would you handle disk quotas? What if the first user isn't just one user but a subset of users that you don't know ahead of time (fluid workflow in dynamic teams).

You (or, rather, someone who actually knows how to write simple programs--most IT departments have such people around) create a small setuid program that implements the constraints you want for your workflow needs and your quota system.

For small course projects of 3 students for 2months (roughly 60 groups across multiple sections of the course), you want me to create unique groups and preconfigure a sub-directory for each group?

Most people would use a small shell script to do it, or they'd delegate the ability to create and manage groups to students.

(Actually, most people in the 21st century wouldn't dream of doing this sort of thing with ACLs at all, they'd use a network-based version control system like Subversion, which has its own permission system.)

Instead of delegating right assignment permission to each student; they manage access to their group and their own file structure?

Yes, that's a great thing to do. Isn't it nice that it's so easy to do on UNIX?

You want me to setuid/setgid different utilities on a server where students have shell access?

Good grief, how dense can you be? No, I don't want you to "setuid/setgid different utilities", I want you to either use an existing framework or create your own set of utilities that actually express the kinds of operations you actually want to delegate to students.

But, actually, I don't want you to do even that because it's pretty clear that you would screw it up. In fact, I would prefer if people like you didn't use UNIX or Linux at all. I recommend that you switch to Windows NT with NTFS and ACLs. While that won't actually solve your problem correctly and will create lots of security problems for you, it will make you happy and it will keep UNIX/Linux from getting associated with your mistakes. Eventually, you'll lose your job and your successor can do things right.

Re:ACLs are not a step forward

[Xross_Ied]

OSX isn't UNIX, it has a cumbersome, hard-to-program, and non-standard administrative database, and it doesn't have UNIX file systems semantics, so these kinds of things may be a lot harder to do on OSX.

MacOSX has full bsd userland APIs and utilities; the kernel is a microkernel (mach) but it is all bsd on the commandline. Last I checked BSDs were consider Unix.
a) The administrative database is by default openldap instead of local files although if you really want you can use local files.
b) The filesystem is HFS+ or UFS (your choice) and on both unix file semantics are implemented.

Have you actually used MacOSX or are you a Linux bigot?

You (or, rather, someone who actually knows how to write simple programs--most IT departments have such people around) create a small setuid program that implements the constraints you want for your workflow needs and your quota system.

In the case of the quota example, all I need is simple file services for PC and Mac clients (no shell access to the server (artist type; they don't do commandline).

Good grief, how dense can you be? No, I don't want you to "setuid/setgid different utilities", I want you to either use an existing framework or create your own set of utilities that actually express the kinds of operations you actually want to delegate to students.

So I and any else that needs similar functionality should implement it ourselves instead of the OS providing this functionality?

Unix style permissions aren't great for network file services, which almost every organization needs.

Re:ACLs are not a step forward

[Nevyn]

How about a non-primary group of a thousand users? Redhat Enterprise 3 update 3 release; utilities segfault around 100 users. I have asked redhat and they don't have an answer (its been 4 months)

Are you trying to use a flat groups file for this? What level of support do you have? What is your IT/CRM/BZ number? What is your support person saying (people don't generally pay money for no responses ... although obviously Red Hat can't fix everything).

Certainly utilities Segfaulting is bad, however as far as I know the only limitation is on the number of groups a uid can be in at once.

Re:ACLs are not a step forward

[Xross_Ied]

Hmm haven't looked at this in sometime, it is on my list of things to get back to.

Yes flat group file (the default /etc/groups and gshadow).

Redhat Enterprise ES, not sure about the IT/CRM/BZ number, this is our company account number with Redhat, right?

Redhat asked for debug output (which I provided) and haven't heard anything since.

I just checked the server and the most groups any given user is in is 5.
Notable points..
a) 1000 students are in the primary "users" group and the g_student group with some students in "special groups" for course projects
b) 200 staff and instructors are in primary "users" group and the g_staff group with each instructor in a departmental group as well.
c) all students accounts are padded/truncated to 8characters (letters and digits only)
d) all staff and instructor accounts are 8 or less char (letters only, no hyphens, etc)
e) some UIDs are >65535 but all GIDs are 5000

Other than that pretty vanilla; did a manual check of.. /etc/group /etc/gshadow /etc/passwd
to make sure the username and group names are all correct and there does not appear to be any visible corruption of the files.

Re:ACLs are not a step forward

[Nevyn]

Redhat Enterprise ES, not sure about the IT/CRM/BZ number, this is our company account number with Redhat, right?

No, those are support system numbers. BZ == bugzilla.redhat.com (but you shouldn't be working with BZ directly, you probably use something off: https://www.redhat.com/apps/support/

Yes flat group file (the default /etc/groups and gshadow).

While still bad, that's a little more understandable. Most people use NIS or LDAP for any non-simple installation, so the flat file code isn't in production as much for "large" data sets like yours.

Apart from that nothing looks abnormal with your installation.

Re:ACLs are not a step forward

[jeif1k]

a) The administrative database is by default openldap instead of local files although if you really want you can use local files.

As I was saying, the way OS X represents administrative information is non-standard and overly complex. The fact that it may use a standard database to do something in a non-standard way doesn't change that.

b) The filesystem is HFS+ or UFS (your choice) and on both unix file semantics are implemented.

HFS+ doesn't even come close to implementing UNIX file system semantics, and UFS is not a viable choice for OS X users because it fails to implement Macintosh semantics properly.

Have you actually used MacOSX or are you a Linux bigot?

I have a couple of OS X machines (as well as some Linux and Windows machines and a few Suns).

So I and any else that needs similar functionality should implement it ourselves instead of the OS providing this functionality? [...] In the case of the quota example, all I need is simple file services for PC and Mac clients (no shell access to the server (artist type; they don't do commandline).

So, you are saying that you expect your "artist types" to fiddle around with ACLs in Windows XP file properties, and that's the basis for your workflow? Oh, boy.

If you want workflow, get a workflow system. Workflow systems can be implemented easily on top of UNIX using the permission mechanisms that exist in UNIX today, using whatever interface (command line, GUI, web) your users prefer.

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.

Re:The evolution of config files

[Anonymous Coward]

You mean like.. THE FILESYSTEM?

Um... well, yeah. That's exactly what they mean. Didn't you RTFA?

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.

They didn't.

Please don't write another broken parser.

They didn't.

Please don't use XML for anything a human has to edit.

They didn't.

Please please don't make me link in an API just to read/write the config settings.

They didn't.

Hmm. Yah, looks like you didn't bother to RTFA.

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.

Re:aiming low

[mailman-zero]

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.

Projects like enlightenment are striving to innovate by creating new libraries and shunning the current crop of toolkits that assume too much and constrain design to a rather limited set of possibilities.

purge doesn't always work

[Anonymous Coward]

i left debian a long long time ago looking for something better (ended up with freebsd 2.2.6) because i was annoyed with the number of packages installed, how the base system wasn't just seen as a base system. i could see that ae was 'required' even though i knew it wasn't, and as dumb or whatever as it sounds i would prefer that it exist without my knowledge as part of a singular 'base' package. i would always go through and delete things like that manually, but when i *PURGED* ae and it left /etc/ae.conf i started looking for alternatives.

Getting it right

[metalhed77]

Linux has a lot of the software necessary for a great operating system. The problem seems to be tying it together neatly. This is why there are so many projects like this, it's a good thing.

Re:Getting it right

[ZephyrXero]

Think of it maybe like the difference between old Mozilla and Firefox. Firefox built upon the Mozilla code base, but was structured differently and a much better app. Linux could use the same...

Re:Getting it right

[pilot1]

I don't agree.
Why is this better than simply sending the patches on to the Linux kernel developers, and developing your own distribution?
That way it would cause no more fragmentation than distributions already do, and they would get a chance to show the rest of the GNU/Linux crowd that their config-management and desktop enviroment ideas really are useful.

This is a good thing

[Rysc]

This is a very good thing.

No, not Mockup. Mockup might be fun after a while, if it tkaes off, which it wont. Elektra is a good thing.

The Elektra guys need to go have a chat with the Gobolinux guys. These two groups were MADE for each other.

What Elektra does is not new or exciting, it's old and simple. This is a "Finally! At last!" more than a "Oooh, shiney!" They are attempting, once gain, to sanify /etc. They're doing it without requiring every program to be changed at once. They're doing it without assuming everything will be world writable. They're doing it without discarding command line configuration editing.

Everything is a text file, so it's easy to edit by hand. Everything is regular, so it's easy to build GUIs for editing it automatically. What they're saying meshes really well with what Hans Reiser has said about filesystems and namespaces, and that guy knows his stuff.

They absolutely do not add anything fancy, which is really good.

I'd like to see some few expansions of the idea:

The ability of they command line tool (kdb edit) to return editable text in more formats than just XML; specifically, for it to use YAML. The biggest drawback to spliting config data into multiple files is the difficulty in editing many related options, which their XML idea nicely solves... but since't it's hell to edit XML but fairly easy to edit YAML, a YAML mode would be nice.

A renaming of their tool, maybe to cfg or conf or something pretentious like that. That way the directory could be /etc/cfg, and perhaps eventually just /cfg if the idea takes off.

Lose the UTF-8 requirements. While nice, it does not mesh well with command line tools, and should be left to the application anyway.

As another poster mentioned, remove comments from the config files themselves. I propose appending a # prefix to files which are comments for files with the same name, e.g.:
system/sw/Foo/firstrun
and then the comment:
system/sw/Foo/#firstrun

Which is semantically very understandable and does not too greatly reduce the available symbols for key names.

As another poster said, make using the library optional, since it's almost is as things stand. There is value to the library for application developers, for consistency and convenience, but it should not be in any way necessary.

The greatest value Elektra adds is "just" sane namespace management, although there is nothing paltry about that.

Re:This is a good thing

[menetto]

One of the contras is that it has a file for each configuration value. So you have to happen a file for each value. And if you look at the number of parameters a program as mutt requires, it appears to me that this will be deadly slow.

How I'd like it: Cascading Configuration

[Bitsy Boffin]

Seems most of the discussion here is regarding the configuration system. So, in that same vein here is how I'd like configuration.

Basically, you know CSS (Cascading StyleSheets) as using in HTML, well, we do the same thing for configuration, call them CCS (Cascading Configuration Sheet).

Lets take an example application, "fooApp".

/etc/main.ccs
-------------
fooApp somePropertiesGroup
{
some-property : some value;
}

/etc/fooApp.ccs
---------------
som ePropertiesGroup
{
some-property : some value;
some-other-property : some other value; !important
}

$HOME/etc/fooApp.ccs
----------- ---------
somePropertiesGroup
{
some-property : a different value;
some-other-property: some other value that is ignored because /etc/fooApp.ccs defines it as !important;
}

Thats just scratching the surface, but you get the idea, basically take the format of CSS, and apply that to configuration. Have a standard set of calls to get a configuration, it starts with /etc/main.ccs, merges in /etc/fooApp.ccs, merges in $HOME/etc/user.ccs, merges in $HOME/fooApp.ccs etc etc (natch, only at startup or when a file changes) applying the standard cascade rules.

You could also use classes within the configuration, eg say you do

bash$ fooApp --className=mySpecialFoo

then you could have

$HOME/etc/fooApp.ccs
--------------------
.mySpe cialFoo somePropertiesGroup
{
some-property : special property here for mySpecialFoo instances of fooApp;
}

Just my 2c.

Re:How I'd like it: Cascading Configuration

[setagllib]

Which is way overcomplicated to parse and often write. Have you completely missed the discussion in this thread about the ideal way of storing configurations? Your way is arguably even worse than XML which at least has libraries for it already.

Re:How I'd like it: Cascading Configuration

[Bitsy Boffin]

I don't see it would be difficult to parse, infact it's a pretty simple markup in all, certainly not difficult to write.

Meta-registry

[caseih]

The idea of a registry is not inherently flawed, but the implementations of it are. gconf and elektra both seem to be decent implementations. the registry database is an aggregation of many files. This means that the package manager can add registry entries and remove them automatically without having to result to programmatic uninstall programs. This keeps the registry from getting full of crap like it does get on Windows. Simply delete the application (rpm -e) and the entries are gone. The problem of local entries (like local dotfiles) in the home directory remains, though. Anyway, I'll wait to see what this all does before I pass judgement on Elektra itself. Something like this should, however, work under in the freedesktop.org umbrella. Making yet another desktop environment seems problematic.

Elektra, it was about time

[MemoryDragon]

Great project, it was about time. I know that system from Java, having a good library dealing with configuration files is great. First, you have a nice standardized api, then you don't have to care, where to save the files, the parsing or what grammar you use.

In java all comes down to build a property entry pair or some kind of dom tree in newer versions and then simply say save (filename) and you dont have to care about the correct place to set the file the parsing anything. Sort of like having the advantages of the windows registry (good standardized access api) without the hazzles (entry clutter not really manually editable, one big database which resides in ram etc...)