On 17/04/2024 22:57, Lawrence D'Oliveiro wrote:
> On Wed, 17 Apr 2024 09:16:07 +0100, The Natural Philosopher wrote:
>
>> You have a system running on DEC PDP-11s: The guys
>> who wrote the software are dead, the company that supplied it went out
>> of business years ago, and no one will even offer a support contract on
>> it, But it runs your trains perfectly.
>
> If you could really afford to spend millions on the hardware, then it
> would be peanuts by comparison to add on a software support contract that
> will provide maintenance and updates for the expected life of the
> hardware.

Stop wriggling.

Software costs way more than hardware.

That's what you spent the money on, and the support contract with the
company that no longer exists is not worth wiping your bottom with.

--
To ban Christmas, simply give turkeys the vote.

On Wed, 17 Apr 2024 23:01:36 +0100, The Natural Philosopher wrote:

> Software costs way more than hardware.

You’re not suggesting the customer can’t afford to pay for it, are you?

On 18/04/2024 00:23, Lawrence D'Oliveiro wrote:
> On Wed, 17 Apr 2024 23:01:36 +0100, The Natural Philosopher wrote:
>
>> Software costs way more than hardware.
>
> You’re not suggesting the customer can’t afford to pay for it, are you?

Stop being deliberately obtuse , and thinking like an Apple or Microsoft
customer.

When did you last upgrade the firmware in your watch? What support
contract is there on your washing machine? Is your house still under
warranty, or does it simply not have a support contract?

Perhaps you should buy a new one, You can surely afford to.

--
“A leader is best When people barely know he exists. Of a good leader,
who talks little,When his work is done, his aim fulfilled,They will say,
“We did this ourselves.”

― Lao Tzu, Tao Te Ching

On Thu, 18 Apr 2024 08:35:12 +0100, The Natural Philosopher wrote:

> On 18/04/2024 00:23, Lawrence D'Oliveiro wrote:
>
>> On Wed, 17 Apr 2024 23:01:36 +0100, The Natural Philosopher wrote:
>>
>>> Software costs way more than hardware.
>>
>> You’re not suggesting the customer can’t afford to pay for it, are you?
>
> [irrelevant blather about non-business-related products]

Is that a yes or a no?

On Wed, 17 Apr 2024, The Natural Philosopher wrote:

> On 17/04/2024 22:57, Lawrence D'Oliveiro wrote:
>> On Wed, 17 Apr 2024 09:16:07 +0100, The Natural Philosopher wrote:
>>
>>> You have a system running on DEC PDP-11s: The guys
>>> who wrote the software are dead, the company that supplied it went out
>>> of business years ago, and no one will even offer a support contract on
>>> it, But it runs your trains perfectly.
>>
>> If you could really afford to spend millions on the hardware, then it
>> would be peanuts by comparison to add on a software support contract that
>> will provide maintenance and updates for the expected life of the
>> hardware.
>
> Stop wriggling.
>
> Software costs way more than hardware.
>
> That's what you spent the money on, and the support contract with the company
> that no longer exists is not worth wiping your bottom with.

Could also be different budgets behind the decision. I've sold to many
companies where what ever I was selling didn't fit within _that_ specific
budget, and then we had to repackage into a service, define it as hardware
etc. etc. to make the sale. I find it fascinating that Lawrence tries to
argue with the guy who was actually there.

(Followups trimmed to comp.os.linux.misc)

In <5be4132e-b5d3-3dbf-24cd-9eec844aa0a8@example.net> D:

[Snip...]

> I find it fascinating that Lawrence tries to
> argue with the guy who was actually there.

It's what trolls do, totally unfazed by reality.

HTH, YMMV ...

--
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at att, dotted with net. * DO NOT SPAM IT. *
I toss GoogleGroup (http://twovoyagers.com/improve-usenet.org/).

In comp.os.linux.misc D <nospam@example.net> wrote:
> I find it fascinating that Lawrence tries to argue with the guy who
> was actually there.

I'm moving more and more with each of Lawrence's responses to the
belief that he is actually trolling. He's not far now from earning a
killfile slot of his very own.

In comp.os.linux.misc The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 18/04/2024 00:23, Lawrence D'Oliveiro wrote:
>> On Wed, 17 Apr 2024 23:01:36 +0100, The Natural Philosopher wrote:
>>
>>> Software costs way more than hardware.
>>
>> You’re not suggesting the customer can’t afford to pay for it, are
>> you?
>
> Stop being deliberately obtuse, and thinking like an Apple or
> Microsoft customer.

Based on the DHCP replies from Lawrence, deliberately obtuse seems to
be his trolling modus-operandi.

> When did you last upgrade the firmware in your watch? What support
> contract is there on your washing machine? Is your house still under
> warranty, or does it simply not have a support contract?
>
> Perhaps you should buy a new one, You can surely afford to.

I would have predicted he would have ignored all of this, but he beat
me to proving that he deliberately ignored it.

Woozy Song <suzyw0ng@outlook.com> wrote at 01:22 this Wednesday (GMT):
> Marc Haber wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> On 64-bit systems (which is what most of us would be running by now),
>>
>> You need to think beyond your desktop PC. Linux runs on billions of
>> embedded systems, many of them being a 32 bit architecture and bound
>> to stay there. Embedded systems tend to have an order of magnitude
>> more in lifetime. The year 2038 is already here for those systems.
>>
>
> So don't get in an elevator on Jan 18/19 2038?

Hopefully it's like Y2K where not too much happens

dl6
--
user <candycane> is generated from /dev/urandom

On Thu, 18 Apr 2024, Rich wrote:

> In comp.os.linux.misc D <nospam@example.net> wrote:
>> I find it fascinating that Lawrence tries to argue with the guy who
>> was actually there.
>
> I'm moving more and more with each of Lawrence's responses to the
> belief that he is actually trolling. He's not far now from earning a
> killfile slot of his very own.
>

I mean, if someone insists on trolling, then please do it creatively and
in a fun way. Pursuing the monty python argument sketch does tend to get
tedious after a while. ;)

On 18/04/2024 16:00, candycanearter07 wrote:
> Woozy Song <suzyw0ng@outlook.com> wrote at 01:22 this Wednesday (GMT):
>> Marc Haber wrote:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>> On 64-bit systems (which is what most of us would be running by now),
>>>
>>> You need to think beyond your desktop PC. Linux runs on billions of
>>> embedded systems, many of them being a 32 bit architecture and bound
>>> to stay there. Embedded systems tend to have an order of magnitude
>>> more in lifetime. The year 2038 is already here for those systems.
>>>
>>
>> So don't get in an elevator on Jan 18/19 2038?
>
>
> Hopefully it's like Y2K where not too much happens
>
>
A lot of legacy COBOL had to be fixed, just not linux

> dl6

--
Climate Change: Socialism wearing a lab coat.

On Thu, 18 Apr 2024 11:27:29 +0200, D wrote:

> I find it fascinating that Lawrence tries to argue with the guy who was
> actually there.

I have encountered way too many cases of customers not taking the simple,
seemingly obvious precautions I mentioned, and then suffering the
consequences years later.

Surely “prevention is better than cure” is just common sense.

On Thu, 18 Apr 2024 16:35:55 -0400, The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 18/04/2024 16:00, candycanearter07 wrote:
>> Woozy Song <suzyw0ng@outlook.com> wrote at 01:22 this Wednesday (GMT):
>>> Marc Haber wrote:
>>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>>> On 64-bit systems (which is what most of us would be running by now),
>>>> You need to think beyond your desktop PC. Linux runs on billions of
>>>> embedded systems, many of them being a 32 bit architecture and bound
>>>> to stay there. Embedded systems tend to have an order of magnitude
>>>> more in lifetime. The year 2038 is already here for those systems.
>>>>
>>>
>>> So don't get in an elevator on Jan 18/19 2038?

>> Hopefully it's like Y2K where not too much happens

> A lot of legacy COBOL had to be fixed, just not linux

I first ran into the century problem in the early 1980's, in a COBOL program
that dealt with rail stock for a Canadian railway company. Some of the cars
have frames built in the 1800's. The wheel assemblies (truks) and couplers
had been replaced multiple times, but the cars themselves were over 100 years
old. That was when I first started insisting on keeping 4 digit years in systems
I designed or was able to get altered.

Just as y2k was minor, I expect 2038 will be too. Most programs store human
readable dates, not seconds since epoch timestamps.

Of those that do store timestamps, only those that require the data to be in
date and/or time order will need to have workarounds or fixes. Very few of those
are used in critical situations.

Reviewing and fixing all of the code will take a lot of time, but the impact
of failing to do that will rarely have important impacts.

Regards, Dave Hodgins

On 2024-04-18, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:

> I first ran into the century problem in the early 1980's, in a COBOL program
> that dealt with rail stock for a Canadian railway company. Some of the cars
> have frames built in the 1800's. The wheel assemblies (truks) and couplers
> had been replaced multiple times, but the cars themselves were over 100 years
> old.

Good one. At about the same time I was working on mortgage programs.
A 25-year amortization meant you had been thinking about Y2K for some
time by then.

> That was when I first started insisting on keeping 4 digit years in systems
> I designed or was able to get altered.

And I was insisting that the dates be stored in year-month-day format.

Back in the early '70s I was working in an all-card shop. One of the
compromises they made to squeeze a record's data into 80 card columns
was to store only the last single digit of the year. One of my first
assignments when I started there in 1970 was to go through all the
programs and change the '6' they were inserting into reports to a '7'.

Another compromise was the cards which held six months' worth of aged
accounts receivable data; we punched six 5-byte packed decimal fields
directly into the cards. That was a lot of holes - most of the columns
got 12-0-1-8-9 punches - and it made the cards noticeable floppy.
If you handled them carefully they passed through the reader OK.
If you weren't careful you could get some nasty card jams that
weren't easily fixed on a keypunch.

--
/~\ Charlie Gibbs | The Internet is like a big city:
\ / <cgibbs@kltpzyxm.invalid> | it has plenty of bright lights and
X I'm really at ac.dekanfrus | excitement, but also dark alleys
/ \ if you read it the right way. | down which the unwary get mugged.

On Thu, 18 Apr 2024 18:19:29 -0400, David W. Hodgins wrote:

> Most programs store human readable dates, not seconds since epoch
> timestamps.

*Cough* no. But my code (that I can think of) is a) not written in C, and
b) stores these timestamps in database fields, which can be easily
redefined.

The Natural Philosopher <tnp@invalid.invalid> wrote:
>On 18/04/2024 16:00, candycanearter07 wrote:
>> Woozy Song <suzyw0ng@outlook.com> wrote at 01:22 this Wednesday (GMT):
>>> Marc Haber wrote:
>>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>>> On 64-bit systems (which is what most of us would be running by now),
>>>>
>>>> You need to think beyond your desktop PC. Linux runs on billions of
>>>> embedded systems, many of them being a 32 bit architecture and bound
>>>> to stay there. Embedded systems tend to have an order of magnitude
>>>> more in lifetime. The year 2038 is already here for those systems.
>>>>
>>>
>>> So don't get in an elevator on Jan 18/19 2038?
>>
>>
>> Hopefully it's like Y2K where not too much happens
>>
>>
>A lot of legacy COBOL had to be fixed, just not linux

Also perl. Back in the 1990ies people actually believed that the date
function returned the year modulo 100 and just slapped a 19 in front
of its output. Bad assumption, it actually returns the year MINUS
1900, so it was at 100 in the year 2000 and it is at 124 now. So you
need to ADD 1900 to get a valid year.

That bug was so common that nerds said "happy new year 19101" a year
later and other people actually understood the joke.

Greetings
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Thu, 18 Apr 2024 18:19:29 -0400, David W. Hodgins wrote:
>
>> Most programs store human readable dates, not seconds since epoch
>> timestamps.
>
>*Cough* no. But my code (that I can think of) is a) not written in C, and
>b) stores these timestamps in database fields, which can be easily
>redefined.

That depends whether you consider an "ALTER TABLE" call for a BIG
table "easy" or not. It's something that many database admins work
hard to avoid.

Greetings
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

On Fri, 19 Apr 2024 07:29:48 +0200, Marc Haber wrote:

> Back in the 1990ies people actually believed that the date
> function returned the year modulo 100 and just slapped a 19 in front of
> its output. Bad assumption, it actually returns the year MINUS 1900, so
> it was at 100 in the year 2000 and it is at 124 now. So you need to ADD
> 1900 to get a valid year.

It had been documented to work that way many years before 2000--precisely
in anticipation of the problem, while trying to keep things backward-
compatible.

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Fri, 19 Apr 2024 07:29:48 +0200, Marc Haber wrote:
>
>> Back in the 1990ies people actually believed that the date
>> function returned the year modulo 100 and just slapped a 19 in front of
>> its output. Bad assumption, it actually returns the year MINUS 1900, so
>> it was at 100 in the year 2000 and it is at 124 now. So you need to ADD
>> 1900 to get a valid year.
>
>It had been documented to work that way many years before 2000--precisely
>in anticipation of the problem, while trying to keep things backward-
>compatible.

Of course it was documented as year-1900 from the very beginning. That
didnt keep software authors from silently assuming different.

Greetings
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

On Fri, 19 Apr 2024 08:49:10 +0200, Marc Haber wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>>On Fri, 19 Apr 2024 07:29:48 +0200, Marc Haber wrote:
>>
>>> Back in the 1990ies people actually believed that the date function
>>> returned the year modulo 100 and just slapped a 19 in front of its
>>> output. Bad assumption, it actually returns the year MINUS 1900, so it
>>> was at 100 in the year 2000 and it is at 124 now. So you need to ADD
>>> 1900 to get a valid year.
>>
>>It had been documented to work that way many years before
>>2000--precisely in anticipation of the problem, while trying to keep
>>things backward- compatible.
>
> Of course it was documented as year-1900 from the very beginning. That
> didnt keep software authors from silently assuming different.

Only ones who didn’t read the docs.

On 18/04/2024 23:06, Lawrence D'Oliveiro wrote:
> On Thu, 18 Apr 2024 11:27:29 +0200, D wrote:
>
>> I find it fascinating that Lawrence tries to argue with the guy who was
>> actually there.
>
> I have encountered way too many cases of customers not taking the simple,
> seemingly obvious precautions I mentioned, and then suffering the
> consequences years later.
>
> Surely “prevention is better than cure” is just common sense.

You remind me of my business partner who was being pressed by a salesman
to take out 'key man ' insurance 'in case I died'.

The final conclusions:
"So if we take out this insurance it will break the company financially,
100%, but if we don't and you don't die, it won't cost us a thing? No
brainer"

(Oddly, he is the one who has been dead many years from cancer despite
being a lot younger than I was).

ArtStudents™ think in terms of binary risk. Safe/not safe,. Real world
people understand statistical probabilities and think it terms of 'how
safe' and 'cost to improve risk ratio'.

We all laughed mightily when in the early days of the Internet,
companies all using "diverse routing" between POPs with *different
companies* /all/ fell over at the same time when a digger cut through
*all* the optical fibres connecting the North of England to the south.
Apparently all the fibre companies were using a single multifibre cable.

So many case are neither simple nor obvious when you actually examine
them in detail

--
"I am inclined to tell the truth and dislike people who lie consistently.
This makes me unfit for the company of people of a Left persuasion, and
all women"

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Fri, 19 Apr 2024 08:49:10 +0200, Marc Haber wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>>On Fri, 19 Apr 2024 07:29:48 +0200, Marc Haber wrote:
>>>
>>>> Back in the 1990ies people actually believed that the date function
>>>> returned the year modulo 100 and just slapped a 19 in front of its
>>>> output. Bad assumption, it actually returns the year MINUS 1900, so it
>>>> was at 100 in the year 2000 and it is at 124 now. So you need to ADD
>>>> 1900 to get a valid year.
>>>
>>>It had been documented to work that way many years before
>>>2000--precisely in anticipation of the problem, while trying to keep
>>>things backward- compatible.
>>
>> Of course it was documented as year-1900 from the very beginning. That
>> didnt keep software authors from silently assuming different.
>
>Only ones who didn’t read the docs.

Some discussions will only die when everything has been told by
everybody.

--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

On Fri, 19 Apr 2024 10:58:10 +0100, The Natural Philosopher wrote:

> You remind me of my business partner who was being pressed by a salesman
> to take out 'key man ' insurance 'in case I died'.

You remind me of this argument by analogy I read once. It proved that you
didn’t need logic to score points in an argument at all.

On Fri, 19 Apr 2024 13:40:41 +0200, Marc Haber wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>>Only ones who didn’t read the docs.
>
> Some discussions will only die when everything has been told by
> everybody.

You can usually tell the difference in the quality of code from those who
read the docs, and those who didn’t.

On 2024-04-16, Richard Kettlewell wrote:

> Nuno Silva <nunojsilva@invalid.invalid> writes:
>> One thing about this topic that has been popping up in several
>> outlets... as El Reg points out in [1]:
>>
>> «The agency noted that its system was installed in 1998, when
>> floppies were still in common use and, er, "computers didn't have
>> hard drives." *That doesn't exactly match reality*,»
>>
>> (emphasis mine) What happened, somebody mixed the years or tried to make
>> up an explanation and came up with a bad one? Or am I missing context?
>> IIRC hard drives were commonplace in 1998, even if not so large.
>>
>> [1] https://www.theregister.com/2024/04/09/san_francisco_muni_floppy_disks/
>
> The disks are 5.25” disks and that does put the origins of the
> technology back into an era where hard drives were at least much less
> common - but certainly very long in the tooth by the time the system was
> deployed.
>
> Other parts of the ATCS also date back to the 1970s, the disks aren’t
> even the oldest component.
>
> References:
> https://www.sfmta.com/projects/train-control-upgrade-project and
> https://sfstandard.com/2023/02/02/sfs-market-street-subway-runs-on-reagan-era-floppy-disks/
> https://www.railwayage.com/news/muni-atcs-replacement-under-way/,
> https://en.wikipedia.org/wiki/SelTrac

Ah, thanks! That makes much more sense :-)

--
Nuno Silva