GNU Coreutils 9.4 Adds Experimental "--enable-systemd" Option, Faster Split

[phoronix]

Phoronix: GNU Coreutils 9.4 Adds Experimental "--enable-systemd" Option, Faster Split

GNU Coreutils 9.4 is out today as the latest version of this collection of utilities common to GNU/Linux systems and other platforms...

https://www.phoronix.com/news/GNU-Coreutils-9.4

[arekm]

Do coreutils binaries have to provided in two variants, systemd and non-systemd (for systems where systemd can be used by is optional; like PLD/Linux) or did they make this in sane and compatible way, so one "binary fits all"?

[Ironmask]

I'm still in utter shock Linux is still fixing 2038 bugs when this was fixed in Windows in 1993. 30 years ago.

[fitzie]

I'm still in utter shock Linux is still fixing 2038 bugs when this was fixed in Windows in 1993. 30 years ago.

there are some 32bit distros could easily switch time_t to 64bit number, but are unwilling to break ABI. those distros should not be used. the only thing that would break (and couldn't use a LD_PRELOAD compatability shim) are statically compiled binaries that you don't have the source code too in order to rebuild.

[cynic]

I'm still in utter shock Linux is still fixing 2038 bugs when this was fixed in Windows in 1993. 30 years ago.

I'd just like to interject for a moment. What you’re referring to as Linux, is in fact, GNU.

[PluMGMK]

Was this ever even an issue in Windows? I thought DOS/Windows had their own threshold dates completely separate from this 2038 one…

[cynic]

Was this ever even an issue in Windows? I thought DOS/Windows had their own threshold dates completely separate from this 2038 one…

it all depends on how you represent the date in every os, library or program in general.

In UNIX and most derivatives OSes, times and dates were storically represented as the number of seconds since "the epoch" (01-01-1970 00:00) using a 32 bit integer, so the 2038 bug.

AFAIK windows use a different data structure (also did DOS)

[ersatz]

Was this ever even an issue in Windows? I thought DOS/Windows had their own threshold dates completely separate from this 2038 one…

No it never was Windows isn't UNIX and the comparison is pointless. The Windows epoch ends in the year 30828.

[Vorpal]

No it never was Windows isn't UNIX and the comparison is pointless. The Windows epoch ends in the year 30828.

Now I'm curious as to the the epoch and range of the system RTC (i.e. what keeps time when the system is turned off). Presumably those too will overflow at some point.

At least on PC I expect the protocol between the OS/BIOS/UEFI and the hardware clock to be somewhat standard. Other platforms will likely differ.

[F.Ultra]

I'm still in utter shock Linux is still fixing 2038 bugs when this was fixed in Windows in 1993. 30 years ago.

Linux is trying to make old 32-bit programs work past 2038 without forcing a recompile. Windows fixed it by requiring a recompile where time_t is an alias for __time64_t if you compile with a recent SDK. Old 32-bit Windows programs that have not been recompiled since that change will experience all the problems.

The way Windows forces this on 32-bit applications was done in Linux back in 5.1and glibc 2.32