Comment by delta_p_delta_x
4 hours ago
> To be fair, if you use only the Linux syscall interface, then a program that you compiled on x86 in the 90s will probably still run anywhere today. Linus is adamant about this.
This is frankly the opposite of how it should've been. Who cares that the kernel ABI doesn't change from release to release? As an end-user, I couldn't care less. Even as a developer I care very little indeed, because I'm not writing drivers. I'm almost never programming directly against the kernel's interface but rather using my language's standard library, which is already an abstraction over the kernel interface.
Platform vendors (this includes distro maintainers) should recompile and re-package libraries for each new ABI in each OS release, done. End-users won't ever notice, they can run their applications portably because the user-mode library ABIs haven't changed... Which is what Win32 has done, and what glibc has consistently failed to do.
The funny thing about the glibc situation is that glibc really doesn’t provide improvements to any of the kernel interfaces or really any comfort stuff for developers. If anything the fact that it is bound by the C standards makes it worse than using the kernel API directly besides that for whatever reason the kernel headers seem to lack a fair number of definitions. That could just be a me problem though.
I think Windows also discourages people to use their syscall directly. It could change from version to version so they should use the API.