Announcement

Collapse
No announcement yet.

Linux 6.1 Will Likely Be This Year's LTS Kernel Release

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Linux 6.1 Will Likely Be This Year's LTS Kernel Release

    Phoronix: Linux 6.1 Will Likely Be This Year's LTS Kernel Release

    This shouldn't be particularly surprising but the in-development Linux 6.1 kernel will likely be this year's Long-Term Support (LTS) kernel version...

    https://www.phoronix.com/news/Linux-6.1-Likely-LTS

  • #2
    What I love about a new Linux LTS is it gives the *BSDs something to base their wifi and graphics support off of. OpenBSD 7.1 and soon 7.2 are pulling DRM from Linux 5.15.x. I worry that AMDGPU won't have all the bits in place for modern cards on NetBSD 10 because they are pulling from Linux 5.4 LTS. I don't know what LTS FreeBSD pulls from.
    Last edited by kylew77; 07 October 2022, 06:32 AM. Reason: EDIT: so basically 6.1 LTS will give OpenBSD good support for ARC Alchemist cards hopefully so I can pick one up for my desktop!

    Comment


    • #3
      Google will prefer that 6.1 will be the LTS as that reduces the need for them to have extensive patchsets for MGLRU on their Android and ChromeOS trees. Also that may mark the introduction of more Arm (QCOM and MTK) socs either in mainline or in the DRM tree that also helps the ChromeOS front.

      Comment


      • #4
        It will be great if 6.1 will be the next LTS kernel!
        I just hope that MGLRU will be accepted and merged in it.

        Comment


        • #5
          As long as those things are disabled by default it shouldn’t bother the use cases that need ultra high stability. Anyway, the kernel also isn’t RT yet.

          Comment


          • #6
            Originally posted by ATLief View Post
            As long as those things are disabled by default it shouldn’t bother the use cases that need ultra high stability. Anyway, the kernel also isn’t RT yet.
            isn't it usual for ultra-high-stability stuff to compile the kernel with custom flags anyway to reduce exposure to issues on stuff that doesn't even need to be there?

            not that the default config should be unstable for the sake of enabling half-baked features... afaik kernel devs judge this systematically for all new features and if they deem something half-baked they'll either hide it behind a kernel flag to ease wider testing or not accept the merge to mainline yet if in any way dangerous to gave it... so if it's merged and enabled it has been deemed good enough for normal use, right?

            Comment

            Working...
            X