back to article 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 …

  1. Anonymous Coward
    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.

    1. Chris 3

      Re: Trim that long gray tail

      Good by PowerPC 601 :(

      1. FILE_ID.DIZ

        Re: Trim that long gray tail

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

  2. Yes Me Silver badge

    Yes, but...

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

    1. 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.

    2. Missing Semicolon Silver badge

      Re: Yes, but...

      Via Eden processors aee now officially dead.

      1. 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.

        1. Missing Semicolon Silver badge

          Re: Yes, but...

          Slackware still has a real 386 build.

        2. 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

    3. Anonymous Coward
      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:

      1. Anonymous Coward
        Anonymous Coward

        Re: Yes, but...

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

    4. Anonymous Coward
      Anonymous Coward

      Re: Yes, but...

      > There's always one out there.

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

  3. Anonymous Coward
    Anonymous Coward

    bye bye 2038

    Happy to see "crushing the 2038 bug"

    1. DJV Silver badge

      Re: bye bye 2038

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

      1. Usermane

        Re: bye bye 2038

        Year 10,00?

        1. Anonymous Coward
          Paris Hilton

          Re: bye bye 2038

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

      2. theblackhand

        Re: bye bye 2038

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

    2. Mage Silver badge

      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.

      1. 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.

      2. 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.

      3. Mage Silver badge

        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.

        1. 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.

          1. Anonymous Coward
            Anonymous Coward

            Re: bye bye 2038

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

          2. heyrick Silver badge

            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...

            1. 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.

          3. 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.

        2. Nick Ryan Silver badge

          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.

          1. 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...

            1. J27

              Re: bye bye 2038

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

      4. Claverhouse Silver badge

        Re: bye bye 2038

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

  4. 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"™.

    1. heyrick Silver badge

      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...

      1. 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.

  5. Mage Silver badge


    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.

    1. A.P. Veening Silver badge

      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.

      1. Alumoi Silver badge

        Re: Random

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

        1. Tom 7

          Re: Random

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

          1. seven of five

            Re: Random

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

            1. Robert Carnegie Silver badge

              Mayan calendar?

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

    2. RobThBay

      Re: Random

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

  6. 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?

    1. Anonymous Coward
      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.

      1. 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.)

  7. 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.)

    1. James 47

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

      1. MacroRodent


        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.

    2. 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.

      1. 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.

        1. 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.

    3. oldcoder

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

      Only set_fs macro.

      1. 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.

  8. Claverhouse Silver badge

    More Light, More Light

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

    Just add 4000 years.

  9. Anonymous Coward
    Anonymous Coward

    The One True Way

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

    1. seven of five

      Re: The One True Way

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

  10. Mage Silver badge

    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?

    1. 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 :)

    2. 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).

    3. 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...

  11. jkloi98

    I have been just want to upgrade my device as well for the work of that was not possible with the old version as well.

    1. Robert Carnegie Silver badge

      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.

  12. Anonymous Coward
    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.

    1. J.G.Harston Silver badge

      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! :)

    2. 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.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like