• Can't Avoid That Shit Rust - Even On Gentoo

    From Farley Flud@21:1/5 to All on Sat Sep 21 12:03:02 2024
    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)
  • From Lawrence D'Oliveiro@21:1/5 to rbowman on Tue Sep 24 21:02:49 2024
    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)
  • From rbowman@21:1/5 to Charlie Gibbs on Tue Sep 24 23:17:00 2024
    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)
  • From John Dallman@21:1/5 to D'Oliveiro on Tue Oct 1 00:56:00 2024
    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)
  • From Lawrence D'Oliveiro@21:1/5 to John Dallman on Mon Sep 30 23:48:35 2024
    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)
  • From John Dallman@21:1/5 to D'Oliveiro on Tue Oct 1 00:25:00 2024
    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)
  • From Lawrence D'Oliveiro@21:1/5 to John Dallman on Tue Oct 1 00:27:23 2024
    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)
  • From 186283@ud0s4.net@21:1/5 to John Dallman on Tue Oct 1 00:16:44 2024
    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)
  • From John Dallman@21:1/5 to D'Oliveiro on Tue Oct 1 10:12:00 2024
    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)
  • From Charlie Gibbs@21:1/5 to 186282@ud0s4.net on Tue Oct 1 16:41:10 2024
    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)
  • From 186283@ud0s4.net@21:1/5 to Charlie Gibbs on Wed Oct 2 00:57:28 2024
    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)
  • From Richard Kettlewell@21:1/5 to 186282@ud0s4.net on Wed Oct 2 08:55:02 2024
    "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)
  • From The Natural Philosopher@21:1/5 to Charlie Gibbs on Wed Oct 2 10:47:25 2024
    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)
  • From Lawrence D'Oliveiro@21:1/5 to Charlie Gibbs on Sat Sep 28 07:38:07 2024
    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)