7 ms·

It feels like the Windows Registry is one of those well-intentioned ideas that ended up being a tremendous mess in actual implementation. "Let's use a central d

by kortex 3y ago

It feels like the Windows Registry is one of those well-intentioned ideas that ended up being a tremendous mess in actual implementation. "Let's use a central database to store things that the OS, drivers, and UI need to access" somehow became "half assed KV dumping ground for every process and their dog to litter with whatever while acting as a singular bottleneck". See also: https://news.ycombinator.com/item?id=32275078 https://news.ycombinator.com/item?id=32275078

foobarian 3y ago
They are global variables. Worth working very hard to block in any project. Separate microservices are the most effective way I saw so far to stop people in a large org from making shortcuts via global contexts. I feel bad for our frontend devs dealing with a tide of global constructs in our React codebase.
- recursive 3y ago
  I still haven't seen a non-handwavy method for orchestrating a transaction across microservices. That means I still can't use them. Although I don't think I ever wanted to particularly.
  - duped 3y ago
    You wouldn't ever design a microservice architecture that required transactions across them. Every microservice owns its own data.
    - recursive 3y ago
      Maybe it's just the domain, but I guess it means the scope of my microservice is just the whole damn thing anyway. I guess I was doing microservices the whole time.
      - toast0 3y ago
        That seems domain specific. I can imagine some services where transactions across everything are unavoidable, but I've also worked on lots of things where there's different databases and transactions aren't needed between them. Some times it is a relaxation of requirements though. Some people might want/need account deletion to also remove all the content related to the account transactionally, etc, and if that's a requirement, everything account related must be in a transactionable system. If you can be more flexible on that, separating account management from other data is pretty common in my experience.
- dclowd9901 3y ago
  Global objects in react are almost universally an anti pattern. The only way to do them right is through a context, ensuring the state lives in the context. But most people hate writing the scaffolding, so a non reactive, non FP singleton gets to work and fails at integrating correctly with the react ecosphere.
- Joker_vD 3y ago
  Well, the file system, too, is a global variable. Concurrent reading/writing of a single file has about the same racy behaviour as concurrent reading/writing of a global variable.
- Dylan16807 3y ago
  You still need to store variables somewhere. The equivalent of "separate microservices" is making sure multiple programs don't share registry keys, and that's already the case 99% of the time for this kind of key.
duped 3y ago
A central key-value store that can be programmatically accessed to persist state across users, processes, and boots, that is also strictly typed and hierarchical is quite useful. I think it would actually be quite useful to have an /etc/conf virtual file system that could be programmatically accessed by user space processes and used as a "dumping ground" just like /etc already is.
- CamperBob2 3y ago
  I think the "central" part is where you lose me with this argument. What advantages does the registry have over application-specific KV stores... besides the potential to interfere with other applications and the OS itself?
  - Someone1234 3y ago
    Where do you store where the application-specific KV stores are located? Are you just going to hard-code it so the application cannot be moved or installed elsewhere or on external drives? Where does the OS store its own settings? There are a lot of problems with software "shotgunning" their junk across the system. This isn't exclusive to the Registry or even a specific OS unfortunately. Just go look at what configuration files are located between applications on Linux for example, it is not consistent at all.
    - philistine 3y ago
      macOS has a folder called Library where this stuff is supposed to go. It's not enforced by decree, with many apps doing their own horrible thing. Ultimately, its macOS' culture that mostly makes apps puts their settings and other resident details in Library. I'm not knowledgeable enough to know why a culturally enforced folder is far worse than the database that Windows has. Care to enlighten me?
      - MaxikCZ 3y ago
        I pressume "Program Files" or "AppData" folders are Windows analogy to Library
Joker_vD 3y ago
> "half assed KV dumping ground for every process and their dog to litter with whatever while acting as a singular bottleneck" Doesn't that describe disk filesystems too? And Unix file namespace in particular (a single hierarchy unifying several block devices, just like registry is composed of several on-disk files)? What about all that junk in one's $HOME?
- kortex 3y ago
  No, because the filesystem is one layer of abstraction lower than the registry. There's nothing with less bottleneck to the filesystem besides raw device access. The registry runs on top of the filesystem. If you wish to use the registry for filesystem-like purposes (eg storing startup config specific to the app or user state), just use filesystem. If you wish to use it like a database for system-wide information, that's a better use-case, but the registry isn't quite a proper database. Windows programs proliferate $HOME junk, too. And that's an issue in its own right, which should be addressed by platform-specific application dirs (e.g. the platformdirs library for python).
  - Joker_vD 3y ago
    > No, because the filesystem is one layer of abstraction lower than the registry. That doesn't prevent it from becoming a KV dumping ground for every process and their dog to litter with whatever, at all. Not in the least because it's already that, which a cursory look through /tmp and /var supports. > There's nothing with less bottleneck to the filesystem besides raw device access I thought there was considerable effort from the Linux kernel team spend on parallelization of the inode and buffers management but if you say that the main bottleneck is the raw device speed then sure, I'll believe you. It's not like NVMe protocl has design with 64K command queues each 64K command long because the OS simply can't saturate the device's bandwith otherwise, right?
- gorgoiler 3y ago
  In particular, taking a leisurely stroll through /etc is quite a treat if you enjoy a well planted and diverse bed of configuration cultures. Over on one end you have papersize, a file containing a single word with seemingly no relation to any installed software. In httpd.conf we have a sort of SGML that’s mostly line oriented CDATA. aliases and many other mail files are all members of the Berkeley DB lineage of key value stores. default/ feels like it’s also a key value store but one suspects that one could probably put a command in there and something would execute it. rc.d is 99% code but with semantics in the symlinks too (see also Debian’s alternatives.) A very large number of files look like braced C code; named.conf even requires terminal semicolons! There’s no value in either consistency or diversity of the underlying implementation be it a registry — the registry, or a gconf thing — or a filesystem smorgasbord of config languages. Without the discipline (authoritarianism?) of a social structure — for example a “company” with a hierarchical leadership that can promote/fire you — you will get diversity in any system. I just reminded myself of the time I used ansible YAML Jinja templates to control EdgeRouter config files that programmatically built config in /etc. Time for a leisurely stroll in a real garden I think, far away from a computer.
belltaco 3y ago
It's developer error. It'd be the same as a game on Linux filling up a conf file or a database with duplicates. Does Linux have mechanisms to guard against that? Didn't think so.
- kortex 3y ago
  No, but I imagine it's a bit easier to catch an unwanted proliferation of files vs unwanted proliferation of registry keys.
- deadlydose 3y ago
  > Does Linux have mechanisms to guard against that? Sure. ulimit or cgroups can.
  - belltaco 3y ago
    I doubt any of those are applied to games or applications on Linux by default.
    - Intralexical 3y ago
      If you install games via Flatpak, or via Steam which you've installed via Flatpak, they are indeed isolated in `~/.var/app/*`, IIRC. But this thread is getting distracted. That's a separate issue, and the applications in question can still pollute all they want within their container.
pathartl 3y ago
Most games that _do_ use the registry use it as a data store that may or may not be accessed by external applications. It provides a very reliable pathing (at least at the time of the game's release) to access typed data. For instance, most EA games from the early 2000's standardized the store of the CD key in ~HKLM:\SOFTWARE\<Game Name>\ergc. This would let one install the game to any drive and still have access to the CD key. Games also use the registry as a way to point to where the game is installed. In the worst case scenario, it's used as a dumping ground for the game's preferences/settings and save states. With the shift to 64 bit and the introduction of WoW64 and most recently the shift to VirtualStores, I would rather nobody ever stores anything in the registry. I'm currently working on a compatibility shim geared towards games that will redirect winapi filesystem and registry calls to a custom location. Hopefully it'll result in being able to make more portable installs of games that may require access to the registry.
- heavenlyblue 3y ago
  How is that different from accessing $HOME/.config? It does exist on Windows too, but I don't want to Google it. I believe in Windows there's even $SHARED/.config
  - c0nsumer 3y ago
    Using the registry is a pretty simple API call to say place X here, read X if it exists, etc. If you need to start manipulating configuration files, then you need to deal with all the complexities of that. The registry is great for exactly this sort of config info. And on Windows, HKLM (HKEY_LOCAL_MACHINE) is for system-wide stuff. If it were per-user config it'd go in HKCU (HKEY_CURRENT_USER).
  - Narishma 3y ago
    I think it's %LOCALAPPDATA% and %APPDATA% respectively.
- kortex 3y ago
  Those sound like exactly the use cases the registry should be used for. However in practice all kinds of state ends up in there that does not need to be accessed by anything other than the game process.
charcircuit 3y ago
As opposed to using the filesystem which is an even poorer KV store?
hulitu 3y ago
> It feels like the Windows Registry is one of those well-intentioned ideas that ended up being a tremendous mess in actual implementation. The real issue is that this is known since Win 95 days , yet some people don't get it.

by kortex 3y ago

foobarian 3y ago

They are global variables. Worth working very hard to block in any project. Separate microservices are the most effective way I saw so far to stop people in a large org from making shortcuts via global contexts. I feel bad for our frontend devs dealing with a tide of global constructs in our React codebase.

recursive 3y ago
I still haven't seen a non-handwavy method for orchestrating a transaction across microservices. That means I still can't use them. Although I don't think I ever wanted to particularly.
- duped 3y ago
  You wouldn't ever design a microservice architecture that required transactions across them. Every microservice owns its own data.
  - recursive 3y ago
    Maybe it's just the domain, but I guess it means the scope of my microservice is just the whole damn thing anyway. I guess I was doing microservices the whole time.
    - toast0 3y ago
      That seems domain specific. I can imagine some services where transactions across everything are unavoidable, but I've also worked on lots of things where there's different databases and transactions aren't needed between them. Some times it is a relaxation of requirements though. Some people might want/need account deletion to also remove all the content related to the account transactionally, etc, and if that's a requirement, everything account related must be in a transactionable system. If you can be more flexible on that, separating account management from other data is pretty common in my experience.
dclowd9901 3y ago
Global objects in react are almost universally an anti pattern. The only way to do them right is through a context, ensuring the state lives in the context. But most people hate writing the scaffolding, so a non reactive, non FP singleton gets to work and fails at integrating correctly with the react ecosphere.
Joker_vD 3y ago
Well, the file system, too, is a global variable. Concurrent reading/writing of a single file has about the same racy behaviour as concurrent reading/writing of a global variable.
Dylan16807 3y ago
You still need to store variables somewhere. The equivalent of "separate microservices" is making sure multiple programs don't share registry keys, and that's already the case 99% of the time for this kind of key.

duped 3y ago

A central key-value store that can be programmatically accessed to persist state across users, processes, and boots, that is also strictly typed and hierarchical is quite useful. I think it would actually be quite useful to have an /etc/conf virtual file system that could be programmatically accessed by user space processes and used as a "dumping ground" just like /etc already is.

CamperBob2 3y ago
I think the "central" part is where you lose me with this argument. What advantages does the registry have over application-specific KV stores... besides the potential to interfere with other applications and the OS itself?
- Someone1234 3y ago
  Where do you store where the application-specific KV stores are located? Are you just going to hard-code it so the application cannot be moved or installed elsewhere or on external drives? Where does the OS store its own settings? There are a lot of problems with software "shotgunning" their junk across the system. This isn't exclusive to the Registry or even a specific OS unfortunately. Just go look at what configuration files are located between applications on Linux for example, it is not consistent at all.
  - philistine 3y ago
    macOS has a folder called Library where this stuff is supposed to go. It's not enforced by decree, with many apps doing their own horrible thing. Ultimately, its macOS' culture that mostly makes apps puts their settings and other resident details in Library. I'm not knowledgeable enough to know why a culturally enforced folder is far worse than the database that Windows has. Care to enlighten me?
    - MaxikCZ 3y ago
      I pressume "Program Files" or "AppData" folders are Windows analogy to Library

Joker_vD 3y ago

> "half assed KV dumping ground for every process and their dog to litter with whatever while acting as a singular bottleneck" Doesn't that describe disk filesystems too? And Unix file namespace in particular (a single hierarchy unifying several block devices, just like registry is composed of several on-disk files)? What about all that junk in one's $HOME?

kortex 3y ago
No, because the filesystem is one layer of abstraction lower than the registry. There's nothing with less bottleneck to the filesystem besides raw device access. The registry runs on top of the filesystem. If you wish to use the registry for filesystem-like purposes (eg storing startup config specific to the app or user state), just use filesystem. If you wish to use it like a database for system-wide information, that's a better use-case, but the registry isn't quite a proper database. Windows programs proliferate $HOME junk, too. And that's an issue in its own right, which should be addressed by platform-specific application dirs (e.g. the platformdirs library for python).
- Joker_vD 3y ago
  > No, because the filesystem is one layer of abstraction lower than the registry. That doesn't prevent it from becoming a KV dumping ground for every process and their dog to litter with whatever, at all. Not in the least because it's already that, which a cursory look through /tmp and /var supports. > There's nothing with less bottleneck to the filesystem besides raw device access I thought there was considerable effort from the Linux kernel team spend on parallelization of the inode and buffers management but if you say that the main bottleneck is the raw device speed then sure, I'll believe you. It's not like NVMe protocl has design with 64K command queues each 64K command long because the OS simply can't saturate the device's bandwith otherwise, right?
gorgoiler 3y ago
In particular, taking a leisurely stroll through /etc is quite a treat if you enjoy a well planted and diverse bed of configuration cultures. Over on one end you have papersize, a file containing a single word with seemingly no relation to any installed software. In httpd.conf we have a sort of SGML that’s mostly line oriented CDATA. aliases and many other mail files are all members of the Berkeley DB lineage of key value stores. default/ feels like it’s also a key value store but one suspects that one could probably put a command in there and something would execute it. rc.d is 99% code but with semantics in the symlinks too (see also Debian’s alternatives.) A very large number of files look like braced C code; named.conf even requires terminal semicolons! There’s no value in either consistency or diversity of the underlying implementation be it a registry — the registry, or a gconf thing — or a filesystem smorgasbord of config languages. Without the discipline (authoritarianism?) of a social structure — for example a “company” with a hierarchical leadership that can promote/fire you — you will get diversity in any system. I just reminded myself of the time I used ansible YAML Jinja templates to control EdgeRouter config files that programmatically built config in /etc. Time for a leisurely stroll in a real garden I think, far away from a computer.

belltaco 3y ago

It's developer error. It'd be the same as a game on Linux filling up a conf file or a database with duplicates. Does Linux have mechanisms to guard against that? Didn't think so.

kortex 3y ago
No, but I imagine it's a bit easier to catch an unwanted proliferation of files vs unwanted proliferation of registry keys.
deadlydose 3y ago
> Does Linux have mechanisms to guard against that? Sure. ulimit or cgroups can.
- belltaco 3y ago
  I doubt any of those are applied to games or applications on Linux by default.
  - Intralexical 3y ago
    If you install games via Flatpak, or via Steam which you've installed via Flatpak, they are indeed isolated in `~/.var/app/*`, IIRC. But this thread is getting distracted. That's a separate issue, and the applications in question can still pollute all they want within their container.

pathartl 3y ago

Most games that _do_ use the registry use it as a data store that may or may not be accessed by external applications. It provides a very reliable pathing (at least at the time of the game's release) to access typed data. For instance, most EA games from the early 2000's standardized the store of the CD key in ~HKLM:\SOFTWARE\<Game Name>\ergc. This would let one install the game to any drive and still have access to the CD key. Games also use the registry as a way to point to where the game is installed. In the worst case scenario, it's used as a dumping ground for the game's preferences/settings and save states. With the shift to 64 bit and the introduction of WoW64 and most recently the shift to VirtualStores, I would rather nobody ever stores anything in the registry. I'm currently working on a compatibility shim geared towards games that will redirect winapi filesystem and registry calls to a custom location. Hopefully it'll result in being able to make more portable installs of games that may require access to the registry.

heavenlyblue 3y ago
How is that different from accessing $HOME/.config? It does exist on Windows too, but I don't want to Google it. I believe in Windows there's even $SHARED/.config
- c0nsumer 3y ago
  Using the registry is a pretty simple API call to say place X here, read X if it exists, etc. If you need to start manipulating configuration files, then you need to deal with all the complexities of that. The registry is great for exactly this sort of config info. And on Windows, HKLM (HKEY_LOCAL_MACHINE) is for system-wide stuff. If it were per-user config it'd go in HKCU (HKEY_CURRENT_USER).
- Narishma 3y ago
  I think it's %LOCALAPPDATA% and %APPDATA% respectively.
kortex 3y ago
Those sound like exactly the use cases the registry should be used for. However in practice all kinds of state ends up in there that does not need to be accessed by anything other than the game process.

charcircuit 3y ago

As opposed to using the filesystem which is an even poorer KV store?

hulitu 3y ago

> It feels like the Windows Registry is one of those well-intentioned ideas that ended up being a tremendous mess in actual implementation. The real issue is that this is known since Win 95 days , yet some people don't get it.