| |||||||||||||
|
| |||||||||||||
Elektrified X.org releasedElektrified X.org releasedPosted Nov 30, 2004 17:13 UTC (Tue) by evgeny (guest, #774)Parent article: Elektrified X.org released
I'm all for the ideas of this project, EXCEPT the choice of the backend DB. I expressed my views quite a time ago (http://freshmeat.net/projects/elektra/#comment-31642), but that remained largely unanswered.
(Log in to post comments)
Elektrified X.org released Posted Nov 30, 2004 17:52 UTC (Tue) by khim (subscriber, #9252) [Link] What's wrong with fs approach ? Any decent filesystem (i.e.: not ext2/ext3) can handle 1'000'000 files per directory and 10'000 directories with ease and without big space loss. XFS, JFS, Reiser4 - take your pick.
Elektrified X.org released Posted Nov 30, 2004 19:08 UTC (Tue) by elanthis (subscriber, #6227) [Link] Because real-life users *do* use ext2/ext3, and any system that's intended to be an actual part of common Linux systems needs to take that into consideration.
The "your FS sucks, use the experimental/unstable one I prefer" approach doesn't work. Especially not when you can just fix the system to not *need* a "better filesystem." For example, just store multiple keys in one file. Not that difficult at all. Insanely simple, even.
Multiple files also making transactions IMPOSSIBLE (literally) because there is no way to perform an atomic action touching multiple files. Its as simple as that - with multiple files, the entire database is unsafe, because it can get corrupted and out of sync. Real life applications will have multiple keys that need to be in one of several states, such that certain combinations don't make sense. Without transactions and *guaranteed* atomic commits it would be possible for these states to occur in certain circumstances, resulting in broken applications.
Elektra also lacks change notification (so you still need to restart/signal daemons) and several other important features. As is, the *ONLY* thing it offers is a common API. And given the huge number of existing apps and scripts that will break by switching to Elektra, that common API just isn't worth it. Elektra also lacks features that other apps *need* like change notification or schemas, making it unusable.
The entire Elektra design can be improved upon. In fact, there are better designs already in existance. One (sorry, I forget the name - Config4GNU or something like that) uses multiple backends. So, if you set a key in the X.org namespace, it would load a backend that reads and writes the existing X.org configuration file. The advantage here is that already existing and already in-use configuration utilities continue to work while new applications can use the universal API. New applications would just use the default config backend, which would be some database or file heirarchy or whatever. Because of the backends, the system can inject a daemon that, for example, singles key changes over D-BUS allowing applications to be notified when the user changes something. By using a pluggable backend, the launching of this daemon can be delayed until after the initial system bootup, allowing the config system to be used during early-early boot with reduced features, and then become fully operational once enough of the system is up and running.
Elektra is a nice thought experimental, but it is far from the ideal implementation. It might evolve into a complete solution over time, or it might give way to Config4GNU or some other system.
File systems Posted Nov 30, 2004 20:00 UTC (Tue) by tarvin (subscriber, #4412) [Link] It's my impression that both ext2 and ext3 are getting rather good at handling directories with many files.
Elektrified X.org released Posted Nov 30, 2004 20:18 UTC (Tue) by tzafrir (subscriber, #11501) [Link] regarding atomic operations:
you can get nearly-atomic operations by creating a temporary file/directory copy and then mv(1) it to the right place. This does does unlink(2) and rename(2).
Anything more requires a specilized daemon,
Elektrified X.org released Posted Nov 30, 2004 22:33 UTC (Tue) by Ross (subscriber, #4065) [Link] That is atomic. The problem is if you are changing multiple files.
My question is why are you doing that?
But if you insist, you can do atomic operations with multiple files as long
Elektrified X.org released Posted Dec 1, 2004 8:33 UTC (Wed) by Wol (guest, #4433) [Link] And why is changing multiple files any different to changing multiple places in one large file? The database I work with stores each "table" in a separate file, and yet it's quite happy with transactions and commits across multiple files.
And (certainly from the nix viewpoint) isn't the file system seen as just one large file? So, from that vantage point, updating multiple files IS just one change to one large file :-)
Cheers,
Elektrified X.org released Posted Dec 1, 2004 16:27 UTC (Wed) by tzafrir (subscriber, #11501) [Link] This is achived by having all accesses to those files going through a database daemon. That daemon should guarantee that locks/transactions etc. are maintained. It also caches currently-used values.
In the filesystem level the kernel does basically the same things.
Elektrified X.org released Posted Nov 30, 2004 19:10 UTC (Tue) by busterb (subscriber, #560) [Link] To expand on this, the best backend is one that supports tracking revisions and rollbacks. Perhaps a CVS/Subversion backend, since they both can store data in relatively plain files? We already use Subversion for tracking changes to /etc, so this would be a natural extension.
Elektrified X.org released Posted Nov 30, 2004 20:29 UTC (Tue) by tzafrir (subscriber, #11501) [Link] You can easily maintain everything using version control (you'd probably want something that supports renames).
All you need is to make sure that there is always an up-to-date copy of the configuration file in the right place.
Elektrified X.org released Posted Nov 30, 2004 21:12 UTC (Tue) by LogicG8 (guest, #11076) [Link] > the best backend is one that supports tracking revisions and rollbacks.
I really have to disagree. Revision control systems are complicated
$ ldd /usr/bin/svn | wc -l
And that doesn't even count the dependencies of svn's dependencies... I
My reasons for actually liking this system:
1) Ability to hand edit config files. If I'm working over ssh (and I do
2) Independence of data. If you've ever had a chunk of the registry
3) I can easily copy/save specific configuration data. With database
4) I can have comments.
5) This can be combined with MACs (mandatory access controls) or ACLs
6) This one is only speculation on my part but corruption can only happen
7) No new paradigms to learn. I know how get around in a filesystem.
8) Easy program interaction. I'll be thrown out of the *nix geek club for
9) More shared code. One less thing to worry about.
Elektrified X.org released Posted Dec 1, 2004 0:30 UTC (Wed) by emkey (guest, #144) [Link] >"8) Easy program interaction. I'll be thrown out of the *nix geek club forsure for saying this but I *like* GUI configuration programs. I like things to be easy."
As do most of us. The problem being GUI's don't for the most part scale worth a dang. In general GUI's are fine, but they should always be considered secondary to some sort of CLI interface. The problem is many vendors get it backwards, or worse yet don't implament any sort of CLI.
Elektrified X.org released Posted Nov 30, 2004 20:09 UTC (Tue) by evgeny (guest, #774) [Link] Well, ext2/ext3 is a filesystem of choice for a very significant (probably still major) part of Linux users. Further, apache/bind/.... will NEVER officially use anything that's available for Linux only (and other Unices don't necessarily have all that advanced filesystems).
But more importantly, a dumb fs-based config is just that: a dumb one. Whereas a decent configuration system should provide for logical expressions, remote management, replication, versioning, transactions/rollbacks etc. All this is practically impossible with a filesystem-based config tree; and all this is posssible with RDBMS.
Elektrified X.org released Posted Nov 30, 2004 22:45 UTC (Tue) by khim (subscriber, #9252) [Link] But more importantly, a dumb fs-based config is just that: a dumb one. Whereas a decent configuration system should provide for logical expressions, remote management, replication, versioning, transactions/rollbacks etc. All this is practically impossible with a filesystem-based config tree; and all this is posssible with RDBMS. If your filesystem is dumb - it's not possible. If your filesystem is smart - it can be done. True - it should be supplied as addon over simple system but all-in-one solutions are never good.
Elektrified X.org released Posted Dec 1, 2004 10:31 UTC (Wed) by evgeny (guest, #774) [Link] > If your filesystem is dumb - it's not possible. If your filesystem is smart - it can be done.
So we can return to this discussion when every man and his dog have such smart filesystems - including embeded devices etc.
Elektrified X.org released Posted Dec 2, 2004 10:08 UTC (Thu) by szh (guest, #23558) [Link] Don't forget to also return to the fact, that not every man and his dogwant replication, versioning, transactions/rollbacks etc. And many of those who need, can do this with filesystems + there own scripts. Just regular cron /etc [or parts of /etc] [incremental] backups satisfy many men and dogs. So the new system will give drawbacks only for those men and dogs.
Elektrified X.org released Posted Dec 2, 2004 10:28 UTC (Thu) by evgeny (guest, #774) [Link] > Don't forget to also return to the fact, that not every man and his dog> want replication, versioning, transactions/rollbacks etc. > And many of those who need, can do this with filesystems + there own > scripts.
Continuing this nice logics, there is no need for a unified configuration system altogether - just as everyone has been adjusting dozens of different configs during the last twenty years of mainstream Unix usage, so we can do it further on. Right?
Elektrified X.org released Posted Dec 1, 2004 0:45 UTC (Wed) by tzafrir (subscriber, #11501) [Link] remote management etc. is beyond the scope of Elektra. Electra is not aware of the semantics of the configuration. It just provides a simple method of accessing configuration.
Adding remote management, versioning on top of that is proably possible.
The main non-standard feature required for Elektra to work propely is symlinks. And even without it most things will work. Other than that all you need is basic file-system interface.
Elektrified X.org released Posted Dec 1, 2004 10:47 UTC (Wed) by evgeny (guest, #774) [Link] > remote management etc. is beyond the scope of Elektra. [...] It just provides a simple method of accessing configuration.
Exactly. It, essentially, implements the day-before-yesterday functionality (INI configs) yet requires facilities not present in all current filesystems.
> Adding remote management, versioning on top of that is proably possible.
Well, the keywords here are "on top" and "probably". ;-) With the same expected level of success as adding security on top of DOS was. It just strikes me that a project with such an ambitious goal as converting _all_ the Unix configuration mess to a single API didn't bother thinking of even yesterday's requirements to system configuration!
Elektrified X.org released Posted Dec 2, 2004 23:07 UTC (Thu) by tzafrir (subscriber, #11501) [Link] > Exactly. It, essentially, implements the> day-before-yesterday functionality (INI configs)
No, it is not INI config. With INI config you have only thre-level deep tree of configuration (file, section, key). Electra does not have this silly limitation.
> yet requires facilities not present in all current filesystems.
The *required* facilities are avilable everywhere. On some systems it will be less efficient. But even ext3 now has support for a more scalable directory access . Try tune2fs -O dir_index
> Well, the keywords here are "on top" and
Rebuilding everything from scratch has even less expected chance of adding security.
> It just strikes me that a project with such
Into a system that is easy to use by eveything and can be used anywhere.
Elektrified X.org released Posted Dec 3, 2004 19:49 UTC (Fri) by evgeny (guest, #774) [Link] > How can you configure the network using this daemon if the networked daemon needs the network configuration just to get going?
In exactly the same way I can run a LDAP server holding the user DB under a given account. Also, think e.g. of gcc bootstrapping, running of fsck on / before anything is mounted etc. We have a lot of similar chicken-or-egg problems.
Elektrified X.org released Posted Nov 30, 2004 17:58 UTC (Tue) by Ross (subscriber, #4065) [Link] The day I can't edit config files with vi is the day I stop using Linux.If you want your config files in a database go ahead, but I'm certainly not going to stand for it on my systems.
Elektrified X.org released Posted Nov 30, 2004 18:00 UTC (Tue) by jwb (guest, #15467) [Link] An RDBMS is the worst possible backend for this. Primarily, the data is not relational! That should be a dead giveaway. But furthermore you would not be able to store postgresql's configuration in postgresql, for obvious reasons, and even if you could, you're elevating postgresql to the status of required package, like ld, sh, and init. That's not a good idea. And if you study the history of incompatible RDBMS formats, even between minor revisions of the same product, you should be well and truly disuaded from using one for basic configuration information.
Elektrified X.org released Posted Nov 30, 2004 20:32 UTC (Tue) by evgeny (guest, #774) [Link] > Primarily, the data is not relational!
Why? Do you mean it's tree-like? But it's well known how to map 1:1 a tree structure (or graph in general) to relational tables.
> But furthermore you would not be able to store postgresql's configuration in postgresql
Postgresql can use PAM for authentication. On the other hand, there is a pgsql-based PAM plugin. See the point? Like PAM has a plain-files fallback backend, so could the config system have.
> and even if you could, you're elevating postgresql to the status of required package
Again, this is wrong for a plugin-backend-based system. A SOHO config would use e.g. SQLite which needs neither config of its own, nor a daemon running.
Having said this, I don't insist on RDBMS. It could be e.g. an XML DB. The problem though, there is neither reilable implementation nor widely accepted XML query language... My point is that fs-based config is a dead end.
Elektrified X.org released Posted Nov 30, 2004 23:02 UTC (Tue) by khim (subscriber, #9252) [Link] Why? Do you mean it's tree-like? But it's well known how to map 1:1 a tree structure (or graph in general) to relational tables. Possible - yes. Convenient - no. Tree-like information should live in tree and we already have one - filesystem tree. Again, this is wrong for a plugin-backend-based system. A SOHO config would use e.g. SQLite which needs neither config of its own, nor a daemon running. Can I use vi over ssh to edit my config then ? No ? Then it's not contender. Having said this, I don't insist on RDBMS. It could be e.g. an XML DB. The problem though, there is neither reilable implementation nor widely accepted XML query language... And even if there is you are still with the same problem: you do not have access control. My point is that fs-based config is a dead end. I'm struggling to see your point. And can not. With fs tree we are having right from the start two important features: You can add remote management, replication, versioning, transactions/rollbacks if you wish - you only need good enough filesystem. If your argument is translated to simple terms it's this: our silesystems are broken and lack a lot of needed features - but we should not fix them. Instead we should build some compilcated system over raw chunk of disk (== file used by RDBS or XML DB). My question is: why ? Why not fix filesystems instead ? Transactions and replications are nice to have for other things. Simple system upgrade is painfull without them! You can not replace Apache with new version before all mosules are upgraded but if you'll upgrade modules first then old apache can not be used anymore. True - window of oppurtunity is not so big, but it still exist. I fail to see why configuration of my system deserve more reliability then my system itself!
Elektrified X.org released Posted Dec 1, 2004 8:53 UTC (Wed) by Wol (guest, #4433) [Link] "Tree-like information should live in a tree". I couldn't agree more!
And I'm going to get shafted for this by the relational crew, but relational theory is CRUD! Look at C&D's first rule - "data is stored as rows and columns". What real-world data comes as rows and columns? NONE of it as far as I can see. Pretty much all of C&D's rules have as much mathematical basis in fact as Euclid's rule that "parallel lines never meet".
And that rule of Euclid, by being wrong, held back geometry for 2000 years. Real world data does NOT come in neat two-dimensionsal packages. Therefore real world data does NOT belong in relational databases.
That's not to say relational theory doesn't have its uses - it is very useful. But by trying to force everything into its own (faulty) mould, it does the rest of the world a major dis-service.
Cheers,
Elektrified X.org released Posted Dec 1, 2004 11:33 UTC (Wed) by evgeny (guest, #774) [Link] > And that rule of Euclid, by being wrong, held back geometry for 2000 years.
Poor Newton. He could discover the general relativity, if not that stupid greek. Was it an attempt at troll?
> Real world data does NOT come in neat two-dimensionsal packages. Therefore real world data does NOT belong in relational databases.
Do some text-book reading before posting, please.
Elektrified X.org released Posted Dec 1, 2004 11:18 UTC (Wed) by evgeny (guest, #774) [Link] > Tree-like information should live in tree and we already have one - filesystem tree.
Configurations are NOT trees. They're graphs (the symlinks used by Electra is a poor-man solution to this). Plus, they're _dynamic_ ones.
> Can I use vi over ssh to edit my config then ? No ? Then it's not contender.
Gosh. Why not `ed' then? There is a userfs plugin that allows to navigate/edit a postgres DB like a directory, if you insist on that. I also assume that you code exclusively in assembler and use `telnet 80 lwn.net' to read my reply.
> And even if there is you are still with the same problem: you do not have access control.
RDBMS have no access control?!
> You can add remote management, replication, versioning, transactions/rollbacks if you wish - you only need good enough filesystem.
U-hu. Just a tiny obstacle.
> Why not fix filesystems instead ?
Well, go fix them. IMHO, filesystem developers have more urgent tasks than tailoring their filesystems to an ambitios configuration project. So we can wait years and years - and still have a dumb (no logical expressions etc) configuration mechanism.
|
|
||||||||||||