Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Introducing the Mockup Project 78

Posted by michael from the hand-that-mocked-heart-that-fed dept.
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."
This discussion has been archived. No new comments can be posted.

Introducing the Mockup Project More

Introducing the Mockup Project

Comments Filter:

  • Sounds like the windows registry (Score:5, Insightful)

    by n1ywb ( 555767 ) on Friday December 31, 2004 @09:56AM (#11227612) Homepage Journal
    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 (Score:4, Informative)

      by fuck nwbvt ( 836920 ) on Friday December 31, 2004 @10:04AM (#11227651) Journal
      Sounds to me more like Mac OS X's preferences system [apple.com] (accessed on the command line through the defaults [apple.com] utility).
    • The registry in Window$ keeps separate values for separate programs, much as is done in all these dot (.) settings files...
    • 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 prefere
    • 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 (Score:5, Interesting)

      by Earlybird ( 56426 ) <{slashdot} {at} {purefiction.net}> on Friday December 31, 2004 @11:07AM (#11228062) Homepage
      • 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.

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

      • 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

      • "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
        • 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-col
      • 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
      • 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 ch
      • 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

    • Re:Sounds like the windows registry (Score:4, Informative)

      by Hard_Code ( 49548 ) on Friday December 31, 2004 @12:05PM (#11228450)
      How about try reading about it: elektra documentation [sourceforge.net]

      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.

    • 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?)
    • 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?!
    • 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 [gnome.org], 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 outsi

  • Maybe not the Registry (Score:3, Insightful)

    by VernonNemitz ( 581327 ) on Friday December 31, 2004 @10:12AM (#11227706) Journal
    The description also sounds like it could be a very large .INI file.

  • No ACLs? (Score:5, Insightful)

    by ka9dgx ( 72702 ) on Friday December 31, 2004 @10:13AM (#11227710) Homepage Journal
    I looked at the mockup of the permissions [mockup.org] 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--

    • 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 wh
      • 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)oca
        • 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 descriptio
          • 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
            • 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 capabl
          • 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 ow
            • 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 tha

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

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

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

                    • 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, a

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

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

                    • 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/ [redhat.com]

                      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 p

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

  • Looks positively innovative (Score:5, Funny)

    by youknowmewell ( 754551 ) on Friday December 31, 2004 @10:18AM (#11227744)
    I haven't seen an interface like that since yesterday.

  • EW (Score:2, Troll)

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

  • So why is this special? (Score:4, Insightful)

    by pilot1 ( 610480 ) on Friday December 31, 2004 @10:34AM (#11227839)
    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.
    • 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.
      • 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...
        • 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.

  • Electra almost there (Score:4, Insightful)

    by spitzak ( 4019 ) on Friday December 31, 2004 @11:47AM (#11228327) Homepage
    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.
    • 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

  • The evolution of config files (Score:5, Insightful)

    by Anonymous Coward on Friday December 31, 2004 @12:07PM (#11228465)

    (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 [cr.yp.to] is a great example of how powerful and simple this can be.

  • aiming low (Score:3, Insightful)

    by jeif1k ( 809151 ) on Friday December 31, 2004 @12:13PM (#11228503)
    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.
    • 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 [enlightenment.org] 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.
  • 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 ass
    • 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.
  • 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

  • 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 o
  • 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 adva

Slashdot Top Deals

"An idealist is one who, on noticing that a rose smells better than a cabbage, concludes that it will also make better soup." - H.L. Mencken

Close