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 …
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.
> 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.
"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
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.
"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.
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.
> 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.
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...
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"™.
"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...
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.
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.
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.)
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.)
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.
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 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.
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.
There's also Anno Lucis used by our friends the Freemasons.
Just add 4000 years.
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?
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 :)
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).
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...
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.
> 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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
