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

311–320 of 333 posts

Re: 2038: Only 21 years away

#311

Post by drzaiusapelord »

ajdlinux wrote: post #286
sedachv wrote: post #241

Earlier quoted context omitted.

Pretty much everything in your post is wrong. IBM mainframes are heavily virtualized and have very good support for moving to larger address spaces. VM and MVS moved from 24-bit to 31-bit to 64-bit address spaces. You can run the old 24-bit applications and upgrade them as needed. Even assembly programs - the old assemblers and instructions are supported on newer hardware. System i (System/38-AS/400) was built around…

Also note that IBM mainframes can run 64-bit Linux just fine. Indeed, IBM's been marketing its LinuxONE mainframe line as a z series machine that doesn't run z/OS at all. (disclaimer: IBMer, but not a mainframe person)

We're talking Mainframe system designs and code from the 70s and 80s. No they aren't running 64-bit linux. I think you guys need to re-read my post. The legacy systems on Y2K had none of these features.

Re: 2038: Only 21 years away

#312

Post by Sean1708 »

mcbits wrote: post #301
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.

64 bits only cover about 7 months at picosecond resolution, so it's possible that 64 bit timestamps will be too small sometime this century, depending on how tightly synchronized the world becomes. An extensible timestamp might not be a bad idea and could still be kept under 64 bits for currently practical purposes.

For picosecond resolution to be useful wouldn't clock rates need to be on the order of THz? Otherwise what advantages would ps resolution give you over ns?

Re: 2038: Only 21 years away

#313

Post by clarry »

cbr wrote: post #34
mrkgnao wrote: post #32

> BSD-based distributions have the advantage of being able to rebuild everything from scratch, so they do not need to maintain user-space ABI compatibility in the same way. I don't understand, not knowing much about BSD. Is this an LTS/support thing? Can someone explain?

Generally people build BSD packages from source instead of installing binaries. (I think; I've not used BSD.)

OpenBSD user since 2009. I have never compiled a package from source.

But they can break the ABI because they do not want to maintain compatibility with old proprietary binaries. It's a source world, in the sense that any software can and will be recompiled if and when needed. That doesn't mean every user has to compile their own system.

Re: 2038: Only 21 years away

#314

Post by sobani »

gnopgnip wrote: post #69
grabcocque wrote: post #2

And IPv6 penetration will have hit 20%.

It is already over 50% in the US.

thanks to runeks [https://news.ycombinator.com/item?id=13925396]

according to https://mobile.slashdot.org/story/16/08/20/2059216/ipv6-achi... it's only the US mobile carriers that are over 50%.

Re: 2038: Only 21 years away

#315

Post by dboreham »

simias wrote: post #62
dboreham wrote: post #51

Earlier quoted context omitted.

IPv4 as designed didn't support anything like a few billion addresses. We had to invent CIDR to get there, years later.

Are you sure about that? If we're talking as IPv4 as specified in RFC 791[0] (dated September 1981) it seems to support billions of addresses already: > Addresses are fixed length of four octets (32 bits). An address begins with a network number, followed by local address (called the "rest" field). There are three formats or classes of internet addresses: in class a, the high order bit is zero, the next 7 bits are th…

I'm sure because I was there, at the meetings when CIDR was proposed and adopted.

Re: 2038: Only 21 years away

#316

Post by dboreham »

Nition wrote: post #205
jerf wrote: post #71

Earlier quoted context omitted.

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.

Indeed. There was no carefully considered trade-off made between storage space and brokenness in 70 years time. Nobody thought like that. Nobody would have expected their code and data to be remotely relevant that far into the future. People wrote code according to present-day norms which would have included using a 32-bit integer for time.

Re: 2038: Only 21 years away

#317

Post by dboreham »

leoedin wrote: post #211
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…

Whenever I do embedded work with counters, every time I assign a variable that has a possibility of overflowing I do a little mental count about how likely it is to overflow. That's part of of the software development process. They may not have had a meeting about it, but I think it's exceedingly unlikely that whoever decided to assign a 32 bit int to store time didn't give some consideration to the date range it cou…

They didn't design it in a vacuum. They had worked on other OS'es already that used 32-bit ints with a 1 second quantum and they (probably subconsciously) thought that if it had been good enough for those other systems it was good enough for Unix.

Re: 2038: Only 21 years away

#318

Post by nickpsecurity »

zeptomu wrote: post #230
OnACoffeeBreak wrote: post #224

Earlier quoted context omitted.

No MMU. It is hard real-time in the sense that there are events that need to be processed withing a small time window (a few microseconds (with help from hardware typically) to milliseconds). The product is custom hardware built with off-the-shelf parts like microcontroller, power converters, sensors, memory. Texas Instruments MSP430 family of microcontrollers [1] is popular for this type of application. They are bas…

Thank you for your thorough answer. I am surprised that you do not apply some kind of verification or checking using formal methods, however it might be the case (at least it is the experience I have) that this is still too inconvenient (and so expensive) to do for more complex pieces of software.

Actually, the high-assurance field that does such things is very small. A tiny niche of the overall industry. Most people doing embedded systems do things like the parent described. The few doing formal usually are trying to achieve a certification that wants to see (a) specific activities performed or (b) no errors. Failures mean expensive recertifications. Examples include EAL5+, esp DO-178B or DO-178C, SIL, and so on. Industries include aerospace, railways, defense, automotive, supposedly medical but I don't remember a specific one. CompSci people try formal methods on both toy, industrial, and FOSS designs all the time with some of their work benefiting stuff in the field. There's barely any uptake despite proven benefits, though. :(

For your pleasure, I did dig up a case study on using formal methods on a pacemaker since I think someone mentioned it upthread.

http://www.comp.nus.edu.sg/~pat/publications/ssiri10_pacemak...

David Wheeler has the best page on tools available:

https://www.dwheeler.com/essays/high-assurance-floss.html

Here's a work-in-progress of my list of all categories of methods for improving correctness from high-assurance security that were also field-proven:

https://lobste.rs/s/mhqf7p/static_typing_will_not_save_us_fr...

Re: 2038: Only 21 years away

#320

Post by valuearb »

contingencies wrote: post #258
narrator wrote: post #163

Earlier quoted context omitted.

Yes, I know some of us will never retire. 8000 years in the future career planning is an interesting thing to think of though. 8000 years ago the only thing that was going on was some neolithic agriculture. Domestication of the Jungle Fowl (modern day chicken) in India and the beginning of irrigated agriculture in Sumeria were probably the biggest news items of that millennium. I guess someone from 8000 years ago cou…

There was almost certainly some forms of relatively advanced seafaring 8000 years ago possibly including skin boats, sails and paddles, ropes, sealants and astronomy. Also, fairly sophisticated metallurgy was widespread with at least silver/iron/gold, possibly bronze. Writing was known to some cultures. Horses, camels and water buffalo were likely all domesticated. Use of drying/smoking for preservation and curing of…

I can believe seafaring, astronomy, and metallurgy. But yogurt? Now you're just pulling my chain.
Post reply on HN