Yeah, they’ve been doing the pre-linked mega archive thing for years. It’s in /var/db/dyld. The only difference here that I see is that they’re not shipping the originals and not rebuilding it all the time. And I’m guessing the resulting archive is now sitting on a protected partition.

This thing can be taken apart, but it’s a little tricky, since it’s pre-linked. I wrote something years ago to do it, not perfect, but enough to get symbols out. (I was trying to annotate iOS stack traces.) I don’t recall if I got it working well enough to open the libraries up in hopper and poke around.

People writing third party linkers or debuggers is one.

I often dig at shared libraries using tools like nm to see what functions are where.

I'm sure there will be a way to unpack the mega archive and run nm (or maybe even run nm directly on the mega archive). Relax :)

Sadly:

  $ nm /System/Library/dyld/dyld_shared_cache_x86_64h
  /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: error: /System/Library/dyld/dyld_shared_cache_x86_64h: Invalid argument.

But yes, there are tools to pick apart a shared cache, some which work better than others.

I never said I wasn't relaxed about it. I don't even use a Mac much.

But the platform does seem to have been in a multi-year process of technical decline, and much of that does speak to a "we know better than you, and everybody else" attitude.

A number of the changes that Apple has been making seem to be security related. One reason to just dlopen() rather than stat() and dlopen() is the race-condition, which an attacker could use to get a program to use the wrong library. Similarly macOS' locked-down root partition. Checking hashes of binaries is also for security, to make sure the binary you're running is the one the developer thought they were giving you. So on the one hand the platform is in "slow technical decline" yet we (HN) claim to value security. It seems to me that the platform is doing well technically. We all remember the mess Microsoft had 10 years ago with security vulnerability du jour; Apple seems to be pre-emptively protecting its users. I submit that the "technical decline" is really "macOS is changing from a freewheeling Unix system to a secure system" and people here want to be cowboys and artists with their own private filesystem canvas. I understand the frustration, but Linux still exists. Apple isn't in the business of making a dev playground, but a computer that Just Works for people. It seems to me there isn't a technical decline, it's that HN is revealing itself to value the plasticity of traditional Unix over security (now that security has gotten good enough). I expect that SELinux has similar chafing restrictions, the only difference is that Linux is more of a set of parts so you get to (must) choose how you put those tools together.

> One reason to just dlopen() rather than stat() and dlopen() is the race-condition

But dlopen() implies code execution all the time, and stat() does not.

A good way to close this race condition, by the way, is to have a dlopen-by-fd API [FreeBSD has fdlopen], and a single call to open(2) resolves the race condition inherent in referencing the filename multiple times.

But to your larger point... It seems there is a crowd that will kneejerk dismiss any criticism as "it's for security". And any implementation bugs (such as introducing massive delays when executing programmatically-generated shell scripts because they need to be hashed and sent to a server, as was an HN headline a while ago) are also justified. I think there needs to be greater skepticism than this about how secure these efforts really makes the system, or if they are just throwing buggy stuff at a wall and applying post hoc justifications.

FFI developers and users.

autoconf developers and users. The whole lib probe ecosystem might need adjustment.

>People writing third party linkers or debuggers is one.

All 10 of them?

Still not zero. And the number of people using them is higher than that.

If in your personal life you are needlessly a jerk to a small number of people... Do you turn around and say "yeah, 10 people. So what?" I suppose many people do.

Weasel words: needlessly and jerk.

Apple didn't do it to be jerks, and didn't do it needlessly (except in the sense "they could just leave it as is").

Seems like you made my point in parentheses.

Jerkiness is subjective, but in my opinion there is a question of respect for the user, developer, or fellow human involved in the area of compatibility, where it is kind of a jerk move to fail to consider that you are breaking people, or someone might narcissistically expect the universe unconditionally to adapt to their whim, making them jump through hoops and live with the consequences of their questionable ideas. Apple does not have some of those values down well.

Apple swaps around stuff for seemingly no reason pretty much every update. Making any compiler or debugger writers life a pain.

The move seems to enforce memory-always, not file-based dyn linking. Whatever is sitting in the memory that responds to the established API.

On the first look it's not that different from how this works now. However, I'm thinking of the next step where the 'system cache' is not even local to the PC, like in a case of a netboot the whole or core set would get downloaded from the remote server be it Apple's or your friendly custom provider/employer.

MacBook Pro VT. It's a stretch, of course...