I don’t think the registry is a good idea. I don’t mind every program having its own dialect of a configuration language, all under the /etc tree. If you think about it, the /etc tree is just a hierarchical key-value store implemented as files where the persistent format of the leaf node is left to its implementer to decide.
> If you think about it, the /etc tree is just a hierarchical key-value store
Well, you're in luck, I have good news for you -- Windows also has its own version of this concept: it's called "The Registry". You might have heard of it?
The registry would have been better if there were a stronger concept of "ownership" of the data it contains, tying each key to the responsible app / subsystem. I've tracked hundreds of software uninstalls and I would bet only about 1% of them actually remove all the cruft they originally stick in (or populated during use). The result is bloat, a larger surface area for corruption, and system slowdown.
Ironically in this respect it was a step backward... When settings lived in INI files, convention typically kept them in the same place as the program, so they were easy to find and were naturally extinguished when you deleted the software.
If you look at more modern OS's like Android and iOS they tend to enforce more explicit ties between apps and their data.
This is often touted as a downside for the registry, and indeed a whole ecosystem of apps have evolved around this concept to 'clean' the registry and 'speed it up'.
In my experience of 35 years of using windows, I have never noticed a bloated registry slowing down a computer. I have also never noticed a speed up of the system by removing some unused keys. The whole point of addresses and key pairs is that individual bits of data can be written or read without loading the whole hive.
I wonder where this idea of a bloated slow registry came from?
Since the registry is a database, I would expect adding and removing branches and leaves would create fragmentation that, in the age of spinning metal and memory pressure, could create performance issues. A file system is easily defragmenters with tools available in the operating system itself, but not the registry. I’m not even sure how much of it can be optimised (by doing garbage collection and defragmenting the underlying files) with the computer running.
If it makes use of indexes, changes will lead to the indexes themselves being fragmented, making performance even worse.
The registry was capable of being compacted, negating the need to defragment it. This was done via the standard Windows Backup utility provided OOTB.
As for performance, the registry was mapped in paged pool memory[0]; only sections in-use needed to be mapped. Other hives were volatile and never persisted to disk. When data is added to the registry, the paged pool expands to accommodate. Maximum registry size is based off of installed memory, up to a limit.
Registry subkeys are organized alphabetically in an internal list; searches are binary searches rather than using an index. Searches begin in the middle of the list and go up or down based upon the alphabetical value being searched for (so start at 50% -> up/down, split remaining list 50%, up/down -> repeat until found).
You can find more info in Chapter 4 of Windows Internals 4th Edition.
Needless to say, none of the concerns you presented were valid back in the dark days.
Anecdotally I've experienced several PC's that became slow/unstable/unusable after a number of years. I can't scientifically prove it was due to the registry (other than a couple that had specific corruption).
But after I started using Total Uninstall religiously, from day 1 of a PC's life, my desktops have lasted indefinitely - going on 15 years for the latest one (yes, really). Hardware was of course upgraded along the way, making old driver removal paramount (which TU is very helpful with).
Analyzing it's logs after a software installation has also been helpful to spot and surgically remove unwanted keys like autostarts, Explorer addins, etc.
Using Windows Installer, this is easily accomplished. The Msi database _does_ track individual files and registry entries. If you're using another installer, or the developer allows their app to write something somewhere that isn't tracked by their installer, you're going to get files left behind.
macOS is especially bad in this respect. Bundles are great, until you have a ~/Library full of files that you never knew about after running an application.
On any Unix I can grep my way into the /etc tree and find files belonging to uninstalled applications and get rid of them myself. The whole point is that I can manage the “configuration database” with the same tools I manage a filesystem. That if the brilliant tools like apt and dnf fail to clean up after a program is uninstalled.
It was introduced with Windows PowerShell 1.0[0]. A text editor would need to directly support managing the registry, but you can read/write/search/do terminally-stuff to the registry via PowerShell.
The term we're looking for is a PSProvider of which there are many. There's even a PSProvider for SharePoint Online[2].
I still like the idea that I think you originally had, whereby apps could only write to their own specific area, thus containing all their configuration. I think that would solve 99% of all complaints about the registry.
Right now, they can write to anywhere your user has access to.
What happens if you have an extensible app, say Microsoft Office, which enumerated it's own subkeys to discover 3rd party plugins?
What if an app provides COM services and needs to write that to a centralized location that is enumerated to discover available COM services?
What if your app happens to be a god-awful HP Print Center app with it's own print drivers and a Windows Service, where it needs to write to a central location that is enumerated for device drivers and Windows Services?
> What happens if you have an extensible app, say Microsoft Office, which enumerated it's own subkeys to discover 3rd party plugins?
Then you have Microsoft Office/Plug-Ins/plugin-guid, whereby Plug-Ins is user writable
> What if an app provides COM services and needs to write that to a centralized location that is enumerated to discover available COM services?
If it is providing services it can write, if it enumerates it can read. You can also have multiple levels, like HKLM (machine) and HKLU (the user).
> What if your app happens to be a god-awful HP Print Center app with it's own print drivers and a Windows Service, where it needs to write to a central location that is enumerated for device drivers and Windows Services?
May God help you. No, but you would have, again like above, a central location you could write to. Up to the Admin if Joe can write to this location or only privileged processes.
It's just, a lot of this was not enforced, only partially (from the windows side when it looks for things), so for everyone else, it's a free for all.
The biggest disadvantage on the Linux side is that something like Group Policy is ridiculously difficult, because every app has it's own location and DSL, and sometimes you have one, central, config file, and sometimes the app is considerate with something like override.d.
1) Office should "own" those keys, and provide a UI to manage its addins. When Office is removed, so is that chunk of registry.
2) COM discovery wasn't particularly well designed in the first place, IMO. It's a perfect example of where the keys should be explicitly tied to the owner (ie. the COM provider) so they are removed when the component is uninstalled. So many programs leave reams of COM-related entries behind, this is table stakes for all those free (and IMO not very useful) registry cleaners.
In both your second and third examples, the OS could either:
a) Provide specific API's (printing is a fairly common service where it makes sense to have a lot of shared functionality hosted in the OS).
b) Designate well-known locations where apps can share access to keys. This is loosely the case today, but I argue the OS could do more to make them explicit and maintain ownership ties so the relevant ones are automatically removed when appropriate (I think Windows Store moved in that direction??).
c) Require one app to own and gatekeep the centralized information, and provide simple primitives that allow the other apps to interact with it to register/unregister themselves. The expectation is the owning app actually manages said information (hopefully providing some sort of UI) but at least when it's removed so will all the contained info.
The important thing is that ownership policies are maintained so when a driver / COM service / etc. are removed their cruft goes away along with them. I recognize there are edge cases but I'm not convinced they can't be solved in a generalized, well-thought-out fashion.
Personally I don't feel an app's storage needs to be completely isolated as is done in Android (a security/extensibility tradeoff).
A lot of this housekeeping comes down to an OS maker providing out-of-the-box tooling to developers, along with sensible defaults, that make following good habits natural and friction-free.
Microsoft in particular provided tools and documentation since the early days, but relied too much on developers to follow them and didn't do enough to make it "just work" for the lazy ones.
Then over the years they changed their minds several times along the way, so convention became a sometimes-conflicting spaghetti mess.
> only about 1% of them actually remove all the cruft they originally stick in (or populated during use). The result is bloat, a larger surface area for corruption, and system slowdown.
I think this is a myth partly spread by commercial offerings that want to 'clean and optimize' a windows install.
Most of the cruft left in the registry is the equivalent of config files in /etc not removed after uninstalling an app. That stuff isn't affecting performance.
15 something years ago I had this unpleasant job where I had to install a major vendor's database on Windows server machines. I remember I also had a lengthy list of things to check and clean in the registry to make sure things work.
Yes, these are configs. And no, we cannot just let applications do whatever they want in the shared config space without a way to trace things back to the original app.
At least in the Linux world I was able to just check what the distro scripts installed.
> And no, we cannot just let applications do whatever they want in the shared config space without a way to trace things back to the original app.
We don't have to let them, but we do for the most part. We could use sandboxing technology to isolate and/or log, but mostly OSs don't do anything to restrict what an executable can do by default, at least as far as installing.
> At least in the Linux world I was able to just check what the distro scripts installed.
You can do this in Windows too sometimes, but it doesn't matter if it's a badly behaving app. There are linux installers that are just binary blobs and it would be a lot more work to monitor what they do also.
>but mostly OSs don't do anything to restrict what an executable can do by default, at least as far as installing.
There is a very mature and very powerful system for this called Jails.
>There are linux installers that are just binary blobs and it would be a lot more work to monitor what they do also.
This is simply not true. If I want to monitor an app in it's entirety I can easily do so on most unixy systems.
Past the default tools that require some amount of systems knowledge to use correctly, you can easily just use Stow or Checkinstall (works on most linux systems).
There is no mechanism for doing this on Windows as even the OS loses track of it sometimes. And if you think I'm being dramatic, trust me, I am not. There is a reason the tools don't exist for Windows, at least meeting feature parity.
> There is a very mature and very powerful system for this called Jails.
No, jails aren't really the solution to the issue I'm talking about.
It's 'a' solution, but not the ideal solution.
> This is simply not true. If I want to monitor an app in it's entirety I can easily do so on most unixy systems.
It is true, but I think you're missing my point. If I wanted to monitor any app on Windows I can do the same, I just need procmon from sysinternals.
> There is no mechanism for doing this on Windows as even the OS loses track of it sometimes.
There is, in fact there are numerous solutions.
The point was simply that there can be hostile installers that you require tools to see what they are doing on both Linux an Windows. Linux isn't special in any way in this regard.
Maybe? What are you envisioning? Some sort of static analysis before a program runs? Explicit opt-in's to what a program needs, from the program itself (and only what it needs)?
I'm just talking about respect for convention. The same way on an FHS respecting distro a software should install to FHS paths and not, for example, make a new root level directory. There's a respect for user preferences there.
It's not about using technical means to restrict software, but about the OS providing certain mechanisms and there being an expectation for trusted software that it will respect those conventions.
That's why I don't consider a jail a solution. It's an extra step the user has to carry out, and I don't think the burden should be on the user if it doesn't have to be. While in one sense it's good security practice to treat every program as malware, most users are not going to do that nor should they have to.
A tool like Sandboxie on Windows solves that problem in one sense, but not the actual root of the problem, which is it being more acceptable than it should be to go against user preferences and convention.
And since it supports variable-lenght binary values, it fully supports that "the persistent format of the leaf node is left to its implementer to decide".
What exactly do I gain from the registry that compensates for the fact I can use any tool that works on files to manage the /etc tree?
Can you manage registry folders with Git and keep track of the changes you make? Can you grep for content? On a Mac it’s indexed by the systemwide text search tooling.
Using the file system to store that data is extremely powerful.
I have no issue with the concept, but in practice the Windows registry is a lot more obfuscated than it needs to be. There can be trees and trees of UUIDs or similar, and there is no need for it to be so user unfriendly.
Part of this might be mixing internal stuff that people never need to see with stuff that people will need to access.
That's a developer choice, not the registry in and of itself. You could just as easily have /etc filled files with GUIDs for file names.
Generally, 3rd party developers don't use a bunch of GUIDs for keys. Microsoft does for Windows components to map the internal object ID of whatever they're dealing with; my assumption is for ease of recognition/documentation on their side (and generally the assumption that the end user shouldn't be playing around in there).
> That's a developer choice, not the registry in and of itself. You could just as easily have /etc filled files with GUIDs for file names.
For sure, that's why I said I have no issue with the concept but rather how it's used in practice.
> Microsoft does for Windows components to map the internal object ID of whatever they're dealing with; my assumption is for ease of recognition/documentation on their side (and generally the assumption that the end user shouldn't be playing around in there).
That's maybe fair, but most of that stuff isn't stuff the user even needs to access most of the time. Maybe separating it out from all the HKLM and HKCU software trees would have made sense.
I don't really understand your point here. It would make perfect sense to have two separate hives by sectioning off all the stuff users, even power users actually need access to. 'specific ACLs' have no bearing on that.
Everyone says, oh /etc is fine, but no registry. But let's be honest, on a user workstation, /etc is only one of many places where config can be found.
Then it seems like the issue you have is how vendors are storing keys in the registry, not the registry itself. In your example, if nginx made a single node in the registry with all its keys under that then it would be just as easy to remove that single node as it would be to remove the single directory.
However in the real world it is never as simple as you suggest. Linux apps often litter the filesystem with data. an app might have files in /etc and /opt with shortcut scripts in /root/bin and /usr/sbin. Config files in /home and /usr directories. Linux file systems are just as littered as windows registries in my experience, if not worse because they differ in different distros.
I like what the elektra project was trying to do, but it didn't catch on. Basically put config into the filesystem with a standard schema, etc. Could use basic tools/permissions on it, rsync it, etc. Benefits of the registry but less prone to failure and no tools needed to be reinvented.
