3 ms·

Nor is there any consistency with the windows registry. Except that, by being such a pain in the posterior, noone edits it manually anymore and all changes are

Nor is there any consistency with the windows registry. Except that, by being such a pain in the posterior, noone edits it manually anymore and all changes are done through GUI apps. Editing config files is easier and faster (not to mention, automatable), so people don't bother creating "control panels" on Linux for the most part. > What would be interesting is a complete re-imagining of a server OS Not sure how 'complete', but aren't you after something like NixOS?

skissane 7y ago
> Nor is there any consistency with the windows registry. The Windows registry is a bad implementation of a good concept. Imagine if the registry had a schema with embedded documentation, foreign key relationships, a packages database with each key owned by a package, etc...
- starik36 7y ago
  > Imagine if the registry had a schema with embedded documentation, foreign key relationships So a database then?
  - skissane 7y ago
    Well, if you think about it, the Windows registry already is a hierarchical database – just a quite limited one. You could have a hierarchical database with richer features (LDAP is a good example of that, although in some ways LDAP is rather clunky). If by database you mean "relational database" – I'm not sure the relational model is the best fit for a config store. I think a more hierarchical database model is more natural for that purpose. (Of course, you could use a relational database as an underlying implementation detail – LDAP is fundamentally a hierarchical database, but there exist LDAP servers which store the data in an RDBMS, for example Oracle Internet Directory.)
- freefriedrice 7y ago
  I've wrestled with this for DECADES! I've built software with a configuration database (Windows registry) and with flat configuration file-folders (*nix). I feel like I'm running in a circle because the trade-offs are so equally balanced that there's no best-case. From considering backups and database consistency, to tripwire malware detection of changed settings, to automation of access, to consistency in naming, retrieval, and type conventions, to self-documentation, to backwards compatibility... At this point I'm not even sure I would understand the correct or "best" methodology if it was handed to me on a silver platter.
pjmlp 7y ago
Well gconf is hardly any better.

skissane 7y ago

> Nor is there any consistency with the windows registry. The Windows registry is a bad implementation of a good concept. Imagine if the registry had a schema with embedded documentation, foreign key relationships, a packages database with each key owned by a package, etc...

starik36 7y ago
> Imagine if the registry had a schema with embedded documentation, foreign key relationships So a database then?
- skissane 7y ago
  Well, if you think about it, the Windows registry already is a hierarchical database – just a quite limited one. You could have a hierarchical database with richer features (LDAP is a good example of that, although in some ways LDAP is rather clunky). If by database you mean "relational database" – I'm not sure the relational model is the best fit for a config store. I think a more hierarchical database model is more natural for that purpose. (Of course, you could use a relational database as an underlying implementation detail – LDAP is fundamentally a hierarchical database, but there exist LDAP servers which store the data in an RDBMS, for example Oracle Internet Directory.)
freefriedrice 7y ago
I've wrestled with this for DECADES! I've built software with a configuration database (Windows registry) and with flat configuration file-folders (*nix). I feel like I'm running in a circle because the trade-offs are so equally balanced that there's no best-case. From considering backups and database consistency, to tripwire malware detection of changed settings, to automation of access, to consistency in naming, retrieval, and type conventions, to self-documentation, to backwards compatibility... At this point I'm not even sure I would understand the correct or "best" methodology if it was handed to me on a silver platter.

pjmlp 7y ago

Well gconf is hardly any better.