3 ms·

So what's wrong with the registry if a file-based registry is okay? The registry could be an abstraction layer over a Unix /etc filesystem, after all.

JackSlateur 2y ago
"rm -rf /etc/nginx" versus "try to remember where are the miriads of random keys spread everywhere"
- alt227 2y ago
  Then it seems like the issue you have is how vendors are storing keys in the registry, not the registry itself. In your example, if nginx made a single node in the registry with all its keys under that then it would be just as easy to remove that single node as it would be to remove the single directory. However in the real world it is never as simple as you suggest. Linux apps often litter the filesystem with data. an app might have files in /etc and /opt with shortcut scripts in /root/bin and /usr/sbin. Config files in /home and /usr directories. Linux file systems are just as littered as windows registries in my experience, if not worse because they differ in different distros.
nmz 2y ago
Labeling, fstab is supposed to be a .tsv, what happens if I mistype something? where's the safety? Does this need to be a DSL?
ruthmarx 2y ago
I have no issue with the concept, but in practice the Windows registry is a lot more obfuscated than it needs to be. There can be trees and trees of UUIDs or similar, and there is no need for it to be so user unfriendly. Part of this might be mixing internal stuff that people never need to see with stuff that people will need to access.
- nullindividual 2y ago
  That's a developer choice, not the registry in and of itself. You could just as easily have /etc filled files with GUIDs for file names. Generally, 3rd party developers don't use a bunch of GUIDs for keys. Microsoft does for Windows components to map the internal object ID of whatever they're dealing with; my assumption is for ease of recognition/documentation on their side (and generally the assumption that the end user shouldn't be playing around in there).
  - ruthmarx 2y ago
    > That's a developer choice, not the registry in and of itself. You could just as easily have /etc filled files with GUIDs for file names. For sure, that's why I said I have no issue with the concept but rather how it's used in practice. > Microsoft does for Windows components to map the internal object ID of whatever they're dealing with; my assumption is for ease of recognition/documentation on their side (and generally the assumption that the end user shouldn't be playing around in there). That's maybe fair, but most of that stuff isn't stuff the user even needs to access most of the time. Maybe separating it out from all the HKLM and HKCU software trees would have made sense.
    - nullindividual 2y ago
      HKLM and HKCU have specific ACLs. It wouldn't make sense to have _two_ user-modifiable registry hives and ditto for machine.
      - ruthmarx 2y ago
        I don't really understand your point here. It would make perfect sense to have two separate hives by sectioning off all the stuff users, even power users actually need access to. 'specific ACLs' have no bearing on that.
        nullindividual 2y ago
        That already exists! It's the HKCU.

JackSlateur 2y ago

"rm -rf /etc/nginx" versus "try to remember where are the miriads of random keys spread everywhere"

alt227 2y ago
Then it seems like the issue you have is how vendors are storing keys in the registry, not the registry itself. In your example, if nginx made a single node in the registry with all its keys under that then it would be just as easy to remove that single node as it would be to remove the single directory. However in the real world it is never as simple as you suggest. Linux apps often litter the filesystem with data. an app might have files in /etc and /opt with shortcut scripts in /root/bin and /usr/sbin. Config files in /home and /usr directories. Linux file systems are just as littered as windows registries in my experience, if not worse because they differ in different distros.

nmz 2y ago

Labeling, fstab is supposed to be a .tsv, what happens if I mistype something? where's the safety? Does this need to be a DSL?

ruthmarx 2y ago

I have no issue with the concept, but in practice the Windows registry is a lot more obfuscated than it needs to be. There can be trees and trees of UUIDs or similar, and there is no need for it to be so user unfriendly. Part of this might be mixing internal stuff that people never need to see with stuff that people will need to access.

nullindividual 2y ago
That's a developer choice, not the registry in and of itself. You could just as easily have /etc filled files with GUIDs for file names. Generally, 3rd party developers don't use a bunch of GUIDs for keys. Microsoft does for Windows components to map the internal object ID of whatever they're dealing with; my assumption is for ease of recognition/documentation on their side (and generally the assumption that the end user shouldn't be playing around in there).
- ruthmarx 2y ago
  > That's a developer choice, not the registry in and of itself. You could just as easily have /etc filled files with GUIDs for file names. For sure, that's why I said I have no issue with the concept but rather how it's used in practice. > Microsoft does for Windows components to map the internal object ID of whatever they're dealing with; my assumption is for ease of recognition/documentation on their side (and generally the assumption that the end user shouldn't be playing around in there). That's maybe fair, but most of that stuff isn't stuff the user even needs to access most of the time. Maybe separating it out from all the HKLM and HKCU software trees would have made sense.
  - nullindividual 2y ago
    HKLM and HKCU have specific ACLs. It wouldn't make sense to have _two_ user-modifiable registry hives and ditto for machine.
    - ruthmarx 2y ago
      I don't really understand your point here. It would make perfect sense to have two separate hives by sectioning off all the stuff users, even power users actually need access to. 'specific ACLs' have no bearing on that.
      - nullindividual 2y ago
        That already exists! It's the HKCU.