Groups > alt.folklore.computers > #218654 > unrolled thread

What is the oldest computer that could be used today for real work?

Started by	Jason Evans <jsevans@mailfence.com>
First post	2021-09-05 09:55 +0000
Last post	2021-10-08 07:27 -0700
Articles	20 on this page of 224 — 41 participants

Back to article view | Back to alt.folklore.computers

Page 5 of 12 — ← Prev page 1 … 3 4 [5] 6 7 … 12 Next page →

#218807

From	Thomas Koenig <tkoenig@netcologne.de>
Date	2021-09-11 11:36 +0000
Message-ID	<shi4c8$j7q$1@newsreader4.netcologne.de>
In reply to	#218798

Peter Flass <peter_flass@yahoo.com> schrieb:
> Scott Lurndal <scott@slp53.sl.home> wrote:
>> Dan Espen <dan1espen@gmail.com> writes:
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>> 
>>>> Dan Espen <dan1espen@gmail.com> writes:
>>>>> John Goerzen <jgoerzen@complete.org> writes:
>>>>> 
>>>>>> On 2021-09-08, Peter Flass <peter_flass@yahoo.com> wrote:
>>>>>>> You can still run programs compiled on a 360 on the latest z box.
>>>>>> 
>>>>>> I gotta say - that's darn impressive.  I'm not aware of anything else that
>>>>>> maintains compatibility that long; am I missing anything?
>>>>> 
>>>>> Nope.  S/360 in it's various flavors is the only survivor of that era.
>>>> 
>>>> Actually, that's not precisely true.  The Burroughs B5500 still lives on
>>>> as the Unisys Clearpath systems, and still supports object files from
>>>> the 1960s.
>>> 
>>> hmm, I actually have been in contact with some of those systems but had
>>> no idea they went back as far as 64.
>> 
>> Here's a video from 1968 on the B6500.  I worked at that plant in Pasadena
>> in the 1980s.
>> 
>> https://www.youtube.com/watch?v=rNBtjEBYFPk
>
> White shirts and ties, sideburns, and cigarettes in the office.

I have a similar video from the early 1970s about a building I came
to work in a few decades earlier.  Same style.

Unfortunately, I do not think I can share it, there are probably
all sorts of legal obstacles, such as the personality rights of
the persons who are shown working in it.

[toc] | [prev] | [next] | [standalone]

#218809

From	scott@slp53.sl.home (Scott Lurndal)
Date	2021-09-11 15:26 +0000
Message-ID	<hU3%I.76808$rl3.18118@fx45.iad>
In reply to	#218798

Peter Flass <peter_flass@yahoo.com> writes:
>Scott Lurndal <scott@slp53.sl.home> wrote:
>> Dan Espen <dan1espen@gmail.com> writes:
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>> 
>>>> Dan Espen <dan1espen@gmail.com> writes:
>>>>> John Goerzen <jgoerzen@complete.org> writes:
>>>>> 
>>>>>> On 2021-09-08, Peter Flass <peter_flass@yahoo.com> wrote:
>>>>>>> You can still run programs compiled on a 360 on the latest z box.
>>>>>> 
>>>>>> I gotta say - that's darn impressive.  I'm not aware of anything else that
>>>>>> maintains compatibility that long; am I missing anything?
>>>>> 
>>>>> Nope.  S/360 in it's various flavors is the only survivor of that era.
>>>> 
>>>> Actually, that's not precisely true.  The Burroughs B5500 still lives on
>>>> as the Unisys Clearpath systems, and still supports object files from
>>>> the 1960s.
>>> 
>>> hmm, I actually have been in contact with some of those systems but had
>>> no idea they went back as far as 64.
>> 
>> Here's a video from 1968 on the B6500.  I worked at that plant in Pasadena
>> in the 1980s.
>> 
>> https://www.youtube.com/watch?v=rNBtjEBYFPk
>
>White shirts and ties, sideburns, and cigarettes in the office.

It wasn't until 1986 that smoking in the Pasadena Burroughs plant
was fully banned.  I moved into an office in 1985 and I had to scrub
every surface to remove the nicotine stains and odor.

[toc] | [prev] | [next] | [standalone]

#218889

From	Branimir Maksimovic <branimir.maksimovic@gmail.com>
Date	2021-09-18 03:57 +0000
Message-ID	<msd1J.38112$2Q_3.23273@fx35.iad>
In reply to	#218764

On 2021-09-08, Peter Flass <peter_flass@yahoo.com> wrote:
> John Goerzen <jgoerzen@complete.org> wrote:
>> On 2021-09-07, J  Clarke <jclarke.873638@gmail.com> wrote:
>>>> https://governor.kansas.gov/wp-content/uploads/2021/04/GintherTaxCouncilKDOT.pdf
>>>> hints that it may be an IBM System 370/Model 145.
>>> 
>>> I'd be very surprised if it actually was.  When did IBM end
>>> maintenance on those?
>> 
>> I have no more information, other than that link claims "The Kansas UI System
>> runs on a Mainframe that was installed in 1977."
>> 
>> Is it possible the hardware was upgraded to something that can emulate the
>> 370/145, and that difference was lost on a non-technical author?  Sure.
>> 
>> I have known other places to run mainframes an absurdly long time.  I've seen it
>> in universities and, of course, there's the famous CompuServe PDP-10 story -
>> though presumably they had more technical know-how to keep their PDP-10s alive.
>> You are right; it does seem farfetched.
>> 
>> ... so I did some more digging, and found
>> https://ldh.la.gov/assets/medicaid/mmis/docs/IVVRProcurementLibrary/Section3RelevantCorporateExperienceCorporateFinancialCondition.doc
>> which claims that the "legacy UI system applications run on the Kansas
>> Department of Administration's OBM OS/390 mainframe."
>> 
>> I know little of IBM's mainframe lineup, but
>> https://en.wikipedia.org/wiki/IBM_System/390 claims that the System/390 has some
>> level of compatibility with the S/370.
>> 
>> - John
>> 
>
> You can still run programs compiled on a 360 on the latest “z” box.
>
Why?

-- 
bmaxa now listens rock.mp3

[toc] | [prev] | [next] | [standalone]

#218890

From	John Levine <johnl@taugh.com>
Date	2021-09-18 04:07 +0000
Message-ID	<si3omm$ii1$1@gal.iecc.com>
In reply to	#218889

According to Branimir Maksimovic  <branimir.maksimovic@gmail.com>:
>> You can still run programs compiled on a 360 on the latest “z” box.
>>
>Why?

Because they are still useful?  Is this a trick question?

-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

[toc] | [prev] | [next] | [standalone]

#218892

From	Ahem A Rivet's Shot <steveo@eircom.net>
Date	2021-09-18 07:27 +0100
Message-ID	<20210918072748.dd8a5db701b21fdbd9bd8b1f@eircom.net>
In reply to	#218890

On Sat, 18 Sep 2021 04:07:50 -0000 (UTC)
John Levine <johnl@taugh.com> wrote:

> According to Branimir Maksimovic  <branimir.maksimovic@gmail.com>:
> >> You can still run programs compiled on a 360 on the latest “z” box.
> >>
> >Why?
> 
> Because they are still useful?  Is this a trick question?

	I suppose the real question is why not recompile them to take
advantage of the newer hardware. I know during Y2K work that a lot of
instances of lost source code came to light, are people still running
binaries for which there is no source ?

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

[toc] | [prev] | [next] | [standalone]

#218893

From	Grant Taylor <gtaylor@tnetconsulting.net>
Date	2021-09-18 00:49 -0600
Message-ID	<si42c6$rr6$1@tncsrv09.home.tnetconsulting.net>
In reply to	#218892

On 9/18/21 12:27 AM, Ahem A Rivet's Shot wrote:
> 	I suppose the real question is why not recompile them to take
> advantage of the newer hardware. I know during Y2K work that a lot of
> instances of lost source code came to light, are people still running
> binaries for which there is no source ?

Why recompile something just for the sake of recompiling it?

If it's working just fine and is exhibiting no symptoms, why mess with it?



-- 
Grant. . . .
unix || die

[toc] | [prev] | [next] | [standalone]

#218896

From	J. Clarke <jclarke.873638@gmail.com>
Date	2021-09-18 05:47 -0400
Message-ID	<2bdbkg5dpehj9i8mp61o9asa558s0ighmd@4ax.com>
In reply to	#218893

On Sat, 18 Sep 2021 00:49:00 -0600, Grant Taylor
<gtaylor@tnetconsulting.net> wrote:

>On 9/18/21 12:27 AM, Ahem A Rivet's Shot wrote:
>> 	I suppose the real question is why not recompile them to take
>> advantage of the newer hardware. I know during Y2K work that a lot of
>> instances of lost source code came to light, are people still running
>> binaries for which there is no source ?
>
>Why recompile something just for the sake of recompiling it?
>
>If it's working just fine and is exhibiting no symptoms, why mess with it?

However sometimes there are binaries with no source.  Source was on a
tape or card deck that got archived and can no longer be found.

[toc] | [prev] | [next] | [standalone]

#218904

From	Peter Flass <peter_flass@yahoo.com>
Date	2021-09-18 11:02 -0700
Message-ID	<5212515.653680167.068231.peter_flass-yahoo.com@news.eternal-september.org>
In reply to	#218896

J. Clarke <jclarke.873638@gmail.com> wrote:
> On Sat, 18 Sep 2021 00:49:00 -0600, Grant Taylor
> <gtaylor@tnetconsulting.net> wrote:
> 
>> On 9/18/21 12:27 AM, Ahem A Rivet's Shot wrote:
>>> I suppose the real question is why not recompile them to take
>>> advantage of the newer hardware. I know during Y2K work that a lot of
>>> instances of lost source code came to light, are people still running
>>> binaries for which there is no source ?
>> 
>> Why recompile something just for the sake of recompiling it?
>> 
>> If it's working just fine and is exhibiting no symptoms, why mess with it?
> 
> However sometimes there are binaries with no source.  Source was on a
> tape or card deck that got archived and can no longer be found.
> 

Or at least messed up. I tried to rebuild the PL/I(F) compiler from source.
Several modules had minor problems, missing or extra END statements, but
one had a major problem: a large chunk of the program was missing. I spent
several days working from a disassembly to reconstruct the original.

IBM had a big fire at PID in Mechanicsburg, and a lot of sources went
missing. Digital Research lost the source to PL/I-86. The source for PL/C
hs not (yet) been found, although the executable still works fine.

-- 
Pete

[toc] | [prev] | [next] | [standalone]

#218907

From	J. Clarke <jclarke.873638@gmail.com>
Date	2021-09-18 16:07 -0400
Message-ID	<kkhckg9thoorgno7k3qe6kt1ldpm7ijk24@4ax.com>
In reply to	#218904

On Sat, 18 Sep 2021 11:02:05 -0700, Peter Flass
<peter_flass@yahoo.com> wrote:

>J. Clarke <jclarke.873638@gmail.com> wrote:
>> On Sat, 18 Sep 2021 00:49:00 -0600, Grant Taylor
>> <gtaylor@tnetconsulting.net> wrote:
>> 
>>> On 9/18/21 12:27 AM, Ahem A Rivet's Shot wrote:
>>>> I suppose the real question is why not recompile them to take
>>>> advantage of the newer hardware. I know during Y2K work that a lot of
>>>> instances of lost source code came to light, are people still running
>>>> binaries for which there is no source ?
>>> 
>>> Why recompile something just for the sake of recompiling it?
>>> 
>>> If it's working just fine and is exhibiting no symptoms, why mess with it?
>> 
>> However sometimes there are binaries with no source.  Source was on a
>> tape or card deck that got archived and can no longer be found.
>> 
>
>Or at least messed up. I tried to rebuild the PL/I(F) compiler from source.
>Several modules had minor problems, missing or extra END statements, but
>one had a major problem: a large chunk of the program was missing. I spent
>several days working from a disassembly to reconstruct the original.
>
>IBM had a big fire at PID in Mechanicsburg, and a lot of sources went
>missing. Digital Research lost the source to PL/I-86. The source for PL/C
>hs not (yet) been found, although the executable still works fine.

And I remember the time that NASTRAN got dropped down the stairwell at
a PPOE.  Three floors with cards flying merrily the whole way.  I
_think_ they were all found (I had to be somewhere and didn't get to
participate in the search).

[toc] | [prev] | [next] | [standalone]

#218898

From	Ahem A Rivet's Shot <steveo@eircom.net>
Date	2021-09-18 15:52 +0100
Message-ID	<20210918155210.02c1c46cfbb0456d26a4ee94@eircom.net>
In reply to	#218893

On Sat, 18 Sep 2021 00:49:00 -0600
Grant Taylor <gtaylor@tnetconsulting.net> wrote:

> On 9/18/21 12:27 AM, Ahem A Rivet's Shot wrote:
> > 	I suppose the real question is why not recompile them to take
> > advantage of the newer hardware. I know during Y2K work that a lot of
> > instances of lost source code came to light, are people still running
> > binaries for which there is no source ?
> 
> Why recompile something just for the sake of recompiling it?
> 
> If it's working just fine and is exhibiting no symptoms, why mess with it?

	Yeah I get it, you might be depending on an old undocumented
compiler bug or you might fall foul of a new one so why risk the new shiny
compiler that might get 10% better performance and might break the
application.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

[toc] | [prev] | [next] | [standalone]

#218905

From	Peter Flass <peter_flass@yahoo.com>
Date	2021-09-18 11:02 -0700
Message-ID	<1489844861.653680428.804943.peter_flass-yahoo.com@news.eternal-september.org>
In reply to	#218898

Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> On Sat, 18 Sep 2021 00:49:00 -0600
> Grant Taylor <gtaylor@tnetconsulting.net> wrote:
> 
>> On 9/18/21 12:27 AM, Ahem A Rivet's Shot wrote:
>>> I suppose the real question is why not recompile them to take
>>> advantage of the newer hardware. I know during Y2K work that a lot of
>>> instances of lost source code came to light, are people still running
>>> binaries for which there is no source ?
>> 
>> Why recompile something just for the sake of recompiling it?
>> 
>> If it's working just fine and is exhibiting no symptoms, why mess with it?
> 
> 	Yeah I get it, you might be depending on an old undocumented
> compiler bug or you might fall foul of a new one so why risk the new shiny
> compiler that might get 10% better performance and might break the
> application.
> 

I ran into this trying to recompile some code that was written for PL/I(F)
with the Enterprise compiler. Several constructs were rejected. This was in
gray areas where the documentation didn’t definitively allow or not allow
the code. After a while it became not worth it to me to make a lot of
changes to fit the new compiler.

-- 
Pete

[toc] | [prev] | [next] | [standalone]

#218909

From	Dan Espen <dan1espen@gmail.com>
Date	2021-09-18 17:46 -0400
Message-ID	<si5mn3$d5j$1@dont-email.me>
In reply to	#218905

Peter Flass <peter_flass@yahoo.com> writes:

> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>> On Sat, 18 Sep 2021 00:49:00 -0600
>> Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>> 
>>> On 9/18/21 12:27 AM, Ahem A Rivet's Shot wrote:
>>>> I suppose the real question is why not recompile them to take
>>>> advantage of the newer hardware. I know during Y2K work that a lot of
>>>> instances of lost source code came to light, are people still running
>>>> binaries for which there is no source ?
>>> 
>>> Why recompile something just for the sake of recompiling it?
>>> 
>>> If it's working just fine and is exhibiting no symptoms, why mess with it?
>> 
>> 	Yeah I get it, you might be depending on an old undocumented
>> compiler bug or you might fall foul of a new one so why risk the new shiny
>> compiler that might get 10% better performance and might break the
>> application.
>
> I ran into this trying to recompile some code that was written for PL/I(F)
> with the Enterprise compiler. Several constructs were rejected. This was in
> gray areas where the documentation didn’t definitively allow or not allow
> the code. After a while it became not worth it to me to make a lot of
> changes to fit the new compiler.

Similar here, large amounts of PL/I and a bit of it broke with
Enterprise PL/I.  Strange how a new compiler can suddenly make
uninitialized variables start causing problems.

We had more than that though including some new compiler bugs.

-- 
Dan Espen

[toc] | [prev] | [next] | [standalone]

#218926

From	cross@spitfire.i.gajendra.net (Dan Cross)
Date	2021-09-22 19:00 +0000
Message-ID	<sifuh5$47i$1@reader1.panix.com>
In reply to	#218898

In article <20210918155210.02c1c46cfbb0456d26a4ee94@eircom.net>,
Ahem A Rivet's Shot  <steveo@eircom.net> wrote:
>On Sat, 18 Sep 2021 00:49:00 -0600
>Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>> On 9/18/21 12:27 AM, Ahem A Rivet's Shot wrote:
>> > 	I suppose the real question is why not recompile them to take
>> > advantage of the newer hardware. I know during Y2K work that a lot of
>> > instances of lost source code came to light, are people still running
>> > binaries for which there is no source ?
>> 
>> Why recompile something just for the sake of recompiling it?
>> 
>> If it's working just fine and is exhibiting no symptoms, why mess with it?
>
>	Yeah I get it, you might be depending on an old undocumented
>compiler bug or you might fall foul of a new one so why risk the new shiny
>compiler that might get 10% better performance and might break the
>application.

By that logic, one should never upgrade anything if it can
be avoided.  An operating system upgrade in particular would
be terribly fraught.

It strikes me how much process we've built predicated on the
presumed difficulty of testing and qualifying software for
production use.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#218928

From	J. Clarke <jclarke.873638@gmail.com>
Date	2021-09-22 17:54 -0400
Message-ID	<8c9nkgl0159m3f0rvhpma1cdqg5b897qo9@4ax.com>
In reply to	#218926

On Wed, 22 Sep 2021 19:00:53 -0000 (UTC),
cross@spitfire.i.gajendra.net (Dan Cross) wrote:

>In article <20210918155210.02c1c46cfbb0456d26a4ee94@eircom.net>,
>Ahem A Rivet's Shot  <steveo@eircom.net> wrote:
>>On Sat, 18 Sep 2021 00:49:00 -0600
>>Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>>> On 9/18/21 12:27 AM, Ahem A Rivet's Shot wrote:
>>> > 	I suppose the real question is why not recompile them to take
>>> > advantage of the newer hardware. I know during Y2K work that a lot of
>>> > instances of lost source code came to light, are people still running
>>> > binaries for which there is no source ?
>>> 
>>> Why recompile something just for the sake of recompiling it?
>>> 
>>> If it's working just fine and is exhibiting no symptoms, why mess with it?
>>
>>	Yeah I get it, you might be depending on an old undocumented
>>compiler bug or you might fall foul of a new one so why risk the new shiny
>>compiler that might get 10% better performance and might break the
>>application.
>
>By that logic, one should never upgrade anything if it can
>be avoided.  An operating system upgrade in particular would
>be terribly fraught.
>
>It strikes me how much process we've built predicated on the
>presumed difficulty of testing and qualifying software for
>production use.

Nothing "presumed" about it.

[toc] | [prev] | [next] | [standalone]

#218975

From	cross@spitfire.i.gajendra.net (Dan Cross)
Date	2021-09-24 19:13 +0000
Message-ID	<sil802$hgg$1@reader1.panix.com>
In reply to	#218928

In article <8c9nkgl0159m3f0rvhpma1cdqg5b897qo9@4ax.com>,
J. Clarke  <jclarke.873638@gmail.com> wrote:
>On Wed, 22 Sep 2021 19:00:53 -0000 (UTC),
>cross@spitfire.i.gajendra.net (Dan Cross) wrote:
>>>	Yeah I get it, you might be depending on an old undocumented
>>>compiler bug or you might fall foul of a new one so why risk the new shiny
>>>compiler that might get 10% better performance and might break the
>>>application.
>>
>>By that logic, one should never upgrade anything if it can
>>be avoided.  An operating system upgrade in particular would
>>be terribly fraught.
>>
>>It strikes me how much process we've built predicated on the
>>presumed difficulty of testing and qualifying software for
>>production use.
>
>Nothing "presumed" about it.

Sure it is.  The level of difficulty depends entirely on
your processes and practices and how robust your test and
staging infrastructure is.  Some places do it very well.
Others, not so much.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#218983

From	J. Clarke <jclarke.873638@gmail.com>
Date	2021-09-24 18:37 -0400
Message-ID	<2fkskgluiu6o31kjfcgsmbh28m4jrek0bq@4ax.com>
In reply to	#218975

On Fri, 24 Sep 2021 19:13:06 -0000 (UTC),
cross@spitfire.i.gajendra.net (Dan Cross) wrote:

>In article <8c9nkgl0159m3f0rvhpma1cdqg5b897qo9@4ax.com>,
>J. Clarke  <jclarke.873638@gmail.com> wrote:
>>On Wed, 22 Sep 2021 19:00:53 -0000 (UTC),
>>cross@spitfire.i.gajendra.net (Dan Cross) wrote:
>>>>	Yeah I get it, you might be depending on an old undocumented
>>>>compiler bug or you might fall foul of a new one so why risk the new shiny
>>>>compiler that might get 10% better performance and might break the
>>>>application.
>>>
>>>By that logic, one should never upgrade anything if it can
>>>be avoided.  An operating system upgrade in particular would
>>>be terribly fraught.
>>>
>>>It strikes me how much process we've built predicated on the
>>>presumed difficulty of testing and qualifying software for
>>>production use.
>>
>>Nothing "presumed" about it.
>
>Sure it is.  The level of difficulty depends entirely on
>your processes and practices and how robust your test and
>staging infrastructure is.  Some places do it very well.
>Others, not so much.

If you feel like robusticizing the "processes and practices and test
and staging infrastructure" for a Fortune 500 financial services
company, I can give you a name to which you can send your sales pitch.
Make it shiny enough and put a big enough hook in it and he may even
bite.

[toc] | [prev] | [next] | [standalone]

#219068

From	cross@spitfire.i.gajendra.net (Dan Cross)
Date	2021-09-27 12:52 +0000
Message-ID	<siseqv$34u$1@reader1.panix.com>
In reply to	#218983

In article <2fkskgluiu6o31kjfcgsmbh28m4jrek0bq@4ax.com>,
J. Clarke  <jclarke.873638@gmail.com> wrote:
>On Fri, 24 Sep 2021 19:13:06 -0000 (UTC),
>cross@spitfire.i.gajendra.net (Dan Cross) wrote:
>>Sure it is.  The level of difficulty depends entirely on
>>your processes and practices and how robust your test and
>>staging infrastructure is.  Some places do it very well.
>>Others, not so much.
>
>If you feel like robusticizing the "processes and practices and test
>and staging infrastructure" for a Fortune 500 financial services
>company, I can give you a name to which you can send your sales pitch.
>Make it shiny enough and put a big enough hook in it and he may even
>bite.

So you admit that those processes and practices are below
those of industry standards in more modern organizations.
Cool.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#218931

From	Dan Espen <dan1espen@gmail.com>
Date	2021-09-22 21:15 -0400
Message-ID	<sigker$kfe$1@dont-email.me>
In reply to	#218926

cross@spitfire.i.gajendra.net (Dan Cross) writes:

> In article <20210918155210.02c1c46cfbb0456d26a4ee94@eircom.net>,
> Ahem A Rivet's Shot  <steveo@eircom.net> wrote:
>>On Sat, 18 Sep 2021 00:49:00 -0600
>>Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>>> On 9/18/21 12:27 AM, Ahem A Rivet's Shot wrote:
>>> > 	I suppose the real question is why not recompile them to take
>>> > advantage of the newer hardware. I know during Y2K work that a lot of
>>> > instances of lost source code came to light, are people still running
>>> > binaries for which there is no source ?
>>> 
>>> Why recompile something just for the sake of recompiling it?
>>> 
>>> If it's working just fine and is exhibiting no symptoms, why mess with it?
>>
>>	Yeah I get it, you might be depending on an old undocumented
>>compiler bug or you might fall foul of a new one so why risk the new shiny
>>compiler that might get 10% better performance and might break the
>>application.
>
> By that logic, one should never upgrade anything if it can
> be avoided.  An operating system upgrade in particular would
> be terribly fraught.
>
> It strikes me how much process we've built predicated on the
> presumed difficulty of testing and qualifying software for
> production use.

You only update software when the benefit justifies the cost.

-- 
Dan Espen

[toc] | [prev] | [next] | [standalone]

#218932

From	J. Clarke <jclarke.873638@gmail.com>
Date	2021-09-22 22:34 -0400
Message-ID	<nmpnkg93i7a8vui9b5qbnvdms0da6uu2g5@4ax.com>
In reply to	#218931

On Wed, 22 Sep 2021 21:15:07 -0400, Dan Espen <dan1espen@gmail.com>
wrote:

>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>
>> In article <20210918155210.02c1c46cfbb0456d26a4ee94@eircom.net>,
>> Ahem A Rivet's Shot  <steveo@eircom.net> wrote:
>>>On Sat, 18 Sep 2021 00:49:00 -0600
>>>Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>>>> On 9/18/21 12:27 AM, Ahem A Rivet's Shot wrote:
>>>> > 	I suppose the real question is why not recompile them to take
>>>> > advantage of the newer hardware. I know during Y2K work that a lot of
>>>> > instances of lost source code came to light, are people still running
>>>> > binaries for which there is no source ?
>>>> 
>>>> Why recompile something just for the sake of recompiling it?
>>>> 
>>>> If it's working just fine and is exhibiting no symptoms, why mess with it?
>>>
>>>	Yeah I get it, you might be depending on an old undocumented
>>>compiler bug or you might fall foul of a new one so why risk the new shiny
>>>compiler that might get 10% better performance and might break the
>>>application.
>>
>> By that logic, one should never upgrade anything if it can
>> be avoided.  An operating system upgrade in particular would
>> be terribly fraught.
>>
>> It strikes me how much process we've built predicated on the
>> presumed difficulty of testing and qualifying software for
>> production use.
>
>You only update software when the benefit justifies the cost.

I wish our management understood that.  I spend half my time
recovering from "updates".

[toc] | [prev] | [next] | [standalone]

#218933

From	Charlie Gibbs <cgibbs@kltpzyxm.invalid>
Date	2021-09-23 02:51 +0000
Message-ID	<JYR2J.36706$rsCb.11019@fx01.iad>
In reply to	#218931

On 2021-09-23, Dan Espen <dan1espen@gmail.com> wrote:

> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>
>> In article <20210918155210.02c1c46cfbb0456d26a4ee94@eircom.net>,
>> Ahem A Rivet's Shot  <steveo@eircom.net> wrote:
>>
>>> On Sat, 18 Sep 2021 00:49:00 -0600
>>> Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>>>
>>>> On 9/18/21 12:27 AM, Ahem A Rivet's Shot wrote:
>>>>
>>>>> 	I suppose the real question is why not recompile them to take
>>>>> advantage of the newer hardware. I know during Y2K work that a lot of
>>>>> instances of lost source code came to light, are people still running
>>>>> binaries for which there is no source ?
>>>> 
>>>> Why recompile something just for the sake of recompiling it?
>>>> 
>>>> If it's working just fine and is exhibiting no symptoms, why mess with it?
>>>
>>>	Yeah I get it, you might be depending on an old undocumented
>>> compiler bug or you might fall foul of a new one so why risk the
>>> new shiny compiler that might get 10% better performance and might
>>> break the application.
>>
>> By that logic, one should never upgrade anything if it can
>> be avoided.  An operating system upgrade in particular would
>> be terribly fraught.

s/would be/is/

Especially if you have no mechanism for parallel testing
prior to the cutover.

>> It strikes me how much process we've built predicated on the
>> presumed difficulty of testing and qualifying software for
>> production use.
>
> You only update software when the benefit justifies the cost.

Sadly, people now update software whenever the vendor tells them to
(or does it behind their back).

Last year I heard that a number of 911 sites went down (i.e. no
dial tone) for at least half an hour thanks to a buggy Windows
update that was pushed out to them.

-- 
/~\  Charlie Gibbs                  |  Life is perverse.
\ /  <cgibbs@kltpzyxm.invalid>      |  It can be beautiful -
 X   I'm really at ac.dekanfrus     |  but it won't.
/ \  if you read it the right way.  |    -- Lily Tomlin

[toc] | [prev] | [next] | [standalone]

Page 5 of 12 — ← Prev page 1 … 3 4 [5] 6 7 … 12 Next page →

csiph-web

What is the oldest computer that could be used today for real work?

Contents

#218807

#218809

#218889

#218890

#218892

#218893

#218896

#218904

#218907

#218898

#218905

#218909

#218926

#218928

#218975

#218983

#219068

#218931

#218932

#218933