On Sun, 20 Nov 2022 12:08:11 -0800, The Horny Goat <lcraver@home.ca>
wrote:

<snip>

>Shortly before midnight they gathered all their staff in the server
>room

As early as 1998 I guessed what was coming and decided that there was
no way I was going to be working on New Year's Eve 1999/2000.

So I removed all mainframe skills (PL/I, JCL, CLIST, ISPF) from my
internal CV, and thus escaped the call up. Had a fantastic time at my
neighbour's party.

--
Jerry Brown

A cat may look at a king
(but probably won't bother)

On Mon, 21 Nov 2022 09:04:48 +0000, Jerry Brown
<jerry@jwbrown.co.uk.invalid> wrote:

>On Sun, 20 Nov 2022 12:08:11 -0800, The Horny Goat <lcraver@home.ca>
>wrote:
>
><snip>
>
>>Shortly before midnight they gathered all their staff in the server
>>room
>
>As early as 1998 I guessed what was coming and decided that there was
>no way I was going to be working on New Year's Eve 1999/2000.
>
>So I removed all mainframe skills (PL/I, JCL, CLIST, ISPF) from my
>internal CV, and thus escaped the call up. Had a fantastic time at my
>neighbour's party.

As I recall the missus and I just stayed home with two very nice
bottles of vino and were in bed not long after midnight - of course
our kids were pre-teens at that point so that might have had something
to do with it.

On Mon, 21 Nov 2022 18:55:47 +1100, "Gary R. Schmidt"
<grschmidt@acm.org> wrote:

>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.
>
> Cheers,
> Gary B-)

I remember as an undergrad writing code to determine what power I had
to raise 1.0001 to to make 1 = 2 to 4 decimal places.....

On Monday, 21 November 2022 at 09:05:46 UTC, Jerry Brown wrote:
> On Sun, 20 Nov 2022 12:08:11 -0800, The Horny Goat <lcr...@home.ca>
> wrote:
>
> <snip>
> >Shortly before midnight they gathered all their staff in the server
> >room
> As early as 1998 I guessed what was coming and decided that there was
> no way I was going to be working on New Year's Eve 1999/2000.
>
> So I removed all mainframe skills (PL/I, JCL, CLIST, ISPF) from my
> internal CV, and thus escaped the call up. Had a fantastic time at my
> neighbour's party.

But you could have been the nail in a
<https://en.wikipedia.org/wiki/For_Want_of_a_Nail>
scenario.

I suppose you weren't, but... one of our databases, not
mainframe, was fine on 01/01/2000, but then it ran into
a bug because it seemed to have a rule that years ending
in 00 aren't leap years. And no the software wasn't
written before 1900... as far as I know.

And maybe you or someone would have fixed that.

Or maybe the support ran out at the end of January 2000.

The result even could be deliberate.

In article <tl1m8r$29gpm$1@dont-email.me>,
Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>On 11/15/2022 6:09 PM, Dorothy J Heydt wrote:
>> In article <tkmbd3$uc0u$2@dont-email.me>,
>> Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>>> xkcd: Y2K and 2038
>>> https://xkcd.com/2697/
>>>
>>> It shouldn't cost more than a trillion dollars or two to investigate this.
>>>
>>> Explained at:
>>> https://www.explainxkcd.com/wiki/index.php/2697:_Y2K_and_2038
>>
>> (Hal Heydt)
>> The *nix world is well into the shift to 64-bit date variables.
>
>Yup. But has the client software been upgraded ?

(Hal Heydt)
Can't speak for anyone else (I retired about 10 years ago), but
the system I run (ConReg for DunDraCon), all dates used are in a
MariaDB database. Since they get added as either CURRENT or in
yyyy-mm-dd format, I'm not worried about Y2K38. Besides...I
expect it'll be Someone Else's Problem by then.

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

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.

Cheers,
Gary B-)

Gary R. Schmidt <grschmidt@acm.org> schrieb:
> 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.

No in-memory database like SAP HANA, then.

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.

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

The ARMv8 spec is up to 12000 pages. All that time will be needed for
somebody to read that, I believe :-)

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.
--
"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 11/22/2022 11:19 AM, 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.

Failed garbage collection threads in Java can kill a box.

Lynn

On 11/22/22 1:43 AM, Thomas Koenig wrote:
> Gary R. Schmidt <grschmidt@acm.org> schrieb:
>> 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.
>
> No in-memory database like SAP HANA, then.
>
> 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.

Bwah-ha-ha-ha! I can remember when IBM’s most popular mainframe maxed
out at 16,000 six-bit characters.

>> 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.
>
> The ARMv8 spec is up to 12000 pages. All that time will be needed for
> somebody to read that, I believe :-)

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

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.

Cheers,
Gary B-)

On Tue, 22 Nov 2022 14:06:25 -0600, Lynn McGuire
<lynnmcguire5@gmail.com> wrote:

>On 11/22/2022 11:19 AM, 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.
>
>Failed garbage collection threads in Java can kill a box.

I don't doubt it, but I don't think they are running Java.

At least, not under that name. The Squeezebox Touch shows:

OS: SqueezeOS - EN - utf8
Platform: arm-linux-gnueabl
Perl Version: 5.10.0 - arm-linux-gnueabl
Database Version: DBD::SQLite 1.34_01

Sadly, the processor is not identified.
--
"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 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.

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

In article <4vcfnh90akrius1iseafa4v42c6c7ssflp@4ax.com>,
Paul S Person <psperson@old.netcom.invalid> wrote:
>On Thu, 17 Nov 2022 21:22:42 GMT, djheydt@kithrup.com (Dorothy J
>Heydt) wrote:
>
>>In article <XnsAF4D56F32F62Dtaustincagmailcom@85.12.62.232>,
>>Ninapenda Jibini <taustinca@gmail.com> wrote:
>>>scott@slp53.sl.home (Scott Lurndal) wrote in
>>>news:l9PbL.74464$1449.32517@fx14.iad:
>>>
>>>> For the most part, a nothingburger. However, there are likely
>>>> lots of small embedded 32-bit processors in devices like routers
>>>> which may exhibit issues, if they're still running 16 years from
>>>> now.
>>>>
>>>You sound just like the doom criers ("Give me money or you'll
>>>DIE!!!") in the run up to y2k.
>>>
>>>How many appliances with embedded processors running today do you
>>>actually believe will still be functional in another 16 years?
>>>
>>>https://www.wired.com/2000/01/y2k-alarmist-wha-happened/
>>
>>(Hal Heydt)
>>Actually, more to the point... How many appliances with embedded
>>processors "care" what the date is? (As for longevity, if I go
>>out to buy a new refrigerator now, I sure as heck expect it to
>>still be functioning in 2038. Same for other major appliances.)
>
>Just make sure it is /not/ part of the "smart house/internet of
>things" nonsense.

(Hal Heydt)
Or--at least--will do its primary function(s) without any
connectivity. But, then, that would be one of my purchase
criteria to begin with.

I know a couple who are both in the top parts of a tech charity
plus R&D supporting arm. He was was asked once what sort of
"smart speaker" he had at home. His reply was, "None." The
reason being that corporate business gets discussed over the
table at meals and having something always listening is a *major*
security risk.

On Wed, 23 Nov 2022 20:42:22 GMT, djheydt@kithrup.com (Dorothy J
Heydt) wrote:

>In article <4vcfnh90akrius1iseafa4v42c6c7ssflp@4ax.com>,
>Paul S Person <psperson@old.netcom.invalid> wrote:
>>On Thu, 17 Nov 2022 21:22:42 GMT, djheydt@kithrup.com (Dorothy J
>>Heydt) wrote:
>>
>>>In article <XnsAF4D56F32F62Dtaustincagmailcom@85.12.62.232>,
>>>Ninapenda Jibini <taustinca@gmail.com> wrote:
>>>>scott@slp53.sl.home (Scott Lurndal) wrote in
>>>>news:l9PbL.74464$1449.32517@fx14.iad:
>>>>
>>>>> For the most part, a nothingburger. However, there are likely
>>>>> lots of small embedded 32-bit processors in devices like routers
>>>>> which may exhibit issues, if they're still running 16 years from
>>>>> now.
>>>>>
>>>>You sound just like the doom criers ("Give me money or you'll
>>>>DIE!!!") in the run up to y2k.
>>>>
>>>>How many appliances with embedded processors running today do you
>>>>actually believe will still be functional in another 16 years?
>>>>
>>>>https://www.wired.com/2000/01/y2k-alarmist-wha-happened/
>>>
>>>(Hal Heydt)
>>>Actually, more to the point... How many appliances with embedded
>>>processors "care" what the date is? (As for longevity, if I go
>>>out to buy a new refrigerator now, I sure as heck expect it to
>>>still be functioning in 2038. Same for other major appliances.)
>>
>>Just make sure it is /not/ part of the "smart house/internet of
>>things" nonsense.
>
>(Hal Heydt)
>Or--at least--will do its primary function(s) without any
>connectivity. But, then, that would be one of my purchase
>criteria to begin with.
>
>I know a couple who are both in the top parts of a tech charity
>plus R&D supporting arm. He was was asked once what sort of
>"smart speaker" he had at home. His reply was, "None." The
>reason being that corporate business gets discussed over the
>table at meals and having something always listening is a *major*
>security risk.

Indeed.

I /know/ that my HP Envy is not spying on me because it (or, rather,
both of the monitors it connects to) has /no/ camera and neither it
nor the monitors have a microphone.

The only /real/ way to be sure is to buy something that cannot connect
if even if you want it to. Or, more to the point, even if the
/manufacturer/ wants it to so much that you can't actually turn the
connection off.

As you may be able to guess, I am a firm believer in being just
paranoid enough (but not more).
--
"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 11/24/2022 9:13 AM, Paul S Person wrote:
> On Wed, 23 Nov 2022 20:42:22 GMT, djheydt@kithrup.com (Dorothy J
> Heydt) wrote:
>
>> In article <4vcfnh90akrius1iseafa4v42c6c7ssflp@4ax.com>,
>> Paul S Person <psperson@old.netcom.invalid> wrote:
>>> On Thu, 17 Nov 2022 21:22:42 GMT, djheydt@kithrup.com (Dorothy J
>>> Heydt) wrote:
>>>
>>>> In article <XnsAF4D56F32F62Dtaustincagmailcom@85.12.62.232>,
>>>> Ninapenda Jibini <taustinca@gmail.com> wrote:
>>>>> scott@slp53.sl.home (Scott Lurndal) wrote in
>>>>> news:l9PbL.74464$1449.32517@fx14.iad:
>>>>>
>>>>>> For the most part, a nothingburger. However, there are likely
>>>>>> lots of small embedded 32-bit processors in devices like routers
>>>>>> which may exhibit issues, if they're still running 16 years from
>>>>>> now.
>>>>>>
>>>>> You sound just like the doom criers ("Give me money or you'll
>>>>> DIE!!!") in the run up to y2k.
>>>>>
>>>>> How many appliances with embedded processors running today do you
>>>>> actually believe will still be functional in another 16 years?
>>>>>
>>>>> https://www.wired.com/2000/01/y2k-alarmist-wha-happened/
>>>>
>>>> (Hal Heydt)
>>>> Actually, more to the point... How many appliances with embedded
>>>> processors "care" what the date is? (As for longevity, if I go
>>>> out to buy a new refrigerator now, I sure as heck expect it to
>>>> still be functioning in 2038. Same for other major appliances.)
>>>
>>> Just make sure it is /not/ part of the "smart house/internet of
>>> things" nonsense.
>>
>> (Hal Heydt)
>> Or--at least--will do its primary function(s) without any
>> connectivity. But, then, that would be one of my purchase
>> criteria to begin with.
>>
>> I know a couple who are both in the top parts of a tech charity
>> plus R&D supporting arm. He was was asked once what sort of
>> "smart speaker" he had at home. His reply was, "None." The
>> reason being that corporate business gets discussed over the
>> table at meals and having something always listening is a *major*
>> security risk.
>
> Indeed.
>
> I /know/ that my HP Envy is not spying on me because it (or, rather,
> both of the monitors it connects to) has /no/ camera and neither it
> nor the monitors have a microphone.
>
> The only /real/ way to be sure is to buy something that cannot connect
> if even if you want it to. Or, more to the point, even if the
> /manufacturer/ wants it to so much that you can't actually turn the
> connection off.
>
> As you may be able to guess, I am a firm believer in being just
> paranoid enough (but not more).

No such thing as too paranoid, why would you even suggest it! You must
be part of the conspiracy!

--
I've done good in this world. Now I'm tired and just want to be a cranky
dirty old man.

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.

> But perhaps my memory is playing me false on that point.
>
> The point is -- been there, been promised that, didn't happen.

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

Jerry Brown <jerry@jwbrown.co.uk.invalid> wrote:
> On Sun, 20 Nov 2022 12:08:11 -0800, The Horny Goat <lcraver@home.ca>
> wrote:
>
> <snip>
>
>>Shortly before midnight they gathered all their staff in the server
>>room
>
> As early as 1998 I guessed what was coming and decided that there was
> no way I was going to be working on New Year's Eve 1999/2000.
>
> So I removed all mainframe skills (PL/I, JCL, CLIST, ISPF) from my
> internal CV, and thus escaped the call up. Had a fantastic time at my
> neighbour's party.

Not much of a party animal, so i did the oppposite...I volunteered
whenever possible (as did a number of my coworkers). It didn't hurt
that for New Year's Eve they were paying a rate equal to eight times
the hourly equivalent of my salary.

Robert
--
Robert K. Shull Email: rkshull at rosettacon dot com

Thomas Koenig <tkoenig@netcologne.de> wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>> On 11/15/2022 6:09 PM, Dorothy J Heydt wrote:
>>> In article <tkmbd3$uc0u$2@dont-email.me>,
>>> Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>>>> xkcd: Y2K and 2038
>>>> https://xkcd.com/2697/
>>>>
>>>> It shouldn't cost more than a trillion dollars or two to investigate this.
>>>>
>>>> Explained at:
>>>> https://www.explainxkcd.com/wiki/index.php/2697:_Y2K_and_2038
>>>
>>> (Hal Heydt)
>>> The *nix world is well into the shift to 64-bit date variables.
>>
>> Yup. But has the client software been upgraded ?
>
> Recompile and you're done, unless your code made some seriously
> bad assumptions about pointers. With the 64-bit Unices which are
> used today, sizeof(long) == sizeof(void *) still holds, same as
> in the day of the VAX.

Not that easy. Binary data files, many backed up to tape and required to be
restorable for 7-10 years, mean that you have to support that legacy format
for the entire period. You also have to be able to differentiate between the
two when you do a read. If it's client-server software the server has to be
able to handle both formats if the client is in the hands of the enemy. Just
because you tell a customer that they have to upgrade doesn't mean they're
going to do it.
I ran into this problem a few years back recompiling an old piece of Usenet
software. The change from 32-bit to 64-bit went fine until it tried to read
the old binary data files, which had records with 32-bit timestamps.
I think I ended up writing a quick program to read the files with 32-bit
timestamps and copy them to files with 64-bit timestamps. But I didn't have
to worry about years of backups.

Robert
--
Robert K. Shull Email: rkshull at rosettacon dot com

rkshullat@rosettacondot.com <rkshullat@rosettacondot.com> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> wrote:
>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>> On 11/15/2022 6:09 PM, Dorothy J Heydt wrote:
>>>> In article <tkmbd3$uc0u$2@dont-email.me>,
>>>> Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>>>>> xkcd: Y2K and 2038
>>>>> https://xkcd.com/2697/
>>>>>
>>>>> It shouldn't cost more than a trillion dollars or two to investigate this.
>>>>>
>>>>> Explained at:
>>>>> https://www.explainxkcd.com/wiki/index.php/2697:_Y2K_and_2038
>>>>
>>>> (Hal Heydt)
>>>> The *nix world is well into the shift to 64-bit date variables.
>>>
>>> Yup. But has the client software been upgraded ?
>>
>> Recompile and you're done, unless your code made some seriously
>> bad assumptions about pointers. With the 64-bit Unices which are
>> used today, sizeof(long) == sizeof(void *) still holds, same as
>> in the day of the VAX.
>
> Not that easy. Binary data files, many backed up to tape and required to be
> restorable for 7-10 years, mean that you have to support that legacy format
> for the entire period.

Binary formats are certainly a problem, especially if they are not well
thought out. Using naked ints or longs for anything is a good example.

As an example, gfortran inherited an unformatted file format from
g77 where record lengths were specified as "long". Of course, this
led to incompatibilities between 32-bit and 64-bit computers.
This was resolved by using 32-bit extensible records, in a format
stolen^H^H^H^H^H^Hinspired by and compatible with the Intel compiler,
plus an option to set the record marker to 64 bits for compatibility
to read older files.

Big and little endian is another thing.

> You also have to be able to differentiate between the
> two when you do a read. If it's client-server software the server has to be
> able to handle both formats if the client is in the hands of the enemy. Just
> because you tell a customer that they have to upgrade doesn't mean they're
> going to do it.

With client server software, there is less excuse for lazy design. The
first RFC for XDR was published 1987, and it had 64-bit integers
(charmingly called "hyper integer").

But then, just because the right way to do it was known, that does not
mean that people actually got it right, or cared if they did.

> I ran into this problem a few years back recompiling an old piece of Usenet
> software. The change from 32-bit to 64-bit went fine until it tried to read
> the old binary data files, which had records with 32-bit timestamps.
> I think I ended up writing a quick program to read the files with 32-bit
> timestamps and copy them to files with 64-bit timestamps. But I didn't have
> to worry about years of backups.

That is probably the best way.

On Thu, 24 Nov 2022 10:54:54 -0800, Dimensional Traveler
<dtravel@sonic.net> wrote:

>On 11/24/2022 9:13 AM, Paul S Person wrote:
>> On Wed, 23 Nov 2022 20:42:22 GMT, djheydt@kithrup.com (Dorothy J
>> Heydt) wrote:
>>
>>> In article <4vcfnh90akrius1iseafa4v42c6c7ssflp@4ax.com>,
>>> Paul S Person <psperson@old.netcom.invalid> wrote:
>>>> On Thu, 17 Nov 2022 21:22:42 GMT, djheydt@kithrup.com (Dorothy J
>>>> Heydt) wrote:
>>>>
>>>>> In article <XnsAF4D56F32F62Dtaustincagmailcom@85.12.62.232>,
>>>>> Ninapenda Jibini <taustinca@gmail.com> wrote:
>>>>>> scott@slp53.sl.home (Scott Lurndal) wrote in
>>>>>> news:l9PbL.74464$1449.32517@fx14.iad:
>>>>>>
>>>>>>> For the most part, a nothingburger. However, there are likely
>>>>>>> lots of small embedded 32-bit processors in devices like routers
>>>>>>> which may exhibit issues, if they're still running 16 years from
>>>>>>> now.
>>>>>>>
>>>>>> You sound just like the doom criers ("Give me money or you'll
>>>>>> DIE!!!") in the run up to y2k.
>>>>>>
>>>>>> How many appliances with embedded processors running today do you
>>>>>> actually believe will still be functional in another 16 years?
>>>>>>
>>>>>> https://www.wired.com/2000/01/y2k-alarmist-wha-happened/
>>>>>
>>>>> (Hal Heydt)
>>>>> Actually, more to the point... How many appliances with embedded
>>>>> processors "care" what the date is? (As for longevity, if I go
>>>>> out to buy a new refrigerator now, I sure as heck expect it to
>>>>> still be functioning in 2038. Same for other major appliances.)
>>>>
>>>> Just make sure it is /not/ part of the "smart house/internet of
>>>> things" nonsense.
>>>
>>> (Hal Heydt)
>>> Or--at least--will do its primary function(s) without any
>>> connectivity. But, then, that would be one of my purchase
>>> criteria to begin with.
>>>
>>> I know a couple who are both in the top parts of a tech charity
>>> plus R&D supporting arm. He was was asked once what sort of
>>> "smart speaker" he had at home. His reply was, "None." The
>>> reason being that corporate business gets discussed over the
>>> table at meals and having something always listening is a *major*
>>> security risk.
>>
>> Indeed.
>>
>> I /know/ that my HP Envy is not spying on me because it (or, rather,
>> both of the monitors it connects to) has /no/ camera and neither it
>> nor the monitors have a microphone.
>>
>> The only /real/ way to be sure is to buy something that cannot connect
>> if even if you want it to. Or, more to the point, even if the
>> /manufacturer/ wants it to so much that you can't actually turn the
>> connection off.
>>
>> As you may be able to guess, I am a firm believer in being just
>> paranoid enough (but not more).
>
>No such thing as too paranoid, why would you even suggest it! You must
>be part of the conspiracy!

I don't entirely disagree with you, but most things /do/ have limits.

Back when the NSA reading emails was in the news, some people insisted
on going to encrypted email. I did not.

I did not because I was sufficiently paranoid to realize that the NSA
had very likely broken /all/ known encryption systems, particularly
computer-based, so it made more sense to just take it for granted that
would be reading mine and not worry about it. Why worry about what you
can't fix? Particularly if you aren't writing about anything remotely
interesting to anyone else.

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!
--
"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 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.
IIRC.

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

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:
>
> >On 11/24/2022 9:13 AM, Paul S Person wrote:
> >> On Wed, 23 Nov 2022 20:42:22 GMT, djh...@kithrup.com (Dorothy J
> >> Heydt) wrote:
> >>
> >>> In article <4vcfnh90akrius1is...@4ax.com>,
> >>> Paul S Person <pspe...@old.netcom.invalid> wrote:
> >>>> On Thu, 17 Nov 2022 21:22:42 GMT, djh...@kithrup.com (Dorothy J
> >>>> Heydt) wrote:
> >>>>
> >>>>> In article <XnsAF4D56F32F62D...@85.12.62.232>,
> >>>>> Ninapenda Jibini <taus...@gmail.com> wrote:
> >>>>>> sc...@slp53.sl.home (Scott Lurndal) wrote in
> >>>>>> news:l9PbL.74464$1449....@fx14.iad:
> >>>>>>
> >>>>>>> For the most part, a nothingburger. However, there are likely
> >>>>>>> lots of small embedded 32-bit processors in devices like routers
> >>>>>>> which may exhibit issues, if they're still running 16 years from
> >>>>>>> now.
> >>>>>>>
> >>>>>> You sound just like the doom criers ("Give me money or you'll
> >>>>>> DIE!!!") in the run up to y2k.
> >>>>>>
> >>>>>> How many appliances with embedded processors running today do you
> >>>>>> actually believe will still be functional in another 16 years?
> >>>>>>
> >>>>>> https://www.wired.com/2000/01/y2k-alarmist-wha-happened/
> >>>>>
> >>>>> (Hal Heydt)
> >>>>> Actually, more to the point... How many appliances with embedded
> >>>>> processors "care" what the date is? (As for longevity, if I go
> >>>>> out to buy a new refrigerator now, I sure as heck expect it to
> >>>>> still be functioning in 2038. Same for other major appliances.)
> >>>>
> >>>> Just make sure it is /not/ part of the "smart house/internet of
> >>>> things" nonsense.
> >>>
> >>> (Hal Heydt)
> >>> Or--at least--will do its primary function(s) without any
> >>> connectivity. But, then, that would be one of my purchase
> >>> criteria to begin with.
> >>>
> >>> I know a couple who are both in the top parts of a tech charity
> >>> plus R&D supporting arm. He was was asked once what sort of
> >>> "smart speaker" he had at home. His reply was, "None." The
> >>> reason being that corporate business gets discussed over the
> >>> table at meals and having something always listening is a *major*
> >>> security risk.
> >>
> >> Indeed.
> >>
> >> I /know/ that my HP Envy is not spying on me because it (or, rather,
> >> both of the monitors it connects to) has /no/ camera and neither it
> >> nor the monitors have a microphone.
> >>
> >> The only /real/ way to be sure is to buy something that cannot connect
> >> if even if you want it to. Or, more to the point, even if the
> >> /manufacturer/ wants it to so much that you can't actually turn the
> >> connection off.
> >>
> >> As you may be able to guess, I am a firm believer in being just
> >> paranoid enough (but not more).
> >
> >No such thing as too paranoid, why would you even suggest it! You must
> >be part of the conspiracy!
> I don't entirely disagree with you, but most things /do/ have limits.
>
> Back when the NSA reading emails was in the news, some people insisted
> on going to encrypted email. I did not.
>
> I did not because I was sufficiently paranoid to realize that the NSA
> had very likely broken /all/ known encryption systems, particularly
> computer-based, so it made more sense to just take it for granted that
> would be reading mine and not worry about it. Why worry about what you
> can't fix? Particularly if you aren't writing about anything remotely
> interesting to anyone else.
>
> 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/

On symmetric ciphers, the largest key I know to have been brute forced
was 64 bits long. It took 4 years and 10s of thousands of machines, around
2007. NIST recommended symmetric key length is now 192 bits, 3x10^39
times as hard. This is regarded as safe for classified material by the US
government, so I expect it's safe and intact.

On asymmetric ciphers, RSA now has a recommended modulus
length of 7680 bits. The number of primes under a given number
is approximately n/ln(n), For 7680, n is about 10^2311.

The largest semiprime publicly factored to date is 829 bits. n for that is about
10^249.

There aren't enough fundamental particles in the universe to approach
these numbers.

It has not been proven that there is no way of factoring large moduli
quickly, but if there were one found, I'd expect we'd have seen some clues,
for example odd transactions in the Bitcoin blockchain.

Quantum computing could in theory be applied, but again, there's no
hint of a QC with even a small fraction of the capability required. Post
Quantum Cryptography is a very active field, and ways to protect data
even against QC are known.

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

Pt

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.

The selling points of ARM have always been performance, low power
consumption, and, lately, system-on-a-chip suitability
> 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.

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