On Saturday, November 26, 2022 at 4:00:29 AM UTC+11, Paul S Person wrote:
> On Thu, 24 Nov 2022 15:36:29 -0500, John W Kennedy
> <john.w....@gmail.com> wrote:
>
> >On 11/23/22 12:03 PM, Paul S Person wrote:
> >> I seem to recall that the theory was that no such software could
> >> possibly exist with the new OSes.
> >
> >Huh? ARM isn’t an OS; it’s a RISC architecture.
> It was claimed that the associated OSes would never lose anything.
> IIRC.
>
> It was the End of Windows, the End of DLL Hell, the End of Lost
> Resources -- a New Age of Computing.

and this is why technical people dislike marketing

On Fri, 25 Nov 2022 17:59:17 -0500, John W Kennedy
<john.w.kennedy@gmail.com> wrote:

>On 11/25/22 12:00 PM, Paul S Person wrote:
>> On Thu, 24 Nov 2022 15:36:29 -0500, John W Kennedy
>> <john.w.kennedy@gmail.com> wrote:
>>
>>> On 11/23/22 12:03 PM, Paul S Person wrote:
>>>> On Wed, 23 Nov 2022 13:41:15 +1100, "Gary R. Schmidt"
>>>> <grschmidt@acm.org> wrote:
>>>>
>>>>> On 23/11/2022 04:19, Paul S Person wrote:
>>>>>> On Tue, 22 Nov 2022 14:23:35 +1100, "Gary R. Schmidt"
>>>>>> <grschmidt@acm.org> wrote:
>>>>>>
>>>>>>> On 22/11/2022 07:21, Thomas Koenig wrote:
>>>>>>>> Gary R. Schmidt <grschmidt@acm.org> schrieb:
>>>>>>>>> On 20/11/2022 20:57, Thomas Koenig wrote:
>>>>>>>>>> Gary R. Schmidt <grschmidt@acm.org> schrieb:
>>>>>>>>>>> On 20/11/2022 03:06, Thomas Koenig wrote:
>>>>>>>>>>>> Gary R. Schmidt <grschmidt@acm.org> schrieb:
>>>>>>>>>>> [SNIP]
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1 - No, massively parallel Linux boxes don't do the same job[2].
>>>>>>>>>>>>
>>>>>>>>>>>> You've looked at what IBM mainframe run these days, right? zOS isn't
>>>>>>>>>>>> the only game in town :-)
>>>>>>>>>>>>
>>>>>>>>>>> No, MSP and XSP are still alive and paying some salaries in the group I
>>>>>>>>>>> work in at Fujitsu Oz. :-)
>>>>>>>>>>
>>>>>>>>>> Last time I read it, the Fujitsu mainframes were still 31 bit.
>>>>>>>>>> Is that the case?
>>>>>>>>> Tep.
>>>>>>>>>
>>>>>>>>> But only an idiot does anything other than approximations using floating
>>>>>>>>> point.
>>>>>>>>
>>>>>>>> Hm, I meant address space :-)
>>>>>>>>
>>>>>>>> Or is Fujitus still on the infamous IBM floating point only? IBM
>>>>>>>> relented and put in IEEE (I forgot when).
>>>>>>>
>>>>>>> Address space - yes, 31-bit - but the SSU is 47-bit. I can't recall
>>>>>>> which FP is used, not my cuppa either way.
>>>>>>>
>>>>>>> The mooted replacement, which may have died as I am typing this, is a
>>>>>>> 64-bit ARM-based design, due around 2030.
>>>>>>>
>>>>>>> Unless I win the lottery, I may have to deal with the early stages of
>>>>>>> this. The plan seems to be to replace everything across the line -
>>>>>>> lappies to supers - with CPUs using this architecture.
>>>>>>
>>>>>> Seems to me I heard that before ... back in the 1990s, in fact.
>>>>>>
>>>>>> You know, back when ARM was supposed to solve the "lost resources"
>>>>>> problem by getting rid of segmented architectures and Windows.
>>>>>>
>>>>>> Judging from my devices, that didn't work out to well: they halt and
>>>>>> reboot from time time, after slowing down in classic Windows fashion.
>>>>>> Except they ain't running Windows and ain't running segmented
>>>>>> processors either, so far as I can tell.
>>>>>
>>>>> Badly written software - or simply badly /conceived/ software - can kill
>>>>> any CPU.
>>>>
>>>> That's /always/ the excuse when the big promises turn out to be, at
>>>> best, overly optimistic.
>>>>
>>>> I seem to recall that the theory was that no such software could
>>>> possibly exist with the new OSes.
>>>
>>> Huh? ARM isn’t an OS; it’s a RISC architecture.
>>
>> It was claimed that the associated OSes would never lose anything.
>> IIRdffdfdfdfdfdff
>What “associated OSes” would they be? RISC OS? Palm OS Cobalt? Virtually
>all system software running on ARM has been ported to it after having
>been created on some other architecture, from 68xxx to 8086. The hottest
>ARM system right now is macOS, which has a history of three prior
>architectures.

I don't remember if they were specific or not.

>The selling points of ARM have always been performance, low power
>consumption, and, lately, system-on-a-chip suitability

And still is.

Been there, seen that, nothing happened. That's my point.

Those who fail to learn from their own history are, it appears, eager
to be doomed to repeat it.

>> It was the End of Windows, the End of DLL Hell, the End of Lost
>> Resources -- a New Age of Computing.
>>
>> And my point -- been there, seen that, it didn't work -- still
>> remains.
>>
>>>> But perhaps my memory is playing me false on that point.
>>>>
>>>> The point is -- been there, been promised that, didn't happen.
--
"In this connexion, unquestionably the most significant
development was the disintegration, under Christian
influence, of classical conceptions of the family and
of family right."

"pete...@gmail.com" <petertrei@gmail.com> writes:
>On Friday, November 25, 2022 at 11:57:46 AM UTC-5, Paul S Person wrote:
>> On Thu, 24 Nov 2022 10:54:54 -0800, Dimensional Traveler
>> <dtr...@sonic.net> wrote:

>> And, anyway, given how long they have had those Crays, up to how many
>> bits do you think they have identified /every single prime/ in that
>> range? And so can (relatively) quickly crack any encryption based on
>> prime numbers? 32-bit? 64-bit? 128-bit? 256-bit? 512-bit? 1Kb? 1Mb?
>> Who can say? Certainly not me!
>
>You're in my house now. I set up the Symmetric Key Challenges at RSA,
>and have been working in cryptographic computing for over 30 years.
>
>https://www.keylength.com/en/4/
>

>
>To sum up: There's no reason yet to think cryptography can be easily
>defeated.

Indeed. Cryptography is almost always defeated due to flaws. Flaws
in the implementation[*], or flaws in the Human side such as social
engineering.

[*] e.g. padding attacks, et alia.

Paul S Person <psperson@old.netcom.invalid> writes:
>On Thu, 24 Nov 2022 15:36:29 -0500, John W Kennedy
><john.w.kennedy@gmail.com> wrote:
>
>
>>>>
>>>> Badly written software - or simply badly /conceived/ software - can kill
>>>> any CPU.
>>>
>>> That's /always/ the excuse when the big promises turn out to be, at
>>> best, overly optimistic.
>>>
>>> I seem to recall that the theory was that no such software could
>>> possibly exist with the new OSes.
>>
>>Huh? ARM isn�t an OS; it�s a RISC architecture.
>
>It was claimed that the associated OSes would never lose anything.
>IIRC.

Claimed by whom?

>
>It was the End of Windows, the End of DLL Hell, the End of Lost
>Resources -- a New Age of Computing.

Computing preceeded Windows and has never been dependent upon
it.

There is far more to the computing world than Microsoft.

In <d_rgL.139145$fg35.118184@fx10.iad> scott@slp53.sl.home (Scott Lurndal) writes:

>Indeed. Cryptography is almost always defeated due to flaws. Flaws
>in the implementation[*], or flaws in the Human side such as social
>engineering.

>[*] e.g. padding attacks, et alia.

For the latter, see https://xkcd.com/538/

- Steven
--
___________________________________________________________________________
Steven Winikoff | "Science is built upon facts, as a house is
Montreal, QC, Canada | built of stones; but an accumulation of
smw@smwonline.ca | facts is no more a science than a heap of
http://smwonline.ca | stones is a house."
| - Henri Poincaré

On Saturday, November 26, 2022 at 12:54:37 PM UTC-5, smw wrote:
> In <d_rgL.139145$fg35....@fx10.iad> sc...@slp53.sl.home (Scott Lurndal) writes:
>
> >Indeed. Cryptography is almost always defeated due to flaws. Flaws
> >in the implementation[*], or flaws in the Human side such as social
> >engineering.
>
> >[*] e.g. padding attacks, et alia.
> For the latter, see https://xkcd.com/538/

The term of art is 'rubber hose cryptanalysis'.

Pt

On Saturday, November 26, 2022 at 12:25:34 PM UTC-5, Scott Lurndal wrote:
> "pete...@gmail.com" <pete...@gmail.com> writes:
> >On Friday, November 25, 2022 at 11:57:46 AM UTC-5, Paul S Person wrote:
> >> On Thu, 24 Nov 2022 10:54:54 -0800, Dimensional Traveler
> >> <dtr...@sonic.net> wrote:
>
> >> And, anyway, given how long they have had those Crays, up to how many
> >> bits do you think they have identified /every single prime/ in that
> >> range? And so can (relatively) quickly crack any encryption based on
> >> prime numbers? 32-bit? 64-bit? 128-bit? 256-bit? 512-bit? 1Kb? 1Mb?
> >> Who can say? Certainly not me!
> >
> >You're in my house now. I set up the Symmetric Key Challenges at RSA,
> >and have been working in cryptographic computing for over 30 years.
> >
> >https://www.keylength.com/en/4/
> >
>
> >
> >To sum up: There's no reason yet to think cryptography can be easily
> >defeated.
> Indeed. Cryptography is almost always defeated due to flaws. Flaws
> in the implementation[*], or flaws in the Human side such as social
> engineering.
>
> [*] e.g. padding attacks, et alia.

sadly, this is sometimes true.

It's like we'd perfected making bricks from untouchable adamantanium,
but used them to build walls with cow dung mortar.

Pt

On Sat, 26 Nov 2022 17:25:29 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:

>"pete...@gmail.com" <petertrei@gmail.com> writes:
>>On Friday, November 25, 2022 at 11:57:46 AM UTC-5, Paul S Person wrote:
>>> On Thu, 24 Nov 2022 10:54:54 -0800, Dimensional Traveler
>>> <dtr...@sonic.net> wrote:
>
>>> And, anyway, given how long they have had those Crays, up to how many
>>> bits do you think they have identified /every single prime/ in that
>>> range? And so can (relatively) quickly crack any encryption based on
>>> prime numbers? 32-bit? 64-bit? 128-bit? 256-bit? 512-bit? 1Kb? 1Mb?
>>> Who can say? Certainly not me!
>>
>>You're in my house now. I set up the Symmetric Key Challenges at RSA,
>>and have been working in cryptographic computing for over 30 years.
>>
>>https://www.keylength.com/en/4/
>>
>
>>
>>To sum up: There's no reason yet to think cryptography can be easily
>>defeated.
>
>Indeed. Cryptography is almost always defeated due to flaws. Flaws
>in the implementation[*], or flaws in the Human side such as social
>engineering.

Yes. It's /always/ somebody else's fault when things go South.

If there is a problem, then we don't need excuses -- we need
solutions.

>[*] e.g. padding attacks, et alia.
--
"In this connexion, unquestionably the most significant
development was the disintegration, under Christian
influence, of classical conceptions of the family and
of family right."

On Sat, 26 Nov 2022 17:26:44 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:

>Paul S Person <psperson@old.netcom.invalid> writes:
>>On Thu, 24 Nov 2022 15:36:29 -0500, John W Kennedy
>><john.w.kennedy@gmail.com> wrote:
>>
>>
>>>>>
>>>>> Badly written software - or simply badly /conceived/ software - can kill
>>>>> any CPU.
>>>>
>>>> That's /always/ the excuse when the big promises turn out to be, at
>>>> best, overly optimistic.
>>>>
>>>> I seem to recall that the theory was that no such software could
>>>> possibly exist with the new OSes.
>>>
>>>Huh? ARM isn’t an OS; it’s a RISC architecture.
>>
>>It was claimed that the associated OSes would never lose anything.
>>IIRC.
>
>Claimed by whom?

The people making the promises about RISC. IIRC.

This was, what, 30 years ago? 25? Details fade.

>>It was the End of Windows, the End of DLL Hell, the End of Lost
>>Resources -- a New Age of Computing.
>
>Computing preceeded Windows and has never been dependent upon
>it.
>
>There is far more to the computing world than Microsoft.

It is the RISC proponents who were making these predictions.

And, BTW, my Windows computers run on /segmented archtectures/, not on
RISC.

IIRC, Intel /tried/ a RISC processor -- but nobody was willing to take
a chance on it for a really /lucrative/ market, like the PC Clone
market.
--
"In this connexion, unquestionably the most significant
development was the disintegration, under Christian
influence, of classical conceptions of the family and
of family right."

Paul S Person <psperson@old.netcom.invalid> writes:
>On Sat, 26 Nov 2022 17:25:29 GMT, scott@slp53.sl.home (Scott Lurndal)
>wrote:
>
>>"pete...@gmail.com" <petertrei@gmail.com> writes:
>>>On Friday, November 25, 2022 at 11:57:46 AM UTC-5, Paul S Person wrote:
>>>> On Thu, 24 Nov 2022 10:54:54 -0800, Dimensional Traveler
>>>> <dtr...@sonic.net> wrote:
>>
>>>> And, anyway, given how long they have had those Crays, up to how many
>>>> bits do you think they have identified /every single prime/ in that
>>>> range? And so can (relatively) quickly crack any encryption based on
>>>> prime numbers? 32-bit? 64-bit? 128-bit? 256-bit? 512-bit? 1Kb? 1Mb?
>>>> Who can say? Certainly not me!
>>>
>>>You're in my house now. I set up the Symmetric Key Challenges at RSA,
>>>and have been working in cryptographic computing for over 30 years.
>>>
>>>https://www.keylength.com/en/4/
>>>
>>
>>>
>>>To sum up: There's no reason yet to think cryptography can be easily
>>>defeated.
>>
>>Indeed. Cryptography is almost always defeated due to flaws. Flaws
>>in the implementation[*], or flaws in the Human side such as social
>>engineering.
>
>Yes. It's /always/ somebody else's fault when things go South.

I'm not sure what you are attempting to convey with that
statement. Care to be more specific?

>
>If there is a problem, then we don't need excuses -- we need
>solutions.

Security or convenience. Pick one.

Paul S Person <psperson@old.netcom.invalid> writes:
>On Sat, 26 Nov 2022 17:26:44 GMT, scott@slp53.sl.home (Scott Lurndal)
>wrote:
>
>>Paul S Person <psperson@old.netcom.invalid> writes:
>>>On Thu, 24 Nov 2022 15:36:29 -0500, John W Kennedy
>>><john.w.kennedy@gmail.com> wrote:
>>>
>>>
>>>>>>
>>>>>> Badly written software - or simply badly /conceived/ software - can kill
>>>>>> any CPU.
>>>>>
>>>>> That's /always/ the excuse when the big promises turn out to be, at
>>>>> best, overly optimistic.
>>>>>
>>>>> I seem to recall that the theory was that no such software could
>>>>> possibly exist with the new OSes.
>>>>
>>>>Huh? ARM isn�t an OS; it�s a RISC architecture.
>>>
>>>It was claimed that the associated OSes would never lose anything.
>>>IIRC.
>>
>>Claimed by whom?
>
>The people making the promises about RISC. IIRC.
>
>This was, what, 30 years ago? 25? Details fade.

I've been in the hardware and OS side of the business for longer
than that, and worked on and OS for the early RISC processor
from Motrola, the 88100. I've never heard such a claim about
"OS never loosing anything"[*].

>It is the RISC proponents who were making these predictions.

You'll need to find some citations to support your memory.

The claims about RISC have always been around the simplicity
of the hardware providing a path to easier and less
expensive implementation.

>
>And, BTW, my Windows computers run on /segmented archtectures/, not on
>RISC.

Windows hasn't run on a "segmented architecture" since NT was
introduced. And the current generation 64-bit x86 architecture
is very RISC-like in the hardware internals. They've done a masterful
job in keeping an ancient 16-bit architecture relevent in modern
times.

>
>IIRC, Intel /tried/ a RISC processor -- but nobody was willing to take
>a chance on it for a really /lucrative/ market, like the PC Clone
>market.

The main issue with the i860 (and later with the P7/Merced/Itanium)
is the difficulty in predicting code paths at compile time rather
than at run-time (as is done in modern RISC designs).

Both the failed processor projects (i860 and Itanium) performance
relied on advanced compiler technology being able to predict the
hot code-paths at compile time. Didn't work out. That was not
related to RISC, but rather the design choices of the processor
vendor.

RISC, as an acronym (Reduced Instruction Set Computer) is somewhat
of a misnomer today; Many modern RISC processors have hundreds
or even thousands (e.g. ARMv8) of instructions; many optional.

A more modern definition may be that a RISC processor today has
dedicated load and store instructions for accessing memory and
have a large general purpose register file (where in a classic
CISC CPU like the VAX or x86, many instructions can access memory
directly without first loading a value in a small register file).

[*] Although there were claims floating around about MVS being
fairly robust, that was due the OS code checking pre and post-
conditions in almost every function at the cost of some performance.

Paul S Person <psperson@old.netcom.invalid> schrieb:

> And, BTW, my Windows computers run on /segmented archtectures/, not on
> RISC.

You are still running a 32-bit versions of Windows? Wow.

scott@slp53.sl.home (Scott Lurndal) wrote in
news:VeNgL.134720$Ayma.73744@fx09.iad:

> Paul S Person <psperson@old.netcom.invalid> writes:
>>On Sat, 26 Nov 2022 17:25:29 GMT, scott@slp53.sl.home (Scott
>>Lurndal) wrote:
>>
>>>"pete...@gmail.com" <petertrei@gmail.com> writes:
>>>>On Friday, November 25, 2022 at 11:57:46 AM UTC-5, Paul S
>>>>Person wrote:
>>>>> On Thu, 24 Nov 2022 10:54:54 -0800, Dimensional Traveler
>>>>> <dtr...@sonic.net> wrote:
>>>
>>>>> And, anyway, given how long they have had those Crays, up to
>>>>> how many bits do you think they have identified /every
>>>>> single prime/ in that range? And so can (relatively) quickly
>>>>> crack any encryption based on prime numbers? 32-bit? 64-bit?
>>>>> 128-bit? 256-bit? 512-bit? 1Kb? 1Mb? Who can say? Certainly
>>>>> not me!
>>>>
>>>>You're in my house now. I set up the Symmetric Key Challenges
>>>>at RSA, and have been working in cryptographic computing for
>>>>over 30 years.
>>>>
>>>>https://www.keylength.com/en/4/
>>>>
>>>
>>>>
>>>>To sum up: There's no reason yet to think cryptography can be
>>>>easily defeated.
>>>
>>>Indeed. Cryptography is almost always defeated due to flaws.
>>>Flaws in the implementation[*], or flaws in the Human side such
>>>as social engineering.
>>
>>Yes. It's /always/ somebody else's fault when things go South.
>
> I'm not sure what you are attempting to convey with that
> statement. Care to be more specific?

He's insulting people who write cyptography apps with flaws they
don't want to admit to.
>
>>
>>If there is a problem, then we don't need excuses -- we need
>>solutions.
>
> Security or convenience. Pick one.
>
Or don't rely on computers on the internet to keep secrets.

--
Terry Austin

Proof that Alan Baker is a liar and a fool, and even stupider than
Lynn:
https://www.cbp.gov/newsroom/stats/sw-border-migration

"Terry Austin: like the polio vaccine, only with more asshole."
-- David Bilek

Jesus forgives sinners, not criminals.

scott@slp53.sl.home (Scott Lurndal) wrote in
news:huNgL.314169$Mlk.253947@fx17.iad:

> Paul S Person <psperson@old.netcom.invalid> writes:
>>On Sat, 26 Nov 2022 17:26:44 GMT, scott@slp53.sl.home (Scott
>>Lurndal) wrote:
>>
>>>Paul S Person <psperson@old.netcom.invalid> writes:
>>>>On Thu, 24 Nov 2022 15:36:29 -0500, John W Kennedy
>>>><john.w.kennedy@gmail.com> wrote:
>>>>
>>>>
>>>>>>>
>>>>>>> Badly written software - or simply badly /conceived/
>>>>>>> software - can kill any CPU.
>>>>>>
>>>>>> That's /always/ the excuse when the big promises turn out
>>>>>> to be, at best, overly optimistic.
>>>>>>
>>>>>> I seem to recall that the theory was that no such software
>>>>>> could possibly exist with the new OSes.
>>>>>
>>>>>Huh? ARM isn�t an OS; it�s a RISC architecture.
>>>>
>>>>It was claimed that the associated OSes would never lose
>>>>anything. IIRC.
>>>
>>>Claimed by whom?
>>
>>The people making the promises about RISC. IIRC.
>>
>>This was, what, 30 years ago? 25? Details fade.
>
> I've been in the hardware and OS side of the business for longer
> than that, and worked on and OS for the early RISC processor
> from Motrola, the 88100. I've never heard such a claim about
> "OS never loosing anything"[*].
>
>
>>It is the RISC proponents who were making these predictions.
>
> You'll need to find some citations to support your memory.
>
> The claims about RISC have always been around the simplicity
> of the hardware providing a path to easier and less
> expensive implementation.
>
I suspect that, as an industry insider, you've seen technical
claims by technical people, and he's seen marketing claims by
marketing "people".

And you know how accurate marketing claims are.

--
Terry Austin

Proof that Alan Baker is a liar and a fool, and even stupider than
Lynn:
https://www.cbp.gov/newsroom/stats/sw-border-migration

"Terry Austin: like the polio vaccine, only with more asshole."
-- David Bilek

Jesus forgives sinners, not criminals.

Thomas Koenig <tkoenig@netcologne.de> writes:
>Paul S Person <psperson@old.netcom.invalid> schrieb:
>
>> And, BTW, my Windows computers run on /segmented archtectures/, not on
>> RISC.
>
>You are still running a 32-bit versions of Windows? Wow.

32-bit versions of windows after WIN2k use a flat
32-bit paged address space. Win95 may have been still using
286-style segmentation - I never have used windows myself
thankfully.

On 11/27/22 12:53 PM, Scott Lurndal wrote:
> Paul S Person <psperson@old.netcom.invalid> writes:
>> On Sat, 26 Nov 2022 17:26:44 GMT, scott@slp53.sl.home (Scott Lurndal)
>> wrote:
>>
>>> Paul S Person <psperson@old.netcom.invalid> writes:
>>>> On Thu, 24 Nov 2022 15:36:29 -0500, John W Kennedy
>>>> <john.w.kennedy@gmail.com> wrote:
>>>>
>>>>
>>>>>>>
>>>>>>> Badly written software - or simply badly /conceived/ software - can kill
>>>>>>> any CPU.
>>>>>>
>>>>>> That's /always/ the excuse when the big promises turn out to be, at
>>>>>> best, overly optimistic.
>>>>>>
>>>>>> I seem to recall that the theory was that no such software could
>>>>>> possibly exist with the new OSes.
>>>>>
>>>>> Huh? ARM isn’t an OS; it’s a RISC architecture.
>>>>
>>>> It was claimed that the associated OSes would never lose anything.
>>>> IIRC.
>>>
>>> Claimed by whom?
>>
>> The people making the promises about RISC. IIRC.
>>
>> This was, what, 30 years ago? 25? Details fade.
>
> I've been in the hardware and OS side of the business for longer
> than that, and worked on and OS for the early RISC processor
> from Motrola, the 88100. I've never heard such a claim about
> "OS never loosing anything"[*].

I first encountered the RISC concept in the article in the IBM Journal
of R&D about the experimental 801 processor and I don’t recall ever
hearing such a claim, either. They talked about performance, compiler
simplification, and cost (especially by completely purging microcode).
And it’s fairly well known that, when Acorn picked up the concept, it
was to meet an “impossible” spec.

>> It is the RISC proponents who were making these predictions.
>
> You'll need to find some citations to support your memory.
>
> The claims about RISC have always been around the simplicity
> of the hardware providing a path to easier and less
> expensive implementation.
>
>>
>> And, BTW, my Windows computers run on /segmented archtectures/, not on
>> RISC.
>
> Windows hasn't run on a "segmented architecture" since NT was
> introduced. And the current generation 64-bit x86 architecture
> is very RISC-like in the hardware internals. They've done a masterful
> job in keeping an ancient 16-bit architecture relevent in modern
> times.

There is an ARM Windows, though, is there not?

>> IIRC, Intel /tried/ a RISC processor -- but nobody was willing to take
>> a chance on it for a really /lucrative/ market, like the PC Clone
>> market.
>
> The main issue with the i860 (and later with the P7/Merced/Itanium)
> is the difficulty in predicting code paths at compile time rather
> than at run-time (as is done in modern RISC designs).
>
> Both the failed processor projects (i860 and Itanium) performance
> relied on advanced compiler technology being able to predict the
> hot code-paths at compile time. Didn't work out. That was not
> related to RISC, but rather the design choices of the processor
> vendor.
>
> RISC, as an acronym (Reduced Instruction Set Computer) is somewhat
> of a misnomer today; Many modern RISC processors have hundreds
> or even thousands (e.g. ARMv8) of instructions; many optional.
>
> A more modern definition may be that a RISC processor today has
> dedicated load and store instructions for accessing memory and
> have a large general purpose register file (where in a classic
> CISC CPU like the VAX or x86, many instructions can access memory
> directly without first loading a value in a small register file).
>
> [*] Although there were claims floating around about MVS being
> fairly robust, that was due the OS code checking pre and post-
> conditions in almost every function at the cost of some performance.

Sometime in the 70s or 80s, IBM adopted a new policy of fixing all
reported security flaws in MVS. But even OS/360 had tried to be secure.

--
John W. Kennedy
Algernon Burbage, Lord Roderick, Father Martin, Bishop Baldwin,
King Pellinore, Captain Bailey, Merlin -- A Kingdom for a Stage!

In article <tlhr3e$3nihq$2@newsreader4.netcologne.de>,
Thomas Koenig <tkoenig@netcologne.de> wrote:
>An iPad has 3GB RAM these days, it is astonishing that serious
>business work can be done in a 2GB address space. But I suspect
>that many applications come from earlier times, when 2GB was
>luxury undreamt of.

(Hal Heydt)
Raspberry Pi 4 Model B comes with up to 8GB. I run the DunDraCon
con reg on a pair (replicated database) of 4GB models. I used to
run it on 1GB SBCs. The shift was because the Pi4B finally got
fast enough I/O to suit me. Con reg kind of rattles around loose
with that much RAM. I suspect that MariaDB just sucks the entire
database into memory.

In article <6FednTnd8bBqz-D-nZ2dnZfqn_adnZ2d@giganews.com>,
John W Kennedy <john.w.kennedy@gmail.com> wrote:
>Bwah-ha-ha-ha! I can remember when IBM’s most popular mainframe maxed
>out at 16,000 six-bit characters.

(Hal Heydt)
That would be the IBM 1401. Minimum memory was 1.2K.

Autocoder is one the languages I learned Way Back When. Then
proceeded to use it on an IBM S/360-30 with 1401 emulation because
that shop was still running Autocoder programs in production in
the early 1970s.

John W Kennedy <john.w.kennedy@gmail.com> writes:
>On 11/27/22 12:53 PM, Scott Lurndal wrote:
>> Paul S Person <psperson@old.netcom.invalid> writes:

>>> And, BTW, my Windows computers run on /segmented archtectures/, not on
>>> RISC.
>>
>> Windows hasn't run on a "segmented architecture" since NT was
>> introduced. And the current generation 64-bit x86 architecture
>> is very RISC-like in the hardware internals. They've done a masterful
>> job in keeping an ancient 16-bit architecture relevent in modern
>> times.
>
>There is an ARM Windows, though, is there not?

There have been Windows implementations for MIPS, ARM, Alpha and PowerPC.

None of which are segmented architectures (leaving aside MIPS KSEG0/1/2/U
which aren't segments in the traditional sense; the user portion of the
address space is paged).

On 28/11/2022 03:32, Paul S Person wrote:
> On Sat, 26 Nov 2022 17:26:44 GMT, scott@slp53.sl.home (Scott Lurndal)
> wrote:
>
>> Paul S Person <psperson@old.netcom.invalid> writes:
>>> On Thu, 24 Nov 2022 15:36:29 -0500, John W Kennedy
>>> <john.w.kennedy@gmail.com> wrote:
>>>
>>>
>>>>>>
>>>>>> Badly written software - or simply badly /conceived/ software - can kill
>>>>>> any CPU.
>>>>>
>>>>> That's /always/ the excuse when the big promises turn out to be, at
>>>>> best, overly optimistic.
>>>>>
>>>>> I seem to recall that the theory was that no such software could
>>>>> possibly exist with the new OSes.
>>>>
>>>> Huh? ARM isn’t an OS; it’s a RISC architecture.
>>>
>>> It was claimed that the associated OSes would never lose anything.
>>> IIRC.
>>
>> Claimed by whom?
>
> The people making the promises about RISC. IIRC.
>
> This was, what, 30 years ago? 25? Details fade.
>
>>> It was the End of Windows, the End of DLL Hell, the End of Lost
>>> Resources -- a New Age of Computing.
>>
>> Computing preceeded Windows and has never been dependent upon
>> it.
>>
>> There is far more to the computing world than Microsoft.
>
> It is the RISC proponents who were making these predictions.
>
> And, BTW, my Windows computers run on /segmented archtectures/, not on
> RISC.
>
No, it doesn't.

Just because your i[0-9] or Xeon processor handles the same old x86 code
that you ran on an 8088 doesn't mean a thing, the actual underlying
hardware is RISC. Well, RISC-ish, things are not simply divided between
the two - and they never really were. (Except, I suppose, for the 801.)

> IIRC, Intel /tried/ a RISC processor -- but nobody was willing to take
> a chance on it for a really /lucrative/ market, like the PC Clone
> market.

The Itanic was an over-priced mistake, the one thing they *did* get
right with it, at first, was it's ability to move data, which was why it
was so expensive. Later versions sacrificed this, probably due to
accountant-driven engineering changes.

Cheers,
Gary B-)

On 28/11/2022 10:08, Scott Lurndal wrote:
> John W Kennedy <john.w.kennedy@gmail.com> writes:
>> On 11/27/22 12:53 PM, Scott Lurndal wrote:
>>> Paul S Person <psperson@old.netcom.invalid> writes:
>
>>>> And, BTW, my Windows computers run on /segmented archtectures/, not on
>>>> RISC.
>>>
>>> Windows hasn't run on a "segmented architecture" since NT was
>>> introduced. And the current generation 64-bit x86 architecture
>>> is very RISC-like in the hardware internals. They've done a masterful
>>> job in keeping an ancient 16-bit architecture relevent in modern
>>> times.
>>
>> There is an ARM Windows, though, is there not?
>
> There have been Windows implementations for MIPS, ARM, Alpha and PowerPC.
>
You forgot SPARC. Rumour has it that NT 4 first booted on a SPARC CPU.
(But you know about rumours. :-) )

> None of which are segmented architectures (leaving aside MIPS KSEG0/1/2/U
> which aren't segments in the traditional sense; the user portion of the
> address space is paged).

I'd forgotten that about MIPS, my major recollection of that
architecture is being told by a Siemens-Nixdorf engineer that I didn't
know how to write code for UNIX systems. Specifically , that I did not
understand how flock/lockf/fcntl worked.

Of course I did... well, Stevens did... and I wasn't stupid enough *not*
to follow what he wrote.

Turns out the actual problem was that the default SysV time-slices were
fine for 8MHz (or was it KHz??), but things don't behave the same way at
36 (or whatever) thingies. So the RM-6000(??)[1] box got a critical OS
patch rushed out the door - when the client is Deutsche Bundespost you
don't risk (ha ha!) upsetting them[2].

Not that it mattered, just doing a sleep(0) after unlocking a file
released the current slice and stopped the batch process from hogging
the CPU and starving the interactive sessions.

Oh, and the SNI engineer lost his job. Making the big, bad happy does
have its payoffs. ;-)

Cheers,
Gary B-)

1 - IIRC, I built the base code (PFXplus) on an RM-600 (a small 32-user
departmental server) here in Melbourne (using a system at ICL/Fujitsu,
amusing, as fifteen years later I joined Fujitsu), the acceptance
testing was done on a small-ish RM-600 (a bigger, faster, departmental
server, 128 or so users) in Hamburg(?), but the final product was
unleashed on the biggest, fastest, expensive-est RM-6000 (and ooh, ever
*so* many users) (in Bonn) that SNI could produce, because, well, this
was German Computer Engineering at its finest. And it didn't work. So
SNI decided it was all our fault, until I faxed the fix to Axel in
Hamburg and he added one line to his source code. :->

2 - Deutsche Bundespost, and why you didn't piss them off.
For those who came in late, after the Second World War, the surviving
members of the Gestapo who were not co-opted by the Americans or Soviets
went into one of two places. In East Germany it was the Staasi. In
West Germany, Deutsche Bundespost.

Scott Lurndal <scott@slp53.sl.home> schrieb:
> John W Kennedy <john.w.kennedy@gmail.com> writes:
>>On 11/27/22 12:53 PM, Scott Lurndal wrote:
>>> Paul S Person <psperson@old.netcom.invalid> writes:
>
>>>> And, BTW, my Windows computers run on /segmented archtectures/, not on
>>>> RISC.
>>>
>>> Windows hasn't run on a "segmented architecture" since NT was
>>> introduced. And the current generation 64-bit x86 architecture
>>> is very RISC-like in the hardware internals. They've done a masterful
>>> job in keeping an ancient 16-bit architecture relevent in modern
>>> times.
>>
>>There is an ARM Windows, though, is there not?
>
> There have been Windows implementations for MIPS, ARM, Alpha and PowerPC.

Vobis (a German computer discounter at the
time) actually offered an Alpha with Windows, the
"Highscreen Alpha 5000". You can see their catalog at
https://www.schmalenstroer.net/books/Alte%20Kataloge/Vobis%20Denkzettel%201997-07-24.pdf
(have to scroll down a bit).

With its PALcode, the Alpha was designed with different operating
systems in mind.

> None of which are segmented architectures (leaving aside MIPS KSEG0/1/2/U
> which aren't segments in the traditional sense; the user portion of the
> address space is paged).

On Sun, 27 Nov 2022 18:26:39 GMT, Ninapenda Jibini
<taustinca@gmail.com> wrote:

>scott@slp53.sl.home (Scott Lurndal) wrote in
>news:VeNgL.134720$Ayma.73744@fx09.iad:
>
>> Paul S Person <psperson@old.netcom.invalid> writes:
>>>On Sat, 26 Nov 2022 17:25:29 GMT, scott@slp53.sl.home (Scott
>>>Lurndal) wrote:
>>>
>>>>"pete...@gmail.com" <petertrei@gmail.com> writes:
>>>>>On Friday, November 25, 2022 at 11:57:46 AM UTC-5, Paul S
>>>>>Person wrote:
>>>>>> On Thu, 24 Nov 2022 10:54:54 -0800, Dimensional Traveler
>>>>>> <dtr...@sonic.net> wrote:
>>>>
>>>>>> And, anyway, given how long they have had those Crays, up to
>>>>>> how many bits do you think they have identified /every
>>>>>> single prime/ in that range? And so can (relatively) quickly
>>>>>> crack any encryption based on prime numbers? 32-bit? 64-bit?
>>>>>> 128-bit? 256-bit? 512-bit? 1Kb? 1Mb? Who can say? Certainly
>>>>>> not me!
>>>>>
>>>>>You're in my house now. I set up the Symmetric Key Challenges
>>>>>at RSA, and have been working in cryptographic computing for
>>>>>over 30 years.
>>>>>
>>>>>https://www.keylength.com/en/4/
>>>>>
>>>>
>>>>>
>>>>>To sum up: There's no reason yet to think cryptography can be
>>>>>easily defeated.
>>>>
>>>>Indeed. Cryptography is almost always defeated due to flaws.
>>>>Flaws in the implementation[*], or flaws in the Human side such
>>>>as social engineering.
>>>
>>>Yes. It's /always/ somebody else's fault when things go South.
>>
>> I'm not sure what you are attempting to convey with that
>> statement. Care to be more specific?
>
>He's insulting people who write cyptography apps with flaws they
>don't want to admit to.

Indeed. Or, perhaps more broadly, secure systems that somehow turn out
to not be, in fact, secure.

But it's more general than that -- this is how "the Wise" in the
Middle Ages preserved their reputations when the plain fact was that
their spells to raise and control demons /did not work/: it was the
fault of the user.

We also saw a more recent example, where the problems with a nuclear
reactor in Japan was not the fault of the designers, but of the
landscape artists/installers, who, it was claimed, should have picked
a better location.

Of course things do occasionally go massively wrong. But then the
insurance companies invoke either "Act of War" or "Act of God". The
blame is /not/ placed on the insured.

>>>If there is a problem, then we don't need excuses -- we need
>>>solutions.
>>
>> Security or convenience. Pick one.
>>
>Or don't rely on computers on the internet to keep secrets.

Precisely.

Returning for a moment from the more extreme parts of the argument,
allow me to point out that secure sites, secure transactions, and
secure emails are for protecting things that would cause damage if
revealed /today/ but which are unlikely to matter if somehow worked
out five years from now. They are intended for financial transactions,
not protection from the NSA.

And a lot of the secure sign-in stuff is at least as much to convince
the bank that you are you (that is, is for their benefit in that it
allows them to prove legally that you signed in and did whatever you
now claim you didn't do) than anything else.
--
"In this connexion, unquestionably the most significant
development was the disintegration, under Christian
influence, of classical conceptions of the family and
of family right."

Paul S Person <psperson@old.netcom.invalid> wrote in
news:c4q9oh5cfddg5j9464g6p4flc7io1ddqca@4ax.com:

> On Sun, 27 Nov 2022 18:26:39 GMT, Ninapenda Jibini
> <taustinca@gmail.com> wrote:
>
>>scott@slp53.sl.home (Scott Lurndal) wrote in
>>news:VeNgL.134720$Ayma.73744@fx09.iad:
>>
>>> Paul S Person <psperson@old.netcom.invalid> writes:
>>>>On Sat, 26 Nov 2022 17:25:29 GMT, scott@slp53.sl.home (Scott
>>>>Lurndal) wrote:
>>>>
>>>>>"pete...@gmail.com" <petertrei@gmail.com> writes:
>>>>>>On Friday, November 25, 2022 at 11:57:46 AM UTC-5, Paul S
>>>>>>Person wrote:
>>>>>>> On Thu, 24 Nov 2022 10:54:54 -0800, Dimensional Traveler
>>>>>>> <dtr...@sonic.net> wrote:
>>>>>
>>>>>>> And, anyway, given how long they have had those Crays, up
>>>>>>> to how many bits do you think they have identified /every
>>>>>>> single prime/ in that range? And so can (relatively)
>>>>>>> quickly crack any encryption based on prime numbers?
>>>>>>> 32-bit? 64-bit? 128-bit? 256-bit? 512-bit? 1Kb? 1Mb? Who
>>>>>>> can say? Certainly not me!
>>>>>>
>>>>>>You're in my house now. I set up the Symmetric Key
>>>>>>Challenges at RSA, and have been working in cryptographic
>>>>>>computing for over 30 years.
>>>>>>
>>>>>>https://www.keylength.com/en/4/
>>>>>>
>>>>>
>>>>>>
>>>>>>To sum up: There's no reason yet to think cryptography can
>>>>>>be easily defeated.
>>>>>
>>>>>Indeed. Cryptography is almost always defeated due to
>>>>>flaws. Flaws in the implementation[*], or flaws in the Human
>>>>>side such as social engineering.
>>>>
>>>>Yes. It's /always/ somebody else's fault when things go South.
>>>
>>> I'm not sure what you are attempting to convey with that
>>> statement. Care to be more specific?
>>
>>He's insulting people who write cyptography apps with flaws they
>>don't want to admit to.
>
> Indeed. Or, perhaps more broadly, secure systems that somehow
> turn out to not be, in fact, secure.

Pretty much what I said.
>
> But it's more general than that -- this is how "the Wise" in the
> Middle Ages preserved their reputations when the plain fact was
> that their spells to raise and control demons /did not work/: it
> was the fault of the user.

Self delusion is at least as old as humanity, and likely older.

--
Terry Austin

"Terry Austin: like the polio vaccine, only with more asshole."
-- David Bilek

Jesus forgives sinners, not criminals.

n Sun, 27 Nov 2022 21:35:09 GMT, djheydt@kithrup.com (Dorothy J Heydt)
wrote:

>In article <tlhr3e$3nihq$2@newsreader4.netcologne.de>,
>Thomas Koenig <tkoenig@netcologne.de> wrote:
>>An iPad has 3GB RAM these days, it is astonishing that serious
>>business work can be done in a 2GB address space. But I suspect
>>that many applications come from earlier times, when 2GB was
>>luxury undreamt of.
>
>(Hal Heydt)
>Raspberry Pi 4 Model B comes with up to 8GB. I run the DunDraCon
>con reg on a pair (replicated database) of 4GB models. I used to
>run it on 1GB SBCs. The shift was because the Pi4B finally got
>fast enough I/O to suit me. Con reg kind of rattles around loose
>with that much RAM. I suspect that MariaDB just sucks the entire
>database into memory.

My HP Envy has 12GB (IIRC, the HP Pavilion has 8GB).

Back in the bad-old-days of Superfetch, the Envy was slowed down when
6GB were reserved for pre-downloade-direct-to-RAM junk -- and the
Pavilion was brought to its knees.

But that was years ago.
--
"In this connexion, unquestionably the most significant
development was the disintegration, under Christian
influence, of classical conceptions of the family and
of family right."