XPost: comp.os.linux.advocacy, alt.os.linux

Rust is laughable garbage.

Some jerk at Mozilla cobbles some shit together and it ends
up impressing his co-workers, all network "programmers" who
are the lowest of the low.

In time it ends up impressing a lot of other pseudo-programmers
and then we get the situation of today. Big fucking deal.

I certainly don't want that junk on my well-oiled Gentoo system,
but it's got to be there thanks to one single entity: libsvg.

Yep. I've got to install that entire Rust monstrosity just to
build a single fucking program: librsvg.

What is "librsvg?"

It's another product of the "progressive" GNOME folks:

https://wiki.gnome.org/Projects/LibRsvg

GNOME is the shittiest DE imaginable. It resembles the dream
of some first-grade art student who has smoked a few joints
before class.

Of course these backward, security-obsessed, illiterati could
never use C. They need to earn their credibility by invoking
Rust.

Fuck Rust and fuck all those that support it.


--
Systemd: solving all the problems that you never knew you had.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.os.linux.advocacy

On 24 Sep 2024 17:49:41 GMT, rbowman wrote:

otoh, the C and POSIX books were as valid as ever.

Assuming the C book covered C99 (or later). Otherwise it would be
seriously out of date.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.os.linux.advocacy

On Tue, 24 Sep 2024 18:24:05 GMT, Charlie Gibbs wrote:

Once I got network programming figured out, I wrote my own library of functions that set everything up the way I want it (including SSH and
TLS). Sure, you have to watch your step sometimes, but it's not quite
as bad as people make it out to be.

I saw no reason to reinvent the OpenSSL wheel particularly if you need
FIPS compliance.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

John

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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:

On Mon, 30 Sep 2024 19:40:06 -0000 (UTC), candycanearter07 wrote:

For instance, the 2038 problem I'm betting will be ignored until
2035.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

On Mon, 30 Sep 2024 19:40:06 -0000 (UTC), candycanearter07 wrote:

For instance, the 2038 problem I'm betting will be ignored until
2035.

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.

John

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 1 Oct 2024 00:56 +0100 (BST), 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.

But those 32-bit Windows apps are not being rebuilt for 64-bit time_t. The option isn’t there.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

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

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.

But those 32-bit Windows apps are not being rebuilt for 64-bit
time_t. The option isn't there.

If you rebuild them with modern toolchains, you get the 64-bit time_t.
There's no way to fix ancient binaries, on any OS.

John

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-10-01, 186282@ud0s4.net <186283@ud0s4.net> wrote:

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.

In other words, "128 bits ought to be enough for anybody." :-)

--
/~\ Charlie Gibbs | We'll go down in history as the
\ / <cgibbs@kltpzyxm.invalid> | first society that wouldn't save
X I'm really at ac.dekanfrus | itself because it wasn't cost-
/ \ if you read it the right way. | effective. -- Kurt Vonnegut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/1/24 12:41 PM, Charlie Gibbs wrote:

On 2024-10-01, 186282@ud0s4.net <186283@ud0s4.net> wrote:

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.

In other words, "128 bits ought to be enough for anybody." :-)

It's a really BIG number ...

But there SHOULD be a few 256/512-bit types in ye
olde library :-)

Now CPUs ... maybe 128-bit IS what future-lookers
need to immediately switch to. Haven't heard many
complaints about 64-bit chips, yet, but doesn't
hurt to plan ahead. Circuitry can be made SO small
now that the extra stuff for 128 all through may
not be such a burden.

OR ... are 'CPUs' even bulk of The Future ?
Somehow I see "AI" - implemented on large
distributed systems of diverse composition,
likely even some 'quantum' thrown in - being
the coming thing. They can emulate old CPUs.
Individual users, well, 99.5% of what they run
actually runs 'cloud' over 6-G and they just
need enough chip to do the pretty graphics.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"186282@ud0s4.net" <186283@ud0s4.net> writes:

It's a really BIG number ...

But there SHOULD be a few 256/512-bit types in ye
olde library :-)

Now CPUs ... maybe 128-bit IS what future-lookers
need to immediately switch to. Haven't heard many
complaints about 64-bit chips, yet, but doesn't
hurt to plan ahead. Circuitry can be made SO small
now that the extra stuff for 128 all through may
not be such a burden.

On x86:

* In one sense it is already up to 512 bits (if you have AVX512
extensions), although that’s slightly misleading, since 512-bit
registers are generally interpreted as vectors of smaller components
(mostly, up to 64 bits)

* There are a handful up instructions that deal in 128-bit quantities
(e.g. AES-NI extension, multipliers and dividers).

There’s relatively little need to deal with 128-bit quantities as such; 64-bits really is enough for most jobs. For most current CPUs virtual
memory addressing is still only 48-bit.

There are certainly niches that need larger quantities; classical
asymmetric cryptography can use integers hundreds or thousands of bits
long. While cryptography implementors might find 4096-bit integer
registers convenient it’d be an incredibly expensive waste for almost
everyon else.

OR ... are 'CPUs' even bulk of The Future ? Somehow I see "AI" -
implemented on large distributed systems of diverse composition,
likely even some 'quantum' thrown in - being the coming thing. They
can emulate old CPUs.

AIs can’t even do basic arithmetic, CPU emulation is certainly not a realistic proposition.

--
https://www.greenend.org.uk/rjk/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 01/10/2024 17:41, Charlie Gibbs wrote:

On 2024-10-01, 186282@ud0s4.net <186283@ud0s4.net> wrote:

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.

In other words, "128 bits ought to be enough for anybody." :-)

It is a curious and interesting speculation, because as processing power
ad address space have gone up, so many things that were simply
impossible, have become commonplace.

Like real time simulation.

And massively parallel computer models, that are fantastically accurate creators of arbitrary results when based on suspect data and
assumptions...:-)

--
“The ultimate result of shielding men from the effects of folly is to
fill the world with fools.”

Herbert Spencer

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.os.linux.advocacy

On Wed, 25 Sep 2024 00:52:17 GMT, Charlie Gibbs wrote:

My libraries call OpenSSL, but let me establish a connection (with or
without TLS) with a single call.

I suppose you can do anything with a single call, if you pack enough
arguments into it ...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)