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

291–300 of 333 posts

Re: 2038: Only 21 years away

#291

Post by callalex »

jerf wrote: post #71
dboreham wrote: post #48

Earlier quoted context omitted.

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

Yes, people absolutely cared about bits and bytes, because they weren't very many of them. (Programmers weren't necessarily thinking of them as monetarily expensive, because even today you don't just go slamming more RAM in to your machine if you need more. The problem is that there were only so many of them.) You could still see the residual hacker attitudes even five years ago, though I'd have to call it mostly dea…

>even today you just go slamming more RAM into the machine if you need it

Hmm, every software gig I've had in the past 5 years that's exactly what I've been expected to do because the extra ten bucks a month for a bigger VM is wayyy less expensive than engineering time. Interesting times.

Re: 2038: Only 21 years away

#292

Post by pravda »

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…

I just set up a Windows 98 system last week!

Installation of win98 is so quick, so easy, compared to XP.

But websites don't render so well in the win98 version of IE. I don't think it knows about CSS.

Re: 2038: Only 21 years away

#293

Post by sedachv »

LoSboccacc wrote: post #22
ISL wrote: post #15

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Intel_8086 In the late 1970s, the cutting-edge microprocessor was 16-bit. The first 32-bit Intel chip was the 386, which debuted in 1985. The TRS-80, a common small computer in the late 70s, offered 4kb-48kb of RAM. When using hardware with that capacity, overflowing time_t in 2038 is hardly a concern.

IBM ran 128 bit virtualized architecture on top of 1988 chips.

Which was a backward-compatible extension of a 48-bit address space system built out of 1970s chips: http://bitsavers.trailing-edge.com/pdf/ibm/system38/IBM_Syst...

Re: 2038: Only 21 years away

#294

Post by taneq »

nsxwolf wrote: post #120
AlexC04 wrote: post #44

Earlier quoted context omitted.

I hope you've trademarked the term "epochalypse" because it is really catchy! I love it.

I will be just 5 years away from retirement, so I will use this as an opportunity to shore up my 401k. Of course, the singularity will be here by then and fix it for us just before turning us all into paper clips, yada yada. I will advertise with the slogan "Epochalypse... NOW."

> turning us all into paper clips

A paperclipocalypse?

Re: 2038: Only 21 years away

#295

Post by lispm »

sedachv wrote: post #247
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.

That is actually how Common Lisp represents time: https://www.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Bo... When you look up "integer": https://www.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Bo... "An integer is a mathematical integer. There is no limit on the magnitude of an integer." What happens when an integer overflows from a fixnum (single-word representation) is that it gets upgraded to a bignum behin…

In systems one still needs to interface Common Lisp with the real world in correct ways. Reading & printing dates in various formats wasn't always correct in some applications.

Re: 2038: Only 21 years away

#296

Post by tragic »

taneq wrote: post #294
nsxwolf wrote: post #120

Earlier quoted context omitted.

I will be just 5 years away from retirement, so I will use this as an opportunity to shore up my 401k. Of course, the singularity will be here by then and fix it for us just before turning us all into paper clips, yada yada. I will advertise with the slogan "Epochalypse... NOW."

> turning us all into paper clips A paperclipocalypse?

Paperclipalypse works for me

Re: 2038: Only 21 years away

#297

Post by jodrellblank »

TillE wrote: post #49
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.

Double again to 256 bits, and there isn't enough energy in the mass of the solar system to power the most efficient state change device conceivable through 2^256 state changes.

https://security.stackexchange.com/a/6149/1427

Re: 2038: Only 21 years away

#298

Post by masklinn »

gbrown_ wrote: post #201
noselasd wrote: post #167

Earlier quoted context omitted.

Linux has a method - which is to add the new in parallel to the old, and remove the old at a later time when it's certainly no longer needed.

That's OK for Linux specific stuff but stat() is pretty standard. So downstream will end up having to clutter code to the effect of - if running on Linux use statx() else if running on non-broken platform use stat().

> That's OK for Linux specific stuff but stat() is pretty standard.

The libc (~POSIX) call is "pretty standard" and uses typedef'd pseudo-abstract types (OSX's stat has been 64b optionally since 10.5 and by default since 10.6, though the 32b version seems to remain available in 10.11 by compiling with _DARWIN_NO_64_BIT_INODE), the underlying syscall is not in any way.

Re: 2038: Only 21 years away

#299

Post by lokedhs »

astrodust wrote: post #276
hinkley wrote: post #270

Earlier quoted context omitted.

Woah, you were alive in the year 2000? Tell us what that was like, grandpa!

Our phones sucked and we had to watch television with commercials you couldn't skip.

I don't know what phone you had in 2000, but I had a Nokia 2100 in 1996 and it was the best phone ever made.

Now that I think about it, I probably had an Ericsson T28 in 2000 and it did kinda suck.

Re: 2038: Only 21 years away

#300

Post by gbrown_ »

RandomBK wrote: post #208
gbrown_ wrote: post #201

Earlier quoted context omitted.

That's OK for Linux specific stuff but stat() is pretty standard. So downstream will end up having to clutter code to the effect of - if running on Linux use statx() else if running on non-broken platform use stat().

I wouldn't expect many applications to call the actual syscalls directly - most will defer to libc or some other layer of abstraction, where these differences can be hidden away.

Do'h, of course!
Post reply on HN