Hacker News Reader

Comment by adrian_b | Hacker News Reader

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 private directory.

In my opinion this is the only sane way of managing software packages, because otherwise, also on Linux, but especially on Windows, I have wasted far too much time during the years with debugging various problems caused by the installation/uninstallation programs.

View on HN

You can do similar on windows. However, the registry was turned into trying to solve a slightly different issue of roaming users, and centrally managed settings, split by machine and user, and using what became active directory. They started off with OLE and its central store of holding name value pairs in a tree. Basically making the registry do at least 4 different things. Only one of them it does 'ok' (COM/OLE lookups). In practice it became a huge mess because thousands of applications now keep their settings in there and poor cleanup practices like you see. When like 99% of the use cases out there would be perfectly well suited to just using the forever deprecated win32 INI API to manage settings and MS just saying 'put your config files in these places for different effects'. Instead they said 'put it all in the registry'. Looking back at it, it is now 100% clear it was a bad design decision.

It should be noted that putting configuration into files rather than registry has been the standing recommendation on Windows for a very long time now. For example, .NET 2.0 (2005) added a standard facility for application settings, and it was implemented on top of XML .config files.

Good to see MS practising what they preach on newly written applications:

https://docs.microsoft.com/en-us/deployedge/configure-micros...

> You can also use REGEDIT.exe on a target computer to view the registry settings that store group policy settings. These policy settings are located at this registry path: HKLM\SOFTWARE\Policies\Microsoft\Edge.

This is a group policy, not a setting. That makes a big difference in the right context - policies are meant for things that are typically centrally managed in enterprise environments, so the ability for the admin to remotely control every setting individually is important, and requires some kind of central system registry for OS tooling to work with.

Yep, but it still sucks if you are a user trying to figure out how a setting is applied, first delve into some seemingly proprietary config db for edge, and then realise its actually configured via a registry gpo.

>the various Linux-based systems where any software package is installed only inside a private directory

Which are these? I assume Qubes OS sidesteps the problem entirely... NixOS?

NixOS, mostly, but not for application data (/var usually), which is closer to the registry.

Reply on news.ycombinator.com