Silly question: if Linux kernel interfaces e.g. syscalls are stable, why is there a need to create an LTS release? How can non-LTS updates affect differently than updates within the LTS branch?
They won't add features but will fix bugs in it. Like distributions with long term support.
You may ask why this matters, but I just installed 6.1 in Debian (testing) a couple of days ago, and it has a fatal bug in a graphics driver I think (AMD iGPU Ryzen 5) - as soon as I start a browser in GNOME, the signal to the monitor is lost and I have to reset. I installed 5.18 in the console, and it works fine.
I haven't figured out how to report the bug, but I also have a hunch that it's probably already fixed. And that's why you make these long-term support releases. You stop refactoring/adding features that destabilize the code, and just fix bugs, and end up with a well-tested fossil. In theory you'd have automated tests of everything, and then you wouldn't need these fossils. But in practice you don't.
It also means that there's a fixed target that can get an extended amount of testing in the field, and when fixes for that version come out you know you're getting issue X fixed but no other change in behavior. Less chance of incidental breakage.
Um, no, I have not seen anything that would be the case for upstream Linux. Sure, downstream distributors like Red Hat might be able to give such guarentees, but they do not generally use upstream LTS releases directly.
Linux (POSIX systems in general, really) userland syscalls are very stable even in non-LTS, this is as you point not the issue. However, that is only the interface to the userland - the "kernelland" driver/modules interface is not garanteed stable.
This and LTS releases usually receiving important security backports reasonably quickly (compared to non-LTS versions) unless you somehow have certain expensive "Enterprise Linux" licenses and can coerce the licensor to do the backporting of the security fix for you.
It's super important for hardware that is not fully upstreamed or other projects that carry a large patch burden. The solution is of course to upstream, but being able to pick a stable kernel and run with it for years without rebasing everything just to get a few security updates is a big win.
> if Linux kernel interfaces e.g. syscalls are stable
Syscalls are not the Linux Kernel interface. Syscalls are core mechanisms to access protected/secure resources. Memcpy, fopen, etc. But the Kernel has much more to it's ABI than just syscalls and those are not guaranteed to be stable.
There's no such need for regular users. I upgrade to linus/master branch regularly since ~4.4, and there's no API breakage, aside from regressions (expected for -rc* kernels, I think) or very obscure stuff like media pipelines changing shape and whatnot.
Are you kidding? If you're on slightly unusual or esoteric hardware, the chance that something about your system breaks after a kernel upgrade is not insignificant. The chance is much lower when upgrading from one LTS point release to another.
Why would I be kidding? Userspace ABI doesn't break much at all. Unbootalbe system is also quite rare. Obscure drivers may break, but I just fix them or wait a bit if I don't have time, that's why I run rc kernels, afterall. But that's not an ABI break.
I wasn't disputing your userspace ABI thing. But you said "There's no ... need [to run an LTS kernel] for regular users". Regular users like their hardware not to break, which means LTS kernels are useful.
If everything is working for you, and you don't need any features or enhancements from a newer kernel, it's totally reasonable for a normal user to not want to risk frequent kernel upgrades.
LTS != stable. On average there's a LTS upgrade every 7 days. Mainline's release cadence is 3 months.
There are a lot of changes going into longterm supported branches: 10s of thousands of patches that were developed and tested against a different codebase written many years into the future are being backpatched into up to 6 year older codebase on top of other randomly picked patches with a hope/assumption that everything will work out the same way it does on mainline. It often does, but uh...
Mainline gets months of testing for each final release, stable releases get about a week of testing at most.
I definitely put my trust into mainline as a regular user. I also like the support for my HW to keep improving as a regular user, which mostly happens with mainline, if I have recent HW.
I view long term supported releases as speciality release useful for some very specific situations, like for device manufacturers who dislike instability of internal kernel apis and can validate each such release against extensive testsuite before pushing it to users. I would not run it as a normal user. (maybe with an offset of several releases, to have more testing for each stable release by others before I move to it)
Well, given how frequently kernel upgrades break stuff, if what you're saying about LTS reliability is true, I suppose the only reasonable solution for regular users is to never update their kernel. Or use a distro which holds kernel releases back for months to do their own validation, like Ubuntu and Debian.
You may ask why this matters, but I just installed 6.1 in Debian (testing) a couple of days ago, and it has a fatal bug in a graphics driver I think (AMD iGPU Ryzen 5) - as soon as I start a browser in GNOME, the signal to the monitor is lost and I have to reset. I installed 5.18 in the console, and it works fine.
I haven't figured out how to report the bug, but I also have a hunch that it's probably already fixed. And that's why you make these long-term support releases. You stop refactoring/adding features that destabilize the code, and just fix bugs, and end up with a well-tested fossil. In theory you'd have automated tests of everything, and then you wouldn't need these fossils. But in practice you don't.