Linus Torvalds hails 'historic' Linux 5.10 for ditching defunct addressing artefact

Linus Torvalds has given the world the first release candidate of version 5.10 of the Linux kernel and called out what he's labelled an historic change – the removal of an addressing tool that appears to have been around for nearly 30 years, sparked a nasty bug a decade ago but has since been made redundant by chipmakers. That …

[Anonymous Coward]

Trim that long gray tail

I'd like to see this called out more often. Seeing bits taken out as no longer needed means to me they are tracking the codebase well. Lest the ghosts of architectures past rise and trouble everyone's sleep in exploits.

[Chris 3]

Re: Trim that long gray tail

Good by PowerPC 601 :(

[FILE_ID.DIZ]

Re: Trim that long gray tail

Whew.... my Apple Network Server 700 lives to die another day!

[Yes Me]

Yes, but...

Wanna bet that no box somewhere is gonna install this and brick itself as a result? There's always one out there.

[Jonathan Richards 1]

Re: Yes, but bet...

I might... what odds are you offering? :) Because I think "brick itself" might be a bit strong. "Bricking" implies irrevocably turning a functioning device into inert building material, and since this is about memory management, I would have thought that the worst that could happen would be clobbering applications, and that reverting to 5.9 would restore operations. The candidate machine would have to be running on some seriously old and obscure hardware, but IME there are indeed many of those.

[Missing Semicolon]

Re: Yes, but...

Via Eden processors aee now officially dead.

[Ogi]

Re: Yes, but...

> Via Eden processors aee now officially dead.

Crap, my main firewall is still running an old Eden mini ITX board, as is my garage PC, and my point to point wifi bridge.

I guess this means I can no longer upgrade Linux on it? That unnerves me, especially for the firewall & Wifi Bridge, which I always keep well patched and up to date.

Seems silly to have to junk perfectly working HW that is doing its job just fine just because of removal of existing software logic.

[Missing Semicolon]

Re: Yes, but...

Slackware still has a real 386 build.

[Ilgaz]

LTS is for that

You just switch them to a Linux LTS kernel such as 5.4.x and live happily next 5+ years

[Anonymous Coward]

Re: Yes, but...

"Wanna bet that no box somewhere is gonna install this and brick itself as a result? There's always one out there."

Of course there will be some, but the good thing is, they won't matter at all, since they will only be used as a sordid museum showcase.

The alternative, which is to keep *all* codebase, VMS, MPE, WIN16, i286, etc ...,aka never cleanup anything, has spectacularly failed already with OpenSSL !

I can't resist to quote the openBSD folks on LibreSSL/OpenSSL here:

https://www.openbsd.org/papers/bsdcan14-libressl/mgp00001.html

[Anonymous Coward]

Re: Yes, but...

So, the alternative is to do what Microsoft does with Windows?

[Anonymous Coward]

Re: Yes, but...

> There's always one out there.

At least six so far, judging by your downvote tally. :-)

[Anonymous Coward]

bye bye 2038

Happy to see "crushing the 2038 bug"

[DJV]

Re: bye bye 2038

Yep, that just leaves the Year 10,000 problem to sort out at some point.

[Usermane]

Re: bye bye 2038

Year 10,00? https://www.reddit.com/r/startrekstabilized/comments/26y9v8/star_trek_freak_out_xpost_rimagestabilization/?utm_medium=android_app&utm_source=share

[Anonymous Coward]

Re: bye bye 2038

Year 10,00? The Normans will be popping over for a chat in a mere 66 years time.

[theblackhand]

Re: bye bye 2038

Shhh - if they perfect stasis in our lifetime I was planning to use Y10K to fund my retirement

[Mage]

Re: bye bye 2038

I think the HC/HE system is better, none of the no year zero stupidity in the middle. It's currently the year 12020. Also avoids the AD BC CE BCE issues, though doesn't solve ambiguity about British dates after general change from Julian to Gregorian Calendar but much much later in Britain. Other systems are available. China (had about 5 changes), Jewish, Moslem and Hindi apart from largely defunct calendars.

There are different issues:

1) The separate physical clock on some systems with its own battery and usually a 32.768 kHz crystal.

2) A clock on some CPUs using a sleep mode and a separate 32.768 kHz crystal. Some are not limited by a clock register.

3) A clock on some CPUs with no special hardware that relies on the gadget never being powered off.

4) Any firmware or BIOS that might not be easily updated

5) An embedded OS that could be using Linux Kernel that can't be updated or is unlikely to be updated.

6) Many Linux devices and Android things that could be updated, but the makers are either gone or won't update.

7) Different levels: HW / FW clock, OS clock, GUI clock/calendar, application clock/calendar. Spreadsheets seem very limited on the date/time assuming everything is an AD/CE Gregorian date. DIY functions for other systems are hard. Especially timelines for fictional worlds, or even simply Mars.

[S4qFBxkFFg]

Re: bye bye 2038

"I think the HC/HE system is better, none of the no year zero stupidity in the middle."

For those wondering; being rid of the "AD1-1=BC1" issue would be very nice indeed.

[teknopaul]

Re: bye bye 2038

Normal 64 Unix time is OK for most uses and easy for interop with other systems Inc browsers.

There are so many wierd realities of representing time in computers: better the devil you know.

[Mage]

Re: bye bye 2038

Also just kill the mm/dd/yyyy, mm/dd/yy, mm/yy and all the variants <month name><day><year>

I notice ebay Ireland and ebay UK both use the daft USA <month name><day><year> format.

ISO yyyy mm dd at least is unambigious except as to calendar type and the same way round as writing quantities of anything, numbers or time.

[MacroRodent]

Re: bye bye 2038

> ISO yyyy mm dd

The nice thing is it is almost equally inconvenient to everyone. Except the Chinese. Judging by the mail headers I get from some colleagues there, their native date format is like 2020年10月26日 where I guess the Chinese letters stand for year, month and day.

[Anonymous Coward]

Re: bye bye 2038

In Europe alone, at least Basques and Hungarians have always used big-endian dates.

[heyrick]

Re: bye bye 2038

If it's the same wibbles as Japanese, then 年, 月, and 日 are year, month, and day respectively.

Actually, 月 means moon and 日 means sun, which mostly corresponds to the time periods involved.

By the way, I use and write an almost ISO date format (I use slashes instead of dashes). Way back when I had to deal with British stuff and American stuff and it got really confusing. So I decided screw this, it's (four digit) year month day and no ambiguity. I even write dates like that on papers at work, which some people think is weird but nobody complains about because again it's just bloody obvious. Plus it sorts nicely if expressed as a character string...

[seven of five]

Re: bye bye 2038

Same here. Though I use dashes to eliminate any possibility to take it for US formatting.

Takes a few months until you do it subconciously.

[J27]

Re: bye bye 2038

People can adapt to things like that easily, it might take a few months tops.

You are right about what those letters stand for.

[Nick Ryan]

Re: bye bye 2038

That's better than not using the month name and having ambiguous dates and is at least translatable by those for whom English, or even American, is not a first language.

[MacroRodent]

Re: bye bye 2038

I actually prefer yyyy-mm-dd notation, even in private notes to myself. I also find the Chinese variant cool, and would use it, if entering those glyphs were convenient on a Western keyboard...

[J27]

Re: bye bye 2038

They are, you just need a Chinese or Japanese IME.

[Claverhouse]

Re: bye bye 2038

Do you remember 7448 ? That was a very good year...

[greogory]

This is why we can't have good times.

I was hoping to still be around to contract out my late septuagenarian skillset, have some fun and maybe make a few bucks in the mad dash of debugging & coding a language "The Youth of The Future"™ never learned four months before New Year's Eve Plus 18 Days to mitigate Y2K3XV3I©, just like I did in my early 30-somethings for OGY2K© and "The Youth of The Past"™.

[heyrick]

Re: This is why we can't have good times.

"The Youth of The Past"™.

The telly at work played Depeche Mode's "Just can't get enough", to which I was absent mindedly humming along to. The announcer said it was a song released in 1981.

Then the bastard added, thirty nine years ago.

F... I swear my hair instantly went grey...uh...greyer...

[seven of five]

Re: This is why we can't have good times.

Black Sabbath is more than fifty years old. *shrugs* Was quite a ride, now wasn't it? Lets see whats next.

[Mage]

Random

A Roman numerals wristwatch demo in javascript. Designed to use a mask and a very small number of LEDS with PIC18F or ARM Cortex M0. The check box seems to simulate pressing the crown, which might be a rotary encoder that is also a push button. Or maybe USB could be used to set time, simply in terminal mode?

The Romans used scribes that used other number systems and also the abacus. They invented the idea that the day changes at midnight instead of dusk. They also managed to run the Etruscan 8 day week and the eastern Med 7 day in parallel for a while. The Babylonians and Ancient Celts had the more logical 13 months, but the Babylonians changed to 12 as it meant easier arithmetic in some respects. That's why there are 13 Zodiac signs. The Jewish system adds a leap month to keep Solar and Lunar time (months = moons) re-synced. Moslem system seems to ignore Solar - Lunar corrections.

[A.P. Veening]

Re: Random

The Chinese calendar also adds a thirteenth month every time it is necessary to keep Solar and Lunar time in sync, the reason why Chinese New Year and Vietnamese New Year (Tết) keeps shifting around. But if you want truly accurate, I suggest you use the old Mayan calendar.

[Alumoi]

Re: Random

Wait, what? I thought the Mayan calendar stopped in 2012!

[Tom 7]

Re: Random

Nope, they just started again at year 0. Sound familiar?

[seven of five]

Re: Random

Actually, they have added a sixth cycle on the outside. A bit like an odometer.

[Robert Carnegie]

Mayan calendar?

In this context, who is or are "they", exactly?

[RobThBay]

Re: Random

The crown seems to toggle between normal time, stop watch and calendar ("D" is displayed).

[FlintMcC1956]

RISC OS did this in the 1980s

Acorn Computers RISC OS has a date roll over similar to 5.10 of 2250 or thereabouts in the 1980s with a 26bit processor why has it taken so long for Linux to catch up?

[Anonymous Coward]

Re: RISC OS did this in the 1980s

Because Linux's architecture is derived from an experimental system written in the early 70s, which no rational individual thaught would still be in use 60 years later.

Whereas riscos was written from scratch by a bunch of people who, Probably werent thinking of end-dates either, but had different design parameters and decided to represent their dates differently.

[NullNix]

Re: RISC OS did this in the 1980s

The 64-bit time_t stuff has been landing for many releases now, and time_t has always been 64-bit on 64-bit platforms. This is all filesystem work, which is much harder because the data is persistent and people like not to lose it. In this case, XFS format v5 is gaining 64-bit stuff for filesystem timestamps, in a backwardly-compatible way that does not require a mkfs: that's all. (Bear in mind that the original XFS is a child of the early 90s, so not all that much newer than RISC OS.)

[NullNix]

This article almost entirely wrong, to the point that I wonder whether the author has done any research whatsoever or knows anything at all about the x86, even the names of the registers in its register file.

%fs and %gs originated with the 386, not the 286, as ten seconds research would show. As Linus himself said in the very announcement you link to, the kernel hasn't used %fs to point to user memory since sometime before the start of git history, and it certainly hasn't been 'made redundant by chipmakers': %fs and %gs are the only two segment registers that are still useful in x86_64 long mode, and indeed the kernel still uses them, as does userspace.

It's just that the kernel no longer uses a function call that happens to still be called set_fs() (for purely historical reasons) to address userspace memory while in kernel mode, that's all. (Instead this security-sensitive thing is now done at the lowest possible level, in the smallest possible number of places, in the access primitives themselves, not scattered across all the individual drivers that do the accesses.)

[James 47]

Isn't at least of them used for thread local storage?

[MacroRodent]

tls

Yes, FS is used for that on 64-bit x86 Linux. It is not the address of the thread-local storage (obviously, segment registers are still just 16 bits), but points to where the address can be loaded.

[the spectacularly refined chap]

The article is fine, of you had taken more time to read it instead of amazing us all with your encyclopedic knowledge of x86 you might have noticed that.

%fs has no special meaning within x86, it is simply another segment register at the programmer's disposal. The name simply reflects a historic convention in the Linux kernel itself rather than architectural features of the underlying silicon.

The hardware feature at play here is protected mode to ringfence processes access to memory. The very protected mode introduced in, oh, that would have been the 286.

The article doesn't even reference any register by name, so enlighten us all as to how the article is in error.

[NullNix]

But in that case the article makes no sense! Linux never *used* 286 protected mode: 286 protected mode is not "being removed by chipmakers" but rather (depending on your viewpoint) either is still here

or ceased to exist as soon as the 386 came along (386 protected mode is a strict superset except for 286 LOADALL, which was never documented). 386 protected mode is also not being removed, not for a very long time. Segment prefix overrides, ditto (heck, gas just had a bug fixed with regard to segment override printing), though many overrides do nothing in long mode.

Regardless, Linux never worked on the 286 in any case.

So... nothing has been "made redundant by chipmakers", this change has little or nothing to do with the 286 (on which %fs never existed, so set_fs obviously never worked there even back in the days when it used %fs)... and set_fs being removed is a purely kernel-internal thing that has no relationship with anything being made obsolete by Intel... or whichever "chipmaker" is being vaguely alluded to here. It stopped using the %fs register ages ago, but that doesn't mean %fs has been removed, just that this particular use for it has gone away. (It is in the ABI. It cannot be removed without breaking every program that uses thread-local storage. %fs is forever.)

My impression of an article written by someone who didn't know what he was talking about persists.

[the spectacularly refined chap]

The historical protected mode worked on segments and came in with the 286. This was retained with the 386 but with paging implemented under the segmentation. With the transition to x86-64 essentially segments no longer exist - it's a flat memory model only and your protection is by page only. Protected segmentation is thus largely redundant, in that you can jump straight from real mode to a flat 64 bit page.

Sure, in practice segment based protection has been gone and this is what the article explains. It's thus a purely historical artifact that has now been phased out.

[oldcoder]

There was no reference to %fs or %gs as registers. I think you missed the boat.

Only set_fs macro.

[NullNix]

But then what was the thing being "made redundant by chipmakers"? As far as I can tell the only possible answer to this is "nothing": segment overrides still exist and still work just as well as they did last year. This change is not being implemented because of changes from "chipmakers" (Intel? AMD? the RISC-V Foundation? At this point it could be anyone).

The article is more than half nonsense.

[Claverhouse]

More Light, More Light

There's also Anno Lucis used by our friends the Freemasons.

Just add 4000 years.

[Anonymous Coward]

The One True Way

Is to measure time starting from the Big Bang. In Planck units, naturally.

[seven of five]

Re: The One True Way

Add another bit to signify pre-bang time. Better save than sorry.

[Mage]

Ancient Systems

I've installed used UNIX, XENIX (386 only) and earlier CROMIX (dual Z80 /68000) in the 1980s.

MINIX in maybe 1991

Full NT 3.1 and Linux Kernel came out in 1993. I did use NT from about 1994 and briefly 3.5 on a 386. Everything NT since on at least a 486 and I used Linux from 1998. Maybe last installed OpenWrt on a 486 like device (PC Engines SBC for a router maybe using a Geode SoC) in about 2007.

I don't think I've installed a Workstation or Server Linux on less than a Pentium 4 in over 15 years.

I might have a 486 somewhere with WFW 3.11. The 286 did have I think a version of UNIX or XENIX, but I never used it. The main point of it was more RAM on DOS and it was mostly used as an 8086. Pointless in most computers compared to a 68000. Really the 386 was Intel's first consumer 16 /32 bit CPU used as 32 bits usually. The 8088 / 8086 wasn't a real 16 bit CPU at all. At least the 286 had a real 16 bit mode, even if only XENIX commonly used it. Really the 486 was dead by the time Linux was usable. Though I think the PII was inferior to P-Pro for NT and it was the PIII that coincided with rapid rise of Linux on Servers. The Segmented Addressing was an evil fudge to make porting 8080 8bit code automatic?

I've seen Power PCs running MAC OS9 at the latest, maybe 15 years ago? Not sure. What is a PowerPC 601 CPU used in?

[amacater]

Re: Ancient Systems

286 could run Xenix / Mark Williams Coherent. Everything else needs 386 and above. AT&T's 3B1 was a Motorola, I think. Linux needed a 386

I couldn't get hold of / afford Coherent - the first machine i had that could run Linux was a 486 - my first laptop was a 386SX which, if I could find it, has an 80M disk and 4M of memory - it does run Debian - installed from floppy disks :)

[Down not across]

Re: Ancient Systems

I've installed used UNIX, XENIX (386 only) and earlier CROMIX (dual Z80 /68000) in the 1980s.

In the 80s, for x86 I used Mark Williams' Coherent and it was rather excellent (ran very nicely on i286 and earlier versions ran even on 8086 IIRC).It was also very reasonably priced unlike Interactive UNIX 386/ix that I did later use on some i386 boxen.

I've seen Power PCs running MAC OS9 at the latest, maybe 15 years ago? Not sure. What is a PowerPC 601 CPU used in?

I have a Quadra with 601 on a separate card (for some reason DayStar comes to mind, but it was long time ago and I can't be bothered to rummage for it).

[Denarius]

Re: Ancient Systems

I used AT&T Unix 5.2 on 286 for real work in early 1990s. Ran well so long as user count < 5. Ran Xenix III on a 8086 with Z80s doing terminal management for amusement for a while before booting early RH in mid 1990s. I had colleagues complaining how RISTOS was so much better. I was puzzled that AT&T could fit a real OS with 14 character names and multi-user on a 286 while DOS struggled to do one user and one task at a time until I did a bit of OS theory, being told DOS was not an OS, but a stand-alone monitor. So pleased times and OS have moved on. Now if only someone could kill off JCL...

[jkloi98]

I have been just want to upgrade my device as well for the work of

https://drugruger.com/category/mexican-blanket/ that was not possible with the old version as well.

[Robert Carnegie]

I am anxious that "drugruger" in that Web address is something to do with drugs...

Or possibly with rugs...

BBC radio "The News Quiz" runs curious newspaper reports, though not this season with the virus I suppose, and I fondly remember one comprising a complaint about the influence of neighbourhood rug pushers.

Although strictly speaking, without further detail, it would be fair to say that I don't remember it.

[Anonymous Coward]

> The One True Way ... Is to measure time starting from the Big Bang. In Planck units, naturally.

Congratulations on a decent starting point for measuring time, and a good incremental increase parameter as well. But a fail for not specifying the upper limit of time measurement in your proposed system.

Now, there is still argument about whether we will end up with a heat death or a Gnab Gib. (That's heat death as in no energy at all left in the universe due to entropy, rather than dying of global warming. Gnab Gib is where the universe stops expanding, then contracts, and does a big bang in reverse (a Big Crunch). The Big Crunch theory is now thought much less likely than a heat death. Gnab Gib is courtesy of Douglas Adams.

Current theory is the heat death will occur in about 10 to the power 100 years time. Ish.

We have been going for about 10 to the power 10 years. Very ish and not enough years. Let's over-egg it at 10 to the power 11 years.

So, to measure a timescale of 10 to the power 111 years to an accuracy of a planck time unit, we need 519 bits of data. Can I suggest we compromise on 512 bits? With 384 bits for years and 144 bits for sub-year units.

That will get us to 601,226,901,190,101,306,339,707,032,778,070,279,008,174,732,520,529,886,901,066,488,712,245,510,429,339,761,526,706,943,586,500,787,976,175,353,856 years after the big bang.

That's 601,226,901,190,101,306,339,707,032,778,070,279,008,174,732,520,529,886,901,066,488,712,245,510,429,339,761,526,706,943,586,500,787,962,475,353,856 years from now, and going back 13,700,000,000 years to epoch time. With a resolution of 0.0000000000000000000000000000000000000000000448410 ish seconds. Six significant figures is a bit optimistic here.

That should suit everyone's requirements for time resolution. Yes, it is a compromise, but I think we can live with it.

Dominic, who used to be a metrologist for a while.

[J.G.Harston]

So in bytes that's 46 bytes for the year and 18 bytes for the subyear. And we are currently in year 0x0000...000680000000-ish. Bytes 5-45 of the year will be zero for the foreseeable future, 40 times the current age of the universe. Hey, why not save 40 bytes of storage! :)

[J27]

If there is a single human alive to be killed by the heat death of the universe I'll eat my hat. I can say that quite confidently because there is no chance at all I'll have to do it because I'll have been dead for billions of years at a minimum.