This reminds me that I wanted to look at increasing the size of the username in /var/log/{btmp,wtmp} which currently is only 8 characters - this output powers "last" and "who".
But the on-disk format is based on the struct as defined in the headers. They'll need to expand that for 64-bit so thought I could try backload the change on that same period.
Not necessarily. Using a 64-bit system and think you're safe? But what if the binary you're running has been compiled for a 32-bit system? What if this is a cloud service you're not even aware of?
As a true example here, my parents' house uses a simple computer to automate watering of different places in their garden. Looked the chip up, 32 bit system. So this will definitely stop working on Jan 2038.
This is just the tip of the iceberg. 2038 is going to be a big issue.
It's not as simple as that. I had a C library using 64-bit time_t on 32-bit CPUs back in the early 1990s. 32-bit CPUs are not incapable of doing 64-bit arithmetic. You cannot infer the bitness of time_t from the bitness of the CPU.
It doesn't run 64bit code but that has nothing to do with handling 64bit numbers. Compiler just generates more instructions (and the execution is slower). Example for multiplication:
https://godbolt.org/g/m1t4NC
...which control at least one plant in Canada (though recently it was replaced with an emulation.)
And apparently they solved the 16-bit data problem, but maybe not the 32-bit date problem.
"A current generation DCC system resides at L3 MAPPS' main Montreal, Canada facility and is used to provide support to all participating COG members until 2035."
Nuclear power plants run critical systems on mostly analog and sometimes pld devices (much easier to formally verify). They also generally don't care about date-time and have rigorous testing/verification. Nuclear PP are not something to worry about for a 2038 bug. It's the industries that don't employ traditional engineering practices that are worrisome.
The most important thing for now is to start to work out and track where devices are so as to be able to be sure to get them when the time to sort this out arrives (2028?)
> In terms of things like on-disk data structures, don't try to second-guess future interfaces by simply adding padding space for a 64-bit time_t or equivalent. The final solution for time handling may not be what you expect and you might just make things worse.
That's pretty unhelpful.
I'll give different advice: store time as leap-second-corrected milliseconds since the standard epoch in a signed 64-bit field. If the Linux maintainers eventually come up with something wacky, write conversion code.
This is the standard format in the Java/JVM world. You might not care about that world, but it at least means this format isn't going away. Any new time convention has to be compatible with this because of the sheer amount of stuff it would break if it wasn't.
When Y2K got hot I told all my team members that 2038 would be worse. At least Y2K was easy for humans to understand, they all could see 1999 => 2000 and how that seemed important. I had bank CIO's and large movie studio CIO's calling me with "unlimited budget to fix this". Because it was easy for their CEO and CFO to understand.
The challenge here will be that this seems awkward from a non-computer science standpoint. Have you tried to explain this to your Mom yet? It's obvious to bit heads but not regular humans. Even my own very technical team thought I was a bit off my rocker talking about this in 1999.
The other very real challenge is the generation gap, many devs working on stuff today have no experience with Y2K issues, they just haven't been working on systems long enough to be bitten by that stuff. They look at old code where some "if (yy < 69)" hack was put in place to support old YYMMDD formats and wonder what the crazy dev was thinking when they pushed that code.
On top of all these issues we have IOT being deployed by brilliant young minds who have no experience dealing with things that have to work for 50 years plus. If anything, the IOT ecosystem is moving to a "technology consumer" mentality where things are built to barely survive 18 months and everyone is moving so quickly they don't worry about 2038 because "it's eons from now". Most of these companies won’t be in business in 2038 but their products will litter the world and still be plugged in bashing away at whatever the internet is by then.
The velocity of this decade is amazing, I stand in awe as I watch all the new technologies that get cranked out in rapid succession. However much of that has been due to the "fail fast, iterate rapidly" approach. Which is great in many ways, but formal verification has taken a back seat while most teams have no engineering review team. These things slowed us down in the past and we have rightfully tossed them over our shoulders in the ever rapidly accelerating pursuit of innovation. However, we have lost of a lot of what it really means to be an “engineer” along the way.
Hacking is great, until it gets someone killed. Thus far software has eaten most of the world that doesn’t kill people. Now we tread into the world that will, the physical world, self-driving trucks, trains, planes, automobiles. Coffee makers that boil over and burn a four-year-old kid who just thought it was fun to push the red thing on dad’s tablet. This is the world we are headed into, and the 2038 problem is really just the tip of the iceberg.
I can tell you the Y2K problem was real, it was painful but easier for humans to understand. If we want companies to prioritize resources to fix 2038 problems now over the next shiny button they want in their UI we will need a massive marketing campaign to get people to understand. Because in the end devs don’t make all the decisions on resource allocation and the people who do have no clue how things really work. It’s an age-old tension between the technologists and the business leaders. How we overcome that here is unclear to me, but I think the basic issue is getting people to understand the potential impact so it comes up in conversations in the Board Room and the CEO is asking the CIO/CTO “So what are we doing about 2038?”. Otherwise nothing will happen on the corporate side.
sure do - John Titor... I still think of him often he was an interesting piece of internet history/culture...and brought up lots of interesting questions...never did have that 2008 civil war...but 2017 looks close...lol
>We can't just replace all the existing interfaces with 64-bit versions, of course - we need to continue suporting the existing interfaces for existing code.
The backwards compatibility problem in a nutshell. You can put off breaking stuff today and kick the can down the road some more, but where does it end? January 19, 2038?
I think it boils down to a philosophical difference, not really a practical difference, despite the inevitable arguments that "we can't just go around breaking all the shit that's already deployed." Even though the pain would be greater short-term, the benefits of breaking stuff today almost always outweighs the hazards of putting it off indefinitely, since there's almost never any motivation for going back and removing the workarounds once a stable solution is implemented. As evidence, OpenSSL is Exhibit A.
25 comments
[ 3.6 ms ] story [ 62.1 ms ] threadBut the on-disk format is based on the struct as defined in the headers. They'll need to expand that for 64-bit so thought I could try backload the change on that same period.
* https://manpages.debian.org/stretch/manpages/utmpx.5.en.html
As a true example here, my parents' house uses a simple computer to automate watering of different places in their garden. Looked the chip up, 32 bit system. So this will definitely stop working on Jan 2038.
This is just the tip of the iceberg. 2038 is going to be a big issue.
And apparently they solved the 16-bit data problem, but maybe not the 32-bit date problem.
"A current generation DCC system resides at L3 MAPPS' main Montreal, Canada facility and is used to provide support to all participating COG members until 2035."
http://mapps.l3t.com/candu-plant-control-systems.html
Embedded systems are switching from 8bit to 32bit and many of them will have no reason to switch to 64bit.
That's pretty unhelpful.
I'll give different advice: store time as leap-second-corrected milliseconds since the standard epoch in a signed 64-bit field. If the Linux maintainers eventually come up with something wacky, write conversion code.
This is the standard format in the Java/JVM world. You might not care about that world, but it at least means this format isn't going away. Any new time convention has to be compatible with this because of the sheer amount of stuff it would break if it wasn't.
The challenge here will be that this seems awkward from a non-computer science standpoint. Have you tried to explain this to your Mom yet? It's obvious to bit heads but not regular humans. Even my own very technical team thought I was a bit off my rocker talking about this in 1999.
The other very real challenge is the generation gap, many devs working on stuff today have no experience with Y2K issues, they just haven't been working on systems long enough to be bitten by that stuff. They look at old code where some "if (yy < 69)" hack was put in place to support old YYMMDD formats and wonder what the crazy dev was thinking when they pushed that code.
On top of all these issues we have IOT being deployed by brilliant young minds who have no experience dealing with things that have to work for 50 years plus. If anything, the IOT ecosystem is moving to a "technology consumer" mentality where things are built to barely survive 18 months and everyone is moving so quickly they don't worry about 2038 because "it's eons from now". Most of these companies won’t be in business in 2038 but their products will litter the world and still be plugged in bashing away at whatever the internet is by then.
The velocity of this decade is amazing, I stand in awe as I watch all the new technologies that get cranked out in rapid succession. However much of that has been due to the "fail fast, iterate rapidly" approach. Which is great in many ways, but formal verification has taken a back seat while most teams have no engineering review team. These things slowed us down in the past and we have rightfully tossed them over our shoulders in the ever rapidly accelerating pursuit of innovation. However, we have lost of a lot of what it really means to be an “engineer” along the way.
Hacking is great, until it gets someone killed. Thus far software has eaten most of the world that doesn’t kill people. Now we tread into the world that will, the physical world, self-driving trucks, trains, planes, automobiles. Coffee makers that boil over and burn a four-year-old kid who just thought it was fun to push the red thing on dad’s tablet. This is the world we are headed into, and the 2038 problem is really just the tip of the iceberg.
I can tell you the Y2K problem was real, it was painful but easier for humans to understand. If we want companies to prioritize resources to fix 2038 problems now over the next shiny button they want in their UI we will need a massive marketing campaign to get people to understand. Because in the end devs don’t make all the decisions on resource allocation and the people who do have no clue how things really work. It’s an age-old tension between the technologists and the business leaders. How we overcome that here is unclear to me, but I think the basic issue is getting people to understand the potential impact so it comes up in conversations in the Board Room and the CEO is asking the CIO/CTO “So what are we doing about 2038?”. Otherwise nothing will happen on the corporate side.
https://www.openbsd.org/papers/eurobsdcon_2013_time_t/index....
The backwards compatibility problem in a nutshell. You can put off breaking stuff today and kick the can down the road some more, but where does it end? January 19, 2038?
I think it boils down to a philosophical difference, not really a practical difference, despite the inevitable arguments that "we can't just go around breaking all the shit that's already deployed." Even though the pain would be greater short-term, the benefits of breaking stuff today almost always outweighs the hazards of putting it off indefinitely, since there's almost never any motivation for going back and removing the workarounds once a stable solution is implemented. As evidence, OpenSSL is Exhibit A.
PRs welcome, not sure how much time I have to do the research.