Re: Can't Avoid That Shit Rust - Even On Gentoo

On 9/30/24 7:55 PM, John Dallman wrote:

In article <vdfdcj$2dsh2$7@dont-email.me>, ldo@nz.invalid (Lawrence
D'Oliveiro) wrote:
 

On Tue, 1 Oct 2024 00:25 +0100 (BST), John Dallman wrote:

In article <vdf71h$2cn51$17@dont-email.me>, ldo@nz.invalid
(Lawrence D'Oliveiro) wrote:

It's not being ignored. The Linux kernel added the option to
build a 32-bit kernel with time_t having 64 bits

>
The same has happened for Windows and Apple's operating systems.
A lot of the work for 2038 is already done.

>
They're not supporting 32-bit code any more. Linux is.

 Apple only run 64-bit code on recent OSes, yes, but Windows 11 still runs
32-bit applications, even though the OS is only available in 64-bit form.
There's no sign of Windows dropping 32-bit applications, and I check
regularly: I'd like to stop supporting them.

   I think 32-bit is (already) kinda obsolete whether
   anybody wants to admit it or not.
   Didn't take long, did it ?
   LONG back some guy at a computer store (remember
   those ?) asked my why anybody would WANT 16-bit
   chips/vars. This was in the c64/Atari-800 days.
   I told him "graphics !" - and was right.
   NOW I wonder if 128-bit should be the aim of
   all future standards. It'd be HARD to use up
   128 bits for almost anything. Alas vars that
   big use up more memory/cycles.
   A few years back I wrote a HDD viewer/editor app
   in Free Pascal/Laz. The DOCS said seek() was
   64-bit ... however SOME OTHER STUFF in the chain
   apparently was NOT, it'd wrap. Had to write a 'C'
   helper pgm using some kinda exotic 64-bit defs
   (and typecasting) to deal with modern LARGE drives.
   Never tried seek() with an OFFSET - that MIGHT have
   added up to 64 bits - but that's an uglier solution.