6 ms·

> what is the windows registry and why do things need to write to it? It's a centralized, high-performance small key value store that's the alternative to writ

> what is the windows registry and why do things need to write to it? It's a centralized, high-performance small key value store that's the alternative to writing a million config files in random places. It's arguably much better in my experience. E.g. one of the never-ending headaches I always have on Linux is updating config files when a package updates. There's no automatic file merge in general (hence .pacnew and such) so you gotta do it by hand (and not everything is available with the foo.d/ hack). The registry already operates at the value granularity so it bypasses this kind of issue. And as a developer you don't have to worry about some things you might not think about, like the trade-off between corrupting your config files with in-place updates vs. having to create a new file and replace the old one after every config change.

throwaway290 3y ago
It's great and granular until someone starts to push complex serialized structures or large blobs as registry values...
manbash 3y ago
OP asked for an analogue, not a comparison. I think it's silly to compare the two.
rapind 3y ago
What's always annoyed me with many operating systems is this need to organize based on function instead of domain. If I install an application named "Bob" then I want ALL of Bob's configuration to live within Bob. I don't want it split between different registry keys or /usr/local, /etc/, /var, /lib, etc. I'm fine with there being conventions and categorizations, but I'd like to root node to be the application itself. Yes, I even want this for multiple users. I know there are design arguments to / for the various different ways of organizing configurations, but IMO they are just inferior from at least this user's perspective.
- Someone1234 3y ago
  I think for all future development, the industry agrees with you. Chromeium, iOS, Android, and Windows Store apps all utilize packages and per-package storage. We're just suffering from backwards compatibility for things made over 30-years ago.
- Brian_K_White 3y ago
  That would be a directory called /bob right in the root dir, containing everything relating to tge bob app, including the firewall settings, both the distro defaults and the user layered, the executables, the image resources, the db libraries, the db store... never mind that the firewall is another package that needs those same settings... No. Or, if you really do want something so insane, well great news, you have snap and flatpak. If those are not complete enough examples of this shining vision, go ahead and show us how it's done.
  - spoiler 3y ago
    You're constructing an argument the person never made. The binary for my app could live in a hypothetical /apps/bob. Its config could be in there too. There's no need to duplicate dynamically linked system libraries in there. If the app need a different version of a library than the one provided by the distro/os, it could vendor it (or link statically). Optionally it can vendor and still try to use OS version if they version is satisfied, but this is just a memory optimisation (disk isn't that expensive). There's also no need to place firewall rules in there. I'm not sure where you got that from. Firewalls are beyond the scope of a single application? As for making thing system-wide available, there's already a few solutions for this (symlinks being a very backwards compatible way of doing this on nixes). For all its faults and poor UX execution (albeit, maybe things improved since I last used them) flat pack and snap have some good ideas!
    - ElectricalUnion 3y ago
      > There's no need to duplicate dynamically linked system libraries in there. > For all its faults and poor UX execution (albeit, maybe things improved since I last used them) flat pack and snap have some good ideas! Hum, flatpak says hello. Unlike the kernel, Linux userland is a not-backwards-compatible hell so the only way to make sure things don't blow up in a spectacular fashion is bundling the whole world that you need with your app, or hopefully that someone bundled the things that you need with a Flatpak Application Platform for you.. > There's also no need to place firewall rules in there. > As for making thing system-wide available, there's already a few solutions for this (symlinks being a very backwards compatible way of doing this on nixes). I'm pretty sure that if you're proposing a "app is a folder" specification, any application that has some system-wide rules it needs to install or suggests or toggle, need to live somewhere in the application folder. Icon customizations, firewall rules, mdns, upnp, those sorts of things. If the application folder is the end-all, then it need to have some form of "$sysconfigdir overlay" folder if it wants to modify $sysconfigdir without actually being able to modify or spill over the actual $sysconfigdir (and therefore not being contained in the folder at all). That is in fact how flatpak works: you're never supposed to write anything at the host /etc, you overlay things in your application folder XDG_CONFIG_DIRS and flatpak-aware applications read flatpak XDG_CONFIG_DIRS folders. That is in fact how nix works: nix packages are supposed to be read-only self-contained folder in /nix/store/$hash-package-$version, and /etc happens to be a non-persistent cache thing that will be overridden sooner or later by a nix expression. But that of course means that now you have several XDG_CONFIG_DIRS/$sysconfigdir lying around in your system.
- tremon 3y ago
  You are correct, from a user's perspective this seems like unnecessary complexity. But here on the system administration side of Chesterton's fence, these splits enable more secure, more robust and more reliable systems. Among others, this allows for improved backup and recovery, better storage efficiency, easier application of security patches and providing centralized configuration.
- hcarvalhoalves 3y ago
  This exists for a while now, but didn't catch on: https://gobolinux.org/at_a_glance.html https://gobolinux.org/at_a_glance.html
  - rapind 3y ago
    Yes exactly.
  - dreamcompiler 3y ago
    That's largely what MacOS does.
- throeaaysn 3y ago
  [dead]
  - Gibbon1 3y ago
    And Microsoft knows corporate is where the reoccurring revenue is.
    - Datagenerator 3y ago
      The number one reason corporate picks Microsoft is the control of people it provides by it lush telemetry dashboards on worker efficiency.
- sokoloff 3y ago
  I like being able to use revision control to track config changes mostly in one place (/etc), using etckeeper.
vardump 3y ago
"high-performance" We might have differing opinions about that. (I've got experience for example in Windows kernel mode drivers and service development.)
- throeaaysn 3y ago
  [dead]
  - vardump 3y ago
    No guesstimates, but it's generally very bad. Especially when there's some corporate "security" software in the loop. And that's the case you have to really code against.
    - dataflow 3y ago
      You already realize it's your security software that's slowing your system calls. Blaming it on the registry makes no sense. It's like blaming HN for being slow because your ISP is slow.
      - vardump 3y ago
        Not mine, but the actual customers'. "Works for me" is not going too far. Besides, registry is not a rocket even on a clean system.
- dataflow 3y ago
  What are you comparing against here that's leading you to a different opinion? Are you claiming file I/O would be faster or that you could write the equivalent functionality faster? Also note that performance isn't just speed either.
  - vardump 3y ago
    For example SQLite is superior. That said, on Windows you kinda have to use registry, especially on the kernel driver level.
msla 3y ago
The performance part is questionable, as is the discoverability: Programs write binary blobs to impossible-to-find keys and, as we see here, there's nothing preventing a severe loss of performance if the program writes too much to the registry. It can only be examined with specialized tools, and, due to the binary values written to it, it might not be meaningfully editable at all.
- akira2501 3y ago
  It's also really a pain once you realize that many strings are stored in raw UTF16 form. It makes using any tools or doing any automation on the values much harder than it should be.
- KennyBlanken 3y ago
  There's also no mechanism for the OS to offer the user the ability to purge registry entries when a program is uninstalled, so the registry just bloats further and further.
  - rvba 3y ago
    Registry bloat was one of the reasons why reinstalling Windows used to speed up computers in the 95-2000 times.
  - nullindividual 3y ago
    This is no different with most Linux distributions or macOS. When applications are deployed and create configuration files (system-wide or user), they're often not removed when deleting the application.
  - RajT88 3y ago
    Installers are supposed to do that. But they have to be well-written installers (many aren't). And anyways, lots of installers are written by companies which want to leave their footprint behind even if you do uninstall. Finding orphaned registry entries is hard - it's not always clear what application put them there, and how to determine that the application is still installed.
_dain_ 3y ago
>one of the never-ending headaches I always have on Linux is updating config files when a package updates. There's no automatic file merge in general (hence .pacnew and such) so you gotta do it by hand (and not everything is available with the foo.d/ hack). nix solves this
llm_nerd 3y ago
The registry is far from high performance. And given the registry is basically a massive hierarchical structure, how is it different from files re: "random places"? The same dev that dumps files in "Random places" would dump values in random places in the registry. The registry is almost never a good choice for storing...anything outside of the operating system itself, unless the data is somehow tightly coupled with a specific Windows install (e.g. an activation key). The idea of storing instance data in the registry is madness.
a-dub 3y ago
> There's no automatic file merge in general (hence .pacnew and such) so you gotta do it by hand (and not everything is available with the foo.d/ hack). The registry already operates at the value granularity so it bypasses this kind of issue. it gets around this issue by creating a gigantic systemwide or per user bucket of crap that inevitably ends up inconsistent. since it is custom there is no good tooling for doing diffs and many developers treat it as quasi private so the config values are often not human readable. there are management utilities that work ok, until they don't. then you have to start over because who knows, it's all just crap. it's literally like a jerry seinfeld joke. you think configuration should be sensible, then everybody just sees this bucket and goes wooopty woopty woo and then it's just filled with crap. bill gates probably sent emails about it. "i tried to look at the registry, but then it was just trashed." that is the registry. a little shadow filesystem with a bizarre layout with weird and incomplete tools that is filled with crap.
pshc 3y ago
Except the part where whenever you install anything on Windows the whole OS grinds to a halt... I assume writing to the registry takes an exclusive lock. Or has to contend with decades of backwards compatibility layers and triggers, or both...
somat 3y ago
It is one of those ideas that sounds good. "Hey we will put all the configs into a database under one tree", Oh wow, that sounds great, sign me up. The main fundamental problem is now you have two trees, with completely different access patterns. It is also all in the spin. What if I told you over on this side of the OS table we too keep all our configs in this great single tree database, not only that, we keep our data in the same database, everything is accessed using the same simple unified interface, the api has about five calls, it is pretty great. It also has the amazing feature that physically separate devices can be merged into the same tree. Preposterous! some would say. All in the same tree! Why you would get everything muddled up. you must have a separate tree for each device. and a special tree with it's own special access patterns just for configs. But for real, people keep trying to reinvent the registry over in linux land. (cough) gnome (cough) and it is terrible.

throwaway290 3y ago

It's great and granular until someone starts to push complex serialized structures or large blobs as registry values...

manbash 3y ago

OP asked for an analogue, not a comparison. I think it's silly to compare the two.

rapind 3y ago

What's always annoyed me with many operating systems is this need to organize based on function instead of domain. If I install an application named "Bob" then I want ALL of Bob's configuration to live within Bob. I don't want it split between different registry keys or /usr/local, /etc/, /var, /lib, etc. I'm fine with there being conventions and categorizations, but I'd like to root node to be the application itself. Yes, I even want this for multiple users. I know there are design arguments to / for the various different ways of organizing configurations, but IMO they are just inferior from at least this user's perspective.

Someone1234 3y ago
I think for all future development, the industry agrees with you. Chromeium, iOS, Android, and Windows Store apps all utilize packages and per-package storage. We're just suffering from backwards compatibility for things made over 30-years ago.
Brian_K_White 3y ago
That would be a directory called /bob right in the root dir, containing everything relating to tge bob app, including the firewall settings, both the distro defaults and the user layered, the executables, the image resources, the db libraries, the db store... never mind that the firewall is another package that needs those same settings... No. Or, if you really do want something so insane, well great news, you have snap and flatpak. If those are not complete enough examples of this shining vision, go ahead and show us how it's done.
- spoiler 3y ago
  You're constructing an argument the person never made. The binary for my app could live in a hypothetical /apps/bob. Its config could be in there too. There's no need to duplicate dynamically linked system libraries in there. If the app need a different version of a library than the one provided by the distro/os, it could vendor it (or link statically). Optionally it can vendor and still try to use OS version if they version is satisfied, but this is just a memory optimisation (disk isn't that expensive). There's also no need to place firewall rules in there. I'm not sure where you got that from. Firewalls are beyond the scope of a single application? As for making thing system-wide available, there's already a few solutions for this (symlinks being a very backwards compatible way of doing this on nixes). For all its faults and poor UX execution (albeit, maybe things improved since I last used them) flat pack and snap have some good ideas!
  - ElectricalUnion 3y ago
    > There's no need to duplicate dynamically linked system libraries in there. > For all its faults and poor UX execution (albeit, maybe things improved since I last used them) flat pack and snap have some good ideas! Hum, flatpak says hello. Unlike the kernel, Linux userland is a not-backwards-compatible hell so the only way to make sure things don't blow up in a spectacular fashion is bundling the whole world that you need with your app, or hopefully that someone bundled the things that you need with a Flatpak Application Platform for you.. > There's also no need to place firewall rules in there. > As for making thing system-wide available, there's already a few solutions for this (symlinks being a very backwards compatible way of doing this on nixes). I'm pretty sure that if you're proposing a "app is a folder" specification, any application that has some system-wide rules it needs to install or suggests or toggle, need to live somewhere in the application folder. Icon customizations, firewall rules, mdns, upnp, those sorts of things. If the application folder is the end-all, then it need to have some form of "$sysconfigdir overlay" folder if it wants to modify $sysconfigdir without actually being able to modify or spill over the actual $sysconfigdir (and therefore not being contained in the folder at all). That is in fact how flatpak works: you're never supposed to write anything at the host /etc, you overlay things in your application folder XDG_CONFIG_DIRS and flatpak-aware applications read flatpak XDG_CONFIG_DIRS folders. That is in fact how nix works: nix packages are supposed to be read-only self-contained folder in /nix/store/$hash-package-$version, and /etc happens to be a non-persistent cache thing that will be overridden sooner or later by a nix expression. But that of course means that now you have several XDG_CONFIG_DIRS/$sysconfigdir lying around in your system.
tremon 3y ago
You are correct, from a user's perspective this seems like unnecessary complexity. But here on the system administration side of Chesterton's fence, these splits enable more secure, more robust and more reliable systems. Among others, this allows for improved backup and recovery, better storage efficiency, easier application of security patches and providing centralized configuration.
hcarvalhoalves 3y ago
This exists for a while now, but didn't catch on: https://gobolinux.org/at_a_glance.html https://gobolinux.org/at_a_glance.html
- rapind 3y ago
  Yes exactly.
- dreamcompiler 3y ago
  That's largely what MacOS does.
throeaaysn 3y ago
[dead]
- Gibbon1 3y ago
  And Microsoft knows corporate is where the reoccurring revenue is.
  - Datagenerator 3y ago
    The number one reason corporate picks Microsoft is the control of people it provides by it lush telemetry dashboards on worker efficiency.
sokoloff 3y ago
I like being able to use revision control to track config changes mostly in one place (/etc), using etckeeper.

vardump 3y ago

"high-performance" We might have differing opinions about that. (I've got experience for example in Windows kernel mode drivers and service development.)

throeaaysn 3y ago
[dead]
- vardump 3y ago
  No guesstimates, but it's generally very bad. Especially when there's some corporate "security" software in the loop. And that's the case you have to really code against.
  - dataflow 3y ago
    You already realize it's your security software that's slowing your system calls. Blaming it on the registry makes no sense. It's like blaming HN for being slow because your ISP is slow.
    - vardump 3y ago
      Not mine, but the actual customers'. "Works for me" is not going too far. Besides, registry is not a rocket even on a clean system.
dataflow 3y ago
What are you comparing against here that's leading you to a different opinion? Are you claiming file I/O would be faster or that you could write the equivalent functionality faster? Also note that performance isn't just speed either.
- vardump 3y ago
  For example SQLite is superior. That said, on Windows you kinda have to use registry, especially on the kernel driver level.

msla 3y ago

The performance part is questionable, as is the discoverability: Programs write binary blobs to impossible-to-find keys and, as we see here, there's nothing preventing a severe loss of performance if the program writes too much to the registry. It can only be examined with specialized tools, and, due to the binary values written to it, it might not be meaningfully editable at all.

akira2501 3y ago
It's also really a pain once you realize that many strings are stored in raw UTF16 form. It makes using any tools or doing any automation on the values much harder than it should be.
KennyBlanken 3y ago
There's also no mechanism for the OS to offer the user the ability to purge registry entries when a program is uninstalled, so the registry just bloats further and further.
- rvba 3y ago
  Registry bloat was one of the reasons why reinstalling Windows used to speed up computers in the 95-2000 times.
- nullindividual 3y ago
  This is no different with most Linux distributions or macOS. When applications are deployed and create configuration files (system-wide or user), they're often not removed when deleting the application.
- RajT88 3y ago
  Installers are supposed to do that. But they have to be well-written installers (many aren't). And anyways, lots of installers are written by companies which want to leave their footprint behind even if you do uninstall. Finding orphaned registry entries is hard - it's not always clear what application put them there, and how to determine that the application is still installed.

_dain_ 3y ago

>one of the never-ending headaches I always have on Linux is updating config files when a package updates. There's no automatic file merge in general (hence .pacnew and such) so you gotta do it by hand (and not everything is available with the foo.d/ hack). nix solves this

llm_nerd 3y ago

The registry is far from high performance. And given the registry is basically a massive hierarchical structure, how is it different from files re: "random places"? The same dev that dumps files in "Random places" would dump values in random places in the registry. The registry is almost never a good choice for storing...anything outside of the operating system itself, unless the data is somehow tightly coupled with a specific Windows install (e.g. an activation key). The idea of storing instance data in the registry is madness.

a-dub 3y ago

> There's no automatic file merge in general (hence .pacnew and such) so you gotta do it by hand (and not everything is available with the foo.d/ hack). The registry already operates at the value granularity so it bypasses this kind of issue. it gets around this issue by creating a gigantic systemwide or per user bucket of crap that inevitably ends up inconsistent. since it is custom there is no good tooling for doing diffs and many developers treat it as quasi private so the config values are often not human readable. there are management utilities that work ok, until they don't. then you have to start over because who knows, it's all just crap. it's literally like a jerry seinfeld joke. you think configuration should be sensible, then everybody just sees this bucket and goes wooopty woopty woo and then it's just filled with crap. bill gates probably sent emails about it. "i tried to look at the registry, but then it was just trashed." that is the registry. a little shadow filesystem with a bizarre layout with weird and incomplete tools that is filled with crap.

pshc 3y ago

Except the part where whenever you install anything on Windows the whole OS grinds to a halt... I assume writing to the registry takes an exclusive lock. Or has to contend with decades of backwards compatibility layers and triggers, or both...

somat 3y ago

It is one of those ideas that sounds good. "Hey we will put all the configs into a database under one tree", Oh wow, that sounds great, sign me up. The main fundamental problem is now you have two trees, with completely different access patterns. It is also all in the spin. What if I told you over on this side of the OS table we too keep all our configs in this great single tree database, not only that, we keep our data in the same database, everything is accessed using the same simple unified interface, the api has about five calls, it is pretty great. It also has the amazing feature that physically separate devices can be merged into the same tree. Preposterous! some would say. All in the same tree! Why you would get everything muddled up. you must have a separate tree for each device. and a special tree with it's own special access patterns just for configs. But for real, people keep trying to reinvent the registry over in linux land. (cough) gnome (cough) and it is terrible.