| |||||||||||||
|
| |||||||||||||
Elektrified X.org releasedElektrified X.org releasedPosted Nov 30, 2004 16:45 UTC (Tue) by marduk (subscriber, #3831)Parent article: Elektrified X.org released
This all looks interesting, but how is it really different from gconf. The description says it's different in that it's used at a system-wide level, but can't gconf be used for system-wide configurations as well?
(Log in to post comments)
Elektrified X.org released Posted Nov 30, 2004 16:56 UTC (Tue) by evgeny (guest, #774) [Link] > can't gconf be used for system-wide configurations as well?
Only if Gnome is run from /etc/inittab ;-)
Elektrified X.org released Posted Nov 30, 2004 17:17 UTC (Tue) by philips (guest, #937) [Link] Good point.
I wouldn't claim that X config is easy. But I beleive that it is much easier to parse by human beings, than what is proposed.
Anyway, it still comes down to question "what to put where".
Apache Config editors are available in abundance - why the same approach can be taken for X?
And what is more. I'm strictly opposed to "system-wide" stuff. One thing is death of Gnome due to damaged config. Another thing is "system-wide" death of system due to damaged config. Different apps have different configs and different priorities for configs. For example, you do not want to mess with /etc/inittab - and you definitely do not want users to be able to manipulate it easily. One size never fits all.
Elektrified X.org released Posted Nov 30, 2004 18:51 UTC (Tue) by emkey (guest, #144) [Link] I remember when Windows went from hundreds of poorly documented .ini files to one even more poorly documented registry tree. I didn't view it as progress then and my first instinct is to not view this effort as progress either.
Change in heart for M$ Posted Nov 30, 2004 19:44 UTC (Tue) by jimwelch (guest, #178) [Link] I just took an "official" class in Windows CE (groan) and M$ is now pushing people to go BACK to ini files and away from the registry (security reasons)!!
Elektrified X.org released Posted Nov 30, 2004 20:11 UTC (Tue) by tzafrir (subscriber, #11501) [Link] That's the point of using a filesystem-based database[*]. The file system is solid and won't be easily corrupted. If a process starts trashing it won't easily corrupt the database (filesystem) itself. That is much unlike XML, where one missing '>' could get rid of a whole subtree.
Elektra also does not need its own daemon. The kernel already does the job.
[*] Think of Hans Reiser's ideas.
Elektrified X.org released Posted Nov 30, 2004 20:47 UTC (Tue) by evgeny (guest, #774) [Link] > The file system is solid and won't be easily corrupted. If a process starts> trashing it won't easily corrupt the database (filesystem) itself. That is > much unlike XML, where one missing '>' could get rid of a whole subtree.
A single corrupted byte in the filesystem block layer could be as dangerous. It's the fsck maturity that eliminates these problems in almost 100% of cases. Similarly, a smart XML parser can be built that can recover from such errors.
> Think of Hans Reiser's ideas.
Yeah, if reisrfs-4 (or -5?) existed years ago AND under all Unices, that could make a difference.
Elektrified X.org released Posted Nov 30, 2004 22:42 UTC (Tue) by tzafrir (subscriber, #11501) [Link] The filesystem is stable. It has to be. Otherwise your configuration gets corrupted whatever you do.
However why replicate so many features that the file system already give you in a database? Or in 2500 implementations of 50 different configuration formats.
Elektrified X.org released Posted Dec 1, 2004 10:03 UTC (Wed) by evgeny (guest, #774) [Link] > The filesystem is stable. It has to be.
I see no reason why a DB should inherently be less stable.
> However why replicate so many features that the file system already give you in a database?
Because FS will never provide me with all the advanced features one expects from a decent configuration system - not without stacking dozens of extra daemons/utilities/... on top of it, at least.
> Or in 2500 implementations of 50 different configuration formats.
Of course. I said it in the beginning, that I like the _idea_ itself - to replace the whole current zoo of config approaches with a single API. It's the _implementation_ that seems to me a dead end.
Elektrified X.org released Posted Dec 1, 2004 16:23 UTC (Wed) by tzafrir (subscriber, #11501) [Link] How do you create different permissions on different part of the database without a priviliged daemon (or something uglier, such as a SUID root binary) ?
This is an important requirement: user applications need not run as root to read configuration. But there should be a place for the secret data.
But please name one thing a database provides that a filesystem doesn't. What database exactly (daemon? file-based? which one?)
Elektrified X.org released Posted Dec 1, 2004 21:37 UTC (Wed) by evgeny (guest, #774) [Link] > How do you create different permissions on different part of the database> without a priviliged daemon (or something uglier, such as a SUID root binary) ?
Depends on the implementation. For a DB _service_ (a daemon running) it's solved like for any other similar problem (and there is no need for it to run under a privileged account - e.g. slapd on my server runs as an unprivileged user 'ldap', yet system-wide authentication works fine). For a simple file-based DB like SQLite it can be solved by splitting the whole data into a few files (1 - writable by root, readable by everyone; 2 - r/w by root ony, plus, similarly, two files per user account).
> But please name one thing a database provides that a filesystem doesn't.
Expressions (aka views). E.g. SELECT * FROM user WHERE user.id > 400 - to have a list of "real" users - used, for example, to send an announce email. Etc. Other things are replication, atomicity, true locking, notifications, rollbacks, versioning, transparent remote access, scalability (in _both_ directions). You get all these for free with a decent RDBMS, and NONE of them with an existing filesystem.
Elektrified X.org released Posted Dec 2, 2004 22:55 UTC (Thu) by tzafrir (subscriber, #11501) [Link] > > But please name one thing a database provides that a> > filesystem doesn't. > > Expressions (aka views). E.g. SELECT * FROM user WHERE > user.id > 400 - to have a list of "real" users - used, > for example, to send an announce email. Etc.
OTOH, the strict typing of the data will get back at you when you try something like:
grep -rl /home/joe /etc/
> Other things are replication,
Try rsync
> atomicity, true locking,
What about filesystem-level locking?
> notifications,
Change notification for a directory is available.
> rollbacks, versioning,
Put arch/subversion in there (cvs probably won't do as it does not support renames)
> transparent remote access,
Add a remote-access daemon. Quite simple to implement. You have to figure out the authentication method first. Currently practically no existing daemon intgrates well enough with the system.
> scalability (in _both_ directions).
Filesystem access is quite scalable
Elektrified X.org released Posted Dec 3, 2004 19:42 UTC (Fri) by evgeny (guest, #774) [Link] > OTOH, the strict typing of the data will get back at you when you try something like:> > grep -rl /home/joe /etc/
Sorry, I didn't get what you meant.
> Try rsync [etc etc etc]
I don't want. For the same reason that nobody in sane mind will pipe 'telnet 80 | html2txt | less' to browse the Web. Possible - yes. Great when nothing else is available - yes. But call this THE ultimate browser?!
Elektrified X.org released Posted Nov 30, 2004 22:58 UTC (Tue) by iabervon (subscriber, #722) [Link] I'd actually claim that X.org configuration is easy. X.org is fine without a config file, unless your monitor is old, in which case you have to include info on your monitor's capabilities. If you want to use a few different resolutions, you have to tell it which ones you want. Other than that, there's not much that needs to be specified, at least in my limited experience.
|
|
||||||||||||