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.

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.

We're just suffering from backyards compatibility for things made over 30-years ago.

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.

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!

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

I get that the actual ugly details are hidden away behind automation in the form of the special dsl and highly specified framework/structure, and maybe sane enough to use, and maybe adresses some pain point or two better than other arrangements.

Just remarking that I've seen 'everything is a symlink' before, and it's the exact opposite of a new idea.

Whether that means nix shares a bad idea with another bad system or this was one of the good ideas from an arguably successful system (for a time) I won't try to say.

https://gobolinux.org/at_a_glance.html

It's still useful for a fleet of clients and servers in an enterprise environment though.

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

Especially when there's some corporate "security" software in the loop. And that's the case you have to really code against.

Besides, registry is not a rocket even on a clean system.

Also note that performance isn't just speed either.

First... where are you getting this from? I just spent half an hour writing a an incredibly simple benchmark and all I see is SQLite being something like 20x slower than a registry query, seemingly caused by repeated locking & I/O system calls. This is on a trivial database with just 1 table with just 1 row, vs. a registry that's on a machine that's been running for years. If you have a benchmark that can disable the locking and get comparable performance, I'd love to see it. Not that it would mean anything though, given the next point.

Second, even if it were somehow faster... you'd be comparing apples to oranges. The registry has a bunch of things SQLite isn't designed for: security integration with the rest of the OS, a hierarchical structure, OS hooks for monitoring & interception, multithreaded access, etc. Have you tried doing these with SQLite before praising how fast it is?

> That said, on Windows you kinda have to use registry, especially on the kernel driver level.

Is it common for drivers to use SQLite to store configuration information in any OS? I dare say I've never seen this.

It's not. You're going to use your assigned registry hive for it.

I think it's silly to compare the two.

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.

nix solves this

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.

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.

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.

Some files in /etc have manpages.

[1] https://github.com/mity/old-new-win32api#registry

A lot of the horror stories came from earlier versions of Windows which had problems with reliability.

If you spend time as a Windows sysadmin you can start to appreciate it, because it does make certain administration tasks easier. Like “I need to change 10 registry different keys on 50 different machines” is easier on Windows. On Linux, I’d do the same with, like, Ansible scripts which can be a lot more error-prone to write.

I thought ReFS was a failure. /s

Now imagine this database is not a great engineering product like SQLite but really, really REALLY fucking sucks at being database, and slows down quickly with sizing up.

Now imagine there is no sensible way to get obsolete data out of it, and as every program uses same file it just gathers, and gathers, and gathers...

This is over 20-years out of date.

Or, from the contrary perspective: it’s the 500 places config lives on Linux, but in one place instead.

(Except it still has a deep hierarchical structure, so that second one is kiiiinda not entirely true, in that you can run into exactly the same issues as scattered config files on Linux)

Editing, sure, you've got essentially a single GUI application and CLI or programmatic access. Your options are certainly more limited than the plethora of text editors available.

You can export a registry path as a text file, make changes in perferred editor, then import it again. It's annoying but I've done it before when needed.

    PS> cd HKLM:\Software\Microsoft\Windows\CurrentVersion
    PS> ls
    [...bunch of stuff...]
    PS> gp Themes DesktopBackground
    DesktopBackground : c:\windows\web\wallpaper\[...default system wallpaper...]

Pwsh is pretty neat in that regard. Besides the actual filesystems drives, many systems have "providers" that allow you to treat their objects as files: the registry, environment variables, the functions defined in your session, the variables, the aliases... Unix's "everything is a file" became "everything is an item".

* a uncorrupted registry hive is supposed to be Directed Acyclic Graph, (while a modern filesystem can have arbitrary cycles with symlinks and bind mounts and junctions) and;

* the registry has more limited name length limits, even assuming Windows somewhat low filesystem name length limits.

The Windows Registry is the NT Kernel's system config/preference store. The closest Linux equivalent is dconf. Like dconf it is built to be a read-mostly/read-optimized database. It's not as strongly focused on a service-bus architecture as dconf. It tries to heavily optimize for an MRU on-disk order (somewhat like redis) and optimize for strong write consistency (unlike redis which is happy to do more in memory between flushes to disk). Any writes at all generally thrash the Registry "hive" database files some. Heavy amounts of writes will murder it. It was optimized for reading not writing.

The Registry was side-ported to Windows 95 from the NT Kernel, in part because COM (it became the central spot for registering COM components), and a lot of mistakes were made in the messaging about it. It was intended to be Kernel-focused and mostly never used by user-space applications. That unfortunately wasn't made clear enough, and needing to register COM components in it certainly muddied the message. So Windows apps have a long history of storing a lot of things to the registry, much of which they should probably use user config files for.

> Can't you store stuff alongside the install? Or in some user data location?

In Windows due to a complicated dance with anti-malware efforts and secure binary memory mapping it is generally frowned upon to store stuff alongside installs (in the %ProgramFiles% or %ProgramFiles(x86)% directories). Many programs (especially well written ones) don't even have write permissions at all to their install folder (similar to how many distros lock down /bin and sometimes /usr/bin and/or /usr/local/bin to superuser accounts only). For backwards compatibility reasons with applications dating all the way back to Windows 95 some app installer are allowed to still re-ACL their install directory to give back write permissions to the application. Also, in modern Windows (since Vista), depending on a number of factors Windows will actually lightly sandbox the app when that occurs and redirect ACL changes and writes to an "overlay" directory, allowing the app to believe that it still is writing to its own install directory but it is actually writing to a machine or user directory outside of %ProgramFiles%.

On the other hand there are plenty of user folders available for config storage: Generally the suggestion is %AppData% for most such files. (This is the "Roaming" app data that may be automatically copied to other machines for some users on some networks, mostly enterprise/corporate accounts/users.) Some apps may prefer %LocalAppData% which doesn't roam for larger config files or more machine-specific transient things (like window positions or caches). It's also common enough to see cross-platform apps use Unix-style dotfiles under %Home% and even sometimes XDG-style dotfiles under %Home%/.config/. That's not generally recommend and especially because of roaming behaviors the general preference is to use the appropriate %AppData% or %LocalAppData% and avoid cluttering %Home%. Though many Windows users don't even really use or see %Home% for a variety of interesting reasons, so its not entirely frowned upon as wrong. (Unlike storing config files under %Documents%, an ancient mistake of many Windows apps not as terrible as storing things in the Registry they shouldn't, but more visibly obnoxious to Windows users that want tidy Documents folders and feel that folder should be entirely user-controlled.)

Also, there is a machine-wide config location, somewhat akin to /etc, named %ProgramData%.

One of the things that made a work computer more complicated than it needed to be was that part of the network setup redirected %Home% some of the time to a network drive (Z:) (a "Home" drive) and other times %Home% was still on the default drive in the default user folder location. I'd constantly have to copy files like npm's .npmrc from one folder to the other to make sure that every use of npm found a right copy of .npmrc.

That "home drive" setup is a relatively common in my experience ancient Windows corporate hack for hand roaming some user files (sometimes including %Documents% which was likely the real intent but %Home% used to be easier to redirect than just %Documents%), so there is a sense of irony in some tools using %Home% as a non-roaming storage only to have it haphazardly roam due to some ancient corporate policy. It's also funny that it is possible for there to be two %Home% folders on Windows in competing locations with different contents, because the %Home% redirect seems buggy.

I think part of it is that there is a growing sense on Windows that %Home% is for "non-roaming, developers might to text edit this" configuration and %AppData% is for more UI-driven config that is less expected to be edited. A lot of developers learn %AppData% just fine, but there is some cross-platform convenience for developer life if you can always in PowerShell (or bash) just vim `~\.somercfile` and expect that to always work. But I still think using %AppData% more consistently is possibly a better thing for Windows apps to do.

It has a "hive" which is part of the user profile. User preferences are stored there ("HKEY_CURRENT_USER").

System-wide preferences are stored in a "hive" for system apps ("HKEY_LOCAL_MACHINE").

It allows applications to mix and match system-wide stuff with user-specific stuff, which only differs by which "hive" it wants to query against. It has several data types for different types of records. There's conventions for how to store things (although apps can do whatever they want), so apps usually store their state and config data under HKLM\SOFTWARE\MyCompany\MyApp for system-wide stuff, and user specific stuff will live under HKCR\SOFTWARE\MyCompany\MyApp.

All in all, my experience has been that on average its usage is a bit more standardized than config files. Of course on windows, apps (particularly C# apps) ship both with config files and a boatload of registry entries.

Lastly - by design, HKCR (the user profile hive) is assumed to sometimes have orphaned data. If a program is installed per-user, and you uninstall it as a different admin user than who installed it, the other user profiles cannot be loaded and modified by the installers thereby orphaning any other user data.

I could be blowing smoke, but this has always been my thinking. An old joke: Registry was derived from the Latin word registratum, which means "put all your eggs in one basket".