4 ms·

I’m curious, are you running i386 devices or more philosophically opposed to deprecation?

by setopt 5mo ago

someperson 5mo ago
Philosophically opposed. I'd like to see indefinite support powered through emulation under a modern CI server hardware with rigorous automated test-suites, with maintenance potentially supported in part with AI. But someone else should do this, of course.
- cedilla 5mo ago
  What's the philosophy?
  - someperson 5mo ago
    Whilst i386 hardware continues to exist, modern Linux kernels should continue to support it.
    - loeg 5mo ago
      Does it continue to exist?
      - userbinator 5mo ago
        Lots of it, especially in embedded systems.
- st_goliath 5mo ago
  > ...powered through emulation under a modern CI server... I have a 486 PC sitting in my living room. For shits and giggles, I've cobbled together a FAT12 boot loader that runs a program directly off a floppy and played around from there. And even by that little that I played around so far, I managed to run into more than one issue where something would work perfectly fine in Qemu, but not on the real hardware. Bochs appears to be more faithful, but also not 100% exact. Btw. did you know that Windows 9x has an interesting TLB invalidation bug that apparently went unnoticed for decades and now triggers in KVM on AMD Zen 2 and newer CPUs? (see: https://github.com/JHRobotics/patcher9x https://github.com/JHRobotics/patcher9x) AFAIK, part of the reason Linux no longer supports i486 is that it made CMPXCHG8B a hard requirement (and also RDTSC). You would need to maintain a completely separate implementation of a bunch of low-level locking primitives. I'm somewhat skeptical how well that will work when your testing relies entirely on emulation. > ... someone else should do this, of course. of course ;-)
- trollbridge 5mo ago
  A lot of things in Linux just plain won't work on an 80386; they dropped support 13 years ago mostly because the 80386 has some quirks with SMP support that make it much more difficult, and developers didn't really have real hardware to test on (emulation doesn't help with things like that).

I’m curious, are you running i386 devices or more philosophically opposed to deprecation?

by setopt 5mo ago

I’m curious, are you running i386 devices or more philosophically opposed to deprecation?

Philosophically opposed. I'd like to see indefinite support powered through emulation under a modern CI server hardware with rigorous automated test-suites, with maintenance potentially supported in part with AI. But someone else should do this, of course.

cedilla 5mo ago
What's the philosophy?
- someperson 5mo ago
  Whilst i386 hardware continues to exist, modern Linux kernels should continue to support it.
  - loeg 5mo ago
    Does it continue to exist?
    - userbinator 5mo ago
      Lots of it, especially in embedded systems.
st_goliath 5mo ago
> ...powered through emulation under a modern CI server... I have a 486 PC sitting in my living room. For shits and giggles, I've cobbled together a FAT12 boot loader that runs a program directly off a floppy and played around from there. And even by that little that I played around so far, I managed to run into more than one issue where something would work perfectly fine in Qemu, but not on the real hardware. Bochs appears to be more faithful, but also not 100% exact. Btw. did you know that Windows 9x has an interesting TLB invalidation bug that apparently went unnoticed for decades and now triggers in KVM on AMD Zen 2 and newer CPUs? (see: https://github.com/JHRobotics/patcher9x https://github.com/JHRobotics/patcher9x) AFAIK, part of the reason Linux no longer supports i486 is that it made CMPXCHG8B a hard requirement (and also RDTSC). You would need to maintain a completely separate implementation of a bunch of low-level locking primitives. I'm somewhat skeptical how well that will work when your testing relies entirely on emulation. > ... someone else should do this, of course. of course ;-)
trollbridge 5mo ago
A lot of things in Linux just plain won't work on an 80386; they dropped support 13 years ago mostly because the 80386 has some quirks with SMP support that make it much more difficult, and developers didn't really have real hardware to test on (emulation doesn't help with things like that).