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…
Why the Windows Registry sucks technically (2010)
131–140 of 342 posts
Re: Why the Windows Registry sucks technically (2010)
#132Earlier 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)
Re: Why the Windows Registry sucks technically (2010)
#133It is easy to be critical of Microsoft and many of their decisions until you reflect on the reality that they have provided the software that has been running billions of computers world-wide for almost four decades. And they have done this with an astounding level of software and hardware compatibility across time, devices and technologies. This is critical to understand before pointing at anything MS and being crit…
> And then imagine having to stay as true as possible to that rule for 40 years. And then imagine that most of your original decisions were poor ones, you won your position by virtue of being an abusive monopoly, and as a result, the majority of the desktop world has been needlessly suffering under the burden of your poor technical decisions for 40 years.
The slow boot and shutdown times, and the interminable upgrades are almost inhuman.
It seems like you can upgrade Ubuntu to a new major version faster than Windows can install a month's worth of fixes.
Especially when the Windows updates are unannounced and suddenly it's going to take 30 minutes to leave your desk instead of 30 seconds.
Re: Why the Windows Registry sucks technically (2010)
#134Earlier 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.
Since we're talking about Linux, I would refrain from using absolute clauses like "never".
systemd-homed allows you to create "portable" user profiles which contain everything pertaining to a particular user, including his password. So user profiles (including your files, etc) can be moved between computers simply by rsync'ing that directory, or putting it on a network share.
`homectl passwd` (which changes a portable user's password) does not require writable /etc.
I think I've seen a few other solutions like that.
Re: Why the Windows Registry sucks technically (2010)
#135I 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…
It's tooling created for security and forensics that tries to manually read it.
Re: Why the Windows Registry sucks technically (2010)
#136Earlier 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.
The bet on "everything is an object" was a honest and competent one, but unfortunately it didn't work. "Everything is a file" works better on practice. Unfortunately, that was the last real attempt on Windows to improve things.
Yes, the lack of diversity in OSes is bad. But Windows doesn't fix it. (Android and iOS were the last large attempt of innovation there, and implemented some really good things, but it's also useless to have the OSes completely managed by large corporations that antagonize both their customers and society as a whole.)
Re: Why the Windows Registry sucks technically (2010)
#137> 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 love editing files in /etc ending in conf! Some are pseudo-INI (OpenSSL), some are pseudo-XML (Apache2 and friends), some are some kind of unholy amalgamation between C and YAML (nginx, dhcp daemons), others are some kind of TOML derivative (systemd, NetworkManager) and there's also some diet JSON in there! Netplan uses YAML, of course, though JSON will probably also parse. It's always a fun adventure to reverse en…
Sure it would be great if all configuration was written in a single configuration format. Life would also be so much easier if there was only one ultimate programming language so we would only have to learn one. Unfortunately reality is messy and for a variety of reasons we have different formats. As a side note, I don't think I ever ran into a syntax error for a system configuration file, because I couldn't figure out the format. The first time that happened to me was when editing a yaml file for CI.
> Of course, most important files contain whitespace separated lines of configuration of which the meaning is only clear if you read the comments above it (cron, fstab, crypttab) or secretly bash scripts (GRUB config and many other files in /etc/default).
Well there is "man fstab", "man 5 cron" etc., so the file formats and options are formatted. However the complaint that the default files are so well commented that one understands what the different options are without actually reading the docs is just weird to me. How is that worse than some random registry key that is not documented anywhere without comments (they are not possible AFAIK) and without knowing what type they should take.
> Then there's user configuration stuff. Sure, HKLM vs HKCU is kind of weird, but the user configuration structure in the Linux home directory is an argument against intelligent design. ~/.config, ~/.programname, ~/.local or ~/snap//current/?
Which program saves configuration inside ~.local? I'm not aware of any and they generally should not. Also adding adding snap to that list is a bit besides the point, I don't think containers typically save their configuration in the registry either?
> Roll the dice and find out! You may be able to find the setting you're looking for in the DConf Editor but if you can't find it there, grep and prayer is your best bet.
I actually dislike that gnome uses dconf (which is a better organised registry), I think it would be better if they instead would have text files as well. I understand it's largely for performance reasons.
> The Windows registry may be the result of a flawed execution, but I'll take it over the mess in Linux any day.
So how do you know what registry keys to change to achieve a certain configuration (without documentation, because you didn't like that on Linux either)?
> Sadly, the registry has fallen out of fashion in Windows so now managing random configuration files somewhere in %USERPROFILE% (if you're lucky and the programmer hasn't hardcoded C:\Users\ as a path) just like on Linux. By the way, who needs the "hidden" FS flag anyway? Just start the filename with a period and pretend the ls-bug-dressed-up-as-a-feature for hiding files and folders is a standard every platform sticks to!
Re: Why the Windows Registry sucks technically (2010)
#138Earlier 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…
To be fair, Microsoft doesn't rely on the registry for complex configurations either, even IIS uses .config files.
Re: Why the Windows Registry sucks technically (2010)
#139Earlier quoted context omitted.
> 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 re…
> Manually editing the registry though... That way lies madness. It's much scarier and it's much more fragile. How... exactly? There's no way to create a syntax error as trivial as you can in config files. How is using regedit or powershell commands more fragile (I understand "scarier" in a way everything you're not used to is scary).
Re: Why the Windows Registry sucks technically (2010)
#140Earlier quoted context omitted.
> 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 sh…
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.