Fixing Y38 will require some public spending. If "researching cancer" is not considered worthy of public spending any more, I'm curious about how the nerds will manage to justify replacing lots of embedded chips "because maths".
If it takes the usual 8 years to replace the current administration with one that accepts listening to experts, and unless big donors can make a profit by organizing the transition, we can expect serious efforts to only start around 2032 globally. No idea if that will be enough this time, we'll see...
(On the bright side, maybe they can charge customers ? That would work.)
13 years is plenty of time to make a start on all of this, and will allow the costs to be spread over that time period without undue hurry. It's also long enough that it will be possible for much software to be allowed to reach end-of-life without being audited, while applying rigorous testing to new software. Procrastination, though, is not a good option.
I remember a rumor that “if enough people take their phone off the hook before midnight it’ll take down the phone network”
The sketch was a riff about the kindergarten joke :
- why do you [insert weird action] ?
- to scare the girafes away
- but there are no girafes here
- of course, I've been [insert weird action here]
And I was a software engineering student at the time, and I tried explaining they were missing the point, but I think it will be how we're approached this time.
So, I think nothing will be done, or not enough, and bugs will happen in 12 years.
But, thankfully, all our computers will have been replaced to allow running js.
But it will be the end of time, as we know it!
Maybe I should start thinking about an early retirement :)
So, ahem, your “early retirement” is assured?
A year is a lot longer than it used to be. And quickly getting longer. Measured in change.
If you ask ChatGPT it’s:
= 285,616 years after 1970
= Year 285,616 >>> 2**53/(1000*3600*24*365)+1970
287586.41472415626
I think many software engineers know that if you want to make any organization care about this type of issue, you need to be ready to demonstrate the severity and impact.
Y2K showed that you don't need details beyond vague threats of "medication administered at the wrong time" and "planes falling out of the air" to get organizations and the public to care. No idea how that's going to tie into the conspiracy-heavy media landscape we inhabit now.
(Note I do think this is a serious issue that needs to be addressed. And I'd love to see specific examples. I'm just pushing back against the idea that examples would make much difference to advocacy efforts)
https://www.theregister.com/2020/04/02/boeing_787_power_cycl...
Seems to be unrelated at first look, but considering the complexities of systems, and cascading failure modes?
The latter is just a ripe plumb, left to rot in the backlog.
It was thankless work that is still glossed over and waved away today, but it was all a very big deal throughout the late 90s.
Mike Judge even made a movie about it! Office Space might be the most recognition turn of the millennium programmers will receive.
However, I’m not sure how you make a 2038 test environment
It assumes that the OS/Kernel etc… are defacto frozen to 2025 or whatever increment until 2038
What was the y2k solution for the people that implemented those fixes in the 90s?
It intercepts system calls to get the time and reports a fake time to the application.
Even if the system boots properly, there's various critical systems that depend upon having the correct time. Say goodbye to things like HTTPS and SSL/TLS certificates.
There's two kinds of internet connected devices these days, those that keep getting updated and those that drift into incompatibility and die as the rest of the ecosystem evolves around them. If these supposed critical devices will still be in use in 12 years without any maintenance then they're unlikely to have any actual importance.
Businesses installing new smart infrastructure and devices will need to pay attention to this, and in 10-15 years they'll need to work out what to replace, of course.
If you switch to 64 bit timestamps, and the network protocol supports dates > 2038, can you then just trigger the rollover bugs by pretending it's 2*64 - 1 seconds after epoch start?
Also, if the actions are potentially so severe, and NTP (or whatever is used) so vulnerable, why haven't we seen many such attacks in the wild?
Update: to be clear I'm not arguing that there isn't a problem, I've already run into it myself. I'm trying to understand how severe it is, how exploitable, and how robust a solution could be.
Here's an example of measuring packages that report warnings for software that has suspicious conversions. Compile with `-Wconversion` with both 32-bit and 64-bit time_t, and see what the difference is. https://github.com/mkj/yocto-y2038
That is using yocto, but you could probably do something similar with other less-embedded distros too, if you can rebuild the world.
FWIW I didn't find much interesting with that apart from busybox dhcpd.
Funniest is that one of them wrote that they have "learned about it after Y2K bug". I thought one learns about this overflow in a "introduction to programming" class...
Only 13 years left!
The best thing about waiting until the last minute to fix something is it will only take a minute.
At least, the good part is that people will get "hunches" about y38, just like you start getting "hunches" about bugs related to locales, time zones, character encodings, currency roundings, etc...
I don't know if there are courses, books, etc... about all those matters that are definitely non "computer sciency", but occupy so much of our engineering time ?
cranberryturkey•20h ago