With 20 digits
one can count to 1048576.
Penguin emperor Linus Torvalds has announced the next version of the Linux kernel will be version 7.0, a matter of some small interest, because it continues his convention of not using version numbers he can’t count on his fingers and toes, and perhaps cements a numbering convention that sees kernel series end with version 19 …
That's if you treat each digit as binary.
You can count higher if you extend it a bit - each finger can be fully closed, partly open (i.e. the finger joint connecting to the hand is opened, but all joints in the finger closed), or fully open.
That said - I don't know many people who can individually control all of their toes, so you probably can't rely on even binary there (or possibly treating it as 2 digits per foot - big toe, other toes, I suspect many people can do that much)
You can actually count to 32 very easily on just the fingers of both hands.
You just point to each horizontal line on each finger with the tip of your thumb before moving to the next finger.
I've used my fingers like that plenty of times. I've never used my toes though.
So you could then actually get to 42 if you also used the toes.
Another useful trick is to use the fingers of one hand for 1-16 as described above and the fingers of the other hand to count how many 16's. 16 x 16 = 256.
A bit like counting in hexadecimal but retaining decimal numbers.
A fact, which when pointed out to a supposed IT teacher by my daughter at school, was poo poo'ed. That the teacher was instantly proved wrong didn't help their mood. And we wonder why we lag behind other countries.......
On the plus side said daughter is heading for a decent degree in CS, iirc the IT teacher had a degree in geography maybe.
Why so many?
According to Gemini:
"As of February 2026, there have been exactly 143 major mainline releases of the Linux kernel. This count tracks every "base" version released personally by Linus Torvalds, from the very first prototypes in 1991 to the current version, 6.19
Indeed, that is also how I understood it. Rugby for gentlemen who moisterise but still have a feeble constitution (hence all that padding and all that). But hey, we are understanding and all for inclusion! (BTW what time is the next 6 Nations game on?)
Didn't grok that all.
For whatever reason I thought superbowel was a baseball event not that travesty of armoured rugby.
On the very few occasions I have been in a sports bar and caught a game on their big screen I have impressed (not) by how slow and frankly boring (excepting perhaps the cheer leaders) the whole silly proceedings are.
I would liven it up by equiping the participants with 2.4m (8') star pickets a let them go to it, in a full melée but I suppose that would be indistinguishable from (ice) hockey.
There is significant evidence for this based on the history of brain damage in USA football in particular. Of course protective equipment is protective, but it has also decreased conscious efforts to avoid injury, resulting in the statistics we see today. The rules and armour have coincidentally aligned to create strategies undermining personal safety for an edge.
Rugby, "a game for gentlemen with odd-shaped balls."
A now-departed friend who shared my total disinterest in Football (the non American sort, though I have a total disinterest in that, too) suggested that the games would be greatly enlivened by burying a small landmine somewhere on the pitch before each match. Harsh, possibly, but I can see where he was coming from.
"I would liven it up by equiping the participants with 2.4m (8') star pickets a let them go to it, in a full melée but I suppose that would be indistinguishable from (ice) hockey."
That sounds more like a description of what typical British football fans used to get up to on the terraces to show their support of their chosen team. Inter City Firm, etc. The lyric of my favourite Billy Bragg song," The Few" derides it perfectly.
Being a nordic chap a misadventure in arctic climes might accelerate the major version numbering although he didn't actually specify that said digits needed to still be attached or indeed still in his possession.
I personally would suppress minor version numbers with trailing zeros. When I first encounter X.10 back in the day when we weren'I so agile, I assumed it was X.1.
So I propose X, X.1 ... X.9, X.11 ... X.19, X.21 and Linus gets to keep his fingers and toes :)
If you reject x.10 because it looks too much like x.1, why does x.11 not seem like it comes between x.1 and x.2? We have two choices: interpret a version number as a single decimal number or split at the . and interpret each component as an integer. Since there are three digits in the Linux version number, that seems the most logical option.
I remember when single arbitrary precision decimal numbers were more common as version numbers and it was a pain. Sometimes, people would release version 2.0, then a large change but not large enough to make it 3.0 (especially as this was also the day when upgrades to a new major number would usually cost money), so they'd jump straight to 2.5. Then they had to make a fix to something in that, so that was 2.6. Since bug fix added 0.1, the next small feature update would be 2.8 to distinguish it, and now there wasn't enough version number left for more than a bug fix release, so they started making 2.94 and 2.96. Semantic versions seem easier to manage properly.
That fixes how to parse it, but it doesn't fix how to not run out of numbers if the numbers have any meaning. In Linux, they seem not to; the major version number changes whenever Linus says without needing to mean anything. For many other projects, it does mean something, usually that a large change has been made, possibly one which would have an effect on downstream software. In commercial software, it's still sometimes sold where major updates require purchase of an update whereas minor fixes don't. In both cases, switching from 1.x to 2.x because x ran out of space can cause problems, which is why I prefer the integer version where x can grow if it needs to.
> We have two choices: interpret a version number as a single decimal number or split at the . and....
The obvious fix, being used by several softwares, is to date it.
With any of the many date-formats the world has standardized on.
*MDY (Month, day, year) *DMY (Day, month, year) *YMD (Year, Month, Day) *JUL (yy/ddd) *ISO (YYYY-MM-DD) *USA (MM/DD/YYYY) *EUR (DD.MM.YYYY) *JIS (YYYY-MM-DD)
If issuing more than one per day, add the time (your choice of format).
This doesn't work on its own. Imagine that I've made software version 20260131. Then I make a big, breaking change in version 20260202. Some people don't want to deal with that just yet, so they don't update. But we find a security vulnerability in the old code from 20260131 so we fix that in a version we release on the 8th of February. What version number does that get? If we used the date and made that 20260208, it would be bad. If people set their machines not to update after 202602XX, they won't get the patch. If people did update to 20260202, they get downgraded to the old version with the fix. Everyone would be unhappy.
That's why version numbers have come to involve multiple parts, so that the size of a change can be communicated in the version number and users can respond accordingly. If you want to put a date as the lowest order component, you can do that as long as you use YYYYMMDD because that number will always increase, but if you use that as the whole thing or in any other location, it breaks.
For many years new versions of TeX and METAFONT (which invariably are just minor bugs fixes) have added another digit of π and e to their number with the stipulation that on his death, Donald Knuth's code will be frozen and moved to version π and e.
Current versions are:
TeX: Version 3.141592653
METAFONT: Version 2.71828182
Your guess is correct IME; to reboot or not is distribution-specific behavior, or at least the default configuration is.
E.g. my couple of remaining Debian hosts are configured to auto install updates, but they don't auto reboot; I could configure them to do so -- there are well-commented options around several reboot scenarios in the /etc/apt/apt.conf.d/50unattended-upgrades file for that.
There's us no such limitation. It can do this just fine, but almost nobody who actually uses their computer for more than one task wants automatic reboots, so it is almost never enabled by default.
Look at your distro specific system documentation to enable it, or try shutting your machine at the end of the day when the had been an update. This is a non-issue.
Nope.
One of the absolute best things of Linux is that it doesn't do things I didn't ask it to do.
I switched to a Framework laptop over Christmas, with a plain Linux install. Honestly... it's refreshing. I spend 10 years on Slackware previously and under Windows I absolutely always missed the control I used to have.
On my Framework, it told me there was a kernel update available. It waited for me to say it was okay to download it (I'm on DSL as I have ZERO choice in my location... it's DSL or quite poor 5G that's slower than DSL, so ... sorry... I don't want stuff just downloading without asking... it literally knocks everything for six from my other downloads, my media streaming or even my gaming). When downloaded it asked if I wanted to install it. Again... I don't want it upgrading libraries underneath me without knowing. Or churning my storage/processor unexpectedly. Then it installed almost all of them except the kernel update which it just said I would have to reboot to activate.
No problem. It just told me. It didn't force me. It didn't schedule it. It didn't start bugging me while I'm working / gaming. It didn't forcibly close my apps. It just... told me.
And when I rebooted it didn't spin off until an eternal, interminable, indeterminate purgatory of letting me know that it was "Updating... Please Wait". It just rebooted... and came back up. That was it.
By comparison, I booted up my old Windows laptop to get some files off it and FORTY FIVE MINUTES LATER I was still waiting for it on that updating screen, unable to do ANYTHING about it. I didn't get a chance to delay, postpone, defer, undo, stop, cancel or anything. I just turned it on... it decided updates were required... and I couldn't use the machine for 45 minutes while it applied updates... to a computer that I wanted to grab two files from and then turn off forever.
No way on earth I want to go back to that. Sorry. I manage Windows for a living, but I have to be paid to do so. At home, I'm now entirely Linux again and - as I said almost the same day as I did that - it's boring. Things work. They do what I say. I don't have to trick the OS into co-operating. I don't have to be told "No".
You want auto-reboot on kernel update? That sounds like one line in some configuration file or script somewhere. But, no, nobody sensible wants that on by default. Not people running servers, not people running home machines.
And I can remember the days of Linux kernel "trampoline" (running a newer kernel inside an older kernel to save rebooting), etc. That's the way we should be going (I believe it's been reinvented as "kernel live patching" or similar). Not forcibly restarting people's machines underneath them without confirmation.
Linux always understood one thing. I'm the user. The computer exists for my benefit. Not the other way around.
Already installed and running; gotta love how Debian tracks the kernel releases so much faster than Ubuntu and the other distros. There are advantages to being the "upstream" distro. Can't say that I see any issues, but that is one of the true joys of being a Penguinista - you don't have to concern yourself about whether your system will actually BOOT after an update like you do with Windblows...
Several things have led to the 3.10 < 3.9 confusion, which does indeed break updates.
The earliest was the conflation, in ASCII, of the decimal point with the full stop (AKA period).
Before this, decimal values were always hand-written with the dot between the units and the fraction mid-way between the top and bottom of the surrounding digits. Even on a typewriter this was easily done.
If ASCII had such a distinct radix-point character, we’d have used it and avoided the ambiguity.
The full stop is positioned like a decimal point but expected to serve as a separator.
In the dying years of Amiga Inc we recognised this and opted, belatedly, for ‘chapter and verse’ format with a colon between the parts. Thus 3:10 is clearly > 3:9
More than 40 years ago Sinclair QDOS addressed the collation issue by interpreting embedded numbers within strings using the same code used to parse floating-point expressions, so that in SuperBASIC etc. Fred0brain matches Fred0.00e1brain, eliminating the error by parsing the number as an arithmetician would do, rather than treating it as text. Case folding was optional and took a year to get right (for the internationalised MG versions of QDOS). One remaining surprise was that a full stop was treated as a degenerate form of zero (0.0 with null digit strings either side) - this could and arguably could have been sifted out as a special case, but the devs were still trying to squeeze a multi-tasking networking device-independent OS into 32 kilobytes (eventually shipping a 32K core and 16K localised part) so that opportunity was lost.
Expecting contemporary strcmp to catch up with Sinclair’s UT.CSTR seems a long shot after four decades, and though we have distinct decimal point glyphs in UCS typing them is platform-dependent and often non-trivial, so I still commend and use the chapter-and-verse approach, starting from 0:0 - or, if you prefer the major/minor/point (ugh) scheme 0:0:0