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

201–210 of 333 posts

Re: 2038: Only 21 years away

#201

Post by gbrown_ »

noselasd wrote: post #167
gbrown_ wrote: post #77

Earlier quoted context omitted.

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.

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

Re: 2038: Only 21 years away

#202

Post by C4K3 »

devcpp wrote: post #185
mikesickler wrote: post #127

Earlier quoted context omitted.

Wikipedia says 292 Billion years forward: https://en.wikipedia.org/wiki/Year_2038_problem

Then I guess it's wrong. https://www.wolframalpha.com/input/?i=years+in+(2%5E64)%2F2+...

Your example counts milliseconds. It is 292 billion, from units:

    You have: (2^64 / 2) seconds
    You want: years
	(2^64 / 2) seconds = 292277265670.798 years

Re: 2038: Only 21 years away

#203

Post by Nition »

zem wrote: post #143
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.

the scenario from "accelerando" is more plausible, where an AI rebuilt itself from scratch to eliminate a thompson "trusting trust" hack.

Man, the plot summary of Accelerando sounded so good but I couldn't get past the writing. That dense name dropping of random tech terms was a bit much in particular.

Re: 2038: Only 21 years away

#204

Post by keithpeter »

njharman wrote: post #90
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 upgrad…

I'd add trains to your list. There are locomotives in use in UK that use electronics (I admit not microprocessor based and not running an actual operating system) dating from 1980s. The ones currently being designed may have similar active service times.

Re: 2038: Only 21 years away

#205

Post by Nition »

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…

I don't think the previous user is saying that no-one cared about space, just that no-one cared about 2038. So that conversation wouldn't have happened anyway.

Re: 2038: Only 21 years away

#208

Post by RandomBK »

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

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.

Re: 2038: Only 21 years away

#209

Post by zeptomu »

OnACoffeeBreak wrote: post #101
gbrown_ wrote: post #31

Earlier quoted context omitted.

I'm really curious about the kind of software things like pacemakers run and potential implications from 32-bit time expiring.

I would guess pacemakers don't run Linux. I would be surprised if they run an OS at all. I work on devices that have to survive 20 years on one non-rechargeable and non-serviceable battery, and there's at most a simple scheduler in place to control tasks. We use 32 bits for epoch time, but our epoch starts Jan 1, 2000, so we have 30 years on Linux before this becomes a problem.

This is really interesting! Obviously it is a topic in itself, but do you mind sketching how one develops software in an environment that requires this extreme amount of reliability? If you do not use an existing general-purpose OS, do you even use a MMU? Is it hard real-time?

E.g. what language do you use? Is it SW or HW that you "ship"? You probably perform some kind of verification and or validation - how does the tool chain look like?

Do you perform model-checking on all possible inputs?

Lots of questions, and you do not have to go into detail, but I would appreciate your input, as it is an interesting topic.

Re: 2038: Only 21 years away

#210

Post by nickpsecurity »

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.

That is a great term. Start investing time in static analysis tools in FOSS that find it for you or your customers. Then extend refactoring tools ("source-to-source translators") to automate the job. Apply for YC for growth. Get acquired by IBM who saw all kinds of adaptations for the tool in their mainframe offerings.
Post reply on HN