Linus Torvalds: Someone 'More Competent Who Isn't Afraid of Numbers Past the Teens' Will Take Over Linux One Day (theregister.com)
- Reference: 0180847516
- News link: https://linux.slashdot.org/story/26/02/23/1936208/linus-torvalds-someone-more-competent-who-isnt-afraid-of-numbers-past-the-teens-will-take-over-linux-one-day
- Source link: https://www.theregister.com/2026/02/23/linux_7_0_rc1/
> "You all know the drill by now: two weeks have passed, and the kernel merge window is closed," he wrote in the post announcing Linux 7.0 rc1. "We have a new major number purely because I'm easily confused and not good with big numbers." Torvalds pointed out that the numbers he applies to new kernel releases are essentially meaningless.
>
> "We haven't done releases based on features (or on "stable vs unstable") for a long, long time now. So that new major number does *not* mean that we have some big new exciting feature, or that we're somehow leaving old interfaces behind. It's the usual "solid progress" marker, nothing more.รข
>
> He then reiterated his plan to end each series of kernels to end at x.19, before the next release becomes y.0 -- a process that takes about 3.5 years -- and then pondered what happens when the next version of Linux reaches a number he finds uncomfortable. "I don't have a solid plan for when the major number itself gets big," he admitted, "by that time, I expect that we'll have somebody more competent in charge who isn't afraid of numbers past the teens. So I'm not going to worry about it."
[1] https://www.theregister.com/2026/02/23/linux_7_0_rc1/
I prefer the 2.x numbering scheme (Score:2)
Back then we had 2. for stable releases, 2. for unstable, and big features would lead to a new 2.x version.
maybe we can argue that due to maturity there aren't really big changes any longer though
Re: (Score:2)
slashdot doesn't like using tags and after decades there isn't still an edit button. sigh
Re: (Score:2)
If you use the classic web interface there is an edit button, it's just labeled another way.
First you click preview
When you're done editing you click submit
Re: (Score:2)
The 2.(stable/devel).patchlevel format worked extremely well and stopped version number explosions. The main drawback to it was that it was prior to git, and so the patchlevel could get very high. We also don't need stable/devel, any more, as we've now got one tree for stable and a different tree for devel.
Having said that, I did very much like the three digit split, even though (as Linus as repeatedly said) it was something of a fiction at times. We do sort-of have that, now, with the third digit being use
Re: I prefer the 2.x numbering scheme (Score:2)
Every version of Linux is both stable and unstable. That there are special versions that have not introduced any breaking changes was always an illusion.
Re: (Score:2)
A a fellow old fart, I completely agree. Even minor number was stable, odd was dev as I recall.
Re: (Score:2)
Since that 2037 problem was due to usage of 32 bits, I assume that get solved by moving to 64 bit
Re: (Score:2)
Linux was fixed a long time ago on 64-bit systems, as it uses time_t internally.
Even bad 3rd-party 64-bit code that uses int (or unsigned int) for time MAY work with just a recompile. Any 32-bit code that uses unsigned int for time will fail. Any 32-bit code that uses int for time will have already failed.
Re: love all this high fiving (Score:2)
The kernel is mostly capable of 64-bit time in the ABIs, and [1]has been discussing the transition seriously since 2017 [lwn.net].
But glibc makes the default time_t type as 32-bit on some architectures (i386 and arm32 being the obvious ones still actively used). Each Linux distro has made different decisions on what to do about this and only some of them have made the breaking change to flip glibc configuration over to 64-bit time.
The handful of Linux distros using musl libc should be good to go. And you can always swit
[1] https://lwn.net/Articles/717076/
Math co-processor (Score:1)
Is Linus vector engine made only of Int8? If so, count me in.
Date based versioning (Score:3)
His comment about 7.0 doesn't mean any big new features is why some projects have gone to date based version number: 2026.02.01
Very useless information (Score:2)
This is truly not newsworthy
Old kernels ? (Score:2)
I find Linux great on old hardware. I'm writing this on a 13yo laptop that works wonders for anything: image processing, video editing, servers, etc... And all the family computers are second-hand systems wiped with Linux. Do things ever get removed from kernels in the sense that you just can't upgrade distro/kernel anymore ? I mean, yeah, 8-bit and 16-bit CPUs got removed a while back, but besides that ?
Re: (Score:3)
i486 support was removed around kernel 5.something.
As I said before... (Score:2, Funny)
...Lennart Poettering is the only and obvious choice to fix and unify the bloated, fragmented mass that Linus is not finished creating.
Re: (Score:2)
...yet
Re: (Score:2)
which 8 & 16 bit cpus were ever in the official linux kernel?
intel 386 support was removed a while ago and other functions were broken, like some old graphic card acceleration if I recall correctly
there's likely more old stuff that got broken in new kernels.
Re: (Score:3)
Linux proper never supported any ia16 CPUs. There is ELKS, which was a fork of Linux (I think) or maybe a porting of Linux kernel features to Minux (possibly), that did. A quick looks seems like people are still checking code into a git, but I don't know if its 'official' or who is behind it these days.
Re: (Score:2)
The only issue I've run into regarding old hardware support are with nVidia drivers (I have an old nVidia Goo 7700 GPU that isn't supported by driver versions past 304, which limits me to kernel 4.4 I believe), but that's not the Linux kernel's fault.
Re:Old kernels ? (Score:4, Informative)
Linux removes a feature from a kernel under one of two conditions only:
1. The feature isn't maintained any more AND is now so stale it cannot compile AND nobody is willing to take on the work to make it work
2. The feature refers to hardware that is so obsolete that the number of users is effectively zero insofar as anyone is capable of determining
As a result, you're generally safe with anything that is built into the official Linux kernel tree. The API provided to applications is incredibly stable and Linus reputedly has an army of dedicated berserker Vikings enforcing this.
However, binary-only drivers and non-standard components are another matter, as they're maintained out-of-tree and don't always comply with Linux kernel practices. This is the only area you have to be careful, as distros aren't always clear as to what is official and what is stuff they've grabbed off the net and linked in.