Live data from Hacker News

Why the Windows Registry sucks technically (2010)

rwmj.wordpress.com

141–150 of 342 posts

Re: Why the Windows Registry sucks technically (2010)

#141

Windows 10 and 11 have moved away from the registry for applications. It's in C:\Users\ \AppData\Local\ for per-user information I haven't had to go into the registry on Windows 10 or 11 except for enabling beta/early access features.

>I haven't had to go into the registry on Windows 10 or 11 except for enabling beta/early access features.

I have to edit the registry on every Windows install to have: sane multi-monitor config, working macro keys (suppress the "office" key advertisement in my $300 copy of Windows), suppress OneDrive Personal on a machine that syncs to an O365 tenant, have a functional file explorer, and I'm sure a half-dozen other things that don't come to mind immediately. (On top of numerous group policies, which are mostly just sanctioned registry tweaks, along with programs to removed telemetry from 10/11 which I'm confident do plenty of registry tweaking on their own.)

This is all to control first-party functionality; before I've even installed a third party program. So, to the contrary, I can't remember the last time I went into %APPDATA% to tweak something Microsoft-related.

Re: Why the Windows Registry sucks technically (2010)

#142

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…

If I was to reimplement it, I would not let any app read the DB directly. Instead I would make an HTTP like interface where you talk to a service that provides the get/set functionality and which always use a text format like an extended JSON with native support for date, int32, etc. This also enabled much easier and better backwards compability as you can specify app-version in the requests, so a version 5 server ca…

All the aspects you mention can be realized by a programmatic OS API as well. No need to sandwich a network layer and a weakly-typed data format (JSON) in between.

Re: Why the Windows Registry sucks technically (2010)

#143
post #116
post #95

Earlier quoted context omitted.

> I can’t and shouldn’t be able to write to /etc as an ordinary or guest user. You're right, you shouldn't. If you are able to, your distro is very odd and I'd recommend seeking a new one. > Sounds like you’re just one of many anti-windows people, exactly what was pointed out about people bashing the registry. There's no need to attack people.

This is emphatically NOT true. If you absolutely could not write to /etc, then you would never be able to change your password. The passwd, chsh, chfn, and other utilities allow a non-privileged user to make controlled changes to privileged files via the setuid/gid system calls. A user can trigger controlled writes to files in /etc.

That's like saying you've broken RSA because you can cause controlled reads. All you have to do is send the encrypted message to the intended recipient and wait for them to decrypt it.

Re: Why the Windows Registry sucks technically (2010)

#144

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…

I hate this fanatical love of the UNIX way. I really hate that as of today Windows is the only non UNIX OS. I trully believe that this fact set us back. No more exciting new OSes only boring unix.

I agree on this. There may be better ways to do things, but people are so sure that UNIX perfected everything 50 years ago that the alternatives don't get explored. Personally I'm not convinced that plain text is naturally better than other options, because what even constitutes plain text? We have ways of encoding our languages into bits on a disk, but without a decoder it really doesn't have any meaning. So how is that different from any other way you can encode data? Isn't the important thing that we have tools that make it easy and consistent to work with the data?

Re: Why the Windows Registry sucks technically (2010)

#145

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…

Doing that in a database is easy. You just write your keys on the "/root/path/subpath" format, and search the strings starting with some text. Most database engines have this kind of search heavily optimized. (And the ones that don't cost hundreds of thousands per core, so who cares?) The one thing you lose by using a real database is that filesystems are only locally coherent, while databases try very hard to be glo…

Agreed, and displaying this like a tree is then a UI concern.

I think you'd get slightly more performance if you were to store "Folder" and "Key" separately -- either three fields or using a parent-child table. You'd be able to index "Folder", and it would make building the tree structure itself easier and more efficient, and looking up all the values in a specific tree simpler.

Re: Why the Windows Registry sucks technically (2010)

#146

Earlier quoted context omitted.

.config/ and .local/ are the de facto /etc for users, but there is the set of XDG_ environment variables that are intended to fill that role.

I'm pretty sure .local is the per-user /usr, and .config is /etc

You’re both correct; a fair number of applications put their configuration in ~/.local/share even though that wasn’t the intent.

Re: Why the Windows Registry sucks technically (2010)

#147

Earlier quoted context omitted.

The biggest issue with etc is that it's owned by root and therefore read only from the application's point of view. So, a great fit for sysadmin-managed configuration, not so great for applications that are GUI-configurable. You end up with a tiered approach of defaults in lib, and cascaded overrides in etc and var.

It's a great thing about etc. If your application `foobar` wants to write something to /etc and doesn't have root privileges (which it probably shouldn't), create a subdirectory /etc/foobar with owner `foobar:foober`, and write there all you want. Many applications do that and it works fine.

Strictly speaking /etc should be relatively static, and dynamic data should go into /var, so you (or the package installation) would create /var/lib/foobar with proper ownership.

Re: Why the Windows Registry sucks technically (2010)

#148

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…

> 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 database engine that supports such a layout.

(Open)LDAP uses a hierarchical structure and saves its data in a database:

* https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Databa...

* https://www.openldap.org/software/man.cgi?query=slapd-mdb

Re: Why the Windows Registry sucks technically (2010)

#149
post #89

Offhand, doesn't this kind of perfectly explain systemd fear? Probably what people had in the back of their heads.

(genuine question) What was the historical fear with systemd? That behaviors get hidden behind binaries rather than shell scripts? Has the fear been realized?

All systemd units can be edited easily, they're files in a filesystem. Journald logs are binary but journalctl gives you ways to output it.

Re: Why the Windows Registry sucks technically (2010)

#150
Why is a registry file called a "hive"?

> Because one of the original developers of Windows NT hated bees. So the developer who was responsible for the registry snuck in as many bee references as he could. A registry file is called a “hive”, and registry data are stored in “cells”, which is what honeycombs are made of.

Source: Raymond Chen, 2003: https://devblogs.microsoft.com/oldnewthing/20030808-00/?p=42...

Post reply on HN