Hit a *really* corner case bug today - a binary was absolutely present but returned ENOENT whenever you tried to run it. strace showed exevce() returning it, so it was happening when the kernel tried to run it. Normally I'd assume that the rtld (the thing that the kernel delegates loading of dynamic libraries to when running a dynamically linked binary) was missing, but ldd showed nothing missing - everything was resolved, including the rtld. WTF?
Turns out that ldd doesn't run the rtld that's defined in the binary - it has a list of rtlds it tries to run against the binary. If I'd read the output more closely I'd have seen:
The toolchain that built the binary set the rtld to a path in /lib, but ldd was reading it out of /lib64.The kernel only uses the built-in path, so we got ENOENT.
It's taken a while for me to figure out why https://www.fsf.org/news/anchoring-the-fsf-in-its-values bothered me so much, and in the end I think it's that the FSF doesn't recognise its unique position in the free software community. Sure, if people sufficiently disagree with the FSF they could start up their own foundation - but the FSF has unique control over the GPL, one of the bedrocks of free software
The FSF asserts it's staying true to its original goals through strict control of who can become a board member, but what if they're wrong on something? What if the board refuses to recognise something fundamental? There's no clear avenue to engage with the board to change their mind, there's no way to become elected to the board to work from within. Someone could start a competitor but the FSF own the copyright to GNU and (more importantly) they own the GPL family of licenses.
I think it's fine for an organisation to making it hard to be subject to ideological takeover, but if that organisation has power nobody else does then what next? We're asserting that the current FSF voting members have an insight into free software that nobody else does, and this doesn't feel great
People justifying their behaviour based on being neurodivergent and accusing anyone who criticises them as being a bigot without considering that those people may also be neurodivergent challenge, difficulty apparently impossible
I've helped deploy TPM-backed remote attestation at 4 different companies and it's the kind of day where people try to tell me I don't understand TPMs or remote attestation
@bugaevc It's not tied in with remote attestation at all, no media streaming companies do that on PCs (and I'm unaware of *any* cases of remote attestation on PCs outside enterprise scenarios where they're having their own hardware attest to them)
A more detailed writeup of how the FSF is not only wrong about TPMs being involved in hardware-based DRM, they missed the actual user-hostile hardware DRM implementation: https://mjg59.dreamwidth.org/70954.html
Former biologist. Actual PhD in genetics. Security at https://aurora.tech, OS security teaching at https://www.ischool.berkeley.edu. Blog: https://mjg59.dreamwidth.org. He/him.