Instead of every tool making its own incompatible, undocumented, non-standard config file/database/format/tools.
So the Registry is a great idea and great software design, but developers are "holding the phone wrong"?
I think applications should be standalone and not tied into some giant central spaghetti shared knot of chewing gum.
The beauty of Linux/Unix is that stuff is configured by text files. Windows was on that path i the early days when everything was configured with ini files before someone had the idea of introducing the registry.
A central configuration database with standard ways of accessing it, doubling as an early 'service-discovery' place (e.g. registration of COM components), with system-wide config and per-user hives loaded when needed, is a great idea, and the registry is tolerably good software design as a way to do that, considering it came from the early 1990s, but developers have carelessly misused it for years, and Microsoft take the blame for that.
Imagine you logged onto a server by SSH and your /home/.program/program.conf file is from a newer version and the program doesn't run. Nobody would attack "the concept of storing configuration in a text file" for that - but people would attack "the registry" when that equivalent happens on Windows.
How many times have people written scripts to "parse" and add/remove lines of config from text files, without ever saying "we're reinventing the wheel for the hundred thousandth time, what a miserable waste of human life, if only there was a standardised key/value store we could put data in with a standard tool"?
And I put "parse" in scare-quotes because how many actually implement a full and correct Apache/Bind/iptables/etc config file parser, instead of a quick regex/sed/AWK/Python hack? JSON changed this a little, but now you'd easily expect to configure a server/service using a REST interface, and the config would be persisted in some unknown not-user-facing database behind the scenes, and that's just "fine".
I thought it meant blaming the user for the flawed design.
> your /home/.program/program.conf file is from a newer version and the program doesn't run.
But a problem in program.conf would sabotage the program, not the entire system. Whereas a bad registry can stop you from booting. That is the main problem.
A real unix equivalent could maybe be a problem with something in /etc, but that stuff is supposed to be 1) set to basic defaults that will work in any circumstance, and 2) kept under lock and key. Whereas the Registry was born as a free-for-all, and only much later got a permission system retrofitted on top.
Was the Registry a good idea? Maybe; but it certainly had a terrible execution, and now we're stuck with the results.
> if only there was a standardised key/value store
Yes, if only - but there isn't, the Registry is Windows-only. That's why developers end up managing text files: because they work everywhere, in 1995 as in 2019; whereas APIs come and go.
> But a problem in program.conf would sabotage the program, not the entire system. Whereas a bad registry can stop you from booting. That is the main problem.
A bad user hive stored on a network drive, can stop a terminal server from booting? Can it? That's the comparison with /home/.program/program.conf that you're replying to.
> A real unix equivalent could maybe be a problem with something in /etc, but that stuff is supposed to be 1) set to basic defaults that will work in any circumstance
Like a kind of "safe mode" that can boot after something has screwed up the registry?
> That's why developers end up managing text files: because they work everywhere, in 1995 as in 2019; whereas APIs come and go.
Yeah, I've never had to fix character encoding issues in text files, or line ending, or newline at end of file, or escaping or quoting issues in text files, because they're all the same and never cause any problems. Microsoft APIs from years ago still work.
Indeed, at that was a major mistake. Multi-user systems had existed for 20 years, Windows 95 was a huge step back.
> I hazard a guess that with NT4 and Windows 2000, the user hive was unlikely to be able to crash your system
... you wish.
> A bad user hive stored on a network drive, can stop a terminal server from booting?
Maybe, I honestly have no idea - I've only seen it happening locally. I wouldn't put anything past registry corruption anyway.
> Like a kind of "safe mode" that can boot after something has screwed up the registry?
Access to Safe mode requires hardware action at boot. The worst you can get from a userland program in unix failing on logon is that you have to log on via shell.
> Yeah, I've never had to fix character encoding issues in text files
The difference is that you can fix all that yourself, with a shell and an editor, whereas if Windows says the registry is borked, the registry is borked and you have no recourse.
Single-user systems had existed for longer. They were dominant at the time especially on small systems - many variants of DOS, Windows 3.1, OS/2 up to version 3, Apple MacOS up to version 8, Amiga, Acorn, Atari, every console, every 8-bit micro, Symbolics Genera[1], BeOS pretended to be single-user. The days of a central computer with tons of connected terminals requiring multi-user auditing, separation, and billing - were fading. Individual computers were becoming cheaper, the internet hadn't risen. Looking back with hindsight of how things turned out, and saying "huge step back" when it was not a step back at the time, it was a step forward from Win 3.1 in many ways and a step sideways in that way, seems weird.
We still have not-multi-user systems now, for embedded devices and mobiles and similar. If it wasn't for network effects, it ought to be possible to make a single-user OS which was simpler and therefore faster and cheaper, and I bet it would be good enough for much of the computing done on the planet today - the amount of personal computers where multiple people need to logon, compared to the amount where you just want random people not to be able to poke at it without permission. Although totally not worth doing these days.
[1] http://www.bitsavers.org/pdf/symbolics/software/genera_8/Ope... page 12, last paragraph.
> ... you wish.
You started this bit by saying "once you give third parties control of the stability of your system, you lose". That happens if you give root access to anyone, on any platform. That happens in Windows 95, but the registry had system/user separation since Windows 2000. So that's 5 years without, vs 20 years with.
Yes I wish it was without problems, and that it had some more standard offline edit ability, but I don't think "userland can crash the system" was a design plan for the registry, so I don't judge it as bad design because of that.
cough dconf cough
Some apps are non-conforming, and store data elsewhere, but as a general model I think it works very well.
On macOS, the registry equivalent is all the plist files stored in ~/Library/Preferences and ~/Library/Application Support. These just get left behind when the .app is deleted.
Early macOS used the installer system, which still exists but is increasingly rare. You'll notice it because the installer has the .pkg extension. The installer writes "receipts" to a special folder, which contains all the files it created, which in principle should help you unininstall. In practice, this doesn't work well, either, because apps litter the file system with files after they're installed.
Apple encourages the use of sandboxing for new apps. You'll find that apps each get a root under ~/Library/Containers. This means you can wipe all of an app's data in one go; as I understand it, sandboxed apps have to explicitly request access to any files they need to access outside of their container.
With APFS they could go even further and give each app their own volume, I suspect.
But most apps aren't yet sandboxed, so we still have file systems polluted with stuff.