8 ms·

> If you think about it, the /etc tree is just a hierarchical key-value store Well, you're in luck, I have good news for you -- Windows also has its own versio

by aseipp 2y ago

> If you think about it, the /etc tree is just a hierarchical key-value store Well, you're in luck, I have good news for you -- Windows also has its own version of this concept: it's called "The Registry". You might have heard of it?

magicalhippo 2y ago
And since it supports variable-lenght binary values, it fully supports that "the persistent format of the leaf node is left to its implementer to decide".
- rbanffy 2y ago
  Except that now it’s an opaque blob and not a text file I can use grep to find and vi to edit.
rkagerer 2y ago
The registry would have been better if there were a stronger concept of "ownership" of the data it contains, tying each key to the responsible app / subsystem. I've tracked hundreds of software uninstalls and I would bet only about 1% of them actually remove all the cruft they originally stick in (or populated during use). The result is bloat, a larger surface area for corruption, and system slowdown. Ironically in this respect it was a step backward... When settings lived in INI files, convention typically kept them in the same place as the program, so they were easy to find and were naturally extinguished when you deleted the software. If you look at more modern OS's like Android and iOS they tend to enforce more explicit ties between apps and their data.
- alt227 2y ago
  > system slowdown This is often touted as a downside for the registry, and indeed a whole ecosystem of apps have evolved around this concept to 'clean' the registry and 'speed it up'. In my experience of 35 years of using windows, I have never noticed a bloated registry slowing down a computer. I have also never noticed a speed up of the system by removing some unused keys. The whole point of addresses and key pairs is that individual bits of data can be written or read without loading the whole hive. I wonder where this idea of a bloated slow registry came from?
  - rbanffy 2y ago
    Since the registry is a database, I would expect adding and removing branches and leaves would create fragmentation that, in the age of spinning metal and memory pressure, could create performance issues. A file system is easily defragmenters with tools available in the operating system itself, but not the registry. I’m not even sure how much of it can be optimised (by doing garbage collection and defragmenting the underlying files) with the computer running. If it makes use of indexes, changes will lead to the indexes themselves being fragmented, making performance even worse.
    - nullindividual 2y ago
      The registry was capable of being compacted, negating the need to defragment it. This was done via the standard Windows Backup utility provided OOTB. As for performance, the registry was mapped in paged pool memory[0]; only sections in-use needed to be mapped. Other hives were volatile and never persisted to disk. When data is added to the registry, the paged pool expands to accommodate. Maximum registry size is based off of installed memory, up to a limit. Registry subkeys are organized alphabetically in an internal list; searches are binary searches rather than using an index. Searches begin in the middle of the list and go up or down based upon the alphabetical value being searched for (so start at 50% -> up/down, split remaining list 50%, up/down -> repeat until found). You can find more info in Chapter 4 of Windows Internals 4th Edition. Needless to say, none of the concerns you presented were valid back in the dark days. [0] https://learn.microsoft.com/en-us/windows/win32/sysinfo/registry-storage-space https://learn.microsoft.com/en-us/windows/win32/sysinfo/regi...
  - rkagerer 2y ago
    Anecdotally I've experienced several PC's that became slow/unstable/unusable after a number of years. I can't scientifically prove it was due to the registry (other than a couple that had specific corruption). But after I started using Total Uninstall religiously, from day 1 of a PC's life, my desktops have lasted indefinitely - going on 15 years for the latest one (yes, really). Hardware was of course upgraded along the way, making old driver removal paramount (which TU is very helpful with). Analyzing it's logs after a software installation has also been helpful to spot and surgically remove unwanted keys like autostarts, Explorer addins, etc.
- ruthmarx 2y ago
  > only about 1% of them actually remove all the cruft they originally stick in (or populated during use). The result is bloat, a larger surface area for corruption, and system slowdown. I think this is a myth partly spread by commercial offerings that want to 'clean and optimize' a windows install. Most of the cruft left in the registry is the equivalent of config files in /etc not removed after uninstalling an app. That stuff isn't affecting performance.
  - vkazanov 2y ago
    15 something years ago I had this unpleasant job where I had to install a major vendor's database on Windows server machines. I remember I also had a lengthy list of things to check and clean in the registry to make sure things work. Yes, these are configs. And no, we cannot just let applications do whatever they want in the shared config space without a way to trace things back to the original app. At least in the Linux world I was able to just check what the distro scripts installed.
    - ruthmarx 2y ago
      > And no, we cannot just let applications do whatever they want in the shared config space without a way to trace things back to the original app. We don't have to let them, but we do for the most part. We could use sandboxing technology to isolate and/or log, but mostly OSs don't do anything to restrict what an executable can do by default, at least as far as installing. > At least in the Linux world I was able to just check what the distro scripts installed. You can do this in Windows too sometimes, but it doesn't matter if it's a badly behaving app. There are linux installers that are just binary blobs and it would be a lot more work to monitor what they do also.
      - whoknowsidont 2y ago
        >but mostly OSs don't do anything to restrict what an executable can do by default, at least as far as installing. There is a very mature and very powerful system for this called Jails. >There are linux installers that are just binary blobs and it would be a lot more work to monitor what they do also. This is simply not true. If I want to monitor an app in it's entirety I can easily do so on most unixy systems. Past the default tools that require some amount of systems knowledge to use correctly, you can easily just use Stow or Checkinstall (works on most linux systems). There is no mechanism for doing this on Windows as even the OS loses track of it sometimes. And if you think I'm being dramatic, trust me, I am not. There is a reason the tools don't exist for Windows, at least meeting feature parity.
- nullindividual 2y ago
  This is the responsibility of the installer. Using Windows Installer, this is easily accomplished. The Msi database _does_ track individual files and registry entries. If you're using another installer, or the developer allows their app to write something somewhere that isn't tracked by their installer, you're going to get files left behind. macOS is especially bad in this respect. Bundles are great, until you have a ~/Library full of files that you never knew about after running an application.
  - rbanffy 2y ago
    > This is the responsibility of the installer On any Unix I can grep my way into the /etc tree and find files belonging to uninstalled applications and get rid of them myself. The whole point is that I can manage the “configuration database” with the same tools I manage a filesystem. That if the brilliant tools like apt and dnf fail to clean up after a program is uninstalled.
    - nullindividual 2y ago
      Windows is no different. Next time you're in front of Terminal, try: cd HKCU:\SOFTWARE You're now browsing the registry and can use terminal commands.
      - rbanffy 2y ago
        When was this introduced? This is surprisingly enlightened. Can I edit keys with a text editor?
        amaccuish 2y ago
        Thank you for your reasoned response. I still like the idea that I think you originally had, whereby apps could only write to their own specific area, thus containing all their configuration. I think that would solve 99% of all complaints about the registry. Right now, they can write to anywhere your user has access to.
rbanffy 2y ago
What exactly do I gain from the registry that compensates for the fact I can use any tool that works on files to manage the /etc tree? Can you manage registry folders with Git and keep track of the changes you make? Can you grep for content? On a Mac it’s indexed by the systemwide text search tooling. Using the file system to store that data is extremely powerful.
- craigmoliver 2y ago
  You can create/export .reg files to your GIT repo/file system...but that may be one extra step and doesn't stay in sync automatically.
  - rbanffy 2y ago
    Another idea would be to do periodic snapshots of the /etc folder. That, sadly, excludes ext4, but any flavour of Solaris can easily do it.

by aseipp 2y ago

magicalhippo 2y ago

And since it supports variable-lenght binary values, it fully supports that "the persistent format of the leaf node is left to its implementer to decide".

rbanffy 2y ago
Except that now it’s an opaque blob and not a text file I can use grep to find and vi to edit.

rkagerer 2y ago

The registry would have been better if there were a stronger concept of "ownership" of the data it contains, tying each key to the responsible app / subsystem. I've tracked hundreds of software uninstalls and I would bet only about 1% of them actually remove all the cruft they originally stick in (or populated during use). The result is bloat, a larger surface area for corruption, and system slowdown. Ironically in this respect it was a step backward... When settings lived in INI files, convention typically kept them in the same place as the program, so they were easy to find and were naturally extinguished when you deleted the software. If you look at more modern OS's like Android and iOS they tend to enforce more explicit ties between apps and their data.

alt227 2y ago
> system slowdown This is often touted as a downside for the registry, and indeed a whole ecosystem of apps have evolved around this concept to 'clean' the registry and 'speed it up'. In my experience of 35 years of using windows, I have never noticed a bloated registry slowing down a computer. I have also never noticed a speed up of the system by removing some unused keys. The whole point of addresses and key pairs is that individual bits of data can be written or read without loading the whole hive. I wonder where this idea of a bloated slow registry came from?
- rbanffy 2y ago
  Since the registry is a database, I would expect adding and removing branches and leaves would create fragmentation that, in the age of spinning metal and memory pressure, could create performance issues. A file system is easily defragmenters with tools available in the operating system itself, but not the registry. I’m not even sure how much of it can be optimised (by doing garbage collection and defragmenting the underlying files) with the computer running. If it makes use of indexes, changes will lead to the indexes themselves being fragmented, making performance even worse.
  - nullindividual 2y ago
    The registry was capable of being compacted, negating the need to defragment it. This was done via the standard Windows Backup utility provided OOTB. As for performance, the registry was mapped in paged pool memory[0]; only sections in-use needed to be mapped. Other hives were volatile and never persisted to disk. When data is added to the registry, the paged pool expands to accommodate. Maximum registry size is based off of installed memory, up to a limit. Registry subkeys are organized alphabetically in an internal list; searches are binary searches rather than using an index. Searches begin in the middle of the list and go up or down based upon the alphabetical value being searched for (so start at 50% -> up/down, split remaining list 50%, up/down -> repeat until found). You can find more info in Chapter 4 of Windows Internals 4th Edition. Needless to say, none of the concerns you presented were valid back in the dark days. [0] https://learn.microsoft.com/en-us/windows/win32/sysinfo/registry-storage-space https://learn.microsoft.com/en-us/windows/win32/sysinfo/regi...
- rkagerer 2y ago
  Anecdotally I've experienced several PC's that became slow/unstable/unusable after a number of years. I can't scientifically prove it was due to the registry (other than a couple that had specific corruption). But after I started using Total Uninstall religiously, from day 1 of a PC's life, my desktops have lasted indefinitely - going on 15 years for the latest one (yes, really). Hardware was of course upgraded along the way, making old driver removal paramount (which TU is very helpful with). Analyzing it's logs after a software installation has also been helpful to spot and surgically remove unwanted keys like autostarts, Explorer addins, etc.
ruthmarx 2y ago
> only about 1% of them actually remove all the cruft they originally stick in (or populated during use). The result is bloat, a larger surface area for corruption, and system slowdown. I think this is a myth partly spread by commercial offerings that want to 'clean and optimize' a windows install. Most of the cruft left in the registry is the equivalent of config files in /etc not removed after uninstalling an app. That stuff isn't affecting performance.
- vkazanov 2y ago
  15 something years ago I had this unpleasant job where I had to install a major vendor's database on Windows server machines. I remember I also had a lengthy list of things to check and clean in the registry to make sure things work. Yes, these are configs. And no, we cannot just let applications do whatever they want in the shared config space without a way to trace things back to the original app. At least in the Linux world I was able to just check what the distro scripts installed.
  - ruthmarx 2y ago
    > And no, we cannot just let applications do whatever they want in the shared config space without a way to trace things back to the original app. We don't have to let them, but we do for the most part. We could use sandboxing technology to isolate and/or log, but mostly OSs don't do anything to restrict what an executable can do by default, at least as far as installing. > At least in the Linux world I was able to just check what the distro scripts installed. You can do this in Windows too sometimes, but it doesn't matter if it's a badly behaving app. There are linux installers that are just binary blobs and it would be a lot more work to monitor what they do also.
    - whoknowsidont 2y ago
      >but mostly OSs don't do anything to restrict what an executable can do by default, at least as far as installing. There is a very mature and very powerful system for this called Jails. >There are linux installers that are just binary blobs and it would be a lot more work to monitor what they do also. This is simply not true. If I want to monitor an app in it's entirety I can easily do so on most unixy systems. Past the default tools that require some amount of systems knowledge to use correctly, you can easily just use Stow or Checkinstall (works on most linux systems). There is no mechanism for doing this on Windows as even the OS loses track of it sometimes. And if you think I'm being dramatic, trust me, I am not. There is a reason the tools don't exist for Windows, at least meeting feature parity.
nullindividual 2y ago
This is the responsibility of the installer. Using Windows Installer, this is easily accomplished. The Msi database _does_ track individual files and registry entries. If you're using another installer, or the developer allows their app to write something somewhere that isn't tracked by their installer, you're going to get files left behind. macOS is especially bad in this respect. Bundles are great, until you have a ~/Library full of files that you never knew about after running an application.
- rbanffy 2y ago
  > This is the responsibility of the installer On any Unix I can grep my way into the /etc tree and find files belonging to uninstalled applications and get rid of them myself. The whole point is that I can manage the “configuration database” with the same tools I manage a filesystem. That if the brilliant tools like apt and dnf fail to clean up after a program is uninstalled.
  - nullindividual 2y ago
    Windows is no different. Next time you're in front of Terminal, try: cd HKCU:\SOFTWARE You're now browsing the registry and can use terminal commands.
    - rbanffy 2y ago
      When was this introduced? This is surprisingly enlightened. Can I edit keys with a text editor?
      - amaccuish 2y ago
        Thank you for your reasoned response. I still like the idea that I think you originally had, whereby apps could only write to their own specific area, thus containing all their configuration. I think that would solve 99% of all complaints about the registry. Right now, they can write to anywhere your user has access to.

rbanffy 2y ago

What exactly do I gain from the registry that compensates for the fact I can use any tool that works on files to manage the /etc tree? Can you manage registry folders with Git and keep track of the changes you make? Can you grep for content? On a Mac it’s indexed by the systemwide text search tooling. Using the file system to store that data is extremely powerful.

craigmoliver 2y ago
You can create/export .reg files to your GIT repo/file system...but that may be one extra step and doesn't stay in sync automatically.
- rbanffy 2y ago
  Another idea would be to do periodic snapshots of the /etc folder. That, sadly, excludes ext4, but any flavour of Solaris can easily do it.