4 ms·

Is this correct? 32-bit will be dead in 2038? This is making me really concerned... Won't it just loop around? I still use a 32-bit laptop as my main writing PC

Is this correct? 32-bit will be dead in 2038? This is making me really concerned... Won't it just loop around? I still use a 32-bit laptop as my main writing PC... Acer Aspire One, from the age of netbooks. Even finding an up-to-date Linux distro was kinda hard... Is there a fix for the time_t?

toyg 6y ago
Read the article. TLDR: this has been fixed in code, at least in Linux. This said, I hope you don’t really plan to be still using that thing in 18 years’ time.
- LoveMortuus 6y ago
  Thank you. For writing it's still amazing and if it still works in 18 that would be amazing, I did just buy a bigger longer battery via eBay! I don't know why but the keyboard feels so amazing... It's like a part of me, I don't even need to think of typing yet the words still appear! I've also put SSD storage into it and upgraded the RAM... It really just makes me very happy
megous 6y ago
Just set your clock to that time and watch what happens.
- core-questions 6y ago
  https://askubuntu.com/a/299489 https://askubuntu.com/a/299489 > No, it will not fail. In the worst case, from the viewpoint of a programmer it will work as expected: it will be reseted to date 1901-12-13 20:45:52:
jmclnx 6y ago
The article has noted the kernel will be fine, but if I read that correctly, glib still uses 32bit time_t. And I thought I saw somewhere ext4 was changed to be fine until sometime around 2160 due to seconds granularity. I wonder how much this is a function of "never break user space." ? The BSDs have no problem with breaking user space, Net/OpenBSD has been using 64bit time_t for a while. And starting with 6.8 OpenBSD's default file system uses 64bit timestamps. With that said, I think Linux's "never break user space" is one of the main reasons Linux is so dominant. And that is making the time_t work harder to complete.
arnd 6y ago
User space doesn't generally deal well with time going backwards, but the main problem is that setting an absolute timeout in a program is broken when the target time is less than the current time. An example of this is 32-bit systemd, which just hangs at boot when the RTC points to a time after 2038, as it tries to figure out of timers work. https://www.adelielinux.org/ https://www.adelielinux.org/ is an example of a Linux distro built on musl-1.2, so you can use that beyond 2038 on 32-bit hardware.

toyg 6y ago

Read the article. TLDR: this has been fixed in code, at least in Linux. This said, I hope you don’t really plan to be still using that thing in 18 years’ time.

LoveMortuus 6y ago
Thank you. For writing it's still amazing and if it still works in 18 that would be amazing, I did just buy a bigger longer battery via eBay! I don't know why but the keyboard feels so amazing... It's like a part of me, I don't even need to think of typing yet the words still appear! I've also put SSD storage into it and upgraded the RAM... It really just makes me very happy

megous 6y ago

Just set your clock to that time and watch what happens.

core-questions 6y ago
https://askubuntu.com/a/299489 https://askubuntu.com/a/299489 > No, it will not fail. In the worst case, from the viewpoint of a programmer it will work as expected: it will be reseted to date 1901-12-13 20:45:52:

jmclnx 6y ago

The article has noted the kernel will be fine, but if I read that correctly, glib still uses 32bit time_t. And I thought I saw somewhere ext4 was changed to be fine until sometime around 2160 due to seconds granularity. I wonder how much this is a function of "never break user space." ? The BSDs have no problem with breaking user space, Net/OpenBSD has been using 64bit time_t for a while. And starting with 6.8 OpenBSD's default file system uses 64bit timestamps. With that said, I think Linux's "never break user space" is one of the main reasons Linux is so dominant. And that is making the time_t work harder to complete.

arnd 6y ago

User space doesn't generally deal well with time going backwards, but the main problem is that setting an absolute timeout in a program is broken when the target time is less than the current time. An example of this is 32-bit systemd, which just hangs at boot when the RTC points to a time after 2038, as it tries to figure out of timers work. https://www.adelielinux.org/ https://www.adelielinux.org/ is an example of a Linux distro built on musl-1.2, so you can use that beyond 2038 on 32-bit hardware.