[HN Gopher] Linux 6.1 Officially Promoted to Being an LTS Kernel
___________________________________________________________________
Linux 6.1 Officially Promoted to Being an LTS Kernel
Author : 0xDEF
Score : 144 points
Date : 2023-02-08 13:04 UTC (9 hours ago)
(HTM) web link (www.phoronix.com)
(TXT) w3m dump (www.phoronix.com)
| AlexAltea wrote:
| 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?
| russdill wrote:
| 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.
| deaddodo wrote:
| > 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.
| [deleted]
| ElectricalUnion wrote:
| 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.
| jxy wrote:
| LTS is a promise that the devs will break less things.
| infamouscow wrote:
| Greg Kroah-Hartman explains the differences:
| http://www.kroah.com/log/blog/2018/08/24/what-stable-kernel-...
| megous wrote:
| 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.
| mort96 wrote:
| 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.
| megous wrote:
| 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.
| mort96 wrote:
| 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.
| megous wrote:
| 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)
| mort96 wrote:
| 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.
| acatton wrote:
| LTS kinda garantees that the internal APIs will not change,
| allowing for upgrades without reboot using something like
| Ksplice.[1] (aka "Hot patching")
|
| [1] https://en.wikipedia.org/wiki/Ksplice
| hedgehog wrote:
| 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.
| dezgeg wrote:
| 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.
| olau wrote:
| 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.
| e12e wrote:
| Any recent lists/posts on "top changes" between previous lts and
| 6.1?
| AstixAndBelix wrote:
| Why don't Linux devs give different labels to the LTS releases?
| Somehow a kernel version that gets supported for 7 years is the
| same kind of LTS as one that gets supported for 3.
| capableweb wrote:
| They do, they label it LTS :)
|
| It seems they don't know beforehand which releases will be
| labeled LTS though, it happens after the release itself.
|
| > eg KH was planning on Linux 6.1 being LTS given its December
| debut. But he was waiting on feedback from kernel stakeholders
| over their test results with Linux 6.1 and plans around using
| Linux 6.1 for the long-term. He's finally collected enough
| positive responses -- along with co-maintainer Sasha Levin --
| that there is confidence in maintaining Linux 6.1 as an LTS
| series.
| jmclnx wrote:
| > It seems they don't know beforehand which releases will be
| labeled LTS though, it happens after the release itself.
|
| This I do not understand. I think for commercial reasons it
| would be good to know:
|
| * The next LTS
|
| * Its actual real "Life Time"
|
| well before its release. I think this will help commercial
| entities and some distros in their planning (maybe even the
| distro I prefer). Right now it seems rather random.
|
| But with that said, years ago, I heard some kernel developers
| would like to stop having LTS kernels. I wonder if these
| somewhat unplanned LTS announcements is one of the reasons
| for that thought.
|
| To me, if they cannot have a formal planning process, maybe
| better not to have any LTS kernels.
| LoganDark wrote:
| LTS has _never_ meant "life time support", it means "long
| term support". "long term" means more than usual. LTS
| versions stay supported for some years when other versions
| are only supported until the next version comes out.
| AstixAndBelix wrote:
| That's not what I'm saying. There is a huge difference
| between a release that gets updates for basically a decade
| and one that gets updates for less than an Android phone's
| cycle. Why can't they call them Really Long Term Release or
| somethinf like that?
| nazgulsenpai wrote:
| Linux kernel actually does have a SLTS designation for
| super long term release. https://wiki.linuxfoundation.org/c
| ivilinfrastructureplatform...
| pavon wrote:
| When it comes down to it, it is the distros (including
| Android) that decide which kernel versions they are going
| to use and for how long. Upstream doesn't always know this
| in advance, and only have limited influence in nudging
| distros to use certain kernels, since the big distros do
| their own patching and backporting anyway. There is no
| point for upstream to continue to support a kernel for 10
| years if no one is actually using it 3 years later. So
| instead they give an initial support window, and extend it
| if the kernel becomes popular and no serious maintenance
| issues are discovered.
| orangepurple wrote:
| Because it sounds like the designation is negotiated with
| many parties simultaneously and there is a lot of
| uncertainty in the process. It seems that once a critical
| mass of supporters pledge to maintain the branch for a
| while it becomes designated LTS. You can't force anyone to
| maintain it for a really long time so they won't commit to
| a timeline. I am speculating this is why.
| billfruit wrote:
| Is the PremptRT path merged in to the Kernel mainline as of this
| version?
| RDaneel0livaw wrote:
| I'm running an up to date Manjaro system, and although I have
| kernel 6.1.9-1 available as an option, it's not installed and
| it's not listed as LTS nor is it "recommended".
|
| Does this mean that'll change soon with an update, and I should
| start running this kernel?
| Shared404 wrote:
| You may want to move away from Manjaro in general[0], but I
| would advise against doing anything that the OS doesn't expect
| you to do - so I'd wait for an update.
|
| [0] https://github.com/arindas/manjarno . EndeavorOS seems like
| a pretty good "Arch but easy" distro these days, and maybe
| Manjaro's improved since the last time I ran it (a few years
| ago now)
| RDaneel0livaw wrote:
| Thanks for the info, and the link. I will read it over. I'm
| thinking I'll probably move back to PopOS when they release
| their DE Cosmic. I used to run pop and loved it, but really
| wanted to try an arch distro. Endeavor looks great, but I'm
| not interested in anything "terminal centric" which is the
| first sentence on their site. But thanks for the suggestion!
| Shared404 wrote:
| PopOS is one of my favorite distro's, I can't wait for
| Cosmic to come out.
|
| Even if I don't go back to Pop on all my boxes, I may
| standardize on Cosmic as my DE.
| e12e wrote:
| Why run "an arch distros" - why not just run arch?
| phillnom wrote:
| Manjaro w/ KDE was my daily driver OS for several years
| before I switched to EndeavourOS w/ KDE a few months ago.
| The only major difference between the two that makes
| EndeavourOS more "terminal centric" is that you have to use
| the CLIs pacman and yay for installing packages, as Pamac
| the GUI package manager is something Manjaro provides. That
| said, I highly recommend making the switch and think with
| some small adjustments, you'll feel right at home.
| beebeepka wrote:
| CLI-centric does not sound great for an HTPC, though. I
| think Manjaro is not bad choice for hassle free TV
| computers with modern hardware. It has much better
| hardware support than Ubuntu out of the box. Updates
| rarely break something other than Gnome (I find anything
| else incredibly hard to use on a TV) extensions. It does
| not get in the way and it rarely needs my attention.
|
| Yeah, it's a easy use. That's a major plus in my book. I
| really don't want to babysit my appliances.
| brink wrote:
| Fwiw, I'm well aware of those issues cited, and still choose
| to use Manjaro as a daily driver.
| Shared404 wrote:
| Completely valid.
|
| I used Manjaro for a while and had recommended it to a
| semi-technical friend and it blew up in my face, so I tend
| to mention the issues when I see people using it.
|
| Nothing wrong with choosing it of course as long as one is
| aware of the issues.
| capableweb wrote:
| Because everyone loooves Rust, you'd be glad to know that this is
| the first Linux release with initial Rust support, so Rust is
| officially in the kernel now and will run on bunch of computers
| shortly, no matter if you want it to or not (granted you run a
| Linux kernel of course).
|
| > Among the key highlights for Linux 6.1 are the initial Rust
| infrastructure has been merged
|
| https://www.phoronix.com/review/linux-61-features
| Denvercoder9 wrote:
| > will run on bunch of computers shortly, no matter if you want
| it to or not (granted you run a Linux kernel of course).
|
| Probably not. The Rust support merged in 6.1 was only the bare
| minimum of infrastructure needed to write kernel modules in
| Rust, there's no modules in the kernel that actually use Rust
| yet. You need to explicitly enable the Rust infrastructure with
| a config option during compilation, and e.g. Debian doesn't do
| that yet (why would they?).
| LoganDark wrote:
| > Rust is officially in the kernel now and will run on bunch of
| computers shortly, no matter if you want it to or not
|
| I believe Rust is only used for a few kernel modules at the
| moment.
| seanw444 wrote:
| Other than the headline of "Rust kernel module mainlined" I
| don't know what this entails. Do you need the entire
| rustc/cargo toolchain to compile this portion of the kernel? Or
| have they implemented some Rust compiler in gcc that it uses?
| conradev wrote:
| Rust support was merged into GCC in December:
| https://www.phoronix.com/news/GCC-13-Rust-Merged
| chaosite wrote:
| That doesn't sound right, are you saying that the kernel
| depends on an unreleased version of GCC (13.1?)
| Narishma wrote:
| No, it doesn't. It uses the regular LLVM compiler.
| conradev wrote:
| Nope - the kernel currently requires LLVM to compile any
| Rust code
|
| GCC 13.1 will bring the first LLVM-free Rust kernel
| builds
| nequo wrote:
| > Rust is officially in the kernel now and will run on bunch of
| computers shortly, no matter if you want it to or not
|
| To me as a user, what difference does it make if the binary
| that I run was compiled from Rust, not from C? It is machine
| code.
| biorach wrote:
| As a user of the kernel, none, right now.
|
| Long term there should be some improvement in reliability and
| security, if things work out as planned.
| jjnoakes wrote:
| I also think it will bring faster development and easier
| testing.
| howinteresting wrote:
| And a new generation of developers who have found C too
| intimidating to write code in.
| jacobr1 wrote:
| I don't think that is the problem. Rather it turns out
| everybody has been naive in thinking you can actually
| successfully manage memory, or other shared resourced in
| C without footgunning yourself.
| howinteresting wrote:
| Those are definitely related but distinct. The fact is
| that many younger developers will simply (for this and
| other reasons) refuse to contribute to a C (or C++)
| project, but happily do so to a Rust project.
| billfruit wrote:
| Also does this lead to an increase in dependencies for
| building the kernel? How about building it for older
| hardware?
| e12e wrote:
| Anyone know if there are implications for Asahi Linux, especially
| on m2 macbook air?
|
| Judging from https://github.com/AsahiLinux/docs/wiki/Feature-
| Support it looks like a lot of m1 stuff needs 6.2, and most of m2
| is "edge" (which I suppose means might be mainline 6.3 at the
| earliest..)?
| NoahKAndrews wrote:
| I don't think Asahi Linux will ever limit themselves to an LTS
| kernel. The whole point of it is specialized drivers that take
| time to get into a mainline release, nevermind the ongoing
| improvements and march of new hardware. I could see them
| eventually settling on stable kernels though.
___________________________________________________________________
(page generated 2023-02-08 23:02 UTC)