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

41–50 of 333 posts

Re: 2038: Only 21 years away

#42

Post by gbrown_ »

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

I know and understand the reasoning for this, I just don't like it. I am a BSD fan, so I indulge in a land where such ABI breaks are possible. In a fantasy land I would like to see the Linux community coming up with a way to deal with ABI breaks. Not that I think such breaks are to be taken lightly but they are sometimes necessary. Such as this case.

Re: 2038: Only 21 years away

#44

Post by AlexC04 »

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 hope you've trademarked the term "epochalypse" because it is really catchy! I love it.

Re: 2038: Only 21 years away

#45

Post by ryan-c »

iamgopal wrote: post #28

Call me stupid, but I think computing will be much different to worry about this. ( single chip os or iot to the level that each hardware component is separate, or something else...)

I'm pretty sure that's exactly what they figured when they designed it in the first place, and here we are many decades later, still living with it.

Re: 2038: Only 21 years away

#46

Post by gregmac »

iamgopal wrote: post #28

Call me stupid, but I think computing will be much different to worry about this. ( single chip os or iot to the level that each hardware component is separate, or something else...)

There are still lots of systems from the 70's and 80's running today. There are many PDP and VAX systems that run parts of the US military, such as missile defense and nuclear ICBM systems. Many airlines and insurance agencies also run on mainframes from that era.

Even if they don't run the actual hardware, they're likely to be running the same software and OS on an emulator running inside modern hardware.

It's simply too expensive and risky to rewrite all the software on a new platform.

Re: 2038: Only 21 years away

#47

Post by swalsh »

antirez wrote: post #24

Using a 64 bit timestamp will only move the problem 292 million years forward, so probably the best solution is to use a variable length field.

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.

Re: 2038: Only 21 years away

#48

Post by dboreham »

jamoes wrote: post #26
_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…

The reasoning I've heard is that back then memory and disk space were limited and they couldn't sacrifice the extra bytes. For example, if every file stores three timestamps (mtime, ctime, and atime), then that's an extra 12 bytes per file to store a 64 bit timestamp vs a 32 bit timestamp. If your system has five thousand files on it, that's an extra 60 KB just for timestamps. In 1970, RAM cost hundreds of dollars pe…

I'm not convinced that the problem was considered in those terms. Imagine that there was a meeting where someone said "I'm going to make time_t 64-bits because if I don't it will mean all software will break in unfortunate ways in the year 2038", and someone else said "Yeah, that's something to be concerned about but we can't do that because memory and disk space is at present too expensive to allow it". Well, I'm confident that no such meeting occurred because nobody back in the early 70's was thinking that way at all. The thinking would be more like "Ok, the last OS I worked on used a 32-bit int, so ho hum...there we are... time_t, move on to code the next thing...".

Re: 2038: Only 21 years away

#49

Post by TillE »

antirez wrote: post #24

Using a 64 bit timestamp will only move the problem 292 million years forward, so probably the best solution is to use a variable length field.

It's kind of impressive the scale of data you can represent when you merely double those very limited 32 bits. Obviously not enough to count every nanosecond in the history of the universe (128 bits would be more than enough for that), but still.

Re: 2038: Only 21 years away

#50

Post by deathanatos »

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.google.com/intl/en/ipv6/statistics.html

Post reply on HN