3 ms·

> OpenBSD solved the time_t issue long ago. It's amazing how quickly you can solve problems when you're fine breaking user space between releases. Not that Li

> OpenBSD solved the time_t issue long ago. It's amazing how quickly you can solve problems when you're fine breaking user space between releases. Not that Linux has a perfect record, but it's much harder when you actually try.

anthk 2y ago
Upgrading is not an issue, now you have vmd and a lot of mirrors still have both the old TGZ sets, ramdisks, kernels and packages to be able to virtualize old machines just in case.
- knorker 2y ago
  I agree that it's a fine use case. I'm just saying it's simpler if you allow yourself a fresh start. Won't work well for games and other stuff you can't just recompile on your own. Going mainframe mode and virtualizing the previous generation has problems in that the older releases don't get security fixes, and may not work as well with tuning and monitoring. I would not want to run a 10 year old OpenBSD, virtual or not. E.g. the speculative execution patches would be nontrivial to backport. But it has valid use cases.
  - anthk 2y ago
    Most games can be either recompilable or able to being run with xnaify or similar Mono/C# wrappers.
    - knorker 2y ago
      Sure, they're recompilable. If whoever has the source recompiles them. Well, turns out ABI stability was not enough to make gamers use Linux, but it's an example. A better example would maybe be the Oracle database. You could maybe see them building for OpenBSD. But not if that means they'd sign up for rebuilding every six months the ABI has potentially broken in the new release. I would not say that this is the reason OpenBSD hasn't yet been the OS of choice for the Oracle sales team, of course.
sillywalk 2y ago
I'd prefer to refer to it as 'changing userspace', as opposed to breaking it. The ABI is changed, and userspace/ports are updated to use the new ABI. Users just upgrade as usual, and don't see any 'breakage'. It wouldn't work for Linux, because the kernel and glibc + the rest of userspace are developed separately. Slides on OpenBSD's transition to 64-bit time_t https://www.openbsd.org/papers/eurobsdcon_2013_time_t/index.html https://www.openbsd.org/papers/eurobsdcon_2013_time_t/index.... "I have altered the ABI. Pray I do not alter it further." -- Theo de Raadt https://marc.info/?l=openbsd-tech&m=157489277318829&w=2 https://marc.info/?l=openbsd-tech&m=157489277318829&w=2
- 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 ago
    Go wasn't properly behaved, the OpenBSD people actually fixed it so it works properly now. It's not broken.
    - knorker 2y ago
      That'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.

anthk 2y ago

Upgrading is not an issue, now you have vmd and a lot of mirrors still have both the old TGZ sets, ramdisks, kernels and packages to be able to virtualize old machines just in case.

knorker 2y ago
I agree that it's a fine use case. I'm just saying it's simpler if you allow yourself a fresh start. Won't work well for games and other stuff you can't just recompile on your own. Going mainframe mode and virtualizing the previous generation has problems in that the older releases don't get security fixes, and may not work as well with tuning and monitoring. I would not want to run a 10 year old OpenBSD, virtual or not. E.g. the speculative execution patches would be nontrivial to backport. But it has valid use cases.
- anthk 2y ago
  Most games can be either recompilable or able to being run with xnaify or similar Mono/C# wrappers.
  - knorker 2y ago
    Sure, they're recompilable. If whoever has the source recompiles them. Well, turns out ABI stability was not enough to make gamers use Linux, but it's an example. A better example would maybe be the Oracle database. You could maybe see them building for OpenBSD. But not if that means they'd sign up for rebuilding every six months the ABI has potentially broken in the new release. I would not say that this is the reason OpenBSD hasn't yet been the OS of choice for the Oracle sales team, of course.

sillywalk 2y ago

I'd prefer to refer to it as 'changing userspace', as opposed to breaking it. The ABI is changed, and userspace/ports are updated to use the new ABI. Users just upgrade as usual, and don't see any 'breakage'. It wouldn't work for Linux, because the kernel and glibc + the rest of userspace are developed separately. Slides on OpenBSD's transition to 64-bit time_t https://www.openbsd.org/papers/eurobsdcon_2013_time_t/index.html https://www.openbsd.org/papers/eurobsdcon_2013_time_t/index.... "I have altered the ABI. Pray I do not alter it further." -- Theo de Raadt https://marc.info/?l=openbsd-tech&m=157489277318829&w=2 https://marc.info/?l=openbsd-tech&m=157489277318829&w=2

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 ago
  Go wasn't properly behaved, the OpenBSD people actually fixed it so it works properly now. It's not broken.
  - knorker 2y ago
    That'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.