| |||||||||||||
|
| |||||||||||||
Elektrified X.org releasedElektrified X.org releasedPosted Nov 30, 2004 20:11 UTC (Tue) by tzafrir (subscriber, #11501)In reply to: Elektrified X.org released by philips Parent article: Elektrified X.org released
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.
(Log in to post comments)
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?!
|
|
||||||||||||