News for hackers. Stuff that matters.
Re:My transition to an Ubuntu workstation by rbanffy on Wednesday October 23, 2019 @07:30AM (#21333473)
It's not that the registry grows large. It's because it accumulates cruft. If your software relies on information in the registry to make decisions, it'll often make decisions based on outdated information a long uninstalled (or upgraded) program left there.

It's the wrong solution to an old problem: having your configuration in hundreds of .INI files was a problem because opening and reading files took a long time. Instead of solving the problem and making opening and reading hundreds of files fast (which would be awesome for a number of other uses of a computer) they created new file that every application would read and write to. It seemed like a great idea at the time.

Every problem has a solution that's simple, elegant, and wrong.

Re:My transition to an Ubuntu workstation by WorldMaker on Wednesday October 23, 2019 @03:28PM (#21337969)
> It's not that the registry grows large. It's because it accumulates cruft.

This seems to be the correct answer, but not for the reason you think ("outdated information"). The registry is a highly indexed database, because it needs to be quick at answering if say a low-level kernel-level driver needs something in real time for an operation. Many of those indexes are variations on Most-Recently-Used (MRU) caches. The more applications that make random queries to the Registry, the more those MRU caches churn and the more likely the MRU caches are full of small, one-off application data versus important stuff that needs to be queried as quickly as possible. (Over time Windows has seemed to work to compensate by changing indexing strategies, but at a high level a lot of the slow down issues with registry still boil down to index problems.)

The Registry wasn't intended to be a general application configuration store, per the original registry usage guidelines. Certainly that ship sailed.

(Also, the key problem with INI files was not that opening/reading them took a long time, it was the same centralization problem: almost every Windows 3.x application stored their INI in C:\WINDOWS for a number of dumb reasons. When Windows 9x started enforcing basic directory ACLs and not every program under the sun could read/write to arbitrary files in C:\WINDOWS, people scurried for the Registry as that seemed the closest to what they were already doing, squirreling config data in C:\WINDOWS for dumb reasons. It took a while for developers to realize they should just put config files in whatever format they prefer in %LOCALAPPDATA% or such like and stop trying to centralize them.)

Re:My transition to an Ubuntu workstation by rbanffy on Thursday October 24, 2019 @08:48AM (#21344115)
Thank you. It's very interesting.

In the Windows 3.1 days I had some interesting problems when importing data into an MS Access databases that would contain reports for our senior execs to read while offline (the web was not a thing back then) and import throughput slowed down to a near-halt after 30 megs of data or so. Our solution was to do the import in chunks, and defragment the database between them.

Re:My transition to an Ubuntu workstation by theandrewbailey on Wednesday October 23, 2019 @10:20AM (#21334874)
> If your software relies on information in the registry to make decisions, it'll often make decisions based on outdated information a long uninstalled (or upgraded) program left there.

Why is your software looking at registry entries that it didn't create?

Re:My transition to an Ubuntu workstation by rbanffy on Wednesday October 23, 2019 @10:27AM (#21334945)
> Why is your software looking at registry entries that it didn't create?

I may want to know where Photoshop is installed to I can register a plugin. Or know about the printers installed. Or know more about the environment than the OS is willing to tell me. Or those may be entries that older versions of other applications of mine did create. Or Windows. Or older versions of Windows.

There are many reasons to look into registry entries that aren't the ones you wrote.