Live data from Hacker News

Why the Windows Registry sucks technically (2010)

rwmj.wordpress.com

211–220 of 342 posts

Re: Why the Windows Registry sucks technically (2010)

#211
post #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.

That's what I'm describing as a reaction at the time even if it didn't turn out to be a big deal.

I'm a long time Linux guy and when I heard about systemd, the first thing it made me think of offhand was the Windows Registry. Now I'm not super-deep on that level of Linux but I could understand the knee-jerk reaction at the time. But you're correct technically, and I think time has proven that there's not much of an issue.

Re: Why the Windows Registry sucks technically (2010)

#212
post #210

Earlier quoted context omitted.

General Linux tools built for text, in a world where everything is plain text and the shell doesn't know how to navigate anything other than a file system. In PowerShell you can cd into HKEY_LOCAL_MACHINE as easily as any drive, and Select-String is perfectly capable of searching registry keys. The baseline is only text and files on systems that don't have anything better to offer.

Isnt there FuseFS for that? It can show the gconf registry as a file tree, allowing you to use tools like recursive diff etc. https://metacpan.org/release/LSIM/GConf-FS-0.01 Something flexible like FuseFS is sorely missing on windows, the stuff google drive had to do creating a new letter drive is pretty gnarly.

You mean https://docs.microsoft.com/en-us/windows/win32/projfs/projec...?

Re: Why the Windows Registry sucks technically (2010)

#213
The registry is not a DB or filesystem it is the registry. My main gripe with the post is it keeps comparing it to Unix things.

It is a place to "register" state and configuration to allow other programs and the admin to manipulate that value or make decisions based on it. Not everything hierarchial is a filesystem and while you can argue it is a db, if it is then it is a very specific purpose built key/value storage db.

I won't dissect the post and respond but the registry structure is not a mess, it is well known and different places have different permissions and purpose.

Re: Why the Windows Registry sucks technically (2010)

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

Users can not write to /etc, those programs like passwd can because they have the suid bit on and run as root regardless of which user initiated the process.

Re: Why the Windows Registry sucks technically (2010)

#215

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…

You could do the paths in reverse (root last), to speed up any string comparisons, since prefix almost always matches and is maybe more wasted work the other way.

Re: Why the Windows Registry sucks technically (2010)

#216

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 concept of a system-wide hierarchical key-value store is actually very useful is some environments. I had to develop one some time ago [1] for an embedded system, since is super useful to have a single point of truth/configuration/state, if every application agrees on using it (which is the case in such systems were every application is known in advance and developed in house)

[1] https://github.com/debevv/camellia

Re: Why the Windows Registry sucks technically (2010)

#217
post #205

Earlier quoted context omitted.

Most Linux GUI apps either litter your home folder with dotfiles, dotfolders (both disgusting) or they follow XDG Base Directory specifications and place configurations in ${XDG_CONFIG_HOME:-${HOME}/.config}

I don't mind dot files or dot folders, but I'm very open to better ideas. My app works on Mac, Linux, and Windows though. Any thoughts?

There are several libraries that handle directory for you in the appropriate OS-specific manner.

One Rust example being https://github.com/dirs-dev/dirs-rs

> The library provides the location of these directories by leveraging the mechanisms defined by

> the XDG base directory and the XDG user directory specifications on Linux and Redox

> the Known Folder API on Windows

> the Standard Directories guidelines on macOS

Re: Why the Windows Registry sucks technically (2010)

#218
I think articles like these miss the point that Microsoft's stuff is not intended to be designed in a predictable way. Their goal, above all else, is to protect their monopoly. Making things convoluted, unpredictable, and undocumented is just one way of doing that. Silently failing, and non-specific error messages are another.

Re: Why the Windows Registry sucks technically (2010)

#219

Earlier quoted context omitted.

> Unix simply doesn't have a "way" in that regard, other than a loose convention to put text files in "/etc". So? The registry doesn't have much of a way either - the actual fields are simply a loose convention. > Every application comes up with its own format. Same with Windows applications - one application might store an IP address as a dotted-octet string, another might store it as a single 32 bit integer. > Pars…

> the actual fields are simply a loose convention. Let alone some windows program end up just save a blob in it and totally ignore the typing. Who care about the field type if I can save everything in a single blob(?

Even Microsoft likes to save blobs.

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\BrowserEmulation\ClearableListData]\UserFilter

Re: Why the Windows Registry sucks technically (2010)

#220

Earlier quoted context omitted.

>> The Registry binary format has all the aspects of a filesystem: things corresponding to directories, inodes, extended attributes etc. > Like? Always thought it was an hierarchical database. A filesystem is a hierarchical database.

I probably miss something then. The article also states that it is not a database.

It’s not a relational database is probably what they meant.
Post reply on HN