I think you just stressed TowerTall's point.
They are saying: "Recent versions of Windows can run old programs made for old versions of Windows. How?".
The Linux kernel is very good at it because of the "Do not break userspace" Linus Torvalds' rule. The usual user space on top of the Linux kernel, not so much.
So yes, backward compatibility and backporting are different matters.
And Windows addresses them both indeed. Your parent commenter is not comparing Windows with Linux.
You pay microsoft for that support.
You can have 10 years support for linux, just pay red hat for it like you pay microsoft.
https://learn.microsoft.com/en-us/lifecycle/products/windows...
NT6.1 (Windows 7) was also supported from 2009 to 2020 (11 years!), and NT 5.1 (Windows XP) was supported from 2001 through either 2014 (13 years!) or 2019 (18 years!) depending on support channel.
Microsoft will support a product for a decade if not more, assuming you're keeping up with security updates which they absolutely will backport. Linux with 2 years is a bad joke, by comparison.
So honest question: What does 10.0.22621.900 mean? Is 10.0.X.Y supported for a decade or is that discontinued at some point and I am forced to upgrade to 10.0.X+10,Y-5?
As an example from https://superuser.com/questions/296020/windows-kernel-name-v... lists
> 6.1.7600.16385, 6.1.7600.16539, 6.1.7600.16617, 6.1.7600.16695, 6.1.7600.16792, 6.1.7600.20655, 6.1.7600.20738, 6.1.7600.20826, 6.1.7600.20941, 6.1.7601.17514, 6.1.7601.17592, 6.1.7601.21701
Are these all just 6.1? Or is 7601 a different version than 7600? Could I choose to stay on 7600 and get backports or do I have to switch to 7601?
Yes. The numbers after the Major.Minor numbers are just revision and build numbers of little consequence for most people.
Are you here for thoughtful conversation or are you just being a Micro$oft Windoze troll? Because I can't tell; I would presume most people here know how to read version numbers.
It's pretty disrespectful to call Linux's process a "bad joke" when these developers mostly aren't getting paid to maintain major versions for any length of time that you'd consider more reasonable.
Meanwhile, if you do want longer-term support for a specific kernel+OS combo, IBM/Red Hat (among others) will be happy to sell it to you. You may think it's inefficient for each enterprise distro to have their own internal kernel fork that they maintain (rather than all contributing to a centralized LTS kernel), but that's the choice they've all seemingly collectively made. I guess they feel that if they're on the hook to support it, they want full and final say of what goes into it.
Also consider that Windows doesn't sell a kernel: they sell a full OS. In the Windows world, you don't mix and match kernel versions with the rest of the system. You get what Microsoft has tested and released together. With Linux, I can start with today's Debian stable and run it for years, but continue updating to a new major kernel version (self-building it if I want or need) every two months. The development and support cycle for an OS is very different than that of a kernel. You just can't compare the two directly. If you want to, compare Windows with RHEL.
Also-also consider that Windows and Linux are used in very different contexts. Microsoft's customers may largely care about different things than (e.g.) Red Hat's customers.
https://superuser.com/questions/296020/windows-kernel-name-v...
it seems that Microsoft does a mix of backports and upgrades:
> 6.1.7600.16385, 6.1.7600.16539, 6.1.7600.16617, 6.1.7600.16695, 6.1.7600.16792, 6.1.7600.20655, 6.1.7600.20738, 6.1.7600.20826, 6.1.7600.20941, 6.1.7601.17514, 6.1.7601.17592, 6.1.7601.21701
So this does not look like 10 year support for the initial version but rather like switching different LTS versions over that time. Is there any data from microsoft itself on support duration, release dates, backports and how to parse these numbers?
To me, though, 6.1.7600.16385 -> 6.1.7601.21701 does sound like long-term support for a single "version" (whatever that word means in this context).
Windows has had three major releases in 11 years. The Linux kernel does one every two months. Windows is an entire OS, with a userland and GUI. The Linux kernel is... a kernel.
The development and support cycles are naturally going to be very different for the two. And regardless, the mainline Linux kernel team is not beholden to anyone for any kind of support. Whatever they do is either voluntary, or done because someone has decided to pay some subset of developers for it to get done. Microsoft employs and pays the people who maintain their old Windows versions.
If no one is paying someone enough to maintain an old Linux kernel for six years, why would they choose to do it? It's mostly thankless, unrewarding work. And given that the pace of development for the Linux kernel is much much faster than that of Windows (or even just the Windows/NT kernel), the job is also much more challenging.
But backwards compatibility isn't what kernel developers are maintaining, they're backporting things like security fixes to older versions of the kernel.
It would be like if a security fix is implemented in Windows 11, and Microsoft also chose to patch the same change in Windows 10. At some point Microsoft decides that older version of Windows won't get new updates, like how Windows 8.1 stopped receiving them this January.
What kernel developers are deciding is that sufficiently old enough kernel branches will stop receiving backports from newer kernels.