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…
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…
Why the Windows Registry sucks technically (2010)
31–40 of 342 posts
Re: Why the Windows Registry sucks technically (2010)
#32I 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…
One of the critiques in this article is that, because you have to know/guess/assume what encoding is used for various strings, there isn’t one for the registry, either.
If so, both approaches suffer from that (but Unix a bit more because it tends to store multiple items under a file system ‘key’, while Windows programs rarely store multiple items under a single registry key)
I do wonder what RegEdit.exe does here. Does it infer encoding, have a long list of key-to-encoding mappings, or a combination of the two?
Re: Why the Windows Registry sucks technically (2010)
#33Earlier quoted context omitted.
Actually the Registry is not a single file, it is a set of files virtually assembled into a single "object" that has many points in common with both a database and a filesystem. Personally I see it more like a filesystem, with some striking resemblance to NTFS.
It is a single file to the underlying filesystem. Yes it reimplements a filesystem, I already said that in the comment you are replying to.
> dir /a C:\Windows\System32\config
...
29.07.2022 12:33 44 040 192 COMPONENTS
21.11.2010 10:21 1 024 COMPONENTS.LOG
29.07.2022 12:33 262 144 COMPONENTS.LOG1
14.07.2009 05:34 0 COMPONENTS.LOG2
29.07.2022 12:33 65 536 COMPONENTS{016888b9-6c6f-11de-8d1d001e0bcde3ec}.TM.blf
06.03.2021 21:44 524 288 COMPONENTS{016888b9-6c6f-11de-8d1d-001e0bcde3ec}.TMContainer00000000000000000001.regtrans-ms
29.07.2022 12:33 524 288 COMPONENTS{016888b9-6c6f-11de-8d1d-001e0bcde3ec}.TMContainer00000000000000000002.regtrans-msRe: Why the Windows Registry sucks technically (2010)
#34I 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 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…
Which are these? I assume Qubes OS sidesteps the problem entirely... NixOS?
Re: Why the Windows Registry sucks technically (2010)
#35I 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…
Re: Why the Windows Registry sucks technically (2010)
#36I 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…
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.
> Parsing that file is application-specific.
Same for Windows applications; the subtree for any application is very specific to that application and almost always differs from the subtree for other applications.
> Updating a value in a text file means re-writing the whole file again.
Not a problem, when it means that breaking a value in a text file breaks only that one application. Break the registry almost always breaks something else, if not the entire system.
I'm not saying files in /etc aren't without their problems, I'm saying that all /etc problems are already present in the registry, but the registry adds a few more of its own.
Re: Why the Windows Registry sucks technically (2010)
#37Earlier quoted context omitted.
That was a deliberate attempt to make it impossible for competitors to read and write their format wasn’t it?
I don't know the exact year that file format was made, but you had to think about performance more than wasting so much memory and cpu cycles to have a fancy file format, no? Ofcourse that era Microsoft tools didn't think much about interoperability outside of Microsoft ecosystem. But to me it seems that them having some XML based file format at that time would be silly and have disadvantages. XML actually was starte…
Most of it wasn’t popular enough and/or got abandoned soon enough for ‘the internet’ to notice, though.
If your software runs in 256kB, writing to a floppy disk, you pack your data structures, use bit fields where possible, and you’re not going to waste CPU time, RAM and disk space to write a format that’s easy to understand and extend.
(Of course, they extended it, anyways, as everybody would)
Re: Why the Windows Registry sucks technically (2010)
#38> 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…
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).
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/? 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.
The Windows registry may be the result of a flawed execution, but I'll take it over the mess in Linux any day. 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)
#39Re: Why the Windows Registry sucks technically (2010)
#40>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.
> Like? Always thought it was an hierarchical database.
A filesystem is a hierarchical database.