4 ms·

Easier to work with files, I can grep them, version them, diff them, edit them with any tool I want.

by midasuni 3y ago

flohofwoe 3y ago
...if you actually know where to look in the first place though...
- iforgotpassword 3y ago
  In /etc/$toolname While in the registry it's like 5 layers deep and you need to figure out the vendor name along the way.
  - flohofwoe 3y ago
    Application specific dot-files are sometimes in the user's home directory, but sometimes also elsewhere.
  - Joker_vD 3y ago
    No, it's not there, it's in ~/.local. Or maybe ~/.cache. What is in /etc, however, is /etc/papersize. Not entirely sure who uses that, but it's there. Also, regedit supports Ctrl+F.
  - JdeBP 3y ago
    Except that it is not /etc/$toolname. Sometimes it's /etc/$subdirectory/$toolname, doing that very many-layers-deep thing that you describe. Sometimes, particularly on the BSDs, it's /usr/local/etc. Sometimes it's ~/.config/$subdirectory/$subdirectory/$thing . Or, if you are lucky, it follows the XDG rules for locating the ~/.config part. Sometimes it's ~/.$toolname . The irony is that all of the arguments about where the files are fall apart and miss the point, as the Windows registry hive file system is far more standardized than Linux-based operating systems and the BSDs are. The real discussion point is whether a structured hierarchical database of key-value pairs with typed values, accessed through an operating system API, is better as an actual database file format, with all that that implies for things like indexing and the elimination of quoting rules, text parsing, and escaping; or as text files just like it used to be with the old loads-of-.INI files system of DOS-Windows 3.
    - com2kid 3y ago
      You forgot about if the tool was installed using snap, then it is someplace different yet again!
      - JdeBP 3y ago
        I didn't want to spend a whole afternoon eumerating every single possibility. Anyway, I vaguely recall that I already did in a Stack Exchange answer, which is ironic given the headlined subject, years ago. (-:
    - Modified3019 3y ago
      The galaxy brain solution is to use nixos/home manager and design your own arbitrary layout config hydra.
- adrian_b 3y ago
  Discovering what registry key controls whatever you are interested in is not at all easier than finding a configuration file, especially because what you need may be dispersed in several keys with obfuscated names that are located in wildly different parts of the huge registry.
- neuromanser 3y ago
  In my experience, print -l /etc/**/*foo* or grep -Ir foo /etc leads to results faster than stabbing in the dark of regedit search. Manpages usually list configuration files.
skissane 3y ago
> Easier to work with files, I can grep them, version them, diff them, edit them with any tool I want. Microsoft could have exposed the registry as a filesystem. R: drive or \\winreg\ or whatever. They kind of have with Powershell, but that's Powershell-specific. They could have made it part of the OS so it was available to all apps, like /proc and /sys on Linux. And then you could do all those things to them too.
- JdeBP 3y ago
  In terms of the native API, it is viewed as a filesystem, accessed via the Object Manager like everything else. The registry is under \REGISTRY .
  - skissane 3y ago
    Not really, because although it is in the Object Manager namespace, it isn't composed of File objects, it is composed of Key objects. So the normal file APIs (e.g. NtOpenFile) don't work on it, instead you have to use NtOpenKey/etc If it were actually a filesystem, it would be composed of File objects, so you could manipulate it using the exact same API calls you use to manipulate files – which would mean that tools/utilities/apps which know how to manipulate files would just magically work on registry keys too.
anjanb 3y ago
The registry can store binary values. Combining binary and text values in the same files usually result in a mess for most users.
delta_p_delta_x 3y ago
I deeply dislike string-typed operating systems (i.e. Unix and its issue). Likewise with 'everything is a file'. OSes are a superb use-case for recursive, object-oriented, hierarchical setup and configuration, but no; Unix and friends, and the programs that run on them, insist on spewing a million-odd .ini, .cfg, .json, .yaml, .xml, .whateverml files all over the filesystem and then 'hiding' them with the leading full-stop.

Easier to work with files, I can grep them, version them, diff them, edit them with any tool I want.

flohofwoe 3y ago

...if you actually know where to look in the first place though...

iforgotpassword 3y ago
In /etc/$toolname While in the registry it's like 5 layers deep and you need to figure out the vendor name along the way.
- flohofwoe 3y ago
  Application specific dot-files are sometimes in the user's home directory, but sometimes also elsewhere.
- Joker_vD 3y ago
  No, it's not there, it's in ~/.local. Or maybe ~/.cache. What is in /etc, however, is /etc/papersize. Not entirely sure who uses that, but it's there. Also, regedit supports Ctrl+F.
- JdeBP 3y ago
  Except that it is not /etc/$toolname. Sometimes it's /etc/$subdirectory/$toolname, doing that very many-layers-deep thing that you describe. Sometimes, particularly on the BSDs, it's /usr/local/etc. Sometimes it's ~/.config/$subdirectory/$subdirectory/$thing . Or, if you are lucky, it follows the XDG rules for locating the ~/.config part. Sometimes it's ~/.$toolname . The irony is that all of the arguments about where the files are fall apart and miss the point, as the Windows registry hive file system is far more standardized than Linux-based operating systems and the BSDs are. The real discussion point is whether a structured hierarchical database of key-value pairs with typed values, accessed through an operating system API, is better as an actual database file format, with all that that implies for things like indexing and the elimination of quoting rules, text parsing, and escaping; or as text files just like it used to be with the old loads-of-.INI files system of DOS-Windows 3.
  - com2kid 3y ago
    You forgot about if the tool was installed using snap, then it is someplace different yet again!
    - JdeBP 3y ago
      I didn't want to spend a whole afternoon eumerating every single possibility. Anyway, I vaguely recall that I already did in a Stack Exchange answer, which is ironic given the headlined subject, years ago. (-:
  - Modified3019 3y ago
    The galaxy brain solution is to use nixos/home manager and design your own arbitrary layout config hydra.
adrian_b 3y ago
Discovering what registry key controls whatever you are interested in is not at all easier than finding a configuration file, especially because what you need may be dispersed in several keys with obfuscated names that are located in wildly different parts of the huge registry.
neuromanser 3y ago
In my experience, print -l /etc/**/*foo* or grep -Ir foo /etc leads to results faster than stabbing in the dark of regedit search. Manpages usually list configuration files.

skissane 3y ago

> Easier to work with files, I can grep them, version them, diff them, edit them with any tool I want. Microsoft could have exposed the registry as a filesystem. R: drive or \\winreg\ or whatever. They kind of have with Powershell, but that's Powershell-specific. They could have made it part of the OS so it was available to all apps, like /proc and /sys on Linux. And then you could do all those things to them too.

JdeBP 3y ago
In terms of the native API, it is viewed as a filesystem, accessed via the Object Manager like everything else. The registry is under \REGISTRY .
- skissane 3y ago
  Not really, because although it is in the Object Manager namespace, it isn't composed of File objects, it is composed of Key objects. So the normal file APIs (e.g. NtOpenFile) don't work on it, instead you have to use NtOpenKey/etc If it were actually a filesystem, it would be composed of File objects, so you could manipulate it using the exact same API calls you use to manipulate files – which would mean that tools/utilities/apps which know how to manipulate files would just magically work on registry keys too.

anjanb 3y ago

The registry can store binary values. Combining binary and text values in the same files usually result in a mess for most users.

delta_p_delta_x 3y ago

I deeply dislike string-typed operating systems (i.e. Unix and its issue). Likewise with 'everything is a file'. OSes are a superb use-case for recursive, object-oriented, hierarchical setup and configuration, but no; Unix and friends, and the programs that run on them, insist on spewing a million-odd .ini, .cfg, .json, .yaml, .xml, .whateverml files all over the filesystem and then 'hiding' them with the leading full-stop.