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

[Ironmask]

when Linus started writing Linux he had no idea where his OS would have been in 30 years.
It wasn't designed to last, and surely not to last this long.
He used a design that was working at the time and was enough for his needs.

Yeah that's fine.
You would have thought critical decisions like this would have been made or repaired after the first dozen or so confirmed users.
But here we are in 2023 still fixing this.
Please don't keep doing this "oopsie doodles Linux was made by a college geek in 1990 so that means we can still keep using 32-bit integers for datetimes in 2023 when all of our entire society's infrastructure might collapse in a decade because of it, huehue"
This was fixed 30 years ago. There is no excuse for this, there never was. Just like there never was an excuse for Y2K bugs.

[caligula]

And again, for the third time:
Windows NT had a 64-bit timestamp in 1993.
This was not revolutionary, it was actually fairly standard.
If only Linux wasn't trying to poorly mimic a hacked-together OS architecture that was designed on a PDP-11 that even it's own creator disowned.

I was using a totally up to date Windows gaming system in 2001 where the accuracy of file timestamps was 2 seconds.

[mos87]

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

punky

I like that.

[cynic]

Yeah that's fine.
You would have thought critical decisions like this would have been made or repaired after the first dozen or so confirmed users.
But here we are in 2023 still fixing this.
Please don't keep doing this "oopsie doodles Linux was made by a college geek in 1990 so that means we can still keep using 32-bit integers for datetimes in 2023 when all of our entire society's infrastructure might collapse in a decade because of it, huehue"
This was fixed 30 years ago. There is no excuse for this, there never was. Just like there never was an excuse for Y2K bugs.

you have no idea how hard this is and how much effort is required.

If you think it is important and easy, fix it by yourself, or pay someone to do it.

on the contrary, if you are using a better OS that fixed this issue 30 years ago, good for you, but stop complaining like a 13 years girl that want the latest barbie.

[Sonadow]

you have no idea how hard this is and how much effort is required.

If you think it is important and easy, fix it by yourself, or pay someone to do it.

on the contrary, if you are using a better OS that fixed this issue 30 years ago, good for you, but stop complaining like a 13 years girl that want the latest barbie.

It's only as hard as they want it to be. And Linux just loves being artificially hard with all the BS over glibc compatibility and x64 microarch levels, and these are just two examples.

What happened to "fuck backwards compatibility, only Microsoft, Apple and Google care about this shit, we always go straight for the new stuff"? Huh? Suddenly we conveniently talk about the importance of maintaining backwards compatibility and how desirable it is, because there is a need to defend a broken design when things go apeshit? But outside of that it's all "fuck backwards compatibility"?

Linux screws itself over with shitty decisions and its users blame others for refusing to give them the same kind of attention and support.

[cynic]

It's only as hard as they want it to be.

sure man!

close your eyes, wish the code is fixed and bam! it's fixed!

tell me where I can follow you for more coding recipes!

[Weasel]

What happened to "fuck backwards compatibility, only Microsoft, Apple and Google care about this shit, we always go straight for the new stuff"? Huh? Suddenly we conveniently talk about the importance of maintaining backwards compatibility and how desirable it is, because there is a need to defend a broken design when things go apeshit? But outside of that it's all "fuck backwards compatibility"?

Nothing happened, you're just fucking clueless, it was never a thing in Linux (kernel)'s userland-facing API. Backwards compatibility was always paramount there. It's only the in-kernel APIs that aren't.

glibc is in similar boat. It's the rest of the userland that doesn't give a shit.

At least educate yourself before clowning.

[Sonadow]

Nothing happened, you're just fucking clueless, it was never a thing in Linux (kernel)'s userland-facing API. Backwards compatibility was always paramount there. It's only the in-kernel APIs that aren't.

glibc is in similar boat. It's the rest of the userland that doesn't give a shit.

At least educate yourself before clowning.

Come back to me when "/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_X.XX' not found" errors no longer exist.

[arekm]

Come back to me when "/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_X.XX' not found" errors no longer exist.

These errors exist because you seem to want forward compatibility (like binary built with newer glibc used on older glibc). Only backward compatibility is provided (binary build on older glibc works on newer glibc).

[Weasel]

Come back to me when "/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_X.XX' not found" errors no longer exist.

I guess Windows isn't backwards compatible either since if you use a symbol/API not available to Windows 95, it will fail to launch on Windows 95…