David Gerard
d@nny disc@ mc²@davidgerard linux apps do not have to be "updated" to the latest kernel, the kernel version is not a component of ABI compatibility and good apps should not rely on linux-only syscalls without a backup, least not because there is no way for the application to actually constrain the installed kernel version. io_uring is the only example of incompatible stuff i can think of and it's not widely used partially because it's not portable and not enabled by default. python literally uses EOL centos linux containers (see "manylinux") to define its standard portable linux ABI, because highly portable linux apps actually can be generated from old linux installs
@davidgerard like, POSIX literally exists for this purpose. it actually is good that you are able to update all your linux packages along with your kernel really easily and it rocks that distros like arch and alpine allow you to rebuild so much code by hand instead of only prepackaging it but "linux apps need to be updated to the latest kernel" isn't a thing
@davidgerard i know you know what linux is so i'm saying this because i literally don't understand
EDIT: this is a really hostile tweet and i'm sorry for that, i was very distracted
@hipsterelectron it is for binaries. ever tried to run an old linux binary? that's what this is talking about
the stable binary interface for linux turns out to be win32
keithzg@davidgerard @hipsterelectron I always hear that and I don't doubt jt's true in some instances but last time I ran the Linux version of UT2004 it only took symlinking a few libraries to get it to run, and that's a complex binary last built closer in time to the first version of Linux than to now...
@keithzg @hipsterelectron ymmv, see tales of the libc->glibc transition for more
@davidgerard i will search but do you have a link describing this?
@hipsterelectron I'm looking and can't find a history!
this was late 1990s.
basically: linux had forked libc from GNU. glibc had gotten much better, so they went back to that. this turned out to be fraught. particulary for distro upgrades.
linux was still using a.out binaries so there was the transition to ELF mixed in there too.
there are bits here:
http://www.linux-m68k.org/faq/glibcinfo.html
https://lwn.net/Articles/417866/
https://www.svgalib.org/libc.html
anyway, this experience scarred everyone who ever dealt with it
@davidgerard wait is this eglibc or is that something else?
@davidgerard so much fucking drama lmao
@davidgerard it's actually quite interesting though to think of ELF as the more modern format and to see how that came to life
@davidgerard i wonder if the transition might have been easier if they had decoupled the libc refactoring work from the a.out -> ELF migration
Daniel Barlow@hipsterelectron @davidgerard a.out>elf was technically a separate thing that happened about a year previous, but you have to remember that distro packaging was in its infancy at this time so most people with working systems probably still had a.out and elf libc 5 coexisting at the time that the switch to glibc happened
@hipsterelectron it was the nineties, they were still working out how to do all this shit
Space Hobo@hipsterelectron @davidgerard It's especially interesting when you look at all the COFF history Linux managed to skip over, which was itself a minor part of the Unix Wars.