Hacker News Reader

Comment by flohofwoe | Hacker News Reader

It's arguably a better idea than the dot-file- and /etc- mess on Linux tbh.

The Windows registry is just a system-wide key/value database.

Actually, it's a combination of several such databases, some system-wide and some per-user.

And they're held in files. So if "I don't even give a damn what format the file is in" were true, registry hive files are not a problem per se. They are just files, too. They are just not text files, as many database files on computers are not.

I think the Windows registry is a classic example of a great idea in theory, but with regrettable quality of execution.

It could have been done a lot better. With a schema, self-documenting, with an integrated package database, with less insane legacy cruft.

But some of that's what you get with 30 years of history, with many decisions made in another era when resources were much more limited

Most if not all "problems" the Registry has are due to programmers like FwarkALark: Refusing to use anything other than scattered text files of varying formats and not cleaning up after themselves.

I love the Registry. It consolidates and centralizes almost everything there is to be configured in a single format, and it's even portable! Navigating it is no different than navigating a file system on a storage medium.

The Registry needs more use, not less.

Yep, I think the registry is far better than the mess of files on Linux. On Windows the answer to "where is this configured", 95% of the time, is the registry. I'm not saying it's perfect, because it isn't. But it's better than files scattered everywhere.

Not just a system-wide key/value database, but one with a few optimizations on top, if memory serves me right. It's in-memory first, which I suppose makes it a tad faster and is also neat for reducing disk writes on anything that receives a lot of changes in a short amount of time.

I think the concept is not too shabby. Perhaps not the best execution or tooling, but on paper, it sounds quite useful.

Another feature: .reg files!

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

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

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.

Application specific dot-files are sometimes in the user's home directory, but sometimes also elsewhere.

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.

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.

You forgot about if the tool was installed using snap, then it is someplace different yet again!

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. (-:

The galaxy brain solution is to use nixos/home manager and design your own arbitrary layout config hydra.

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.

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.

> 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.

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 .

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.

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

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.

I think the main point of this rant is how horrible regedit is. IMO it's a fair point.

But one that misses the point that regedit was superseded by regedt32 and even that hasn't been the only tool in the toolkit for decades.

There are specialized tools like (for instance) the ODBC Data Sources utilities that edit specific parts of the registry in more structured ways; and there are generalized tools like PowerShell that actually present the Registry as if it were a filesystem. One can actually "dir" the Registry with "-recursive" and wildcards and whatnot in PowerShell. (Personally, I try to be in the habit of avoiding PowerShell's compatibility aliases, but they're there for the people who want things to appear like their old familiar MS-DOS command lines.)

"I cannot edit this database file with a text editor." is an I-have-a-hammer-everything-must-be-a-nail argument. In the world of Windows and MS/PC-DOS preceding it, we've had specialized file editors for a long time.

I mentioned Peter Norton in another comment. Norton Utilities and clones like PC Tools and the Graham Utilities had specialized data file editors and viewers of several kinds. PC Tools could do several of the leading MS/PC-DOS database file formats, as I recall. (I'm not getting the box out of storage and checking the manual. (-: ) The culture of MS/PC-DOS has had the idea that more than just text editors exist for many years.

Reply on news.ycombinator.com