Here I thought it was a post on the singularity. It might be ironic if all the AI starts running into all sorts of 2038 bugs and this ends up being a huge issue.
2038: Only 21 years away
61–70 of 333 posts
Re: 2038: Only 21 years away
#62Earlier quoted context omitted.
When you're mainly working with 32bit CPUs (or less) and the year of overflow is almost 50 years in the future I can forgive them for considering it was good enough at the time. Maybe they thought that by the time it was going to be an issue somebody else would've replaced it? It's in the same bag as IPv4 "only" supporting a few billion addresses, hindsight is always 20/20... Moreover even 64bit timestamps wouldn't b…
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 the network, and the last 24 bits are the local address; [...]
7 bit network times 24bit local addresses is already more than two billions.
Re: 2038: Only 21 years away
#63Earlier quoted context omitted.
There is a certain amount of snark embedded in this post, but its not a bad idea at all - I'll be in much the same boat at that time - perhaps I can borrow the same idea...
It wasn't intended to be sarcastic. I suspect there will be a lot of businesses (especially finance) interested in verifying that the "ancient" Linux system they setup to replace their mainframe 25 years "ago" is safe. I lived through the Year 2000, and watched the same thing happen there. With suitable groundwork, there will be a willing and wealthy market looking for people to assuage their fears - a service I see…
Databases too. MySQL has a 2038 bug in their UNIX_TIMESTAMP function.
select unix_timestamp('2038-01-19') returns 2147472000
select unix_timestamp('2038-01-20') returns 0Re: 2038: Only 21 years away
#64This 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 hope you've trademarked the term "epochalypse" because it is really catchy! I love it.
He didn't invent it. It's been around about as long as people have seen this problem coming.
Re: 2038: Only 21 years away
#65Is 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…
If you told the original UNIX developers that there was even the slightest chance their system might still be in use in 2038, they probably would have called in some large, friendly men in white coats to haul you away.
Add to that the fact that memory was very much not cheap at the time. Memory for the PDP-7 (the first computer to run UNIX) cost $12,000-20,000 for 4kB of memory. In 1965 dollars. In 2017 terms, that means that wasting four bytes had an amortized cost of three hundred to six hundred dollars. And that's for each instance of the type in memory.
Re: 2038: Only 21 years away
#66> 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.)
The only time I build from source (ports) on FreeBSD is because the package maintainer picked "crappy"[1] options. On OpenBSD, I can generally find the flavor of port that has the options I want. If I cannot I resort to ports.
1) for my definition of crappy, not compiling PostgreSQL support is the most common for me
Re: 2038: Only 21 years away
#67Is 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…
Back in 1970, no language had a 64-bit integer type. And it started with Unix, which was a skunkworks hobby project, so a thinking of "we'll solve it within the next 68 years" is perfectly reasonable. They could have made it unsigned instead of signed, which would have made it work until 2100 or so, but I think a 68-year horizon is more than most systems being built today have.
>They could have made it unsigned instead of signed
C actually didn't have unsigned integer types in the beginning. They were added many years later and also not at the same time. For example, the Unix V7 C compiler only had "unsigned int".
Re: 2038: Only 21 years away
#68Using 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.
On the other hand, using a 64 bit integer to count seconds moves the problem 292 billion years forward, and we can probably let the Omega Point handle it from there.
On the other other hand, getting greedy and using a 64 bit integer to count nanoseconds only moves the problem 448 years forwards. That's long enough to seem like it's perfectly safe, but short enough that it might just not be.
Re: 2038: Only 21 years away
#69And IPv6 penetration will have hit 20%.
It is already over 50% in the US.
Re: 2038: Only 21 years away
#70Earlier 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.
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.