[kitotik]

Once binary plists were introduced, it was only a matter of time before it became the macOS equivalent of windows registry.

The fact that Apple is maintaining multiple parsers, and apparently added yet another in response to this bug, just smells bad.

[ken]

I thought the Windows Registry was reviled because it was a single database that held everything from user customization to device driver and boot configuration, in one file. It was contrasted with the Unix/Linux way, which was single-purpose text files, with the system-wide configuration in protected /etc files, and user-specific configuration in ~/. files

Plists are the best of both worlds. They're a file format rather than a system database, so user-specific config goes in ~/Library/, application-specific config goes in the *.app/ bundles, and system-wide config is in /System or /Library. But it's also a unified format, so each program doesn't need to implement its own parser, and users and developers don't have to wonder how application XYZ decided to escape backslashes, in its config file.

How are they "the macOS equivalent of windows registry"? Or is that just a generic techno-slur?

[kitotik]

I meant it in the sense that it turned into binary blobs that became less accessible for humans to manage, and a place where both Apple and 3rd party vendors started hiding magic stuff stored who-knows-where in a format that isn’t easy to grep / find.

[azinman2]

It is far from the Windows registry. Everything is file-oriented, making it easy to backup or wipe away any given plist. The plists themselves are well named and located files that tell you what it is, and things don’t appear in multiple places. No program that gets installed needs to modify any system plists; in fact, apps pretty much never access plist that they don’t own. This last fact makes it so different from windows that you don’t see “plist repair apps” in the same way you do for windows.

Binary plists are identifiable to ascii plists, they’re just more compact. plutil is a utility that can convert them back and forth. Internally the plist classes can be passed either to load and they won’t bat an eye.

[saagarjha]

> Everything is file-oriented, making it easy to backup or wipe away any given plist.

Does cfprefsd react well to that these days?

[azinman2]

Most plists are NOT NSUserDefaults / CFPreferences

[saagarjha]

Right, but those would be the closest analog to the registry would it not?

[azinman2]

Kind of but that doesn’t make it the same, especially when it doesn’t suffer from all the issues that plague the registry.

[geoffpado]

…in OS X 10.2? In 2002?[0]

Seems like a significant amount of time.

[0]: https://en.wikipedia.org/wiki/Property_list#History

[saagarjha]

Property lists have been around since forever. They're NeXT technology.