I made a proper version of https://wetdry.world/@mudkip/113793607230321821 #xenia #y2k38

@octylFractal this meme is just wrong, no? Linux has used 64-bit time on 32-bit architectures since 5.6, which was released half a decade ago (and it used 64-bit time on 64-bit architectures even way before that)

@sodiboo @octylFractal old 32 bit apps use 32 bit time but they are already broken on many systems

@charlotte @octylFractal sure but that’s… not Linux? meme implies the kernel has this issue?

@sodiboo @octylFractal shit half a decade ago was 2020

@piku @octylFractal correct. Linux used 32-bit time representation on 32-bit architectures up until 2020.

@sodiboo @charlotte It was not my intention to indicate the kernel, Tux here is a stand-in for any Linux-based distro.

@piku @sodiboo @octylFractal oh no

@enbykibby @piku @sodiboo @octylFractal
Y2K returns
but this time it’s Y2K38

@octylFractal @atax1a oh thank goodness someone finally fixed the date issue so it was 32 bit signed instead of 31 bit unsigned

@octylFractal @atax1a lmao like every comment on the original is that the rollover is wrong

@sodiboo I don't think it applies much since last year, when Debian finally finished https://wiki.debian.org/ReleaseGoals/64bit-time

But I did have to deal with Java being compiled against 32-bit time APIs on 32-bit systems just this last week, and was resolving an issue with people actively using those systems. So in a general sense, not all Linux systems are actually using it yet, and it still applies in that way.

@octylFractal @sodiboo this isn't a magic fix...it's required to at least rebuild your code against the new libraries, and will probably only work if your code is using only time_t or whatever and not doing dodgy things like explicitly managing it internally as a signed 32-bit int anywhere.