5 ms·

The registry is a fantastic idea - it's a great pity software developers misused and screwed it up so badly, and a shame other OSs haven't copied it and built o

The registry is a fantastic idea - it's a great pity software developers misused and screwed it up so badly, and a shame other OSs haven't copied it and built on it. Instead of every tool making its own incompatible, undocumented, non-standard config file/database/format/tools.

dlivingston 7y ago
I think Apple solved this problem well with the .app application files. All application files and resources are self-contained. Drag the .app file to the Trash to completely remove it. Some apps are non-conforming, and store data elsewhere, but as a general model I think it works very well.
- FigBug 7y ago
  .apps aren't really analogous to the registry, they are more like the contents of the Program Files directory. On macOS, the registry equivalent is all the plist files stored in ~/Library/Preferences and ~/Library/Application Support. These just get left behind when the .app is deleted.
- atombender 7y ago
  macOS doesn't get it right. Removing .app files doesn't delete attendant files under ~/Library/Application Support. You need a utility like App Cleaner [1] (which is great) for that. Early macOS used the installer system, which still exists but is increasingly rare. You'll notice it because the installer has the .pkg extension. The installer writes "receipts" to a special folder, which contains all the files it created, which in principle should help you unininstall. In practice, this doesn't work well, either, because apps litter the file system with files after they're installed. Apple encourages the use of sandboxing for new apps. You'll find that apps each get a root under ~/Library/Containers. This means you can wipe all of an app's data in one go; as I understand it, sandboxed apps have to explicitly request access to any files they need to access outside of their container. With APFS they could go even further and give each app their own volume, I suspect. But most apps aren't yet sandboxed, so we still have file systems polluted with stuff. [1] https://freemacsoft.net/appcleaner/ https://freemacsoft.net/appcleaner/
andrewstuart 7y ago
>> it's a great pity software developers misused and screwed it up so badly So the Registry is a great idea and great software design, but developers are "holding the phone wrong"? I think applications should be standalone and not tied into some giant central spaghetti shared knot of chewing gum. The beauty of Linux/Unix is that stuff is configured by text files. Windows was on that path i the early days when everything was configured with ini files before someone had the idea of introducing the registry.
- jodrellblank 7y ago
  "Holding the phone wrong" referred to people using something as they'd expect, but it not working at all. The registry turned to trash by people using it wrongly, because people don't write software very well. When ordinary users needed admin rights because developers stored per-user settings in the system-wide config, that's developers misusing the registry. When tools register themselves as file-format-handlers in the registry directly instead of going through Windows' API and getting user permission, so they can steal file format registrations, that's developers being malicious or bad at their jobs. When developers persist things in the registry without taking into account the documentation that warns things like "the user hive might be loaded on a desktop then on a terminal server with a different version of the installed application", that's developers not using it properly. A central configuration database with standard ways of accessing it, doubling as an early 'service-discovery' place (e.g. registration of COM components), with system-wide config and per-user hives loaded when needed, is a great idea, and the registry is tolerably good software design as a way to do that, considering it came from the early 1990s, but developers have carelessly misused it for years, and Microsoft take the blame for that. Imagine you logged onto a server by SSH and your /home/.program/program.conf file is from a newer version and the program doesn't run. Nobody would attack "the concept of storing configuration in a text file" for that - but people would attack "the registry" when that equivalent happens on Windows. How many times have people written scripts to "parse" and add/remove lines of config from text files, without ever saying "we're reinventing the wheel for the hundred thousandth time, what a miserable waste of human life, if only there was a standardised key/value store we could put data in with a standard tool"? And I put "parse" in scare-quotes because how many actually implement a full and correct Apache/Bind/iptables/etc config file parser, instead of a quick regex/sed/AWK/Python hack? JSON changed this a little, but now you'd easily expect to configure a server/service using a REST interface, and the config would be persisted in some unknown not-user-facing database behind the scenes, and that's just "fine".
mackal 7y ago
GNOME used to have GConf, which is basically the same thing as Windows Registry. GNOME 3 replaced that with dconf/gsettings which serves very similar purposes.
- deleted 7y ago
  [deleted]

dlivingston 7y ago

I think Apple solved this problem well with the .app application files. All application files and resources are self-contained. Drag the .app file to the Trash to completely remove it. Some apps are non-conforming, and store data elsewhere, but as a general model I think it works very well.

FigBug 7y ago
.apps aren't really analogous to the registry, they are more like the contents of the Program Files directory. On macOS, the registry equivalent is all the plist files stored in ~/Library/Preferences and ~/Library/Application Support. These just get left behind when the .app is deleted.
atombender 7y ago
macOS doesn't get it right. Removing .app files doesn't delete attendant files under ~/Library/Application Support. You need a utility like App Cleaner [1] (which is great) for that. Early macOS used the installer system, which still exists but is increasingly rare. You'll notice it because the installer has the .pkg extension. The installer writes "receipts" to a special folder, which contains all the files it created, which in principle should help you unininstall. In practice, this doesn't work well, either, because apps litter the file system with files after they're installed. Apple encourages the use of sandboxing for new apps. You'll find that apps each get a root under ~/Library/Containers. This means you can wipe all of an app's data in one go; as I understand it, sandboxed apps have to explicitly request access to any files they need to access outside of their container. With APFS they could go even further and give each app their own volume, I suspect. But most apps aren't yet sandboxed, so we still have file systems polluted with stuff. [1] https://freemacsoft.net/appcleaner/ https://freemacsoft.net/appcleaner/

andrewstuart 7y ago

>> it's a great pity software developers misused and screwed it up so badly So the Registry is a great idea and great software design, but developers are "holding the phone wrong"? I think applications should be standalone and not tied into some giant central spaghetti shared knot of chewing gum. The beauty of Linux/Unix is that stuff is configured by text files. Windows was on that path i the early days when everything was configured with ini files before someone had the idea of introducing the registry.

jodrellblank 7y ago
"Holding the phone wrong" referred to people using something as they'd expect, but it not working at all. The registry turned to trash by people using it wrongly, because people don't write software very well. When ordinary users needed admin rights because developers stored per-user settings in the system-wide config, that's developers misusing the registry. When tools register themselves as file-format-handlers in the registry directly instead of going through Windows' API and getting user permission, so they can steal file format registrations, that's developers being malicious or bad at their jobs. When developers persist things in the registry without taking into account the documentation that warns things like "the user hive might be loaded on a desktop then on a terminal server with a different version of the installed application", that's developers not using it properly. A central configuration database with standard ways of accessing it, doubling as an early 'service-discovery' place (e.g. registration of COM components), with system-wide config and per-user hives loaded when needed, is a great idea, and the registry is tolerably good software design as a way to do that, considering it came from the early 1990s, but developers have carelessly misused it for years, and Microsoft take the blame for that. Imagine you logged onto a server by SSH and your /home/.program/program.conf file is from a newer version and the program doesn't run. Nobody would attack "the concept of storing configuration in a text file" for that - but people would attack "the registry" when that equivalent happens on Windows. How many times have people written scripts to "parse" and add/remove lines of config from text files, without ever saying "we're reinventing the wheel for the hundred thousandth time, what a miserable waste of human life, if only there was a standardised key/value store we could put data in with a standard tool"? And I put "parse" in scare-quotes because how many actually implement a full and correct Apache/Bind/iptables/etc config file parser, instead of a quick regex/sed/AWK/Python hack? JSON changed this a little, but now you'd easily expect to configure a server/service using a REST interface, and the config would be persisted in some unknown not-user-facing database behind the scenes, and that's just "fine".

mackal 7y ago

GNOME used to have GConf, which is basically the same thing as Windows Registry. GNOME 3 replaced that with dconf/gsettings which serves very similar purposes.

deleted 7y ago
[deleted]