Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

2038: Only 21 years away

lwn.net

Post reply on HN
Print view View original

151–160 of 333 posts

Re: 2038: Only 21 years away

#151

Post by gjjrfcbugxbhf »

drzaiusapelord wrote: post #103
archgrove wrote: post #3

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.

No one is deploying 32-bit linux now, outside of tiny edge cases and mobile. Mobile devices that go in the trash every 2 years. What do you reasonably expect to be around in 2038 in 32-bit form? Once 64-bit processors became mainstream, the 2038 problem pretty much solved itself. There's only disincentives to building a 32-bit system today let alone in 20+ years. Unlike with Y2k where there was nothing but incentives…

By 2030 systems being deployed today will be very legacy. And some orgs will still be running them.

Also doesn't it depend what the language/database does as much as the system?

Re: 2038: Only 21 years away

#152

Post by elastic_church »

deathanatos wrote: post #50
grabcocque wrote: post #2

And IPv6 penetration will have hit 20%.

You jest, but global IPv6 penetration is at ~16%. It rose ~6% last year, so if linear growth is presumed (and it's actually been growing closer to exponentially, as would be expected) we should hit 20% late this year. I'm hopeful that we'll see some decent pickup of it since AWS finally started offering it. This is global adoption; some countries, including the United States, have already hit 20%. [1]: https://www.go…

thats motivational

Re: 2038: Only 21 years away

#154

Post by Lockyy »

scandox wrote: post #56
archgrove wrote: post #3

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.

Start right now. You'll have the SEO and the thought-leadership circuit all stitched up well in advance.

Start too early and you'll sound like an end of the world preacher. You need to time it so that you look cutting edge rather than paranoid.

Re: 2038: Only 21 years away

#155

Post by DannyB2 »

archgrove wrote: post #3

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.

Re: 2038: Only 21 years away

#156

Post by calt »

drzaiusapelord wrote: post #125
JoachimSchipper wrote: post #118

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've worked on financial systems still running on mainframes from the 80s. The Y2K compatibility commit messages are there in the logs.

Airline reservation systems run on software written in the 50s and 60s

Your views on evergreen this and disposable up to date that are very naive.

Embedded systems and business systems live for a VERY long time.

Re: 2038: Only 21 years away

#157

Post by [deleted] »

Aissen wrote: post #39
gbrown_ wrote: post #27

> statx() will serve as the year-2038-capable version of the stat() family of calls Does this seem horrible to anyone else? Why not fix stat()? Does this syscall have to be so highly preserved even when it will be broken? One of the advantages of the OpenBSD approach of being able to make intrusive changes saw their time_t made 64-bit in the 5.5 release in 2014. https://www.openbsd.org/55.html Admittedly this is much…

In Linux kernel land, the golden rule is to never break the userspace ABI. Yes, it might happen, but it's never intentional, unless there's no other choice (glaring security issue for instance).

[deleted]

Re: 2038: Only 21 years away

#158

Post by Spooky23 »

drzaiusapelord wrote: post #110
archgrove wrote: post #9

Earlier quoted context omitted.

It wasn't intended to be sarcastic. I suspect there will be a lot of businesses (especially finance) interested in verifying that the "ancient" Linux system they setup to replace their mainframe 25 years "ago" is safe. I lived through the Year 2000, and watched the same thing happen there. With suitable groundwork, there will be a willing and wealthy market looking for people to assuage their fears - a service I see…

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

Re: 2038: Only 21 years away

#159

Post by [deleted] »

drzaiusapelord wrote: post #110
archgrove wrote: post #9

Earlier quoted context omitted.

It wasn't intended to be sarcastic. I suspect there will be a lot of businesses (especially finance) interested in verifying that the "ancient" Linux system they setup to replace their mainframe 25 years "ago" is safe. I lived through the Year 2000, and watched the same thing happen there. With suitable groundwork, there will be a willing and wealthy market looking for people to assuage their fears - a service I see…

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

[deleted]

Re: 2038: Only 21 years away

#160

Post by [deleted] »

drzaiusapelord wrote: post #110
archgrove wrote: post #9

Earlier quoted context omitted.

It wasn't intended to be sarcastic. I suspect there will be a lot of businesses (especially finance) interested in verifying that the "ancient" Linux system they setup to replace their mainframe 25 years "ago" is safe. I lived through the Year 2000, and watched the same thing happen there. With suitable groundwork, there will be a willing and wealthy market looking for people to assuage their fears - a service I see…

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

[deleted]
Post reply on HN