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

71–80 of 333 posts

Re: 2038: Only 21 years away

#71

Post by jerf »

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…

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 dead now. But they were absolutely counting bits and bytes all the time, by default, in a way few programmers nowadays can appreciate.

It's why we have "creat" instead of "create", it's why file permissions are tightly packed into three octal digits (as one of the old systems Unix ran on was actually a fan of 36-bit machine words, so 9 bits divided things more evenly at the time). It's why C strings are null-terminated, instead of the more sensible in every way length-delimited, except that length delimited strings require one extra byte if you want to support the size range between 256-65535. Yes, the programmers of that time would rather have one extra byte per string than a safe string library. Pre-OSX Mac programmers can tell you all about dealing with one-byte-length-delimited strings and how often they ended up with things truncated at 255 chars accidentally.

In an era where "mainframes" shipped with dozens of kilobytes of RAM, yeah, they cared.

Re: 2038: Only 21 years away

#72

Post by [deleted] »

swalsh wrote: post #47
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.

[deleted]

Re: 2038: Only 21 years away

#73

Post by beamatronic »

Aardwolf wrote: post #59
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...)

21 years ago was 1996. How different is computing now compared to 1996? Do you consider 2017 vs 2038 to probably have more difference or less difference than 1996 vs 2017? If more difference, do you expect technology to accelerate faster in the next 21 years than the last 21 years, and why?

>> How different is computing now compared to 1996?

Distributed computing went from being "something that is possible" to "the default". Otherwise, all the standard resources such as processors, RAM, disk, and networking all got faster and cheaper. USB revolutionized plugging in peripherals. All the CRT displays are gone.

From the Linux command line point of view, you're more likely to use tools written with python, perl, or ruby, but the big change there is package managers. You don't download source or binaries from FTP sites as often as you did in the old days.

Re: 2038: Only 21 years away

#74

Post by 1maginary »

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…

>The graph shows the percentage of users that access Google over IPv6.

I'm finding it really hard to believe, as someone in Guatemala, that 6% of requests to Google here are made over IPv6. Is there any way to gain more insight? e.g. what ISPs are responsible?

Re: 2038: Only 21 years away

#76

Post by Zitrax »

pkulak wrote: post #57

Is 2038 the end of a signed int? If so, can't we just make it unsigned and buy ourselves another 70 years or so? I don't know how much of an issue not being able to represent time before 1970 is, but for timestamps that doesn't seem like it would be an issue.

That would break systems that relies on time stamps earlier than 1970 though.

  int main(void)
  {
      time_t epoch = -100;
      printf("%s", asctime(gmtime(&epoch)));
  }
The above would for example print a time in 1969.

Re: 2038: Only 21 years away

#77

Post by gbrown_ »

masklinn wrote: post #70
gbrown_ wrote: post #42

Earlier quoted context omitted.

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.

The problem is because Linux is just a kernel (not an entire system like BSDs) the syscall ABI is the actual kernel API . If you break it, you break the world. On BSDs, or Window, or most every OS, there's a base "userland" library (e.g. libc) which serves as the kernel API and hides whatever ABI specific syscalls use, Linux doesn't have that.

I know, I'm saying it would be nice if the Linux kernel could set up a method for breaking ABI's in a planned fashion. I'm not saying it would be easy.

Re: 2038: Only 21 years away

#78

Post by axlee »

chiph wrote: post #25
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.

There were fortunes made in 1999 doing similar work.

It was a good time to be a COBOL developer.

Re: 2038: Only 21 years away

#80

Post by Aardwolf »

beamatronic wrote: post #73
Aardwolf wrote: post #59

Earlier quoted context omitted.

21 years ago was 1996. How different is computing now compared to 1996? Do you consider 2017 vs 2038 to probably have more difference or less difference than 1996 vs 2017? If more difference, do you expect technology to accelerate faster in the next 21 years than the last 21 years, and why?

>> How different is computing now compared to 1996? Distributed computing went from being "something that is possible" to "the default". Otherwise, all the standard resources such as processors, RAM, disk, and networking all got faster and cheaper. USB revolutionized plugging in peripherals. All the CRT displays are gone. From the Linux command line point of view, you're more likely to use tools written with python,…

That would also apply for 1996 vs 2005 :/
Post reply on HN