News for hackers. Stuff that matters.
Re:Glibc is still not Y2038 compliant by default by Beltiras on Wednesday December 29, 2021 @06:13AM (#29723836)
Thankfully upgrades move faster in the OSS world. The worrysome cases are embedded systems. Especially those built intentionally 32 bit.
Re:Glibc is still not Y2038 compliant by default by masklinn on Wednesday December 29, 2021 @07:05AM (#29724073)
...

TFA is about how GNU/Linux systems being deployed right now are not Y2038-safe.

Windows applications have been safe from this issue by default starting from VC8.0 (VS 2005), macOS users since 10.7.

And to be fair Linux itself has used 64b time_t on 64b machines from the start (and since 5.6 — last year — has also migrated i386 to 64b time_t[0], though a few issues will remain forever).

[0] https://lkml.org/lkml/2020/1/29/355?anz=web

Re:Glibc is still not Y2038 compliant by default by btown on Wednesday December 29, 2021 @09:41AM (#29725212)
> upgrades move faster in the OSS world

There are many who don’t think like this. Microsoft has dedicated teams that ensure backwards compatibility for legacy applications, and even then people stay on XP. If you have an inherited Ubuntu system that has been happily running a proprietary binary for years, there’s even less guarantee (and certainly no marketing organization making that guarantee) that an upgrade won’t break things. And so you fall far behind LTS.

Re:Glibc is still not Y2038 compliant by default by zymhan on Wednesday December 29, 2021 @12:29PM (#29727120)
laughs in debian

au contraire, it's quite easy to keep museum-level ancient Linux distros running

Re:Glibc is still not Y2038 compliant by default by azernik on Wednesday December 29, 2021 @02:43PM (#29729109)
Your desktop Linux distro is not the scary case here