On Thu, 17 Nov 2022 16:32:09 GMT, djheydt@kithrup.com (Dorothy J
Heydt) wrote:

>In article <l9PbL.74464$1449.32517@fx14.iad>,
>Slcott Lurndal <slp53@pacbell.net> wrote:
>>Jibini Kula Tumbili Kujisalimisha <taustinca@gmail.com> writes:
>>>Lynn McGuire <lynnmcguire5@gmail.com> wrote in
>>>news:tkmbd3$uc0u$2@dont-email.me:
>>>
>>>> xkcd: Y2K and 2038
>>>> https://xkcd.com/2697/
>>>>
>>>> It shouldn't cost more than a trillion dollars or two to
>>>> investigate this.
>>>
>>>I'll start doing so as soon as the check clears.
>>>
>>>Or it could end up being as big a nothingburger as y2k was, because
>>>the people who run such systems aren't idiots.
>>
>>We (Burroughs) started preparing for 2000 in 1987. None of our customers
>>were affected by the rollover (and most customer software on those mainframes
>>used two-digit year fields in 1987).
>>
>>And, on the vast majority of unix/linux servers/desktops currently running,
>>
>>sizeof(time_t)=8 (64 bits)
>>
>>Which pushes the "2038" date out to December 4th, in the year 292,277,026,596.
>>
>>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.
>
>(Hal Heydt)
>And just because the hardware uses 32-bit words doesn't prevent it
>from having 64-bit numeric variables.

No, it doesn't. Or 128-bitters either.

But there may be a cost (in cycles used) for using them. And, perhaps,
also for having to remember to use special functions instead of
operators.
--
"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, 17 Nov 2022 21:22:42 +0000, 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.)

You might be disappointed. My mother's church has gone through three new
refrigerators in two years. Meanwhile a refrigerator my father bought in
the fifties to keep drinks cold for the tobacco croppers is still
running(unless it has stopped in the last few days) under a shelter
outback.

On 19/11/22 08:10, Magewolf wrote:
> On Thu, 17 Nov 2022 21:22:42 +0000, 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.)
>
> You might be disappointed. My mother's church has gone through three new
> refrigerators in two years.

The practice of chilling souls is a relatively recent phenomenon whose
premise is based on the false assumption that a condemned soul does not
begin to burn until it reaches the depths of hell. Perhaps unreasonable
to criticise the refrigerator, perhaps not but my personal opinion is
that smoke alarms in refrigerators should not be compulsory.

Meanwhile a refrigerator my father bought in
> the fifties to keep drinks cold for the tobacco croppers is still
> running(unless it has stopped in the last few days) under a shelter
> outback.

Drinks! Tobacco! A refrigerator obviously powered by the devil.

Gary R. Schmidt <grschmidt@acm.org> schrieb:
> On 18/11/2022 22:56, Thomas Koenig wrote:
>> Dorothy J Heydt <djheydt@kithrup.com> schrieb:
>>
>>> (Hal Heydt)
>>> And just because the hardware uses 32-bit words doesn't prevent it
>>> from having 64-bit numeric variables.
>>>
>>> All the programmers I knew in the 1970s were well aware of the
>>> Y2K issue then. One shop I was in in the mid-70s had a program
>>> to print 30 year amortization tables. Even then it was written
>>> to handle post-2000 end dates.
>>>
>>> For a long time, businesses usually replaced application systems
>>> about every 5 to 7 years. As a result, most IT people assumed
>>> that sometime from the late 1980s to early 1990s, the
>>> replacement cycle would shift everything to date routines that
>>> handled the century rollover. Then companies quit *replacing*
>>> systems and it became apparent (years before panic set in among
>>> the MBAs) that Something Needed to be Done. The bean counters
>>> weren't willing to spend the money to fix things until the panic
>>> struck in the late 1990s. At that point, it cost a lot more, of
>>> course.
>>
>> I always thought that the Y2K problem was one reason to move away
>> from legacy mainframe systems. If you have to redo the system
>> anyway, you might as well move to a different system.
>
> Replacing a mainframe with anything else is not trivial.
>
> Which is why most large mainframe sites still use mainframes.

Around the 2000 timeframe, a lot of mainframe sites became
no-longer-mainframe sites.

SAP R/3 had a lot to do with it, I believe. The company I worked
for still had 3270 terminal emulators running on PCs in the late
1990s. Before 2000, they were all gone when they replaced their
home-grown accounting system with SAP R/3, which ran client-server.

If that transformation saved any money, I'm not sure, the project
was horrible. No, it wasn't horrible, it was _really_ horrible.
Fortunately, I wasn't involved, I just heard a few tidbits from
people who were in that project.

> Nothing moves data about whilst transforming it as fast as a
> mainframe[1], which is where most, "We can move you to <insert
> Relational Database and x64 box> in six months", attempts hit the wall.

Those who can convert easily have already converted, I believe.

> Banks really don't like the idea of waiting 36 hours for the end-of-day
> processing to complete.
>
> Lots of people what think they're really shmott guys come a cropper on this.
>
> Cheers,
> Gary B-)
>
> 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 :-)

And SAP HANA will run exclusively on Linux by 2027, zOS will no
longer be supported. Nor will SAP continue to support Oracle or
or DB2 as unerlying database.

"Marketing by crowbar" comes to mind.

> I was
> in storage at SGI, they're really good at applying the *same* transform
> to a lot of data, not things like, "Here's a set of payroll rules, apply
> them to the records on this DASD, and write the resulting records on
> that DASD over there".
>
> 2 - Those big Linux systems are really, really good at recording and
> processing telephone calls looking for "interesting" content. For some
> reason the NSA buys them and installs them near large routing hubs in
> the USA, I can't think why...

The NSA has always been a big driver for computer development. Didn't
Cray implement POPCNT due to their demanding it?

On Sat, 19 Nov 2022 16:06:37 -0000 (UTC), Thomas Koenig
<tkoenig@netcologne.de> wrote:

>Gary R. Schmidt <grschmidt@acm.org> schrieb:
>> On 18/11/2022 22:56, Thomas Koenig wrote:
>>> Dorothy J Heydt <djheydt@kithrup.com> schrieb:
>>>
>>>> (Hal Heydt)
>>>> And just because the hardware uses 32-bit words doesn't prevent it
>>>> from having 64-bit numeric variables.
>>>>
>>>> All the programmers I knew in the 1970s were well aware of the
>>>> Y2K issue then. One shop I was in in the mid-70s had a program
>>>> to print 30 year amortization tables. Even then it was written
>>>> to handle post-2000 end dates.
>>>>
>>>> For a long time, businesses usually replaced application systems
>>>> about every 5 to 7 years. As a result, most IT people assumed
>>>> that sometime from the late 1980s to early 1990s, the
>>>> replacement cycle would shift everything to date routines that
>>>> handled the century rollover. Then companies quit *replacing*
>>>> systems and it became apparent (years before panic set in among
>>>> the MBAs) that Something Needed to be Done. The bean counters
>>>> weren't willing to spend the money to fix things until the panic
>>>> struck in the late 1990s. At that point, it cost a lot more, of
>>>> course.
>>>
>>> I always thought that the Y2K problem was one reason to move away
>>> from legacy mainframe systems. If you have to redo the system
>>> anyway, you might as well move to a different system.
>>
>> Replacing a mainframe with anything else is not trivial.
>>
>> Which is why most large mainframe sites still use mainframes.
>
>Around the 2000 timeframe, a lot of mainframe sites became
>no-longer-mainframe sites.
>
>SAP R/3 had a lot to do with it, I believe. The company I worked
>for still had 3270 terminal emulators running on PCs in the late
>1990s. Before 2000, they were all gone when they replaced their
>home-grown accounting system with SAP R/3, which ran client-server.
>
>If that transformation saved any money, I'm not sure, the project
>was horrible. No, it wasn't horrible, it was _really_ horrible.
>Fortunately, I wasn't involved, I just heard a few tidbits from
>people who were in that project.
>
>> Nothing moves data about whilst transforming it as fast as a
>> mainframe[1], which is where most, "We can move you to <insert
>> Relational Database and x64 box> in six months", attempts hit the wall.
>
>Those who can convert easily have already converted, I believe.
>
>> Banks really don't like the idea of waiting 36 hours for the end-of-day
>> processing to complete.
>>
>> Lots of people what think they're really shmott guys come a cropper on this.
>>
>> Cheers,
>> Gary B-)
>>
>> 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 :-)
>
>And SAP HANA will run exclusively on Linux by 2027, zOS will no
>longer be supported. Nor will SAP continue to support Oracle or
>or DB2 as unerlying database.
>
>"Marketing by crowbar" comes to mind.

IIRC, they used to change the plugs on each new generation of
mainframe. Forcing their competitors for peripherals to scramble to
catch up.

Apparently, old habits die hard.

>> I was
>> in storage at SGI, they're really good at applying the *same* transform
>> to a lot of data, not things like, "Here's a set of payroll rules, apply
>> them to the records on this DASD, and write the resulting records on
>> that DASD over there".
>>
>> 2 - Those big Linux systems are really, really good at recording and
>> processing telephone calls looking for "interesting" content. For some
>> reason the NSA buys them and installs them near large routing hubs in
>> the USA, I can't think why...
>
>The NSA has always been a big driver for computer development. Didn't
>Cray implement POPCNT due to their demanding it?

Well, they probable /were/ (and, for all I know, may still be) Cray's
most lucrative client.

And he who pays the piper calls the tune.
--
"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 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. :-)

Cheers,
Gary B-)

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?

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

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!

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