Linux 7.0 Kernel Confirmed By Linus Torvalds, Expected In Mid-April 2026 (9to5linux.com) 75
An anonymous reader writes: Linus Torvalds has confirmed the next major kernel series as Linux 7.0, reports Linux news website 9to5Linux.com: "So there you have it, the Linux 6.x era has ended with today's Linux 6.19 kernel release, and a new one will begin with Linux 7.0, which is expected in mid-April 2026. The merge window for Linux 7.0 will open tomorrow, February 9th, and the first Release Candidate (RC) milestone is expected on February 22nd, 2026."
Rust? (Score:2, Interesting)
Re:Rust? (Score:4, Funny)
It'll be written in javascript and distributed only in encrypted, containerized bninaries.
Re: Rust? (Score:2)
Re:Rust? (Score:5, Informative)
It's just a numbering scheme. Linus thinks .19 is already big enough number to increment the major release number, even without any new feature introduction. So 6.19 is the last 6.x version, as had happened with 3.19, 4.20, 5.19.
Switch to current numbering with 3.0 in 2011 (Score:2)
You might have mentioned that the current flat numbering scheme started in 2011 (see, e.g. https://www.linuxfoundation.or... [linuxfoundation.org] or https://en.wikipedia.org/wiki/... [wikipedia.org]). Before, there were stable branches (e.g. 2.6.x), seperately numbered from development branches (e.g. 2.5.x).
Re: (Score:1)
Sure as soon as a developer at Anthropic uses a couple dozen parallel Claude agents and burns through $50k of compute time. No problem. It's the future.
Re: (Score:2)
Just curious - will it be written in Rust?
A little bit of it will
Re: (Score:2)
Re: Rust? (Score:2)
This is an A+ joke. If I had points rn, you'd have them.
Re: (Score:2)
I'm fine with it as long as it doesn't steal all the Oxygen from C.
It's spelled Doxygen, but I don't think Linux uses it.
Re: (Score:1)
Just curious - will it be written in Rust?
Applesoft BASIC.
Re: (Score:2)
Re: (Score:2)
There are already non-GNU alternatives for these utilities with non-copyleft licenses. BSD use them.
GNU utilities will remain in C and licensed under the GPL. There is a competing project called uutils with the goal of re-writing clones in Rust. That project also happen to use the MIT license. But this project may fail or succeed (even if it works, it doesn't mean people are going to ditch the GNU utilities). But what matter is that this is a competing project.
The Linux kernel doesn't have a direct competit
Re: (Score:2)
I know about BSD, and use it over Linux. I'm talking about projects that are redoing these GNU projects in Rust to re-license them: I'm not the one doing it
The reason I make the analogy is that there are people who are rewriting existing software in Rust, like in the case w/ uutils. Likewise, I wonder whether Linux too will be re-written that way
Re: (Score:2)
rewriting existing software kind of imply that it's the same organization switching from C to Rust and from GPL to MIT.
It's more like a clone here. And as far as I know, there is no major project of writing a Linux kernel clone.
Also if uutils end up good, the GNU project could always fork it and license it under GPL.
Re: (Score:2)
It's the first kernel where Rust is officially part of the kernel, the experiment with Rust APIs and some kernel components being written in Rust being considered a success in general.
C is not going anywhere, and still has a relatively privileged role in the kernel, but Rust will hopefully make it easier to write and maintain many drivers and file systems that the dependence on C has made maintenance a liability for.
Major new feature in 7.0 (Score:2)
Re: (Score:2)
Well then Linus is lucky Sun Microsystems open-sourced java from the start so we can have openjdk now because Oracle would have for sure sued Linus into oblivion:
https://www.baeldung.com/java-... [baeldung.com]
Running out of fingers and toes (Score:5, Informative)
Re:Running out of fingers and toes (Score:5, Interesting)
Another popular way is date based numbering. So the kernel just released could have been 2026.02, the next prolly 2026.05, the last 2025.11. It doesn't really matter.
Re: Running out of fingers and toes (Score:2)
Should have been Linux 26.xx.
And the first Linux I used should have been Linux -5.xx a nice small number
Re: Running out of fingers and toes (Score:2)
Linux95! *Crashes immediately*
Re: (Score:2)
Another popular way is date based numbering. So the kernel just released could have been 2026.02, the next prolly 2026.05, the last 2025.11. It doesn't really matter.
Yes eclipse IDE does that and so do I for my own software releases. At some point although, version numbers were more indicative of major structural changes but not so much anymore if you look at Google chrome or Firefox release number for example.
Re: (Score:2)
Re: (Score:2)
Another popular way is date based numbering. So the kernel just released could have been 2026.02, the next prolly 2026.05, the last 2025.11. It doesn't really matter.
All good until the Americans go from 2026.05.01 to 2026.03.02
Re:Running out of fingers and toes (Score:4, Interesting)
No more dumb than any other versioning scheme. I'd rather see a version 7.0 than a version 6.25.3.
Re: (Score:2)
False. The versioning scheme you compare it to has significant meaning. You just described something that shows major version 6, minor version 25, and point release 3. Historically these had very clear implications to users.
Point releases: bug fixes.
Minor releases: introduce new features.
Major releases: introduce major foundational features or introduce a changes which may have compatibility implications.
The fact that you would "rather see" a smaller number means that you never understood what the numbers m
Re: (Score:3)
I understand the versioning scheme just fine. My problem with it, just like most others, is that is wasn't used the same way across the board. Different developers how different definitions on what counts as major or minor. Some developers only change major numbers on compatibility changes only. If this became the de facto and only way to version any and all software, along with clearly defined rules so everyone does it the same, I'm on board. But since that will never be the case, none of it even really ma
Re: (Score:2)
It doesn't need to be used across the board. It just needs to be used consistently within a project. Versioning schemes provide information to your users. As long as the users have an understanding of how you publish versions they can get useful information on it. That doesn't help if you select version numbers based on "feels".
By the way interesting discussion here. One that shows a huge and dramatic shift in the mindset of Slashdot over the years. Back when Linus first announced bumps in major versions wi
Re: (Score:2)
As long as the users have an understanding of how you publish versions they can get useful information on it.
Yeah, and, like I said, most of them don't understand. Which is exactly why there has been a shift. And I'm tired of the inconsistency from one project to another.
Re: (Score:2)
The thing is, this isn't something that needs to be meet the needs of all. Version numbers are not UX design. Without looking it up, what version of Chrome or Firefox are you using right now? Or what Linux kernel do you have installed? I bet you can't answer it because it has no impact on your design.
Most users don't need to understand versioning. But for those who do, having a sane versioning system is invaluable. This is developer level enshittification started by Chrome.
Re: (Score:2)
*Used to be*. Stop living in the past.
I'm not "living" in the past. I'm lamenting one, one that was saner.
Every kernel has significant changes
Wow. Everyone would be smarter if you just never commented on programming related topics again.
Re: (Score:2)
Less dumb than others.
I'm running Linux version "death in the void". This software requires Linux version "constipated badger" or newer to run.
So er...
Did I mention I find code names irritating?
Re: (Score:3)
No, the major.minor.point system is actually useful. Second best is a date based system if you intend to release major releases on a regular basis, but major.minor gives you a sense of what versions are comparable, what versions included breaking changes, etc.
Version numbers just becoming completely meaningless is one reason I really feel our entire industry is going downhill at the moment. Another example of us ignoring long held standard practices that were there for a reason because "new is shiny". And t
Re: (Score:3)
No, the major.minor.point system is actually useful. ... major.minor gives you a sense of what versions are comparable, what versions included breaking changes, etc.
This is only assuming it's being used accurately and correctly, ideally by following Semantic Versioning 2.0. But that hasn't been, and isn't, the case for a LOT of software, hence why I don't find it any better in practice. It *is* better on paper, however.
newcomers like yourself come along and have no idea why we did those things
Incorrect. I'm am not a newcomer and I know full well how everything works. However, I cannot fix the laziness and stupidity of the end users who don't want to bother to learn or understand anything. I cannot fix the developers who choose to version howe
Re: (Score:2)
NetBSD? (Score:2)
Yeah, what exactly is the role of NetBSD now? Just running on ancient hardware? Incidentally, for all its talk about running on a potato, NetBSD was never ported to the Itanic. FreeBSD at one point was, but not NetBSD
Right now, there are just 3 current CPU platforms out there - x86, Arm and RISC-V. Both FreeBSD and OpenBSD support all 3. OpenBSD also supports some, but not all, legacy CPUs, such as PA-RISC, Sparc, Power, MIPS and Alpha. FreeBSD only supports, in addition to x86, Arm and RISC-V, the
Re: (Score:2)
Development, if you're creating a multi platform piece of software NetBSD is the way to go, it has Vulkin support better then OpenBSD, it's better at cross-platform development then FreeBSD, so to make a piece of software that's compatible with everything that is pretty much relevant you only need GCC and Mingw-Win64
If you're looking at developing something like a game engine, developing it on NetBSD gives you the easiest path to all the relevant targets.
The BSD and Linux by coding pure C++ makes them porta
Re: (Score:2)
Welcome to version numbering in software. Its all dumb.
This is also why so many rolling releases have moved on from version numbers, and just do year/month instead.
Yeah (Score:2)
Re: Yeah (Score:2)
8 to 10 was also Microsoft.
Re: Yeah (Score:2)
Re: (Score:1)
And Star Wars - 4 to 6. They should really get on making more of those!
Welcome to Whose Line Is It Anyway? (Score:2)
The show where everything is made up and the points don't matter. That's right, the points are like the Linux kernel versioning scheme!
Re: (Score:2)
To me a big part of Linux's long lasting success has been the fact it has had a truly benevolent overlord so this is just part and parcel of that. Stopping at 20 should be tradition for its continuing future.
Re:Running out of fingers and toes (Score:4, Insightful)
Re: Running out of fingers and toes (Score:3)
Vibes based versioning was the industry standard when Linux began development.
Re: (Score:2)
FWIW, Linux 7.0â(TM)s major version increase is primarily a numbering milestone, not a signal of a single massive breaking change or new feature set. Linux kernel version numbers are sequential and historically donâ(TM)t imply strict semantic meaning; number bumps have happened for pragmatic reasons (cleaner versioning and manageable minor numbers) rather than functional messaging.
Always kind of assumed the versioning scheme is a psychological device to get all those who maintain older custom forks of the kernel to not get too hopelessly out of sync. Sort of wow you are on 7 and we are still on 5.. maybe we should update.
Re: (Score:2)
For a while the scheme DID matter. From 1.0 to 2.6, evens (and zero) were stable, odds were development.
2.6 stretched from 2003 to 2011 when Linus just declared that instead of the next version of "stable" being 2.6.40 it was going to be 3.0.
Re: (Score:1)
For a while the scheme DID matter. From 1.0 to 2.6, evens (and zero) were stable, odds were development.
That was the time frame when The SCO Group for one of its lawsuits wanted the source code for the non existent Linux 2.7. Couldn't give what never existed and never would exist either. They did a lot of stupid things in that set of lawsuits.
Re: (Score:2)
Linux kernel version numbers are sequential and historically don’t imply strict semantic meaning
I wouldn't use the word "historically" like that. You're describing two vastly different histories. It's like saying "historically" Europe has been a continent of peace because there's been no war in the past 70 years.
"Historically" Linux kernel version numbers prior to 4.0 had a strict semantic meaning. The move from 2.0 to 2.2, 2.4, and 2.6 all introduced major feature changes to the underlying kernel function which often introduced compatibilities issues. E.g. 2.6 introduced SE Linux. 2.4 changed the und
Damn I'm getting old (Score:4, Funny)
Re: Damn I'm getting old (Score:5, Informative)
Pick up the loadable module part and then I think Character devices are essentially the same. Network and block devices are a little more involved. Cgroups, name spaces, I/O memory allocators, device tree. Those things are new and need a little work to learn them if you need to support them.
Re: (Score:2)
But also, you maybe don't have to.
Linux is becoming ever more microkernelish. Quite a lot can be done from user space these days. USB drivers, filesystems, block and character devices, human interface devices, sound devices and so on.
It's pretty neat really!
Re: (Score:2)
Re: (Score:2)
It's a hybrid system. And I think it will always be a hybrid.
You can do file system and simple USB drivers in user space. And this has a stable ABI and it's easier to debug. Ideal if you want to make something quick or if you have some project that isn't going to make it into the main kernel.
For hardware vendors, they should really consider developing and upstreaming a kernel mode driver. It's going to offer the best performance and widest features and easiest end-user experience (automatic modprobe on udev
Re: (Score:2)
It's not so much that they're moving as now for many subsystems there are drivers that forward all the syscalls back out to user space so new things can be written in userland.
Writing custom USB drivers is a complete breeze for example now. You can use higher level languages than C, and crashes crash the program, rather than bring down the OS. There's a load of funky FUSE filesystems for things that it would be barmy to have kernel drivers for, like Borg.
I honestly don't know about networking stacks. I'd ha
Re:Damn I'm getting old (Score:4, Funny)
Only that Kernel major numbers are not "eras". (Score:2)
This is a non-event.
Say hello to VBA kernel support (Score:2)
No more messing around with C or Rust, just write everything from kernel drivers to kernel ai agents in your favorite Microsoft editor!
BInary would be so much more efficient (Score:2)
IIUC Linus counts minor version numbers using his fingers and toes using unary arithmetic - hence, no minor version numbers above 20. Now if he used binary - easily implemented with fingers (straight = 1, bent = 0), we could have 1024 minor versions before we'd need a major bump. That would save 98% of useless articles like this on slashdot and no doubt many other outlets.
(Note, using binary in this way impacts typing, so perhaps Linus would pull changes less often. This needs to be factored into any sav
Re: (Score:2)
Were the kernel versions that topped out at 19 the ones where one of Linus' fingers was otherwise occupied signalling opinions to mailing lists?