4 ms·

How about a file system? Because that is precisely what the registry is, a file system in a file. The keys are just paths to a variable which can be a text or b

How about a file system? Because that is precisely what the registry is, a file system in a file. The keys are just paths to a variable which can be a text or binary file. And people who suggest SQL or another monstrous abstractions as an implementation need to take a step back and apply the idea of philosophical simplicity to their work. I honestly don't understand why people have this tendency to over engineer simple problems. I suppose it helps during review time.

orf 8y ago
It has a few more types than that[1]. While the registry is not exactly super elegant and suffers from issues I think it's a pretty simplistic answer to a complex problem, especially one rooted in history and rife with backwards compatibility concerns (windows still supports the legacy format used only in Windows 2000!). People who sit back and say "replace it with text files/sqlite" don't really understand it or the problem it solves that well. Using the actual file system brings in file system concerns - how do you handle registry transactions or concurrent updates? 1. https://msdn.microsoft.com/en-us/library/windows/desktop/bb773476(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/bb7...
- AnIdiotOnTheNet 8y ago
  It doesn't really matter how many types it has, just give each file an extension indicating the type, like filesystems already do.
  - 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 ago
      Filesystems 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 ago
        So 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 ago
        Or you could just put those rules into the filesystem itself. After all, what is a filesystem if not a hierarchical database?
        jodrellblank 8y ago
        Open 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 ago
        So 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
- grumpydba 8y ago
  Well text files work perfectly fine for unix/linux. And the installation process is infinitely less painful.
  - orf 8y ago
    I think that's a fallacy. Just because it works somewhere (and not great, as every bit of software has its own damn arbitrary format only it can parse) doesn't mean it works here. It is conceptually a bit simpler, however that doesn't mean it is better.
    - grumpydba 8y ago
      after all I've only been administering linux/unix/windows boxes for 15 years so how would I know! Installing by untaring a package, versioning the config files, adding comments... I'd rather have a bespoke format than deeply nested keys in various locations (HKCU/HKLM/HKROOT and all that mess). Having to find leftover keys, or to use pmon to find which ones are accessed is such a horrible experience.
      - orf 8y ago
        I'm not sure why you are uninstalling software so often, nor why you are so anal about cleaning the entire registry. But hey, it's a one click thing to deploy a registry change to a fleet of 10,000 AD boxes, one that can change the configuration of the 1Password app as well as MS Word, and have it done reliably. That's why it's better.
        grumpydba 8y ago
        Because some leftover keys broke software installs maybe ? Happened to me countless times.
        orf 8y ago
        Has never happened to me since perhaps the XP days. Why are you uninstalling software so often through AD? Not that it absolves this issue, but it's not common to have huge software churn like this. And hey, isolate the issue and push a registry change to every single machine in the network, instantly and consistently.
marcosdumay 8y ago
I'd prefer going into the direction where it would be preferable to replace most of our filesystems with databases. I imagine that, if we didn't have to serialize stuff all the time to send over the network we would already be there ages ago.

orf 8y ago

It has a few more types than that[1]. While the registry is not exactly super elegant and suffers from issues I think it's a pretty simplistic answer to a complex problem, especially one rooted in history and rife with backwards compatibility concerns (windows still supports the legacy format used only in Windows 2000!). People who sit back and say "replace it with text files/sqlite" don't really understand it or the problem it solves that well. Using the actual file system brings in file system concerns - how do you handle registry transactions or concurrent updates? 1. https://msdn.microsoft.com/en-us/library/windows/desktop/bb773476(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/bb7...

AnIdiotOnTheNet 8y ago
It doesn't really matter how many types it has, just give each file an extension indicating the type, like filesystems already do.
- 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 ago
    Filesystems 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 ago
      So 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 ago
        Or you could just put those rules into the filesystem itself. After all, what is a filesystem if not a hierarchical database?
        jodrellblank 8y ago
        Open 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 ago
        So 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
grumpydba 8y ago
Well text files work perfectly fine for unix/linux. And the installation process is infinitely less painful.
- orf 8y ago
  I think that's a fallacy. Just because it works somewhere (and not great, as every bit of software has its own damn arbitrary format only it can parse) doesn't mean it works here. It is conceptually a bit simpler, however that doesn't mean it is better.
  - grumpydba 8y ago
    after all I've only been administering linux/unix/windows boxes for 15 years so how would I know! Installing by untaring a package, versioning the config files, adding comments... I'd rather have a bespoke format than deeply nested keys in various locations (HKCU/HKLM/HKROOT and all that mess). Having to find leftover keys, or to use pmon to find which ones are accessed is such a horrible experience.
    - orf 8y ago
      I'm not sure why you are uninstalling software so often, nor why you are so anal about cleaning the entire registry. But hey, it's a one click thing to deploy a registry change to a fleet of 10,000 AD boxes, one that can change the configuration of the 1Password app as well as MS Word, and have it done reliably. That's why it's better.
      - grumpydba 8y ago
        Because some leftover keys broke software installs maybe ? Happened to me countless times.
        orf 8y ago
        Has never happened to me since perhaps the XP days. Why are you uninstalling software so often through AD? Not that it absolves this issue, but it's not common to have huge software churn like this. And hey, isolate the issue and push a registry change to every single machine in the network, instantly and consistently.

marcosdumay 8y ago

I'd prefer going into the direction where it would be preferable to replace most of our filesystems with databases. I imagine that, if we didn't have to serialize stuff all the time to send over the network we would already be there ages ago.