4 ms·
And how would you handle concurrent updates and transactions? The registry is a database. There is a reason we use Postgres instead of flat files, and it is no
by orf 8y ago
And how would you handle concurrent updates and transactions?
The registry is a database. There is a reason we use Postgres instead of flat files, and it is not people overdesigning things for review time.
And again, if you think the registry maps 1-1 to the file system you don't understand it. And that's fine. Just don't hate it because of that.
- AnIdiotOnTheNet 8y agoFilesystems can support transactions. In fact, NTFS does [0] already. [0] https://en.wikipedia.org/wiki/Transactional_NTFS https://en.wikipedia.org/wiki/Transactional_NTFS
- orf 8y agoSo now every program that interacts with the registry in that way needs to implement transactional IO operations correctly and sanely, and if they don't bad things will happen? A thing that is so complex Microsoft is considering deprecating it due to that alone? You also didn't mention concurrent access, or think about random code writing random completely invalid data into files, or consider how you would evolve the on disk format. That sounds awful burdensome for a simple key-value api. Perhaps you could use some kind of service to shield clients from that complexity, and so you don't have one dumb program messing the entire registry up for everyone else. That would be cool. You could call it the registry service.
- AnIdiotOnTheNet 8y agoOr you could just put those rules into the filesystem itself. After all, what is a filesystem if not a hierarchical database?
- jodrellblank 8y agoOpen your PowerShell and `cd HKCU:` and walk the registry. After all, what is a filesystem if not a path to some data, papering over a complex subsystem?
- orf 8y agoSo let's bloat the file system specifics for no real reason, other than you think it's cleaner like this? It's not. Concurrent writes and type validation are way out of the picture here if you do that.
- MisterTea 8y ago> concurrent updates and transactions? From Wikipedia: "The Windows Registry is a hierarchical database that stores low-level settings for the Microsoft Windows operating system and for applications that opt to use the registry." Are we still talking about a configuration archive or a production database for an application? That's when you have to start asking yourself: "is this a sane way to do things?" Because the more you argue for it, the less attractive it becomes as a solution for something that stores configuration data.
- orf 8y agoWe're talking about the configuration registry. The one that may require multiple configuration options to be changed in a transactional manner. The one that may have multiple threads or processes reading and writing to the keys (because who knows what stupid devs will do). The one that's a bit more advanced and granular than a config file in /etc/ because it needs to be. Oh yeah, that reminds me, you'd also need to handle subscribing to registry update notifications in this flat-file 'who needs anything other than text files' fantasy. Again, just because you don't grok the problem space doesn't mean its empty.
- yjftsjthsd-h 8y ago> Oh yeah, that reminds me, you'd also need to handle subscribing to registry update notifications in this flat-file 'who needs anything other than text files' fantasy. > Again, just because you don't grok the problem space doesn't mean its empty. Case in point: inotify.
- SSLy 8y agoisn't and isn't going to become recursive over the path
- orf 8y agohas numerous problems as an API and is fiddly and requires every app that wants to listen to do this correctly. Look. Yes you can hack together the registry using flat files, using FS notifications, using the insane transactional FS apis, magically working out how to handle concurrent writes etc and have every process that wants to interact with it implement this correctly. But why. In every sense it is less clean, more complex and generally worse. Wasn't the idea to make it better and cleaner?