4 ms·
Linux could probably do it despite glibc, just more carefully. But OpenBSD also broke Go binaries, with some recent changes, right? Breaking ABI towards users
by knorker 2y ago
Linux could probably do it despite glibc, just more carefully.
But OpenBSD also broke Go binaries, with some recent changes, right?
Breaking ABI towards userspace, or breaking user space? What's the difference? Binaries that used to work no longer do.
If you only run packages and ports, then shrug. If all you have is packages, ports, and source, then just upgrade and recompile everything.
I'm not saying it's wrong to break userspace, but it's not inaccurate to call it such.
C.f. Google's monorepo, to not need to maintain an ABI.
ABIs may or may not be overrated, but dropping that requirement sure make things easier.
- HumanProtractor 2y agoGo wasn't properly behaved, the OpenBSD people actually fixed it so it works properly now. It's not broken.
- knorker 2y agoThat's Hyrum's law for you. Actually that's not even fair to Go. I'm as annoyed as anyone about the many suboptimal technical choices of the Go team, but I would say that Theo saying "I have altered the ABI. Pray I do not alter it further" is quite accurate. Go in this case made a choice based on one "promise", and OpenBSD changed the deal. Even Hyrum's law is more about "as implemented". Go actually went with "as designed, in the last, what, four decades?". Syscalls actually did use to be the API, and statically linked libc really did use to be "ok". OpenBSD let security be done though the heavens fall, and that's fine. But it's MUCH easier than the alternative. So obviously much easier to make progress on.
- sillywalk 2y agoOn second thought, I think you're right. The term breaking user-space is more accurate. I was more thinking of the 'end-user', not the package maintainers, and app developers. Random user upgrades to a new OS release, gets the new software packages which use the new ABI.