> Not that I'm convinced most distros even do 32-bit development anyway these days.
32-bit is essentially dead outside of weird scenarios like companies still running Windows XP. Even the cheap Android phones should all be 64-bit these days.
So unless you really need to support old hardware (or microcontrollers I guess), it means you can now confidently do fun stuff like cramming data into the 64-bit user data pointer in callback APIs.
Probably very little 32-bit embedded using 80486 CPUs. If your embedded system uses an x86 CPU that's newer than 1993 it should still be fine for a few years.
It's probably not a problem, nice thing is that the existing kernel sources will stay available, so even if special systems need to run on 486, they can always build kernels.
There's probably no intersection where 486 legacy systems are going to be in need of kernel features that are not already implemented.
In that unlikely event, it may still be possible to backport said feature to the last 486 compatible kernel.
7 comments
[ 3.8 ms ] story [ 33.6 ms ] thread32-bit is essentially dead outside of weird scenarios like companies still running Windows XP. Even the cheap Android phones should all be 64-bit these days.
So unless you really need to support old hardware (or microcontrollers I guess), it means you can now confidently do fun stuff like cramming data into the 64-bit user data pointer in callback APIs.
There's probably no intersection where 486 legacy systems are going to be in need of kernel features that are not already implemented.
In that unlikely event, it may still be possible to backport said feature to the last 486 compatible kernel.