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

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

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

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)

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!]

On Friday, November 17, 2023 at 12:53:49 AM UTC+11, a a wrote:
> The arsehole Martin Brown <'''newspam'''@nonad.co.uk> persisting in being an Off-topic troll...

The arsehole here is a a, who seems to think he knows what an off-topic troll is without bothering to tell us why the posts he objects to should be classified as off-topic trolls.

At one stage, when his psychosis was less florid, he would post - pathetically inept - explanations of why he disliked a particular post, but now he has degenerated into the perfect example of a troll. Since he doesn't actually address the topic under discussion, his every post is off-topic.

He's posted 26 "contributions" to this thread. and none of them has been in any way useful, except perhaps in makig it clear that he's totally out of his mind.

--
Bill Sloman, Sydney

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.

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.

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.

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.

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.

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

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

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?

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

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?

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

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.

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.

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/

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>

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...

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

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

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.