• Downfall fallout: Intel knew AVX chips were insecure and did nothing, l

    From Fred Bloggs@21:1/5 to All on Mon Nov 13 09:08:34 2023
    'Intel has been sued by a handful of PC buyers who claim the x86 goliath failed to act when informed five years ago about faulty chip instructions that allowed the recent Downfall vulnerability, and during that period sold billions of insecure chips.'

    https://www.theregister.com/2023/11/09/intel_downfall_lawsuit/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to bloggs.fredbloggs.fred@gmail.com on Mon Nov 13 09:32:51 2023
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs <bloggs.fredbloggs.fred@gmail.com> wrote:


    'Intel has been sued by a handful of PC buyers who claim the x86 goliath failed to act when informed five years ago about faulty chip instructions that allowed the recent Downfall vulnerability, and during that period sold billions of insecure chips.'

    https://www.theregister.com/2023/11/09/intel_downfall_lawsuit/

    Some day we will be free of x86 and freed from bloated insecure
    operating systems.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to John Larkin on Mon Nov 13 18:00:03 2023
    On 13/11/2023 17:32, John Larkin wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs <bloggs.fredbloggs.fred@gmail.com> wrote:


    'Intel has been sued by a handful of PC buyers who claim the x86 goliath failed to act when informed five years ago about faulty chip instructions that allowed the recent Downfall vulnerability, and during that period sold billions of insecure chips.'

    https://www.theregister.com/2023/11/09/intel_downfall_lawsuit/

    Some day we will be free of x86 and freed from bloated insecure
    operating systems.

    However, the problem here is with speculative execution and hardware
    designed for optimum speed. Most systems had something similar by way of vulnerability. You may not like the Intel architecture (and neither do
    I) but it is still dominant today. ARM is bigger by volume now but not
    by value.

    Captain Zilog and Motorola have both fallen by the wayside...

    If anything I suspect that OS's and particularly on the AI side of
    things is going to get ever more human like including fallibility.

    --
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to John Larkin on Mon Nov 13 18:09:57 2023
    John Larkin <jl@997PotHill.com> wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs <bloggs.fredbloggs.fred@gmail.com> wrote:


    'Intel has been sued by a handful of PC buyers who claim the x86 goliath
    failed to act when informed five years ago about faulty chip
    instructions that allowed the recent Downfall vulnerability, and during
    that period sold billions of insecure chips.'

    https://www.theregister.com/2023/11/09/intel_downfall_lawsuit/

    Some day we will be free of x86 and freed from bloated insecure
    operating systems.



    Well, we can go back to banging rocks together anytime we like. ;)

    Cheers

    Phil Hobbs

    --
    Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred Bloggs@21:1/5 to John Larkin on Mon Nov 13 10:19:54 2023
    On Monday, November 13, 2023 at 12:33:33 PM UTC-5, John Larkin wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs <bloggs.fred...@gmail.com> wrote:


    'Intel has been sued by a handful of PC buyers who claim the x86 goliath failed to act when informed five years ago about faulty chip instructions that allowed the recent Downfall vulnerability, and during that period sold billions of insecure chips.'

    https://www.theregister.com/2023/11/09/intel_downfall_lawsuit/
    Some day we will be free of x86 and freed from bloated insecure
    operating systems.


    Sounds like some kind of sophisticated predictive caching scheme to minimize main memory latency. But just how dumb are the idiots at Intel if they cache security data that has nothing to do with the application. Since the microcontrol knows nothing
    about the application, they should have given the microcontrol a means of keeping segments of memory off limits to the caching, via the OS I'm guessing.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dimiter_Popoff@21:1/5 to John Larkin on Mon Nov 13 20:47:13 2023
    On 11/13/2023 19:32, John Larkin wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs <bloggs.fredbloggs.fred@gmail.com> wrote:


    'Intel has been sued by a handful of PC buyers who claim the x86 goliath failed to act when informed five years ago about faulty chip instructions that allowed the recent Downfall vulnerability, and during that period sold billions of insecure chips.'

    https://www.theregister.com/2023/11/09/intel_downfall_lawsuit/

    Some day we will be free of x86 and freed from bloated insecure
    operating systems.


    At least we can stay optimistic :-). Then what, ARM or Risc-V...
    That at a time when power is still around, and IBM made it freely
    license a couple of years ago.
    The rest cannot even sort out their endianness nonsense.
    I am not sure if anyone actually realizes how *wast* the bloat is.

    ======================================================
    Dimiter Popoff, TGI http://www.tgi-sci.com ====================================================== http://www.flickr.com/photos/didi_tgi/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to All on Mon Nov 13 12:46:40 2023
    On 11/13/2023 11:47 AM, Dimiter_Popoff wrote:
    At least we can stay optimistic :-). Then what, ARM or Risc-V...
    That at a time when power is still around, and IBM made it freely
    license a couple of years ago.
    The rest cannot even sort out their endianness nonsense.
    I am not sure if anyone actually realizes how *wast* the bloat is.

    Operating Systems, nowadays, do "too much" AND still cling to the
    monolithic notion created in the 60's (which makes them buggier and
    more insecure).

    [Look at the many-billion-dollar Linux kernel and wonder why it
    STILL has bugs!]

    Sadly, one can't opt for pared-down versions of OS's -- it's pretty
    much take-it-all-or-nothing.

    OTOH, most developers wouldn't know where to start paring...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to Fred Bloggs on Mon Nov 13 23:59:37 2023
    XPost: free.spam

    The idiot Fred Bloggs <bloggs.fredbloggs.fred@gmail.com> persisting in being an Off-topic troll...

    --
    Fred Bloggs <bloggs.fredbloggs.fred@gmail.com> wrote:

    X-Received: by 2002:a0c:f9c8:0:b0:66d:12b3:b2a5 with SMTP id j8-20020a0cf9c8000000b0066d12b3b2a5mr185860qvo.11.1699899595645;
    Mon, 13 Nov 2023 10:19:55 -0800 (PST)
    X-Received: by 2002:a25:73c6:0:b0:da1:513d:8a3c with SMTP id
    o189-20020a2573c6000000b00da1513d8a3cmr169013ybc.11.1699899595150; Mon, 13
    Nov 2023 10:19:55 -0800 (PST)
    Path: not-for-mail
    Newsgroups: sci.electronics.design
    Date: Mon, 13 Nov 2023 10:19:54 -0800 (PST)
    In-Reply-To: <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com>
    Injection-Info: google-groups.googlegroups.com; posting-host=2601:5cc:4701:5250:d507:bd4:a0b5:c2af;
    posting-account=iGtwSwoAAABNNwPORfvAs6OM4AR9GRHt
    NNTP-Posting-Host: 2601:5cc:4701:5250:d507:bd4:a0b5:c2af
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com> <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com>
    User-Agent: G2/1.0
    MIME-Version: 1.0
    Message-ID: <72b435b7-2538-4bff-8b69-eb0c1c5116fen@googlegroups.com>
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did
    nothing, lawsuit claims
    From: Fred Bloggs <bloggs.fredbloggs.fred@gmail.com>
    Injection-Date: Mon, 13 Nov 2023 18:19:55 +0000
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable
    X-Received-Bytes: 2465

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Panteltje@21:1/5 to jl@997PotHill.com on Tue Nov 14 05:59:23 2023
    On a sunny day (Mon, 13 Nov 2023 09:32:51 -0800) it happened John Larkin <jl@997PotHill.com> wrote in <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com>:

    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs ><bloggs.fredbloggs.fred@gmail.com> wrote:


    'Intel has been sued by a handful of PC buyers who claim the x86 goliath failed to act when informed five years ago about
    faulty chip instructions that allowed the recent Downfall vulnerability, and during that period sold billions of insecure chips.'

    https://www.theregister.com/2023/11/09/intel_downfall_lawsuit/

    Some day we will be free of x86 and freed from bloated insecure
    operating systems.

    Too many lawers
    If those used their time on earth to design something better it would help.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Panteltje@21:1/5 to dp@tgi-sci.com on Tue Nov 14 06:12:05 2023
    On a sunny day (Mon, 13 Nov 2023 20:47:13 +0200) it happened Dimiter_Popoff <dp@tgi-sci.com> wrote in <uitqvi$rjpc$1@dont-email.me>:

    On 11/13/2023 19:32, John Larkin wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fredbloggs.fred@gmail.com> wrote:


    'Intel has been sued by a handful of PC buyers who claim the x86 goliath failed to act when informed five years ago about
    faulty chip instructions that allowed the recent Downfall vulnerability, and during that period sold billions of insecure chips.'

    https://www.theregister.com/2023/11/09/intel_downfall_lawsuit/

    Some day we will be free of x86 and freed from bloated insecure
    operating systems.


    At least we can stay optimistic :-). Then what, ARM or Risc-V...
    That at a time when power is still around, and IBM made it freely
    license a couple of years ago.
    The rest cannot even sort out their endianness nonsense.
    I am not sure if anyone actually realizes how *wast* the bloat is.

    I program Microchip PICs is asm.
    Much can be done with a few lines of code.

    When I look at Linux these days and do a
    ps avx
    I see 228 processes running...
    All I am doing on the Rspberry Pi 4 8GB (ARM!!) is writing this text file and have Firefox running, but doing nothing now.
    Talk about bloat.
    And no idea what some of those processes do...
    here some
    My Usenet newsreader....
    23196 pts/2 SNl 28:03 6 368 23007 6184 0.0 NewsFleX
    that is one,
    but then:
    26133 pts/6 Sl+ 334:46 5882 603 1514124 462312 5.7 firefox-esr
    26234 pts/6 Sl+ 1:33 96 603 475068 112272 1.3 /usr/lib/firefox-esr/firefox-esr -contentproc -childID 1 -isForBrowser -prefsLen 1 -prefMapSize 238412 -jsInit 285636 -parentBuildID 20220811191823 -appdir /usr/lib/firefox-esr/browser 26133 true
    tab
    26296 pts/6 Sl+ 22:42 39 603 615780 136988 1.6 /usr/lib/firefox-esr/firefox-esr -contentproc -childID 2 -isForBrowser -prefsLen 4967 -prefMapSize 238412 -jsInit 285636 -parentBuildID 20220811191823 -appdir /usr/lib/firefox-esr/browser 26133
    true tab
    26342 ? I 0:00 0 0 0 0 0.0 [kworker/3:0-events] 26372 pts/6 Sl+ 225:02 87 603 811480 157948 1.9 /usr/lib/firefox-esr/firefox-esr -contentproc -childID 3 -isForBrowser -prefsLen 5627 -prefMapSize 238412 -jsInit 285636 -parentBuildID 20220811191823 -appdir /usr/lib/firefox-esr/browser 26133
    true tab
    26734 pts/6 Sl+ 0:00 0 603 167328 25136 0.3 /usr/lib/firefox-esr/firefox-esr -contentproc -parentBuildID 20220811191823 -prefsLen 5811 -prefMapSize 238412 -appdir /usr/lib/firefox-esr/browser 26133 true rdd
    27112 ? I 0:00 0 0 0 0 0.0 [kworker/2:2-mm_percpu_wq]
    27276 ? I< 0:07 0 0 0 0 0.0 [kworker/1:1H-kblockd] 27371 ? I< 0:00 0 0 0 0 0.0 [kworker/0:1H]
    27607 ? I 0:00 0 0 0 0 0.0 [kworker/3:1-events] 27628 ? I 0:00 0 0 0 0 0.0 [kworker/1:1-events_power_efficient]
    27649 ? I 0:00 0 0 0 0 0.0 [kworker/u8:0-events_unbound]
    27764 ? I< 0:00 0 0 0 0 0.0 [kworker/1:2H]
    27770 ? I< 0:00 0 0 0 0 0.0 [kworker/3:1H]
    27791 ? I 0:00 0 0 0 0 0.0 [kworker/1:3-mm_percpu_wq]
    28129 pts/6 Sl+ 0:00 98 603 416648 70608 0.8 /usr/lib/firefox-esr/firefox-esr -contentproc -childID 137 -isForBrowser -prefsLen 8918 -prefMapSize 238412 -jsInit 285636 -parentBuildID 20220811191823 -appdir /usr/lib/firefox-esr/browser 26133
    true tab
    28328
    ...

    Security? By now EVERYBODY in the universe must know everything...
    Hacking it would take a few minutes only.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Tue Nov 14 07:36:55 2023
    On Mon, 13 Nov 2023 18:09:57 -0000 (UTC), Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    John Larkin <jl@997PotHill.com> wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fredbloggs.fred@gmail.com> wrote:


    'Intel has been sued by a handful of PC buyers who claim the x86 goliath >>> failed to act when informed five years ago about faulty chip
    instructions that allowed the recent Downfall vulnerability, and during
    that period sold billions of insecure chips.'

    https://www.theregister.com/2023/11/09/intel_downfall_lawsuit/

    Some day we will be free of x86 and freed from bloated insecure
    operating systems.



    Well, we can go back to banging rocks together anytime we like. ;)

    Cheers

    Phil Hobbs

    Or put 1024 risc processors on a chip and manage them rationally.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to All on Tue Nov 14 07:38:32 2023
    On Mon, 13 Nov 2023 20:47:13 +0200, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 11/13/2023 19:32, John Larkin wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fredbloggs.fred@gmail.com> wrote:


    'Intel has been sued by a handful of PC buyers who claim the x86 goliath failed to act when informed five years ago about faulty chip instructions that allowed the recent Downfall vulnerability, and during that period sold billions of insecure chips.'

    https://www.theregister.com/2023/11/09/intel_downfall_lawsuit/

    Some day we will be free of x86 and freed from bloated insecure
    operating systems.


    At least we can stay optimistic :-). Then what, ARM or Risc-V...
    That at a time when power is still around, and IBM made it freely
    license a couple of years ago.
    The rest cannot even sort out their endianness nonsense.
    I am not sure if anyone actually realizes how *wast* the bloat is.


    Windows 11 is obvious proof.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dimiter_Popoff@21:1/5 to John Larkin on Tue Nov 14 18:09:23 2023
    On 11/14/2023 17:38, John Larkin wrote:
    On Mon, 13 Nov 2023 20:47:13 +0200, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 11/13/2023 19:32, John Larkin wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fredbloggs.fred@gmail.com> wrote:


    'Intel has been sued by a handful of PC buyers who claim the x86 goliath failed to act when informed five years ago about faulty chip instructions that allowed the recent Downfall vulnerability, and during that period sold billions of insecure chips.
    '

    https://www.theregister.com/2023/11/09/intel_downfall_lawsuit/

    Some day we will be free of x86 and freed from bloated insecure
    operating systems.


    At least we can stay optimistic :-). Then what, ARM or Risc-V...
    That at a time when power is still around, and IBM made it freely
    license a couple of years ago.
    The rest cannot even sort out their endianness nonsense.
    I am not sure if anyone actually realizes how *wast* the bloat is.


    Windows 11 is obvious proof.


    I was offered it a few times on my windows 10 laptop (named tvset3...)
    and so far I was allowed to decline. A neighbour came a few days ago
    for help (I sometimes serve as IT to helpless neighbours) who had
    clicked accept... His problem was they wanted to force him into
    having a PIN number, the screen after that looked weird but
    usable. I don't know how much of it can be brought back to "normal"
    as one sees what normal is but judging by your outcry it must be
    really bad. Eventually they will force us all into it I guess,
    I can swallow that as I use it for reading pdf-s and browsing,
    plus the occasional ltspice.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to John Larkin on Tue Nov 14 16:03:38 2023
    XPost: free.spam

    The idiot John Larkin <jl@997PotHill.com> persisting in being an Off-topic troll...

    --
    John Larkin <jl@997PotHill.com> wrote:

    Path: not-for-mail
    NNTP-Posting-Date: Tue, 14 Nov 2023 15:37:21 +0000
    From: John Larkin <jl@997PotHill.com>
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did nothing, lawsuit claims
    Date: Tue, 14 Nov 2023 07:36:55 -0800
    Organization: Highland Tech
    Reply-To: xx@yy.com
    Message-ID: <cu47li9f5gri305iafvffnmao9aurkvi2m@4ax.com>
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com> <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitopl$r9m7$1@dont-email.me>
    X-Newsreader: Forte Agent 3.1/32.783
    MIME-Version: 1.0
    Content-Type: text/plain; charset=us-ascii
    Content-Transfer-Encoding: 7bit
    Lines: 28
    X-Trace: sv3-NeviuCKhW7gq+KcnKLZgBmqFp0y8+dBVyDRSKhCHzfVgaPLJfQU9UNktIJBeibfmoPXbdd3jXL1lO4F!s0cF7QPNsK706NBEkhV6ThAUVV6I10A1SJkzx47H1cpEMsCaiEt3/lhwWK2jw4uefzxxIJYGepnS!qg8uWg==
    X-Complaints-To: www.supernews.com/docs/abuse.html
    X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
    X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
    X-Postfilter: 1.3.40
    X-Received-Bytes: 2290

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to Jan Panteltje on Tue Nov 14 16:03:44 2023
    XPost: free.spam

    The arsehole Jan Panteltje <alien@comet.invalid> persisting in being an Off-topic troll...

    --
    Jan Panteltje <alien@comet.invalid> wrote:

    Path: not-for-mail
    From: Jan Panteltje <alien@comet.invalid>
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did
    nothing, lawsuit claims
    Date: Tue, 14 Nov 2023 06:12:05 GMT
    Message-ID: <uiv33l$1g1ta$1@solani.org>
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com> <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitqvi$rjpc$1@dont-email.me>
    MIME-Version: 1.0
    Content-Type: text/plain; ISO-8859-15
    Content-Transfer-Encoding: 8bit
    Injection-Date: Tue, 14 Nov 2023 06:12:06 -0000 (UTC)
    Injection-Info: solani.org;
    logging-data="1574826"; mail-complaints-to="abuse@news.solani.org" User-Agent: NewsFleX-1.5.7.5 (Linux-5.15.32-v7l+)
    Cancel-Lock: sha1:UqKvZl7ug0vl0VHn8HviXVlES4Y=
    X-Newsreader-location: NewsFleX-1.5.7.5 (c) 'LIGHTSPEED' off line news reader for the Linux platform
    NewsFleX homepage: http://www.panteltje.nl/panteltje/newsflex/ and ftp download ftp://sunsite.unc.edu/pub/linux/system/news/readers/
    X-User-ID: eJwFwYEBwCAIA7CXFFrAc1aR/09YQo8dNxEMcDg9dh/cbhdC5XaW0tZuLfaRKgsiIXuPsbdne3VCMDjm+wFM6BT9
    X-Received-Bytes: 5041

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to dp@tgi-sci.com on Wed Nov 15 03:06:02 2023
    XPost: free.spam

    The idiot Dimiter_Popoff <dp@tgi-sci.com> persisting in being an Off-topic troll...

    --
    Dimiter_Popoff <dp@tgi-sci.com> wrote:

    Path: not-for-mail
    From: Dimiter_Popoff <dp@tgi-sci.com>
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did
    nothing, lawsuit claims
    Date: Tue, 14 Nov 2023 18:09:23 +0200
    Organization: TGI
    Lines: 37
    Message-ID: <uj063l$19nj8$1@dont-email.me>
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com>
    <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitqvi$rjpc$1@dont-email.me>
    <r257lipb348csh8otghajpb8v2ds1707lj@4ax.com>
    Reply-To: dp@tgi-sci.com
    MIME-Version: 1.0
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit
    Injection-Date: Tue, 14 Nov 2023 16:09:25 -0000 (UTC)
    Injection-Info: dont-email.me; posting-host="9fafad3c3d2fc760e1d40da89e4c8a02";
    logging-data="1367656"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18yjcJzPbv60hPFVTrfvkaG"
    User-Agent: Mozilla Thunderbird
    Cancel-Lock: sha1:0eUdMlVQ/x2jmVL7SmXOfqPdVhM=
    In-Reply-To: <r257lipb348csh8otghajpb8v2ds1707lj@4ax.com>
    Content-Language: en-US
    X-Received-Bytes: 2906

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to John Larkin on Wed Nov 15 11:57:48 2023
    On 14/11/2023 15:36, John Larkin wrote:
    On Mon, 13 Nov 2023 18:09:57 -0000 (UTC), Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    John Larkin <jl@997PotHill.com> wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fredbloggs.fred@gmail.com> wrote:


    'Intel has been sued by a handful of PC buyers who claim the x86 goliath >>>> failed to act when informed five years ago about faulty chip
    instructions that allowed the recent Downfall vulnerability, and during >>>> that period sold billions of insecure chips.'

    https://www.theregister.com/2023/11/09/intel_downfall_lawsuit/

    Some day we will be free of x86 and freed from bloated insecure
    operating systems.

    It isn't the x86's fault that consumer OS's are insecure it is the far
    too much code running at high privilege levels required for gaming.

    IBM's OS/2 was a pretty secure OS on the x86 for its day. Had it been
    for 386 and above only then history might have been different. Making it
    work on the legacy 286 was an incredibly stupid idea that let Win3 gain
    the upper hand. Conflated with it was the launch of the PS/2 hardware
    with its MCA bus made all the rival PC makers club together against IBM.

    Talk about shooting yourself in the foot with both barrels, reloading
    and doing it again...

    Well, we can go back to banging rocks together anytime we like. ;)


    Or put 1024 risc processors on a chip and manage them rationally.

    The devil is *always* in the details. Only someone who has never worked
    on highly parallel systems would suggest such a naive approach.

    Once you go beyond 4 CPUs coordinating who has access to what and when
    becomes ever more complicated. The most important task is invariably the
    one that farms out work to the others so that they are all doing useful
    work. It is quite easy to end up using more power to do less if you push
    number of CPU cores too high. Particularly in problems where smart
    pruning of the tree can eliminated large chunks of brute force work.

    Graphics cards and CUDA already provide massively parallel CPUs for
    tasks which are amenable to such treatment. AI and some scientific
    computing can be done this way very efficiently.

    --
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Wed Nov 15 04:43:19 2023
    onsdag den 15. november 2023 kl. 13.22.54 UTC+1 skrev Martin Brown:
    On 14/11/2023 15:38, John Larkin wrote:
    On Mon, 13 Nov 2023 20:47:13 +0200, Dimiter_Popoff <d...@tgi-sci.com> wrote:

    On 11/13/2023 19:32, John Larkin wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fred...@gmail.com> wrote:


    'Intel has been sued by a handful of PC buyers who claim the x86 goliath failed to act when informed five years ago about faulty chip instructions that allowed the recent Downfall vulnerability, and during that period sold billions of insecure
    chips.'

    https://www.theregister.com/2023/11/09/intel_downfall_lawsuit/
    Too many US lawyers and no common sense.
    Some day we will be free of x86 and freed from bloated insecure
    operating systems.


    At least we can stay optimistic :-). Then what, ARM or Risc-V...
    That at a time when power is still around, and IBM made it freely
    license a couple of years ago.
    The rest cannot even sort out their endianness nonsense.
    I am not sure if anyone actually realizes how *wast* the bloat is.

    Windows 11 is obvious proof.
    Win11 isn't all that bad (Win8 was a dog's dinner). If you don't like it then install Ubuntu or one of the other free Unix clones instead.

    Then you really will have a secure OS on an x86 chip (provided that you configure it correctly). The learning curve on Unix is a bit steep
    though but it is useable out of the box. I'm running my copy as a guest
    OS under Win11 Pro via VMWare because the MS virtualisation sucks.

    what's wrong with WSL/WLS2 ?

    win11 even comes with an X server out of the box so everything just works

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to John Larkin on Wed Nov 15 12:22:39 2023
    On 14/11/2023 15:38, John Larkin wrote:
    On Mon, 13 Nov 2023 20:47:13 +0200, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 11/13/2023 19:32, John Larkin wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fredbloggs.fred@gmail.com> wrote:


    'Intel has been sued by a handful of PC buyers who claim the x86 goliath failed to act when informed five years ago about faulty chip instructions that allowed the recent Downfall vulnerability, and during that period sold billions of insecure chips.
    '

    https://www.theregister.com/2023/11/09/intel_downfall_lawsuit/

    Too many US lawyers and no common sense.

    Some day we will be free of x86 and freed from bloated insecure
    operating systems.


    At least we can stay optimistic :-). Then what, ARM or Risc-V...
    That at a time when power is still around, and IBM made it freely
    license a couple of years ago.
    The rest cannot even sort out their endianness nonsense.
    I am not sure if anyone actually realizes how *wast* the bloat is.

    Windows 11 is obvious proof.

    Win11 isn't all that bad (Win8 was a dog's dinner). If you don't like it
    then install Ubuntu or one of the other free Unix clones instead.

    Then you really will have a secure OS on an x86 chip (provided that you configure it correctly). The learning curve on Unix is a bit steep
    though but it is useable out of the box. I'm running my copy as a guest
    OS under Win11 Pro via VMWare because the MS virtualisation sucks.

    I have finally had to install Ubuntu myself to gain access to exotic
    software that is only available on Unix (and porting it to Windows would
    be incredibly tedious and error prone which is why no-one ever has).

    I'm quite impressed with it so far and Maxima is much more stable on the
    Unix platform which is an unexpected bonus for me (likewise I suspect
    for Latex too). I may yet make the change to becoming a Unix advocate.

    In future there are some things that I will now do under Unix because it
    works better there than on Windows rather than because there is no
    equivalent on Windows (which is what motivated me to jump ship).

    --
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to Lasse Langwadt Christensen on Wed Nov 15 14:02:11 2023
    XPost: free.spam

    The arsehole Lasse Langwadt Christensen <langwadt@fonz.dk> persisting in being an Off-topic troll...

    --
    Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    X-Received: by 2002:a05:620a:294d:b0:773:eed7:76ad with SMTP id n13-20020a05620a294d00b00773eed776admr134585qkp.11.1700052200394;
    Wed, 15 Nov 2023 04:43:20 -0800 (PST)
    X-Received: by 2002:a17:903:4282:b0:1cc:2bff:fe61 with SMTP id
    ju2-20020a170903428200b001cc2bfffe61mr1414346plb.3.1700052200044; Wed, 15 Nov
    2023 04:43:20 -0800 (PST)
    Path: not-for-mail
    Newsgroups: sci.electronics.design
    Date: Wed, 15 Nov 2023 04:43:19 -0800 (PST)
    In-Reply-To: <uj2d6m$1o35u$1@dont-email.me>
    Injection-Info: google-groups.googlegroups.com; posting-host=130.225.196.250; posting-account=mW5JKwkAAAAMyuWOVeLp8yffyAkVx0g7
    NNTP-Posting-Host: 130.225.196.250
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com>
    <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitqvi$rjpc$1@dont-email.me>
    <r257lipb348csh8otghajpb8v2ds1707lj@4ax.com> <uj2d6m$1o35u$1@dont-email.me> User-Agent: G2/1.0
    MIME-Version: 1.0
    Message-ID: <5d701133-5dc6-467f-9a05-c44523ac8651n@googlegroups.com>
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did
    nothing, lawsuit claims
    From: Lasse Langwadt Christensen <langwadt@fonz.dk>
    Injection-Date: Wed, 15 Nov 2023 12:43:20 +0000
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable
    X-Received-Bytes: 3338

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to Martin Brown on Wed Nov 15 14:02:37 2023
    XPost: free.spam

    The idiot Martin Brown <'''newspam'''@nonad.co.uk> persisting in being an Off-topic troll...

    --
    Martin Brown <'''newspam'''@nonad.co.uk> wrote:

    Path: not-for-mail
    From: Martin Brown <'''newspam'''@nonad.co.uk>
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did nothing, lawsuit claims
    Date: Wed, 15 Nov 2023 11:57:48 +0000
    Organization: A noiseless patient Spider
    Lines: 53
    Message-ID: <uj2bo3$1nro4$1@dont-email.me>
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com> <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitopl$r9m7$1@dont-email.me> <cu47li9f5gri305iafvffnmao9aurkvi2m@4ax.com>
    MIME-Version: 1.0
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit
    Injection-Date: Wed, 15 Nov 2023 11:57:55 -0000 (UTC)
    Injection-Info: dont-email.me; posting-host="da074032933b93e032349712827090fb"; logging-data="1830660"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19UjHEIsyTTttYVYjB86epDl4Fkmh5uUpRRdJHqGOC9xA=="
    User-Agent: Mozilla Thunderbird
    Cancel-Lock: sha1:w2PBoR983jjXRW2W0ZNP74tfl9M=
    In-Reply-To: <cu47li9f5gri305iafvffnmao9aurkvi2m@4ax.com>
    Content-Language: en-GB
    X-Received-Bytes: 3584

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to '''newspam'''@nonad.co.uk on Wed Nov 15 07:48:29 2023
    On Wed, 15 Nov 2023 11:57:48 +0000, Martin Brown
    <'''newspam'''@nonad.co.uk> wrote:

    On 14/11/2023 15:36, John Larkin wrote:
    On Mon, 13 Nov 2023 18:09:57 -0000 (UTC), Phil Hobbs
    <pcdhSpamMeSenseless@electrooptical.net> wrote:

    John Larkin <jl@997PotHill.com> wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fredbloggs.fred@gmail.com> wrote:


    'Intel has been sued by a handful of PC buyers who claim the x86 goliath >>>>> failed to act when informed five years ago about faulty chip
    instructions that allowed the recent Downfall vulnerability, and during >>>>> that period sold billions of insecure chips.'

    https://www.theregister.com/2023/11/09/intel_downfall_lawsuit/

    Some day we will be free of x86 and freed from bloated insecure
    operating systems.

    It isn't the x86's fault that consumer OS's are insecure it is the far
    too much code running at high privilege levels required for gaming.

    IBM's OS/2 was a pretty secure OS on the x86 for its day. Had it been
    for 386 and above only then history might have been different. Making it
    work on the legacy 286 was an incredibly stupid idea that let Win3 gain
    the upper hand. Conflated with it was the launch of the PS/2 hardware
    with its MCA bus made all the rival PC makers club together against IBM.

    Talk about shooting yourself in the foot with both barrels, reloading
    and doing it again...

    Well, we can go back to banging rocks together anytime we like. ;)


    Or put 1024 risc processors on a chip and manage them rationally.

    The devil is *always* in the details. Only someone who has never worked
    on highly parallel systems would suggest such a naive approach.

    Absolute hardware protection isn't naive. It's not even hard. But
    you've got to want to do it.

    Why do you always revert to insults, and not make rational cases for
    your opinions? Most people do that, because lame insults are much
    easier than thinking.


    Once you go beyond 4 CPUs coordinating who has access to what and when >becomes ever more complicated. The most important task is invariably the
    one that farms out work to the others so that they are all doing useful
    work. It is quite easy to end up using more power to do less if you push >number of CPU cores too high. Particularly in problems where smart
    pruning of the tree can eliminated large chunks of brute force work.

    Graphics cards and CUDA already provide massively parallel CPUs for
    tasks which are amenable to such treatment. AI and some scientific
    computing can be done this way very efficiently.

    That doesn't make the OS any more secure. All that hung-on hardware
    just creates more opportunities for hacks.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Martin Brown on Wed Nov 15 10:09:53 2023
    On 11/15/2023 4:57 AM, Martin Brown wrote:
    Once you go beyond 4 CPUs coordinating who has access to what and when becomes
    ever more complicated.

    But that's really more of a case with SMP -- there is strong temptation
    to "impurely" share things that really *shouldn't* be shared. All, of
    course, in the name of "performance".

    Decoupling processors is much like decoupling processes -- you
    want to *minimize* interactions (doing otherwise is usually a
    very bad smell!)

    The most important task is invariably the one that farms
    out work to the others so that they are all doing useful work.

    Yes. And, the "shorter" the tasks, the tougher this becomes
    as it's NP-Hard to sort out how "best" to do so.

    OTOH, for long-running processes, there are more opportunities
    for tuning -- if moving a process is relatively inexpensive
    (as it would be on SMP)

    It is quite easy
    to end up using more power to do less if you push number of CPU cores too high.

    I run multiple 4-core devices, loosely coupled. Trying to keep every
    core maximally used -- in light of a dynamic workload -- is costly
    (time and space). In my case, I can dedicate cores to specific
    high-overhead tasks (like keeping the network saturated) to
    make use of those resources. And, can migrate (long-running)
    tasks between nodes (and, thus, cores) to balance the workload
    system-wide.

    *AND*, make a note of what I've done, "successfully", so the next
    time the opportunity arises, I can adopt this configuration without
    having to rehash the same analysis!

    OTOH, cores are inexpensive so why the obsession with performance
    (often at the expense of reliability, security, maintainability, etc.)?

    [*Billions* of dollars maintaining Linux... based on a 50 year-old
    OS's notion of how an OS should be designed and the services that
    it should present. Really? No one has learned anything in all these
    decades? Is keeping old code running worth that much to FUTURE
    code?]

    Particularly in problems where smart pruning of the tree can eliminated large chunks of brute force work.

    A real problem is having a scheme for the run-time tracking of dependencies between tasks. E.g., if X dies (or is killed off), what other processes
    are no "made redundant" due to its unavailability? Likewise, how much
    other cruft can you discard *if* you choose to kill off X?

    Sadly, most schedulers and workload managers only look at a naive
    "priority" to make their decisions and, if lucky, later *react*
    to other processes that fail to make progress.

    Graphics cards and CUDA already provide massively parallel CPUs for tasks which
    are amenable to such treatment. AI and some scientific computing can be done this way very efficiently.

    But those are usually truly parallel operations; you don't try to
    run different processes on each of those processors.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to John Larkin on Wed Nov 15 09:39:05 2023
    On Tuesday, November 14, 2023 at 7:37:37 AM UTC-8, John Larkin wrote:
    On Mon, 13 Nov 2023 18:09:57 -0000 (UTC), Phil Hobbs <pcdhSpamM...@electrooptical.net> wrote:

    John Larkin <j...@997PotHill.com> wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fred...@gmail.com> wrote:

    Some day we will be free of x86 and freed from bloated insecure
    operating systems.

    Well, we can go back to banging rocks together anytime we like. ;)

    Or put 1024 risc processors on a chip and manage them rationally.

    We cannot rationally manage a congress of a few hundred when they're
    humans, why do you expect we can handle intercommunicating
    'risc processors' either? The experience with humans is
    well documented, hasn't changed much since

    <https://archive.org/details/mackay-popular-delusions>

    So, to the idea of rationally managing 1024 risk processors, I will add "Imagine a Beowulf cluster of those..."

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to All on Wed Nov 15 18:16:42 2023
    On 14/11/2023 16:09, Dimiter_Popoff wrote:
    On 11/14/2023 17:38, John Larkin wrote:
    On Mon, 13 Nov 2023 20:47:13 +0200, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 11/13/2023 19:32, John Larkin wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fredbloggs.fred@gmail.com> wrote:


    'Intel has been sued by a handful of PC buyers who claim the x86
    goliath failed to act when informed five years ago about faulty
    chip instructions that allowed the recent Downfall vulnerability,
    and during that period sold billions of insecure chips.'

    https://www.theregister.com/2023/11/09/intel_downfall_lawsuit/

    Some day we will be free of x86 and freed from bloated insecure
    operating systems.


    At least we can stay optimistic :-). Then what, ARM or Risc-V...
    That at a time when power is still around, and IBM made it freely
    license a couple of years ago.
    The rest cannot even sort out their endianness nonsense.
    I am not sure if anyone actually realizes how *wast* the bloat is.

    Windows 11 is obvious proof.

    I was offered it a few times on my windows 10 laptop (named tvset3...)
    and so far I was allowed to decline. A neighbour came a few days ago
    for help (I sometimes serve as IT to helpless neighbours) who had
    clicked accept... His problem was they wanted to force him into
    having a PIN number, the screen after that looked weird but
    usable. I don't know how much of it can be brought back to "normal"
    as one sees what normal is but judging by your outcry it must be
    really bad. Eventually they will force us all into it I guess,
    I can swallow that as I use it for reading pdf-s and browsing,
    plus the occasional ltspice.

    The only gotcha I can see is that every version requires more ram and
    occupies more disk space but both are cheap and fast today.

    Win10 is going officially unsupported sometime soon in 2025. I expect it
    will get a reprieve or there will be a global malware catastrophe.

    https://www.zdnet.com/article/microsoft-windows-10-is-a-security-disaster-waiting-to-happen/

    Win11 main advantage for me is that it understands performance cores on
    the more recent Intel CPUs. That is a kludge in Win10.

    The last truly dreadful edition of windows was Win8.
    Think Picasso on a bad acid trip and you will not be too far off.

    --
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to whit3rd@gmail.com on Wed Nov 15 18:52:08 2023
    XPost: free.spam

    The idiot whit3rd <whit3rd@gmail.com> persisting in being an Off-topic troll...

    --
    whit3rd <whit3rd@gmail.com> wrote:

    X-Received: by 2002:a0c:d847:0:b0:66d:101e:9f11 with SMTP id i7-20020a0cd847000000b0066d101e9f11mr137228qvj.8.1700069946416;
    Wed, 15 Nov 2023 09:39:06 -0800 (PST)
    X-Received: by 2002:a17:902:efcc:b0:1cc:2549:c281 with SMTP id
    ja12-20020a170902efcc00b001cc2549c281mr1694280plb.13.1700069946092; Wed, 15
    Nov 2023 09:39:06 -0800 (PST)
    Path: not-for-mail
    Newsgroups: sci.electronics.design
    Date: Wed, 15 Nov 2023 09:39:05 -0800 (PST)
    In-Reply-To: <cu47li9f5gri305iafvffnmao9aurkvi2m@4ax.com>
    Injection-Info: google-groups.googlegroups.com; posting-host=209.221.140.126; posting-account=vKQm_QoAAADOaDCYsqOFDAW8NJ8sFHoE
    NNTP-Posting-Host: 209.221.140.126
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com>
    <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitopl$r9m7$1@dont-email.me> <cu47li9f5gri305iafvffnmao9aurkvi2m@4ax.com>
    User-Agent: G2/1.0
    MIME-Version: 1.0
    Message-ID: <b5d488fb-4cae-41de-a003-0f823a6fd2b2n@googlegroups.com>
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did
    nothing, lawsuit claims
    From: whit3rd <whit3rd@gmail.com>
    Injection-Date: Wed, 15 Nov 2023 17:39:06 +0000
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable
    X-Received-Bytes: 2436

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Martin Brown on Wed Nov 15 11:52:01 2023
    On 11/15/2023 5:22 AM, Martin Brown wrote:
    Then you really will have a secure OS on an x86 chip (provided that you configure it correctly). The learning curve on Unix is a bit steep though but it is useable out of the box. I'm running my copy as a guest OS under Win11 Pro
    via VMWare because the MS virtualisation sucks.

    The biggest part of the "UN*X mindset" is the notion that you *build* tools (functionality) by stringing together EXISTING tools -- instead of the
    MS mindset where every tool that you *think* the user might need while
    using your app has to be PART of your app!

    This requires familiarity with more small tools -- instead of lots of
    detail about big tools that each try to offer some similar "small
    function" within.

    I have finally had to install Ubuntu myself to gain access to exotic software that is only available on Unix (and porting it to Windows would be incredibly tedious and error prone which is why no-one ever has).

    Why have you (presumably) avoided it? Most Eunices install a lot easier
    (and quicker!) than Windows. The only tough part is if you want to offer specific network services on a host (name, file transfer, SMB, packet filtering, etc.). There, the UIs tend to be pretty archaic (read:
    non-GUI) and often cryptic. Best not tackled by newbies.

    I'm quite impressed with it so far and Maxima is much more stable on the Unix platform which is an unexpected bonus for me (likewise I suspect for Latex too). I may yet make the change to becoming a Unix advocate.

    In future there are some things that I will now do under Unix because it works
    better there than on Windows rather than because there is no equivalent on Windows (which is what motivated me to jump ship).

    My approach has sort of been the opposite: using UN*X for the
    important things and Windows for those things that are more
    "window dressing" (documentation, CAD/EDA, multimedia, etc.).
    I've not used a Windows-based toolchain for ages (since VC1.0!)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to John Larkin on Wed Nov 15 18:52:39 2023
    XPost: free.spam

    The idiot John Larkin <jl@997PotHill.com> persisting in being an Off-topic troll...

    --
    John Larkin <jl@997PotHill.com> wrote:

    Path: not-for-mail
    NNTP-Posting-Date: Wed, 15 Nov 2023 15:48:56 +0000
    From: John Larkin <jl@997PotHill.com>
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did nothing, lawsuit claims
    Date: Wed, 15 Nov 2023 07:48:29 -0800
    Organization: Highland Tech
    Reply-To: xx@yy.com
    Message-ID: <2pp9lilnjguvunre4bjo8etijfk1oaohpa@4ax.com>
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com> <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitopl$r9m7$1@dont-email.me> <cu47li9f5gri305iafvffnmao9aurkvi2m@4ax.com> <uj2bo3$1nro4$1@dont-email.me>
    X-Newsreader: Forte Agent 3.1/32.783
    MIME-Version: 1.0
    Content-Type: text/plain; charset=us-ascii
    Content-Transfer-Encoding: 7bit
    Lines: 64
    X-Trace: sv3-XvZqwJpsyGrVjEvxwj4dLdoq21jDApq1ssX3K4xrbL7XiebrWYztFA8m2G4KuZ9X5Ea/IGs8N7bnOGy!D3ZJ9xoFY+SxQ09J/HgooM4Zo2s+Dzd7ICvoA8h8xhK3Hl8q/vEG8Pwhd27Gj87vygwO0dd4h6Ir!E1Zfig==
    X-Complaints-To: www.supernews.com/docs/abuse.html
    X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
    X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
    X-Postfilter: 1.3.40
    X-Received-Bytes: 4300

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to Don Y on Wed Nov 15 18:52:45 2023
    XPost: free.spam

    The idiot Don Y <blockedofcourse@foo.invalid> persisting in being an Off-topic troll...

    --
    Don Y <blockedofcourse@foo.invalid> wrote:

    Path: not-for-mail
    From: Don Y <blockedofcourse@foo.invalid>
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did
    nothing, lawsuit claims
    Date: Wed, 15 Nov 2023 10:09:53 -0700
    Organization: A noiseless patient Spider
    Lines: 66
    Message-ID: <uj2u18$1qs7f$1@dont-email.me>
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com>
    <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitopl$r9m7$1@dont-email.me>
    <cu47li9f5gri305iafvffnmao9aurkvi2m@4ax.com> <uj2bo3$1nro4$1@dont-email.me> MIME-Version: 1.0
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit
    Injection-Date: Wed, 15 Nov 2023 17:10:00 -0000 (UTC)
    Injection-Info: dont-email.me; posting-host="d54e60bac4869010f681b4fb05599286";
    logging-data="1929455"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Pp2tocJVidCZTzffIxJQm"
    User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
    Thunderbird/102.2.2
    Cancel-Lock: sha1:4/fFPKttHRMJqKiCV7wHQgmyx2o=
    Content-Language: en-US
    In-Reply-To: <uj2bo3$1nro4$1@dont-email.me>
    X-Received-Bytes: 4185

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to Martin Brown on Wed Nov 15 18:52:51 2023
    XPost: free.spam

    The arsehole Martin Brown <'''newspam'''@nonad.co.uk> persisting in being an Off-topic troll...

    --
    Martin Brown <'''newspam'''@nonad.co.uk> wrote:

    Path: not-for-mail
    From: Martin Brown <'''newspam'''@nonad.co.uk>
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did
    nothing, lawsuit claims
    Date: Wed, 15 Nov 2023 18:16:42 +0000
    Organization: A noiseless patient Spider
    Lines: 57
    Message-ID: <uj31uf$1rfa0$1@dont-email.me>
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com>
    <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitqvi$rjpc$1@dont-email.me>
    <r257lipb348csh8otghajpb8v2ds1707lj@4ax.com> <uj063l$19nj8$1@dont-email.me> MIME-Version: 1.0
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit
    Injection-Date: Wed, 15 Nov 2023 18:16:47 -0000 (UTC)
    Injection-Info: dont-email.me; posting-host="da074032933b93e032349712827090fb";
    logging-data="1948992"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+UwALQzrfxFIoFKcvTCSfVm+whOoe3K5fdemZ8EULoLw=="
    User-Agent: Mozilla Thunderbird
    Cancel-Lock: sha1:PmRYIptwRw4VNY9YZhwaD9YaZMk=
    In-Reply-To: <uj063l$19nj8$1@dont-email.me>
    Content-Language: en-GB
    X-Received-Bytes: 3848

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Martin Brown on Wed Nov 15 11:54:01 2023
    On 11/15/2023 11:16 AM, Martin Brown wrote:
    The only gotcha I can see is that every version requires more ram and occupies
    more disk space but both are cheap and fast today.

    Save for a generation of machines with 8GB *hardware* memory limits...

    OTOH, I can run a *BSD box with *megabytes* of RAM if I am willing
    to live witht he thrashing (which, unlike windows machines,
    won't take the machine to its knees)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to Don Y on Wed Nov 15 20:41:25 2023
    XPost: free.spam

    The idiot Don Y <blockedofcourse@foo.invalid> persisting in being an Off-topic troll...

    --
    Don Y <blockedofcourse@foo.invalid> wrote:

    Path: not-for-mail
    From: Don Y <blockedofcourse@foo.invalid>
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did
    nothing, lawsuit claims
    Date: Wed, 15 Nov 2023 11:52:01 -0700
    Organization: A noiseless patient Spider
    Lines: 40
    Message-ID: <uj340o$1rrht$1@dont-email.me>
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com>
    <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitqvi$rjpc$1@dont-email.me>
    <r257lipb348csh8otghajpb8v2ds1707lj@4ax.com> <uj2d6m$1o35u$1@dont-email.me> MIME-Version: 1.0
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit
    Injection-Date: Wed, 15 Nov 2023 18:52:09 -0000 (UTC)
    Injection-Info: dont-email.me; posting-host="d54e60bac4869010f681b4fb05599286";
    logging-data="1961533"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18T8t6LHW4UjPCoJGFYYSy+"
    User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
    Thunderbird/102.2.2
    Cancel-Lock: sha1:hNyz3KxHPH6tJPEDCEH0cEDOAsw=
    Content-Language: en-US
    In-Reply-To: <uj2d6m$1o35u$1@dont-email.me>
    X-Received-Bytes: 3329

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From john larkin@21:1/5 to All on Wed Nov 15 13:48:30 2023
    On Wed, 15 Nov 2023 09:39:05 -0800 (PST), whit3rd <whit3rd@gmail.com>
    wrote:

    On Tuesday, November 14, 2023 at 7:37:37?AM UTC-8, John Larkin wrote:
    On Mon, 13 Nov 2023 18:09:57 -0000 (UTC), Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    John Larkin <j...@997PotHill.com> wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fred...@gmail.com> wrote:

    Some day we will be free of x86 and freed from bloated insecure
    operating systems.

    Well, we can go back to banging rocks together anytime we like. ;)

    Or put 1024 risc processors on a chip and manage them rationally.

    We cannot rationally manage a congress of a few hundred when they're
    humans, why do you expect we can handle intercommunicating
    'risc processors' either? The experience with humans is
    well documented, hasn't changed much since

    <https://archive.org/details/mackay-popular-delusions>

    So, to the idea of rationally managing 1024 risk processors, I will add >"Imagine a Beowulf cluster of those..."

    It makes sense, if you think and give it a chance. Don't apply the
    current big-OS multiprocessor multithread paradigm.

    One CPU is the master manager.

    Some CPUs are dedicated to be services, like device drivers, file
    handlers, internet interfaces, user interfaces.

    Then some CPUs run applications. Some have lots of power, including
    floating point, some are dinky. Probably two catagories.

    Every CPU has its own small ram, cache, and an access mechanism to
    main external DRAMs. Every CPU has absolute hardware protection.
    Violate the rules and die.

    The limit on a multicore chip will be thermal.

    CPUs used to be a rare, expensive resource. We have plenty of compute
    power now. Let's use it for reliability.

    Not that current OS's are resource efficient. DOS on an 8088 did some
    things faster than my new monster with 20K times the resources.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From john larkin@21:1/5 to '''newspam'''@nonad.co.uk on Wed Nov 15 14:01:18 2023
    On Wed, 15 Nov 2023 18:16:42 +0000, Martin Brown
    <'''newspam'''@nonad.co.uk> wrote:

    On 14/11/2023 16:09, Dimiter_Popoff wrote:
    On 11/14/2023 17:38, John Larkin wrote:
    On Mon, 13 Nov 2023 20:47:13 +0200, Dimiter_Popoff <dp@tgi-sci.com>
    wrote:

    On 11/13/2023 19:32, John Larkin wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fredbloggs.fred@gmail.com> wrote:


    'Intel has been sued by a handful of PC buyers who claim the x86
    goliath failed to act when informed five years ago about faulty
    chip instructions that allowed the recent Downfall vulnerability,
    and during that period sold billions of insecure chips.'

    https://www.theregister.com/2023/11/09/intel_downfall_lawsuit/

    Some day we will be free of x86 and freed from bloated insecure
    operating systems.


    At least we can stay optimistic :-). Then what, ARM or Risc-V...
    That at a time when power is still around, and IBM made it freely
    license a couple of years ago.
    The rest cannot even sort out their endianness nonsense.
    I am not sure if anyone actually realizes how *wast* the bloat is.

    Windows 11 is obvious proof.

    I was offered it a few times on my windows 10 laptop (named tvset3...)
    and so far I was allowed to decline. A neighbour came a few days ago
    for help (I sometimes serve as IT to helpless neighbours) who had
    clicked accept... His problem was they wanted to force him into
    having a PIN number, the screen after that looked weird but
    usable. I don't know how much of it can be brought back to "normal"
    as one sees what normal is but judging by your outcry it must be
    really bad. Eventually they will force us all into it I guess,
    I can swallow that as I use it for reading pdf-s and browsing,
    plus the occasional ltspice.

    The only gotcha I can see is that every version requires more ram and >occupies more disk space but both are cheap and fast today.

    Win10 is going officially unsupported sometime soon in 2025. I expect it
    will get a reprieve or there will be a global malware catastrophe.

    https://www.zdnet.com/article/microsoft-windows-10-is-a-security-disaster-waiting-to-happen/

    Win11 main advantage for me is that it understands performance cores on
    the more recent Intel CPUs. That is a kludge in Win10.

    The last truly dreadful edition of windows was Win8.
    Think Picasso on a bad acid trip and you will not be too far off.

    I miss Win7, but most of the machines have died.

    Win11 got terrible user reviews, but update 23H2 fixed a lot of
    stupidities. It's almost tolerable, after a lot of tweaks.

    It runs Firefox, LT Spice, PADS, VLC, Crimson, Agent, Irfanview, and a
    bunch of my old compiled PowerBasic programs. And seems reliable so
    far.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to john larkin on Wed Nov 15 23:06:08 2023
    XPost: free.spam

    The idiot john larkin <jl@650pot.com> persisting in being an Off-topic troll...

    --
    john larkin <jl@650pot.com> wrote:

    Path: not-for-mail
    NNTP-Posting-Date: Wed, 15 Nov 2023 22:01:18 +0000
    From: john larkin <jl@650pot.com>
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did nothing, lawsuit claims
    Date: Wed, 15 Nov 2023 14:01:18 -0800
    Message-ID: <kifalit7mrjn9fcieugqi3vibtbe83lfbj@4ax.com>
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com> <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitqvi$rjpc$1@dont-email.me> <r257lipb348csh8otghajpb8v2ds1707lj@4ax.com> <uj063l$19nj8$1@dont-email.me> <uj31uf$1rfa0$1@dont-email.me>
    User-Agent: ForteAgent/8.00.32.1272
    MIME-Version: 1.0
    Content-Type: text/plain; charset=us-ascii
    Content-Transfer-Encoding: 7bit
    Lines: 66
    X-Trace: sv3-DTxSNgpg3br4iF94EXd6RMoWgGw5MTrPq6Lq2Pmnk2gRNgFppoUUg9sscrN6fqsymUSkizBRT9ngLrA!QFMjrfwe9xRX9XFU6EYORxdxPb8DFs0u1qUOXC1b0lnwERIv0ZqLy6QvWo2vxrEb7jKSKA4T1v9L!DIVAgQ==
    X-Complaints-To: www.supernews.com/docs/abuse.html
    X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
    X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
    X-Postfilter: 1.3.40
    X-Received-Bytes: 4506

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anthony William Sloman@21:1/5 to John Larkin on Wed Nov 15 21:52:43 2023
    On Thursday, November 16, 2023 at 2:49:13 AM UTC+11, John Larkin wrote:
    On Wed, 15 Nov 2023 11:57:48 +0000, Martin Brown
    <'''newspam'''@nonad.co.uk> wrote:

    On 14/11/2023 15:36, John Larkin wrote:
    On Mon, 13 Nov 2023 18:09:57 -0000 (UTC), Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    John Larkin <j...@997PotHill.com> wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fred...@gmail.com> wrote:


    'Intel has been sued by a handful of PC buyers who claim the x86 goliath
    failed to act when informed five years ago about faulty chip
    instructions that allowed the recent Downfall vulnerability, and during
    that period sold billions of insecure chips.'

    https://www.theregister.com/2023/11/09/intel_downfall_lawsuit/

    Some day we will be free of x86 and freed from bloated insecure
    operating systems.

    It isn't the x86's fault that consumer OS's are insecure it is the far
    too much code running at high privilege levels required for gaming.

    IBM's OS/2 was a pretty secure OS on the x86 for its day. Had it been
    for 386 and above only then history might have been different. Making it >work on the legacy 286 was an incredibly stupid idea that let Win3 gain >the upper hand. Conflated with it was the launch of the PS/2 hardware
    with its MCA bus made all the rival PC makers club together against IBM.

    Talk about shooting yourself in the foot with both barrels, reloading
    and doing it again...

    Well, we can go back to banging rocks together anytime we like. ;)


    Or put 1024 risc processors on a chip and manage them rationally.

    The devil is *always* in the details. Only someone who has never worked
    on highly parallel systems would suggest such a naive approach.

    Absolute hardware protection isn't naive. It's not even hard. But
    you've got to want to do it.

    Why do you always revert to insults, and not make rational cases for your opinions?

    He did, but you post4ed your response above it.

    Most people do that, because lame insults are much easier than thinking.

    You are exhibiting exactly that behavior.

    Once you go beyond 4 CPUs coordinating who has access to what and when >becomes ever more complicated. The most important task is invariably the >one that farms out work to the others so that they are all doing useful >work. It is quite easy to end up using more power to do less if you push >number of CPU cores too high. Particularly in problems where smart
    pruning of the tree can eliminated large chunks of brute force work.

    Graphics cards and CUDA already provide massively parallel CPUs for
    tasks which are amenable to such treatment. AI and some scientific >computing can be done this way very efficiently.

    That doesn't make the OS any more secure. All that hung-on hardware just creates more opportunities for hacks.\\

    If it isn't designed carefully.

    --
    Bill Sloman, Sydney

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Panteltje@21:1/5 to jl@650pot.com on Thu Nov 16 06:44:00 2023
    On a sunny day (Wed, 15 Nov 2023 13:48:30 -0800) it happened john larkin <jl@650pot.com> wrote in <48eali9c9lp841616piphv6jc2tp16rpuj@4ax.com>:

    On Wed, 15 Nov 2023 09:39:05 -0800 (PST), whit3rd <whit3rd@gmail.com>
    wrote:

    On Tuesday, November 14, 2023 at 7:37:37?AM UTC-8, John Larkin wrote:
    On Mon, 13 Nov 2023 18:09:57 -0000 (UTC), Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    John Larkin <j...@997PotHill.com> wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fred...@gmail.com> wrote:

    Some day we will be free of x86 and freed from bloated insecure
    operating systems.

    Well, we can go back to banging rocks together anytime we like. ;)

    Or put 1024 risc processors on a chip and manage them rationally.

    We cannot rationally manage a congress of a few hundred when they're >>humans, why do you expect we can handle intercommunicating
    'risc processors' either? The experience with humans is
    well documented, hasn't changed much since

    <https://archive.org/details/mackay-popular-delusions>

    So, to the idea of rationally managing 1024 risk processors, I will add >>"Imagine a Beowulf cluster of those..."

    It makes sense, if you think and give it a chance. Don't apply the
    current big-OS multiprocessor multithread paradigm.

    One CPU is the master manager.

    Some CPUs are dedicated to be services, like device drivers, file
    handlers, internet interfaces, user interfaces.

    Then some CPUs run applications. Some have lots of power, including
    floating point, some are dinky. Probably two catagories.

    Every CPU has its own small ram, cache, and an access mechanism to
    main external DRAMs. Every CPU has absolute hardware protection.
    Violate the rules and die.

    The limit on a multicore chip will be thermal.

    CPUs used to be a rare, expensive resource. We have plenty of compute
    power now. Let's use it for reliability.

    Not that current OS's are resource efficient. DOS on an 8088 did some
    things faster than my new monster with 20K times the resources.

    I have several Microchip PIC powered small boxes connected
    to the 'main' computer (a Raspberry Pi4 4 GB with 4 TB harddisk now) via serial or Ethernet,
    and some Chinese boxes (security camera system that has its own processor, GPS receiver, etc) too,
    also data from other Raspberries doing things.
    If any fails, only that specific input is affected, and error reports will appear.
    or the main computer will even talk to you (like now for the gas sensor) if something is wrong.
    It makes the load on the 'main' computer minimal.
    So this is basically a multi-processor system that can be extended in a big way.
    No silly task interrupts needed to handle all those processes,
    all handled on the spot, PICs are a few dollars.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to Don Y on Thu Nov 16 11:04:38 2023
    On 15/11/2023 18:54, Don Y wrote:
    On 11/15/2023 11:16 AM, Martin Brown wrote:
    The only gotcha I can see is that every version requires more ram and
    occupies more disk space but both are cheap and fast today.

    Save for a generation of machines with 8GB *hardware* memory limits...

    It was ever thus. Time was when each new OS required almost all of the
    hardware currently in use to be replaced.

    OTOH, I can run a *BSD box with *megabytes* of RAM if I am willing
    to live witht he thrashing (which, unlike windows machines,
    won't take the machine to its knees)

    I can recall a time back when big iron had a whopping (for the time) 4MB
    of main memory and when you you had to get a special ticket to allow
    your jobs to use more than 1MB at a time. Lisp wouldn't run in less.

    --
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to john larkin on Thu Nov 16 11:17:04 2023
    On 15/11/2023 22:01, john larkin wrote:
    On Wed, 15 Nov 2023 18:16:42 +0000, Martin Brown
    <'''newspam'''@nonad.co.uk> wrote:

    On 14/11/2023 16:09, Dimiter_Popoff wrote:

    I can swallow that as I use it for reading pdf-s and browsing,
    plus the occasional ltspice.

    The only gotcha I can see is that every version requires more ram and
    occupies more disk space but both are cheap and fast today.

    Win10 is going officially unsupported sometime soon in 2025. I expect it
    will get a reprieve or there will be a global malware catastrophe.

    https://www.zdnet.com/article/microsoft-windows-10-is-a-security-disaster-waiting-to-happen/

    Win11 main advantage for me is that it understands performance cores on
    the more recent Intel CPUs. That is a kludge in Win10.

    The last truly dreadful edition of windows was Win8.
    Think Picasso on a bad acid trip and you will not be too far off.

    I miss Win7, but most of the machines have died.

    Win7 will run on modern CPUs although I wouldn't recommend it unless you
    either have a damn good impenetrable firewall (plenty of ancient big
    scientific instruments still work that way 20 year design life -
    although clever virtualisation of antique hardware environments are
    getting around that).

    You can extract the original license key from old kit with suitable
    tools - although the license server may now have disappeared so you
    cannot register new hardware to run Win7. It means that certain
    motherboards have premium prices in the second hand market.

    You can make Win11 look enough like WIn7 to be acceptable.

    Win11 got terrible user reviews, but update 23H2 fixed a lot of
    stupidities. It's almost tolerable, after a lot of tweaks.

    It runs Firefox, LT Spice, PADS, VLC, Crimson, Agent, Irfanview, and a
    bunch of my old compiled PowerBasic programs. And seems reliable so
    far.

    None of those are particularly taxing. The big change was when 32bit
    code (and before that 16bit) became unsupported.
    That broke a lot of major players installers like Adobe Photoshop and
    others.
    You just like to whinge and whine about Intel and Microsoft.

    --
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Martin Brown on Thu Nov 16 05:44:36 2023
    On 11/16/2023 4:04 AM, Martin Brown wrote:
    On 15/11/2023 18:54, Don Y wrote:
    On 11/15/2023 11:16 AM, Martin Brown wrote:
    The only gotcha I can see is that every version requires more ram and
    occupies more disk space but both are cheap and fast today.

    Save for a generation of machines with 8GB *hardware* memory limits...

    It was ever thus. Time was when each new OS required almost all of the hardware
    currently in use to be replaced.

    Dunno. Save for laptops, I've always opted to repurpose servers
    as workstations so RAM was never really an issue (144G in each
    of my current W7 boxes). Or, number of spindles.

    *This* machine is of the "8GB, single spindle" variety and it
    is annoying to see how often I can run out of resources just
    surfing/email. SWMBO has a similar machine that often throws
    fits running MSAccess -- likely a resource problem but Access
    never throws obvious errors.

    [This seems to be a common problem in larger pieces of software;
    some error condition is checked in a utility function/subroutine,
    then reported to it's caller -- who has no idea what to DO about
    it (often because they are too far down from the UI) so it just
    gets ignored. Sort of like folks failing to check malloc().]

    [[It's not unique to big pieces of code, either. I'm sure everyone
    who has written a UART driver (or equivalent) has included code
    in it to check for framing/parity/overrun errors... but, what did
    they *do* with that information? How was it ever communicated
    to higher levels in the code so that <something> could act on it?
    Is "Present signal level is 1234" where many of the characters
    have parity errors -- or, <gasp> a framing error in the middle
    of "12ABC34" -- the same as the identical message devoid of errors?]]

    OTOH, I can run a *BSD box with *megabytes* of RAM if I am willing
    to live witht he thrashing (which, unlike windows machines,
    won't take the machine to its knees)

    I can recall a time back when big iron had a whopping (for the time) 4MB of main memory and when you you had to get a special ticket to allow your jobs to
    use more than 1MB at a time. Lisp wouldn't run in less.

    I used to run FreeBSD/NetBSD on a 386SX with 4MB of RAM. Annoying to
    see how much it now requires (still significantly less than Windows!)

    As a kid, it was a 16KB *mini* that we rented time on! (CHAINing programs)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to upsidedown@downunder.com on Thu Nov 16 05:56:49 2023
    On 11/16/2023 5:44 AM, upsidedown@downunder.com wrote:
    Such number of processors might be usable e.g. for Monte Carlo
    simulations, but quite useless for random computer use.

    "Random" is the operative word, there.

    But, not all computer use falls cleanly into "desktop vs. nondesktop".
    I'm currently at 1152 cores and finding uses for all of them (though
    admittedly not *optimal* uses).

    As with thousands of processES, the key to effectively using thousands
    of processORS is to ensure they aren't competing for much. Communications (intercommunications) is the bane of *any* system, at run-time.

    And, at design-time.

    The problem is initially one of complexity management in the MIND of
    the developer; does your problem decompose nicely?

    If you can find INDEPENDENT uses for physical -- and virtual -- processes, there's no problem exploiting multitudes of them.

    [I've frequently added small microcontrollers as "I/O processors"
    to improve the design/performance of a primary microPROCESSOR.
    Instead of adding generic hardware to interface to the field
    directly from the MPU, let the I/Os on an MCU handle that
    and give the MCU responsibility for running that I/O -- under
    the direction of the MPU. MCUs are cheap. The same is true
    of MPUs!]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From upsidedown@downunder.com@21:1/5 to john larkin on Thu Nov 16 14:44:36 2023
    On Wed, 15 Nov 2023 13:48:30 -0800, john larkin <jl@650pot.com> wrote:

    On Wed, 15 Nov 2023 09:39:05 -0800 (PST), whit3rd <whit3rd@gmail.com>
    wrote:

    On Tuesday, November 14, 2023 at 7:37:37?AM UTC-8, John Larkin wrote:
    On Mon, 13 Nov 2023 18:09:57 -0000 (UTC), Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    John Larkin <j...@997PotHill.com> wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fred...@gmail.com> wrote:

    Some day we will be free of x86 and freed from bloated insecure
    operating systems.

    Well, we can go back to banging rocks together anytime we like. ;)

    Or put 1024 risc processors on a chip and manage them rationally.

    We cannot rationally manage a congress of a few hundred when they're >>humans, why do you expect we can handle intercommunicating
    'risc processors' either? The experience with humans is
    well documented, hasn't changed much since

    <https://archive.org/details/mackay-popular-delusions>

    So, to the idea of rationally managing 1024 risk processors, I will add >>"Imagine a Beowulf cluster of those..."

    Such number of processors might be usable e.g. for Monte Carlo
    simulations, but quite useless for random computer use.


    It makes sense, if you think and give it a chance. Don't apply the
    current big-OS multiprocessor multithread paradigm.

    One CPU is the master manager.

    Some CPUs are dedicated to be services, like device drivers, file
    handlers, internet interfaces, user interfaces.

    Then some CPUs run applications. Some have lots of power, including
    floating point, some are dinky. Probably two catagories.

    Every CPU has its own small ram, cache, and an access mechanism to
    main external DRAMs. Every CPU has absolute hardware protection.
    Violate the rules and die.

    The limit on a multicore chip will be thermal.

    CPUs used to be a rare, expensive resource. We have plenty of compute
    power now. Let's use it for reliability.

    Not that current OS's are resource efficient. DOS on an 8088 did some
    things faster than my new monster with 20K times the resources.

    It sounds like you try to reinvent the IBM SNA mainframe networking architecture from 1974 :-)

    https://en.wikipedia.org/wiki/Systems_Network_Architecture

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to Anthony William Sloman on Thu Nov 16 13:52:15 2023
    XPost: free.spam

    The idiot Anthony William Sloman <bill.sloman@ieee.org> persisting in being an Off-topic troll...

    --
    Anthony William Sloman <bill.sloman@ieee.org> wrote:

    X-Received: by 2002:a05:620a:cc3:b0:778:9aed:d94 with SMTP id b3-20020a05620a0cc300b007789aed0d94mr150749qkj.9.1700113964813;
    Wed, 15 Nov 2023 21:52:44 -0800 (PST)
    X-Received: by 2002:a17:903:3310:b0:1ca:a290:4c1e with SMTP id
    jk16-20020a170903331000b001caa2904c1emr2068376plb.0.1700113964418; Wed, 15
    Nov 2023 21:52:44 -0800 (PST)
    Path: not-for-mail
    Newsgroups: sci.electronics.design
    Date: Wed, 15 Nov 2023 21:52:43 -0800 (PST)
    In-Reply-To: <2pp9lilnjguvunre4bjo8etijfk1oaohpa@4ax.com>
    Injection-Info: google-groups.googlegroups.com; posting-host=59.102.83.245; posting-account=SJ46pgoAAABuUDuHc5uDiXN30ATE-zi-
    NNTP-Posting-Host: 59.102.83.245
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com>
    <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitopl$r9m7$1@dont-email.me>
    <cu47li9f5gri305iafvffnmao9aurkvi2m@4ax.com> <uj2bo3$1nro4$1@dont-email.me> <2pp9lilnjguvunre4bjo8etijfk1oaohpa@4ax.com>
    User-Agent: G2/1.0
    MIME-Version: 1.0
    Message-ID: <86790735-c14c-438b-ba8f-94cb4309fd55n@googlegroups.com>
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did
    nothing, lawsuit claims
    From: Anthony William Sloman <bill.sloman@ieee.org>
    Injection-Date: Thu, 16 Nov 2023 05:52:44 +0000
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable
    X-Received-Bytes: 4848

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to Jan Panteltje on Thu Nov 16 13:53:10 2023
    XPost: free.spam

    The arsehole Jan Panteltje <alien@comet.invalid> persisting in being an Off-topic troll...

    --
    Jan Panteltje <alien@comet.invalid> wrote:

    Path: not-for-mail
    From: Jan Panteltje <alien@comet.invalid>
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did nothing, lawsuit claims
    Date: Thu, 16 Nov 2023 06:44:00 GMT
    Message-ID: <uj4dng$1iu06$1@solani.org>
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com> <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitopl$r9m7$1@dont-email.me> <cu47li9f5gri305iafvffnmao9aurkvi2m@4ax.com> <b5d488fb-4cae-41de-a003-0f823a6fd2b2n@googlegroups.com> <
    48eali9c9lp841616piphv6jc2tp16rpuj@4ax.com>
    MIME-Version: 1.0
    Content-Type: text/plain; ISO-8859-15
    Content-Transfer-Encoding: 8bit
    Injection-Date: Thu, 16 Nov 2023 06:44:00 -0000 (UTC)
    Injection-Info: solani.org;
    logging-data="1669126"; mail-complaints-to="abuse@news.solani.org" User-Agent: NewsFleX-1.5.7.5 (Linux-5.15.32-v7l+)
    Cancel-Lock: sha1:LtA1U6tQ+EiNZzSa3rKlX6zyaS0=
    X-User-ID: eJwFwYEBwCAIA7CXCtKq5wiD/09YwiVT7RAVHI6HTUPxCNXbWd8E0Dh0+7TZflIXqcgxntWJhVchN1jz/kLnFLQ=
    X-Newsreader-location: NewsFleX-1.5.7.5 (c) 'LIGHTSPEED' off line news reader for the Linux platform
    NewsFleX homepage: http://www.panteltje.nl/panteltje/newsflex/ and ftp download ftp://sunsite.unc.edu/pub/linux/system/news/readers/
    X-Received-Bytes: 4431

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to upsidedown@downunder.com on Thu Nov 16 13:53:16 2023
    XPost: free.spam

    The idiot upsidedown@downunder.com persisting in being an Off-topic troll...

    --
    upsidedown@downunder.com wrote:

    Path: not-for-mail
    From: upsidedown@downunder.com
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did nothing, lawsuit claims
    Message-ID: <rk2cli5krra78uhajm05oh1eorag933tq5@4ax.com>
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com> <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitopl$r9m7$1@dont-email.me> <cu47li9f5gri305iafvffnmao9aurkvi2m@4ax.com> <b5d488fb-4cae-41de-a003-0f823a6fd2b2n@googlegroups.com> <
    48eali9c9lp841616piphv6jc2tp16rpuj@4ax.com>
    User-Agent: ForteAgent/8.00.32.1272
    MIME-Version: 1.0
    Content-Type: text/plain; charset=us-ascii
    Content-Transfer-Encoding: 7bit
    Lines: 61
    X-Complaints-To: abuse@easynews.com
    Organization: Forte - www.forteinc.com
    Bytes: 3196
    X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
    Date: Thu, 16 Nov 2023 14:44:36 +0200
    X-Received-Bytes: 3401

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to Martin Brown on Thu Nov 16 13:53:28 2023
    XPost: free.spam

    The idiot Martin Brown <'''newspam'''@nonad.co.uk> persisting in being an Off-topic troll...

    --
    Martin Brown <'''newspam'''@nonad.co.uk> wrote:

    Path: not-for-mail
    From: Martin Brown <'''newspam'''@nonad.co.uk>
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did
    nothing, lawsuit claims
    Date: Thu, 16 Nov 2023 11:04:38 +0000
    Organization: A noiseless patient Spider
    Lines: 21
    Message-ID: <uj4t0d$280cn$1@dont-email.me>
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com>
    <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitqvi$rjpc$1@dont-email.me>
    <r257lipb348csh8otghajpb8v2ds1707lj@4ax.com> <uj063l$19nj8$1@dont-email.me>
    <uj31uf$1rfa0$1@dont-email.me> <uj344f$1rrht$2@dont-email.me>
    MIME-Version: 1.0
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit
    Injection-Date: Thu, 16 Nov 2023 11:04:45 -0000 (UTC)
    Injection-Info: dont-email.me; posting-host="2da3cb937c29cf8f833fe24ff58e8472";
    logging-data="2359703"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/IFdYOqOzG1T5eNz35gQA9vAy59ZdLiaksc7+7MmwFxw=="
    User-Agent: Mozilla Thunderbird
    Cancel-Lock: sha1:au5/1zZ5I+98LcxotmoM3egeSoI=
    In-Reply-To: <uj344f$1rrht$2@dont-email.me>
    Content-Language: en-GB
    X-Received-Bytes: 2145

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to Don Y on Thu Nov 16 13:53:22 2023
    XPost: free.spam

    The arsehole Don Y <blockedofcourse@foo.invalid> persisting in being an Off-topic troll...

    --
    Don Y <blockedofcourse@foo.invalid> wrote:

    Path: not-for-mail
    From: Don Y <blockedofcourse@foo.invalid>
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did
    nothing, lawsuit claims
    Date: Thu, 16 Nov 2023 05:56:49 -0700
    Organization: A noiseless patient Spider
    Lines: 30
    Message-ID: <uj53ip$291os$3@dont-email.me>
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com>
    <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitopl$r9m7$1@dont-email.me>
    <cu47li9f5gri305iafvffnmao9aurkvi2m@4ax.com>
    <b5d488fb-4cae-41de-a003-0f823a6fd2b2n@googlegroups.com>
    <48eali9c9lp841616piphv6jc2tp16rpuj@4ax.com>
    <rk2cli5krra78uhajm05oh1eorag933tq5@4ax.com>
    MIME-Version: 1.0
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit
    Injection-Date: Thu, 16 Nov 2023 12:56:57 -0000 (UTC)
    Injection-Info: dont-email.me; posting-host="1b553efc9136b6b985c933d38aaa2701";
    logging-data="2393884"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+IlJzOnF+PQrLHbM/bPGlo"
    User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
    Thunderbird/102.2.2
    Cancel-Lock: sha1:NOIS8LYBKqfi2cNHR5cbLtV0Pq0=
    In-Reply-To: <rk2cli5krra78uhajm05oh1eorag933tq5@4ax.com>
    Content-Language: en-US
    X-Received-Bytes: 2827

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to upsidedown@downunder.com on Thu Nov 16 08:10:39 2023
    On Thu, 16 Nov 2023 14:44:36 +0200, upsidedown@downunder.com wrote:

    On Wed, 15 Nov 2023 13:48:30 -0800, john larkin <jl@650pot.com> wrote:

    On Wed, 15 Nov 2023 09:39:05 -0800 (PST), whit3rd <whit3rd@gmail.com> >>wrote:

    On Tuesday, November 14, 2023 at 7:37:37?AM UTC-8, John Larkin wrote:
    On Mon, 13 Nov 2023 18:09:57 -0000 (UTC), Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    John Larkin <j...@997PotHill.com> wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fred...@gmail.com> wrote:

    Some day we will be free of x86 and freed from bloated insecure
    operating systems.

    Well, we can go back to banging rocks together anytime we like. ;)

    Or put 1024 risc processors on a chip and manage them rationally.

    We cannot rationally manage a congress of a few hundred when they're >>>humans, why do you expect we can handle intercommunicating
    'risc processors' either? The experience with humans is
    well documented, hasn't changed much since

    <https://archive.org/details/mackay-popular-delusions>

    So, to the idea of rationally managing 1024 risk processors, I will add >>>"Imagine a Beowulf cluster of those..."

    Such number of processors might be usable e.g. for Monte Carlo
    simulations, but quite useless for random computer use.


    I disagree. One CPU can run the top-level OS. One CPU can be the file
    server. One can be the internet interface. And so on. Some can run
    downloaded buggy applications, but with absolute protections.

    What's wrong with that?

    The trick is to stop thinking about sharing one giant complex
    multitasked CPU to do everything, and making that safe... which seems
    to be impossible. CPUs have become cheap and software has become
    bloated.

    I wish that virtual memory had never been invented. And that Intel had
    stuck to making DRAM.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to John Larkin on Thu Nov 16 08:24:51 2023
    On Thursday, November 16, 2023 at 8:11:24 AM UTC-8, John Larkin wrote:
    On Thu, 16 Nov 2023 14:44:36 +0200, upsid...@downunder.com wrote:

    On Wed, 15 Nov 2023 13:48:30 -0800, john larkin <j...@650pot.com> wrote:

    On Wed, 15 Nov 2023 09:39:05 -0800 (PST), whit3rd <whi...@gmail.com> >>wrote:

    On Tuesday, November 14, 2023 at 7:37:37?AM UTC-8, John Larkin wrote: >>>> On Mon, 13 Nov 2023 18:09:57 -0000 (UTC), Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    John Larkin <j...@997PotHill.com> wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fred...@gmail.com> wrote:

    Some day we will be free of x86 and freed from bloated insecure
    operating systems.

    Well, we can go back to banging rocks together anytime we like. ;)

    Or put 1024 risc processors on a chip and manage them rationally.

    We cannot rationally manage a congress of a few hundred when they're >>>humans, why do you expect we can handle intercommunicating
    'risc processors' either? The experience with humans is
    well documented, hasn't changed much since

    <https://archive.org/details/mackay-popular-delusions>

    So, to the idea of rationally managing 1024 risk processors, I will add >>>"Imagine a Beowulf cluster of those..."

    Such number of processors might be usable e.g. for Monte Carlo >simulations, but quite useless for random computer use.
    I disagree. One CPU can run the top-level OS. One CPU can be the file server. One can be the internet interface. And so on. Some can run downloaded buggy applications, but with absolute protections.

    What's wrong with that?

    Well, to start, the economics of having that many mechanisms, and
    the 'top-level' structure encouraging a single point of failure.
    The real issue, though, is that bugs fall through the cracks
    in folks' mental models of what their tools do.

    There's lots of users of SPICE that don't understand the
    matrix solution of simultaneous equations and Kirchhoff's rules
    for setting up those equations. That implies that they
    don't understand SPICE, either. The human at the top
    isn't really in control, when that happens.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to '''newspam'''@nonad.co.uk on Thu Nov 16 08:47:56 2023
    On Thu, 16 Nov 2023 11:17:04 +0000, Martin Brown
    <'''newspam'''@nonad.co.uk> wrote:

    On 15/11/2023 22:01, john larkin wrote:
    On Wed, 15 Nov 2023 18:16:42 +0000, Martin Brown
    <'''newspam'''@nonad.co.uk> wrote:

    On 14/11/2023 16:09, Dimiter_Popoff wrote:

    I can swallow that as I use it for reading pdf-s and browsing,
    plus the occasional ltspice.

    The only gotcha I can see is that every version requires more ram and
    occupies more disk space but both are cheap and fast today.

    Win10 is going officially unsupported sometime soon in 2025. I expect it >>> will get a reprieve or there will be a global malware catastrophe.

    https://www.zdnet.com/article/microsoft-windows-10-is-a-security-disaster-waiting-to-happen/

    Win11 main advantage for me is that it understands performance cores on
    the more recent Intel CPUs. That is a kludge in Win10.

    The last truly dreadful edition of windows was Win8.
    Think Picasso on a bad acid trip and you will not be too far off.

    I miss Win7, but most of the machines have died.

    Win7 will run on modern CPUs although I wouldn't recommend it unless you >either have a damn good impenetrable firewall (plenty of ancient big >scientific instruments still work that way 20 year design life -
    although clever virtualisation of antique hardware environments are
    getting around that).

    You can extract the original license key from old kit with suitable
    tools - although the license server may now have disappeared so you
    cannot register new hardware to run Win7. It means that certain
    motherboards have premium prices in the second hand market.

    You can make Win11 look enough like WIn7 to be acceptable.

    Win11 got terrible user reviews, but update 23H2 fixed a lot of
    stupidities. It's almost tolerable, after a lot of tweaks.

    It runs Firefox, LT Spice, PADS, VLC, Crimson, Agent, Irfanview, and a
    bunch of my old compiled PowerBasic programs. And seems reliable so
    far.

    None of those are particularly taxing. The big change was when 32bit
    code (and before that 16bit) became unsupported.
    That broke a lot of major players installers like Adobe Photoshop and
    others.
    You just like to whinge and whine about Intel and Microsoft.

    You just like to insult people.

    Design something. You'll feel better.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to whit3rd@gmail.com on Thu Nov 16 17:25:15 2023
    XPost: free.spam

    The arsehole whit3rd <whit3rd@gmail.com> persisting in being an Off-topic troll...

    --
    whit3rd <whit3rd@gmail.com> wrote:

    X-Received: by 2002:a0c:e84b:0:b0:66d:365:a767 with SMTP id l11-20020a0ce84b000000b0066d0365a767mr191203qvo.8.1700151892835;
    Thu, 16 Nov 2023 08:24:52 -0800 (PST)
    X-Received: by 2002:a17:90a:e54b:b0:280:7ea4:7d04 with SMTP id
    ei11-20020a17090ae54b00b002807ea47d04mr4711086pjb.6.1700151892463; Thu, 16
    Nov 2023 08:24:52 -0800 (PST)
    Path: not-for-mail
    Newsgroups: sci.electronics.design
    Date: Thu, 16 Nov 2023 08:24:51 -0800 (PST)
    In-Reply-To: <eafcli95b5qcateh2h07f35rg1fqriqoi0@4ax.com>
    Injection-Info: google-groups.googlegroups.com; posting-host=209.221.140.126; posting-account=vKQm_QoAAADOaDCYsqOFDAW8NJ8sFHoE
    NNTP-Posting-Host: 209.221.140.126
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com>
    <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitopl$r9m7$1@dont-email.me>
    <cu47li9f5gri305iafvffnmao9aurkvi2m@4ax.com> <b5d488fb-4cae-41de-a003-0f823a6fd2b2n@googlegroups.com>
    <48eali9c9lp841616piphv6jc2tp16rpuj@4ax.com> <rk2cli5krra78uhajm05oh1eorag933tq5@4ax.com>
    <eafcli95b5qcateh2h07f35rg1fqriqoi0@4ax.com>
    User-Agent: G2/1.0
    MIME-Version: 1.0
    Message-ID: <6bfde742-69df-4eee-ad3e-6d047c573d2en@googlegroups.com>
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did
    nothing, lawsuit claims
    From: whit3rd <whit3rd@gmail.com>
    Injection-Date: Thu, 16 Nov 2023 16:24:52 +0000
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable
    X-Received-Bytes: 4071

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to John Larkin on Thu Nov 16 17:25:22 2023
    XPost: free.spam

    The arsehole John Larkin <jl@997PotHill.com> persisting in being an Off-topic troll...

    --
    John Larkin <jl@997PotHill.com> wrote:

    Path: not-for-mail
    NNTP-Posting-Date: Thu, 16 Nov 2023 16:48:24 +0000
    From: John Larkin <jl@997PotHill.com>
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did nothing, lawsuit claims
    Date: Thu, 16 Nov 2023 08:47:56 -0800
    Organization: Highland Tech
    Reply-To: xx@yy.com
    Message-ID: <1shclip7hihi6amkbe8bjgpnlsr00jt3cb@4ax.com>
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com> <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitqvi$rjpc$1@dont-email.me> <r257lipb348csh8otghajpb8v2ds1707lj@4ax.com> <uj063l$19nj8$1@dont-email.me> <uj31uf$1rfa0$1@dont-email.me> <
    kifalit7mrjn9fcieugqi3vibtbe83lfbj@4ax.com> <uj4tnm$284bt$2@dont-email.me>
    X-Newsreader: Forte Agent 3.1/32.783
    MIME-Version: 1.0
    Content-Type: text/plain; charset=us-ascii
    Content-Transfer-Encoding: 7bit
    Lines: 58
    X-Trace: sv3-We7GOh7itvoqfAnN14Lz7c4PI6OPo5wCT1eJFV5qBGhWOoMrTBu8Z970Kr162JOPKOn/G29o6p5sn8c!BuLe7G14h4bsvg22tabTmxKEMp5+BK/x4QfxyxicuPmCXnc1ETvnkbMMLTsGmWROZ6abpqKt1+zc!IjluJQ==
    X-Complaints-To: www.supernews.com/docs/abuse.html
    X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
    X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
    X-Postfilter: 1.3.40
    Bytes: 3826
    X-Received-Bytes: 3964

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From john larkin@21:1/5 to All on Thu Nov 16 10:22:06 2023
    On Thu, 16 Nov 2023 08:24:51 -0800 (PST), whit3rd <whit3rd@gmail.com>
    wrote:

    On Thursday, November 16, 2023 at 8:11:24?AM UTC-8, John Larkin wrote:
    On Thu, 16 Nov 2023 14:44:36 +0200, upsid...@downunder.com wrote:

    On Wed, 15 Nov 2023 13:48:30 -0800, john larkin <j...@650pot.com> wrote:

    On Wed, 15 Nov 2023 09:39:05 -0800 (PST), whit3rd <whi...@gmail.com>
    wrote:

    On Tuesday, November 14, 2023 at 7:37:37?AM UTC-8, John Larkin wrote:
    On Mon, 13 Nov 2023 18:09:57 -0000 (UTC), Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    John Larkin <j...@997PotHill.com> wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fred...@gmail.com> wrote:

    Some day we will be free of x86 and freed from bloated insecure
    operating systems.

    Well, we can go back to banging rocks together anytime we like. ;)

    Or put 1024 risc processors on a chip and manage them rationally.

    We cannot rationally manage a congress of a few hundred when they're
    humans, why do you expect we can handle intercommunicating
    'risc processors' either? The experience with humans is
    well documented, hasn't changed much since

    <https://archive.org/details/mackay-popular-delusions>

    So, to the idea of rationally managing 1024 risk processors, I will add >> >>>"Imagine a Beowulf cluster of those..."

    Such number of processors might be usable e.g. for Monte Carlo
    simulations, but quite useless for random computer use.
    I disagree. One CPU can run the top-level OS. One CPU can be the file
    server. One can be the internet interface. And so on. Some can run
    downloaded buggy applications, but with absolute protections.

    What's wrong with that?

    Well, to start, the economics of having that many mechanisms, and
    the 'top-level' structure encouraging a single point of failure.
    The real issue, though, is that bugs fall through the cracks
    in folks' mental models of what their tools do.

    There's lots of users of SPICE that don't understand the
    matrix solution of simultaneous equations and Kirchhoff's rules
    for setting up those equations. That implies that they
    don't understand SPICE, either. The human at the top
    isn't really in control, when that happens.

    I don't need to understand the code inside Spice. I just need to use
    it.

    I don't automatically trust a Spice sim anyhow. As Mike E famously
    said, the main function of Spice is to train your instincts.

    I recently added a 1 ohm resistor to a Spice model, one end grounded
    and the other just open. It decreased sim time by a factor of
    thousands. Explain that for us please.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to john larkin on Thu Nov 16 19:55:09 2023
    XPost: free.spam

    The idiot john larkin <jl@650pot.com> persisting in being an Off-topic troll...

    --
    john larkin <jl@650pot.com> wrote:

    Path: not-for-mail
    NNTP-Posting-Date: Thu, 16 Nov 2023 18:22:06 +0000
    From: john larkin <jl@650pot.com>
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did nothing, lawsuit claims
    Date: Thu, 16 Nov 2023 10:22:06 -0800
    Message-ID: <36nclil8bnf2bbdkg1damb71r86v4fh95h@4ax.com>
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com> <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitopl$r9m7$1@dont-email.me> <cu47li9f5gri305iafvffnmao9aurkvi2m@4ax.com> <b5d488fb-4cae-41de-a003-0f823a6fd2b2n@googlegroups.com> <
    48eali9c9lp841616piphv6jc2tp16rpuj@4ax.com> <rk2cli5krra78uhajm05oh1eorag933tq5@4ax.com> <eafcli95b5qcateh2h07f35rg1fqriqoi0@4ax.com> <6bfde742-69df-4eee-ad3e-6d047c573d2en@googlegroups.com>
    User-Agent: ForteAgent/8.00.32.1272
    MIME-Version: 1.0
    Content-Type: text/plain; charset=us-ascii
    Content-Transfer-Encoding: 7bit
    Lines: 65
    X-Trace: sv3-81XzLwQkL4PQCvdBSoSOcdbCev+aCI/oQxXDHfBY6mkZ1aY50vXD44Jby3t27mtRsWqwHLpoOWEmEmp!kg2dPzlr4y4x9KvGfQ21Tc7LeLtKhz4A6xHkI7thWz+3//2dE6QH2CxTXei6CFBr8mDRVUBNZLTX!8Rd6LA==
    X-Complaints-To: www.supernews.com/docs/abuse.html
    X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
    X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
    X-Postfilter: 1.3.40
    Bytes: 4328
    X-Received-Bytes: 4466

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to All on Thu Nov 16 12:59:26 2023
    On 11/16/2023 9:24 AM, whit3rd wrote:
    Well, to start, the economics of having that many mechanisms, and
    the 'top-level' structure encouraging a single point of failure.

    The problem with multiple processors -- even colocated on a single
    die -- is that they inevitably need to communicate with each-other
    and/or some sort of executive. Those costs dominate the run-time
    expense of the system.

    Organizing that on a die for large numbers of processors is
    difficult -- there are only so many layers that you can employ!

    If you rely on a mesh, then you need redundancy so no one DEAD
    processor tears a hole in the fabric.

    Busses, similarly, have to be designed so no single fault
    busies the whole bus. (We designed some automation years ago
    that ran a bus out to the field --- hundreds of feet from the
    controller. To ensure a single node HARDWARE failure couldn't
    bodge the comms to all of the field nodes, we included provisions
    to superimpose a high voltage on the lines to toast fuses in any
    nodes that were "stuck" on the line.)

    And, where's the *field* in all this? Another chip?? How
    do you ensure processor X (but not Y or Z) can access some
    portion of the field without also exposing it to others?

    And, any hardware that you put in for comms makes a nasty
    assumption regarding *policy* (as the algorithms governing
    it would have to be in silicon); hardware should only ever
    provide *mechanism*... *policy* should be left to the system
    designer.

    The real issue, though, is that bugs fall through the cracks
    in folks' mental models of what their tools do.

    Yes. Especially when trying to partition a design that
    *could* use shitloads of processors.

    I've tackled that by treating each node (4 cores) as a separate
    primary application -- defined by it's I/Os. So, I can forget
    (ignore) the rest of the system while working on THAT design.
    And, because I exert strict control over comms between nodes
    (and tasks within nodes), I can be assured that nothing unintended
    can dick with my activities, there.

    There's lots of users of SPICE that don't understand the
    matrix solution of simultaneous equations and Kirchhoff's rules
    for setting up those equations. That implies that they
    don't understand SPICE, either. The human at the top
    isn't really in control, when that happens.

    That's true of a lot of tools. Most folks who write code
    can't imagine the opcodes that will actually be executed
    nor how the activity on the busses will unfold. It's a
    reason you find folks struggling to write even simple
    hardware drivers.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to John Larkin on Thu Nov 16 15:04:31 2023
    On 2023-11-16 11:10, John Larkin wrote:
    On Thu, 16 Nov 2023 14:44:36 +0200, upsidedown@downunder.com wrote:

    On Wed, 15 Nov 2023 13:48:30 -0800, john larkin <jl@650pot.com> wrote:

    On Wed, 15 Nov 2023 09:39:05 -0800 (PST), whit3rd <whit3rd@gmail.com>
    wrote:

    On Tuesday, November 14, 2023 at 7:37:37?AM UTC-8, John Larkin wrote: >>>>> On Mon, 13 Nov 2023 18:09:57 -0000 (UTC), Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    John Larkin <j...@997PotHill.com> wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fred...@gmail.com> wrote:

    Some day we will be free of x86 and freed from bloated insecure
    operating systems.

    Well, we can go back to banging rocks together anytime we like. ;)

    Or put 1024 risc processors on a chip and manage them rationally.

    We cannot rationally manage a congress of a few hundred when they're
    humans, why do you expect we can handle intercommunicating
    'risc processors' either? The experience with humans is
    well documented, hasn't changed much since

    <https://archive.org/details/mackay-popular-delusions>

    So, to the idea of rationally managing 1024 risk processors, I will add >>>> "Imagine a Beowulf cluster of those..."

    Such number of processors might be usable e.g. for Monte Carlo
    simulations, but quite useless for random computer use.


    I disagree. One CPU can run the top-level OS. One CPU can be the file
    server. One can be the internet interface. And so on. Some can run
    downloaded buggy applications, but with absolute protections.

    What's wrong with that?

    You're making a lot of counterfactual assumptions here. For instance:

    1. No single task needs more than 0.1% of the capacity of the chip.

    2. Similarly, there is no need for hardware acceleration, or else you
    can have hundreds of FPUs, for instance, each big enough to handle a
    nice fast SPICE simulation (because by hypothesis they can't cooperate).

    3. Interprocess communication, e.g. shared memory or nonlocally-coherent
    cache, is not important.

    4. You can have enough interconnection hardware for hundreds of cores to
    access shared resources such as main memory, disk, graphics memory, USB,
    mouse & keyboard, and so on, completely independently.

    5. Those shared resources are completely immune to compromise themselves.

    And on and on.

    What you're describing is more like 1024 elevator controllers in a bag,
    with no elevators attached. It wouldn't be a useful box for general use.

    The trick is to stop thinking about sharing one giant complex
    multitasked CPU to do everything, and making that safe... which seems
    to be impossible. CPUs have become cheap and software has become
    bloated.

    I wish that virtual memory had never been invented. And that Intel had
    stuck to making DRAM.

    Cheers

    Phil Hobbs
    (Former optical interconnect person)

    --
    Dr Philip C D Hobbs
    Principal Consultant
    ElectroOptical Innovations LLC / Hobbs ElectroOptics
    Optics, Electro-optics, Photonics, Analog Electronics
    Briarcliff Manor NY 10510

    http://electrooptical.net
    http://hobbs-eo.com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Thu Nov 16 14:35:23 2023
    On Thu, 16 Nov 2023 15:04:31 -0500, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    On 2023-11-16 11:10, John Larkin wrote:
    On Thu, 16 Nov 2023 14:44:36 +0200, upsidedown@downunder.com wrote:

    On Wed, 15 Nov 2023 13:48:30 -0800, john larkin <jl@650pot.com> wrote:

    On Wed, 15 Nov 2023 09:39:05 -0800 (PST), whit3rd <whit3rd@gmail.com>
    wrote:

    On Tuesday, November 14, 2023 at 7:37:37?AM UTC-8, John Larkin wrote: >>>>>> On Mon, 13 Nov 2023 18:09:57 -0000 (UTC), Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    John Larkin <j...@997PotHill.com> wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fred...@gmail.com> wrote:

    Some day we will be free of x86 and freed from bloated insecure >>>>>>>> operating systems.

    Well, we can go back to banging rocks together anytime we like. ;) >>>>>
    Or put 1024 risc processors on a chip and manage them rationally.

    We cannot rationally manage a congress of a few hundred when they're >>>>> humans, why do you expect we can handle intercommunicating
    'risc processors' either? The experience with humans is
    well documented, hasn't changed much since

    <https://archive.org/details/mackay-popular-delusions>

    So, to the idea of rationally managing 1024 risk processors, I will add >>>>> "Imagine a Beowulf cluster of those..."

    Such number of processors might be usable e.g. for Monte Carlo
    simulations, but quite useless for random computer use.


    I disagree. One CPU can run the top-level OS. One CPU can be the file
    server. One can be the internet interface. And so on. Some can run
    downloaded buggy applications, but with absolute protections.

    What's wrong with that?

    You're making a lot of counterfactual assumptions here. For instance:

    1. No single task needs more than 0.1% of the capacity of the chip.

    I never said that.


    2. Similarly, there is no need for hardware acceleration, or else you
    can have hundreds of FPUs, for instance, each big enough to handle a
    nice fast SPICE simulation (because by hypothesis they can't cooperate).

    Spice already uses multiple CPUs. There's no reason that some CPUs
    can't work together, with shared memory. The OS can set that up, still
    with absolute hardware protections.


    3. Interprocess communication, e.g. shared memory or nonlocally-coherent >cache, is not important.

    Of course it's important. Just do it right.


    4. You can have enough interconnection hardware for hundreds of cores to >access shared resources such as main memory, disk, graphics memory, USB, >mouse & keyboard, and so on, completely independently.

    Most service-type CPUs (drivers, file servers, internet server) can be
    accessed by an application program any number of ways. Bloated OSs do
    that now, just very badly.


    5. Those shared resources are completely immune to compromise themselves.

    A driver program can be very carefully designed and tested and
    ultimately debugged. After that, no other process can corrupt it
    because the hardware won't allow it.

    It's interesting how many bugs I see in procedural code, and how few I
    see in FPGA programs. We are a lot better at hardware design than
    software sloshing.


    And on and on.

    What you're describing is more like 1024 elevator controllers in a bag,
    with no elevators attached. It wouldn't be a useful box for general use.

    It would be wonderful as a general-purpose PC.


    The trick is to stop thinking about sharing one giant complex
    multitasked CPU to do everything, and making that safe... which seems
    to be impossible. CPUs have become cheap and software has become
    bloated.

    I wish that virtual memory had never been invented. And that Intel had
    stuck to making DRAM.

    Cheers

    Phil Hobbs
    (Former optical interconnect person)

    So, in 2053, we will be running a 64-core 150 GHz x86 with terabytes
    of dram. The OS will fill up all of the dram so we'll still be
    thrashing. Figure maybe 60 million page faults per second.

    The OS will download and install an update every hour and cold start
    will take a full day. It will crash a few times per day. Microsoft
    will insist on your house as collateral to order a subscription to
    Windows 473.

    Unless someone has a better idea. What's yours?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeroen Belleman@21:1/5 to john larkin on Thu Nov 16 23:29:56 2023
    On 11/16/23 19:22, john larkin wrote:
    On Thu, 16 Nov 2023 08:24:51 -0800 (PST), whit3rd <whit3rd@gmail.com>
    wrote:

    On Thursday, November 16, 2023 at 8:11:24?AM UTC-8, John Larkin wrote:
    On Thu, 16 Nov 2023 14:44:36 +0200, upsid...@downunder.com wrote:

    On Wed, 15 Nov 2023 13:48:30 -0800, john larkin <j...@650pot.com> wrote: >>>>
    On Wed, 15 Nov 2023 09:39:05 -0800 (PST), whit3rd <whi...@gmail.com> >>>>> wrote:

    On Tuesday, November 14, 2023 at 7:37:37?AM UTC-8, John Larkin wrote: >>>>>>> On Mon, 13 Nov 2023 18:09:57 -0000 (UTC), Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    John Larkin <j...@997PotHill.com> wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fred...@gmail.com> wrote:

    Some day we will be free of x86 and freed from bloated insecure >>>>>>>>> operating systems.

    Well, we can go back to banging rocks together anytime we like. ;) >>>>>>
    Or put 1024 risc processors on a chip and manage them rationally. >>>>>>
    We cannot rationally manage a congress of a few hundred when they're >>>>>> humans, why do you expect we can handle intercommunicating
    'risc processors' either? The experience with humans is
    well documented, hasn't changed much since

    <https://archive.org/details/mackay-popular-delusions>

    So, to the idea of rationally managing 1024 risk processors, I will add >>>>>> "Imagine a Beowulf cluster of those..."

    Such number of processors might be usable e.g. for Monte Carlo
    simulations, but quite useless for random computer use.
    I disagree. One CPU can run the top-level OS. One CPU can be the file
    server. One can be the internet interface. And so on. Some can run
    downloaded buggy applications, but with absolute protections.

    What's wrong with that?

    Well, to start, the economics of having that many mechanisms, and
    the 'top-level' structure encouraging a single point of failure.
    The real issue, though, is that bugs fall through the cracks
    in folks' mental models of what their tools do.

    There's lots of users of SPICE that don't understand the
    matrix solution of simultaneous equations and Kirchhoff's rules
    for setting up those equations. That implies that they
    don't understand SPICE, either. The human at the top
    isn't really in control, when that happens.

    I don't need to understand the code inside Spice. I just need to use
    it.

    I don't automatically trust a Spice sim anyhow. As Mike E famously
    said, the main function of Spice is to train your instincts.

    I recently added a 1 ohm resistor to a Spice model, one end grounded
    and the other just open. It decreased sim time by a factor of
    thousands. Explain that for us please.


    You probably had something dodgy in your circuit, like a node
    without DC path, a loop with zero resistance, or a lossless
    resonator.

    Jeroen Belleman

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Thu Nov 16 15:07:16 2023
    torsdag den 16. november 2023 kl. 23.36.06 UTC+1 skrev John Larkin:
    On Thu, 16 Nov 2023 15:04:31 -0500, Phil Hobbs <pcdhSpamM...@electrooptical.net> wrote:

    On 2023-11-16 11:10, John Larkin wrote:
    On Thu, 16 Nov 2023 14:44:36 +0200, upsid...@downunder.com wrote:

    On Wed, 15 Nov 2023 13:48:30 -0800, john larkin <j...@650pot.com> wrote: >>>
    On Wed, 15 Nov 2023 09:39:05 -0800 (PST), whit3rd <whi...@gmail.com> >>>> wrote:

    On Tuesday, November 14, 2023 at 7:37:37?AM UTC-8, John Larkin wrote: >>>>>> On Mon, 13 Nov 2023 18:09:57 -0000 (UTC), Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    John Larkin <j...@997PotHill.com> wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fred...@gmail.com> wrote:

    Some day we will be free of x86 and freed from bloated insecure >>>>>>>> operating systems.

    Well, we can go back to banging rocks together anytime we like. ;) >>>>>
    Or put 1024 risc processors on a chip and manage them rationally. >>>>>
    We cannot rationally manage a congress of a few hundred when they're >>>>> humans, why do you expect we can handle intercommunicating
    'risc processors' either? The experience with humans is
    well documented, hasn't changed much since

    <https://archive.org/details/mackay-popular-delusions>

    So, to the idea of rationally managing 1024 risk processors, I will add >>>>> "Imagine a Beowulf cluster of those..."

    Such number of processors might be usable e.g. for Monte Carlo
    simulations, but quite useless for random computer use.


    I disagree. One CPU can run the top-level OS. One CPU can be the file
    server. One can be the internet interface. And so on. Some can run
    downloaded buggy applications, but with absolute protections.

    What's wrong with that?

    You're making a lot of counterfactual assumptions here. For instance:

    1. No single task needs more than 0.1% of the capacity of the chip.
    I never said that.

    2. Similarly, there is no need for hardware acceleration, or else you
    can have hundreds of FPUs, for instance, each big enough to handle a
    nice fast SPICE simulation (because by hypothesis they can't cooperate). Spice already uses multiple CPUs. There's no reason that some CPUs
    can't work together, with shared memory. The OS can set that up, still
    with absolute hardware protections.

    3. Interprocess communication, e.g. shared memory or nonlocally-coherent >cache, is not important.
    Of course it's important. Just do it right.

    4. You can have enough interconnection hardware for hundreds of cores to >access shared resources such as main memory, disk, graphics memory, USB, >mouse & keyboard, and so on, completely independently.
    Most service-type CPUs (drivers, file servers, internet server) can be accessed by an application program any number of ways. Bloated OSs do
    that now, just very badly.

    5. Those shared resources are completely immune to compromise themselves.
    A driver program can be very carefully designed and tested and
    ultimately debugged. After that, no other process can corrupt it
    because the hardware won't allow it.

    It's interesting how many bugs I see in procedural code, and how few I
    see in FPGA programs. We are a lot better at hardware design than
    software sloshing.

    And on and on.

    What you're describing is more like 1024 elevator controllers in a bag, >with no elevators attached. It wouldn't be a useful box for general use.
    It would be wonderful as a general-purpose PC.

    The trick is to stop thinking about sharing one giant complex
    multitasked CPU to do everything, and making that safe... which seems
    to be impossible. CPUs have become cheap and software has become
    bloated.

    I wish that virtual memory had never been invented. And that Intel had
    stuck to making DRAM.

    Cheers

    Phil Hobbs
    (Former optical interconnect person)
    So, in 2053, we will be running a 64-core 150 GHz x86

    the first 3GHz came out +20 years ago and most of them are still ~3GHz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to jeroen@nospam.please on Thu Nov 16 15:52:56 2023
    On Thu, 16 Nov 2023 23:29:56 +0100, Jeroen Belleman
    <jeroen@nospam.please> wrote:

    On 11/16/23 19:22, john larkin wrote:
    On Thu, 16 Nov 2023 08:24:51 -0800 (PST), whit3rd <whit3rd@gmail.com>
    wrote:

    On Thursday, November 16, 2023 at 8:11:24?AM UTC-8, John Larkin wrote:
    On Thu, 16 Nov 2023 14:44:36 +0200, upsid...@downunder.com wrote:

    On Wed, 15 Nov 2023 13:48:30 -0800, john larkin <j...@650pot.com> wrote: >>>>>
    On Wed, 15 Nov 2023 09:39:05 -0800 (PST), whit3rd <whi...@gmail.com> >>>>>> wrote:

    On Tuesday, November 14, 2023 at 7:37:37?AM UTC-8, John Larkin wrote: >>>>>>>> On Mon, 13 Nov 2023 18:09:57 -0000 (UTC), Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    John Larkin <j...@997PotHill.com> wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fred...@gmail.com> wrote:

    Some day we will be free of x86 and freed from bloated insecure >>>>>>>>>> operating systems.

    Well, we can go back to banging rocks together anytime we like. ;) >>>>>>>
    Or put 1024 risc processors on a chip and manage them rationally. >>>>>>>
    We cannot rationally manage a congress of a few hundred when they're >>>>>>> humans, why do you expect we can handle intercommunicating
    'risc processors' either? The experience with humans is
    well documented, hasn't changed much since

    <https://archive.org/details/mackay-popular-delusions>

    So, to the idea of rationally managing 1024 risk processors, I will add >>>>>>> "Imagine a Beowulf cluster of those..."

    Such number of processors might be usable e.g. for Monte Carlo
    simulations, but quite useless for random computer use.
    I disagree. One CPU can run the top-level OS. One CPU can be the file
    server. One can be the internet interface. And so on. Some can run
    downloaded buggy applications, but with absolute protections.

    What's wrong with that?

    Well, to start, the economics of having that many mechanisms, and
    the 'top-level' structure encouraging a single point of failure.
    The real issue, though, is that bugs fall through the cracks
    in folks' mental models of what their tools do.

    There's lots of users of SPICE that don't understand the
    matrix solution of simultaneous equations and Kirchhoff's rules
    for setting up those equations. That implies that they
    don't understand SPICE, either. The human at the top
    isn't really in control, when that happens.

    I don't need to understand the code inside Spice. I just need to use
    it.

    I don't automatically trust a Spice sim anyhow. As Mike E famously
    said, the main function of Spice is to train your instincts.

    I recently added a 1 ohm resistor to a Spice model, one end grounded
    and the other just open. It decreased sim time by a factor of
    thousands. Explain that for us please.


    You probably had something dodgy in your circuit, like a node
    without DC path, a loop with zero resistance, or a lossless
    resonator.

    Jeroen Belleman

    Why did the 1 ohm resistor fix that?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to John Larkin on Thu Nov 16 19:49:18 2023
    On 2023-11-16 17:35, John Larkin wrote:
    On Thu, 16 Nov 2023 15:04:31 -0500, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    On 2023-11-16 11:10, John Larkin wrote:
    On Thu, 16 Nov 2023 14:44:36 +0200, upsidedown@downunder.com wrote:

    On Wed, 15 Nov 2023 13:48:30 -0800, john larkin <jl@650pot.com> wrote: >>>>
    On Wed, 15 Nov 2023 09:39:05 -0800 (PST), whit3rd <whit3rd@gmail.com> >>>>> wrote:

    On Tuesday, November 14, 2023 at 7:37:37?AM UTC-8, John Larkin wrote: >>>>>>> On Mon, 13 Nov 2023 18:09:57 -0000 (UTC), Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    John Larkin <j...@997PotHill.com> wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fred...@gmail.com> wrote:

    Some day we will be free of x86 and freed from bloated insecure >>>>>>>>> operating systems.

    Well, we can go back to banging rocks together anytime we like. ;) >>>>>>
    Or put 1024 risc processors on a chip and manage them rationally. >>>>>>
    We cannot rationally manage a congress of a few hundred when they're >>>>>> humans, why do you expect we can handle intercommunicating
    'risc processors' either? The experience with humans is
    well documented, hasn't changed much since

    <https://archive.org/details/mackay-popular-delusions>

    So, to the idea of rationally managing 1024 risk processors, I will add >>>>>> "Imagine a Beowulf cluster of those..."

    Such number of processors might be usable e.g. for Monte Carlo
    simulations, but quite useless for random computer use.


    I disagree. One CPU can run the top-level OS. One CPU can be the file
    server. One can be the internet interface. And so on. Some can run
    downloaded buggy applications, but with absolute protections.

    What's wrong with that?

    You're making a lot of counterfactual assumptions here. For instance:

    1. No single task needs more than 0.1% of the capacity of the chip.

    I never said that.

    No, you didn't, but if there's no close cooperation between cores,
    that's where you wind up. To do anything useful together, the cores
    have to be able to share at least memory and a filesystem, which blows
    the safety of your scheme.

    2. Similarly, there is no need for hardware acceleration, or else you
    can have hundreds of FPUs, for instance, each big enough to handle a
    nice fast SPICE simulation (because by hypothesis they can't cooperate).

    Spice already uses multiple CPUs. There's no reason that some CPUs
    can't work together, with shared memory. The OS can set that up, still
    with absolute hardware protections.

    Magic is happening here someplace. You can't keep things separate and
    together at the same time.



    3. Interprocess communication, e.g. shared memory or nonlocally-coherent
    cache, is not important.

    Of course it's important. Just do it right.

    I'd love to hear just how that works without opening the sorts of vulnerabilities you claim to avoid. I certainly don't know how to do it.

    4. You can have enough interconnection hardware for hundreds of cores to
    access shared resources such as main memory, disk, graphics memory, USB,
    mouse & keyboard, and so on, completely independently.

    Most service-type CPUs (drivers, file servers, internet server) can be accessed by an application program any number of ways. Bloated OSs do
    that now, just very badly.

    But you don't specify how it could be done better.

    5. Those shared resources are completely immune to compromise themselves.

    A driver program can be very carefully designed and tested and
    ultimately debugged. After that, no other process can corrupt it
    because the hardware won't allow it.

    But it has to

    It's interesting how many bugs I see in procedural code, and how few I
    see in FPGA programs. We are a lot better at hardware design than
    software sloshing.


    And on and on.

    What you're describing is more like 1024 elevator controllers in a bag,
    with no elevators attached. It wouldn't be a useful box for general use.

    It would be wonderful as a general-purpose PC.

    That's what the earliest massively-parallel enthusiasts thought. Stuff
    from the '80s like the Connection Machine, the Computing Surface, et al.
    Didn't work for beans for general-purpose computing, because there
    aren't good ways to apply fine-grained parallelism to the great majority
    of important problems.

    The trick is to stop thinking about sharing one giant complex
    multitasked CPU to do everything, and making that safe... which seems
    to be impossible. CPUs have become cheap and software has become
    bloated.

    I wish that virtual memory had never been invented. And that Intel had
    stuck to making DRAM.


    So, in 2053, we will be running a 64-core 150 GHz x86 with terabytes
    of dram. The OS will fill up all of the dram so we'll still be
    thrashing. Figure maybe 60 million page faults per second.

    The OS will download and install an update every hour and cold start
    will take a full day. It will crash a few times per day. Microsoft
    will insist on your house as collateral to order a subscription to
    Windows 473.

    Unless someone has a better idea. What's yours?

    I gave up on Windows ages ago, because my masochism circuits are all out
    of commission.

    The box I'm writing this on is my daily-driver Thinkpad 480, running
    Qubes OS version 4.1. It's a Xen distribution that runs everything in
    virtual machines.

    One of the nicest things about it is that almost any VM can be used as a template for *disposable VMs*. A dispVM let me browse like Conan the Barbarian--I don't have to care if it gets pwned, because the whole VM
    it goes away completely when I close the browser.

    At the moment I have ten VMs running. Besides the hypervisor (Dom0)
    there are service VMs for networking, firewall, and USB, two DispVMs
    running different browser sessions, and one each for Usenet, simulation
    (really used mostly for running Windows programs under Wine), one for
    secure storage (which has no networking), and one for general work
    things such as writing books and doing email.

    It's a bit on the heavyweight side, especially because for security
    reasons it virtualizes video, which sucks power. However, it's been
    pretty well bulletproof for the five or six years that I've been using
    it for everything.

    Highly recommended.

    Cheers

    Phil Hobbs


    --
    Dr Philip C D Hobbs
    Principal Consultant
    ElectroOptical Innovations LLC / Hobbs ElectroOptics
    Optics, Electro-optics, Photonics, Analog Electronics
    Briarcliff Manor NY 10510

    http://electrooptical.net
    http://hobbs-eo.com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to Jeroen Belleman on Fri Nov 17 01:18:01 2023
    XPost: free.spam

    The arsehole Jeroen Belleman <jeroen@nospam.please> persisting in being an Off-topic troll...

    --
    Jeroen Belleman <jeroen@nospam.please> wrote:

    Path: not-for-mail
    From: Jeroen Belleman <jeroen@nospam.please>
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did nothing, lawsuit claims
    Date: Thu, 16 Nov 2023 23:29:56 +0100
    Organization: A noiseless patient Spider
    Lines: 72
    Message-ID: <uj654o$2es19$1@dont-email.me>
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com> <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitopl$r9m7$1@dont-email.me> <cu47li9f5gri305iafvffnmao9aurkvi2m@4ax.com> <b5d488fb-4cae-41de-a003-0f823a6fd2b2n@googlegroups.com> <
    48eali9c9lp841616piphv6jc2tp16rpuj@4ax.com> <rk2cli5krra78uhajm05oh1eorag933tq5@4ax.com> <eafcli95b5qcateh2h07f35rg1fqriqoi0@4ax.com> <6bfde742-69df-4eee-ad3e-6d047c573d2en@googlegroups.com> <36nclil8bnf2bbdkg1damb71r86v4fh95h@4ax.com>
    MIME-Version: 1.0
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit
    Injection-Date: Thu, 16 Nov 2023 22:29:47 -0000 (UTC)
    Injection-Info: dont-email.me; posting-host="9633d5a4bd8168b949f9c6636f23adf3"; logging-data="2584617"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/1c4D9TWODNUDGPjjob7os"
    User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0
    Cancel-Lock: sha1:B6BTgowxI0qx8uX9webYIdeVRCQ=
    In-Reply-To: <36nclil8bnf2bbdkg1damb71r86v4fh95h@4ax.com>
    Content-Language: en-US
    X-Received-Bytes: 4683

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to Lasse Langwadt Christensen on Fri Nov 17 01:17:55 2023
    XPost: free.spam

    The idiot Lasse Langwadt Christensen <langwadt@fonz.dk> persisting in being an Off-topic troll...

    --
    Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    X-Received: by 2002:ad4:4701:0:b0:671:2af6:8d60 with SMTP id qb1-20020ad44701000000b006712af68d60mr80207qvb.5.1700176037685;
    Thu, 16 Nov 2023 15:07:17 -0800 (PST)
    X-Received: by 2002:a17:90a:558c:b0:283:98d1:89ee with SMTP id
    c12-20020a17090a558c00b0028398d189eemr66132pji.0.1700176037291; Thu, 16 Nov
    2023 15:07:17 -0800 (PST)
    Path: not-for-mail
    Newsgroups: sci.electronics.design
    Date: Thu, 16 Nov 2023 15:07:16 -0800 (PST)
    In-Reply-To: <r35dli1au3siiieroone1clgvu303t85lf@4ax.com>
    Injection-Info: google-groups.googlegroups.com; posting-host=94.145.228.129; posting-account=mW5JKwkAAAAMyuWOVeLp8yffyAkVx0g7
    NNTP-Posting-Host: 94.145.228.129
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com>
    <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitopl$r9m7$1@dont-email.me>
    <cu47li9f5gri305iafvffnmao9aurkvi2m@4ax.com> <b5d488fb-4cae-41de-a003-0f823a6fd2b2n@googlegroups.com>
    <48eali9c9lp841616piphv6jc2tp16rpuj@4ax.com> <rk2cli5krra78uhajm05oh1eorag933tq5@4ax.com>
    <eafcli95b5qcateh2h07f35rg1fqriqoi0@4ax.com> <62ea37b3-ffd9-fc6b-de7b-894fef274021@electrooptical.net>
    <r35dli1au3siiieroone1clgvu303t85lf@4ax.com>
    User-Agent: G2/1.0
    MIME-Version: 1.0
    Message-ID: <fd3363e6-558f-4ac4-9e7e-74b019f6887an@googlegroups.com>
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did
    nothing, lawsuit claims
    From: Lasse Langwadt Christensen <langwadt@fonz.dk>
    Injection-Date: Thu, 16 Nov 2023 23:07:17 +0000
    Content-Type: text/plain; charset="UTF-8"
    X-Received-Bytes: 6154

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to John Larkin on Fri Nov 17 01:18:07 2023
    XPost: free.spam

    The arsehole John Larkin <jl@997PotHill.com> persisting in being an Off-topic troll...

    --
    John Larkin <jl@997PotHill.com> wrote:

    Path: not-for-mail
    NNTP-Posting-Date: Thu, 16 Nov 2023 23:53:24 +0000
    From: John Larkin <jl@997PotHill.com>
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did nothing, lawsuit claims
    Date: Thu, 16 Nov 2023 15:52:56 -0800
    Organization: Highland Tech
    Reply-To: xx@yy.com
    Message-ID: <1padli5n5v4o67l9lif9hicc0djl7jsd81@4ax.com>
    References: <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitopl$r9m7$1@dont-email.me> <cu47li9f5gri305iafvffnmao9aurkvi2m@4ax.com> <b5d488fb-4cae-41de-a003-0f823a6fd2b2n@googlegroups.com> <48eali9c9lp841616piphv6jc2tp16rpuj@4ax.com> <
    rk2cli5krra78uhajm05oh1eorag933tq5@4ax.com> <eafcli95b5qcateh2h07f35rg1fqriqoi0@4ax.com> <6bfde742-69df-4eee-ad3e-6d047c573d2en@googlegroups.com> <36nclil8bnf2bbdkg1damb71r86v4fh95h@4ax.com> <uj654o$2es19$1@dont-email.me>
    X-Newsreader: Forte Agent 3.1/32.783
    MIME-Version: 1.0
    Content-Type: text/plain; charset=us-ascii
    Content-Transfer-Encoding: 7bit
    Lines: 78
    X-Trace: sv3-NuMrmGta4z0GQxEy0h9ry1Ng+4sozFYy6hEYPrlseE83xeVbf9U4lFi2aVqqBMx+DM6YSO+GdZk1gYy!dljvnCCuMgzB2pOp8He4fslprkJQg+fPUElMyrMH8V60F7jrSELEQUvSBpi7hNDWdUds6OBv4iCX!M4qihA==
    X-Complaints-To: www.supernews.com/docs/abuse.html
    X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
    X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
    X-Postfilter: 1.3.40
    X-Received-Bytes: 5095

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to Don Y on Fri Nov 17 01:18:14 2023
    XPost: free.spam

    The arsehole Don Y <blockedofcourse@foo.invalid> persisting in being an Off-topic troll...

    --
    Don Y <blockedofcourse@foo.invalid> wrote:

    Path: not-for-mail
    From: Don Y <blockedofcourse@foo.invalid>
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did
    nothing, lawsuit claims
    Date: Thu, 16 Nov 2023 12:59:26 -0700
    Organization: A noiseless patient Spider
    Lines: 58
    Message-ID: <uj5sb6$2dh3m$2@dont-email.me>
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com>
    <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitopl$r9m7$1@dont-email.me>
    <cu47li9f5gri305iafvffnmao9aurkvi2m@4ax.com>
    <b5d488fb-4cae-41de-a003-0f823a6fd2b2n@googlegroups.com>
    <48eali9c9lp841616piphv6jc2tp16rpuj@4ax.com>
    <rk2cli5krra78uhajm05oh1eorag933tq5@4ax.com>
    <eafcli95b5qcateh2h07f35rg1fqriqoi0@4ax.com>
    <6bfde742-69df-4eee-ad3e-6d047c573d2en@googlegroups.com>
    MIME-Version: 1.0
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit
    Injection-Date: Thu, 16 Nov 2023 19:59:35 -0000 (UTC)
    Injection-Info: dont-email.me; posting-host="1b553efc9136b6b985c933d38aaa2701";
    logging-data="2540662"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/zeKynlE9vIITt1LWJdF/M"
    User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
    Thunderbird/102.2.2
    Cancel-Lock: sha1:75DlL/jw5epEH1sXPu8Fx8hL0Eo=
    In-Reply-To: <6bfde742-69df-4eee-ad3e-6d047c573d2en@googlegroups.com> Content-Language: en-US
    X-Received-Bytes: 4295

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to Phil Hobbs on Fri Nov 17 01:18:20 2023
    XPost: free.spam

    The arsehole Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> persisting in being an Off-topic troll...

    --
    Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    Path: not-for-mail
    From: Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net>
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did nothing, lawsuit claims
    Date: Thu, 16 Nov 2023 15:04:31 -0500
    Organization: A noiseless patient Spider
    Lines: 88
    Message-ID: <62ea37b3-ffd9-fc6b-de7b-894fef274021@electrooptical.net> References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com> <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitopl$r9m7$1@dont-email.me> <cu47li9f5gri305iafvffnmao9aurkvi2m@4ax.com> <b5d488fb-4cae-41de-a003-0f823a6fd2b2n@googlegroups.com> <
    48eali9c9lp841616piphv6jc2tp16rpuj@4ax.com> <rk2cli5krra78uhajm05oh1eorag933tq5@4ax.com> <eafcli95b5qcateh2h07f35rg1fqriqoi0@4ax.com>
    MIME-Version: 1.0
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit
    Injection-Info: dont-email.me; posting-host="a82f5870083be59ddc2c8df043d40ed5"; logging-data="2542444"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18QcT/6xngEPUhLX4kJg+Tg"
    User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.0
    Cancel-Lock: sha1:Mm4G939F/kBGf8F6kBVLqGaFHBk=
    In-Reply-To: <eafcli95b5qcateh2h07f35rg1fqriqoi0@4ax.com>
    X-Received-Bytes: 4730

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Thu Nov 16 17:37:04 2023
    On Thu, 16 Nov 2023 19:49:18 -0500, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    On 2023-11-16 17:35, John Larkin wrote:
    On Thu, 16 Nov 2023 15:04:31 -0500, Phil Hobbs
    <pcdhSpamMeSenseless@electrooptical.net> wrote:

    On 2023-11-16 11:10, John Larkin wrote:
    On Thu, 16 Nov 2023 14:44:36 +0200, upsidedown@downunder.com wrote:

    On Wed, 15 Nov 2023 13:48:30 -0800, john larkin <jl@650pot.com> wrote: >>>>>
    On Wed, 15 Nov 2023 09:39:05 -0800 (PST), whit3rd <whit3rd@gmail.com> >>>>>> wrote:

    On Tuesday, November 14, 2023 at 7:37:37?AM UTC-8, John Larkin wrote: >>>>>>>> On Mon, 13 Nov 2023 18:09:57 -0000 (UTC), Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    John Larkin <j...@997PotHill.com> wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fred...@gmail.com> wrote:

    Some day we will be free of x86 and freed from bloated insecure >>>>>>>>>> operating systems.

    Well, we can go back to banging rocks together anytime we like. ;) >>>>>>>
    Or put 1024 risc processors on a chip and manage them rationally. >>>>>>>
    We cannot rationally manage a congress of a few hundred when they're >>>>>>> humans, why do you expect we can handle intercommunicating
    'risc processors' either? The experience with humans is
    well documented, hasn't changed much since

    <https://archive.org/details/mackay-popular-delusions>

    So, to the idea of rationally managing 1024 risk processors, I will add >>>>>>> "Imagine a Beowulf cluster of those..."

    Such number of processors might be usable e.g. for Monte Carlo
    simulations, but quite useless for random computer use.


    I disagree. One CPU can run the top-level OS. One CPU can be the file
    server. One can be the internet interface. And so on. Some can run
    downloaded buggy applications, but with absolute protections.

    What's wrong with that?

    You're making a lot of counterfactual assumptions here. For instance:

    1. No single task needs more than 0.1% of the capacity of the chip.

    I never said that.

    No, you didn't, but if there's no close cooperation between cores,
    that's where you wind up. To do anything useful together, the cores
    have to be able to share at least memory and a filesystem, which blows
    the safety of your scheme.

    If one core is a proven secure file server that does nothing else,
    flakey apps would run on other cores and make requests for file
    service, using some hardware-secure interprocess communication means.

    Has Wintel ever made sure that it's impossible to execute in data or
    stack spaces? Or that a shared cache can never be compromised? Do they
    even have a read-only-data mapping mode?

    Wintel's attutude is to execute anything.







    2. Similarly, there is no need for hardware acceleration, or else you
    can have hundreds of FPUs, for instance, each big enough to handle a
    nice fast SPICE simulation (because by hypothesis they can't cooperate).

    Spice already uses multiple CPUs. There's no reason that some CPUs
    can't work together, with shared memory. The OS can set that up, still
    with absolute hardware protections.

    Magic is happening here someplace. You can't keep things separate and >together at the same time.

    Separate processors on the same chip, with hardware protections.
    That's not hard to do if you really want to do it.






    3. Interprocess communication, e.g. shared memory or nonlocally-coherent >>> cache, is not important.

    Of course it's important. Just do it right.

    I'd love to hear just how that works without opening the sorts of >vulnerabilities you claim to avoid. I certainly don't know how to do it.

    Hardware message queues is one way. FPGAs and even RP2040 can do that.
    A file server can examine requests and reject unsafe ones. But no
    queued request can crash the file server, or DMA into someone else's
    space. That's not hard to enforce, as long as you really want to.






    4. You can have enough interconnection hardware for hundreds of cores to >>> access shared resources such as main memory, disk, graphics memory, USB, >>> mouse & keyboard, and so on, completely independently.

    Most service-type CPUs (drivers, file servers, internet server) can be
    accessed by an application program any number of ways. Bloated OSs do
    that now, just very badly.

    But you don't specify how it could be done better.

    Absolute hardware protection and safe inter-processor messaging.
    Sacrifice a bit of speed for safety. 256 GHz-class ARM processors
    should be enough processing power for the average citizen.



    5. Those shared resources are completely immune to compromise themselves. >>
    A driver program can be very carefully designed and tested and
    ultimately debugged. After that, no other process can corrupt it
    because the hardware won't allow it.

    But it has to

    A CPU has to allow itself to be corrupted? OK, it's hopeless.




    It's interesting how many bugs I see in procedural code, and how few I
    see in FPGA programs. We are a lot better at hardware design than
    software sloshing.


    And on and on.

    What you're describing is more like 1024 elevator controllers in a bag,
    with no elevators attached. It wouldn't be a useful box for general use. >>
    It would be wonderful as a general-purpose PC.

    That's what the earliest massively-parallel enthusiasts thought. Stuff
    from the '80s like the Connection Machine, the Computing Surface, et al.
    Didn't work for beans for general-purpose computing, because there
    aren't good ways to apply fine-grained parallelism to the great majority
    of important problems.

    So avoid fine-grained parallelism.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to All on Thu Nov 16 19:11:57 2023
    On Thu, 16 Nov 2023 17:37:04 -0800, John Larkin <jl@997PotHill.com>
    wrote:

    On Thu, 16 Nov 2023 19:49:18 -0500, Phil Hobbs ><pcdhSpamMeSenseless@electrooptical.net> wrote:

    On 2023-11-16 17:35, John Larkin wrote:
    On Thu, 16 Nov 2023 15:04:31 -0500, Phil Hobbs
    <pcdhSpamMeSenseless@electrooptical.net> wrote:

    On 2023-11-16 11:10, John Larkin wrote:
    On Thu, 16 Nov 2023 14:44:36 +0200, upsidedown@downunder.com wrote:

    On Wed, 15 Nov 2023 13:48:30 -0800, john larkin <jl@650pot.com> wrote: >>>>>>
    On Wed, 15 Nov 2023 09:39:05 -0800 (PST), whit3rd <whit3rd@gmail.com> >>>>>>> wrote:

    On Tuesday, November 14, 2023 at 7:37:37?AM UTC-8, John Larkin wrote: >>>>>>>>> On Mon, 13 Nov 2023 18:09:57 -0000 (UTC), Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    John Larkin <j...@997PotHill.com> wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fred...@gmail.com> wrote:

    Some day we will be free of x86 and freed from bloated insecure >>>>>>>>>>> operating systems.

    Well, we can go back to banging rocks together anytime we like. ;) >>>>>>>>
    Or put 1024 risc processors on a chip and manage them rationally. >>>>>>>>
    We cannot rationally manage a congress of a few hundred when they're >>>>>>>> humans, why do you expect we can handle intercommunicating
    'risc processors' either? The experience with humans is
    well documented, hasn't changed much since

    <https://archive.org/details/mackay-popular-delusions>

    So, to the idea of rationally managing 1024 risk processors, I will add
    "Imagine a Beowulf cluster of those..."

    Such number of processors might be usable e.g. for Monte Carlo
    simulations, but quite useless for random computer use.


    I disagree. One CPU can run the top-level OS. One CPU can be the file >>>>> server. One can be the internet interface. And so on. Some can run
    downloaded buggy applications, but with absolute protections.

    What's wrong with that?

    You're making a lot of counterfactual assumptions here. For instance: >>>>
    1. No single task needs more than 0.1% of the capacity of the chip.

    I never said that.

    No, you didn't, but if there's no close cooperation between cores,
    that's where you wind up. To do anything useful together, the cores
    have to be able to share at least memory and a filesystem, which blows
    the safety of your scheme.

    If one core is a proven secure file server that does nothing else,
    flakey apps would run on other cores and make requests for file
    service, using some hardware-secure interprocess communication means.

    Has Wintel ever made sure that it's impossible to execute in data or
    stack spaces? Or that a shared cache can never be compromised? Do they
    even have a read-only-data mapping mode?

    Wintel's attutude is to execute anything.







    2. Similarly, there is no need for hardware acceleration, or else you
    can have hundreds of FPUs, for instance, each big enough to handle a
    nice fast SPICE simulation (because by hypothesis they can't cooperate). >>>
    Spice already uses multiple CPUs. There's no reason that some CPUs
    can't work together, with shared memory. The OS can set that up, still
    with absolute hardware protections.

    Magic is happening here someplace. You can't keep things separate and >>together at the same time.

    Separate processors on the same chip, with hardware protections.
    That's not hard to do if you really want to do it.






    3. Interprocess communication, e.g. shared memory or nonlocally-coherent >>>> cache, is not important.

    Of course it's important. Just do it right.

    I'd love to hear just how that works without opening the sorts of >>vulnerabilities you claim to avoid. I certainly don't know how to do it.

    Hardware message queues is one way. FPGAs and even RP2040 can do that.
    A file server can examine requests and reject unsafe ones. But no
    queued request can crash the file server, or DMA into someone else's
    space. That's not hard to enforce, as long as you really want to.






    4. You can have enough interconnection hardware for hundreds of cores to >>>> access shared resources such as main memory, disk, graphics memory, USB, >>>> mouse & keyboard, and so on, completely independently.

    Most service-type CPUs (drivers, file servers, internet server) can be
    accessed by an application program any number of ways. Bloated OSs do
    that now, just very badly.

    But you don't specify how it could be done better.

    Absolute hardware protection and safe inter-processor messaging.
    Sacrifice a bit of speed for safety. 256 GHz-class ARM processors
    should be enough processing power for the average citizen.



    5. Those shared resources are completely immune to compromise themselves. >>>
    A driver program can be very carefully designed and tested and
    ultimately debugged. After that, no other process can corrupt it
    because the hardware won't allow it.

    But it has to

    A CPU has to allow itself to be corrupted? OK, it's hopeless.




    It's interesting how many bugs I see in procedural code, and how few I
    see in FPGA programs. We are a lot better at hardware design than
    software sloshing.


    And on and on.

    What you're describing is more like 1024 elevator controllers in a bag, >>>> with no elevators attached. It wouldn't be a useful box for general use. >>>
    It would be wonderful as a general-purpose PC.

    That's what the earliest massively-parallel enthusiasts thought. Stuff >>from the '80s like the Connection Machine, the Computing Surface, et al.
    Didn't work for beans for general-purpose computing, because there
    aren't good ways to apply fine-grained parallelism to the great majority
    of important problems.

    So avoid fine-grained parallelism.

    Actually, Ken Olson was right; few people need a computer at home or
    at work.

    Given a several Gbit/sec gen9 universal cell network everywhere, and
    optionally 100 Gbit fiber to your house, why hassle with several
    computers and operating systems and applications? Let Amazon or
    somebody do it all for you. It can throw supercomputer power at LT
    Spice when you want it.

    I'll patent the idea and call it "time sharing."

    A tiny box can connect to the world and drive a monitor and a keyboard
    and USB or whatever. Or use your phone.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Panteltje@21:1/5 to jl@997PotHill.com on Fri Nov 17 06:30:35 2023
    On a sunny day (Thu, 16 Nov 2023 15:52:56 -0800) it happened John Larkin <jl@997PotHill.com> wrote in <1padli5n5v4o67l9lif9hicc0djl7jsd81@4ax.com>:

    On Thu, 16 Nov 2023 23:29:56 +0100, Jeroen Belleman
    <jeroen@nospam.please> wrote:

    On 11/16/23 19:22, john larkin wrote:
    On Thu, 16 Nov 2023 08:24:51 -0800 (PST), whit3rd <whit3rd@gmail.com>
    wrote:

    On Thursday, November 16, 2023 at 8:11:24?AM UTC-8, John Larkin wrote: >>>>> On Thu, 16 Nov 2023 14:44:36 +0200, upsid...@downunder.com wrote:

    On Wed, 15 Nov 2023 13:48:30 -0800, john larkin <j...@650pot.com> wrote: >>>>>>
    On Wed, 15 Nov 2023 09:39:05 -0800 (PST), whit3rd <whi...@gmail.com> >>>>>>> wrote:

    On Tuesday, November 14, 2023 at 7:37:37?AM UTC-8, John Larkin wrote: >>>>>>>>> On Mon, 13 Nov 2023 18:09:57 -0000 (UTC), Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    John Larkin <j...@997PotHill.com> wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fred...@gmail.com> wrote:

    Some day we will be free of x86 and freed from bloated insecure >>>>>>>>>>> operating systems.

    Well, we can go back to banging rocks together anytime we like. ;) >>>>>>>>
    Or put 1024 risc processors on a chip and manage them rationally. >>>>>>>>
    We cannot rationally manage a congress of a few hundred when they're >>>>>>>> humans, why do you expect we can handle intercommunicating
    'risc processors' either? The experience with humans is
    well documented, hasn't changed much since

    <https://archive.org/details/mackay-popular-delusions>

    So, to the idea of rationally managing 1024 risk processors, I will add
    "Imagine a Beowulf cluster of those..."

    Such number of processors might be usable e.g. for Monte Carlo
    simulations, but quite useless for random computer use.
    I disagree. One CPU can run the top-level OS. One CPU can be the file >>>>> server. One can be the internet interface. And so on. Some can run
    downloaded buggy applications, but with absolute protections.

    What's wrong with that?

    Well, to start, the economics of having that many mechanisms, and
    the 'top-level' structure encouraging a single point of failure.
    The real issue, though, is that bugs fall through the cracks
    in folks' mental models of what their tools do.

    There's lots of users of SPICE that don't understand the
    matrix solution of simultaneous equations and Kirchhoff's rules
    for setting up those equations. That implies that they
    don't understand SPICE, either. The human at the top
    isn't really in control, when that happens.

    I don't need to understand the code inside Spice. I just need to use
    it.

    I don't automatically trust a Spice sim anyhow. As Mike E famously
    said, the main function of Spice is to train your instincts.

    I recently added a 1 ohm resistor to a Spice model, one end grounded
    and the other just open. It decreased sim time by a factor of
    thousands. Explain that for us please.


    You probably had something dodgy in your circuit, like a node
    without DC path, a loop with zero resistance, or a lossless
    resonator.

    Jeroen Belleman

    Why did the 1 ohm resistor fix that?

    Has AI made it into spice?
    Reasoning by AI: "Guy has no clue, resistor that way makes no sense
    no need for high precision math", -> 1000 x faster,
    I am not kidding, was just reading this:
    https://arstechnica.com/information-technology/2023/11/ai-powered-drawing-app-stuns-developers-by-turning-sketches-into-functional-games/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to John Larkin on Thu Nov 16 23:28:05 2023
    On Thursday, November 16, 2023 at 5:37:48 PM UTC-8, John Larkin wrote:

    Absolute hardware protection and safe inter-processor messaging.
    Sacrifice a bit of speed for safety. 256 GHz-class ARM processors
    should be enough processing power for the average citizen.

    Enough power, yes; an effective tool, no. 256 processors and one
    citizen is like 256 motors driving a four-wheel vehicle. It's the connections that kill your economics.

    As for absolute hardware protection, protecting means making
    access impossible?

    Cone-of-silence security, in other words. <https://www.youtube.com/watch?v=HWtPPWi6OMQ>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to All on Fri Nov 17 01:37:26 2023
    On 11/17/2023 12:28 AM, whit3rd wrote:
    Enough power, yes; an effective tool, no. 256 processors and one
    citizen is like 256 motors driving a four-wheel vehicle. It's the connections
    that kill your economics.

    As for absolute hardware protection, protecting means making
    access impossible?

    Cone-of-silence security, in other words. <https://www.youtube.com/watch?v=HWtPPWi6OMQ>

    Worse. SELECTIVE access. And, given that you can't predict
    (i.e., dictate) what any two processes (processORS) might
    want to share or how they would want to share it, just what
    sort of mechanism could you implement -- efficiently,
    reliably and cheaply -- to allow applications to decide
    what and how to share?

    I.e., you've got a distributed system with all of the
    woes that come with it (most folks are inept when it comes
    to dealing with multiple processors and the issues regarding
    their interactions). Note how many "successful" NoW's
    have been reliably deployed...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to Don Y on Fri Nov 17 09:44:02 2023
    On 15/11/2023 18:52, Don Y wrote:
    On 11/15/2023 5:22 AM, Martin Brown wrote:

    I have finally had to install Ubuntu myself to gain access to exotic
    software that is only available on Unix (and porting it to Windows
    would be incredibly tedious and error prone which is why no-one ever
    has).

    Why have you (presumably) avoided it?  Most Eunices install a lot easier (and quicker!) than Windows.  The only tough part is if you want to offer specific network services on a host (name, file transfer, SMB, packet filtering, etc.).  There, the UIs tend to be pretty archaic (read:
    non-GUI) and often cryptic.  Best not tackled by newbies.

    It was the cryptic archaic UI's and having already invested quite some
    effort in OS/2 PM development skills which paid rather well. They had a segmented architecture where it was very hard (but not quite impossible)
    for a process to access or write to memory outside its allocated zones.

    Unfortunately the flat memory model and pointer to a God alone knows
    what windows object won out in the end and we all now pay the price.
    Segmented memory access isn't pretty but it puts hard bounds on what
    damage a rogue process can actually do to a working machine.

    I'm quite impressed with it so far and Maxima is much more stable on
    the Unix platform which is an unexpected bonus for me (likewise I
    suspect for Latex too). I may yet make the change to becoming a Unix
    advocate.

    In future there are some things that I will now do under Unix because
    it works better there than on Windows rather than because there is no
    equivalent on Windows (which is what motivated me to jump ship).

    My approach has sort of been the opposite:  using UN*X for the
    important things and Windows for those things that are more
    "window dressing" (documentation, CAD/EDA, multimedia, etc.).
    I've not used a Windows-based toolchain for ages (since VC1.0!)

    Fundamentally it comes down to a strategy of only using unfamiliar
    esoteric stuff for solving problems that won't yield any other way.

    I'm presently trying to get to grips with ARM's Remez approximation code
    in Julia and Sollya's alternative way of doing things. Maxima and Excel
    don't even agree on which way the function I am modelling diverges from reality! (and they are each given the same precision coefficients)

    I'm slightly more inclined to trust Maxima...

    If anyone here has experience wrestling with either of these
    approximation tools I would be interested in comparing notes...

    --
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to All on Fri Nov 17 02:07:17 2023
    On Thu, 16 Nov 2023 23:28:05 -0800 (PST), whit3rd <whit3rd@gmail.com>
    wrote:

    On Thursday, November 16, 2023 at 5:37:48?PM UTC-8, John Larkin wrote:

    Absolute hardware protection and safe inter-processor messaging.
    Sacrifice a bit of speed for safety. 256 GHz-class ARM processors
    should be enough processing power for the average citizen.

    Enough power, yes; an effective tool, no. 256 processors and one
    citizen is like 256 motors driving a four-wheel vehicle. It's the connections
    that kill your economics.


    Current OS's have apps calling on file servers and device drivers, by
    task switching a shared CPU, which is hazardous and inefficient. Save
    contexts, flush caches, flag virtual pages as invalid. You don't need
    to do that dangerous slow stuff if you don't share one CPU for
    everything. With a CPU per service, all those services are not only
    safe, they truly run in parallel.

    As for absolute hardware protection, protecting means making
    access impossible?

    It means safe.


    Cone-of-silence security, in other words. ><https://www.youtube.com/watch?v=HWtPPWi6OMQ>

    I'm always impressed by most peoples' default reaction to a new idea.
    They tend to use all available intelligence to defend against it.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeroen Belleman@21:1/5 to John Larkin on Fri Nov 17 10:31:54 2023
    On 11/17/23 00:52, John Larkin wrote:
    On Thu, 16 Nov 2023 23:29:56 +0100, Jeroen Belleman
    <jeroen@nospam.please> wrote:

    On 11/16/23 19:22, john larkin wrote:
    On Thu, 16 Nov 2023 08:24:51 -0800 (PST), whit3rd <whit3rd@gmail.com>
    wrote:

    On Thursday, November 16, 2023 at 8:11:24?AM UTC-8, John Larkin wrote: >>>>> On Thu, 16 Nov 2023 14:44:36 +0200, upsid...@downunder.com wrote:

    On Wed, 15 Nov 2023 13:48:30 -0800, john larkin <j...@650pot.com> wrote: >>>>>>
    On Wed, 15 Nov 2023 09:39:05 -0800 (PST), whit3rd <whi...@gmail.com> >>>>>>> wrote:

    On Tuesday, November 14, 2023 at 7:37:37?AM UTC-8, John Larkin wrote: >>>>>>>>> On Mon, 13 Nov 2023 18:09:57 -0000 (UTC), Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    John Larkin <j...@997PotHill.com> wrote:
    On Mon, 13 Nov 2023 09:08:34 -0800 (PST), Fred Bloggs
    <bloggs.fred...@gmail.com> wrote:

    Some day we will be free of x86 and freed from bloated insecure >>>>>>>>>>> operating systems.

    Well, we can go back to banging rocks together anytime we like. ;) >>>>>>>>
    Or put 1024 risc processors on a chip and manage them rationally. >>>>>>>>
    We cannot rationally manage a congress of a few hundred when they're >>>>>>>> humans, why do you expect we can handle intercommunicating
    'risc processors' either? The experience with humans is
    well documented, hasn't changed much since

    <https://archive.org/details/mackay-popular-delusions>

    So, to the idea of rationally managing 1024 risk processors, I will add
    "Imagine a Beowulf cluster of those..."

    Such number of processors might be usable e.g. for Monte Carlo
    simulations, but quite useless for random computer use.
    I disagree. One CPU can run the top-level OS. One CPU can be the file >>>>> server. One can be the internet interface. And so on. Some can run
    downloaded buggy applications, but with absolute protections.

    What's wrong with that?

    Well, to start, the economics of having that many mechanisms, and
    the 'top-level' structure encouraging a single point of failure.
    The real issue, though, is that bugs fall through the cracks
    in folks' mental models of what their tools do.

    There's lots of users of SPICE that don't understand the
    matrix solution of simultaneous equations and Kirchhoff's rules
    for setting up those equations. That implies that they
    don't understand SPICE, either. The human at the top
    isn't really in control, when that happens.

    I don't need to understand the code inside Spice. I just need to use
    it.

    I don't automatically trust a Spice sim anyhow. As Mike E famously
    said, the main function of Spice is to train your instincts.

    I recently added a 1 ohm resistor to a Spice model, one end grounded
    and the other just open. It decreased sim time by a factor of
    thousands. Explain that for us please.


    You probably had something dodgy in your circuit, like a node
    without DC path, a loop with zero resistance, or a lossless
    resonator.

    Jeroen Belleman

    Why did the 1 ohm resistor fix that?


    I don't know, I didn't write LTspice. I have a suspicion that Mike
    inserts hidden components with values close to the numerical limits
    of precision. Most of the time, with normal circuits, that doesn't
    matter. Sometimes, in circuits that are too idealized, it does.

    Jeroen Belleman

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to whit3rd@gmail.com on Fri Nov 17 16:20:30 2023
    XPost: free.spam

    The arsehole whit3rd <whit3rd@gmail.com> persisting in being an Off-topic troll...

    --
    whit3rd <whit3rd@gmail.com> wrote:

    X-Received: by 2002:a05:620a:2117:b0:77a:29f:97e8 with SMTP id l23-20020a05620a211700b0077a029f97e8mr227042qkl.5.1700206086331;
    Thu, 16 Nov 2023 23:28:06 -0800 (PST)
    X-Received: by 2002:a05:6a00:1ca3:b0:690:3ac3:f3f1 with SMTP id
    y35-20020a056a001ca300b006903ac3f3f1mr5586954pfw.1.1700206086033; Thu, 16 Nov
    2023 23:28:06 -0800 (PST)
    Path: not-for-mail
    Newsgroups: sci.electronics.design
    Date: Thu, 16 Nov 2023 23:28:05 -0800 (PST)
    In-Reply-To: <l2gdli1213tmjnsur3ivooc8a8s0lt2uf6@4ax.com>
    Injection-Info: google-groups.googlegroups.com; posting-host=209.221.140.126; posting-account=vKQm_QoAAADOaDCYsqOFDAW8NJ8sFHoE
    NNTP-Posting-Host: 209.221.140.126
    References: <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitopl$r9m7$1@dont-email.me>
    <cu47li9f5gri305iafvffnmao9aurkvi2m@4ax.com> <b5d488fb-4cae-41de-a003-0f823a6fd2b2n@googlegroups.com>
    <48eali9c9lp841616piphv6jc2tp16rpuj@4ax.com> <rk2cli5krra78uhajm05oh1eorag933tq5@4ax.com>
    <eafcli95b5qcateh2h07f35rg1fqriqoi0@4ax.com> <62ea37b3-ffd9-fc6b-de7b-894fef274021@electrooptical.net>
    <r35dli1au3siiieroone1clgvu303t85lf@4ax.com> <c94a297c-4087-d545-4545-c9596b887909@electrooptical.net>
    <l2gdli1213tmjnsur3ivooc8a8s0lt2uf6@4ax.com>
    User-Agent: G2/1.0
    MIME-Version: 1.0
    Message-ID: <bf50b9ef-980a-4a85-b89e-d8e56bfde647n@googlegroups.com>
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did
    nothing, lawsuit claims
    From: whit3rd <whit3rd@gmail.com>
    Injection-Date: Fri, 17 Nov 2023 07:28:06 +0000
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable
    X-Received-Bytes: 2425

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to Martin Brown on Fri Nov 17 16:20:55 2023
    XPost: free.spam

    The arsehole Martin Brown <'''newspam'''@nonad.co.uk> persisting in being an Off-topic troll...

    --
    Martin Brown <'''newspam'''@nonad.co.uk> wrote:

    Path: not-for-mail
    From: Martin Brown <'''newspam'''@nonad.co.uk>
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did
    nothing, lawsuit claims
    Date: Fri, 17 Nov 2023 09:44:02 +0000
    Organization: A noiseless patient Spider
    Lines: 54
    Message-ID: <uj7cl9$2oe8i$1@dont-email.me>
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com>
    <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitqvi$rjpc$1@dont-email.me>
    <r257lipb348csh8otghajpb8v2ds1707lj@4ax.com> <uj2d6m$1o35u$1@dont-email.me>
    <uj340o$1rrht$1@dont-email.me>
    MIME-Version: 1.0
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit
    Injection-Date: Fri, 17 Nov 2023 09:44:09 -0000 (UTC)
    Injection-Info: dont-email.me; posting-host="03c154cfba1b1827684863b3558a2087";
    logging-data="2898194"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1//dd4ccM+gwARoGoWpejo7LWpHlJBIbp8oD8fmv61GwQ=="
    User-Agent: Mozilla Thunderbird
    Cancel-Lock: sha1:lFrY0ApR5Fd0NgRNHOE7bhy6NsM=
    Content-Language: en-GB
    In-Reply-To: <uj340o$1rrht$1@dont-email.me>
    X-Received-Bytes: 3932

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to Jan Panteltje on Fri Nov 17 16:21:02 2023
    XPost: free.spam

    The arsehole Jan Panteltje <alien@comet.invalid> persisting in being an Off-topic troll...

    --
    Jan Panteltje <alien@comet.invalid> wrote:

    Path: not-for-mail
    From: Jan Panteltje <alien@comet.invalid>
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did nothing, lawsuit claims
    Date: Fri, 17 Nov 2023 06:30:35 GMT
    Message-ID: <uj71ac$1k8pm$1@solani.org>
    References: <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitopl$r9m7$1@dont-email.me> <cu47li9f5gri305iafvffnmao9aurkvi2m@4ax.com> <b5d488fb-4cae-41de-a003-0f823a6fd2b2n@googlegroups.com> <48eali9c9lp841616piphv6jc2tp16rpuj@4ax.com> <
    rk2cli5krra78uhajm05oh1eorag933tq5@4ax.com> <eafcli95b5qcateh2h07f35rg1fqriqoi0@4ax.com> <6bfde742-69df-4eee-ad3e-6d047c573d2en@googlegroups.com> <36nclil8bnf2bbdkg1damb71r86v4fh95h@4ax.com> <uj654o$2es19$1@dont-email.me> <
    1padli5n5v4o67l9lif9hicc0djl7jsd81@4ax.com>
    MIME-Version: 1.0
    Content-Type: text/plain; ISO-8859-15
    Content-Transfer-Encoding: 8bit
    Injection-Date: Fri, 17 Nov 2023 06:30:36 -0000 (UTC)
    Injection-Info: solani.org;
    logging-data="1712950"; mail-complaints-to="abuse@news.solani.org" User-Agent: NewsFleX-1.5.7.5 (Linux-5.15.32-v7l+)
    Cancel-Lock: sha1:L1E6srtBGQvgV2k057tjf/2KmRk=
    X-Newsreader-location: NewsFleX-1.5.7.5 (c) 'LIGHTSPEED' off line news reader for the Linux platform
    NewsFleX homepage: http://www.panteltje.nl/panteltje/newsflex/ and ftp download ftp://sunsite.unc.edu/pub/linux/system/news/readers/
    X-User-ID: eJwFwQEBACAIA7BKov5AHEHfP4IbFo3tm+CGIGf0rI6Oyu3MB0IF8iHsvrCTrBRzuSYdKYzKM+Ksay59SC8VQQ==
    X-Received-Bytes: 5441

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to John Larkin on Fri Nov 17 16:21:14 2023
    XPost: free.spam

    The arsehole John Larkin <jl@997PotHill.com> persisting in being an Off-topic troll...

    --
    John Larkin <jl@997PotHill.com> wrote:

    Path: not-for-mail
    NNTP-Posting-Date: Fri, 17 Nov 2023 01:37:32 +0000
    From: John Larkin <jl@997PotHill.com>
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did nothing, lawsuit claims
    Date: Thu, 16 Nov 2023 17:37:04 -0800
    Organization: Highland Tech
    Reply-To: xx@yy.com
    Message-ID: <l2gdli1213tmjnsur3ivooc8a8s0lt2uf6@4ax.com>
    References: <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitopl$r9m7$1@dont-email.me> <cu47li9f5gri305iafvffnmao9aurkvi2m@4ax.com> <b5d488fb-4cae-41de-a003-0f823a6fd2b2n@googlegroups.com> <48eali9c9lp841616piphv6jc2tp16rpuj@4ax.com> <
    rk2cli5krra78uhajm05oh1eorag933tq5@4ax.com> <eafcli95b5qcateh2h07f35rg1fqriqoi0@4ax.com> <62ea37b3-ffd9-fc6b-de7b-894fef274021@electrooptical.net> <r35dli1au3siiieroone1clgvu303t85lf@4ax.com> <c94a297c-4087-d545-4545-c9596b887909@electrooptical.net>
    X-Newsreader: Forte Agent 3.1/32.783
    MIME-Version: 1.0
    Content-Type: text/plain; charset=us-ascii
    Content-Transfer-Encoding: 7bit
    Lines: 163
    X-Trace: sv3-I0TQ1N7FpUQ0/CMIYnoT17/CO28tPNSJSXgPeWZUMCVzG3TT252JiXwQEPsd25FhHyXHhKpaPLNDg6k!6czcEkWQLef8roAic8bmuHW5IE6yl7tpkU6c9TJCY9HjzxAmM5+vzavm+HRdKHHTKZ+0nf7sapq3!mDxIoQ==
    X-Complaints-To: www.supernews.com/docs/abuse.html
    X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
    X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
    X-Postfilter: 1.3.40
    X-Received-Bytes: 7829

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to Jeroen Belleman on Fri Nov 17 16:21:08 2023
    XPost: free.spam

    The idiot Jeroen Belleman <jeroen@nospam.please> persisting in being an Off-topic troll...

    --
    Jeroen Belleman <jeroen@nospam.please> wrote:

    Path: not-for-mail
    From: Jeroen Belleman <jeroen@nospam.please>
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did nothing, lawsuit claims
    Date: Fri, 17 Nov 2023 10:31:54 +0100
    Organization: A noiseless patient Spider
    Lines: 86
    Message-ID: <uj7bts$2ob98$1@dont-email.me>
    References: <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitopl$r9m7$1@dont-email.me> <cu47li9f5gri305iafvffnmao9aurkvi2m@4ax.com> <b5d488fb-4cae-41de-a003-0f823a6fd2b2n@googlegroups.com> <48eali9c9lp841616piphv6jc2tp16rpuj@4ax.com> <
    rk2cli5krra78uhajm05oh1eorag933tq5@4ax.com> <eafcli95b5qcateh2h07f35rg1fqriqoi0@4ax.com> <6bfde742-69df-4eee-ad3e-6d047c573d2en@googlegroups.com> <36nclil8bnf2bbdkg1damb71r86v4fh95h@4ax.com> <uj654o$2es19$1@dont-email.me> <
    1padli5n5v4o67l9lif9hicc0djl7jsd81@4ax.com>
    MIME-Version: 1.0
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit
    Injection-Date: Fri, 17 Nov 2023 09:31:40 -0000 (UTC)
    Injection-Info: dont-email.me; posting-host="e00f15488cb83c14e2584689882af488"; logging-data="2895144"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+n5l/23bk3AZJj9rQZxJzf"
    User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0
    Cancel-Lock: sha1:kUpRHjqx7batOvstxAxi/FvFHfI=
    In-Reply-To: <1padli5n5v4o67l9lif9hicc0djl7jsd81@4ax.com>
    Content-Language: en-US
    X-Received-Bytes: 5316

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to Don Y on Fri Nov 17 16:21:26 2023
    XPost: free.spam

    The idiot Don Y <blockedofcourse@foo.invalid> persisting in being an Off-topic troll...

    --
    Don Y <blockedofcourse@foo.invalid> wrote:

    Path: not-for-mail
    From: Don Y <blockedofcourse@foo.invalid>
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did
    nothing, lawsuit claims
    Date: Fri, 17 Nov 2023 01:37:26 -0700
    Organization: A noiseless patient Spider
    Lines: 26
    Message-ID: <uj78of$2npbr$1@dont-email.me>
    References: <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com>
    <uitopl$r9m7$1@dont-email.me> <cu47li9f5gri305iafvffnmao9aurkvi2m@4ax.com>
    <b5d488fb-4cae-41de-a003-0f823a6fd2b2n@googlegroups.com>
    <48eali9c9lp841616piphv6jc2tp16rpuj@4ax.com>
    <rk2cli5krra78uhajm05oh1eorag933tq5@4ax.com>
    <eafcli95b5qcateh2h07f35rg1fqriqoi0@4ax.com>
    <62ea37b3-ffd9-fc6b-de7b-894fef274021@electrooptical.net>
    <r35dli1au3siiieroone1clgvu303t85lf@4ax.com>
    <c94a297c-4087-d545-4545-c9596b887909@electrooptical.net>
    <l2gdli1213tmjnsur3ivooc8a8s0lt2uf6@4ax.com>
    <bf50b9ef-980a-4a85-b89e-d8e56bfde647n@googlegroups.com>
    MIME-Version: 1.0
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit
    Injection-Date: Fri, 17 Nov 2023 08:37:36 -0000 (UTC)
    Injection-Info: dont-email.me; posting-host="690610e700b37fc5a88a4d38af846c2f";
    logging-data="2876795"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+jzKpnNtt9rIebiNuoT7xT"
    User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
    Thunderbird/102.2.2
    Cancel-Lock: sha1:cwLBYmTHbgEnK4kD31UZ3VY7wUM=
    In-Reply-To: <bf50b9ef-980a-4a85-b89e-d8e56bfde647n@googlegroups.com> Content-Language: en-US
    X-Received-Bytes: 2793

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Martin Brown on Fri Nov 17 11:13:27 2023
    On 11/17/2023 2:44 AM, Martin Brown wrote:
    On 15/11/2023 18:52, Don Y wrote:
    On 11/15/2023 5:22 AM, Martin Brown wrote:

    I have finally had to install Ubuntu myself to gain access to exotic
    software that is only available on Unix (and porting it to Windows would be >>> incredibly tedious and error prone which is why no-one ever has).

    Why have you (presumably) avoided it?  Most Eunices install a lot easier
    (and quicker!) than Windows.  The only tough part is if you want to offer >> specific network services on a host (name, file transfer, SMB, packet
    filtering, etc.).  There, the UIs tend to be pretty archaic (read:
    non-GUI) and often cryptic.  Best not tackled by newbies.

    It was the cryptic archaic UI's and having already invested quite some effort in OS/2 PM development skills which paid rather well.

    Ah, you're looking for it as a platform on which to code; I use commercial
    OSs only to support *tools* (I code on bare metal).

    I use Windows-based tools for tasks that tend to be graphic/interactive
    and UN*X-based for "batch" processing. E.g., I "drew" all of the
    models for my gestures (gesture recognizer) in Illustrator (under
    Windows). Wrote a filter (under BSD) to parse the PostScript within each
    AI file to extract the Beziers defining the gesture from all the .AI overhead. Another filter to parse those and populate the RDBMS with the individual segments. Then, code to extract the features from each segment to
    augment each DB record. Finally, ship all that back over to Windows
    to render them, interactively, for "proofreading" and inclusion into the
    formal documentation and user manual.

    They had a segmented
    architecture where it was very hard (but not quite impossible) for a process to
    access or write to memory outside its allocated zones.

    Segments are great -- but usually not of sufficient number or
    granularity (it would be nice to statically define a segment per
    object and just use segment numbers instead of bare addresses).

    The other downside is they only protect an app from itself
    (and, only if the app intentionally makes use of that capability).

    I emulate segments in a PMMU by wasting large swaths of the address
    space. I.e., force objects to begin on page boundaries and fit
    in N contiguous pages. Barren wasteland between pages gives me a
    similar sort of protection (SIGSEGV).

    This has relatively low cost (though more than segment hardware).

    But, the real need for protection is between processes so you don't
    worry about some other activity stomping on YOUR resources. As
    the goal should always be to slice-and-dice into small units of
    low/modest complexity, that means lots of processes. And, the cost
    for crossing a protection domain is a bit high. An order of magnitude
    (maybe two?) moreso if you have to leave the physical processor!

    OTOH, processors are cheap compared to development costs. The idea
    of writing big pieces of code is just foolhardy -- are you REALLY
    that concerned over performance of generic applications??

    [Having lots of protected processes is exhilirating; so much
    easier to get the code right the first time when you're not
    dealing with all sorts of barely-related cruft!]

    Unfortunately the flat memory model and pointer to a God alone knows what windows object won out in the end and we all now pay the price. Segmented memory access isn't pretty but it puts hard bounds on what damage a rogue process can actually do to a working machine.

    I spend hardware resources on reinforcing abstractions. So, you
    deal with *objects* referenced by a handle (akin to a file descriptor...
    it's just a number that means nothing outside of the context of YOUR
    task).

    So, *YOU* don't muck with any objects but, rather, tell the objects
    what you want them to do to themselves on your behalf.

    Because everything indirects through a handle, the OS mediates all
    accesses. If I want you to be able to "close" a door but not open
    it, then the capability that you are issued (embedded in the
    handle you have been give to that "door") won't allow you to invoke
    the open method. And, you won't even know there are OTHER "doors"
    unless you have been given handles to them (the idea of a global namespace/filesystem is *so* 1960's -- why should every process
    know about every name/file in the system? And, then have to layer
    ACLs on that to block unwanted access? Just hide the object and
    the idea of unwanted accesses goes away!)

    Of course, if you try to invoke a method that isn't permitted
    by your capability, then you are obviously either buggy or trying
    to subvert the system. In each case, you should die and be blocked
    from running, again (you're clearly unfit)!

    Imagine trying to impose these sorts of mechanisms and policies in *hardware*...

    I'm quite impressed with it so far and Maxima is much more stable on the >>> Unix platform which is an unexpected bonus for me (likewise I suspect for >>> Latex too). I may yet make the change to becoming a Unix advocate.

    In future there are some things that I will now do under Unix because it >>> works better there than on Windows rather than because there is no
    equivalent on Windows (which is what motivated me to jump ship).

    My approach has sort of been the opposite:  using UN*X for the
    important things and Windows for those things that are more
    "window dressing" (documentation, CAD/EDA, multimedia, etc.).
    I've not used a Windows-based toolchain for ages (since VC1.0!)

    Fundamentally it comes down to a strategy of only using unfamiliar esoteric stuff for solving problems that won't yield any other way.

    Well, in my case it's not that the problems won't *yield* but,
    rather, that the cost of doing it some other way (with some other
    tools) is higher than I'd like to pay. E.g., I could have built
    all the gesture models by hand just typing coordinates of control
    points for the beziers and having a look at the resulting renderings.
    But, that's WAY too tedious (read: prone to error).

    [Isn't that why we opt for less efficient hardware and software
    solutions -- to minimize the chance of screwing up?]

    I'm presently trying to get to grips with ARM's Remez approximation code in Julia and Sollya's alternative way of doing things. Maxima and Excel don't even
    agree on which way the function I am modelling diverges from reality! (and they
    are each given the same precision coefficients)

    I'm slightly more inclined to trust Maxima...

    Have you looked at (still) other tools? Perhaps Octave? Or YACAS,
    Yorick?

    I rely on Mathematica for most of my number crunching. But, my $WORK intentionally tries to avoid complex math as runtime costs are usually
    not something that the application can afford. So, I look at what the
    theory says (on my desktop) and then pick suitable approximations
    to embed in the run-time.

    [Like pre-characterizing Beziers instead of trying to *fit* them at
    run-time. So, my run-time algorithms can be simple linear operations]

    If anyone here has experience wrestling with either of these approximation tools I would be interested in comparing notes...

    Phil H may have some exposure... You may want to start a new thread with
    an appropriate subject line -- or PM him directly?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From john larkin@21:1/5 to All on Fri Nov 17 10:33:48 2023
    On Thu, 16 Nov 2023 08:47:56 -0800, John Larkin <jl@997PotHill.com>
    wrote:

    On Thu, 16 Nov 2023 11:17:04 +0000, Martin Brown
    <'''newspam'''@nonad.co.uk> wrote:

    On 15/11/2023 22:01, john larkin wrote:
    On Wed, 15 Nov 2023 18:16:42 +0000, Martin Brown
    <'''newspam'''@nonad.co.uk> wrote:

    On 14/11/2023 16:09, Dimiter_Popoff wrote:

    I can swallow that as I use it for reading pdf-s and browsing,
    plus the occasional ltspice.

    The only gotcha I can see is that every version requires more ram and
    occupies more disk space but both are cheap and fast today.

    Win10 is going officially unsupported sometime soon in 2025. I expect it >>>> will get a reprieve or there will be a global malware catastrophe.

    https://www.zdnet.com/article/microsoft-windows-10-is-a-security-disaster-waiting-to-happen/

    Win11 main advantage for me is that it understands performance cores on >>>> the more recent Intel CPUs. That is a kludge in Win10.

    The last truly dreadful edition of windows was Win8.
    Think Picasso on a bad acid trip and you will not be too far off.

    I miss Win7, but most of the machines have died.

    Win7 will run on modern CPUs although I wouldn't recommend it unless you >>either have a damn good impenetrable firewall (plenty of ancient big >>scientific instruments still work that way 20 year design life -
    although clever virtualisation of antique hardware environments are
    getting around that).

    You can extract the original license key from old kit with suitable
    tools - although the license server may now have disappeared so you
    cannot register new hardware to run Win7. It means that certain >>motherboards have premium prices in the second hand market.

    You can make Win11 look enough like WIn7 to be acceptable.

    Win11 got terrible user reviews, but update 23H2 fixed a lot of
    stupidities. It's almost tolerable, after a lot of tweaks.

    It runs Firefox, LT Spice, PADS, VLC, Crimson, Agent, Irfanview, and a
    bunch of my old compiled PowerBasic programs. And seems reliable so
    far.

    None of those are particularly taxing. The big change was when 32bit
    code (and before that 16bit) became unsupported.
    That broke a lot of major players installers like Adobe Photoshop and >>others.
    You just like to whinge and whine about Intel and Microsoft.

    You just like to insult people.

    Design something. You'll feel better.

    I suspect that designing (and building) hardware makes people happier
    and friendlier than typing code all day. Hardware design exercizes a
    lot more parts of your brain and body.

    It sure makes me happier. I get depressed if I type code for more than
    a week or two.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From john larkin@21:1/5 to '''newspam'''@nonad.co.uk on Fri Nov 17 10:38:27 2023
    On Thu, 16 Nov 2023 11:04:38 +0000, Martin Brown
    <'''newspam'''@nonad.co.uk> wrote:

    On 15/11/2023 18:54, Don Y wrote:
    On 11/15/2023 11:16 AM, Martin Brown wrote:
    The only gotcha I can see is that every version requires more ram and
    occupies more disk space but both are cheap and fast today.

    Save for a generation of machines with 8GB *hardware* memory limits...

    It was ever thus. Time was when each new OS required almost all of the >hardware currently in use to be replaced.

    OTOH, I can run a *BSD box with *megabytes* of RAM if I am willing
    to live witht he thrashing (which, unlike windows machines,
    won't take the machine to its knees)

    I can recall a time back when big iron had a whopping (for the time) 4MB
    of main memory and when you you had to get a special ticket to allow
    your jobs to use more than 1MB at a time. Lisp wouldn't run in less.

    I remember a big press release when IBM announced mainframe memory for
    a mere $50,000 per megabyte. $50K would buy 10 Cadillacs then.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to john larkin on Fri Nov 17 20:23:45 2023
    XPost: free.spam

    The arsehole john larkin <jl@650pot.com> persisting in being an Off-topic troll...

    --
    john larkin <jl@650pot.com> wrote:

    Path: not-for-mail
    NNTP-Posting-Date: Fri, 17 Nov 2023 18:38:27 +0000
    From: john larkin <jl@650pot.com>
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did nothing, lawsuit claims
    Date: Fri, 17 Nov 2023 10:38:27 -0800
    Message-ID: <tkcfli9p932sfp9f5d7kqu4mpdmnud52fb@4ax.com>
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com> <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitqvi$rjpc$1@dont-email.me> <r257lipb348csh8otghajpb8v2ds1707lj@4ax.com> <uj063l$19nj8$1@dont-email.me> <uj31uf$1rfa0$1@dont-email.me> <
    uj344f$1rrht$2@dont-email.me> <uj4t0d$280cn$1@dont-email.me>
    User-Agent: ForteAgent/8.00.32.1272
    MIME-Version: 1.0
    Content-Type: text/plain; charset=us-ascii
    Content-Transfer-Encoding: 7bit
    Lines: 24
    X-Trace: sv3-8pCvVkcAcsM77zmfutcCHxNidtz/g+f9yVuh8V9PJZuXf0cvlXXlSfNYTgYomHBOmm/ScbiNwjmgRX5!TsWblykBbkNxGZj4BpnwztMIDe1d2tI6zczSDjs0doVrXJgGA2ZsE+2pjw0++YSpB/oRJmELu3yu!jQmufg==
    X-Complaints-To: www.supernews.com/docs/abuse.html
    X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
    X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
    X-Postfilter: 1.3.40
    X-Received-Bytes: 2690

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to Don Y on Fri Nov 17 20:23:57 2023
    XPost: free.spam

    The arsehole Don Y <blockedofcourse@foo.invalid> persisting in being an Off-topic troll...

    --
    Don Y <blockedofcourse@foo.invalid> wrote:

    Path: not-for-mail
    From: Don Y <blockedofcourse@foo.invalid>
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did nothing, lawsuit claims
    Date: Fri, 17 Nov 2023 11:13:27 -0700
    Organization: A noiseless patient Spider
    Lines: 148
    Message-ID: <uj8agh$2tcjv$2@dont-email.me>
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com> <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitqvi$rjpc$1@dont-email.me> <r257lipb348csh8otghajpb8v2ds1707lj@4ax.com> <uj2d6m$1o35u$1@dont-email.me> <uj340o$1rrht$1@dont-email.me> <
    uj7cl9$2oe8i$1@dont-email.me>
    MIME-Version: 1.0
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit
    Injection-Date: Fri, 17 Nov 2023 18:13:38 -0000 (UTC)
    Injection-Info: dont-email.me; posting-host="690610e700b37fc5a88a4d38af846c2f"; logging-data="3060351"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX190aAWZkeWgYUz1obdNSZzh"
    User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2
    Cancel-Lock: sha1:AMa0UfczxaWPj4AdKMRyBx4U2o8=
    Content-Language: en-US
    In-Reply-To: <uj7cl9$2oe8i$1@dont-email.me>
    X-Received-Bytes: 8818

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From upsidedown@downunder.com@21:1/5 to '''newspam'''@nonad.co.uk on Fri Nov 17 23:59:28 2023
    On Fri, 17 Nov 2023 09:44:02 +0000, Martin Brown
    <'''newspam'''@nonad.co.uk> wrote:


    It was the cryptic archaic UI's and having already invested quite some
    effort in OS/2 PM development skills which paid rather well. They had a >segmented architecture where it was very hard (but not quite impossible)
    for a process to access or write to memory outside its allocated zones.

    Apparently it had non-overlapping segments. IIRC the segment registers
    also had an exe/moexe bit.Thus it would be quite hard to modify the
    code segment accidentally.

    With 386 Intel made a mistake by first evaluated the segment address,
    then truncate it to 32 bits before applying paging. Thus the virtual
    address space was limited to 4 GB. A better solution would have been
    skipping the truncation to 32 bits and allow 4 GB access for each
    segment.

    Things get worse by some OSes which loaded 0 to all segment registers,
    thus all segments overlapped, so writing into the code segment is
    easy. No help setting the execute bit in the code segment register and
    denying in other segments.


    Unfortunately the flat memory model and pointer to a God alone knows
    what windows object won out in the end and we all now pay the price. >Segmented memory access isn't pretty but it puts hard bounds on what
    damage a rogue process can actually do to a working machine.

    I can understand the segmented system problems with 16 bit 8086 code,
    but in 32 bit 386 mode it would have less harmful.

    It is sad that the segmented access is nearly gone in 64 bitters. A
    few more segment registers and most addresses could be generated with
    2 or 4 byte offsets relative to the segment register, instead of full
    8 byte address references.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to upsidedown@downunder.com on Fri Nov 17 18:06:38 2023
    On 11/17/2023 2:59 PM, upsidedown@downunder.com wrote:
    On Fri, 17 Nov 2023 09:44:02 +0000, Martin Brown
    <'''newspam'''@nonad.co.uk> wrote:


    It was the cryptic archaic UI's and having already invested quite some
    effort in OS/2 PM development skills which paid rather well. They had a
    segmented architecture where it was very hard (but not quite impossible)
    for a process to access or write to memory outside its allocated zones.

    Apparently it had non-overlapping segments. IIRC the segment registers
    also had an exe/moexe bit.Thus it would be quite hard to modify the
    code segment accidentally.

    Also possible in ARM v8.

    Limits on segment size have proven to be dreadfully small.
    Even 32b segment size register isn't exceptional.

    The processor designer in me wants to see segments begin
    anywhere (even if that causes unaligned memory hits)
    and the length have a maximum size equal to the size
    of the physical address space with a granularity of
    a single byte (again, accepting the performance hits...
    provide mechanism, not policy!)

    And, you need a PMMU *under* the segmentation hardware to
    piece together chunks of discontiguous memory as its
    unreasonable to expect a static mapping to work for all
    applications.

    But, realistically, you can "settle" for much fewer choices
    (e.g., a few page sizes aligned in a similarly coarse page frame)

    Sadly, neither approach makes things any easier for the software;
    either too much detail to manage, or too much approximation
    to manage.

    With 386 Intel made a mistake by first evaluated the segment address,
    then truncate it to 32 bits before applying paging. Thus the virtual
    address space was limited to 4 GB. A better solution would have been
    skipping the truncation to 32 bits and allow 4 GB access for each
    segment.

    Things get worse by some OSes which loaded 0 to all segment registers,
    thus all segments overlapped, so writing into the code segment is
    easy. No help setting the execute bit in the code segment register and denying in other segments.

    The problem with managing the underlying hardware is more
    pervasive. Most OSs hide far too much from their users.
    E.g., if I make an access beyond the current limits of
    a particular segment, shouldn't I -- at least -- have a say in
    how that is handled? Instead, the OS will likely throw a
    fault and shoot me.

    Exposing memory management to the user lets him exploit
    the hardware to *his* advantage.

    E.g., I routinely pass large objects to the network stack
    (and other local processes).

    But, they sit, queued for transport for some amount of
    time (it would be foolish to require a synchronous call).
    Using call-by-reference semantics, it's possible that the
    object could be altered by some other thread -- including
    the one that "sent" it -- while it's queued.

    I fake call-by-value semantics WITHOUT duplicating the
    object (which would consume additional memory AND
    time to marshall the arguments) by twiddling the TLB
    entries for those pages, marking them R/O in the caller.

    This lets the caller access the object after passing it to
    the stack (as would normally be the case with call-by-reference)
    *but* ensures any attempts by the caller to ALTER the
    object will be intercepted -- because the object
    wants to be transported in the state it was at the
    time it was passed to the stack!

    Write attempts cause the referenced page to be remapped
    (in the caller) to a different page and a R/W copy of the
    original page's contents made available for the caller
    to modify. Repeat, as required.

    [Note that the original object was R/W before it was
    passed to the stack, else even this write would fault]

    When the original object eventually is consumed by the stack,
    the original pages are returned to their original R/W
    states with any of the created duplicates replacing the
    corresponding originals.

    So, the stack's copy of the image was never corrupted.
    It benefits from a call-by-value interface without
    the cost of maintaining a duplicate copy of the object
    (which may or may not ever be needed, as such).
    Yet the caller was given freedom to modify it, at will,
    without blocking on it being released by the stack.

    It also lets the stack (callee) free portions of the
    object as they are converted into packets. Otherwise,
    a synchronous call would have been required with the
    caller handling that aspect of the object management.

    Of course, this is a privileged operation so you don't
    just let ANY user-level task fiddle with the TLBs.
    But, you can let *trusted* tasks outside of the
    OS perform these actions without having to add this
    functionality to the kernel (increasing its size).

    Unfortunately the flat memory model and pointer to a God alone knows
    what windows object won out in the end and we all now pay the price.
    Segmented memory access isn't pretty but it puts hard bounds on what
    damage a rogue process can actually do to a working machine.

    I can understand the segmented system problems with 16 bit 8086 code,
    but in 32 bit 386 mode it would have less harmful.

    History teaches us that all of these "hacks" eventually
    come around to bite us in the ass. Limits always look
    like obstacles to *someone's* application.

    It is sad that the segmented access is nearly gone in 64 bitters. A
    few more segment registers and most addresses could be generated with
    2 or 4 byte offsets relative to the segment register, instead of full
    8 byte address references.

    What's the goal, there? To save on code space?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to Don Y on Sat Nov 18 13:34:37 2023
    XPost: free.spam

    The idiot Don Y <blockedofcourse@foo.invalid> persisting in being an Off-topic troll...

    --
    Don Y <blockedofcourse@foo.invalid> wrote:

    Path: not-for-mail
    From: Don Y <blockedofcourse@foo.invalid>
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did
    nothing, lawsuit claims
    Date: Fri, 17 Nov 2023 18:06:38 -0700
    Organization: A noiseless patient Spider
    Lines: 130
    Message-ID: <uj92n8$317b8$1@dont-email.me>
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com>
    <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitqvi$rjpc$1@dont-email.me>
    <r257lipb348csh8otghajpb8v2ds1707lj@4ax.com> <uj2d6m$1o35u$1@dont-email.me>
    <uj340o$1rrht$1@dont-email.me> <uj7cl9$2oe8i$1@dont-email.me>
    <usmfli9erlm2tdn2q220kk62l7uergukfu@4ax.com>
    MIME-Version: 1.0
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit
    Injection-Date: Sat, 18 Nov 2023 01:06:49 -0000 (UTC)
    Injection-Info: dont-email.me; posting-host="58b0f9a6cc277452fdb4b751f75782c6";
    logging-data="3186024"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Y3RCCUKflMtj0U7Uw3SDZ"
    User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
    Thunderbird/102.2.2
    Cancel-Lock: sha1:V0gQK0YYUV+sQwftHktnGvaqCT8=
    In-Reply-To: <usmfli9erlm2tdn2q220kk62l7uergukfu@4ax.com>
    Content-Language: en-US
    X-Received-Bytes: 7045

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to upsidedown@downunder.com on Sat Nov 18 13:34:31 2023
    XPost: free.spam

    The idiot upsidedown@downunder.com persisting in being an Off-topic troll...

    --
    upsidedown@downunder.com wrote:

    Path: not-for-mail
    From: upsidedown@downunder.com
    Newsgroups: sci.electronics.design
    Subject: Re: Downfall fallout: Intel knew AVX chips were insecure and did nothing, lawsuit claims
    Message-ID: <usmfli9erlm2tdn2q220kk62l7uergukfu@4ax.com>
    References: <252e18ff-414a-4d18-b984-796f8311ad8dn@googlegroups.com> <ebn4lidvt7bqf9al4dq2nooo4iqpv2ifgm@4ax.com> <uitqvi$rjpc$1@dont-email.me> <r257lipb348csh8otghajpb8v2ds1707lj@4ax.com> <uj2d6m$1o35u$1@dont-email.me> <uj340o$1rrht$1@dont-email.me> <
    uj7cl9$2oe8i$1@dont-email.me>
    User-Agent: ForteAgent/8.00.32.1272
    MIME-Version: 1.0
    Content-Type: text/plain; charset=us-ascii
    Content-Transfer-Encoding: 7bit
    Lines: 38
    X-Complaints-To: abuse@easynews.com
    Organization: Forte - www.forteinc.com
    Bytes: 2565
    X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
    Date: Fri, 17 Nov 2023 23:59:28 +0200
    X-Received-Bytes: 2770

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