I have both written software for standards-based protocols, and used software written to standards-based protocols, so no, I would not expect it.

Not breaking backwards compatibility for existing users is the golden rule of software support. When an unfortunate pull-requester attempts to break backwards compatibility with Linus Torvalds' software, he has some very choice language to complain about the practice. If they were attempting to break backwards compatibility just because they dis-liked some particular app or service or use case, he might even use foul language.

Fortunately, I am a very well behaved and good little HN user, so I will not repeat that language here. But imagine what Linus would have said, really loudly, with all capital letters. There. That's better.

Linux breaks backwards compatibly all the time. Just not for userland programs. But if you are expecting your kernal module to be low maintenance you are in for a surprise...

The kernel has a clear definition of what will be backwards compatible, and what never will be. In-kernel interfaces are never stable, and kernel-to-userspace interfaces are very stable, with an ABI docs directory breaking out what is and isn't.

https://github.com/torvalds/linux/blob/e7aa8c2eb11ba69b1b690...

If the kernel's user interface just started blocking on open for 4000 milliseconds for no apparent reason, people would not be happy. Firefox expects users to demand that app writers edit, recompile, test, and ship them a new app to prevent the block. This is <insert lots of not very nice adjectives>.

This is an interesting example because the kernel's open() interface blocks for 4,000 ms all the time. Heavy swapping or the ext3 journal is full and some other app just called fsync().

Apps have to handle it. If they don't, because for example, they access the disk while also trying to be a display compositor, then they are simply broken. It does not matter if the kernel is usually fast enough. Because sometimes it isn't.

Do you know what the reason for this distinction is? On Windows, it seems kernel-mode APIs seem to stay quite stable as well... there are exceptions mostly on the device driver side because hardware tends to evolve (e.g. display/graphics drivers), but generic drivers (= kernel modules) generally seem to be able to rely on backwards-compatibility too.

My understanding is that it's to intentionally discourage trying to keep things out of tree, where they will inevitably break in worse ways. It also makes the GPL enthusiasts happy, but I doubt that was Linus's big goal.

I see, thanks. I'd be curious as to why he feels it would "inevitably break in worse ways", seeing as how that's not really the case on other platforms.

Basically, if you're going to have drivers out of tree, the driver ABI has to be perfectly stable, which restricts internal refactoring. Otherwise things break - and this does happen elsewhere; lots of drivers for Windows XP don't work on 10.