| |||||||||||||
|
| |||||||||||||
Elektrified X.org releasedElektrified X.org releasedPosted Nov 30, 2004 18:00 UTC (Tue) by jwb (guest, #15467)In reply to: Elektrified X.org released by evgeny Parent article: Elektrified X.org released
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.
(Log in to post comments)
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.
|
|
||||||||||||