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

81–90 of 333 posts

Re: 2038: Only 21 years away

#81

Post by mrweasel »

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…

Because OpenBSD already did a large part of the work, and ensuring that software in their ports tree still work (and pushing patches to upstream developers) it should require less of an effort for Linux to go the same route.

Re: 2038: Only 21 years away

#82

Post by cesarb »

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.

That only moves the problem outwards; instead of having to keep compatibility within the syscall ABI, you have to keep compatibility within the "base userland library" ABI, which is probably much larger (for instance, printf is not a syscall).

Re: 2038: Only 21 years away

#84

Post by hunterjrj »

jpm_sd wrote: post #37
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.

Good idea. Our Qeng Ho descendants will thank us. [0] [0] https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Interste...

Up vote for the Deepness reference! What a great novel, and I suspect the concept of a "programmer archaeologist" would be of interest to many here...

Re: 2038: Only 21 years away

#85

Post by Retric »

ejcx wrote: post #58
swalsh wrote: post #47

Earlier quoted context omitted.

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.

If humans are still alive 292million years in the future, seems like that's our best time to take control back from our sentient AI overlords.

I think this would make a great science fiction setting. Where some clock error destroys most/all the magic tech out there and humanity is doing hunting and gathering on space stations etc.

Re: 2038: Only 21 years away

#87

Post by ProblemFactory »

gbrown_ wrote: post #42
Aissen wrote: post #39

Earlier quoted context omitted.

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.

stat() takes a pointer to a struct where to write its output. This struct currently has 32bit values for time.

If you updated stat() to write 64bit values into a different struct, any existing program calling it with a pointer to an old struct would get garbage data (and a potential buffer overflow).

Renaming the function also makes debugging easier - after statx() is in widespread use, stat() could be replaced with a placeholder that raises the SIGTRAP signal, and immediately detects epoch-unsafe programs still in use.

Re: 2038: Only 21 years away

#88

Post by abfan1127 »

gbrown_ wrote: post #31
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'm really curious about the kind of software things like pacemakers run and potential implications from 32-bit time expiring.

pacemakers I worked on ran on 8 bit MCUs.

Re: 2038: Only 21 years away

#89

Post by masklinn »

cesarb wrote: post #82
masklinn wrote: post #70

Earlier quoted context omitted.

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.

That only moves the problem outwards; instead of having to keep compatibility within the syscall ABI, you have to keep compatibility within the "base userland library" ABI, which is probably much larger (for instance, printf is not a syscall).

> That only moves the problem outwards

It also moves it to a place where you can have somewhat abstracted types (so chances are the client will work with just a recompile as it picks up the updated typedef), you can much more easily prepare the transition by e.g. using various flags or even trying alternatives beforehand (for instance OSX originally added a stat64 call before before rollbacking that choice and using macros to transition stat to 64b), and you are able to stop before a completely mangled syscall is actually attempted (by checking for some version symbol which must be set if you compiled for the 64b version of the various syscalls).

Re: 2038: Only 21 years away

#90

Post by njharman »

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

> Call me stupid,

Well I won't say you are stupid. But do you realize we are talking about a time format "designed" 40+ years ago. And some cpus are still compatible with chips from 80's 90's. To imagine all that will go away and be solved in 20 years is not logical.

Also, the problem isn't with PCs (which will be upgraded) but the billions of IoT, industrial controls, and other embedded devices that lack easy upgrade paths. Things like elevators, pressure release valves, cars.

Post reply on HN