xkcd: Y2K and 2038
https://xkcd.com/2697/
It shouldn't cost more than a trillion dollars or two to
investigate this.
Lynn McGuire <[email protected]> wrote in news:tkmbd3$uc0u$[email protected]:
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.
Lynn McGuire <[email protected]> wrote in >news:tkmbd3$uc0u$[email protected]:
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.
[email protected] (Scott Lurndal) wrote in >news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there are likelyYou sound just like the doom criers ("Give me money or you'll
lots of small embedded 32-bit processors in devices like routers
which may exhibit issues, if they're still running 16 years from
now.
DIE!!!") in the run up to y2k.
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
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.
Ninapenda Jibini <[email protected]> writes:
[email protected] (Scott Lurndal) wrote in >>news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there are likelyYou sound just like the doom criers ("Give me money or you'll
lots of small embedded 32-bit processors in devices like routers
which may exhibit issues, if they're still running 16 years from
now.
DIE!!!") in the run up to y2k.
I said "if they're still running 16 years from now", which is
quite unlikely. However, cheap-ass manufacturers may continue
to use the same software in newer devices, sadly.
[email protected] (Scott Lurndal) on Sat, 12 Nov 2022 16:57:44 GMT
typed in rec.arts.sf.written the following:
Ninapenda Jibini <[email protected]> writes:
[email protected] (Scott Lurndal) wrote in >>>news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there are likelyYou sound just like the doom criers ("Give me money or you'll
lots of small embedded 32-bit processors in devices like routers
which may exhibit issues, if they're still running 16 years from
now.
DIE!!!") in the run up to y2k.
I said "if they're still running 16 years from now", which is
quite unlikely. However, cheap-ass manufacturers may continue
to use the same software in newer devices, sadly.
It is possible. As the cliche was "back in my day" - most of the
current batch of programmers have no idea that there are COBOL
programs still running which were compiled before they were born.
The question is, how many people / organizations have a system
which has been running, is running, will be running, with little or no
reason to replace it with a New And Improved Hardware?
On Fri, 11 Nov 2022 14:30:25 -0600, Lynn McGuire
<[email protected]> 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
So, two questions occur:
1. This appears to be a Unix problem. Apart of Unix and Linux and
friends, will anyone /else/ be affected?
2. Why go to 33 bits? If the problem is that 32 is too few, why not
just jump to 64 and save the future some problems? Is doing things in
the clearly least optimal way (you are going to end up with 40 bits
anyway, since they come in 8-bit groups called "bytes") a Unix/Linux >tradition? Do Real Programmers always to things the Most Difficult Way >Possible?
Jibini Kula Tumbili Kujisalimisha <[email protected]> writes:
Lynn McGuire <[email protected]> wrote in
news:tkmbd3$uc0u$[email protected]:
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.
Y2K was a "nothingburger" because of all the work done to
stop it from
being a triple-decker shit sandwitch. If everyone had treated
it like no big deal, it would have been a very big deal.
Dave Van Domelen, really tired of the attitude people have
that if a
problem is fixed, then it was never a problem in the first
place.
On Fri, 11 Nov 2022 14:30:25 -0600, Lynn McGuire
<[email protected]> 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
So, two questions occur:
1. This appears to be a Unix problem. Apart of Unix and Linux and
friends, will anyone /else/ be affected?
2. Why go to 33 bits? If the problem is that 32 is too few, why not
just jump to 64 and save the future some problems? Is doing things in
the clearly least optimal way (you are going to end up with 40 bits
anyway, since they come in 8-bit groups called "bytes") a Unix/Linux tradition? Do Real Programmers always to things the Most Difficult Way Possible?
Ninapenda Jibini <[email protected]> writes:
[email protected] (Scott Lurndal) wrote in >>news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there are likelyYou sound just like the doom criers ("Give me money or you'll
lots of small embedded 32-bit processors in devices like routers
which may exhibit issues, if they're still running 16 years from
now.
DIE!!!") in the run up to y2k.
I said "if they're still running 16 years from now", which is
quite unlikely.
However, cheap-ass manufacturers may continue
to use the same software in newer devices, sadly.
On Fri, 11 Nov 2022 14:30:25 -0600, Lynn McGuire
<[email protected]> 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
So, two questions occur:
1. This appears to be a Unix problem. Apart of Unix and Linux
and friends, will anyone /else/ be affected?
2. Why go to 33 bits? If the problem is that 32 is too few, why
not just jump to 64 and save the future some problems? Is doing
things in the clearly least optimal way (you are going to end up
with 40 bits anyway, since they come in 8-bit groups called
"bytes") a Unix/Linux tradition? Do Real Programmers always to
things the Most Difficult Way Possible?
On 11/12/2022 9:42 AM, Scott Lurndal wrote:
Jibini Kula Tumbili Kujisalimisha <[email protected]> writes:
Lynn McGuire <[email protected]> wrote in
news:tkmbd3$uc0u$[email protected]:
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.
The operating systems arefixed but the customer software is not.
The software at minimum needs a recompile. But the software
needs a going through to see if it is just stuffing the time and
date information into a 32 bit signed integer.
[email protected] (Scott Lurndal) on Sat, 12 Nov 2022 16:57:44 GMT
typed in rec.arts.sf.written the following:
Ninapenda Jibini <[email protected]> writes:
[email protected] (Scott Lurndal) wrote in
news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there are likelyYou sound just like the doom criers ("Give me money or you'll
lots of small embedded 32-bit processors in devices like routers
which may exhibit issues, if they're still running 16 years from
now.
DIE!!!") in the run up to y2k.
I said "if they're still running 16 years from now", which is
quite unlikely. However, cheap-ass manufacturers may continue
to use the same software in newer devices, sadly.
It is possible. As the cliche was "back in my day" - most of the current batch of programmers have no idea that there are COBOL
programs still running which were compiled before they were born.
The question is, how many people / organizations have a system
which has been running, is running, will be running, with little or no
reason to replace it with a New And Improved Hardware?
Lynn McGuire <[email protected]> wrote in news:tkor96$177j$[email protected]:
On 11/12/2022 9:42 AM, Scott Lurndal wrote:Do you anticipate a lot of problems getting that done in the next
Jibini Kula Tumbili Kujisalimisha <[email protected]> writes:
Lynn McGuire <[email protected]> wrote in
news:tkmbd3$uc0u$[email protected]:
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.
The operating systems arefixed but the customer software is not.
The software at minimum needs a recompile. But the software
needs a going through to see if it is just stuffing the time and
date information into a 32 bit signed integer.
16 years?
[email protected] (Dave Van Domelen) wrote in
Dave Van Domelen, really tired of the attitude people haveCheese Eating Surrender Monkey, really tired of idiots who assume
that if a
problem is fixed, then it was never a problem in the first
place.
that because professionals did their job once, they can't possibly do
so again.
It's not a big deal if those professionals keep doing their jobs, and
- this is the part you're apparently too stupid to understand -
*doing* *their* *jobs* *isn't* *a* *big* *deal* *either*.
It's *routine.*
[email protected] (Scott Lurndal) wrote in news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there are likelyYou sound just like the doom criers ("Give me money or you'll
lots of small embedded 32-bit processors in devices like routers
which may exhibit issues, if they're still running 16 years from
now.
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/
pyotr filipivich <[email protected]> writes:
[email protected] (Scott Lurndal) on Sat, 12 Nov 2022 16:57:44 GMT
typed in rec.arts.sf.written the following:
Ninapenda Jibini <[email protected]> writes:
[email protected] (Scott Lurndal) wrote in
news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there are likelyYou sound just like the doom criers ("Give me money or you'll
lots of small embedded 32-bit processors in devices like routers
which may exhibit issues, if they're still running 16 years from
now.
DIE!!!") in the run up to y2k.
I said "if they're still running 16 years from now", which is
quite unlikely. However, cheap-ass manufacturers may continue
to use the same software in newer devices, sadly.
It is possible. As the cliche was "back in my day" - most of the
current batch of programmers have no idea that there are COBOL
programs still running which were compiled before they were born.
The question is, how many people / organizations have a system
which has been running, is running, will be running, with little or no
reason to replace it with a New And Improved Hardware?
Most of those workloads are still running on legacy iron, and will
for the forseeable future (IBM, Unisys). Modern workloads based on
current distributed technologies (the world-wide web, for instance)
are either already 64-bit clean.
The time_t issue is uniquely an
Unix issue and those, aside from the low-end consumer grade hardware mentioned
above, are largely already 64-bit clean.
The competence of programmers varies, and it is likely that there is
a fair amount of software that treats time_t as interchangable with
the C/C++ 'int' type, which is prima facia broken, but works in 32-bit environments (and may continue to work post 2038 depending on the
context of the usage).
On Fri, 11 Nov 2022 14:30:25 -0600, Lynn McGuire
<[email protected]> 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
So, two questions occur:
1. This appears to be a Unix problem. Apart of Unix and Linux and
friends, will anyone /else/ be affected?
2. Why go to 33 bits? If the problem is that 32 is too few, why not
just jump to 64 and save the future some problems? Is doing things in
the clearly least optimal way (you are going to end up with 40 bits
anyway, since they come in 8-bit groups called "bytes") a Unix/Linux tradition? Do Real Programmers always to things the Most Difficult Way Possible?
[email protected] (Scott Lurndal) on Sat, 12 Nov 2022 16:57:44 GMT
typed in rec.arts.sf.written the following:
Ninapenda Jibini <[email protected]> writes:
[email protected] (Scott Lurndal) wrote in
news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there are likelyYou sound just like the doom criers ("Give me money or you'll
lots of small embedded 32-bit processors in devices like routers
which may exhibit issues, if they're still running 16 years from
now.
DIE!!!") in the run up to y2k.
I said "if they're still running 16 years from now", which is
quite unlikely. However, cheap-ass manufacturers may continue
to use the same software in newer devices, sadly.
It is possible. As the cliche was "back in my day" - most of the current batch of programmers have no idea that there are COBOL
programs still running which were compiled before they were born.
The question is, how many people / organizations have a system
which has been running, is running, will be running, with little or no
reason to replace it with a New And Improved Hardware?
On 11/12/2022 2:35 PM, Ninapenda Jibini wrote:
[email protected] (Dave Van Domelen) wrote in
Dave Van Domelen, really tired of the attitude people haveCheese Eating Surrender Monkey, really tired of idiots who
that if a
problem is fixed, then it was never a problem in the first
place.
assume that because professionals did their job once, they
can't possibly do so again.
It's not a big deal if those professionals keep doing their
jobs, and - this is the part you're apparently too stupid to
understand - *doing* *their* *jobs* *isn't* *a* *big* *deal*
*either*.
It's *routine.*
Not a regular reader of the Risks digest, then.
On 11/12/2022 1:37 PM, Ninapenda Jibini wrote:
Lynn McGuire <[email protected]> wrote in
news:tkor96$177j$[email protected]:
On 11/12/2022 9:42 AM, Scott Lurndal wrote:Do you anticipate a lot of problems getting that done in the
Jibini Kula Tumbili Kujisalimisha <[email protected]>
writes:
Lynn McGuire <[email protected]> wrote in
news:tkmbd3$uc0u$[email protected]:
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.
The operating systems arefixed but the customer software is
not.
The software at minimum needs a recompile. But the software
needs a going through to see if it is just stuffing the time
and date information into a 32 bit signed integer.
next 16 years?
Hard to tell. There is an enormous amount of custom software in
companies.
On 11/12/22 11:32 AM, Ninapenda Jibini wrote:
[email protected] (Scott Lurndal) wrote in
news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there areYou sound just like the doom criers ("Give me money or you'll
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.
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/
Do not misunderstand. The Y2K problem was very real, and started
causing serious damage at least as early as August 16, 1972
(9999 days before Y2K), when tapes on IBM mainframes that were
supposed to be marked “retain forever” started to be marked
"ready for recycling” instead.
(It was also about that time that our operating system—to be
fair to IBM, it was a beta—started crashing every day at
exactly 7:00PM EST. It turned out to be caused by a zero divide
in the rollover-GMT code—7:00PM EST is midnight, GMT. And why
the zero divide? Ultimately, because one IBM coder was aware
that, in the Gregorian Calendar, AD 1900 had skipped leap year,
while another coder was blissfully unaware of it.)
Lynn McGuire <[email protected]> wrote in news:tkmbd3$uc0u$[email protected]:
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.
On 11/11/2022 5:39 PM, Jibini Kula Tumbili Kujisalimisha wrote:
Lynn McGuire <[email protected]> wrote in
news:tkmbd3$uc0u$[email protected]:
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.
Y2K was massively over-hyped - largely by the media, as usual. There
was never going to be huge issues with with things like traffic lights
and elevators suddenly not working. There were also a lot of tech
people who jumped on this scaremongering bandwagon to greedily increase
their own pay-packets.
[email protected] (Scott Lurndal) on Sat, 12 Nov 2022 16:57:44 GMT
typed in rec.arts.sf.written the following:
Ninapenda Jibini <[email protected]> writes:
[email protected] (Scott Lurndal) wrote in >>>news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there are likelyYou sound just like the doom criers ("Give me money or you'll
lots of small embedded 32-bit processors in devices like routers
which may exhibit issues, if they're still running 16 years from
now.
DIE!!!") in the run up to y2k.
I said "if they're still running 16 years from now", which is
quite unlikely. However, cheap-ass manufacturers may continue
to use the same software in newer devices, sadly.
It is possible. As the cliche was "back in my day" - most of the
current batch of programmers have no idea that there are COBOL
programs still running which were compiled before they were born.
The question is, how many people / organizations have a system
which has been running, is running, will be running, with little or no
reason to replace it with a New And Improved Hardware?
Mark Jackson <[email protected]> wrote in >news:[email protected]:
On 11/12/2022 2:35 PM, Ninapenda Jibini wrote:I was for a while. Yes, stupid people do stupid things.
[email protected] (Dave Van Domelen) wrote in
Dave Van Domelen, really tired of the attitude people haveCheese Eating Surrender Monkey, really tired of idiots who
that if a
problem is fixed, then it was never a problem in the first
place.
assume that because professionals did their job once, they
can't possibly do so again.
It's not a big deal if those professionals keep doing their
jobs, and - this is the part you're apparently too stupid to
understand - *doing* *their* *jobs* *isn't* *a* *big* *deal*
*either*.
It's *routine.*
Not a regular reader of the Risks digest, then.
But the world didn't end at midnight, December 31, 1999, despite the >predictions of idiots like you.
It got fixed real fast.
Paul S Person <[email protected]d> wrote in >news:[email protected]:
On Fri, 11 Nov 2022 14:30:25 -0600, Lynn McGuirePerhaps it's comic, and 33 bits is funnier than 64, and _you missed
<[email protected]> 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
So, two questions occur:
1. This appears to be a Unix problem. Apart of Unix and Linux
and friends, will anyone /else/ be affected?
2. Why go to 33 bits? If the problem is that 32 is too few, why
not just jump to 64 and save the future some problems? Is doing
things in the clearly least optimal way (you are going to end up
with 40 bits anyway, since they come in 8-bit groups called
"bytes") a Unix/Linux tradition? Do Real Programmers always to
things the Most Difficult Way Possible?
the joke_.
On Sat, 12 Nov 2022 09:48:23 -0800, pyotr filipivich
<[email protected]> wrote:
[email protected] (Scott Lurndal) on Sat, 12 Nov 2022 16:57:44
GMT typed in rec.arts.sf.written the following:
Ninapenda Jibini <[email protected]> writes:
[email protected] (Scott Lurndal) wrote in >>>>news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there areYou sound just like the doom criers ("Give me money or you'll
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.
DIE!!!") in the run up to y2k.
I said "if they're still running 16 years from now", which is
quite unlikely. However, cheap-ass manufacturers may continue
to use the same software in newer devices, sadly.
It is possible. As the cliche was "back in my day" - most
of the
current batch of programmers have no idea that there are COBOL
programs still running which were compiled before they were
born.
The question is, how many people / organizations have a
system
which has been running, is running, will be running, with little
or no reason to replace it with a New And Improved Hardware?
Raises hand.
(I tend to use my equipment until it literally dies. OK, the DSL
modem/router was an exception, but only because the ISP pulled
the plug.)
In article <[email protected]>,
Ninapenda Jibini <[email protected]> wrote:
Paul S Person <[email protected]d> wrote in
news:[email protected]:
On Sat, 12 Nov 2022 09:48:23 -0800, pyotr filipivich
<[email protected]> wrote:
[email protected] (Scott Lurndal) on Sat, 12 Nov 2022 16:57:44
GMT typed in rec.arts.sf.written the following:
Ninapenda Jibini <[email protected]> writes:
[email protected] (Scott Lurndal) wrote in
news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there areYou sound just like the doom criers ("Give me money or you'll
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.
DIE!!!") in the run up to y2k.
I said "if they're still running 16 years from now", which is
quite unlikely. However, cheap-ass manufacturers may continue
to use the same software in newer devices, sadly.
It is possible. As the cliche was "back in my day" - most
of the
current batch of programmers have no idea that there are COBOL
programs still running which were compiled before they were
born.
The question is, how many people / organizations have a
system
which has been running, is running, will be running, with little
or no reason to replace it with a New And Improved Hardware?
Raises hand.
(I tend to use my equipment until it literally dies. OK, the DSL
modem/router was an exception, but only because the ISP pulled
the plug.)
And how often do you have inexpensive appliance devices last 16
years? How many do you have right now that were bought in 2006?
--
Well, I post to Usenet from a 1997 desktop, read SF on a 2011 Kindle,
and have a 2002 Sun Ultrasparc I do my email on..
Paul S Person <[email protected]d> wrote in >news:[email protected]:
On Sat, 12 Nov 2022 09:48:23 -0800, pyotr filipivich
<[email protected]> wrote:
[email protected] (Scott Lurndal) on Sat, 12 Nov 2022 16:57:44
GMT typed in rec.arts.sf.written the following:
Ninapenda Jibini <[email protected]> writes:
[email protected] (Scott Lurndal) wrote in >>>>>news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there areYou sound just like the doom criers ("Give me money or you'll >>>>>DIE!!!") in the run up to y2k.
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.
I said "if they're still running 16 years from now", which is
quite unlikely. However, cheap-ass manufacturers may continue
to use the same software in newer devices, sadly.
It is possible. As the cliche was "back in my day" - most
of the
current batch of programmers have no idea that there are COBOL
programs still running which were compiled before they were
born.
The question is, how many people / organizations have a
system
which has been running, is running, will be running, with little
or no reason to replace it with a New And Improved Hardware?
Raises hand.
(I tend to use my equipment until it literally dies. OK, the DSL
modem/router was an exception, but only because the ISP pulled
the plug.)
And how often do you have inexpensive appliance devices last 16
years? How many do you have right now that were bought in 2006?
--
Paul S Person <[email protected]d> wrote in news:[email protected]:
On Sat, 12 Nov 2022 09:48:23 -0800, pyotr filipivich
<[email protected]> wrote:
[email protected] (Scott Lurndal) on Sat, 12 Nov 2022 16:57:44
GMT typed in rec.arts.sf.written the following:
Ninapenda Jibini <[email protected]> writes:
[email protected] (Scott Lurndal) wrote in
news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there areYou sound just like the doom criers ("Give me money or you'll
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.
DIE!!!") in the run up to y2k.
I said "if they're still running 16 years from now", which is
quite unlikely. However, cheap-ass manufacturers may continue
to use the same software in newer devices, sadly.
It is possible. As the cliche was "back in my day" - most
of the
current batch of programmers have no idea that there are COBOL
programs still running which were compiled before they were
born.
The question is, how many people / organizations have a
system
which has been running, is running, will be running, with little
or no reason to replace it with a New And Improved Hardware?
Raises hand.
(I tend to use my equipment until it literally dies. OK, the DSL
modem/router was an exception, but only because the ISP pulled
the plug.)
And how often do you have inexpensive appliance devices last 16
years? How many do you have right now that were bought in 2006?
On 11/13/2022 1:08 PM, Ted Nolan <tednolan> wrote:
In article <[email protected]>,
Ninapenda Jibini <[email protected]> wrote:
Paul S Person <[email protected]d> wrote in
news:[email protected]:
On Sat, 12 Nov 2022 09:48:23 -0800, pyotr filipivich
<[email protected]> wrote:
[email protected] (Scott Lurndal) on Sat, 12 Nov 2022 16:57:44
GMT typed in rec.arts.sf.written the following:
Ninapenda Jibini <[email protected]> writes:
[email protected] (Scott Lurndal) wrote in
news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there areYou sound just like the doom criers ("Give me money or you'll
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.
DIE!!!") in the run up to y2k.
I said "if they're still running 16 years from now", which is
quite unlikely. However, cheap-ass manufacturers may continue
to use the same software in newer devices, sadly.
It is possible. As the cliche was "back in my day" - most
of the
current batch of programmers have no idea that there are COBOL
programs still running which were compiled before they were
born.
The question is, how many people / organizations have a
system
which has been running, is running, will be running, with little
or no reason to replace it with a New And Improved Hardware?
Raises hand.
(I tend to use my equipment until it literally dies. OK, the DSL
modem/router was an exception, but only because the ISP pulled
the plug.)
And how often do you have inexpensive appliance devices last 16
years? How many do you have right now that were bought in 2006?
--
Well, I post to Usenet from a 1997 desktop, read SF on a 2011 Kindle,
and have a 2002 Sun Ultrasparc I do my email on..
I have been thinking about seeing if my 1993 Sun workstation will boot.
The last time I booted it (maybe 20 years ago), the disk was squealing.
I've got some code on there I would like to have again.
Lynn
In article <[email protected]>,
Ninapenda Jibini <[email protected]> wrote:
Paul S Person <[email protected]d> wrote in
news:[email protected]:
On Sat, 12 Nov 2022 09:48:23 -0800, pyotr filipivich
<[email protected]> wrote:
[email protected] (Scott Lurndal) on Sat, 12 Nov 2022 16:57:44
GMT typed in rec.arts.sf.written the following:
Ninapenda Jibini <[email protected]> writes:
[email protected] (Scott Lurndal) wrote in
news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there areYou sound just like the doom criers ("Give me money or you'll
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.
DIE!!!") in the run up to y2k.
I said "if they're still running 16 years from now", which is
quite unlikely. However, cheap-ass manufacturers may continue
to use the same software in newer devices, sadly.
It is possible. As the cliche was "back in my day" - most
of the
current batch of programmers have no idea that there are COBOL
programs still running which were compiled before they were
born.
The question is, how many people / organizations have a
system
which has been running, is running, will be running, with little
or no reason to replace it with a New And Improved Hardware?
Raises hand.
(I tend to use my equipment until it literally dies. OK, the DSL
modem/router was an exception, but only because the ISP pulled
the plug.)
And how often do you have inexpensive appliance devices last 16
years? How many do you have right now that were bought in 2006?
--
Well, I post to Usenet from a 1997 desktop, read SF on a 2011 Kindle,
and have a 2002 Sun Ultrasparc I do my email on..
In article <tkrjr0$832$[email protected]>,
Lynn McGuire <[email protected]> wrote:
On 11/13/2022 1:08 PM, Ted Nolan <tednolan> wrote:
In article <[email protected]>,
Ninapenda Jibini <[email protected]> wrote:
Paul S Person <[email protected]d> wrote in
news:[email protected]:
On Sat, 12 Nov 2022 09:48:23 -0800, pyotr filipivich
<[email protected]> wrote:
[email protected] (Scott Lurndal) on Sat, 12 Nov 2022 16:57:44
GMT typed in rec.arts.sf.written the following:
Ninapenda Jibini <[email protected]> writes:
[email protected] (Scott Lurndal) wrote in
news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there areYou sound just like the doom criers ("Give me money or you'll
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.
DIE!!!") in the run up to y2k.
I said "if they're still running 16 years from now", which is
quite unlikely. However, cheap-ass manufacturers may continue
to use the same software in newer devices, sadly.
It is possible. As the cliche was "back in my day" - most
of the
current batch of programmers have no idea that there are COBOL
programs still running which were compiled before they were
born.
The question is, how many people / organizations have a
system
which has been running, is running, will be running, with little
or no reason to replace it with a New And Improved Hardware?
Raises hand.
(I tend to use my equipment until it literally dies. OK, the DSL
modem/router was an exception, but only because the ISP pulled
the plug.)
And how often do you have inexpensive appliance devices last 16
years? How many do you have right now that were bought in 2006?
--
Well, I post to Usenet from a 1997 desktop, read SF on a 2011 Kindle,
and have a 2002 Sun Ultrasparc I do my email on..
I have been thinking about seeing if my 1993 Sun workstation will boot.
The last time I booted it (maybe 20 years ago), the disk was squealing.
I've got some code on there I would like to have again.
Lynn
Well then, have a plan to get it on the network quick (and enable
FTP on another system behind your firewall) because you may not
have long to do the transfer..
In article <[email protected]>,
Ninapenda Jibini <[email protected]> wrote:
Paul S Person <[email protected]d> wrote in >>news:[email protected]:
On Sat, 12 Nov 2022 09:48:23 -0800, pyotr filipivich
<[email protected]> wrote:
[email protected] (Scott Lurndal) on Sat, 12 Nov 2022
16:57:44 GMT typed in rec.arts.sf.written the following:
Ninapenda Jibini <[email protected]> writes:
[email protected] (Scott Lurndal) wrote in >>>>>>news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there areYou sound just like the doom criers ("Give me money or
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'll DIE!!!") in the run up to y2k.
I said "if they're still running 16 years from now", which is
quite unlikely. However, cheap-ass manufacturers may
continue to use the same software in newer devices, sadly.
It is possible. As the cliche was "back in my day" - most
of the
current batch of programmers have no idea that there are COBOL
programs still running which were compiled before they were
born.
The question is, how many people / organizations have a
system
which has been running, is running, will be running, with
little or no reason to replace it with a New And Improved
Hardware?
Raises hand.
(I tend to use my equipment until it literally dies. OK, the
DSL modem/router was an exception, but only because the ISP
pulled the plug.)
And how often do you have inexpensive appliance devices last 16
years? How many do you have right now that were bought in 2006?
--
Well, I post to Usenet from a 1997 desktop,
[email protected] (Ted Nolan <tednolan>) wrote in >news:[email protected]:
In article <[email protected]>,
Ninapenda Jibini <[email protected]> wrote:
Paul S Person <[email protected]d> wrote in >>>news:[email protected]:
On Sat, 12 Nov 2022 09:48:23 -0800, pyotr filipivich
<[email protected]> wrote:
[email protected] (Scott Lurndal) on Sat, 12 Nov 2022
16:57:44 GMT typed in rec.arts.sf.written the following:
Ninapenda Jibini <[email protected]> writes:
[email protected] (Scott Lurndal) wrote in >>>>>>>news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there areYou sound just like the doom criers ("Give me money or
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'll DIE!!!") in the run up to y2k.
I said "if they're still running 16 years from now", which is
quite unlikely. However, cheap-ass manufacturers may
continue to use the same software in newer devices, sadly.
It is possible. As the cliche was "back in my day" - most
of the
current batch of programmers have no idea that there are COBOL >>>>>programs still running which were compiled before they were
born.
The question is, how many people / organizations have a
system
which has been running, is running, will be running, with
little or no reason to replace it with a New And Improved
Hardware?
Raises hand.
(I tend to use my equipment until it literally dies. OK, the
DSL modem/router was an exception, but only because the ISP
pulled the plug.)
And how often do you have inexpensive appliance devices last 16
years? How many do you have right now that were bought in 2006?
--
Well, I post to Usenet from a 1997 desktop,
Which, of course, caught on fire, exploded, and killed your dog at
midnight on December 31, 1999, because these things are unsolvable >catatrophes that will end human civilization.
This entire converstaion is an hallucination during your death
throes at the hands of cannibals.
On 2022-11-13 10:11, Ninapenda Jibini wrote:
Paul S Person <[email protected]d> wrote in
news:[email protected]:
On Sat, 12 Nov 2022 09:48:23 -0800, pyotr filipivich
<[email protected]> wrote:
[email protected] (Scott Lurndal) on Sat, 12 Nov 2022 16:57:44
GMT typed in rec.arts.sf.written the following:
Ninapenda Jibini <[email protected]> writes:
[email protected] (Scott Lurndal) wrote in
news:l9PbL.74464$[email protected]:
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.
I said "if they're still running 16 years from now", which is
quite unlikely. However, cheap-ass manufacturers may continue
to use the same software in newer devices, sadly.
It is possible. As the cliche was "back in my day" - most
of the current batch of programmers have no idea that there are COBOL
programs still running which were compiled before they were
born.
The question is, how many people / organizations have a
system which has been running, is running, will be running, with little >>>> or no reason to replace it with a New And Improved Hardware?
Raises hand.
(I tend to use my equipment until it literally dies. OK, the DSL
modem/router was an exception, but only because the ISP pulled
the plug.)
And how often do you have inexpensive appliance devices last 16
years? How many do you have right now that were bought in 2006?
My Braun coffee maker dates from well before 1994...
...because I got it from my Dad when I bought my condo in 1994...
...and he'd had it for ages when I got it.
It's probably more than 40 years old.
Your Name <[email protected]> wrote:
On 11/11/2022 5:39 PM, Jibini Kula Tumbili Kujisalimisha wrote:
Lynn McGuire <[email protected]> wrote in
news:tkmbd3$uc0u$[email protected]:
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.
Y2K was massively over-hyped - largely by the media, as usual. There
was never going to be huge issues with with things like traffic lights
and elevators suddenly not working. There were also a lot of tech
people who jumped on this scaremongering bandwagon to greedily increase
their own pay-packets.
Well, I'll admit that I got a very nice boost for the holiday by volunteering (at 8x times my normal pay) to sit at work rather than stay home with the family on New Year's Eve.
There were a LOT of function-breaking bugs fixed in significant bits of infrastructure leading up to Y2K. Other than generating a whole lot of sales to preppers, the hype did one really important thing...it got the bean counters listening to what the the engineers had been saying for years.
Which was, essentially, that the bean counters were going to regret their inaction when the lawsuits started rolling in. Even if the failures weren't of the "All die. Oh the embarrassment." type, customers tend to frown on things
like, for example, discovering that the service they were charging by the minute for stopped recording usage on January 1st.
It was never a matter of not knowing that there was a problem, it was a matter of prioritizing remediation over new features and other bugs.
Even with the effort put in, we still saw plenty of unpatched (mostly cosmetic) issues. The most common was probably seeing dates displayed as "1-1-19100".
(I tend to use my equipment until it literally dies. OK, the DSL
modem/router was an exception, but only because the ISP pulled
the plug.)
And how often do you have inexpensive appliance devices last 16
years? How many do you have right now that were bought in 2006?
My Braun coffee maker dates from well before 1994...
...because I got it from my Dad when I bought my condo in 1994...
...and he'd had it for ages when I got it.
It's probably more than 40 years old.
[email protected] (Scott Lurndal) on Sat, 12 Nov 2022 16:57:44 GMT
typed in rec.arts.sf.written the following:
Ninapenda Jibini <[email protected]> writes:
[email protected] (Scott Lurndal) wrote in
news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there are likelyYou sound just like the doom criers ("Give me money or you'll
lots of small embedded 32-bit processors in devices like routers
which may exhibit issues, if they're still running 16 years from
now.
DIE!!!") in the run up to y2k.
I said "if they're still running 16 years from now", which is
quite unlikely. However, cheap-ass manufacturers may continue
to use the same software in newer devices, sadly.
It is possible. As the cliche was "back in my day" - most of the current batch of programmers have no idea that there are COBOL
programs still running which were compiled before they were born.
The question is, how many people / organizations have a system
which has been running, is running, will be running, with little or no
reason to replace it with a New And Improved Hardware?
On 2022-11-12 17:48:23 +0000, pyotr filipivich said:
[email protected] (Scott Lurndal) on Sat, 12 Nov 2022
16:57:44 GMT typed in rec.arts.sf.written the following:
Ninapenda Jibini <[email protected]> writes:
[email protected] (Scott Lurndal) wrote in
news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there areYou sound just like the doom criers ("Give me money or you'll
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.
DIE!!!") in the run up to y2k.
I said "if they're still running 16 years from now", which is
quite unlikely. However, cheap-ass manufacturers may continue
to use the same software in newer devices, sadly.
It is possible. As the cliche was "back in my day" - most
of the
current batch of programmers have no idea that there are COBOL
programs still running which were compiled before they were
born.
The question is, how many people / organizations have a
system
which has been running, is running, will be running, with
little or no reason to replace it with a New And Improved
Hardware?
I used my Apple PowerMac G3 computer for just over 20 years
before I had to replace it due to it irrepairably breaking down.
My car is 28 years old, and I've had it for 24 of those years.
As in another post, our clothes tumble dryer is around 50 years
old. My mother's bed would be about the same vintage (she
doesn't want to replace it).
On 2022-11-13 19:12:14 +0000, Alan said:
On 2022-11-13 10:11, Ninapenda Jibini wrote:
Paul S Person <[email protected]d> wrote in
news:[email protected]:
On Sat, 12 Nov 2022 09:48:23 -0800, pyotr filipivich
<[email protected]> wrote:
[email protected] (Scott Lurndal) on Sat, 12 Nov 2022
16:57:44 GMT typed in rec.arts.sf.written the following:
Ninapenda Jibini <[email protected]> writes:
[email protected] (Scott Lurndal) wrote in
news:l9PbL.74464$[email protected]:
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.
I said "if they're still running 16 years from now", which
is quite unlikely. However, cheap-ass manufacturers may
continue to use the same software in newer devices, sadly.
It is possible. As the cliche was "back in my day" - most
of the current batch of programmers have no idea that there
are COBOL programs still running which were compiled before
they were born.
The question is, how many people / organizations have a
system which has been running, is running, will be running,
with little or no reason to replace it with a New And
Improved Hardware?
Raises hand.
(I tend to use my equipment until it literally dies. OK, the
DSL modem/router was an exception, but only because the ISP
pulled the plug.)
And how often do you have inexpensive appliance devices last
16 years? How many do you have right now that were bought in
2006?
My Braun coffee maker dates from well before 1994...
...because I got it from my Dad when I bought my condo in
1994...
...and he'd had it for ages when I got it.
It's probably more than 40 years old.
There's a UK show called "The Repair Shop" where people bring
all sorts of old things in to be repaired by experts. A few
episodes ago there was one woman with her mother's old electric
food mixer, which was at least 50 years old. After the expert
took it apart to fully clean it, it was working again like new.
Another woman wrote in to the local TV GUide magazine to say she
had the same model of food mixer that was also still going well.
Our clothes tumble dryer is probably about that old too and has
never had any problems. Our dishwasher on the other hand is
about 20 years old, but we rarely use it, so has probably only
been turned on about half a dozen times over those yeras, yet
the control panel is still broken (it's a now-known fault
because they stupidly used cheap plastic which gets ruined by
teh water and heat).
Things these days simply aren't made to last, and in many cases
they're difficult or impossible to even fix. :-(
Paul S Person <[email protected]d> wrote in >news:[email protected]:
It got fixed real fast.
But according to the predictions, that's impossible, because
civilization has ended, and cannibals living in caves lack the
ability to fix complicated electronics.
On Sun, 13 Nov 2022 18:12:29 GMT, Ninapenda Jibini
<[email protected]> wrote:
Paul S Person <[email protected]d> wrote in >>news:[email protected]:
It got fixed real fast.
But according to the predictions, that's impossible, because
civilization has ended, and cannibals living in caves lack the
ability to fix complicated electronics.
Fortunately, this was a rare occurrence, not the new normal.
Your Name <[email protected]> on Mon, 14 Nov 2022 16:50:19
+1300 typed in rec.arts.sf.written the following:
Things these days simply aren't made to last, and in many cases
they're difficult or impossible to even fix. :-(
Things are designed with (at best) ease of assembly /
installation
in mind. Remember the Manza 2+2 which had access to one of the
spark plugs blocked by an engine mount?
Paul S Person <[email protected]d> wrote in >news:[email protected]:
On Sat, 12 Nov 2022 09:48:23 -0800, pyotr filipivich
<[email protected]> wrote:
[email protected] (Scott Lurndal) on Sat, 12 Nov 2022 16:57:44
GMT typed in rec.arts.sf.written the following:
Ninapenda Jibini <[email protected]> writes:
[email protected] (Scott Lurndal) wrote in >>>>>news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there areYou sound just like the doom criers ("Give me money or you'll >>>>>DIE!!!") in the run up to y2k.
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.
I said "if they're still running 16 years from now", which is
quite unlikely. However, cheap-ass manufacturers may continue
to use the same software in newer devices, sadly.
It is possible. As the cliche was "back in my day" - most
of the
current batch of programmers have no idea that there are COBOL
programs still running which were compiled before they were
born.
The question is, how many people / organizations have a
system
which has been running, is running, will be running, with little
or no reason to replace it with a New And Improved Hardware?
Raises hand.
(I tend to use my equipment until it literally dies. OK, the DSL
modem/router was an exception, but only because the ISP pulled
the plug.)
And how often do you have inexpensive appliance devices last 16
years? How many do you have right now that were bought in 2006?
Paul S Person <[email protected]d> on Sun, 13 Nov 2022
09:10:30 -0800 typed in rec.arts.sf.written the following:
You sound just like the doom criers ("Give me money or you'll >>>>>DIE!!!") in the run up to y2k.
I said "if they're still running 16 years from now", which is
quite unlikely. However, cheap-ass manufacturers may continue
to use the same software in newer devices, sadly.
It is possible. As the cliche was "back in my day" - most of the >>>current batch of programmers have no idea that there are COBOL
programs still running which were compiled before they were born.
The question is, how many people / organizations have a system
which has been running, is running, will be running, with little or no >>>reason to replace it with a New And Improved Hardware?
Raises hand.
(I tend to use my equipment until it literally dies. OK, the DSL >>modem/router was an exception, but only because the ISP pulled the
plug.)
"it was ... a mercy killing." B-)
pyotr filipivich <[email protected]> wrote in news:[email protected]:
Your Name <[email protected]> on Mon, 14 Nov 2022 16:50:19
+1300 typed in rec.arts.sf.written the following:
Things these days simply aren't made to last, and in many cases
they're difficult or impossible to even fix. :-(
Things are designed with (at best) ease of assembly /
installation
in mind. Remember the Manza 2+2 which had access to one of the
spark plugs blocked by an engine mount?
Wasn't there a Cadillac that required lifting the block off the motor
mounts to access the spark plugs?
On 11/14/2022 10:02 AM, Jibini Kula Tumbili Kujisalimisha wrote:
pyotr filipivich <[email protected]> wrote in
news:[email protected]:
Your Name <[email protected]> on Mon, 14 Nov 2022 16:50:19
+1300 typed in rec.arts.sf.written the following:
Things these days simply aren't made to last, and in many cases
they're difficult or impossible to even fix. :-(
Things are designed with (at best) ease of assembly /
installation
in mind. Remember the Manza 2+2 which had access to one of the
spark plugs blocked by an engine mount?
Wasn't there a Cadillac that required lifting the block off the motor
mounts to access the spark plugs?
My Dad's 1977 Ford F-350 required laying on top of the air cleaner to
get to the back two plugs in the 460 in3 V8. When I changed the plugs
at 30,000+ miles, it was obvious that the back two plugs had never been changed as the electrodes were totally burnt off.
On 11/14/2022 10:02 AM, Jibini Kula Tumbili Kujisalimisha wrote:
pyotr filipivich <[email protected]> wrote in
news:[email protected]:
Your Name <[email protected]> on Mon, 14 Nov 2022 16:50:19
+1300 typed in rec.arts.sf.written the following:
Things these days simply aren't made to last, and in many
cases they're difficult or impossible to even fix. :-(
Things are designed with (at best) ease of assembly /
installation
in mind. Remember the Manza 2+2 which had access to one of
the spark plugs blocked by an engine mount?
Wasn't there a Cadillac that required lifting the block off the
motor mounts to access the spark plugs?
My Dad's 1977 Ford F-350 required laying on top of the air
cleaner to get to the back two plugs in the 460 in3 V8. When I
changed the plugs at 30,000+ miles, it was obvious that the back
two plugs had never been changed as the electrodes were totally
burnt off.
On 11/14/2022 10:02 AM, Jibini Kula Tumbili Kujisalimisha wrote:
pyotr filipivich <[email protected]> wrote in
news:[email protected]:
Your Name <[email protected]> on Mon, 14 Nov 2022 16:50:19
+1300 typed in rec.arts.sf.written the following:
Things these days simply aren't made to last, and in many cases
they're difficult or impossible to even fix. :-(
Things are designed with (at best) ease of assembly /
installation
in mind. Remember the Manza 2+2 which had access to one of the
spark plugs blocked by an engine mount?
Wasn't there a Cadillac that required lifting the block off the motor
mounts to access the spark plugs?
My Dad's 1977 Ford F-350 required laying on top of the air cleaner to
get to the back two plugs in the 460 in3 V8. When I changed the plugs
at 30,000+ miles, it was obvious that the back two plugs had never been >changed as the electrodes were totally burnt off.
On 11/12/2022 2:35 PM, Ninapenda Jibini wrote:
[email protected] (Dave Van Domelen) wrote in
Dave Van Domelen, really tired of the attitude people haveCheese Eating Surrender Monkey, really tired of idiots who assume
that if a
problem is fixed, then it was never a problem in the first
place.
that because professionals did their job once, they can't possibly do
so again.
It's not a big deal if those professionals keep doing their jobs, and
- this is the part you're apparently too stupid to understand -
*doing* *their* *jobs* *isn't* *a* *big* *deal* *either*.
It's *routine.*
Not a regular reader of the Risks digest, then.
On 2022-11-14 15:04, Lynn McGuire wrote:
On 11/14/2022 10:02 AM, Jibini Kula Tumbili Kujisalimisha wrote:
pyotr filipivich <[email protected]> wrote in
news:[email protected]:
Your Name <[email protected]> on Mon, 14 Nov 2022 16:50:19
+1300 typed in rec.arts.sf.written� the following:
Things these days simply aren't made to last, and in many cases
they're difficult or impossible to even fix.� :-(
����� Things are designed with (at best) ease of assembly /
����� installation
in mind.� Remember the Manza 2+2 which had access to one of the
spark plugs blocked by an engine mount?
Wasn't there a Cadillac that required lifting the block off the motor
mounts to access the spark plugs?
My Dad's 1977 Ford F-350 required laying on top of the air cleaner to
get to the back two plugs in the 460 in3 V8.� When I changed the plugs
at 30,000+ miles, it was obvious that the back two plugs had never been
changed as the electrodes were totally burnt off.
A buddy of mine was working on Ford pickup for his son to replace some
broken exhaust manifold studs...
(A KNOWN problem with this particular truck)
...because the official Ford repair procedure involved...
...REMOVING THE ENTIRE CAB!
Mark Jackson <[email protected]> schrieb:
On 11/12/2022 2:35 PM, Ninapenda Jibini wrote:
[email protected] (Dave Van Domelen) wrote in
Dave Van Domelen, really tired of the attitude people haveCheese Eating Surrender Monkey, really tired of idiots who assume
that if a
problem is fixed, then it was never a problem in the first
place.
that because professionals did their job once, they can't possibly do
so again.
It's not a big deal if those professionals keep doing their jobs, and
- this is the part you're apparently too stupid to understand -
*doing* *their* *jobs* *isn't* *a* *big* *deal* *either*.
It's *routine.*
Not a regular reader of the Risks digest, then.
There hasn't been an issue of RISKS for quite some time.
(I'm a reader, and very occasionally a contributor).
On Mon, 14 Nov 2022 17:04:52 -0600, Lynn McGuire
<[email protected]> wrote:
On 11/14/2022 10:02 AM, Jibini Kula Tumbili Kujisalimisha wrote:
pyotr filipivich <[email protected]> wrote in
news:[email protected]:
Your Name <[email protected]> on Mon, 14 Nov 2022 16:50:19
+1300 typed in rec.arts.sf.written the following:
Things these days simply aren't made to last, and in many cases
they're difficult or impossible to even fix. :-(
Things are designed with (at best) ease of assembly /
installation
in mind. Remember the Manza 2+2 which had access to one of the
spark plugs blocked by an engine mount?
Wasn't there a Cadillac that required lifting the block off the motor
mounts to access the spark plugs?
My Dad's 1977 Ford F-350 required laying on top of the air cleaner to
get to the back two plugs in the 460 in3 V8. When I changed the plugs
at 30,000+ miles, it was obvious that the back two plugs had never been
changed as the electrodes were totally burnt off.
Did that improve it's performance or did they turn out to be
superfluous?
On Mon, 14 Nov 2022 15:09:09 -0800, Alan <[email protected]>
wrote:
On 2022-11-14 15:04, Lynn McGuire wrote:
On 11/14/2022 10:02 AM, Jibini Kula Tumbili Kujisalimisha
wrote:
pyotr filipivich <[email protected]> wrote in
news:[email protected]:
Your Name <[email protected]> on Mon, 14 Nov 2022
16:50:19 +1300 typed in rec.arts.sf.written� the following:
Things these days simply aren't made to last, and in many
cases they're difficult or impossible to even fix.� :-(
����� Things are designed with (at best) ease of assembly /
����� installation
in mind.� Remember the Manza 2+2 which had access to one of
the spark plugs blocked by an engine mount?
Wasn't there a Cadillac that required lifting the block off
the motor mounts to access the spark plugs?
My Dad's 1977 Ford F-350 required laying on top of the air
cleaner to get to the back two plugs in the 460 in3 V8.� When
I changed the plugs at 30,000+ miles, it was obvious that the
back two plugs had never been changed as the electrodes were
totally burnt off.
A buddy of mine was working on Ford pickup for his son to
replace some broken exhaust manifold studs...
(A KNOWN problem with this particular truck)
...because the official Ford repair procedure involved...
...REMOVING THE ENTIRE CAB!
Well, if it's under warranty so Ford is paying for it, that
/might/ be OK.
If not, then a known problem combined with a perhaps
overly-elaborate repair procedure doesn't speak well for Ford.
But then, my dad, not a Ford fan, gave two "explanations" for
the name:
Found On Road Dead
Fix Or Replace Daily
and who can say he was wrong?
Paul S Person <[email protected]d> wrote in >news:[email protected]:
On Mon, 14 Nov 2022 15:09:09 -0800, Alan <[email protected]>
wrote:
On 2022-11-14 15:04, Lynn McGuire wrote:
On 11/14/2022 10:02 AM, Jibini Kula Tumbili Kujisalimisha
wrote:
pyotr filipivich <[email protected]> wrote in
news:[email protected]:
Your Name <[email protected]> on Mon, 14 Nov 2022
16:50:19 +1300 typed in rec.arts.sf.written� the following:
Things these days simply aren't made to last, and in many
cases they're difficult or impossible to even fix.� :-(
����� Things are designed with (at best) ease of assembly /
����� installation
in mind.� Remember the Manza 2+2 which had access to one of
the spark plugs blocked by an engine mount?
Wasn't there a Cadillac that required lifting the block off
the motor mounts to access the spark plugs?
My Dad's 1977 Ford F-350 required laying on top of the air
cleaner to get to the back two plugs in the 460 in3 V8.� When
I changed the plugs at 30,000+ miles, it was obvious that the
back two plugs had never been changed as the electrodes were
totally burnt off.
A buddy of mine was working on Ford pickup for his son to
replace some broken exhaust manifold studs...
(A KNOWN problem with this particular truck)
...because the official Ford repair procedure involved...
...REMOVING THE ENTIRE CAB!
Well, if it's under warranty so Ford is paying for it, that
/might/ be OK.
If not, then a known problem combined with a perhaps
overly-elaborate repair procedure doesn't speak well for Ford.
But then, my dad, not a Ford fan, gave two "explanations" for
the name:
Found On Road Dead
Fix Or Replace Daily
and who can say he was wrong?
The other old saw is, of course, First On Race Day, which has about
as much basis in history (which is to say, a tiny bit, but not
much.)
John W Kennedy <[email protected]> wrote in news:[email protected]:
On 11/12/22 11:32 AM, Ninapenda Jibini wrote:
[email protected] (Scott Lurndal) wrote in
news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there areYou sound just like the doom criers ("Give me money or you'll
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.
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/
Do not misunderstand. The Y2K problem was very real, and started
causing serious damage at least as early as August 16, 1972
(9999 days before Y2K), when tapes on IBM mainframes that were
supposed to be marked “retain forever” started to be marked
"ready for recycling” instead.
Serious, perhaps, but not especially wide spread.
(It was also about that time that our operating system—to beAnd did hellfire rain down from the heavens, with cats and dogs
fair to IBM, it was a beta—started crashing every day at
exactly 7:00PM EST. It turned out to be caused by a zero divide
in the rollover-GMT code—7:00PM EST is midnight, GMT. And why
the zero divide? Ultimately, because one IBM coder was aware
that, in the Gregorian Calendar, AD 1900 had skipped leap year,
while another coder was blissfully unaware of it.)
living together, heralding the end of human civilization? No.
Nobody kicked your dog, either. Professionals fixed it, and life
went on.
And we know 2038 is coming. Decades in advance.
In article <[email protected]>,
Jibini Kula Tumbili Kujisalimisha <[email protected]> wrote:
Paul S Person <[email protected]d> wrote in >>news:[email protected]:
Well, if it's under warranty so Ford is paying for it, that
/might/ be OK.
If not, then a known problem combined with a perhaps
overly-elaborate repair procedure doesn't speak well for Ford.
But then, my dad, not a Ford fan, gave two "explanations" for
the name:
Found On Road Dead
Fix Or Replace Daily
and who can say he was wrong?
The other old saw is, of course, First On Race Day, which has about
as much basis in history (which is to say, a tiny bit, but not
much.)
I found an entire Ford Joke Book at my aunt's house once. Probably
from the 1920s:
Did you know Ford is mentioned in the Bible?
Really?
Well, what other car could Ascend to Heaven on 'High'?
Did you know all Fords must now be painted red?
No, why?
Because the law says any tin-can filled with gasoline must
be painted red!
On 11/12/22 5:09 PM, Ninapenda Jibini wrote:
John W Kennedy <[email protected]> wrote in
news:[email protected]:
On 11/12/22 11:32 AM, Ninapenda Jibini wrote:
[email protected] (Scott Lurndal) wrote in
news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there areYou sound just like the doom criers ("Give me money or you'll
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.
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/
Do not misunderstand. The Y2K problem was very real, and
started causing serious damage at least as early as August 16,
1972 (9999 days before Y2K), when tapes on IBM mainframes that
were supposed to be marked “retain forever” started to be
marked "ready for recycling” instead.
Serious, perhaps, but not especially wide spread.
Really? Tell me, are you saying that IBM mainframes were
uncommon in 1972, or that few of them used 2400-foot tapes?
John W Kennedy <[email protected]> wrote in news:[email protected]:
On 11/12/22 5:09 PM, Ninapenda Jibini wrote:
John W Kennedy <[email protected]> wrote in
news:[email protected]:
On 11/12/22 11:32 AM, Ninapenda Jibini wrote:
[email protected] (Scott Lurndal) wrote in
news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there areYou sound just like the doom criers ("Give me money or you'll
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.
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/
Do not misunderstand. The Y2K problem was very real, and
started causing serious damage at least as early as August 16,
1972 (9999 days before Y2K), when tapes on IBM mainframes that
were supposed to be marked “retain forever” started to be
marked "ready for recycling” instead.
Serious, perhaps, but not especially wide spread.
Really? Tell me, are you saying that IBM mainframes were
uncommon in 1972, or that few of them used 2400-foot tapes?
By comparison to today, yes, they were uncommon.
And they were all
being handled by people who knew what they were doing.
And few
businesses relied on them to the degree that most businesses do
today, so that if they're without it for a short time, it's not a catastrophe.
Can you point me to a single news story about how catastrophic a
problem it was? No? Why do you suppose that is?
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
In article <tkmbd3$uc0u$[email protected]>,
Lynn McGuire <[email protected]> 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.
On 11/15/2022 6:09 PM, Dorothy J Heydt wrote:
In article <tkmbd3$uc0u$[email protected]>,
Lynn McGuire <[email protected]> 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 ?
On 11/15/2022 6:09 PM, Dorothy J Heydt wrote:
In article <tkmbd3$uc0u$[email protected]>,
Lynn McGuire <[email protected]> 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 ?
On 11/15/2022 11:14 AM, Paul S Person wrote:
On Mon, 14 Nov 2022 17:04:52 -0600, Lynn McGuire
<[email protected]> wrote:
On 11/14/2022 10:02 AM, Jibini Kula Tumbili Kujisalimisha wrote:
pyotr filipivich <[email protected]> wrote in
news:[email protected]:
Your Name <[email protected]> on Mon, 14 Nov 2022 16:50:19
+1300 typed in rec.arts.sf.written the following:
Things these days simply aren't made to last, and in many cases
they're difficult or impossible to even fix. :-(
Things are designed with (at best) ease of assembly /
installation
in mind. Remember the Manza 2+2 which had access to one of the
spark plugs blocked by an engine mount?
Wasn't there a Cadillac that required lifting the block off the motor
mounts to access the spark plugs?
My Dad's 1977 Ford F-350 required laying on top of the air cleaner to
get to the back two plugs in the 460 in3 V8. When I changed the plugs
at 30,000+ miles, it was obvious that the back two plugs had never been
changed as the electrodes were totally burnt off.
Did that improve it's performance or did they turn out to be
superfluous?
Gas mileage changed from 5 mpg to 6 mpg.
Paul S Person <[email protected]d> wrote in >news:[email protected]:
On Mon, 14 Nov 2022 15:09:09 -0800, Alan <[email protected]>
wrote:
On 2022-11-14 15:04, Lynn McGuire wrote:
On 11/14/2022 10:02 AM, Jibini Kula Tumbili Kujisalimisha
wrote:
pyotr filipivich <[email protected]> wrote in
news:[email protected]:
Your Name <[email protected]> on Mon, 14 Nov 2022
16:50:19 +1300 typed in rec.arts.sf.written� the following:
Things these days simply aren't made to last, and in many
cases they're difficult or impossible to even fix.� :-(
����� Things are designed with (at best) ease of assembly /
����� installation
in mind.� Remember the Manza 2+2 which had access to one of
the spark plugs blocked by an engine mount?
Wasn't there a Cadillac that required lifting the block off
the motor mounts to access the spark plugs?
My Dad's 1977 Ford F-350 required laying on top of the air
cleaner to get to the back two plugs in the 460 in3 V8.� When
I changed the plugs at 30,000+ miles, it was obvious that the
back two plugs had never been changed as the electrodes were
totally burnt off.
A buddy of mine was working on Ford pickup for his son to
replace some broken exhaust manifold studs...
(A KNOWN problem with this particular truck)
...because the official Ford repair procedure involved...
...REMOVING THE ENTIRE CAB!
Well, if it's under warranty so Ford is paying for it, that
/might/ be OK.
If not, then a known problem combined with a perhaps
overly-elaborate repair procedure doesn't speak well for Ford.
But then, my dad, not a Ford fan, gave two "explanations" for
the name:
Found On Road Dead
Fix Or Replace Daily
and who can say he was wrong?
The other old saw is, of course, First On Race Day, which has about
as much basis in history (which is to say, a tiny bit, but not
much.)
On Tue, 15 Nov 2022 11:40:46 -0700, Jibini Kula Tumbili
Kujisalimisha <[email protected]> wrote:
Paul S Person <[email protected]d> wrote in >>news:[email protected]:
On Mon, 14 Nov 2022 15:09:09 -0800, Alan <[email protected]>
wrote:
On 2022-11-14 15:04, Lynn McGuire wrote:
On 11/14/2022 10:02 AM, Jibini Kula Tumbili Kujisalimisha
wrote:
pyotr filipivich <[email protected]> wrote in
news:[email protected]:
Your Name <[email protected]> on Mon, 14 Nov 2022
16:50:19 +1300 typed in rec.arts.sf.written� the
following:
Things these days simply aren't made to last, and in many
cases they're difficult or impossible to even fix.� :-(
����� Things are designed with (at best) ease of assembly
/ ����� installation
in mind.� Remember the Manza 2+2 which had access to one
of the spark plugs blocked by an engine mount?
Wasn't there a Cadillac that required lifting the block off
the motor mounts to access the spark plugs?
My Dad's 1977 Ford F-350 required laying on top of the air
cleaner to get to the back two plugs in the 460 in3 V8.�
When I changed the plugs at 30,000+ miles, it was obvious
that the back two plugs had never been changed as the
electrodes were totally burnt off.
A buddy of mine was working on Ford pickup for his son to
replace some broken exhaust manifold studs...
(A KNOWN problem with this particular truck)
...because the official Ford repair procedure involved...
...REMOVING THE ENTIRE CAB!
Well, if it's under warranty so Ford is paying for it, that
/might/ be OK.
If not, then a known problem combined with a perhaps
overly-elaborate repair procedure doesn't speak well for Ford.
But then, my dad, not a Ford fan, gave two "explanations" for
the name:
Found On Road Dead
Fix Or Replace Daily
and who can say he was wrong?
The other old saw is, of course, First On Race Day, which has
about as much basis in history (which is to say, a tiny bit, but
not much.)
I don't recall every hearing that one.
Perhaps, not being a Fan of Ford, my dad ... ignored it.
On Tue, 15 Nov 2022 14:00:18 -0600, Lynn McGuire
<[email protected]> wrote:
On 11/15/2022 11:14 AM, Paul S Person wrote:
On Mon, 14 Nov 2022 17:04:52 -0600, Lynn McGuire
<[email protected]> wrote:
On 11/14/2022 10:02 AM, Jibini Kula Tumbili Kujisalimisha
wrote:
pyotr filipivich <[email protected]> wrote in
news:[email protected]:
Your Name <[email protected]> on Mon, 14 Nov 2022
16:50:19 +1300 typed in rec.arts.sf.written the following:
Things these days simply aren't made to last, and in many
cases they're difficult or impossible to even fix. :-(
Things are designed with (at best) ease of assembly
/ installation
in mind. Remember the Manza 2+2 which had access to one of
the spark plugs blocked by an engine mount?
Wasn't there a Cadillac that required lifting the block off
the motor mounts to access the spark plugs?
My Dad's 1977 Ford F-350 required laying on top of the air
cleaner to get to the back two plugs in the 460 in3 V8. When
I changed the plugs at 30,000+ miles, it was obvious that the
back two plugs had never been changed as the electrodes were
totally burnt off.
Did that improve it's performance or did they turn out to be
superfluous?
Gas mileage changed from 5 mpg to 6 mpg.
A 20% improvement!
But rather low by today's standards, surely?
Paul S Person <[email protected]d> wrote in news:[email protected]:
On Tue, 15 Nov 2022 14:00:18 -0600, Lynn McGuireA bit.
<[email protected]> wrote:
On 11/15/2022 11:14 AM, Paul S Person wrote:
On Mon, 14 Nov 2022 17:04:52 -0600, Lynn McGuire
<[email protected]> wrote:
On 11/14/2022 10:02 AM, Jibini Kula Tumbili Kujisalimisha
wrote:
pyotr filipivich <[email protected]> wrote in
news:[email protected]:
Your Name <[email protected]> on Mon, 14 Nov 2022
16:50:19 +1300 typed in rec.arts.sf.written the following:
Things these days simply aren't made to last, and in many
cases they're difficult or impossible to even fix. :-(
Things are designed with (at best) ease of assembly
/ installation
in mind. Remember the Manza 2+2 which had access to one of
the spark plugs blocked by an engine mount?
Wasn't there a Cadillac that required lifting the block off
the motor mounts to access the spark plugs?
My Dad's 1977 Ford F-350 required laying on top of the air
cleaner to get to the back two plugs in the 460 in3 V8. When
I changed the plugs at 30,000+ miles, it was obvious that the
back two plugs had never been changed as the electrodes were
totally burnt off.
Did that improve it's performance or did they turn out to be
superfluous?
Gas mileage changed from 5 mpg to 6 mpg.
A 20% improvement!
But rather low by today's standards, surely?
Friend of mine had a Dodge Super Bee (of the 68-71 year models, not
the modern revival) with whatever the biggest motor they put in it.
He said he could watch the gas gauge visibly drop when he floored
it. (And not because the sensor was in the front of the tank.)
On 2022-11-16 10:06, Jibini Kula Tumbili Kujisalimisha wrote:
Paul S Person <[email protected]d> wrote in
news:[email protected]:
Friend of mine had a Dodge Super Bee (of the 68-71 year models, not
the modern revival) with whatever the biggest motor they put in it.
He said he could watch the gas gauge visibly drop when he floored
it. (And not because the sensor was in the front of the tank.)
He might have said...
...or more likely you're making it up...
...either way, it's bullshit.
Alan <[email protected]> writes:
On 2022-11-16 10:06, Jibini Kula Tumbili Kujisalimisha wrote:
Paul S Person <[email protected]d> wrote in
news:[email protected]:
Friend of mine had a Dodge Super Bee (of the 68-71 year models, not
the modern revival) with whatever the biggest motor they put in it.
He said he could watch the gas gauge visibly drop when he floored
it. (And not because the sensor was in the front of the tank.)
He might have said...
...or more likely you're making it up...
...either way, it's bullshit.
It is more likely the gas sloshing to the back of the
tank under acceleration causing the needle to move.
Alan <[email protected]> writes:
On 2022-11-16 10:06, Jibini Kula Tumbili Kujisalimisha wrote:
Paul S Person <[email protected]d> wrote in
news:[email protected]:
Friend of mine had a Dodge Super Bee (of the 68-71 year
models, not the modern revival) with whatever the biggest
motor they put in it. He said he could watch the gas gauge
visibly drop when he floored it. (And not because the sensor
was in the front of the tank.)
He might have said...
...or more likely you're making it up...
...either way, it's bullshit.
It is more likely the gas sloshing to the back of the
tank under acceleration causing the needle to move.
[email protected] (Scott Lurndal) wrote in news:FybdL.139383$[email protected]:
Alan <[email protected]> writes:That does happen, but this was more than that.
On 2022-11-16 10:06, Jibini Kula Tumbili Kujisalimisha wrote:
Paul S Person <[email protected]d> wrote in
news:[email protected]:
Friend of mine had a Dodge Super Bee (of the 68-71 year
models, not the modern revival) with whatever the biggest
motor they put in it. He said he could watch the gas gauge
visibly drop when he floored it. (And not because the sensor
was in the front of the tank.)
He might have said...
...or more likely you're making it up...
...either way, it's bullshit.
It is more likely the gas sloshing to the back of the
tank under acceleration causing the needle to move.
Lynn McGuire <[email protected]> schrieb:
On 11/15/2022 6:09 PM, Dorothy J Heydt wrote:
In article <tkmbd3$uc0u$[email protected]>,
Lynn McGuire <[email protected]> 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.
Apparently, some people thought that sizeof(int) == sizeof(void *)
would be guaranteed for all times in the future. That turned out
not to be the case.
And as for big-endian vs. little-endian - that has been won by
little-endian.
Jibini Kula Tumbili Kujisalimisha <[email protected]> writes:
Lynn McGuire <[email protected]> wrote in >>news:tkmbd3$uc0u$[email protected]:
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.
On 2022-11-16 12:16, Scott Lurndal wrote:
Alan <[email protected]> writes:
On 2022-11-16 10:06, Jibini Kula Tumbili Kujisalimisha wrote:
Paul S Person <[email protected]d> wrote in
news:[email protected]:
Friend of mine had a Dodge Super Bee (of the 68-71 year models, not
the modern revival) with whatever the biggest motor they put in it.
He said he could watch the gas gauge visibly drop when he floored
it. (And not because the sensor was in the front of the tank.)
He might have said...
...or more likely you're making it up...
...either way, it's bullshit.
It is more likely the gas sloshing to the back of the
tank under acceleration causing the needle to move.
Essentially certain.
Assuming an absolute worst case scenario:
Instantaneous fuel consumption of 1 mpg.
At 1 mph = 1 gallon per hour usage.
A 1 gallon tank
Means a needle the moves from full to empty...
in ONE HOUR!
If the needle is the typical quarter of a circle sweep (90 degrees),
then that means it moves 1.5 degrees per minute. The minute hand on a
clock moves at 6 degrees per minute.
Does anyone want to claim they can see the minute hand on a clock
"visibly move"?
On 11/16/22 4:31 PM, Alan wrote:
On 2022-11-16 12:16, Scott Lurndal wrote:
Alan <[email protected]> writes:
On 2022-11-16 10:06, Jibini Kula Tumbili Kujisalimisha wrote:
Paul S Person <[email protected]d> wrote in
news:[email protected]:
Friend of mine had a Dodge Super Bee (of the 68-71 year models, not
the modern revival) with whatever the biggest motor they put in it.
He said he could watch the gas gauge visibly drop when he floored
it. (And not because the sensor was in the front of the tank.)
He might have said...
...or more likely you're making it up...
...either way, it's bullshit.
It is more likely the gas sloshing to the back of the
tank under acceleration causing the needle to move.
Essentially certain.
Assuming an absolute worst case scenario:
Instantaneous fuel consumption of 1 mpg.
At 1 mph = 1 gallon per hour usage.
A 1 gallon tank
Means a needle the moves from full to empty...
in ONE HOUR!
If the needle is the typical quarter of a circle sweep (90 degrees),
then that means it moves 1.5 degrees per minute. The minute hand on a
clock moves at 6 degrees per minute.
Does anyone want to claim they can see the minute hand on a clock
"visibly move"?
I can, on an antique grandfather clock.
[email protected] (Scott Lurndal) wrote in >news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there are likelyYou sound just like the doom criers ("Give me money or you'll
lots of small embedded 32-bit processors in devices like routers
which may exhibit issues, if they're still running 16 years from
now.
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/
In article <[email protected]>,
Ninapenda Jibini <[email protected]> wrote:
[email protected] (Scott Lurndal) wrote in >>news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there are likelyYou sound just like the doom criers ("Give me money or you'll
lots of small embedded 32-bit processors in devices like routers
which may exhibit issues, if they're still running 16 years from
now.
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.)
On Fri, 11 Nov 2022 14:30:25 -0600, Lynn McGuire
<[email protected]> 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
So, two questions occur:
1. This appears to be a Unix problem. Apart of Unix and Linux and
friends, will anyone /else/ be affected?
2. Why go to 33 bits? If the problem is that 32 is too few, why not
just jump to 64 and save the future some problems? Is doing things in
the clearly least optimal way (you are going to end up with 40 bits
anyway, since they come in 8-bit groups called "bytes") a Unix/Linux >tradition? Do Real Programmers always to things the Most Difficult Way >Possible?
In article <[email protected]>,
Ninapenda Jibini <[email protected]> wrote:
[email protected] (Scott Lurndal) wrote in >>news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there are likelyYou sound just like the doom criers ("Give me money or you'll
lots of small embedded 32-bit processors in devices like routers
which may exhibit issues, if they're still running 16 years from
now.
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?
[email protected] (Dorothy J Heydt) writes:
In article <[email protected]>,
Ninapenda Jibini <[email protected]> wrote:
[email protected] (Scott Lurndal) wrote in >>>news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there areYou sound just like the doom criers ("Give me money or you'll
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.
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?
SOHO Routers, for instance, may use the current time for log
timestamps and for time-based web-site blocking.
I wish smoke detectors knew the time, so the damned low-battery
beeps would never occur at 0130 :-)
[email protected] (Dorothy J Heydt) writes:
In article <[email protected]>,
Ninapenda Jibini <[email protected]> wrote:
[email protected] (Scott Lurndal) wrote in
news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there are likelyYou sound just like the doom criers ("Give me money or you'll
lots of small embedded 32-bit processors in devices like routers
which may exhibit issues, if they're still running 16 years from
now.
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?
SOHO Routers, for instance, may use the current time for log timestamps
and for time-based web-site blocking.
I wish smoke detectors knew the time, so the damned low-battery beeps
would never occur at 0130 :-)
(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.
Dorothy J Heydt <[email protected]> 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.
On 18/11/2022 22:56, Thomas Koenig wrote:
Dorothy J Heydt <[email protected]> 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.
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.
1 - No, massively parallel Linux boxes don't do the same job[2]. 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".
In article <[email protected]>,
Ninapenda Jibini <[email protected]> wrote:
[email protected] (Scott Lurndal) wrote in >>news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there are likelyYou sound just like the doom criers ("Give me money or you'll
lots of small embedded 32-bit processors in devices like routers
which may exhibit issues, if they're still running 16 years from
now.
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.)
In article <l9PbL.74464$[email protected]>,
Slcott Lurndal <[email protected]> wrote:
Jibini Kula Tumbili Kujisalimisha <[email protected]> writes:
Lynn McGuire <[email protected]> wrote in >>>news:tkmbd3$uc0u$[email protected]:
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.
In article <[email protected]>, Ninapenda
Jibini <[email protected]> wrote:
[email protected] (Scott Lurndal) wrote in >>news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there are likely lotsYou sound just like the doom criers ("Give me money or you'll DIE!!!")
of small embedded 32-bit processors in devices like routers which may
exhibit issues, if they're still running 16 years from now.
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.)
On Thu, 17 Nov 2022 21:22:42 +0000, Dorothy J Heydt wrote:
In article <[email protected]>, Ninapenda
Jibini <[email protected]> wrote:
[email protected] (Scott Lurndal) wrote in
news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there are likely lotsYou sound just like the doom criers ("Give me money or you'll DIE!!!")
of small embedded 32-bit processors in devices like routers which may
exhibit issues, if they're still running 16 years from now.
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 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 18/11/2022 22:56, Thomas Koenig wrote:
Dorothy J Heydt <[email protected]> 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.
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.
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].
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...
Gary R. Schmidt <[email protected]> schrieb:
On 18/11/2022 22:56, Thomas Koenig wrote:
Dorothy J Heydt <[email protected]> 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?
Gary R. Schmidt <[email protected]> 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 :-)
On 20/11/2022 03:06, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:[SNIP]
No, MSP and XSP are still alive and paying some salaries in the group I
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 :-)
work in at Fujitsu Oz. :-)
Gary R. Schmidt <[email protected]> schrieb:Tep.
On 20/11/2022 03:06, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:[SNIP]
No, MSP and XSP are still alive and paying some salaries in the group I
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 :-)
work in at Fujitsu Oz. :-)
Last time I read it, the Fujitsu mainframes were still 31 bit.
Is that the case?
On 11/15/2022 6:09 PM, Dorothy J Heydt wrote:
In article <tkmbd3$uc0u$[email protected]>,
Lynn McGuire <[email protected]> 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 ?
On 20/11/2022 20:57, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:Tep.
On 20/11/2022 03:06, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:[SNIP]
No, MSP and XSP are still alive and paying some salaries in the group I
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 :-)
work in at Fujitsu Oz. :-)
Last time I read it, the Fujitsu mainframes were still 31 bit.
Is that the case?
But only an idiot does anything other than approximations using floating point.
Gary R. Schmidt <[email protected]> schrieb:
On 20/11/2022 20:57, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:Tep.
On 20/11/2022 03:06, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:[SNIP]
No, MSP and XSP are still alive and paying some salaries in the group I >>>> work in at Fujitsu Oz. :-)
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 :-)
Last time I read it, the Fujitsu mainframes were still 31 bit.
Is that the case?
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 <[email protected]> schrieb:
On 20/11/2022 20:57, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:Tep.
On 20/11/2022 03:06, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:[SNIP]
No, MSP and XSP are still alive and paying some salaries in the group I >>>>> work in at Fujitsu Oz. :-)
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 :-)
Last time I read it, the Fujitsu mainframes were still 31 bit.
Is that the case?
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.
On 22/11/2022 07:21, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:
On 20/11/2022 20:57, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:Tep.
On 20/11/2022 03:06, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:[SNIP]
No, MSP and XSP are still alive and paying some salaries in the group I >>>>> work in at Fujitsu Oz. :-)
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 :-)
Last time I read it, the Fujitsu mainframes were still 31 bit.
Is that the case?
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.
On Tue, 22 Nov 2022 14:23:35 +1100, "Gary R. Schmidt"
<[email protected]> wrote:
On 22/11/2022 07:21, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:
On 20/11/2022 20:57, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:Tep.
On 20/11/2022 03:06, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:[SNIP]
No, MSP and XSP are still alive and paying some salaries in the group I >>>>>> work in at Fujitsu Oz. :-)You've looked at what IBM mainframe run these days, right? zOS isn't >>>>>>> the only game in town :-)
1 - No, massively parallel Linux boxes don't do the same job[2]. >>>>>>>
Last time I read it, the Fujitsu mainframes were still 31 bit.
Is that the case?
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.
Gary R. Schmidt <[email protected]> schrieb:
On 22/11/2022 07:21, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:
On 20/11/2022 20:57, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:Tep.
On 20/11/2022 03:06, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:[SNIP]
No, MSP and XSP are still alive and paying some salaries in the group I >>>>>> work in at Fujitsu Oz. :-)You've looked at what IBM mainframe run these days, right? zOS isn't >>>>>>> the only game in town :-)
1 - No, massively parallel Linux boxes don't do the same job[2]. >>>>>>>
Last time I read it, the Fujitsu mainframes were still 31 bit.
Is that the case?
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"
<[email protected]> wrote:
On 22/11/2022 07:21, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:
On 20/11/2022 20:57, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:Tep.
On 20/11/2022 03:06, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:[SNIP]
No, MSP and XSP are still alive and paying some salaries in the group I >>>>>> work in at Fujitsu Oz. :-)You've looked at what IBM mainframe run these days, right? zOS isn't >>>>>>> the only game in town :-)
1 - No, massively parallel Linux boxes don't do the same job[2]. >>>>>>>
Last time I read it, the Fujitsu mainframes were still 31 bit.
Is that the case?
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.
On 23/11/2022 04:19, Paul S Person wrote:
On Tue, 22 Nov 2022 14:23:35 +1100, "Gary R. Schmidt"
<[email protected]> wrote:
On 22/11/2022 07:21, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:
On 20/11/2022 20:57, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:Tep.
On 20/11/2022 03:06, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:[SNIP]
No, MSP and XSP are still alive and paying some salaries in the group I >>>>>>> work in at Fujitsu Oz. :-)You've looked at what IBM mainframe run these days, right? zOS isn't >>>>>>>> the only game in town :-)
1 - No, massively parallel Linux boxes don't do the same job[2]. >>>>>>>>
Last time I read it, the Fujitsu mainframes were still 31 bit.
Is that the case?
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.
On 11/22/2022 11:19 AM, Paul S Person wrote:
On Tue, 22 Nov 2022 14:23:35 +1100, "Gary R. Schmidt"
<[email protected]> wrote:
On 22/11/2022 07:21, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:
On 20/11/2022 20:57, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:Tep.
On 20/11/2022 03:06, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:[SNIP]
No, MSP and XSP are still alive and paying some salaries in the group I >>>>>>> work in at Fujitsu Oz. :-)You've looked at what IBM mainframe run these days, right? zOS isn't >>>>>>>> the only game in town :-)
1 - No, massively parallel Linux boxes don't do the same job[2]. >>>>>>>>
Last time I read it, the Fujitsu mainframes were still 31 bit.
Is that the case?
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.
On Thu, 17 Nov 2022 21:22:42 GMT, [email protected] (Dorothy J
Heydt) wrote:
In article <[email protected]>,
Ninapenda Jibini <[email protected]> wrote:
[email protected] (Scott Lurndal) wrote in >>>news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there are likelyYou sound just like the doom criers ("Give me money or you'll
lots of small embedded 32-bit processors in devices like routers
which may exhibit issues, if they're still running 16 years from
now.
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.
In article <[email protected]>,
Paul S Person <[email protected]d> wrote:
On Thu, 17 Nov 2022 21:22:42 GMT, [email protected] (Dorothy J
Heydt) wrote:
In article <[email protected]>,
Ninapenda Jibini <[email protected]> wrote:
[email protected] (Scott Lurndal) wrote in >>>>news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there are likelyYou sound just like the doom criers ("Give me money or you'll
lots of small embedded 32-bit processors in devices like routers
which may exhibit issues, if they're still running 16 years from
now.
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, [email protected] (Dorothy J
Heydt) wrote:
In article <[email protected]>,
Paul S Person <[email protected]d> wrote:
On Thu, 17 Nov 2022 21:22:42 GMT, [email protected] (Dorothy J
Heydt) wrote:
In article <[email protected]>,
Ninapenda Jibini <[email protected]> wrote:
[email protected] (Scott Lurndal) wrote in
news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there are likelyYou sound just like the doom criers ("Give me money or you'll
lots of small embedded 32-bit processors in devices like routers
which may exhibit issues, if they're still running 16 years from
now.
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).
On Wed, 23 Nov 2022 13:41:15 +1100, "Gary R. Schmidt"
<[email protected]> wrote:
On 23/11/2022 04:19, Paul S Person wrote:
On Tue, 22 Nov 2022 14:23:35 +1100, "Gary R. Schmidt"
<[email protected]> wrote:
On 22/11/2022 07:21, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:
On 20/11/2022 20:57, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:Tep.
On 20/11/2022 03:06, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:[SNIP]
No, MSP and XSP are still alive and paying some salaries in the group IYou've looked at what IBM mainframe run these days, right? zOS isn't >>>>>>>>> the only game in town :-)
1 - No, massively parallel Linux boxes don't do the same job[2]. >>>>>>>>>
work in at Fujitsu Oz. :-)
Last time I read it, the Fujitsu mainframes were still 31 bit.
Is that the case?
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.
Lynn McGuire <[email protected]> schrieb:
On 11/15/2022 6:09 PM, Dorothy J Heydt wrote:
In article <tkmbd3$uc0u$[email protected]>,
Lynn McGuire <[email protected]> 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.
Thomas Koenig <[email protected]> wrote:
Lynn McGuire <[email protected]> schrieb:
On 11/15/2022 6:09 PM, Dorothy J Heydt wrote:
In article <tkmbd3$uc0u$[email protected]>,
Lynn McGuire <[email protected]> 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.
On 11/23/22 12:03 PM, Paul S Person wrote:
On Wed, 23 Nov 2022 13:41:15 +1100, "Gary R. Schmidt"
<[email protected]> wrote:
On 23/11/2022 04:19, Paul S Person wrote:
On Tue, 22 Nov 2022 14:23:35 +1100, "Gary R. Schmidt"
<[email protected]> wrote:
On 22/11/2022 07:21, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:
On 20/11/2022 20:57, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:Tep.
On 20/11/2022 03:06, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:[SNIP]
No, MSP and XSP are still alive and paying some salaries in the group IYou've looked at what IBM mainframe run these days, right? zOS isn't
1 - No, massively parallel Linux boxes don't do the same job[2]. >>>>>>>>>>
the only game in town :-)
work in at Fujitsu Oz. :-)
Last time I read it, the Fujitsu mainframes were still 31 bit. >>>>>>>> Is that the case?
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.
On 11/24/2022 9:13 AM, Paul S Person wrote:
On Wed, 23 Nov 2022 20:42:22 GMT, [email protected] (Dorothy J
Heydt) wrote:
In article <[email protected]>,
Paul S Person <[email protected]d> wrote:
On Thu, 17 Nov 2022 21:22:42 GMT, [email protected] (Dorothy J
Heydt) wrote:
In article <[email protected]>,
Ninapenda Jibini <[email protected]> wrote:
[email protected] (Scott Lurndal) wrote in
news:l9PbL.74464$[email protected]:
For the most part, a nothingburger. However, there are likelyYou sound just like the doom criers ("Give me money or you'll
lots of small embedded 32-bit processors in devices like routers >>>>>>> which may exhibit issues, if they're still running 16 years from >>>>>>> now.
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!
On Thu, 24 Nov 2022 15:36:29 -0500, John W KennedyWhat “associated OSes” would they be? RISC OS? Palm OS Cobalt? Virtually all system software running on ARM has been ported to it after having
<[email protected]> wrote:
On 11/23/22 12:03 PM, Paul S Person wrote:
On Wed, 23 Nov 2022 13:41:15 +1100, "Gary R. Schmidt"
<[email protected]> wrote:
On 23/11/2022 04:19, Paul S Person wrote:
On Tue, 22 Nov 2022 14:23:35 +1100, "Gary R. Schmidt"
<[email protected]> wrote:
On 22/11/2022 07:21, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:
On 20/11/2022 20:57, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:Tep.
On 20/11/2022 03:06, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:[SNIP]
No, MSP and XSP are still alive and paying some salaries in the group IYou've looked at what IBM mainframe run these days, right? zOS isn't
1 - No, massively parallel Linux boxes don't do the same job[2]. >>>>>>>>>>>
the only game in town :-)
work in at Fujitsu Oz. :-)
Last time I read it, the Fujitsu mainframes were still 31 bit. >>>>>>>>> Is that the case?
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
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.
On 11/25/22 12:00 PM, Paul S Person wrote:
On Thu, 24 Nov 2022 15:36:29 -0500, John W KennedyWhat �associated OSes� would they be? RISC OS? Palm OS Cobalt? Virtually
<[email protected]> wrote:
On 11/23/22 12:03 PM, Paul S Person wrote:
On Wed, 23 Nov 2022 13:41:15 +1100, "Gary R. Schmidt"
<[email protected]> wrote:
On 23/11/2022 04:19, Paul S Person wrote:
On Tue, 22 Nov 2022 14:23:35 +1100, "Gary R. Schmidt"
<[email protected]> wrote:
On 22/11/2022 07:21, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:
On 20/11/2022 20:57, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:Tep.
On 20/11/2022 03:06, Thomas Koenig wrote:
Gary R. Schmidt <[email protected]> schrieb:[SNIP]
No, MSP and XSP are still alive and paying some salaries in the group IYou've looked at what IBM mainframe run these days, right? zOS isn't
1 - No, massively parallel Linux boxes don't do the same job[2]. >>>>>>>>>>>>
the only game in town :-)
work in at Fujitsu Oz. :-)
Last time I read it, the Fujitsu mainframes were still 31 bit. >>>>>>>>>> Is that the case?
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
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.
On Thu, 24 Nov 2022 15:36:29 -0500, John W Kennedy
<[email protected]> wrote:
Badly written software - or simply badly /conceived/ software - can kill >>>> any CPU.
That's /always/ the excuse when the big promises turn out to be, at
best, overly optimistic.
I seem to recall that the theory was that no such software could
possibly exist with the new OSes.
Huh? ARM isn�t an OS; it�s a RISC architecture.
It was claimed that the associated OSes would never lose anything.
IIRC.
It was the End of Windows, the End of DLL Hell, the End of Lost
Resources -- a New Age of Computing.
Paul S Person <[email protected]d> writes:
On Thu, 24 Nov 2022 15:36:29 -0500, John W Kennedy >><[email protected]> wrote:
Badly written software - or simply badly /conceived/ software - can kill >>>>> any CPU.
That's /always/ the excuse when the big promises turn out to be, at
best, overly optimistic.
I seem to recall that the theory was that no such software could
possibly exist with the new OSes.
Huh? ARM isn�t an OS; it�s a RISC architecture.
It was claimed that the associated OSes would never lose anything.
IIRC.
Claimed by whom?
It was the End of Windows, the End of DLL Hell, the End of Lost
Resources -- a New Age of Computing.
Computing preceeded Windows and has never been dependent upon
it.
There is far more to the computing world than Microsoft.
On Sat, 26 Nov 2022 17:26:44 GMT, [email protected] (Scott Lurndal)
wrote:
Paul S Person <[email protected]d> writes:
On Thu, 24 Nov 2022 15:36:29 -0500, John W Kennedy >>><[email protected]> wrote:
Badly written software - or simply badly /conceived/ software - can kill >>>>>> any CPU.
That's /always/ the excuse when the big promises turn out to be, at
best, overly optimistic.
I seem to recall that the theory was that no such software could
possibly exist with the new OSes.
Huh? ARM isn�t an OS; it�s a RISC architecture.
It was claimed that the associated OSes would never lose anything.
IIRC.
Claimed by whom?
The people making the promises about RISC. IIRC.
This was, what, 30 years ago? 25? Details fade.
It is the RISC proponents who were making these predictions.
And, BTW, my Windows computers run on /segmented archtectures/, not on
RISC.
IIRC, Intel /tried/ a RISC processor -- but nobody was willing to take
a chance on it for a really /lucrative/ market, like the PC Clone
market.
And, BTW, my Windows computers run on /segmented archtectures/, not on
RISC.
Paul S Person <[email protected]d> writes:
On Sat, 26 Nov 2022 17:26:44 GMT, [email protected] (Scott
Lurndal) wrote:
Paul S Person <[email protected]d> writes:
On Thu, 24 Nov 2022 15:36:29 -0500, John W Kennedy >>>><[email protected]> wrote:
Badly written software - or simply badly /conceived/
software - can kill any CPU.
That's /always/ the excuse when the big promises turn out
to be, at best, overly optimistic.
I seem to recall that the theory was that no such software
could possibly exist with the new OSes.
Huh? ARM isn�t an OS; it�s a RISC architecture.
It was claimed that the associated OSes would never lose
anything. IIRC.
Claimed by whom?
The people making the promises about RISC. IIRC.
This was, what, 30 years ago? 25? Details fade.
I've been in the hardware and OS side of the business for longer
than that, and worked on and OS for the early RISC processor
from Motrola, the 88100. I've never heard such a claim about
"OS never loosing anything"[*].
It is the RISC proponents who were making these predictions.
You'll need to find some citations to support your memory.
The claims about RISC have always been around the simplicity
of the hardware providing a path to easier and less
expensive implementation.
Paul S Person <[email protected]d> writes:
On Sat, 26 Nov 2022 17:26:44 GMT, [email protected] (Scott Lurndal)
wrote:
Paul S Person <[email protected]d> writes:
On Thu, 24 Nov 2022 15:36:29 -0500, John W Kennedy
<[email protected]> wrote:
Badly written software - or simply badly /conceived/ software - can kill
any CPU.
That's /always/ the excuse when the big promises turn out to be, at >>>>>> best, overly optimistic.
I seem to recall that the theory was that no such software could
possibly exist with the new OSes.
Huh? ARM isn’t an OS; it’s a RISC architecture.
It was claimed that the associated OSes would never lose anything.
IIRC.
Claimed by whom?
The people making the promises about RISC. IIRC.
This was, what, 30 years ago? 25? Details fade.
I've been in the hardware and OS side of the business for longer
than that, and worked on and OS for the early RISC processor
from Motrola, the 88100. I've never heard such a claim about
"OS never loosing anything"[*].
It is the RISC proponents who were making these predictions.
You'll need to find some citations to support your memory.
The claims about RISC have always been around the simplicity
of the hardware providing a path to easier and less
expensive implementation.
And, BTW, my Windows computers run on /segmented archtectures/, not on
RISC.
Windows hasn't run on a "segmented architecture" since NT was
introduced. And the current generation 64-bit x86 architecture
is very RISC-like in the hardware internals. They've done a masterful
job in keeping an ancient 16-bit architecture relevent in modern
times.
IIRC, Intel /tried/ a RISC processor -- but nobody was willing to take
a chance on it for a really /lucrative/ market, like the PC Clone
market.
The main issue with the i860 (and later with the P7/Merced/Itanium)
is the difficulty in predicting code paths at compile time rather
than at run-time (as is done in modern RISC designs).
Both the failed processor projects (i860 and Itanium) performance
relied on advanced compiler technology being able to predict the
hot code-paths at compile time. Didn't work out. That was not
related to RISC, but rather the design choices of the processor
vendor.
RISC, as an acronym (Reduced Instruction Set Computer) is somewhat
of a misnomer today; Many modern RISC processors have hundreds
or even thousands (e.g. ARMv8) of instructions; many optional.
A more modern definition may be that a RISC processor today has
dedicated load and store instructions for accessing memory and
have a large general purpose register file (where in a classic
CISC CPU like the VAX or x86, many instructions can access memory
directly without first loading a value in a small register file).
[*] Although there were claims floating around about MVS being
fairly robust, that was due the OS code checking pre and post-
conditions in almost every function at the cost of some performance.
Paul S Person <[email protected]d> schrieb:
And, BTW, my Windows computers run on /segmented archtectures/, not on
RISC.
You are still running a 32-bit versions of Windows? Wow.
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.
On 11/27/22 12:53 PM, Scott Lurndal wrote:
Paul S Person <[email protected]d> writes:
And, BTW, my Windows computers run on /segmented archtectures/, not on
RISC.
Windows hasn't run on a "segmented architecture" since NT was
introduced. And the current generation 64-bit x86 architecture
is very RISC-like in the hardware internals. They've done a masterful
job in keeping an ancient 16-bit architecture relevent in modern
times.
There is an ARM Windows, though, is there not?
Bwah-ha-ha-ha! I can remember when IBM’s most popular mainframe maxed
out at 16,000 six-bit characters.
On Sat, 26 Nov 2022 17:26:44 GMT, [email protected] (Scott Lurndal)
wrote:
Paul S Person <[email protected]d> writes:
On Thu, 24 Nov 2022 15:36:29 -0500, John W Kennedy
<[email protected]> wrote:
Badly written software - or simply badly /conceived/ software - can kill >>>>>> any CPU.
That's /always/ the excuse when the big promises turn out to be, at
best, overly optimistic.
I seem to recall that the theory was that no such software could
possibly exist with the new OSes.
Huh? ARM isn’t an OS; it’s a RISC architecture.
It was claimed that the associated OSes would never lose anything.
IIRC.
Claimed by whom?
The people making the promises about RISC. IIRC.
This was, what, 30 years ago? 25? Details fade.
It was the End of Windows, the End of DLL Hell, the End of Lost
Resources -- a New Age of Computing.
Computing preceeded Windows and has never been dependent upon
it.
There is far more to the computing world than Microsoft.
It is the RISC proponents who were making these predictions.
And, BTW, my Windows computers run on /segmented archtectures/, not on
RISC.
IIRC, Intel /tried/ a RISC processor -- but nobody was willing to take
a chance on it for a really /lucrative/ market, like the PC Clone
market.
John W Kennedy <[email protected]> writes:
On 11/27/22 12:53 PM, Scott Lurndal wrote:
Paul S Person <[email protected]d> writes:
And, BTW, my Windows computers run on /segmented archtectures/, not on >>>> RISC.
Windows hasn't run on a "segmented architecture" since NT was
introduced. And the current generation 64-bit x86 architecture
is very RISC-like in the hardware internals. They've done a masterful
job in keeping an ancient 16-bit architecture relevent in modern
times.
There is an ARM Windows, though, is there not?
There have been Windows implementations for MIPS, ARM, Alpha and PowerPC.
None of which are segmented architectures (leaving aside MIPS KSEG0/1/2/U which aren't segments in the traditional sense; the user portion of the address space is paged).
John W Kennedy <[email protected]> writes:
On 11/27/22 12:53 PM, Scott Lurndal wrote:
Paul S Person <[email protected]d> writes:
And, BTW, my Windows computers run on /segmented archtectures/, not on >>>> RISC.
Windows hasn't run on a "segmented architecture" since NT was
introduced. And the current generation 64-bit x86 architecture
is very RISC-like in the hardware internals. They've done a masterful
job in keeping an ancient 16-bit architecture relevent in modern
times.
There is an ARM Windows, though, is there not?
There have been Windows implementations for MIPS, ARM, Alpha and PowerPC.
None of which are segmented architectures (leaving aside MIPS KSEG0/1/2/U which aren't segments in the traditional sense; the user portion of the address space is paged).
In article <tlhr3e$3nihq$[email protected]>,
Thomas Koenig <[email protected]> wrote:
An iPad has 3GB RAM these days, it is astonishing that serious
business work can be done in a 2GB address space. But I suspect
that many applications come from earlier times, when 2GB was
luxury undreamt of.
(Hal Heydt)
Raspberry Pi 4 Model B comes with up to 8GB. I run the DunDraCon
con reg on a pair (replicated database) of 4GB models. I used to
run it on 1GB SBCs. The shift was because the Pi4B finally got
fast enough I/O to suit me. Con reg kind of rattles around loose
with that much RAM. I suspect that MariaDB just sucks the entire
database into memory.
[email protected] (Scott Lurndal) wrote in >news:huNgL.314169$[email protected]:
Paul S Person <[email protected]d> writes:I suspect that, as an industry insider, you've seen technical
On Sat, 26 Nov 2022 17:26:44 GMT, [email protected] (Scott
Lurndal) wrote:
Paul S Person <[email protected]d> writes:
On Thu, 24 Nov 2022 15:36:29 -0500, John W Kennedy >>>>><[email protected]> wrote:
Badly written software - or simply badly /conceived/
software - can kill any CPU.
That's /always/ the excuse when the big promises turn out
to be, at best, overly optimistic.
I seem to recall that the theory was that no such software
could possibly exist with the new OSes.
Huh? ARM isn�t an OS; it�s a RISC architecture.
It was claimed that the associated OSes would never lose
anything. IIRC.
Claimed by whom?
The people making the promises about RISC. IIRC.
This was, what, 30 years ago? 25? Details fade.
I've been in the hardware and OS side of the business for longer
than that, and worked on and OS for the early RISC processor
from Motrola, the 88100. I've never heard such a claim about
"OS never loosing anything"[*].
It is the RISC proponents who were making these predictions.
You'll need to find some citations to support your memory.
The claims about RISC have always been around the simplicity
of the hardware providing a path to easier and less
expensive implementation.
claims by technical people, and he's seen marketing claims by
marketing "people".
And you know how accurate marketing claims are.
Paul S Person <[email protected]d> schrieb:
And, BTW, my Windows computers run on /segmented archtectures/, not on
RISC.
You are still running a 32-bit versions of Windows? Wow.
On Sun, 27 Nov 2022 18:30:23 GMT, Ninapenda Jibini
<[email protected]> wrote:
[email protected] (Scott Lurndal) wrote in >>news:huNgL.314169$[email protected]:
Paul S Person <[email protected]d> writes:I suspect that, as an industry insider, you've seen technical
On Sat, 26 Nov 2022 17:26:44 GMT, [email protected] (Scott
Lurndal) wrote:
Paul S Person <[email protected]d> writes:
On Thu, 24 Nov 2022 15:36:29 -0500, John W Kennedy >>>>>><[email protected]> wrote:
Badly written software - or simply badly /conceived/
software - can kill any CPU.
That's /always/ the excuse when the big promises turn out
to be, at best, overly optimistic.
I seem to recall that the theory was that no such
software could possibly exist with the new OSes.
Huh? ARM isn�t an OS; it�s a RISC architecture.
It was claimed that the associated OSes would never lose
anything. IIRC.
Claimed by whom?
The people making the promises about RISC. IIRC.
This was, what, 30 years ago? 25? Details fade.
I've been in the hardware and OS side of the business for
longer than that, and worked on and OS for the early RISC
processor from Motrola, the 88100. I've never heard such a
claim about "OS never loosing anything"[*].
It is the RISC proponents who were making these predictions.
You'll need to find some citations to support your memory.
The claims about RISC have always been around the simplicity
of the hardware providing a path to easier and less
expensive implementation.
claims by technical people, and he's seen marketing claims by
marketing "people".
And you know how accurate marketing claims are.
I think both points are quite possible.
Although some of it may have come from articles in BYTE or DDJ.
So perhaps "enthusiasts" rather than "marketing".
In article <[email protected]>,
John W Kennedy <[email protected]> wrote:
Bwah-ha-ha-ha! I can remember when IBM’s most popular mainframe maxed
out at 16,000 six-bit characters.
(Hal Heydt)
That would be the IBM 1401. Minimum memory was 1.2K.
Autocoder is one the languages I learned Way Back When. Then
proceeded to use it on an IBM S/360-30 with 1401 emulation because
that shop was still running Autocoder programs in production in
the early 1970s.
I first encountered the RISC concept in the article in the IBM Journal
of R&D about the experimental 801 processor and I don’t recall ever
hearing such a claim, either. They talked about performance, compiler simplification, and cost (especially by completely purging microcode).
And it’s fairly well known that, when Acorn picked up the concept, it
was to meet an “impossible” spec.
Windows hasn't run on a "segmented architecture" since NT was
introduced. And the current generation 64-bit x86 architecture
is very RISC-like in the hardware internals. They've done a masterful
job in keeping an ancient 16-bit architecture relevent in modern
times.
There is an ARM Windows, though, is there not?
There have been Windows implementations for MIPS, ARM, Alpha and PowerPC.Vobis (a German computer discounter at the
time) actually offered an Alpha with Windows, the
"Highscreen Alpha 5000". You can see their catalog at https://www.schmalenstroer.net/books/Alte%20Kataloge/Vobis%20Denkzettel%201997-07-24.pdf
(have to scroll down a bit).
With its PALcode, the Alpha was designed with different operating
systems in mind.
Paul S Person <[email protected]d> wrote in news:[email protected]:
On Sun, 27 Nov 2022 18:30:23 GMT, Ninapenda Jibini
<[email protected]> wrote:
[email protected] (Scott Lurndal) wrote in
news:huNgL.314169$[email protected]:
Paul S Person <[email protected]d> writes:I suspect that, as an industry insider, you've seen technical
On Sat, 26 Nov 2022 17:26:44 GMT, [email protected] (Scott
Lurndal) wrote:
Paul S Person <[email protected]d> writes:
On Thu, 24 Nov 2022 15:36:29 -0500, John W Kennedy
<[email protected]> wrote:
Badly written software - or simply badly /conceived/
software - can kill any CPU.
That's /always/ the excuse when the big promises turn out
to be, at best, overly optimistic.
I seem to recall that the theory was that no such
software could possibly exist with the new OSes.
Huh? ARM isn’t an OS; it’s a RISC architecture.
It was claimed that the associated OSes would never lose
anything. IIRC.
Claimed by whom?
The people making the promises about RISC. IIRC.
This was, what, 30 years ago? 25? Details fade.
I've been in the hardware and OS side of the business for
longer than that, and worked on and OS for the early RISC
processor from Motrola, the 88100. I've never heard such a
claim about "OS never loosing anything"[*].
It is the RISC proponents who were making these predictions.
You'll need to find some citations to support your memory.
The claims about RISC have always been around the simplicity
of the hardware providing a path to easier and less
expensive implementation.
claims by technical people, and he's seen marketing claims by
marketing "people".
And you know how accurate marketing claims are.
I think both points are quite possible.
Although some of it may have come from articles in BYTE or DDJ.
So perhaps "enthusiasts" rather than "marketing".
Entusiasts are simply parroting the marketing spiel.
Paul S Person <[email protected]d> wrote in >news:[email protected]:
On Sun, 27 Nov 2022 18:30:23 GMT, Ninapenda Jibini
<[email protected]> wrote:
[email protected] (Scott Lurndal) wrote in >>>news:huNgL.314169$[email protected]:
Paul S Person <[email protected]d> writes:I suspect that, as an industry insider, you've seen technical
On Sat, 26 Nov 2022 17:26:44 GMT, [email protected] (Scott
Lurndal) wrote:
Paul S Person <[email protected]d> writes:
On Thu, 24 Nov 2022 15:36:29 -0500, John W Kennedy >>>>>>><[email protected]> wrote:
Badly written software - or simply badly /conceived/
software - can kill any CPU.
That's /always/ the excuse when the big promises turn out
to be, at best, overly optimistic.
I seem to recall that the theory was that no such
software could possibly exist with the new OSes.
Huh? ARM isn�t an OS; it�s a RISC architecture.
It was claimed that the associated OSes would never lose >>>>>>>anything. IIRC.
Claimed by whom?
The people making the promises about RISC. IIRC.
This was, what, 30 years ago? 25? Details fade.
I've been in the hardware and OS side of the business for
longer than that, and worked on and OS for the early RISC
processor from Motrola, the 88100. I've never heard such a
claim about "OS never loosing anything"[*].
It is the RISC proponents who were making these predictions.
You'll need to find some citations to support your memory.
The claims about RISC have always been around the simplicity
of the hardware providing a path to easier and less
expensive implementation.
claims by technical people, and he's seen marketing claims by
marketing "people".
And you know how accurate marketing claims are.
I think both points are quite possible.
Although some of it may have come from articles in BYTE or DDJ.
So perhaps "enthusiasts" rather than "marketing".
Entusiasts are simply parroting the marketing spiel.
On 11/28/2022 12:47 AM, Thomas Koenig wrote:
There have been Windows implementations for MIPS, ARM, Alpha and PowerPC. >> Vobis (a German computer discounter at thetime) actually offered an Alpha with Windows, the
"Highscreen Alpha 5000". You can see their catalog at
https://www.schmalenstroer.net/books/Alte%20Kataloge/Vobis%20Denkzettel%201997-07-24.pdf
(have to scroll down a bit).
With its PALcode, the Alpha was designed with different operating
systems in mind.
There were at least a couple dozen Alphas that could run NT or 2000. At
one orkspace I maintained three DS10s, two VMS and one NT.
On 29/11/2022 05:08, Jibini Kula Tumbili Kujisalimisha wrote:
Paul S Person <[email protected]d> wrote inBut how do you tell the difference???? :-)
news:[email protected]:
On Sun, 27 Nov 2022 18:30:23 GMT, Ninapenda Jibini
<[email protected]> wrote:
[email protected] (Scott Lurndal) wrote in
news:huNgL.314169$[email protected]:
Paul S Person <[email protected]d> writes:I suspect that, as an industry insider, you've seen technical
On Sat, 26 Nov 2022 17:26:44 GMT, [email protected]
(Scott Lurndal) wrote:
Paul S Person <[email protected]d> writes:
On Thu, 24 Nov 2022 15:36:29 -0500, John W Kennedy
<[email protected]> wrote:
Badly written software - or simply badly /conceived/
software - can kill any CPU.
That's /always/ the excuse when the big promises turn
out to be, at best, overly optimistic.
I seem to recall that the theory was that no such
software could possibly exist with the new OSes.
Huh? ARM isn’t an OS; it’s a RISC architecture.
It was claimed that the associated OSes would never lose
anything. IIRC.
Claimed by whom?
The people making the promises about RISC. IIRC.
This was, what, 30 years ago? 25? Details fade.
I've been in the hardware and OS side of the business for
longer than that, and worked on and OS for the early RISC
processor from Motrola, the 88100. I've never heard such a
claim about "OS never loosing anything"[*].
It is the RISC proponents who were making these
predictions.
You'll need to find some citations to support your memory.
The claims about RISC have always been around the simplicity
of the hardware providing a path to easier and less
expensive implementation.
claims by technical people, and he's seen marketing claims by
marketing "people".
And you know how accurate marketing claims are.
I think both points are quite possible.
Although some of it may have come from articles in BYTE or
DDJ. So perhaps "enthusiasts" rather than "marketing".
Entusiasts are simply parroting the marketing spiel.
On Mon, 28 Nov 2022 11:08:29 -0700, Jibini Kula Tumbili Kujisalimisha ><[email protected]> wrote:
BTW, has anyone else noticed this interesting progression:
1) A claim is reported that RISC processors will take over the world.
2) I point out that this same claim was made 25 (say) years ago, and
it didn't happen.
3) Others claim that modern "segmented" processors are really RISC
processors which mimic segmentation so the software will run.
Which, of course, leads to the question:
If RISC processors have /already/ taken over the world, why was the
new prediction made at all?
I suspect that, as always, we have long-since descended into semantic
mush.
Paul S Person <[email protected]d> writes:
I suspect that, as always, we have long-since descended into
semantic mush.
I suspect that you are reaching to make a pointless argument.
On Mon, 28 Nov 2022 11:08:29 -0700, Jibini Kula Tumbili
Kujisalimisha <[email protected]> wrote:
Paul S Person <[email protected]d> wrote in >>news:[email protected]:
On Sun, 27 Nov 2022 18:30:23 GMT, Ninapenda Jibini
<[email protected]> wrote:
[email protected] (Scott Lurndal) wrote in >>>>news:huNgL.314169$[email protected]:
Paul S Person <[email protected]d> writes:I suspect that, as an industry insider, you've seen technical
On Sat, 26 Nov 2022 17:26:44 GMT, [email protected] (Scott >>>>>>Lurndal) wrote:
Paul S Person <[email protected]d> writes:
On Thu, 24 Nov 2022 15:36:29 -0500, John W Kennedy >>>>>>>><[email protected]> wrote:
Badly written software - or simply badly /conceived/
software - can kill any CPU.
That's /always/ the excuse when the big promises turn
out to be, at best, overly optimistic.
I seem to recall that the theory was that no such
software could possibly exist with the new OSes.
Huh? ARM isn�t an OS; it�s a RISC architecture.
It was claimed that the associated OSes would never lose >>>>>>>>anything. IIRC.
Claimed by whom?
The people making the promises about RISC. IIRC.
This was, what, 30 years ago? 25? Details fade.
I've been in the hardware and OS side of the business for
longer than that, and worked on and OS for the early RISC
processor from Motrola, the 88100. I've never heard such a
claim about "OS never loosing anything"[*].
It is the RISC proponents who were making these predictions.
You'll need to find some citations to support your memory.
The claims about RISC have always been around the simplicity
of the hardware providing a path to easier and less
expensive implementation.
claims by technical people, and he's seen marketing claims by
marketing "people".
And you know how accurate marketing claims are.
I think both points are quite possible.
Although some of it may have come from articles in BYTE or
DDJ. So perhaps "enthusiasts" rather than "marketing".
Entusiasts are simply parroting the marketing spiel.
I'm not sure that was the case. There were, and probably still
are, a /lot/ of people who really really hate segmented
architectures and Windows. The marketing campaign was much, much
tamer.
BTW, has anyone else noticed this interesting progression:
1) A claim is reported that RISC processors will take over the
world. 2) I point out that this same claim was made 25 (say)
years ago, and it didn't happen.
3) Others claim that modern "segmented" processors are really
RISC processors which mimic segmentation so the software will
run.
Which, of course, leads to the question:
If RISC processors have /already/ taken over the world, why was
the new prediction made at all?
I suspect that, as always, we have long-since descended into
semantic mush.
On Tue, 29 Nov 2022 09:58:11 -0700, Jibini Kula Tumbili
Kujisalimisha <[email protected]> wrote:
[email protected] (Scott Lurndal) wrote in
news:3IrhL.7$[email protected]:
Paul S Person <[email protected]d> writes:Isn't that the whole purpose of Usenet?
I suspect that, as always, we have long-since descended into
semantic mush.
I suspect that you are reaching to make a pointless argument.
I don't know that that is the /whole/ purpose of Usenet -- but
it is certainly a common use and a lot of fun.
\
[email protected] (Scott Lurndal) wrote in
news:3IrhL.7$[email protected]:
Paul S Person <[email protected]d> writes:
Isn't that the whole purpose of Usenet?I suspect that, as always, we have long-since descended into
semantic mush.
I suspect that you are reaching to make a pointless argument.
On Mon, 28 Nov 2022 11:08:29 -0700, Jibini Kula Tumbili Kujisalimisha <[email protected]> wrote:
Paul S Person <[email protected]d> wrote in
news:[email protected]:
On Sun, 27 Nov 2022 18:30:23 GMT, Ninapenda Jibini
<[email protected]> wrote:
[email protected] (Scott Lurndal) wrote in
news:huNgL.314169$[email protected]:
Paul S Person <[email protected]d> writes:I suspect that, as an industry insider, you've seen technical
On Sat, 26 Nov 2022 17:26:44 GMT, [email protected] (Scott
Lurndal) wrote:
Paul S Person <[email protected]d> writes:
On Thu, 24 Nov 2022 15:36:29 -0500, John W Kennedy
<[email protected]> wrote:
Badly written software - or simply badly /conceived/
software - can kill any CPU.
That's /always/ the excuse when the big promises turn out
to be, at best, overly optimistic.
I seem to recall that the theory was that no such
software could possibly exist with the new OSes.
Huh? ARM isn’t an OS; it’s a RISC architecture.
It was claimed that the associated OSes would never lose
anything. IIRC.
Claimed by whom?
The people making the promises about RISC. IIRC.
This was, what, 30 years ago? 25? Details fade.
I've been in the hardware and OS side of the business for
longer than that, and worked on and OS for the early RISC
processor from Motrola, the 88100. I've never heard such a
claim about "OS never loosing anything"[*].
It is the RISC proponents who were making these predictions.
You'll need to find some citations to support your memory.
The claims about RISC have always been around the simplicity
of the hardware providing a path to easier and less
expensive implementation.
claims by technical people, and he's seen marketing claims by
marketing "people".
And you know how accurate marketing claims are.
I think both points are quite possible.
Although some of it may have come from articles in BYTE or DDJ.
So perhaps "enthusiasts" rather than "marketing".
Entusiasts are simply parroting the marketing spiel.
I'm not sure that was the case. There were, and probably still are, a
/lot/ of people who really really hate segmented architectures and
Windows. The marketing campaign was much, much tamer.
BTW, has anyone else noticed this interesting progression:
1) A claim is reported that RISC processors will take over the world.
2) I point out that this same claim was made 25 (say) years ago, and
it didn't happen.
3) Others claim that modern "segmented" processors are really RISC
processors which mimic segmentation so the software will run.
Which, of course, leads to the question:
If RISC processors have /already/ taken over the world, why was the
new prediction made at all?
I suspect that, as always, we have long-since descended into semantic
mush.
On 11/29/22 12:10 PM, Paul S Person wrote:
On Mon, 28 Nov 2022 11:08:29 -0700, Jibini Kula Tumbili Kujisalimisha
<[email protected]> wrote:
Paul S Person <[email protected]d> wrote in
news:[email protected]:
On Sun, 27 Nov 2022 18:30:23 GMT, Ninapenda Jibini
<[email protected]> wrote:
[email protected] (Scott Lurndal) wrote in
news:huNgL.314169$[email protected]:
Paul S Person <[email protected]d> writes:I suspect that, as an industry insider, you've seen technical
On Sat, 26 Nov 2022 17:26:44 GMT, [email protected] (Scott
Lurndal) wrote:
Paul S Person <[email protected]d> writes:
On Thu, 24 Nov 2022 15:36:29 -0500, John W Kennedy
<[email protected]> wrote:
Badly written software - or simply badly /conceived/
software - can kill any CPU.
That's /always/ the excuse when the big promises turn out >>>>>>>>>>> to be, at best, overly optimistic.
I seem to recall that the theory was that no such
software could possibly exist with the new OSes.
Huh? ARM isn’t an OS; it’s a RISC architecture.
It was claimed that the associated OSes would never lose
anything. IIRC.
Claimed by whom?
The people making the promises about RISC. IIRC.
This was, what, 30 years ago? 25? Details fade.
I've been in the hardware and OS side of the business for
longer than that, and worked on and OS for the early RISC
processor from Motrola, the 88100. I've never heard such a
claim about "OS never loosing anything"[*].
It is the RISC proponents who were making these predictions.
You'll need to find some citations to support your memory.
The claims about RISC have always been around the simplicity
of the hardware providing a path to easier and less
expensive implementation.
claims by technical people, and he's seen marketing claims by
marketing "people".
And you know how accurate marketing claims are.
I think both points are quite possible.
Although some of it may have come from articles in BYTE or DDJ.
So perhaps "enthusiasts" rather than "marketing".
Entusiasts are simply parroting the marketing spiel.
I'm not sure that was the case. There were, and probably still are, a
/lot/ of people who really really hate segmented architectures and
Windows. The marketing campaign was much, much tamer.
BTW, has anyone else noticed this interesting progression:
1) A claim is reported that RISC processors will take over the world.
Apart from legacy architectures dating back to the 60s or 70s, haven’t they?
And even the current implementations of z/Architecture are
implemented mostly as RISC, with a minority of opcodes invisibly
implemented in software using the hardware opcodes (a paradigm that
actually goes back to the S/360-44).
John W Kennedy <[email protected]> schrieb:
On 11/29/22 12:10 PM, Paul S Person wrote:
On Mon, 28 Nov 2022 11:08:29 -0700, Jibini Kula Tumbili Kujisalimisha
<[email protected]> wrote:
Paul S Person <[email protected]d> wrote in
news:[email protected]:
On Sun, 27 Nov 2022 18:30:23 GMT, Ninapenda Jibini
<[email protected]> wrote:
[email protected] (Scott Lurndal) wrote in
news:huNgL.314169$[email protected]:
Paul S Person <[email protected]d> writes:I suspect that, as an industry insider, you've seen technical
On Sat, 26 Nov 2022 17:26:44 GMT, [email protected] (Scott
Lurndal) wrote:
Paul S Person <[email protected]d> writes:
On Thu, 24 Nov 2022 15:36:29 -0500, John W Kennedy
<[email protected]> wrote:
Badly written software - or simply badly /conceived/ >>>>>>>>>>>>> software - can kill any CPU.
That's /always/ the excuse when the big promises turn out >>>>>>>>>>>> to be, at best, overly optimistic.
I seem to recall that the theory was that no such
software could possibly exist with the new OSes.
Huh? ARM isn’t an OS; it’s a RISC architecture.
It was claimed that the associated OSes would never lose
anything. IIRC.
Claimed by whom?
The people making the promises about RISC. IIRC.
This was, what, 30 years ago? 25? Details fade.
I've been in the hardware and OS side of the business for
longer than that, and worked on and OS for the early RISC
processor from Motrola, the 88100. I've never heard such a
claim about "OS never loosing anything"[*].
It is the RISC proponents who were making these predictions.
You'll need to find some citations to support your memory.
The claims about RISC have always been around the simplicity
of the hardware providing a path to easier and less
expensive implementation.
claims by technical people, and he's seen marketing claims by
marketing "people".
And you know how accurate marketing claims are.
I think both points are quite possible.
Although some of it may have come from articles in BYTE or DDJ.
So perhaps "enthusiasts" rather than "marketing".
Entusiasts are simply parroting the marketing spiel.
I'm not sure that was the case. There were, and probably still are, a
/lot/ of people who really really hate segmented architectures and
Windows. The marketing campaign was much, much tamer.
BTW, has anyone else noticed this interesting progression:
1) A claim is reported that RISC processors will take over the world.
Apart from legacy architectures dating back to the 60s or 70s, haven’t
they?
Well, yes and no - it is very much a matter of debate.
Old systems (like almost all versions of the /360, the VAX, the
Motorola 6800 or the DG Eclipse/MV of "The Soul of a New Machine"
fame ) used static microcode, where each instruction was split into
one or several microcode instructions, which were then executed.
The original RISC designs were, in a way, machines which exposed
the microcode directly to the user. At least the 801 was indeed
used as such, to run a /370 (I believe). They also used pipeplining
on their instructions to gain performance. They also (usually) had
one cycle per instruction, later versions had superscalar execution, out-of-order execution and whatnot.
Today's CISC designs like the different AMD64 versions out there
first translate their CICS instructions into micro-ops (microcode,
if you will), which they then pipeline, schedule out-of-order
and whatnot.
A relatively pure RISC design like the POWER still has many
instructions as a single micro-instructions, others are cracked
into two. I believe RISC-V is designed so that it is a relatively
pure RISC, and each instruction is designed so it more or
less can be implemented directly. Of course, they advertise
for instruction fusion for things they left out.
So... has RISC taken over the world? You could argue as well that
microcode (not static, but instructions that can be scheduled)
rules supreme in x86-world. This is slightly at variance with
the definition of microcode as it is used now (which is static
RAM the same sort of micro-ops that the main engine uses).
And even the current implementations of z/Architecture are
implemented mostly as RISC, with a minority of opcodes invisibly
implemented in software using the hardware opcodes (a paradigm that
actually goes back to the S/360-44).
That is _really_ hard to define. IIRC, the hardware runs a superset
of a subset of the instructions that the programmer sees, and they
use millicode (executing one machine instructions via several
other machine instructions of the same format, but with some additional
ones available which the programmer cannot use).
Backwards compatibility to the mid-1960s comes at a price...
John W Kennedy <[email protected]> schrieb:
On 11/29/22 12:10 PM, Paul S Person wrote:
On Mon, 28 Nov 2022 11:08:29 -0700, Jibini Kula Tumbili Kujisalimisha
<[email protected]> wrote:
Paul S Person <[email protected]d> wrote in
news:[email protected]:
On Sun, 27 Nov 2022 18:30:23 GMT, Ninapenda Jibini
<[email protected]> wrote:
[email protected] (Scott Lurndal) wrote in
news:huNgL.314169$[email protected]:
Paul S Person <[email protected]d> writes:I suspect that, as an industry insider, you've seen technical
On Sat, 26 Nov 2022 17:26:44 GMT, [email protected] (Scott
Lurndal) wrote:
Paul S Person <[email protected]d> writes:
On Thu, 24 Nov 2022 15:36:29 -0500, John W Kennedy
<[email protected]> wrote:
Badly written software - or simply badly /conceived/ >>>>>>>>>>>>> software - can kill any CPU.
That's /always/ the excuse when the big promises turn out >>>>>>>>>>>> to be, at best, overly optimistic.
I seem to recall that the theory was that no such
software could possibly exist with the new OSes.
Huh? ARM isn’t an OS; it’s a RISC architecture.
It was claimed that the associated OSes would never lose
anything. IIRC.
Claimed by whom?
The people making the promises about RISC. IIRC.
This was, what, 30 years ago? 25? Details fade.
I've been in the hardware and OS side of the business for
longer than that, and worked on and OS for the early RISC
processor from Motrola, the 88100. I've never heard such a
claim about "OS never loosing anything"[*].
It is the RISC proponents who were making these predictions.
You'll need to find some citations to support your memory.
The claims about RISC have always been around the simplicity
of the hardware providing a path to easier and less
expensive implementation.
claims by technical people, and he's seen marketing claims by
marketing "people".
And you know how accurate marketing claims are.
I think both points are quite possible.
Although some of it may have come from articles in BYTE or DDJ.
So perhaps "enthusiasts" rather than "marketing".
Entusiasts are simply parroting the marketing spiel.
I'm not sure that was the case. There were, and probably still are, a
/lot/ of people who really really hate segmented architectures and
Windows. The marketing campaign was much, much tamer.
BTW, has anyone else noticed this interesting progression:
1) A claim is reported that RISC processors will take over the world.
Apart from legacy architectures dating back to the 60s or 70s, haven’t
they?
Well, yes and no - it is very much a matter of debate.
Old systems (like almost all versions of the /360, the VAX, the
Motorola 6800 or the DG Eclipse/MV of "The Soul of a New Machine"
fame ) used static microcode, where each instruction was split into
one or several microcode instructions, which were then executed.
The original RISC designs were, in a way, machines which exposed
the microcode directly to the user. At least the 801 was indeed
used as such, to run a /370 (I believe).
They also used pipeplining
on their instructions to gain performance. They also (usually) had
one cycle per instruction, later versions had superscalar execution, out-of-order execution and whatnot.
Today's CISC designs like the different AMD64 versions out there
first translate their CICS instructions into micro-ops (microcode,
if you will), which they then pipeline, schedule out-of-order
and whatnot.
A relatively pure RISC design like the POWER still has many
instructions as a single micro-instructions, others are cracked
into two. I believe RISC-V is designed so that it is a relatively
pure RISC, and each instruction is designed so it more or
less can be implemented directly. Of course, they advertise
for instruction fusion for things they left out.
So... has RISC taken over the world? You could argue as well that
microcode (not static, but instructions that can be scheduled)
rules supreme in x86-world. This is slightly at variance with
the definition of microcode as it is used now (which is static
RAM the same sort of micro-ops that the main engine uses).
And even the current implementations of z/Architecture are
implemented mostly as RISC, with a minority of opcodes invisibly
implemented in software using the hardware opcodes (a paradigm that
actually goes back to the S/360-44).
That is _really_ hard to define. IIRC, the hardware runs a superset
of a subset of the instructions that the programmer sees, and they
use millicode (executing one machine instructions via several
other machine instructions of the same format, but with some additional
ones available which the programmer cannot use).
Backwards compatibility to the mid-1960s comes at a price...
n Sun, 27 Nov 2022 21:35:09 GMT, [email protected] (Dorothy J Heydt)
wrote:
In article <tlhr3e$3nihq$[email protected]>,
Thomas Koenig <[email protected]> wrote:
An iPad has 3GB RAM these days, it is astonishing that serious
business work can be done in a 2GB address space. But I suspect
that many applications come from earlier times, when 2GB was
luxury undreamt of.
(Hal Heydt)
Raspberry Pi 4 Model B comes with up to 8GB. I run the DunDraCon
con reg on a pair (replicated database) of 4GB models. I used to
run it on 1GB SBCs. The shift was because the Pi4B finally got
fast enough I/O to suit me. Con reg kind of rattles around loose
with that much RAM. I suspect that MariaDB just sucks the entire
database into memory.
My HP Envy has 12GB (IIRC, the HP Pavilion has 8GB).
In article <[email protected]>,
Paul S Person <[email protected]d> wrote:
n Sun, 27 Nov 2022 21:35:09 GMT, [email protected] (Dorothy J
Heydt) wrote:
In article <tlhr3e$3nihq$[email protected]>,
Thomas Koenig <[email protected]> wrote:
An iPad has 3GB RAM these days, it is astonishing that serious
business work can be done in a 2GB address space. But I
suspect that many applications come from earlier times, when
2GB was luxury undreamt of.
(Hal Heydt)
Raspberry Pi 4 Model B comes with up to 8GB. I run the
DunDraCon con reg on a pair (replicated database) of 4GB
models. I used to run it on 1GB SBCs. The shift was because
the Pi4B finally got fast enough I/O to suit me. Con reg kind
of rattles around loose with that much RAM. I suspect that
MariaDB just sucks the entire database into memory.
My HP Envy has 12GB (IIRC, the HP Pavilion has 8GB).
(Hal Heydt)
Ah...but do either of those machines sell for $55? (Ganted,
that's without PSU, keyboard, mouse/tracball, mass storage
device, cables, or monitor. But with a KVM switch, some of that
can be shared. Since I'm using 120GB SSDs for mass storage, the
*total* outlay for each Pi4B-4 is right about $100 since I
already had some of the required devices on hand.)
On Mon, 28 Nov 2022 11:08:29 -0700, Jibini Kula Tumbili Kujisalimisha ><[email protected]> wrote:
Paul S Person <[email protected]d> wrote in >>news:[email protected]:
On Sun, 27 Nov 2022 18:30:23 GMT, Ninapenda Jibini
<[email protected]> wrote:
[email protected] (Scott Lurndal) wrote in >>>>news:huNgL.314169$[email protected]:
Paul S Person <[email protected]d> writes:I suspect that, as an industry insider, you've seen technical
On Sat, 26 Nov 2022 17:26:44 GMT, [email protected] (Scott >>>>>>Lurndal) wrote:
Paul S Person <[email protected]d> writes:
On Thu, 24 Nov 2022 15:36:29 -0500, John W Kennedy >>>>>>>><[email protected]> wrote:
Badly written software - or simply badly /conceived/
software - can kill any CPU.
That's /always/ the excuse when the big promises turn out
to be, at best, overly optimistic.
I seem to recall that the theory was that no such
software could possibly exist with the new OSes.
Huh? ARM isn�t an OS; it�s a RISC architecture.
It was claimed that the associated OSes would never lose >>>>>>>>anything. IIRC.
Claimed by whom?
The people making the promises about RISC. IIRC.
This was, what, 30 years ago? 25? Details fade.
I've been in the hardware and OS side of the business for
longer than that, and worked on and OS for the early RISC
processor from Motrola, the 88100. I've never heard such a
claim about "OS never loosing anything"[*].
It is the RISC proponents who were making these predictions.
You'll need to find some citations to support your memory.
The claims about RISC have always been around the simplicity
of the hardware providing a path to easier and less
expensive implementation.
claims by technical people, and he's seen marketing claims by
marketing "people".
And you know how accurate marketing claims are.
I think both points are quite possible.
Although some of it may have come from articles in BYTE or DDJ.
So perhaps "enthusiasts" rather than "marketing".
Entusiasts are simply parroting the marketing spiel.
I'm not sure that was the case. There were, and probably still are, a
/lot/ of people who really really hate segmented architectures and
Windows. The marketing campaign was much, much tamer.
BTW, has anyone else noticed this interesting progression:
1) A claim is reported that RISC processors will take over the world.
2) I point out that this same claim was made 25 (say) years ago, and
it didn't happen.
3) Others claim that modern "segmented" processors are really RISC
processors which mimic segmentation so the software will run.
Which, of course, leads to the question:
If RISC processors have /already/ taken over the world, why was the
new prediction made at all?
I suspect that, as always, we have long-since descended into semantic
mush.
(Hal Heydt)
In a sense...RISC (in the form of ARM designs) *has* taken over
the world. Compare the annual sales of desktop and laptop sales
(mostly x86, Intel and AMD) against the sales of tablets and
"smart" phones (almost exclusively ARM/ARM-derived RISC designs).
In article <[email protected]>,
Paul S Person <[email protected]d> wrote:
n Sun, 27 Nov 2022 21:35:09 GMT, [email protected] (Dorothy J Heydt) >>wrote:
In article <tlhr3e$3nihq$[email protected]>,
Thomas Koenig <[email protected]> wrote:
An iPad has 3GB RAM these days, it is astonishing that serious
business work can be done in a 2GB address space. But I suspect
that many applications come from earlier times, when 2GB was
luxury undreamt of.
(Hal Heydt)
Raspberry Pi 4 Model B comes with up to 8GB. I run the DunDraCon
con reg on a pair (replicated database) of 4GB models. I used to
run it on 1GB SBCs. The shift was because the Pi4B finally got
fast enough I/O to suit me. Con reg kind of rattles around loose
with that much RAM. I suspect that MariaDB just sucks the entire >>>database into memory.
My HP Envy has 12GB (IIRC, the HP Pavilion has 8GB).
(Hal Heydt)
Ah...but do either of those machines sell for $55? (Ganted,
that's without PSU, keyboard, mouse/tracball, mass storage
device, cables, or monitor. But with a KVM switch, some of that
can be shared. Since I'm using 120GB SSDs for mass storage, the
*total* outlay for each Pi4B-4 is right about $100 since I
already had some of the required devices on hand.)
Dorothy J Heydt <[email protected]> schrieb:And somewhere in a box I have the same for the M88000 - it's two
(Hal Heydt)
In a sense...RISC (in the form of ARM designs) *has* taken over
the world. Compare the annual sales of desktop and laptop sales
(mostly x86, Intel and AMD) against the sales of tablets and
"smart" phones (almost exclusively ARM/ARM-derived RISC designs).
And now for the discussion if an architecture with 12000 pages of
manual can be called "reduced" in any meaningful way :-)
I have the Motorola 6800 handbook from 1979 upstairs, it's rather
thin.
Dorothy J Heydt <[email protected]> schrieb:
(Hal Heydt)
In a sense...RISC (in the form of ARM designs) *has* taken over
the world. Compare the annual sales of desktop and laptop sales
(mostly x86, Intel and AMD) against the sales of tablets and
"smart" phones (almost exclusively ARM/ARM-derived RISC designs).
And now for the discussion if an architecture with 12000 pages of
manual can be called "reduced" in any meaningful way :-)
I have the Motorola 6800 handbook from 1979 upstairs, it's rather
thin.
On 12/4/22 7:45 AM, Thomas Koenig wrote:
Dorothy J Heydt <[email protected]> schrieb:
(Hal Heydt)
In a sense...RISC (in the form of ARM designs) *has* taken over
the world. Compare the annual sales of desktop and laptop sales
(mostly x86, Intel and AMD) against the sales of tablets and
"smart" phones (almost exclusively ARM/ARM-derived RISC designs).
And now for the discussion if an architecture with 12000 pages of
manual can be called "reduced" in any meaningful way :-)
I have the Motorola 6800 handbook from 1979 upstairs, it's rather
thin.
All that proves is that not all architectures are documented in the same >detail. The most complex instructions that I know of in ARM are Load
Multiple and Store Multiple.
On 04/12/2022 23:45, Thomas Koenig wrote:
Dorothy J Heydt <[email protected]> schrieb:And somewhere in a box I have the same for the M88000 - it's two
(Hal Heydt)
In a sense...RISC (in the form of ARM designs) *has* taken over
the world. Compare the annual sales of desktop and laptop sales
(mostly x86, Intel and AMD) against the sales of tablets and
"smart" phones (almost exclusively ARM/ARM-derived RISC designs).
And now for the discussion if an architecture with 12000 pages of
manual can be called "reduced" in any meaningful way :-)
I have the Motorola 6800 handbook from 1979 upstairs, it's rather
thin.
volumes. :-)
On 12/4/22 7:45 AM, Thomas Koenig wrote:
Dorothy J Heydt <[email protected]> schrieb:
(Hal Heydt)
In a sense...RISC (in the form of ARM designs) *has* taken over
the world. Compare the annual sales of desktop and laptop sales
(mostly x86, Intel and AMD) against the sales of tablets and
"smart" phones (almost exclusively ARM/ARM-derived RISC designs).
And now for the discussion if an architecture with 12000 pages of
manual can be called "reduced" in any meaningful way :-)
I have the Motorola 6800 handbook from 1979 upstairs, it's rather
thin.
All that proves is that not all architectures are documented in the same detail. The most complex instructions that I know of in ARM are Load
Multiple and Store Multiple.
"Gary R. Schmidt" <[email protected]> writes:
On 04/12/2022 23:45, Thomas Koenig wrote:
Dorothy J Heydt <[email protected]> schrieb:And somewhere in a box I have the same for the M88000 - it's two
(Hal Heydt)
In a sense...RISC (in the form of ARM designs) *has* taken over
the world. Compare the annual sales of desktop and laptop sales
(mostly x86, Intel and AMD) against the sales of tablets and
"smart" phones (almost exclusively ARM/ARM-derived RISC designs).
And now for the discussion if an architecture with 12000 pages of
manual can be called "reduced" in any meaningful way :-)
I have the Motorola 6800 handbook from 1979 upstairs, it's rather
thin.
volumes. :-)
The original 88100 manual was a single volume for the processor
and a second for the 88200 (MMU).
[email protected] (Dorothy J Heydt) wrote in
news:[email protected]:
In article <[email protected]>,Complete kits start under $200, and prices in the last couple of
Paul S Person <[email protected]d> wrote:
n Sun, 27 Nov 2022 21:35:09 GMT, [email protected] (Dorothy J
Heydt) wrote:
In article <tlhr3e$3nihq$[email protected]>,
Thomas Koenig <[email protected]> wrote:
An iPad has 3GB RAM these days, it is astonishing that serious >>>>>business work can be done in a 2GB address space. But I
suspect that many applications come from earlier times, when
2GB was luxury undreamt of.
(Hal Heydt)
Raspberry Pi 4 Model B comes with up to 8GB. I run the
DunDraCon con reg on a pair (replicated database) of 4GB
models. I used to run it on 1GB SBCs. The shift was because
the Pi4B finally got fast enough I/O to suit me. Con reg kind
of rattles around loose with that much RAM. I suspect that
MariaDB just sucks the entire database into memory.
My HP Envy has 12GB (IIRC, the HP Pavilion has 8GB).
(Hal Heydt)
Ah...but do either of those machines sell for $55? (Ganted,
that's without PSU, keyboard, mouse/tracball, mass storage
device, cables, or monitor. But with a KVM switch, some of that
can be shared. Since I'm using 120GB SSDs for mass storage, the
*total* outlay for each Pi4B-4 is right about $100 since I
already had some of the required devices on hand.)
years have been *outrageiously* high. They'll come back down
eventually, to probably 2/3 of that or less.
In article <[email protected]>,
Ninapenda Jibini <[email protected]> wrote:
[email protected] (Dorothy J Heydt) wrote in >>news:[email protected]:
In article <[email protected]>,Complete kits start under $200, and prices in the last couple of
Paul S Person <[email protected]d> wrote:
n Sun, 27 Nov 2022 21:35:09 GMT, [email protected] (Dorothy
J Heydt) wrote:
In article <tlhr3e$3nihq$[email protected]>,
Thomas Koenig <[email protected]> wrote:
An iPad has 3GB RAM these days, it is astonishing that
serious business work can be done in a 2GB address space.
But I suspect that many applications come from earlier
times, when 2GB was luxury undreamt of.
(Hal Heydt)
Raspberry Pi 4 Model B comes with up to 8GB. I run the
DunDraCon con reg on a pair (replicated database) of 4GB
models. I used to run it on 1GB SBCs. The shift was because
the Pi4B finally got fast enough I/O to suit me. Con reg
kind of rattles around loose with that much RAM. I suspect
that MariaDB just sucks the entire database into memory.
My HP Envy has 12GB (IIRC, the HP Pavilion has 8GB).
(Hal Heydt)
Ah...but do either of those machines sell for $55? (Ganted,
that's without PSU, keyboard, mouse/tracball, mass storage
device, cables, or monitor. But with a KVM switch, some of
that can be shared. Since I'm using 120GB SSDs for mass
storage, the *total* outlay for each Pi4B-4 is right about
$100 since I already had some of the required devices on
hand.)
years have been *outrageiously* high. They'll come back down
eventually, to probably 2/3 of that or less.
(Hal Heydt)
Depends on how you buy them. If you go on FleaBay or the like,
yes, you'll pay way over list. If you stick to the authorized
resellers, then you get the RPF parts (SBC, case, video cable,
PSU) for list price.
On Sat, 3 Dec 2022 20:42:16 GMT, [email protected] (Dorothy J Heydt)
wrote:
In article <[email protected]>,
Paul S Person <[email protected]d> wrote:
n Sun, 27 Nov 2022 21:35:09 GMT, [email protected] (Dorothy J Heydt) >>>wrote:
In article <tlhr3e$3nihq$[email protected]>,
Thomas Koenig <[email protected]> wrote:
An iPad has 3GB RAM these days, it is astonishing that serious >>>>>business work can be done in a 2GB address space. But I suspect
that many applications come from earlier times, when 2GB was
luxury undreamt of.
(Hal Heydt)
Raspberry Pi 4 Model B comes with up to 8GB. I run the DunDraCon
con reg on a pair (replicated database) of 4GB models. I used to
run it on 1GB SBCs. The shift was because the Pi4B finally got
fast enough I/O to suit me. Con reg kind of rattles around loose
with that much RAM. I suspect that MariaDB just sucks the entire >>>>database into memory.
My HP Envy has 12GB (IIRC, the HP Pavilion has 8GB).
(Hal Heydt)
Ah...but do either of those machines sell for $55? (Ganted,
that's without PSU, keyboard, mouse/tracball, mass storage
device, cables, or monitor. But with a KVM switch, some of that
can be shared. Since I'm using 120GB SSDs for mass storage, the
*total* outlay for each Pi4B-4 is right about $100 since I
already had some of the required devices on hand.)
Of course not.
Even though I bought a desktop version [1] through Office Depot at a >discount. (This had two video outputs, DVI and VGA, rather than one
HDMI. As it happened, my existing monitors were both VGA, but one of
them had a DVI port and even included a DVI cable. OTOH, I had no
choice between wired and wireless mouse/keyboard; I got wireless and
so kept the existing trackball/keyboard.)
[1] It has been a while since I checked but, at least at one time, a >/portable/ version of the HP Envy existed -- at a much higher price
than the HP Pavilion I eventually bought or the desktop HP Envy.
In article <[email protected]>,
Paul S Person <[email protected]d> wrote:
On Sat, 3 Dec 2022 20:42:16 GMT, [email protected] (Dorothy J Heydt)
wrote:
In article <[email protected]>,
Paul S Person <[email protected]d> wrote:
n Sun, 27 Nov 2022 21:35:09 GMT, [email protected] (Dorothy J Heydt) >>>> wrote:
In article <tlhr3e$3nihq$[email protected]>,
Thomas Koenig <[email protected]> wrote:
An iPad has 3GB RAM these days, it is astonishing that serious
business work can be done in a 2GB address space. But I suspect
that many applications come from earlier times, when 2GB was
luxury undreamt of.
(Hal Heydt)
Raspberry Pi 4 Model B comes with up to 8GB. I run the DunDraCon
con reg on a pair (replicated database) of 4GB models. I used to
run it on 1GB SBCs. The shift was because the Pi4B finally got
fast enough I/O to suit me. Con reg kind of rattles around loose
with that much RAM. I suspect that MariaDB just sucks the entire
database into memory.
My HP Envy has 12GB (IIRC, the HP Pavilion has 8GB).
(Hal Heydt)
Ah...but do either of those machines sell for $55? (Ganted,
that's without PSU, keyboard, mouse/tracball, mass storage
device, cables, or monitor. But with a KVM switch, some of that
can be shared. Since I'm using 120GB SSDs for mass storage, the
*total* outlay for each Pi4B-4 is right about $100 since I
already had some of the required devices on hand.)
Of course not.
Even though I bought a desktop version [1] through Office Depot at a
discount. (This had two video outputs, DVI and VGA, rather than one
HDMI. As it happened, my existing monitors were both VGA, but one of
them had a DVI port and even included a DVI cable. OTOH, I had no
choice between wired and wireless mouse/keyboard; I got wireless and
so kept the existing trackball/keyboard.)
[1] It has been a while since I checked but, at least at one time, a
/portable/ version of the HP Envy existed -- at a much higher price
than the HP Pavilion I eventually bought or the desktop HP Envy.
(Hal Heydt)
DVI-D is signal compatable with HDMI. All you need is--a quite inexpensive--HDMI to DVI adapter. Or you can get HDMI to DVI
cables. I've got a good sized collection of monitors that all
have at least DVI input. Last batch of adapters I got were less
than $2 each.
VGA is a whole 'nother animal. Conversion requires an active
device and most of the cheap devices to do that aren't very
good. Plus converters are one way only. You get *either* HDMI to
VGA *or* VGA to HDMI.
The other headache that's coming along is DisplyPort (DP). Like
VGA conversion, any given device is either DP to HDMI or HDMI to
DP. DP to HDMI are very common. To find an HDMI to DP, you've
got to sift through a lot of entries. And, again, there are
quality issues as well as having to be an active device.
In article <[email protected]>,
Paul S Person <[email protected]d> wrote:
On Sat, 3 Dec 2022 20:42:16 GMT, [email protected] (Dorothy J Heydt) >>wrote:
In article <[email protected]>,
Paul S Person <[email protected]d> wrote:
n Sun, 27 Nov 2022 21:35:09 GMT, [email protected] (Dorothy J Heydt) >>>>wrote:
In article <tlhr3e$3nihq$[email protected]>,
Thomas Koenig <[email protected]> wrote:
An iPad has 3GB RAM these days, it is astonishing that serious >>>>>>business work can be done in a 2GB address space. But I suspect >>>>>>that many applications come from earlier times, when 2GB was
luxury undreamt of.
(Hal Heydt)
Raspberry Pi 4 Model B comes with up to 8GB. I run the DunDraCon
con reg on a pair (replicated database) of 4GB models. I used to
run it on 1GB SBCs. The shift was because the Pi4B finally got
fast enough I/O to suit me. Con reg kind of rattles around loose >>>>>with that much RAM. I suspect that MariaDB just sucks the entire >>>>>database into memory.
My HP Envy has 12GB (IIRC, the HP Pavilion has 8GB).
(Hal Heydt)
Ah...but do either of those machines sell for $55? (Ganted,
that's without PSU, keyboard, mouse/tracball, mass storage
device, cables, or monitor. But with a KVM switch, some of that
can be shared. Since I'm using 120GB SSDs for mass storage, the
*total* outlay for each Pi4B-4 is right about $100 since I
already had some of the required devices on hand.)
Of course not.
Even though I bought a desktop version [1] through Office Depot at a >>discount. (This had two video outputs, DVI and VGA, rather than one
HDMI. As it happened, my existing monitors were both VGA, but one of
them had a DVI port and even included a DVI cable. OTOH, I had no
choice between wired and wireless mouse/keyboard; I got wireless and
so kept the existing trackball/keyboard.)
[1] It has been a while since I checked but, at least at one time, a >>/portable/ version of the HP Envy existed -- at a much higher price
than the HP Pavilion I eventually bought or the desktop HP Envy.
(Hal Heydt)
DVI-D is signal compatable with HDMI. All you need is--a quite >inexpensive--HDMI to DVI adapter. Or you can get HDMI to DVI
cables. I've got a good sized collection of monitors that all
have at least DVI input. Last batch of adapters I got were less
than $2 each.
VGA is a whole 'nother animal. Conversion requires an active
device and most of the cheap devices to do that aren't very
good. Plus converters are one way only. You get *either* HDMI to
VGA *or* VGA to HDMI.
The other headache that's coming along is DisplyPort (DP). Like
VGA conversion, any given device is either DP to HDMI or HDMI to
DP. DP to HDMI are very common. To find an HDMI to DP, you've
got to sift through a lot of entries. And, again, there are
quality issues as well as having to be an active device.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 17:18:58 |
| Calls: | 12,103 |
| Calls today: | 3 |
| Files: | 15,004 |
| Messages: | 6,518,069 |