[drzaiusapelord]

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.

[JoachimSchipper]

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

[drzaiusapelord]

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 following and has typically a 2 year depreciation anyway.

[calt]

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.

[samuraig]

but their mobile enabled recipe site is TOTALLY going to be around for a long time too!!! ;-)

[ams6110]

That's exactly what programmers in the 1980s thought about the code they were writing. Otherwise they would have used four digits for years.

[JoachimSchipper]

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.

[tyingq]

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.

[JdeBP]

There's always TAICLOCK.

* http://cr.yp.to/proto/taiclock.txt

Technically, "always" is a stretch. But it's shorter than "until the age of the universe is well over an order of magnitude bigger than it is now".

[HankB99]

Yeah. I was working on an IoT system that uses NTP to set time. I generally plan a 20 year life span for tings like this. There's S/W I wrote over 20 years ago that is in devices still in use. The only good thing about this is that I'll not likely be around when trouble crops up. I didn't see any way to accommodate changes that are nearly decades away in code I write today.

[astrodust]

Once in a while you'll stumble upon a Novell Netware server that's been running since the mid 1990s. Twenty years isn't a long time.

[madphrodite]

Novell 3.x or 4. IPX/SPX only. print, file and directory service. Netware client for windows. Man I loved those days.

[drzaiusapelord]

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 with help to change date fields. That's trivial stuff.

[tyingq]

Right, but at a high level, I'm answering why there might be money in consulting on this later.

There will be Fortune 500 companies that have old ntp clients running somewhere in 2038...pretty much guaranteed. They'll also have apps with 32 time_t structures running as well, database columns that overflow, etc. Or maybe they won't, but aren't sure. You sell them a service that audits all of those things, scripts that look for troublesome stuff using source code greps, network sniffing for old protocols, static analysis, simplistic parsing of ldd, etc. And, a prepackaged methodology, spreadsheets, PowerPoint to socialize the effort, and so on.

It was the same for Y2K. Fixes for many things were available well ahead of time. Companies had no methodology or tools to ensure that the fixes were in place.

[cdelsolar]

The NTP issue will actually surface in 2036, so your consultancy better be up and ready 2 years early!

[astrodust]

Great, so not only will the epochalypse happen but we'll have no idea how close we are since our clocks are drifting like Paul Walker.

[galdosdi]

Where there's development, there's support

[gjjrfcbugxbhf]

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?