The Burroughs large system architecture of the 1960s and 1970s (B6500, B6700 etc.) did it. Objects were called “arrays” and there was hardware support for allocating and deallocating them in Algol, the native language. These systems were initially aimed at businesses (for example, Ford was a big customer for such things as managing what parts were flowing where) I believe, but later they managed to support FORTRAN with its unsafe flat model.
These were large machines (think of a room 20m square) and with explicit hardware support for Algol operations including the array stuff and display registers for nested functions, were complex and power hungry and with a lot to go wrong. Eventually, with the technology of the day, they became uncompetitive against simpler architectures. By this time too, people wanted to program in languages like C++ that were not supported.
The Photo (v2) app gives you a choice of using Apple’s converters or “Serif” converters. But, when last I looked, lens corrections were not available with the Apple converters.
Yes, ideally the tool should edit its own preferences. A quick and dirty tool might leave the user to run the macOS "defaults" command line utility themselves. It’s certainly no worse than looking up the dotfile format and firing up vi.
Towards the end TFA claims that Apple’s bundled command line utilities, including zsh and vim, put their dotfiles in ~/.config. They don’t. They put them in the traditional BSD place, the user’s home directory ~/. Looking at mine now, I see .bash_login, .emacs (wow! that’s old), .lldb, .lldbinit, .vimrc, .swiftpm, .z{profile,env,rc} and a few others. I see no ~/.config directory.
My personal practice when writing command line utiities for macOS is to use the macOS API to write settings (previously known as “preferences”) into ~/Library/Preferences, so they can interoperate with any GUI versions of them I might like to write, and for the utilities themselves to have command line options to control those settings. As a sibling comment suggests, you do need to avoid name space collisions. You can use a reverse DNS name, or some companies are big enough just to use their company name. They do appear as .plist files but are actually maintained by a daemon – which nicely avoids race problems with multiple processes updating settings.
If I were writing a portable utility which had a dotfile with a documented format the user was expected to edit, I would make it a dotfile under the home directory.
~/Library/Application Support is really more for per-user static data, like presets and templates, things that are known in a GUI by a string in some dialogue but not necessarily thought of by the user as a file.
How do I do that? fstat(2) is no help on macOS, and even if it were would return false positives from things like backup and content indexers ("Time Machine" and "Spotlight" on macOS).
> ... directories, if used properly, can protect a 777 file from being changed. The error in the mental model is in how permissions work, not how files are organized.
There is a second possible misconception that I did touch on in my last paragraph, but didn't spell out. On Unix, the permissions check is done when you open the file, not when you perform the read or write. This means that a user who cannot currently open the file (because directory permissions mean they have no way to get to the inode) can nonetheless alter it now if they opened it when they could. So you could rename the file from the attacker's directory into your installer's private directory, verify its cryptographic signature, but then the attacker injects their malware into the file before you start copying, and you install the malware.
Because the two common types of locks on Unix (BSD and POSIX record) are advisory, you can't just lock that file against writers before you check the signature. This is in contrast to Windows, where you can't even rename or delete the file if someone else has it open.
"But because of a subtlety of Unix systems (of which macOS is one), when an existing file is moved from another location to the root directory, it retains the same read-write permissions it previously had."
And ownership. (The sentence before that suggests "root directory" here means "directory owned by root".) The permissions on the directory apply only to the file's directory entry, not the file itself.
This isn't a "subtlety", it's how it works, and no-one who doesn't understand this should be writing macOS installers.
The correct approach is to open the file for read and copy its bytes into your private area. Only then check the cryptographic signature. Just renaming into your private directory isn't enough, even if that directory has no read or execute access to other users, because the attacker could have opened the file for write access before you did the rename.
These were large machines (think of a room 20m square) and with explicit hardware support for Algol operations including the array stuff and display registers for nested functions, were complex and power hungry and with a lot to go wrong. Eventually, with the technology of the day, they became uncompetitive against simpler architectures. By this time too, people wanted to program in languages like C++ that were not supported.
With today’s technology, it might be possible.