> For one, the FreeBSD kernel specifically has a compatibility layer for Linux binaries to use their familiar syscalls [0].

I believe this strengthens my argument. Linux kernel-userspace interface is so stable other projects are implementing it. I remember Justine Tunney mentioning this before, the idea that the x86_64 Linux system call ABI is turning into some kind of lingua franca of systems programming.

https://justine.lol/ape.html

> x86-64 Linux ABI Makes a Pretty Good Lingua Franca

Would be interesting if people started targeting Linux because of this, banking on the fact that other systems will just implement Linux. Even Windows has Linux built into it these days.

> For its ordinary syscalls, it also has a policy not to break binary compatibility without good reason.

Thank you for the source. I don't think that's a particularly strong guarantee. It's certainly stronger than OpenBSD's at least.

> Most other OSes just don't maintain quite the level of 'indefinite stability' that the Linux kernel does across different versions

Yeah. I think this is something that makes Linux unique.

> And even Linux doesn't implement older versions of syscalls when the kernel is ported to new architectures, so eventually you have to rotate your implementation regardless, if you want people to run your code on new systems.

That's true. Only new architectures are affected though. The old ones have all the old system calls, many with multiple versions, all supported. Porting to a new architecture doesn't invalidate the stability of existing ones.

> People often say "X is impossible" when the truth is "X is tricky and full of caveats, and I don't want to think about it, so stop asking".

> Or if the devs themselves are saying it, it might be "I want to look like I'm 'tough on crime' toward users of undocumented behavior"

I get what you're saying. I truly apologize if I came across that way. I did not mean to say that.

I got interested in this low level direct system call stuff because I literally got sick of reading "but you, mere mortal, are not meant to access these raw system interfaces, that's for us, you are meant to call the little library function we made for you" in the Linux and libc manuals. Last thing I want is to end up doing the same to others.

By "can't do this" I meant to say the developers maintaining the system don't want you bypassing their system libraries and won't take responsibility for it if you do so. If the program breaks because the kernel interfaces changed, they'll tell us it's our own fault and refuse fix to it.

Linux takes the opposite approach: breaking user space makes Linus Torvalds yell at the people until the breakage is reverted. I'm enthusiastic about it because it's the only system where this is supported.

> As for compatibility issues, you're running into that the moment you start doing undocumented fun stuff like omitting ELF sections or overlapping headers

I agree. Should be fine as long as the ELF specification is respected. It's okay though, ELF is flexible enough that even in 2024 it's possible to invent some new fun stuff.

https://www.matheusmoreira.com/articles/self-contained-lone-...

Embedding arbitrary files into an existing ELF and patching it so that Linux automatically maps it in before the program even runs. Since Linux gives processes a pointer to the program headers, the file is in memory and reachable without a issuing a single system call.