Imho the approach of using win like registry is a bad idea. But what could be done is(I think it was already tried or something) is to still keep the normal configuration files but get them parsed into and shown if you care like registry... butthen it would still store them back to the old format... basicaly you combine the best possible approach with this one...
Re: I really don't like the name
Maybe something like modernetc or something with these letters. I read all the comments and starts thinking that this would really be a great idea but will surely takes a great deal of effort to come at life. We will see... I don't think there's a future thought
> % I really think we should do something
> better .....
> What you sugest?
> Other similar projects are less popular
> because they have
> different names.
> Also, I'm trying to address the MS
> registry's problems like
> centralization, etc.
> A filesystem is one possible backend. Is
> provides automatic hierarchy, security
> etc. Other implementations may come.
I didn't see any stubs in the code for a kind of "backend plugin" mechanism.
> LR is not for enterprise cross-server
> administration. For this, use LDAP, NIS,
I meant enterprise level of managing workstations also.
> LR was created to substitute
> human-readable text configuration files
I know, and it's wrong IMHO. You're trying to implement functionality of MS registry, but its ideology is outdated; it's already at least one-generation old even in the MS world. I fully agree that it's a way better than the current zoo of Unix configuration schemes/formats, but are you serious about persuading a major part of Linux/Unix developers/vendors something so dated is worth a _lot_ of efforts to convert to? I doubt so.
> Because precisely RDBMS is dumbness.
> RDBMS is not available for early boot
> stage programs, like /sbin/init,
Depends on RDBMS. With e.g. SQLite you get it immediately. Also, according to your logic, it's impossible to use LDAP on localhost for authentication. But PAM nicely prooves otherwise. Again, because it use a smart plugin/augumenting approach. For initial system setup, plain text files works, and when the LDAP server is ready, it extends the initial small auth DB. But all apps linked to libpam know knowthing about it.
> RDBMS are a too complex substitute for
> simple text files. It is a sandbox,
> problematic to administer in critical
Come on, a corrupted filesystem (especially with many thousands of inodes) isn't easier to deal with than a corrupted RDBMS storage. Tell it to banks etc which trust these sandboxes to store transactions worth of billions of bucks. It's all about backups and reliability of design.
> Please read the specs before
> Nope. Using FS in this manner is a dead
> end with no feasible way of solving
> scalability problems. It's even more
> doomed than gconf. Try to estimate the
> number of inodes per user assuming all
> apps switched to LR. You'll easily count
> thousands; for true multi-user systems,
> that'll go to hundreds of thousands.
A filesystem is one possible backend. Is provides automatic hierarchy, security etc. Other implementations may come. The main point is the API and the keys namespace. Possible options are unique text file per folder, etc.
> what about enterprise-level
> configuration management?!
LR is not for enterprise cross-server administration. For this, use LDAP, NIS, etc. LR was created to substitute human-readable text configuration files only.
> Not to mention inherited dumbness of
> such a configuration storage. Why not
> use a smart backend, e.g. an RDBMS? Just
> imagine what kind of unparalleled power
> and flexibility one gets with
> views/triggeres/... And you get
> rollback/replication/... for free.
Because precisely RDBMS is dumbness. RDBMS is not available for early boot stage programs, like /sbin/init, and RDBMS are a too complex substitute for simple text files. It is a sandbox, problematic to administer in critical situations.
Please read the specs before argumenting. All the points you mentioned are explained there.
> I like idea of using filesystem as
> backend, any
> performance issues (if there would be
> any) are fs
Nope. Using FS in this manner is a dead end with no feasible way of solving scalability problems. It's even more doomed than gconf. Try to estimate the number of inodes per user assuming all apps switched to LR. You'll easily count thousands; for true multi-user systems, that'll go to hundreds of thousands. And what about enterprise-level configuration management?!
Not to mention inherited dumbness of such a configuration storage. Why not use a smart backend, e.g. an RDBMS? Just imagine what kind of unparalleled power and flexibility one gets with views/triggeres/... And you get rollback/replication/... for free.
I like idea of using filesystem as backend, any
performance issues (if there would be any) are fs
To get it widely used big distro (like Debian) must
I like it...
I like the idea, really.
Let's take a major idea: Linux MUST become user-friendly to be used by many companies that doesn't support it because it is "too hard to use".
Believe me, most users don't know what a HDD is! Do you want them to know how to configure his browser's preferences using VI? NO!
I think the LR idea could lead to another project to act like a "Control Panel", but as *nix was born with security in mind, the results of a major project would be great for the end-user installing a distro at home and admins with hundreds of stations running on a diskless environment.
I Believe linux really needs unified development for "real world software". Although OpenOffice is a great software, it still misses many functions/features to become really "friendly" and "compatible".
Many "to be great" softwares development are ceased so soon that you just can't get a stable release of them. I mean that there are so many "wheel re-inventing" taking nice coded softwares to suddenly disappear... that is VERY sad. Thounsands of hours of programming wasted.
I was amazed when i ran KDE 3.2; it IS fast! But you still see thousands of apps on the menu... too sad... you could have 1/10 of those to do the same things...
And GConf is a real mess... dependencies et al.
That's it, LR has my support to keep going and grow up, i'll be happy to see it supported by the major distros.
Re: I think this is a bad idea
> % The Registry isn't in one file, but
> % folder is an
> % actual folder, and each key is a file.
> % That means it can
> % use the filesystem's security.
> Holy cow!!!!! One of the comments above
> stated that each program having its own
> config file results in a fat and bulky
> system. Now, its being suggested that
> not only each program be included in a
> single registry, but *EACH KEY BE ITS
> OWN FILE*?!?!?!? And this isn't fat and
well if your file system is effiecient at saving small files then it's not bulky. If your file system is effecient at looking in large directories (use a modern system that uses hash tables for directories rather than flat dirs), then it will be fast. Ideally there should be little difference in performance between storing all your data in a single file using some effecient algorithms and storing each folder leaf as a file. Of course not ever file system is near this ideal, but most are pretty reasonable.
Performance of your configuration files should never be an issue. Applications would normally only look at configuration on start up, and perhaps occationally poll them to realize updates. If you have some small short life application that looks at configuration often (like procmail), then performance of configuration files would be an issue. But I would say that the model procmail uses is less than ideal, and perhaps you should have set it up in a batch mode if performance is critical.
> From a configuration managment this may
> seem like a good idea, but from a
> technical standpoint, the filesystem is
> going to suffer. Plus, managing 100+
> machines still isn't helped. For that
> matter, why not go one step further and
> instead of a system registry, make a
> network-based registry to house all the
> settings of all machines in one
Well the idea is with a generic API you could fetch configuration over LDAP or whatever transparently. This configuration file system would even work correctly over NFS.
> I agree that standard text files are
> still optimal. They are conducive to
> virutally *any* means of management.
> The registry requires an API, text files
> require human eyes...nothing more. Any
> scripting language can be used to write
> a script which traverses *thousands* of
> machines to adjust text files. This
> task would be much, much harder with an
> API-based registry.
registry is certainly human editable. It is designed specifically to allow you to edit, browse, back-up, search, etc using standard tools. vi to edit, cd and ls to browse, find to search, tar to back up. you can even edit a temporary copy and use mv to put it in place once you have verified your configuration is ready for production.
For space and performance a binary database would be ideal, but then you'd lose the benefit of being able to hand edit the configs if there was a catastropic failure.
every application implementing it's own flat file format results in a lot of duplicated code. Theoretically you could make applications smaller if they just linked in the same library for configurations and reused the same bit of code to read out of a registry. Although this registry is actual so simple, that you don't need a library (but it is recommended you use one). and generally implementations of this style of configuration are going to be a lot smaller than your typical XML-based or weird hierarchal formats (like bind or dhcpd)
> I commend the authors of the software
> for _wanting_ to make life easier for
> sys-admins of all stages. But I'm sorry
> guys, this does not _make_ it easier.
I think it has quite a bit of potential. And I commend the authors for having the guts to stray away from traditional Unix into something that might be easier. A major advantage of Free Software is that it can provide a way for an entire community to experiment with new ideas.
Also I'm not sure why you say so strongly that it does not make anything easier. Could you give an example of it not making things easier? All I saw were complaints about text files and having lots of files that would some how slow down a file system designed to have lots of small files on it.
I like the idea very much
I went through the docs quickly... I think the posibility of destroying the Linux Registry and thus making the whole system unusable is about the same as removing the whole /etc directory structure from your disk by accident.
The way one could destroy a key from registry is no different to removing /etc/inittab or any other config file. And the way one could insert a wrong value is no different to simply messing up a random line from /etc/fstab by accident...
But what you get! Centralized uniform configuration interface for the whole system. Stuff I've been always missing in UNIX.
It is so exciting only to imagine the entire Linux OS distribution based on a single configuration interface!
Despite the fact that no one here like the idea, i like it. Todays dot file are obsolete. Gnome and KDE know that for some times now. First, gnome's gconf is _not_ used by most gtk/gnome apps so it's completely useless. On the other hand, the KDE team did a great job in that area with configuration files, one single directory to store them all. (~/.kde/share/config). I haven't checked, but there is certainly an API for kde apps to store and retreive their configuration files. I hate my home directory being bloated with lots of dot file and gtk/gnome apps are the best to fill my home with those files. This project is a very good idea but it wont work until most program use it, including kde/gnome. There is a lot of PR todo ...
An open, cross-platform journaling program.
A scientific plotting package.