Live data from Hacker News

Why the Windows Registry sucks technically (2010)

rwmj.wordpress.com

41–50 of 342 posts

Re: Why the Windows Registry sucks technically (2010)

#41
post #20

> This is a far cry from /etc/progname.conf in Linux. Some of these arguments are not really in good faith. First, this isn't a technical issue with the registry, but with how it's been used over the years and never "refactored" - a distinct issue. Second, I dare you to run "ls /etc" and claim it's not a mess... Besides, most of the post is how anyone with a text editor and admin rights can bork/hack the machine. As…

> Second, I dare you to run "ls /etc" and claim it's not a mess...

In unix man my.conf will work for most sane programs.

Re: Why the Windows Registry sucks technically (2010)

#42
post #14

>Hello Microsoft programmers, a memory dump is not a file format Wait until you see the Office formats without the extra x in the extension.

That was a deliberate attempt to make it impossible for competitors to read and write their format wasn’t it?

In the era that these formats were started it was fairly commmon to treat your file format as a dump of memory. It wasn't about preventing competitors from reading it. It was more about the speed of loading it and the lower overhead.

This was before the landscaped had changed so much that the security implications of a format you didn't parse before loading it and the hardware landscape had changed so much that there was no longer a detectable performance hit on parsing a format before loading it.

You had interchange formats which were designed to be used between systems and had a defined parseable formats but if your format was meant to be used by you system alone and not shared then it was believed that a memory dump was strictly faster and better for the the user experience.

We've since learned a whole about why that is not a good idea but it wasn't always obvious in the before times.

Re: Why the Windows Registry sucks technically (2010)

#43

Earlier quoted context omitted.

The problem of removing applications together with their configurations is trivially solved in the various Linux-based systems where any software package is installed only inside a private directory. Any files that would be expected to be in shared directories like /usr/bin, /usr/lib or /etc, are replaced by symbolic links. Except for symbolic links, the installation of a package must not change anything outside its…

>the various Linux-based systems where any software package is installed only inside a private directory Which are these? I assume Qubes OS sidesteps the problem entirely... NixOS?

NixOS, mostly, but not for application data (/var usually), which is closer to the registry.

Re: Why the Windows Registry sucks technically (2010)

#44
post #20

> This is a far cry from /etc/progname.conf in Linux. Some of these arguments are not really in good faith. First, this isn't a technical issue with the registry, but with how it's been used over the years and never "refactored" - a distinct issue. Second, I dare you to run "ls /etc" and claim it's not a mess... Besides, most of the post is how anyone with a text editor and admin rights can bork/hack the machine. As…

> Second, I dare you to run "ls /etc" and claim it's not a mess...

In principle, sure. But in practice, using /etc to edit configuration data is not that hard, and every Linux user does it all the time. Different software uses different configuration formats, sure (though it's worth nothing that NixOS is doing really clever things to solve that problem), but it's really not that hard or scary.

Manually editing the registry though... That way lies madness. It's much scarier and it's much more fragile.

Re: Why the Windows Registry sucks technically (2010)

#45
post #20

> This is a far cry from /etc/progname.conf in Linux. Some of these arguments are not really in good faith. First, this isn't a technical issue with the registry, but with how it's been used over the years and never "refactored" - a distinct issue. Second, I dare you to run "ls /etc" and claim it's not a mess... Besides, most of the post is how anyone with a text editor and admin rights can bork/hack the machine. As…

I mean, yeah - /etc is messy. Every configuration file in /etc has yet another bespoke configuration language. And somewhere on your system lies a corresponding buggy, half implemented parser for it.

But /etc has gotten messy in the same way a desk gets messy. There's documents everywhere, but if you pick anything up and take a look at it, you can usually (with the help of google) figure out what that file does and how you can change it. It helps that almost every file in /etc is owned by a single program or library. And just about all of those programs have documentation. (Or, at worst, source code).

In comparison, the windows registry feels like an old, disorganized community's storage space. On first glance things look organized, but actually there's been dozens of half hearted attempts to organize everything over the years by different people, each with their own idea of where everything should go. You don't recognise half the stuff in there. Random ex-employees have been dumping random objects in there for years. But its impossible to tell at a glance what random objects are critically important, and what is trash. Everyone else has this problem too, so nobody throws anything out, and its just accreted.

Braver people than you have fallen on their swords trying to tame the windows registry. There be dragons.

I'd take /etc over the windows registry any day of the week. /etc is messy at the surface level. The windows registry is messy like a fractal.

Re: Why the Windows Registry sucks technically (2010)

#47
post #22

Earlier quoted context omitted.

> The UNIX way is undeniably more flexible since it isn't a virtual filesystem, it is just a filesystem. Unix simply doesn't have a "way" in that regard, other than a loose convention to put text files in "/etc". Every application comes up with its own format. Parsing that file is application-specific. Updating a value in a text file means re-writing the whole file again. It is a technically-inferior approach that ha…

Modern Linux DEs have an arguably worse version by not only having traditional `/etc` for some types of configurations but _also_ having a "registry" that's really similar to the Windows one for GUI apps... (re: gconf for Gnome)

Is Gconf any different from OSX defaults?

Re: Why the Windows Registry sucks technically (2010)

#48
post #39

A point being overlooked by article and commenters: the records in the registry probably use in the order of 10-100 bytes each, while every actual file takes up at least around 1024 (EDIT: maybe more like 4096?) bytes. Putting tiny 'files' into a special format is a no-brainer on the older computers that existed when the Registry was first created. I am assuming this was one of the motivations to create the Registry…

Good perspective. It’s easy to lose track of that as enough time has passed that the parents of commenters were in high school when this was implemented.

One time perspective thing to keep in mind is that the IBM mainframe was younger to the folks doing this work at Microsoft than we are to the Microsoft people today. Their constraints were different and the diversity of end users was very different.

Even with years of experience and advancement, in Linux we moved configuration to systemd, which is exponentially better than the registry but also more complex. Complicated configuration systems will always have pros and cons.

Re: Why the Windows Registry sucks technically (2010)

#49
post #24

Earlier quoted context omitted.

Is there any "way" at all that doesn't suck though? Not having "a way" in this sense is more like a feature, a single source of truth works well if it really is treated as such by all actors. Configurations under unix are a mixture of stdin, config files, env variables and bespoke solutions. Under Windows, you have all of the above and on top of that the registry. Any attempt at a solution in this regard risks being…

On a more philosophical level, the Unix convention is the "liberal" one, giving application writers more freedoms. Liberty enables more flexible applications and more chaos at the same time. A highly structured approach might be beneficial in the short run, but it might prove to be burdening beyond its due date.

Its partly about where burden is placed. Making it easy for developers sometimes makes it hard on users and admins. And some times it becomes security issue because of varied approaches. Not sure there is right answer especially in open source where its hard to get devs.

Re: Why the Windows Registry sucks technically (2010)

#50

I really appreciate when people use technical facts to criticize something, like with this. It is a well written take-down of the implementation of the Windows Registry as of both today and 2010. I suspect if the concept of the registry was created today it would look more like a database (e.g. Sqlite), although organizing it like a virtual FileSystem does have a certain appeal, and unfortunately I don't know of a da…

> The UNIX way is undeniably more flexible since it isn't a virtual filesystem, it is just a filesystem. Unix simply doesn't have a "way" in that regard, other than a loose convention to put text files in "/etc". Every application comes up with its own format. Parsing that file is application-specific. Updating a value in a text file means re-writing the whole file again. It is a technically-inferior approach that ha…

> Updating a value in a text file means re-writing the whole file again. It is a technically-inferior approach that has survived in time because text files are still text files.

It always seems like registries are trying to solve three different problems: configuration, status and process shared state. Registries seem to work poorly compared to text files for configuration, and work somewhat well for some level of shared state. I think to compare functionality with Linux, you would have to compare /etc, .configs and the /proc filesystem.

As for tecnically inferior, the *ix approach seems to have made the right tradeoffs, via the hand of Darwin, rather than some brilliant engineering insight. The article did a good job of explaining what's wrong with Windows' implementation of the registry. What is right with the *ix approach is that configuration files are usually read on startup, and only written to when configuration is changed (which should be infrequent). This works really well for server software, command line utilities, and an awful lot of GUI software. For some GUI software, particularly where you have really complex feature sets, we need to save state of widgets (i.e. saving the default zoom level) and text files may be problematic for this (i.e two instances of the app running), and this is where the registry really shines.

Post reply on HN