6 ms·

It bothers me that they are only doing the transition now. It should have been done 20 years ago. 2038 is less than 15 years away and I bet a significant porti

It bothers me that they are only doing the transition now. It should have been done 20 years ago. 2038 is less than 15 years away and I bet a significant portion of systems will not be upgraded during this period. (As a reference, Windows 7 was released 15 years ago and it's still on 3% usage share [1].) What's worse, compared to Y2K problem, in 2038, much more critical infrastructures will depend on computers (payment, self-driving cars, public transportation, security cameras, etc etc). We are doomed. [1] https://en.wikipedia.org/wiki/Template:Windows_usage_share https://en.wikipedia.org/wiki/Template:Windows_usage_share

Denvercoder9 2y ago
Note that for most systems this transition already happened with the transition to 64-bit architectures, in the 2000s. It's only 32-bit architectures to which the current transition applies. Debian couldn't have transitioned them 20 years ago, as kernel support for 64-bit time_t on a 32-bit architecture is fairly recent (Linux 5.6 in 2020).
- asveikau 2y ago
  I remember OpenBSD working on this about 10 years ago. Also, strictly speaking transitioning with the CPU architecture is not enough -- having kernel APIs and ABIs have 64-bit time_t is not the only place it needs to change. Notably, it has to change in the filesystem too. And at that point millions of people will have on-disk structures with 32bit timestamps, so it needs to transition in a somewhat back compatible way.
- phaedrus 2y ago
  Except some communication protocols have a 32 bit timestamp baked into the format.
htjrjfjtktn 2y ago
[flagged]
tomxor 2y ago
> 2038 is less than 15 years away and I bet a significant portion of systems will not be upgraded during this period. No, Linux distro releases are not like Windows, there is little reason to be holding back and running 15 year old systems. If you are running Debian 12 in 2038, lack of t64 will be the least of your issues. Debain 12 standard LTS ends in 2028 [0] and extended support (if you pay for it) ends in 2033 [1]. Beyond that you're on your own. If you're running servers, you'd be mad to be running any the current stable and old-stable releases by then. [0] https://wiki.debian.org/LTS https://wiki.debian.org/LTS [1] https://wiki.debian.org/LTS/Extended https://wiki.debian.org/LTS/Extended
- soupbowl 2y ago
  I worked on ancient redhat and debian Linux equipment recently. Just because it shouldn't be used or is "easy" to upgrade means nothing in the real world. That applys now and it will 15 years from now.
  - yoyohello13 2y ago
    People willfully/recklessly running systems well beyond eol is not the problem of maintainers.
    - HeatrayEnjoyer 2y ago
      It will be everyone's problem if critical infrastructure stops working. Nobody gives a flying carp who's fault it is when erroneous air traffic control systems start killing people or bank transactions stop processing.
      - ranger_danger 2y ago
        Everyone except for the people who voted to EOL those older OSes people still use.
        HeatrayEnjoyer 2y ago
lamontcg 2y ago
> We are doomed. Doubt it. Any disruption will probably be two orders of magnitude less than the COVID-19 pandemic. Most systems (like self driving cars or payments) will be 64-bit and unaffected. Anything critical still running 32-bit will be on these kinds of debian distros or NetBSD or whatever. The stuff that breaks will mostly be flashing-VCR-time impacts that can be worked around (timestamps on security cameras may wrap around to 1970 and be impossible to set to the correct date, but the cameras should still continue working). There may be stupid companies that go bankrupt because all their devices fail hard and they get sued out of existence, but that kind of impact happens all the time. Just looking at something like the list of largest trading losses in banks: https://en.wikipedia.org/wiki/List_of_trading_losses https://en.wikipedia.org/wiki/List_of_trading_losses The economy has a very large capacity for dumbassery. Most hard failures will just be Keynesian stimulus for their competitors. Any hard failures that result in losses to the customers (e.g. stores robbed because security cameras down) will get absorbed by insurance -- and really they're already getting robbed so much by smash and grabs with stolen vehicles I doubt it matters.
TacticalCoder 2y ago
From TFA: > This is now less that 15 years away and plenty of system that will have problems have already been shipped. We should stop adding to the problem. Most computing, especially computing using Debian or its derivatives, is now done on 64-bit hardware where this issue does not arise. The goal is to support 64 bit time on 32 bit systems. > We are doomed. We really aren't. Y2K was a big nothingburger despite the media scaremongering. 64 bit systems are already nearly everywhere. As TFA states: most distros don't even bother supporting 32 bit hardware anymore. They simply don't. Are there going to be tiny Internet-of-shitty-insecure-Things devices out there failing in 2038? Very likely. Nuclear powerplants failing, nuclear warheads launched by mistake and lab doors wrongly opened (from labs where they do GoF research on deadly viruses)? Nope. Not gonna happen.
- immibis 2y ago
  Plenty of single-purpose 32-bit ARM systems are around.
- NoahKAndrews 2y ago
  Wasn't it a nothingburger because of the massive effort to get everything important updated in time?
IshKebab 2y ago
How many 32 bit time-dependent systems running 15 year old Linux do you think there will be in 2038? It's going to be a handful at most.
- immibis 2y ago
  I worked on one. Cellphone routers deployed in remote locations, yes including handling 911 calls. They'll probably all crash at the rollover and require a technician to come and upgrade the firmware on site.
ezoe 2y ago
Do you really remember 20 years ago? I do. It was year 2004. Linux kernel 2.6 was still in development and people are using 2.2 or even 2.0. The latest stable Debian was Woody at that time, using Linux kernel 2.2. GNU/Linux was still struggling to support POSIX threads. ext3 was merged to the Linux kernel in 2001 and people were still using ext2. ext2/ext3 has year 2038 problem but in year 2004, nobody think it seriously. Even the ext4 had year 2038 problem and later got a workaround to prolong its life for another few hundred years. UTF-8 standard was just finalized in 2003 and nobody thought it will be the default character encoding. No GNU/Linux Distros at that time uses UTF-8 as the default locale. Most people believed UTF-16 was the future but reluctant to change , except for Microsoft Windows. Microsoft was the early adopter of Unicode and they are paying for their failure of choosing UTF-16 while all other OSes, web browsers and everything later choose UTF-8. People of 2004 realized the year 2038 problem. But there was no way we could use 64 bit signed integer as time_t at that time. Even for the filesystem. Even if we tried to fix it in 2004, it was probably a bad choice that needed to be redone right now. Personally, I think that if people are still using Linux kernel 2.2 or Windows CE in their embedded system in year 2038, they have serious other problems as well.

Denvercoder9 2y ago

Note that for most systems this transition already happened with the transition to 64-bit architectures, in the 2000s. It's only 32-bit architectures to which the current transition applies. Debian couldn't have transitioned them 20 years ago, as kernel support for 64-bit time_t on a 32-bit architecture is fairly recent (Linux 5.6 in 2020).

asveikau 2y ago
I remember OpenBSD working on this about 10 years ago. Also, strictly speaking transitioning with the CPU architecture is not enough -- having kernel APIs and ABIs have 64-bit time_t is not the only place it needs to change. Notably, it has to change in the filesystem too. And at that point millions of people will have on-disk structures with 32bit timestamps, so it needs to transition in a somewhat back compatible way.
phaedrus 2y ago
Except some communication protocols have a 32 bit timestamp baked into the format.

htjrjfjtktn 2y ago

[flagged]

tomxor 2y ago

> 2038 is less than 15 years away and I bet a significant portion of systems will not be upgraded during this period. No, Linux distro releases are not like Windows, there is little reason to be holding back and running 15 year old systems. If you are running Debian 12 in 2038, lack of t64 will be the least of your issues. Debain 12 standard LTS ends in 2028 [0] and extended support (if you pay for it) ends in 2033 [1]. Beyond that you're on your own. If you're running servers, you'd be mad to be running any the current stable and old-stable releases by then. [0] https://wiki.debian.org/LTS https://wiki.debian.org/LTS [1] https://wiki.debian.org/LTS/Extended https://wiki.debian.org/LTS/Extended

soupbowl 2y ago
I worked on ancient redhat and debian Linux equipment recently. Just because it shouldn't be used or is "easy" to upgrade means nothing in the real world. That applys now and it will 15 years from now.
- yoyohello13 2y ago
  People willfully/recklessly running systems well beyond eol is not the problem of maintainers.
  - HeatrayEnjoyer 2y ago
    It will be everyone's problem if critical infrastructure stops working. Nobody gives a flying carp who's fault it is when erroneous air traffic control systems start killing people or bank transactions stop processing.
    - ranger_danger 2y ago
      Everyone except for the people who voted to EOL those older OSes people still use.
      - HeatrayEnjoyer 2y ago

lamontcg 2y ago

> We are doomed. Doubt it. Any disruption will probably be two orders of magnitude less than the COVID-19 pandemic. Most systems (like self driving cars or payments) will be 64-bit and unaffected. Anything critical still running 32-bit will be on these kinds of debian distros or NetBSD or whatever. The stuff that breaks will mostly be flashing-VCR-time impacts that can be worked around (timestamps on security cameras may wrap around to 1970 and be impossible to set to the correct date, but the cameras should still continue working). There may be stupid companies that go bankrupt because all their devices fail hard and they get sued out of existence, but that kind of impact happens all the time. Just looking at something like the list of largest trading losses in banks: https://en.wikipedia.org/wiki/List_of_trading_losses https://en.wikipedia.org/wiki/List_of_trading_losses The economy has a very large capacity for dumbassery. Most hard failures will just be Keynesian stimulus for their competitors. Any hard failures that result in losses to the customers (e.g. stores robbed because security cameras down) will get absorbed by insurance -- and really they're already getting robbed so much by smash and grabs with stolen vehicles I doubt it matters.

TacticalCoder 2y ago

From TFA: > This is now less that 15 years away and plenty of system that will have problems have already been shipped. We should stop adding to the problem. Most computing, especially computing using Debian or its derivatives, is now done on 64-bit hardware where this issue does not arise. The goal is to support 64 bit time on 32 bit systems. > We are doomed. We really aren't. Y2K was a big nothingburger despite the media scaremongering. 64 bit systems are already nearly everywhere. As TFA states: most distros don't even bother supporting 32 bit hardware anymore. They simply don't. Are there going to be tiny Internet-of-shitty-insecure-Things devices out there failing in 2038? Very likely. Nuclear powerplants failing, nuclear warheads launched by mistake and lab doors wrongly opened (from labs where they do GoF research on deadly viruses)? Nope. Not gonna happen.

immibis 2y ago
Plenty of single-purpose 32-bit ARM systems are around.
NoahKAndrews 2y ago
Wasn't it a nothingburger because of the massive effort to get everything important updated in time?

IshKebab 2y ago

How many 32 bit time-dependent systems running 15 year old Linux do you think there will be in 2038? It's going to be a handful at most.

immibis 2y ago
I worked on one. Cellphone routers deployed in remote locations, yes including handling 911 calls. They'll probably all crash at the rollover and require a technician to come and upgrade the firmware on site.

ezoe 2y ago

Do you really remember 20 years ago? I do. It was year 2004. Linux kernel 2.6 was still in development and people are using 2.2 or even 2.0. The latest stable Debian was Woody at that time, using Linux kernel 2.2. GNU/Linux was still struggling to support POSIX threads. ext3 was merged to the Linux kernel in 2001 and people were still using ext2. ext2/ext3 has year 2038 problem but in year 2004, nobody think it seriously. Even the ext4 had year 2038 problem and later got a workaround to prolong its life for another few hundred years. UTF-8 standard was just finalized in 2003 and nobody thought it will be the default character encoding. No GNU/Linux Distros at that time uses UTF-8 as the default locale. Most people believed UTF-16 was the future but reluctant to change , except for Microsoft Windows. Microsoft was the early adopter of Unicode and they are paying for their failure of choosing UTF-16 while all other OSes, web browsers and everything later choose UTF-8. People of 2004 realized the year 2038 problem. But there was no way we could use 64 bit signed integer as time_t at that time. Even for the filesystem. Even if we tried to fix it in 2004, it was probably a bad choice that needed to be redone right now. Personally, I think that if people are still using Linux kernel 2.2 or Windows CE in their embedded system in year 2038, they have serious other problems as well.