Live data from Hacker News

Why the Windows Registry sucks technically (2010)

rwmj.wordpress.com

231–240 of 342 posts

Re: Why the Windows Registry sucks technically (2010)

#231
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…

Extracted from the "Rationale" section of https://en.wikipedia.org/wiki/Windows_Registry 1) Since file parsing is done much more efficiently with a binary format, it may be read from or written to more quickly than a text INI file. 2) Strongly typed data can be stored in the registry, as opposed to the text information stored in .INI files. 3) Because user-based registry settings are loaded from a user-specific path…

> These points are mostly bogus IMO

Why?

Re: Why the Windows Registry sucks technically (2010)

#232
post #210

Earlier quoted context omitted.

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... ?

Interesting, I hadn't seen that. Did Google Drive go with the virtual drive letter thing mainly for backwards compatibility to older windows?

Re: Why the Windows Registry sucks technically (2010)

#233
post #182

Earlier quoted context omitted.

On ext4, a file of 160 bytes or less (and no xattrs) can be stored inline in the inode[1], so the whole thing takes up 256 bytes (plus 8 + [length of filename] for the directory entry). I don’t think any Unix filesystem did that in 1989, but the problem is not unsolvable, especially given that you are hardly going to use a configuration file to store a single value. NTFS does the same, actually, except it can’t count…

> On ext4, a file of 160 bytes or less (and no xattrs) can be stored inline in the inode[1], so the whole thing takes up 256 bytes (plus 8 + [length of filename] for the directory entry). It can if you enable an option that is not widely used, IIRC.

Huh, right you are: the inline_data feature is from 3.8 (2013), but apparently tune2fs couldn’t enable it on a live filesystem for some time after that, and it’s still not on by default.

(I remembered seeing the feature in the format description, but did not think it would actually be unused in most cases.)

Re: Why the Windows Registry sucks technically (2010)

#234
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…

That overhead is not intrinsic to the concept of a filesystem. If you asked someone to design a filesystem specifically to store short strings they could easily come up with a low-overhead design while preserving the other advantages of real filesystems.

Re: Why the Windows Registry sucks technically (2010)

#235
The Windows registry is sort of a copy of the Mac's "resource fork". The original Mac had files with both a data fork, the file contents, and a "resource fork", which is a tree-like database. Preferences and such were stored in resource forks. This was a good idea, implemented badly. Because it was originally designed for floppy disks, writes were very expensive. So resource forks were left open in an inconsistent state after modification, to be closed at program exit. After a crash, resource forks were damaged. Unfortunately, this flaw persisted long after the Mac line got hard drives and more speed.

Apple was on the right track with the concept that most programs needed a database for their state, but, because of the cram job needed to squeeze the original MacOS into 128K of RAM, got stuck on a bad design. Microsoft didn't have that excuse with their Registry.

Re: Why the Windows Registry sucks technically (2010)

#236

The Windows Registry is a pretty good key-value store for centrally storing config. Because some, perhaps many, have abused the originally good idea, does not invalidate its positive aspects. Also, I do not agree it is a file system. It is a key-value storage system that is leagues better than the win.ini, system.ini, and the prolific ini file collection hell it replaced. Some form of version control would make the r…

It’s impressive because they actually achieved that level of centralization. Most systems aim to have a centralized configuration “place” but it doesn’t stick. With windows the registry really did stick

Re: Why the Windows Registry sucks technically (2010)

#237
post #178

https://www.libelektra.org/home is an attempt to bring a registry to linux. It doesn't have the problems of its windows equivalent. I wish this project was more popular.

Why? The windows registry is a disaster. The whole idea is wrong. You want to keep configuration with the thing being configured. Most Mac installs are "drag the folder on to your disk". You are done.

Isn't app configuration in Mac kept in property list files under ~/Library/Preferences/?

Re: Why the Windows Registry sucks technically (2010)

#238

Earlier quoted context omitted.

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.

Is that you, Dave Cutler? But more seriously, what do you want from an OS? Cleaner design? Plan 9 comes to mind. QNX is very elegant, too. Some microkernel thing? Fuchsia, but some say it's inelegant and overdesigned right off the bat. Minix has some nice properties but somehow nobody but Intel seems to use it. Also, QNX again (but as the name suggests it's similar to Unix)... Distributed computing? I don't know, see…

QNX got a lot of things right, mainly in the area of interprocess communication. Interprocess communication came late to Unix/Linux, and it shows. Microservices under QNX work much better than under Linux. Interprocess communication is fast and works like a synchronous function call. Hard real time actually works with QNX. But QNX had nothing new on the database side.

Re: Why the Windows Registry sucks technically (2010)

#239
post #204

Earlier quoted context omitted.

perhaps the kernel, but i suspect that much of the userland (which is a lot of what i reference here when i say "unix"- all the command line utilities, shells, the C programming language) was influenced by the needs of both the research community and the technical operation of the telephone network itself.

I'm more than happy to be corrected about this, but my understanding is that the groups at Bell Labs that created and matured Unix were not closely tied into the telephony groups, if at all. The lack of interest in telephony use cases is evidenced by early releases and "workbench" distributions for Unix: PWB/Unix[1] focused on providing a development environment for programmers, and WWB[2] was aimed at technical edit…

Yes, for the large part the computing work at Bell Labs was of a separate and distinct lineage from telephony. The story is somewhat complicated by AT&T's corporate history, as prior to divestiture AT&T was, for the most part, prohibited from selling "computers" as part of the terms of their regulated monopoly. In part as a result of this regulatory situation, the computing work at Bell Labs was viewed as more theoretical than applied. Telephone switching equipment itself, such as the ESS, never ran Unix. This is rather complicated by the fact that some sources (not incorrectly) describe the 5ESS as running UNIX, but in fact the so-called UNIX-RTR they ran was an independently developed operating system that featured partial UNIX compatibility. This was largely for convenience as by that time UNIX was often being used as a development and build environment for switching software.

It's easy to see why UNIX wasn't really involved in the telephone system itself: UNIX was designed as an operating system for mid and minicomputers such as the PDP that featured a largely "conventional" (from the modern perspective, the matter was less settled at the time) Von Neumann architecture with opportunistic scheduling. Telephone switches, back to the 1ESS and back to the XBAR if you choose to view it as a computing machine, tended to be Harvard architecture with real-time scheduling. This was viewed a far more suitable for telephone equipment since it had extremely high uptime and reliability requirements compared to computers. This comes from the different applications: in the '70s computers were still viewed as machines for offline processing in batch mode, where failures were handled by backing out and restarting the batch. Telephone switches were online machines that could not restart their work from the beginning without disrupting calls in progress. These were basically two completely separate lineages of computing machines that had little in common until the '90s, although the PDP itself was an important step in eroding that divide since it was popular for process control applications (this history relates to the reason the PDP was called the PDP).

Keep in mind as well that telephone switching equipment of that era made heavy use of hardware reliability measures (lockstep synchronization of redundant control modules and a large amount of "safety" logic implemented in hardware) as well as running almost entirely from read-only storage (in its most extreme form, the metal punchcards used by the 1ESS). These were further factors that made phone switches dissimilar enough from "computers" that they ran quite distinct software, which usually lacked many of the elements that we would now consider part of an "operating system" (e.g. dynamic process scheduling). To some extent this is still true although e.g. Nortel DMS is more often running off of RHEL-based controllers now.

General-purpose mainframes and minicomputers were heavily used within AT&T but for offline applications such as billing, accounting, and maintenance management. For example, many electronic exchange switches were originally paired with a PDP-11 class machine that tracked maintenance and fault data for the office to replace the original paper tickets. Over time these machines gained more capabilities such as automatic line testing, but they remained "external" to the phone switch for reliability reasons. Billing was, for the most part, done by physically removing the tapes from the switch's data recorder and loading it into a computer to totalize and generate bills. Later on this process was automated but still with a clear separation of the switching system and the billing system.

Post 1984 AT&T, no longer a regulated monopoly, was permitted to compete directly with IBM, Lexmark, etc with their computing division. The venture was an infamous failure, and AT&T never saw real traction as a computer vendor. AT&T's rapid technical development but failure to actually build a sustainable computer business is what brought us the UNIX ecosystem: they built it, but they couldn't sell it, so eventually they basically gave up and licensed it to anyone with a pulse.

Re: Why the Windows Registry sucks technically (2010)

#240

Earlier quoted context omitted.

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.

Is that you, Dave Cutler? But more seriously, what do you want from an OS? Cleaner design? Plan 9 comes to mind. QNX is very elegant, too. Some microkernel thing? Fuchsia, but some say it's inelegant and overdesigned right off the bat. Minix has some nice properties but somehow nobody but Intel seems to use it. Also, QNX again (but as the name suggests it's similar to Unix)... Distributed computing? I don't know, see…

RIM (The Blackberry people) bought QNX. Do you know, if they have been good shepherds? Has that helped, or disadvantaged QNX as a viable solution proposal in the project space it had?.
Post reply on HN