Linus Torvalds: Someone 'More Competent Who Isn't Afraid of Numbers Past the Teens' Will Take Over Linux One Day (theregister.com) 36
Linus Torvalds has pondered his professional mortality in a self-deprecating post to mark the release of the first release candidate for version 7.0 of the Linux kernel. From a report: "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."
"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."
Old kernels ? (Score:3)
Re:Old kernels ? (Score:4, Informative)
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:3)
...yet
Re: (Score:2)
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)
LOL! Somebody stole the name "Minux":
https://www.minux.io/ [minux.io]
Maybe you meant MINIX?
Minux:
"Minux" commonly refers to a lightweight, minimalist Linux distribution, often based on TinyCore Linux or as a custom Arch Linux metadistribution, rather than the 1987 Unix-like operating system MINIX. These "Minux" versions aim to provide a functional, terminal-based or GUI-driven, and resource-efficient computing environment.
Minux (TinyCore Base): A 24MB Live CD ISO that includes FLTK/GTK applications, JWM window manager, and various tools.
Minux (Arch-based): A shell-script-installed metadistribution focusing on a terminal/Vim/tiling window manager environment for learning purposes.
Alternative Uses: "Minux" also refers to architectural lighting fixtures and extendable console furniture.
Note: Often, users mistakenly type "Minux" when searching for the academic operating system MINIX.
Minix (Score:2)
Ha, even the name "Minix" has been stolen by a Hong Kong based company that makes mini PCs [minix.com.hk]. Too bad AST never thought of copyrighting at least the name. In a YouTube video of one of their products, I saw somebody suggest that they run Minix on those Minix computers
Re: (Score:2)
I guess you mean trademarked? You have to keep using and protecting your trademark for it to stay valid, I doubt he'd have wanted to bother with that.
You don't have to copyright anything, you have a copyright on all works you release automatically unless you declare it public domain. But the key concept here is "works", you can't copyright something short line a product name or a simple slogan. So there would not even have been a way for him to prevent someone else using the name Minix just on the basis of
Re: (Score:2)
Well, the Minix OS had stopped any development since version 3.2, so like you say, trademarking wouldn't have worked. But had he copyrighted the name Minix, so that only he could have used it, then there wouldn't have been a company applying that name to mini PC boxes that it makes
Fun factoid: UNIX is the name of a property development company in India that X/Open doesn't seem to have heard of
Re: (Score:2)
Yes but
1) you can't copyright mere names.See https://www.copyright.gov/help... [copyright.gov] ("Names are not protected by copyright law. Some names may be protected under trademark law.")
2) you don't have to copyright your works, they are copyrighted by default, although in 1987 the US still required a copyright notice to be added, BUT
3) the 1st edition of "Operating Systems: Design and Implementation" where Minix was first published, HAS a copyright notice: (c) 1987 by Prentice Hall inc.
A PDF of the 1st edition can be f
Re: (Score:3)
Re:Old kernels ? (Score:5, 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.
Re: (Score:3)
Even 32-bit support is on its way to getting removed, unless one is willing to stick to the last old version that supported it. Yeah, Linux is portable, but that means squat if the support for hardware platforms gets dropped just b'cos they are too old. Maybe freeze the kernel at a point, maybe say version 6, but continue to release security updates for them, as long as they want
Otherwise, the only option these legacy hardware platforms have is NetBSD, which has no plans to ever drop anything. Only har
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:3)
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)
Actually, I've found that using the date of release in the form YY.mm is the best way to number these, as opposed to the double decimal template eg 5.3.2. That way, let's say that a version released in January 2026 has a bug, that version will be 26.01. Let's say that bug gets fixed in February, then 26.02 will be the bug fix version. Let's say that in April, a new Nvidia FOSS driver gets released and added. That can then be 26.04, and so on. I'm assuming that they won't be releasing multiple releases
Re: (Score:2)
You seem to be suggesting that there is a difference b/w internal version numbers (within a project) and the version numbers released out to the public. I'm talking only about the latter. Internally, the project devs can call it anything. In fact, since this current system seems to work for them, they can keep using it for internal purposes. Something like Windows XP being NT 6.0 or something
Re: (Score:2)
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:3)
The kernel is mostly capable of 64-bit time in the ABIs, and 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
Re: (Score:2)
Even on 32-bit systems and glibc, you can get a 64-bit time_t and 64-bit off_t by compiling with:
-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64
Unfortunately, it's up to application developers to do this. IMO, it really should be the default.
Math co-processor (Score:1)
Date based versioning (Score:3)
Very useless information (Score:1)
Version numbers (Score:2)
Linus should make the next version of Linux 12 or higher, that way Microsoft shits itself and releases Windows 360 or One or some other dumb name because marketing told them consumers go with the biggest number.