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

101–110 of 333 posts

Re: 2038: Only 21 years away

#101

Post by OnACoffeeBreak »

gbrown_ wrote: post #31
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.

I'm really curious about the kind of software things like pacemakers run and potential implications from 32-bit time expiring.

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.

Re: 2038: Only 21 years away

#102

Post by jonstewart »

mikeash wrote: post #65
_uhtu wrote: post #5

Is there a reason why they decided to store time as seconds from 1970? In a 32-bit integer nonetheless. It seems like basic logic would have lead the original designers to make it at least 64 bits so that you'd never overflow it (with a 64 bit time we'd be good til the year 292277026596). 64 bits would also allow you to also cover the entirety of history, all the way back to 13.7 billion years ago when the Universe c…

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…

I really think society must expend every effort to keep Ken Thompson alive until the end of the epoch.

Re: 2038: Only 21 years away

#103

Post by drzaiusapelord »

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 to keep using Windows and DOS systems where the 2000 cut-over was problematic. The non-compliant stuff was being sold months before Jan 1, 2000. The 32-bit linux systems have been old hat for years now, let alone 20+ years from now.

Not to mention that those old COBOL programs were nightmares of undocumented messes and spaghetti code no one fully understood, even the guys maintaining them at the time. Modern C or C++ or Java or .NET apps certainly can be ugly, but even a second year CS student can find the date variables and make the appropriate changes. They won't be calling in $500/hr guys for this. Modern systems are simply just easier to work with than proprietary mainframes running assembly or COBOL applications that have built up decades of technical debt.

Re: 2038: Only 21 years away

#104

Post by zie »

halcyondaze wrote: post #93

As a layman here, can someone explain this what the significance of the year 2038 is to me?

Nothing significant except that the storage spot for unix will fill up. Unix used to use a 32bit variable to store time in seconds since the epoch of 1970, so it will overflow in the year 2038. Most modern Unix systems have fixed the problem already, but Linux has a harder time than the others, and is still working on their fix.

Re: 2038: Only 21 years away

#105

Post by marcosdumay »

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…

What's up with that huge weekly variation?

Re: 2038: Only 21 years away

#107

Post by soundwave106 »

halcyondaze wrote: post #93

As a layman here, can someone explain this what the significance of the year 2038 is to me?

https://en.wikipedia.org/wiki/Year_2038_problem

Short summary: Many systems (including Unix) store time as a signed 32 bit int, with the value 0 representing January 1st 1970 00:00:00. This number will overflow on 03:14:07 UTC on 19 January 2038.

Re: 2038: Only 21 years away

#108

Post by cat199 »

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…

We'll see what actually happens..

No direct insight, but -

a.out -> ELF, glibc2, and NPTL threads radically shifted threading and required kernel/userland cooperation in the Linosphere; We now have ELF symbol versioning widely supported which should make this even easier, so I suspect there will be some sort of long-run transition period and some fun C #ifdef macro fun over the long haul - e.g. I could see this new statx() thing (which apparently has additional information) being the baseline, and then having some -DLINUX_2038 gizmo which redefines stat() in terms of this function when present, possibly with some sort of ld trickery to splice together the appropriate functions in the case of shared libraries, yadda..

Re: 2038: Only 21 years away

#110

Post by drzaiusapelord »

archgrove wrote: post #9
Aloha wrote: post #7

Earlier quoted context omitted.

There is a certain amount of snark embedded in this post, but its not a bad idea at all - I'll be in much the same boat at that time - perhaps I can borrow the same idea...

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 version and make whatever small changes are needed to date storing in the old 32-bit apps. You won't need a wizened COBOL guy for this. A first year CS student would be able to look at C or C++ code and figure this out. Modern languages are far more verbose and OO programming makes this stuff far easier to work with.

Comparing mainframes to unix systems really doesn't make sense. Its two entirely different designs. Not to mention, the idea of running a 32-bit OS today is odd, let alone 20+ years from now, especially with everything being cloudified. You'd be hard pressed to even find a 32-bit linux system in 20+ years, let alone be asked to work on one. That's like being asked to setup 1000 Windows 98 workstations today.

Post reply on HN