Hacker News Reader

Comment by dimtion | Hacker News Reader

> One of the great things about Linux is its stable and backwards compatible system call interface. This will enable us to ship the latest stable branch of the Linux kernel to all versions of WSL2.

This is a very interesting phrase. Linus often appeared to be yelling at developers not respecting the rule #1 of the kernel. However the kernel being strictly backward compatible is a boon for Linux users, most of the industry should be inspired by this strict policy.

Interestingly, Microsoft (compared to Google, Apple...) is the company providing the best long term support for its products.

View on HN

Also interestingly, the NT kernel is not backward compatible at syscall level. MS even had to invent quite convoluted stuff to run kind of other versions of Windows (but not really...) in their containers, and part of the tech (picoprocesses) was also recycled for WSL1, if I understand correctly.

So I'm really fond of that they wrote: "One of the great things about Linux is its stable and backwards compatible system call interface." I immediately added a big fat: "in contrast with the NT kernel" in my head :D

Neither Darwin or the BSD's (though I'm no BSD expert, I could be mistaken) have a stable system call ABI either. Linux seems to be pretty unique in this regard.

That's not uncommon in Enterprisey OSs. I believe Solaris, AIX and HP/UX are also pathologically backwards compatible.

Oh... And zOS/zVM. "Mature" no longer describe those two. "Timeless"/"Ageless"/"Eternal" would probably be better words.

I don't know about the others but NetBSD has had an even stronger focus on compatability, with some people still running an old binary from NetBSD 0.9 (released in 1993). The one major exception was that the first threading implementation was based on scheduler activations and was completely removed.

Any system that supports static binaries needs a stable system call interface if it wants binary compatibility. IIUC, Windows never supported static binaries.

> Any system that supports static binaries needs a stable system call interface if it wants binary compatibility. IIUC, Windows never supported static binaries.

I feel like you're just playing semantics here. Windows refers to syscalls by name rather than number (which IMO is better), so the numbers aren't the static entities; the static entities are the names. That's static to me. I don't see a single thing that referencing by numbers vs. names would gain you.

https://en.wikipedia.org/wiki/Dynamic-link_library

https://en.wikipedia.org/wiki/Static_library

I'm not saying Windows is wrong (other systems later changed to dynmaic linking but some still have support for static linking) it just means that you can't replace only the kernel with a new major version and expect it to work (another issue there is kmem grovelers which I think Linux is entirely rid of but NetBSD isn't quite).

IIUC, most of the major issues with Windows compatability are due to developers not following the documented system interface and directly calling the explicitly unstable and undocumented system calls directly. Stuff that uses the documented interface continues to work indefinitely.

The origin of the stable syscall tradition in unixy systems is not fixing the same issues that Windows has but is due to the historic use of static binaries.

> the NT kernel is not backward compatible at syscall level

I don't think they officially guarantee it, but would you mind elaborating on this? They change the syscall numbers frequently, which you never ever use on Windows (you reference them by name instead), but any syscall that I've ever used (NtCreateFile, NtQuerySystemInformation, etc.) has been rock solid/stable. What syscalls have you seen broken in the past that users were actually relying on?

> However the kernel being strictly backward compatible is a boon for Linux users

Unfortunately the rest of the echo system like glibc people have not learned this rule. So practically it's not as beneficial as one would hope.

Reply on news.ycombinator.com