Branches
Comments
[»]
Idea...
by Andraž 'ruskie' Levstik - Oct 13th 2004 08:19:09
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...
[reply]
[top]
[»]
Approach
by Haden - Jul 27th 2004 11:53:12
I like idea of using filesystem as backend, any
performance issues (if there would be any) are fs
problems.
To get it widely used big distro (like Debian) must
step-in.
[reply]
[top]
[»]
Re: Approach
by Evgeny Stambulchik - Jul 27th 2004 14:15:45
> I like idea of using filesystem as
> backend, any
> performance issues (if there would be
> any) are fs
> problems.
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.
[reply]
[top]
[»]
Re: Approach
by Avi Alkalay - Jul 27th 2004 15:10:49
> 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.
> And
> 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.
--
[reply]
[top]
[»]
Re: Approach
by Evgeny Stambulchik - Jul 27th 2004 23:53:36
> 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,
> etc.
I meant enterprise level of managing workstations also.
> LR was created to substitute
> human-readable text configuration files
> only.
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.
> and
> RDBMS are a too complex substitute for
> simple text files. It is a sandbox,
> problematic to administer in critical
> situations.
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
> argumenting.
I did.
[reply]
[top]
[»]
I like it...
by MSilveira - Jul 27th 2004 11:27:14
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.
Mauricio
--
Helloooo Worrrrld! :D
[reply]
[top]
[»]
I like the idea very much
by Jan Tomka - Jul 27th 2004 10:40:27
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!
--
Jan Tomka
[reply]
[top]
[»]
Good Idea
by oksala - Jul 27th 2004 10:26:25
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 ...
[reply]
[top]
[»]
Bad idea. Those who don't know their history are doomed to repeat it.
by jkinz - Jun 2nd 2004 06:31:12
This is exactly the same thing as the microsoft windows registry.
It violates most of the basic UNIX and Linux design principles,
Most importantly:
Keep it simple
Make each tool do one thing in a stand alone fashion
The project originator has worked with MS software for too long and it has
affected his/her world view of how to build good systems.
Hopefully MS has patented the registry idea and won't licenses it to
anyone without fees.
[reply]
[top]
[»]
Re: Bad idea. Those who don't know their history are doomed to repeat it.
by Avi Alkalay - Jul 4th 2004 05:25:18
> This is exactly the same thing as the
> microsoft windows registry.
In the concept, not in the implementation.
> It violates most of the basic UNIX and
> Linux design principles,
> Most importantly:
>
> Keep it simple
The way it is today is not simple to humans, and
not simple at all for programs (to let them integrate
by themselves).
> Make each tool do one thing in a stand
> alone fashion
This leads to desintegration and to developers
reinvent the wheel. You end up with a fat and
frankstein system.
> Hopefully MS has patented the registry
> idea and won't licenses it to anyone
> without fees.
Can you point us to some more info about this?
--
[reply]
[top]
[»]
I think this is a bad idea
by David Kramer - Jun 1st 2004 21:12:25
One of the worst things about Windows (as a product, as opposed to
Microsoft as a company) is the registry system. It has nothing to do with
implementation. The fact that one config file controls every piece of
software on the machine, there is only one tool that can read and modify
this special config file, and that installing any program can change it for
better or worse, are just bad ideas.
What I see happening is what happened with the old Red Hat configuration
program. Something goes wrong, the database gets corrupted, and the box is
useless. Or some app overwrites the keys for some other app due to poor
usage of the API, and then they both fail.
Cleartext configuration files are safer, you can diff them, you can use
version control on them, you can hold multiple copies and switch them as
needed, and you can edit them using any one of dozens of tools.
If your goal is centralized configuration management, then lend your
efforts to webmin, which does an excellent job of centrally managing the
configuration of dozens of applications by letting the software know the
config file format.
[reply]
[top]
[»]
Re: I think this is a bad idea
by Rev. Adam Tauno Williams - Jun 10th 2004 05:38:24
> One of the worst things about Windows
> (as a product, as opposed to Microsoft
> as a company) is the registry system.
> It has nothing to do with
> implementation. The fact that one
> config file controls every piece of
> software on the machine, there is only
> one tool that can read and modify this
> special config file, and that installing
> any program can change it for better or
> worse, are just bad ideas.
It has everything to do with the implementation. What you are describing
is the result of an implementation that has no secure/access-levels. NDS,
AD, or OpenLDAP provide a "central" configuration store for HUGE
applications, without exhibiting the problems the 'registry' exhibits.
Even M$ has moved from policies (with had the problem of registry
shadowing) to GPOs which don't. The issue is that
whatever-central-repository MUST support granular access control AND schema
validation - or you end up with goo.
You can have something like GNOME's Gconf which is stable and works well.
Gconf exists to serve just the same purpose as the registry - only it uses
XML. The backends are modular so there isn't any reason that Gconf
couldn't also/instead use something like AD, NDS, or OpenLDAP.
> If your goal is centralized
> configuration management, then lend your
> efforts to webmin, which does an
> excellent job of centrally managing the
> configuration of dozens of applications
> by letting the software know the config
> file format.
Webmin does nothing to help this. It is just a [insecure] method of
twiddling [and possibly wrecking] a bunch of disparate configuration files.
It CERTAINLY doesn't help one manage 100+ machines.
[reply]
[top]
[»]
Re: I think this is a bad idea
by Avi Alkalay - Jul 4th 2004 05:49:07
> You can have something like GNOME's
> Gconf which is stable and works well.
> Gconf exists to serve just the same
> purpose as the registry - only it uses
> XML. The backends are modular so there
> isn't any reason that Gconf couldn't
> also/instead use something like AD, NDS,
> or OpenLDAP.
GConf problem is not exactly his XML backend. Most
critical are:
-It is a daemon, so if it dies you loose your
configurations. LR addresses this.
- It is completelly dependent on high-level Gnome
libs (look
here) which makes it not usable for early boot
stage programs. LR
addresses it.
- GConf was not designed for security (as far as I
know), so you can't manage that some keys or
trees are RO or unaccessible to some users, etc.
GConf is designed (and too much optimized) for
high-level personal desktop configuration store. LR
addresses it.
GConf was investigated before LR project started,
to not reinvent the wheel.
--
[reply]
[top]
[»]
Re: I think this is a bad idea
by SirTalon - Jun 15th 2004 17:29:49
> One of the worst things about Windows
> (as a product, as opposed to Microsoft
> as a company) is the registry system.
> It has nothing to do with
> implementation. The fact that one
> config file controls every piece of
> software on the machine, there is only
> one tool that can read and modify this
> special config file, and that installing
> any program can change it for better or
> worse, are just bad ideas.
>
> What I see happening is what happened
> with the old Red Hat configuration
> program. Something goes wrong, the
> database gets corrupted, and the box is
> useless. Or some app overwrites the
> keys for some other app due to poor
> usage of the API, and then they both
> fail.
>
> Cleartext configuration files are safer,
> you can diff them, you can use version
> control on them, you can hold multiple
> copies and switch them as needed, and
> you can edit them using any one of
> dozens of tools.
>
> If your goal is centralized
> configuration management, then lend your
> efforts to webmin, which does an
> excellent job of centrally managing the
> configuration of dozens of applications
> by letting the software know the config
> file format.
The Registry isn't in one file, but each folder is an
actual folder, and each key is a file. That means it can
use the filesystem's security.
--
[reply]
[top]
[»]
Re: I think this is a bad idea
by David - Jul 27th 2004 09:54:28
> The Registry isn't in one file, but each
> 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 bulky?
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 location.
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.
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.
GPenguin
[reply]
[top]
[»]
Re: I think this is a bad idea
by Jon Mayo - Jul 27th 2004 10:47:18
>
> % The Registry isn't in one file, but
> each
> % 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
> bulky?
>
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
> location.
>
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.
>
> GPenguin
>
>
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.
[reply]
[top]
[»]
Re: I think this is a bad idea
by Avi Alkalay - Jul 4th 2004 05:20:05
> One of the worst things about Windows
> (as a product, as opposed to Microsoft
> as a company) is the registry system.
It has disadvantages [in their implementation] but
also makes the system fully integrated.
> there is only
> one tool that can read and modify this
> special config file, and that installing
> any program can change it for better or
> worse, are just bad ideas.
The tool does not matter. The API is the central
idea, and any program (ANY PROGRAM!)
can use it with Linux Registry, because it doesn't
have dependencies like XML, etc.
> What I see happening is what happened
> with the old Red Hat configuration
> program. Something goes wrong, the
> database gets corrupted, and the box is
> useless. Or some app overwrites the
> keys for some other app due to poor
> usage of the API, and then they both
> fail.
Yes. It is very hard to make GUI tools that reads
and changes human-readable text files. This is
why the corruption happens.
> Cleartext configuration files are safer,
> you can diff them, you can use version
> control on them, you can hold multiple
> copies and switch them as needed, and
> you can edit them using any one of
> dozens of tools.
Current text configuration files are not
programatically manageable. Are only
human-manageable. And [READ THE
SPEC !!] LR
lets you use any text editor (including vi) to edit
keys.
> If your goal is centralized
> configuration management, then lend your
> efforts to webmin, which does an
> excellent job of centrally managing the
> configuration of dozens of applications
> by letting the software know the config
> file format.
Webmin tryies to make a human job: edit
human-readable text configuration files.
Impossible. And it is not very well adopted.
Read the spec before doing this comment.
--
[reply]
[top]
[»]
Fine with the name
by Rev. Adam Tauno Williams - Mar 9th 2004 06:21:00
I'm fine with the name, everybody knows conceptually what the registry
is.
I'd encourage use of existing technologies like XML and/or LDAP over
something new, and I think it would facilitate greater adoption especially
in large networks (where something like this could help take on NDS or AD
and make Linux system somthing resembling "manageable").
But even just this will be better than the mess that is /etc; and people
might be able to make admin tools (like Webmin, etc...) that actually work
reliably and have some semblance of security.
[reply]
[top]
[»]
Inadequate
by Patrick - Jun 1st 2004 19:03:06
I think they are missing the fact that a registry file is a single point of
failure. It would take but one bug in one program to possibly wipe out
information in the entire registry affecting numerous programs. If they
expect to support a wide range of open source software with varying code
quality it becomes a (minimal) possibility. With the multiple files in /etc
approach, you're 99.999% likely not to run into a bug in a program that
destroys every file and directory in /etc.
[reply]
[top]
[»]
Re: Inadequate
by rainer - Jun 14th 2004 02:46:50
> I think they are missing the fact that a
> registry file is a single point of
> failure. It would take but one bug in
> one program to possibly wipe out
> information in the entire registry
> affecting numerous programs.
Reading helps. Really. Look at the overview
at the project homepage, and you will see that there is
no single file and no single point of failure. Keys are
files, and protected by access permissions. And I would
suggest that the author would spell this out in the FM
project description, because it would help to avoid
comments misguided by a project name that certainly
does a good job in attracting attention.
The only problem that I can see is the fact that this
implementation may use up a large number of inodes,
and may also waste a lot of disk space on filesystems
which allocate at least a full block for each file. Not
a problem with reiserfs, but maybe with ext3 (?).
[reply]
[top]
[»]
I really don't like the name
by realz - Mar 6th 2004 20:58:27
I really think we should do something better about it than microsoft
windows registry and that we should use an other name for the new project.
[reply]
[top]
[»]
Re: I really don't like the name
by Avi Alkalay - Mar 7th 2004 02:15:14
> 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.
--
[reply]
[top]
[»]
Re: I really don't like the name
by Michel Di Croci - Aug 30th 2004 13:16:13
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.
>
[reply]
[top]
|
