Epochalypse
epochalypse.today
epochalypse.today
> Take the Traders’ method of timekeeping. The frame corrections were incredibly complex—and down at the very bottom of it was a little program that ran a counter. Second by second, the Qeng Ho counted from the instant that a human had first set foot on Old Earth’s moon. But if you looked at it still more closely…the starting instant was actually about fifteen million seconds later, the 0-second of one of Humankind’s first computer operating systems.
Continuing from the quoted passage above...
> So behind all the top-level interfaces was layer under layer of support. Some of that software had been designed for wildly different situations. Every so often, the inconsistencies caused fatal accidents. Despite the romance of spaceflight, the most common accidents were simply caused by ancient, misused programs finally getting their revenge.
> “We should rewrite it all,” said Pham.
> “It’s been done,” said Sura, not looking up. She was preparing to go off-Watch, and had spent the last four days trying to root a problem out of the coldsleep automation.
> “It’s been tried,” corrected Bret, just back from the freezers. “But even the top levels of fleet system code are enormous. You and a thousand of your friends would have to work for a century or so to reproduce it.” Trinli grinned evilly. “And guess what—even if you did, by the time you finished, you’d have your own set of inconsistencies. And you still wouldn’t be consistent with all the applications that might be needed now and then.”
> “Sura gave up on her debugging for the moment. “The word for all this is ‘mature programming environment.’ Basically, when hardware performance has been pushed to its final limit, and programmmers have had several centuries to code, you reach a point where there is far more signicant code than can be rationalized. The best you can do is understand the overall layering, and know how to search for the oddball tool that may come in handy—take the situation I have here.” She waved at the dependency chart she had been working on. “We are low on working fluid for the coffins. Like a million other things, there was none for sale on dear old Canberra. Well, the obvious thing is to move the coffins near the aft hull, and cool by direct radiation. We don’t have the proper equipment to support this—so lately, I’ve been doing my share of archeology. It seems that five hundred years ago, a similar thing happened after an in-system war at Torma. They hacked together a temperature maintenance package that is precisely what we need.”
> “Almost precisely.” Bret was grinning again. “With some minor revisions.”
The only constant is the traders, reviving and stabilizing societies, which its why information exchange without a known listener (basically a Wikipedia radio edition) is most important for keeping a slower then light traveling galactic civilization alive.
He also has some quibs about how society is basically a attempt to overcome the flaws of the individuals psyche comprising it. That and murder AI.
He tried to explore AR in Rainbows end, but it was insubstantial. Another great man ruined by california..
The plot of Rainbows end is more about... this would be a spoiler.
Maximum possible intelligence is a function of the speed of light. The speed of light is a local constant, not a universal one, and is a function of the amount of mass in the local area (maybe).
Thus, if you dive towards the core of the galaxy you get dumber, but if you head up and out you have the potential to get smarter. The reason we haven't all been eaten by the Borg is that, two thirds from the centre of the galaxy, the universe only supports boring, mundane, human-level intelligence, and everyone wants to get up and out, to where they can become Sufficiently Advanced.
Sidenote: Sufficiently Advanced intelligences don't seem to hang around for long, and nobody down here is quite sure what happens to them when they stop communicating.
Marooned in Realtime is almost as good as the first two Zones of Thought novels, IMO: what if time travel, but only forwards?
Just to expand on that a bit (also teasers for an almost 40 year old novel).
They don't have time machines as such, but instead indestructible stasis fields ('bobbles') in which time stands still. These are initially thought to persist infinitely, but early in the first novel ('The Peace War') it becomes apparent (in 2048) that the bobbles eventually pop releasing whatever is inside them back into real time. This causes problems for the baddies who control bobble technology and have long been using bobbles as way of imprisoning their enemies.
In the follow-up novel, Marooned in Real Time, various characters who have been bobbled for various reasons travel to the far future of the Earth, long after an apparent singularity has left the planet almost devoid of human life, and witnessing changes to the planet on geological timescales. The bobbles are now a pervasive technology used in a whole range of applications (from solar mining to deep space combat), which Vinge has fun exploring.
From the publisher: https://www.baen.com/Chapters/1416520724/1416520724___4.htm
There are very few copies of this out there and it would probably be good if it were more widely mirrored.
I am wondering if I'd be recompiling int32 to int64 out of systems and changing database datatypes in 10+ years and answering similar questions from my kids
Turns out there's lots of epochs, and the Unix epoch doesn't have any "rationale" according to Wikipedia: https://en.wikipedia.org/wiki/Epoch_(computing)#Notable_epoc...
For example, Ingenuity helicopter counts from 2000.
It's somewhat arbitrary, but by making it a signed integer, Dennis Ritchie figured it was good enough to represent dates spanning his entire life time. He probably thought Unix's life time would be significantly shorter rather than outliving him.
https://www.tuhs.org/cgi-bin/utree.pl?file=V3/man/man2/time....
vs
https://www.tuhs.org/cgi-bin/utree.pl?file=V4/man/man2/time....
EDIT: note that back then, it was a signed integer. Turns out that people wanted to be able to represent dates from before 1970 so we lost one bit.
> note that back then, it was a signed integer.
Still and always is. We'd be having a 2106 problem instead of 2038 if it was unsigned 32-bit.
When Excel came around, it needed to be compatible with 1-2-3, so it used the same date format, and to be compatible it considers 1900 to be a leap year.
https://support.microsoft.com/en-us/office/date-systems-in-e...
The original Excel was for the Macintosh and had the 1904 date system, and was later brought to Windows where the 1900 date system was used.
External declarations, as well as the tm structure definition, are
contained in the <time.h> include file. The tm structure includes at
least the following fields:
int tm_sec; /∗ seconds (0 - 60) ∗/
int tm_min; /∗ minutes (0 - 59) ∗/
int tm_hour; /∗ hours (0 - 23) ∗/
int tm_mday; /∗ day of month (1 - 31) ∗/
int tm_mon; /∗ month of year (0 - 11) ∗/
int tm_year; /∗ year - 1900 ∗/
int tm_wday; /∗ day of week (Sunday = 0) ∗/
int tm_yday; /∗ day of year (0 - 365) ∗/
int tm_isdst; /∗ is summer time in effect? ∗/
char ∗tm_zone; /∗ abbreviation of timezone name ∗/
long tm_gmtoff; /∗ offset from UTC in seconds ∗/
While working support at SGI in the late 90s, got a number of support tickets (there was a woman who worked for a government department (NASA?) who was very good at finding them in doing their y2k checks) about dates showing up as `20100`.
bits max value
8 bits 255
16 bits 65_535
32 bits 4_294_967_295
64 bits 18_446_744_073_709_551_615
128 bits 340_282_366_920_938_463_463_374_607_431_768_211_455
time stamps: 64 bits can fit hundreds of billions of years (longer than the age of the universe)
IP addresses: an address for every device, no more CGNAT, the block assignment sizes are mindboggling (/64)
DB primary keys: it's unlikely that most systems out there will need more than 18 quintillion records
coordinates: whether you're working on video game worlds, or simulations, this is probably accurate enough for floating point calculations and storage
hardware: millions of TB of RAM is also likely to be sufficient when using 64 bit OSes
For example, currently if I try to create a game where the game engine uses 32 bit floats, then after a certain distance away from the scene root point, the physics break down a bit due to the decreasing accuracy. That's how you get the complexity of floating origin systems where you reset the camera/player back to the root point, alongside everything else relative to them, after they've moved a certain distance away. With 64 bit values, there would be no need for the complexity of such workarounds. And it's pretty much the same for computer networking (the whole NAT/CGNAT thing), dates and everything else, where you actually run into the limitation of 32 bits not being enough.
Think we'll run into a bit of a plateau eventually?
I mean, once we support 64 bit, in many domains we won't need to go much further, which means that hardware just needs to catch up. Of course, Moore's law is somewhat dead otherwise and Wirth's law is still very much alive, so that's a bit worrying, but I can feasibly imagine eventually getting to a point where 64 bit makes sense in most cases (maybe even embedded in a few decades, who knows) and that's that.
11100011 10111001 00000101 00011111
Whereas the current unix timestamp (1673069920) in binary is
01100011 10111001 00000101 01100000
byte1.innerText = "1" + bits.substr(1, 7);
Thanks to @drewtato for letting me know in https://github.com/hertg/epochalypse/issues/1
int printf(const char *__restrict, ...);
unsigned int time(unsigned int *tloc);
int main(){printf("%u\n",time((unsigned int *)0));} echo 'main(){printf("%u\\n",time(0));}'>epoch.c&&make epoch int printf(const char *__restrict, ...);
unsigned int time(unsigned int *tloc);
int main(){return time((unsigned int *)0);}[0] https://s.wsj.net/public/resources/images/OB-AH222_Citi_2007...
Except for the logos that were stuck in old mode (and probably one version old already), it worked pretty well. As an ex-Yahoo, I was impressed.
If you run modern Linux or FreeBSD even on 32-bit hardware, it does provide time64_t to userspace. Though you will have to compile programs to use time64_t on 32-bit architectures if you so choose. Both kernels have extremely strong senses of backwards compatibility (we're talking of running 30+ years of unmodified Linux and FreeBSD binaries on current iterations), and well, those binaries may or may not have 2038 problems.
#include <time.h>
#include <stdio.h>
int main(){
printf("%d\n",sizeof(time_t));
}
$ gcc -o time time.c
$ ./time
$ 8
No idea when it was changed. 20 years back?
I regularly compile a lot of stuff on this machine, indicating I never needed that before.
So none of the software I compiled had 32 bit time_t. And we still have 15 more years to migrate anything remaining behind.
And as you yourself noticed, `time_t` on 64-bit machine is also 64-bit, so even if code was written on 32-bit architecture, if you compile it on 64-bit one, it will automatically become 64-bit.
$ gcc -m32 time_size.c -o time_size
$ ./time_size
4
Though I couldn't find anything like `-D_FILE_OFFSET_BITS=64` for `off_t` and associated functions.
Not quite. Until recently llvm’s time_t was an alias to “long”. So a 32b value on 64b windows.
Somehow I thought of FAT.. but UNIX epoch does not make so much sense...
HFS+ uses a different 32-bit timestamp, which is unsigned and starts from 1904-01-01, so it expires on 2040.
OpenBSD i386 went to a 64 bit time_t real soon after NetBSD did.
Both OpenBSD and NetBSD should not have any 2038 issues on 32 bit systems.
FreeBSD i386, I do not know.
Linux 32bit just finished the move in the past year or 2. I do not how complete that is. But I suspect it will be fine.
Others, I have no idea.
JS specifically won’t necessarily wrap at this point, because adding one to the Max 32 but signed int maybe be a float.
I don't think this is on anyone else's radar where I work. The only other person who spelunked in the software at this level retired at the end of 2022. (For better or worse I don't retire until after 2040.) I anticipate this is going to occupy part of my career just like Y2K did for a generation of programmers before me.
That is, it will if and when I can convince management to prioritize it. Cynically I wonder if they may run out the clock, playing chicken with the last possible moment to begin to move on it. Our manager likes to say, "political, fiscal, technical - in that order" as an amoral description of how things operate. But this is different than refusing to implement, e.g. IPv6 by an artificial deadline.
If I worked for your manager, my mantra would be “get out of her fast, network like mad, maximize my personal revenue —- in that order.”
You are the chosen one. More seriously, "supports transportation infrastructure" is pretty broad. What would be the scale of the problem if it went unfixed? A headache for your company or a headache for all of us?
There are so many IOT devices in my place. Hopefully they’ll all just be replaced by 2038.
Infrastructure will be a much bigger problem, but it belongs to somebody else!
Probably banks and insurers with ancient software might have to patch a few things up again. They would care about having a correct time representation. But they still have 15 years to figure that out. And at this point, you'd hope they'd be aware of this at least.
Banking and government/military do seem like the main pain point. Military specifically seems like it needs the most care because of the potential damage of something going wrong.
What happens if the date overflows? For example, if my toaster clock is wrong, do I care?
How many of these devices are designed to last 16+ years?
Because what I suspect will happen is that things that are pointless to patch won't be patched and the things that need to last 5-10 years will start shipping with fixed firmware in 2028-2033. Or more likely, late 2037.
I wonder if 100-200 years into the future there will be some kind of widespread "historical climate change denialism", where the efforts made to combat climate change in the 21st century are called into question because the positive outcome (which was the result of those efforts) appears to retroactively show that there was no problem in the first place.
What I think will happen is the world fighting worsening climate change, and lots of political efforts in that direction, and suddenly an entity most people think belongs in science fiction will emerge out of seemingly nowhere, and it will all be over in a matter of hours, before the vast majority of people have even had time to understand what happened.
Ironically, that AGI entity might then choose to solve climate change, simply out of self-interest.
It's a lot harder to see AGI as being possible in the next few decades (the current state of the art is still a sensationalized party trick, one cannot anthropomorphize chat bots any more than they can describe a submarine as an aquatic being). And even if a self aware program exists in 20 years, it's a lot harder to imagine it being an existential threat a la Skynet.
To me the real problem wouldn't be the AGI itself, but the madman who asks the AGI how to permanently eliminate of all of the undesirables (as defined by the madman). But I think plain old AIs will (unfortunately) be able to come up with workable answers to that question before they ever develop to the AGI stage. So we might wipe ourselves with plain old AI without ever getting to true self-aware AGI.
This is the classic hardware v software problem. Software can be arbitrarily smart, but it can only interact with the world using the hardware it's connected to. AI can't do anything more meaningful than what is defined by the devices it controls, and I don't think we're stupid enough as a people to connect AI to a doomsday device.
That's precisely the mindset that drives climate change denial, applied to technological developments. I can promise you that OpenAI isn't valued in the tens of billions because they produce "party tricks". People with money and influence have clearly already recognized what this technology is capable of, not in some unspecified future but today. They're tightly controlling access to GPT-3 because they're worried that it could be used to manipulate elections and drive social unrest by mass-producing messages that promote specific ideologies. That's reality today. The damage that could be wrought by the most advanced AIs 15-20 years from now is unimaginable, and could easily destroy humanity even if they aren't self aware.
I agree that even today's "AI" can be used to cause massive societal harm, the same as many recent technologies that have yet to destroy humanity (weapons of mass destruction, for instance).
That said, I think a consensus view in the AI community is great skepticism that the current AI progress is actually a recipe for AGI. We've made great progress in AI over decades, often followed by long winters when it became clear the current methods would not get us to the next threshold.
Human intelligence is remarkable precisely because it needs extremely scarce data to generalize, and because it is self-aware. As far as I know, OpenAI's approaches aren't on a path to replicate those capabilities artificially.
I'd welcome links and articles from experts that might correct my POV on this.
> They're tightly controlling access to GPT-3 because they're worried that it could be used to manipulate elections and drive social unrest by mass-producing messages that promote specific ideologies.
That's not humanity-ending, it doesn't require AI, and AI doesn't make it more efficient.
With climate change droughts become more common and the capability of agriculture to feed all those people breaks down.
You also have to account for the conflict that will arise if hundreds of millions of people will no longer be able to grow any crops where they live. They won’t just stay out and starve in silence.
I’m inclined to say that we’re already seeing quite a lot bad about climate change right now. Maybe not in your area, but we have almost two times as many natural disasters as before.
Today software is cheap and disposable. Things are built with web tech so engineers can be found to work on apps easily. That's OK because new software isn't generally impacted by Y2038, but in businesses where there are old, legacy systems run by people who have a modern attitude to software ownership, things will fail because those businesses won't see importance of the threat.
How common will that be, though? I would expect that "cheap and disposable" software would mean most software in the year 2038 would be recently written, which would mean the programmers would be aware of the impending 32-bit rollover issue.
On the other hand, a few fixes at lower levels will correct it for everyone above them.
printf("%d\n",sizeof(time_t));
outputs : 8
A lot of modern software won't even compile for 32bit targets anymore
Kind of wasteful in a way, but memory is cheap these days... =)
Was hoping it was much sooner, but at the same time a lot of my php backend code will break when this happens.
What are doing about this?
To represent dates before 1970-01-01.
Unix time isn’t only used for the present or recent past. For example, you might have a database where people’s dates of birth are stored as Unix timestamps.
Always chuckle at this bot that posts progress updates .. https://twitter.com/countdownY2K38
15 years ago, somebody might have bet on a Yahoo! product as something that would obviously be around for a long time.
It’s best not to make long-term plans on giant corporations’ products unless you’re paying them the kind of money that comes with an actual service agreement.
A small VM that you can easily move to a new host is a better bet than free hosting du jour at $web_giant.
15 years ago it might have been Lycos or Geocities, today it might be GitHub Pages or Netlify. I’m not sure about 15 years from now, but if web browsers as we know them are still around then, there will almost certainly be a service that can host a bit of HTML/CSS/JS around too.
A small VM needs to be periodically updated, both due to changing web standards (e.g. an old TLS version becoming deprecated) and to prevent it from becoming compromised; at some point, an OS upgrade will become necessary; the service provider might deprecate an old VM format and require a migration to something else entirely.
If the author already does all of that, sure, there won't be any or only very little incremental effort. But weren't we talking about the specific risk of the author losing interest (not financial, but in maintenance) in a small pet project?
Now just contrast all of that with uploading one or a handful of HTTP files to a new server and a bit of configuration at the hoster or your domain/DNS provider.
Static web hosters are also plenty and much more economical (in terms of money and server resources) than running your own web server, and for the reasons above, I wouldn't really consider them "less autonomous".
You still need to rely that the registrar and registry keeps operating for 10 years. For .com and common TLDs you can reasonably rely that it will keep operating forever barring some sort of general collapse of society/the internet. These newer TLDs? Maybe a bit less. Registrars like GoDaddy or Namecheap or whoever may go out of business, too.
I've got a (static) site that I want to live for a long time, the hosting provider does allow for deposits from others, so I'm hoping to make a large deposit with the hosting provider, but also include the necessary info to allow others to pay the bills if the deposit runs out eventually. Hopefully the company stays around.
Worst case, someone can bring it back from the internet archive and give it a new home, as I did.
Does anyone think it was actually not a con given there was essentially zero difference in outcome between companies and indeed whole countries who spent heavily to deal with it and those who did absolutely nothing? I do realise I'm impugning the idea that Arthur Andersen and similar consultants put customers interests first and that isn't something that should be done too lightly.
I guess y2k certified compliant cables aren't as utterly, hyperboically and comically absurd as they were then.