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

121–130 of 333 posts

Re: 2038: Only 21 years away

#122

Post by cat199 »

dboreham wrote: post #48
jamoes wrote: post #26

Earlier quoted context omitted.

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

PDP-11:

https://en.wikipedia.org/wiki/PDP-11_architecture#CPU_regist...

5x 16 bit registers.

So ability to operate on 1x 64 bit number and some change if loaded all at once.

How many instructions do you think it would take to add/subtract 2x 64 bit integers? vs 2x 32 bit integers on such a machine?

Not to mention having to implement and debug this logic in assembly on a teletype vs using a native instruction.. (see "Extended Instruction Set (EIS)" in same link)

Noone would have considered 64 bits at all because it would have been a huge hassle and not worth it, even beyond thinking ahead in this way..

Besides.. if 'the last OS I worked on' was probably the 1st or second interactive timesharing system ever written, give or take (e.g MULTICS/ITS), and I worked on it at a low level, because thats what people did, chances are, I might have talked to the person who came up with the idea on how to store the time on that system.. who conceivably could be the 2nd or 3rd person ever to actually implement this, ever.. And if this is the case, don't you think, that person would have thought about it somewhat?

Programmers at that time were many times much better at these things than now..

See also: http://catb.org/jargon/html/story-of-mel.html

(which itself was posted in 1983 concerning the same topic...)

I'd suggest spinning up some SIM-H VM's and mucking around for a while with early unices (v5,v7,32V,4.3BSD), and probably ITS or TOPS-10/TWENEX as well ... it is quite illuminating and very insightful.

Re: 2038: Only 21 years away

#124

Post by drzaiusapelord »

tyingq wrote: post #111
drzaiusapelord wrote: post #103

Earlier quoted context omitted.

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…

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.

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.

Re: 2038: Only 21 years away

#125

Post by drzaiusapelord »

JoachimSchipper wrote: post #118
drzaiusapelord wrote: post #103

Earlier quoted context omitted.

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…

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

Re: 2038: Only 21 years away

#128

Post by mark4o »

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

In Unix v1 (1971) it actually did not even track the year. The time system call was documented as "get time of year", and returned "the time since 00:00:00, Jan. 1, 1971, measured in sixtieths of a second" (https://www.bell-labs.com/usr/dmr/www/pdfs/man22.pdf). The operator had to set the time on each boot, and there was no option to set a year. The PDP-7 hardware could increment a counter every 1/60 second but only while it was powered on. Later the time was changed to whole seconds and redefined to be the time since January 1, 1970 00:00:00 GMT (now UTC), but was kept 32 bits.
Post reply on HN