Live data from Hacker News

2038: Only 21 years away

lwn.net

191–200 of 333 posts

Re: 2038: Only 21 years away

#191
post #111

Earlier quoted context omitted.

It won't be the same magnitude of issues. However, I'm sure there will be plenty of apps on said 64 bit Linux that have issues. I commented about a mysql problem here that exists on 64 bit MySQL, on 64 bit Linux. It's not much of a stretch that some internal apps at a company would have similar issues. Edit: Ntp has something of a protocol issue to be addressed as well.

Yeah but that's a protocol issue. Single graybeard devs aren't going to be paid to fix that. The people who run ntp are going to push out a new protocol way before 2038. Even if there are issues, more than likely they'll be able to handle it internally. OO programming isn't going anywhere and modern languages and concepts are easier to work with than piles of undocumented COBOL from Y2K. They won't be calling you wit…

Where there's development, there's support

Re: 2038: Only 21 years away

#193
post #143
post #47

Earlier quoted context omitted.

Think about how much entropy will build up in systems over 292 million years. Systems thousands of years old will be underneath newer systems hundreds of years old. The AI's will be scrambling to fix the problem.

the scenario from "accelerando" is more plausible, where an AI rebuilt itself from scratch to eliminate a thompson "trusting trust" hack.

That's something of a trope now, isn't it? Although it was never spelled out how Mr. Rabbit handled that scenario in Rainbows End, Defiant basically had to force Dragon to kill herself in order for her to escape her programmed-in limitations in Worm.

Re: 2038: Only 21 years away

#194

This is (serious) a part of my retirement planning. I'll be mid-50s when this hits, and have enough low level system knowledge to be dangerous. In about 15 years, I'll start spinning up my epochalypse consultancy, and I'm expecting a reasonable return on investment in verifying systems as 2038 compliant.

My retirement planning is to work on the Y10K problem. When the year 9997 comes along, everyone is going to start worrying about the rollover to five digit years. In about the year 9995 I will start seriously brushing up on my COBOL.

This is obviously a joke, but here's a serious reply to it: There will already be serious Y10K problems in 9997, just like there were Y2K problems earlier than 1997.

Epochs & date formats aren't only used to represent & display the current date, but dates in the future, e.g. think about reservation systems, graphing libraries that display things 10-15-50 years in the future etc.

Re: 2038: Only 21 years away

#196

Earlier quoted context omitted.

>verifying that the "ancient" Linux system they setup to replace their mainframe 25 years "ago" is safe. The problem with mainframes is that they can't be trivially upgraded or migrated to 64-bit like modern OS's on x86 hardware can be. Vendor lock-in, retirement of OS, bare to the metal coding, etc caused this. If these mainframes were running a modern OS, it would have been trivial to upgrade them to a 64-bit versi…

Be careful about your definition of absurd. Somewhere, right now, some poor bastard is building an NT 3.51 workstation for some stupid reason. I'll bet you $0.05 that some future poor bastard will be building NT4 or 2000 devices in 2038. :)

Well, at least NT has no problem with 2038 ;-)

Re: 2038: Only 21 years away

#197

Earlier quoted context omitted.

I would guess pacemakers don't run Linux. I would be surprised if they run an OS at all. I work on devices that have to survive 20 years on one non-rechargeable and non-serviceable battery, and there's at most a simple scheduler in place to control tasks. We use 32 bits for epoch time, but our epoch starts Jan 1, 2000, so we have 30 years on Linux before this becomes a problem.

you might be underestimating modern med devices which even have wireless access (beats a port or invasive surgery to read a log). example for the issues in this area: https://spqr.eecs.umich.edu/papers/49SS2-3_burleson.pdf

I see "wireless", but not "WiFi" or "802.11*" in the PDF.

For what it's worth, devices I work on have a few wireless interfaces while guaranteeing 20-year life time: one interface is long-range (on the order of 10km), two are short range (on the order of a few mm). There is no way we can get to 20-year life time with doing WiFi (maintaining current battery size/capacity) for long'ish range and maybe not even BT for shorter range.

Re: 2038: Only 21 years away

#198

Earlier quoted context omitted.

There are, in fact, a lot of 32-bit ARM chips still being deployed today. Yes, arm64 is usable, but using e.g. a Beagleboard- or even Raspberry Pi-class device still often makes sense (for cost or compatibility reasons.)

No 2016 beagleboard implementation will be running BigCo's finances and be irreplaceable in 2038. Lets be realistic here. Those 70s and 80s programmers were working on mainframes with multi-decade depreciation. We work on servers and projects with 3-5 year deprecation when we aren't working on evergreen cloud configurations. Not to mention we've already standardized on 64-bit systems, outside of mobile, which is soon…

I mostly agree with you about BigCo's finances.

But some industrial- or military-spec ARMv7 core running a critical embedded system or two, in 2038? Twenty-year design lifespans (often with servicing and minor design updates) are definitely not unheard of, and successful systems often outlive their design lifespan.

Re: 2038: Only 21 years away

#199
post #65

Earlier quoted context omitted.

If you told the original UNIX developers that there was even the slightest chance their system might still be in use in 2038, they probably would have called in some large, friendly men in white coats to haul you away. Add to that the fact that memory was very much not cheap at the time. Memory for the PDP-7 (the first computer to run UNIX) cost $12,000-20,000 for 4kB of memory. In 1965 dollars. In 2017 terms, that m…

The year 2038 problem is actually younger than unix. The first definition was 60th of seconds since 1970-01-01T00:00:00.00 stored in two words (note that a word is 18 bit on a PDP-7!). That definition was later changed. Also Linus could have defined `time_t` to be 64 bit when he started linux. https://en.wikipedia.org/wiki/Unix_time#History http://aaroncrane.co.uk/2008/02/unix_time/

I'm not even sure there was a standard 64-bit type for C in 1991... Or how well compiles on PC would support that.

Re: 2038: Only 21 years away

#200
post #37

Earlier quoted context omitted.

Good idea. Our Qeng Ho descendants will thank us. [0] [0] https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Interste...

Up vote for the Deepness reference! What a great novel, and I suspect the concept of a "programmer archaeologist" would be of interest to many here...

A Fire Upon The Deep is a fantastic book as well.
Post reply on HN