Packages With “t64” On The Ends Of Their Names

[Lawrence D'Oliveiro]

Lately, in Debian Unstable, I have noticed package names starting to
appear with “t64” on the ends. No doubt this will percolate through to
Debian derivatives as well. I wondered what this was about, and found
this forum thread
<https://www.antixforum.com/forums/topic/t64-at-the-end-of-a-package-title/>.

This has to do with the “year-2038” problem, which should only affect
32-bit systems anyway. But it seems some people are sufficiently
concerned about this to ensure that their code will build with a
64-bit size for time_t (the POSIX type for holding the number of
seconds since 1st January 1970), even on 32-bit systems.

This is controlled at build time by setting the _TIME_BITS symbol to
the value 64. There is a file /usr/include/features-time64.h (present
if you have the libc6-dev package installed) that does the necessary
setup of other time-related API calls based on this.

On 64-bit systems (which is what most of us would be running by now),
there would be absolutely no difference in the code with this setting.
So the change in package name is I think only to maintain
compatibility with 32-bit architectures.

[Marc Haber]

Post by Lawrence D'Oliveiro
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.

Post by Lawrence D'Oliveiro
there would be absolutely no difference in the code with this setting.
So the change in package name is I think only to maintain
compatibility with 32-bit architectures.

The change in package name for 64 bit architectures is because the
build process for .deb packages is essentially the same regardless of
the architecture it happens for. Rebuilding the entire archive on
64bit systems is a largely automated process, while building
infrastructure to have different build processes, dependencies and
package names depending on architecture bit width is something that
must be done by humans.

Human time is more valueable than machine time, hence the way we¹ are
doing this transition.

Greetings
Marc

¹ we, Debian, as I am a Debian Developer

[Lawrence D'Oliveiro]

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.

And most of those systems will never have their OSes updated. Most vendors
of embedded systems seem to develop their products with a “ship and
forget” mentality.

¹ we, Debian, as I am a Debian Developer

Greetings, and thanks, to the mother of all distros. ;)

[Richard Kettlewell]

Post by Lawrence D'Oliveiro

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.

And most of those systems will never have their OSes updated. Most
vendors of embedded systems seem to develop their products with a
“ship and forget” mentality.

So it depends if the vendors (and users, who are often negligent about
upgrades) care about them still working properly from 2038 onwards.
Still, there’ll be new devices, with newer firmware.

[Marc Haber]

Post by Lawrence D'Oliveiro

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.

And most of those systems will never have their OSes updated. Most vendors
of embedded systems seem to develop their products with a “ship and
forget” mentality.

That makes it even more important to think NOW about year 2038.

Post by Lawrence D'Oliveiro

¹ we, Debian, as I am a Debian Developer

Greetings, and thanks, to the mother of all distros. ;)

*bow*

Greetings
Marc

[candycanearter07]

Post by Marc Haber

Post by Lawrence D'Oliveiro

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.

And most of those systems will never have their OSes updated. Most vendors
of embedded systems seem to develop their products with a “ship and
forget” mentality.

That makes it even more important to think NOW about year 2038.

Exactly, we don't want a repeat of Y2K.

Post by Marc Haber

Post by Lawrence D'Oliveiro

¹ we, Debian, as I am a Debian Developer

Greetings, and thanks, to the mother of all distros. ;)

*bow*
Greetings
Marc

Thank you for your work.

[The Natural Philosopher]

Post by Lawrence D'Oliveiro

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.

And most of those systems will never have their OSes updated. Most vendors
of embedded systems seem to develop their products with a “ship and
forget” mentality.

Many pieces of industrial gear still run on DOS

you dont upgrade kit that works, for functionality, only to fix problems

Post by Lawrence D'Oliveiro

¹ we, Debian, as I am a Debian Developer

Greetings, and thanks, to the mother of all distros. ;)

Amen

[Marco Moock]

Post by The Natural Philosopher

Post by Lawrence D'Oliveiro

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.

And most of those systems will never have their OSes updated. Most
vendors of embedded systems seem to develop their products with a
“ship and forget” mentality.

Many pieces of industrial gear still run on DOS

I know that and I know that they have beads of sweat on their forehead
because they know when it fails it is hard to fix because hardware
availability is tricky and who still knows how to operate systems from
30 years ago.

Post by The Natural Philosopher
you dont upgrade kit that works, for functionality, only to fix problems

If the time doesn't work properly, many things are broken, especially
when those devices are connected to a network.

[Lawrence D'Oliveiro]

Post by The Natural Philosopher
Many pieces of industrial gear still run on DOS

Would you entrust mission-critical business functions to obsolete,
unsupported software?

Post by The Natural Philosopher
you dont upgrade kit that works, for functionality, only to fix problems

The trouble with “if it ain’t broke, don’t fix it” is when you wait until
it *is* broke, and only then discover that you have no idea how to fix it.

[Rich]

Post by Lawrence D'Oliveiro

Post by The Natural Philosopher
Many pieces of industrial gear still run on DOS

Would you entrust mission-critical business functions to obsolete,
unsupported software?

TNP might not, but that does not change the fact that TNP's statement
is all too true. There is much industrial gear that runs on DOS (or
other, now extinct, OS'es).

A recent (related) example that made the rounds a week or two ago:

SFMTA's train system running on floppy disks; city fears 'catastrophic failure' before upgrade

https://abc7news.com/san-francisco-train-system-has-been-running-on-floppy-disks-but-city-fears-catastrophic-failure-before-upgrade/14624828/

Still relying on floppy disks 26 years later.

[Marco Moock]

Post by Rich
SFMTA's train system running on floppy disks; city fears
'catastrophic failure' before upgrade

Exactly that is the result of "never change a running system". Spare
parts are often not available and if it breaks, it is hard to fix it.

[The Natural Philosopher]

Post by Marco Moock

Post by Rich
SFMTA's train system running on floppy disks; city fears
'catastrophic failure' before upgrade

Exactly that is the result of "never change a running system". Spare
parts are often not available and if it breaks, it is hard to fix it.

However, in the end its pure cost benefit analysis. You don't buy a car
until the horse that pulls your cart, dies.

Chances are that if you had changed a running system, you would break it
anyway...I had a furious phone call from a customer whose ISDN equipped
router no longer connected to the internet. He swore blind that he
hadn't changed its configuration. But, someone had installed new
firmware in the ISDN PABX hadnt they? I got a full apology, and the ISDN
firmware was downgraded to the version that worked.

Business is about minimising lifetime costs whilst still giving
acceptable availability on systems. Suppliers like to sell you support
contracts that include upgrades you actually don't need. If it 'just
works' then why bother?

A late friend used to build chemical analysis software. He built it in
turbo pascal on DOS. It interfaced with a board he designed that drove
the actual hardware which was highly specialised.

That code is still running keeping the environment safe .


I recall a 21 year old IBM360 sitting in a factory still running
identical RPG and COBOL that its application was written in 20 years
ago, It ran fine, but no one was prepared to support the hardware, so
onto an IBM AIX machine it was going to be ported.


You simply do not change just because something newer is available, in
the world of industrial and commercial computing. That's only for pointy
headed PFYs who are in love with technology, not running a business.

[Nuno Silva]

Post by Rich

Post by Lawrence D'Oliveiro

Post by The Natural Philosopher
Many pieces of industrial gear still run on DOS

Would you entrust mission-critical business functions to obsolete,
unsupported software?

TNP might not, but that does not change the fact that TNP's statement
is all too true. There is much industrial gear that runs on DOS (or
other, now extinct, OS'es).
SFMTA's train system running on floppy disks; city fears 'catastrophic failure' before upgrade
https://abc7news.com/san-francisco-train-system-has-been-running-on-floppy-disks-but-city-fears-catastrophic-failure-before-upgrade/14624828/
Still relying on floppy disks 26 years later.

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/

[Richard Kettlewell]

Post by Nuno Silva
One thing about this topic that has been popping up in several
«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

[The Natural Philosopher]

Post by Nuno Silva

Post by Rich

Post by Lawrence D'Oliveiro

Post by The Natural Philosopher
Many pieces of industrial gear still run on DOS

Would you entrust mission-critical business functions to obsolete,
unsupported software?

TNP might not, but that does not change the fact that TNP's statement
is all too true. There is much industrial gear that runs on DOS (or
other, now extinct, OS'es).
SFMTA's train system running on floppy disks; city fears 'catastrophic failure' before upgrade
https://abc7news.com/san-francisco-train-system-has-been-running-on-floppy-disks-but-city-fears-catastrophic-failure-before-upgrade/14624828/
Still relying on floppy disks 26 years later.

One thing about this topic that has been popping up in several
«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/

(from that article...
..."Bear in mind that the US nuclear arsenal ran off eight-inch floppies
until 2019. It's the way stuff was done when these systems were built
last century".)

Who knows, Chinese whispers between the person who made the decision who
may be dead, and the press release written by someone whose skills are
in writing, not IT.

[The Natural Philosopher]

Post by Lawrence D'Oliveiro

Post by The Natural Philosopher
Many pieces of industrial gear still run on DOS

Would you entrust mission-critical business functions to obsolete,
unsupported software?

People trust a lot of things to WIN XP

Freedos is supported

But you completely missed the point. If a piece of hardware and software
works as intended, it doesn't matter how 'obsolete or unsupported' it
is. Viz nuclear power stations running on PDP11s and so on.

It is clear you do not actually understand DOS at all: There is nothing
TO support. It is simply a program loader. Everything else is the user
application, as DOS allows Assembly language coded bare metal
programming if you want it to.

Post by Lawrence D'Oliveiro

Post by The Natural Philosopher
you dont upgrade kit that works, for functionality, only to fix problems

The trouble with “if it ain’t broke, don’t fix it” is when you wait until
it *is* broke, and only then discover that you have no idea how to fix it.

Another arm waver from the unreal world of fervent imaginings.

Read what I said. If it has problems, you fix them

If you are a manufacturer of an embedded system either you release bug
fixes and allow people to flash or re program ROM, or you simply sell
them a later version.

But most embedded code is so damned simple it doesn't even need an
operating system. But even it it is running some sort of linux or BSD
unix, chances are it is cheap enough to throw away in ten years time.

[Carlos E.R.]

Post by The Natural Philosopher

Post by Lawrence D'Oliveiro

Post by The Natural Philosopher
Many pieces of industrial gear still run on DOS

Would you entrust mission-critical business functions to obsolete,
unsupported software?

People trust a lot of things to WIN XP
Freedos is supported
But you completely missed the point. If a piece of hardware and software
works as intended, it doesn't matter how 'obsolete or unsupported' it
is. Viz nuclear power stations running on PDP11s and so on.
It is clear you do not actually understand DOS at all: There is nothing
TO support. It is simply a program loader. Everything else is the user
application, as DOS allows Assembly language coded bare metal
programming if you want it to.

And there is no network access to protect from. The thing is as secure
as it was when built. You only have to protect from physical access.

The real problem is hardware breakdown. There are no spares.

Machines installed 1998 could have been designed 5 years before. Using
an actual 8086 in an expensive industrial PC was possible, a Pentium
would be normal.

[The Natural Philosopher]

Post by Carlos E.R.

Post by The Natural Philosopher

Post by Lawrence D'Oliveiro

Post by The Natural Philosopher
Many pieces of industrial gear still run on DOS

Would you entrust mission-critical business functions to obsolete,
unsupported software?

People trust a lot of things to WIN XP
Freedos is supported
But you completely missed the point. If a piece of hardware and
software works as intended, it doesn't matter how 'obsolete or
unsupported' it is. Viz nuclear power stations running on PDP11s and
so on.
It is clear you do not actually understand DOS at all: There is
nothing TO support. It is simply a program loader. Everything else is
the user application, as DOS allows Assembly language coded bare metal
programming if you want it to.

And there is no network access to protect from. The thing is as secure
as it was when built. You only have to protect from physical access.
The real problem is hardware breakdown. There are no spares.
Machines installed 1998 could have been designed 5 years before. Using
an actual 8086 in an expensive industrial PC was possible, a Pentium
would be normal.

Actually today one would probably plump for a Pi or ARM chip running
stripped down linux, and do the I/O other than via the old XT style
plugin boards I2C or USB, or very local networking. Or simply hang some
logic round the GPIO pins to make the thing look like an 8088 I/O bus 16
GPIO pins plus two more for read/write would emulate an 256 x 8 bit
wide IO bus.

[Carlos E.R.]

Post by Lawrence D'Oliveiro

Post by The Natural Philosopher
Many pieces of industrial gear still run on DOS

Would you entrust mission-critical business functions to obsolete,
unsupported software?

On industrial environment, which is not a business environment, yes, I
would.

Post by Lawrence D'Oliveiro

Post by The Natural Philosopher
you dont upgrade kit that works, for functionality, only to fix problems

The trouble with “if it ain’t broke, don’t fix it” is when you wait until
it *is* broke, and only then discover that you have no idea how to fix it.

You don't replace an industrial setup worth millions just because the
computer is "obsolete". The computer is just part of it. An industrial
setup is intended to keep working decades.

[The Natural Philosopher]

Post by Carlos E.R.

Post by Lawrence D'Oliveiro

Post by The Natural Philosopher
Many pieces of industrial gear still run on DOS

Would you entrust mission-critical business functions to obsolete,
unsupported software?

On industrial environment, which is not a business environment, yes, I
would.

Post by Lawrence D'Oliveiro

Post by The Natural Philosopher
you dont upgrade kit that works, for functionality, only to fix problems

The trouble with “if it ain’t broke, don’t fix it” is when you wait until
it *is* broke, and only then discover that you have no idea how to fix it.

You don't replace an industrial setup worth millions just because the
computer is "obsolete". The computer is just part of it. An industrial
setup is intended to keep working decades.

Back in the 80s worked on a terrible project - software to go in
underwater fibre repeaters.

Everything was a muddle, but one of the permies remarked 'at least we
are allowed to use silicon, now'

They had to stick with GERMANIUM until silicon devices had been around
25 years - the guaranteed product life span.

There are still more than a few PDPs and vaxen doing mission critical
stuff out there.

As the saying goes, 'A VAX is like an erect penis, It will stay up as
long as you don't fuck with it'

[Carlos E.R.]

Post by The Natural Philosopher

Post by Carlos E.R.

Post by Lawrence D'Oliveiro

Post by The Natural Philosopher
Many pieces of industrial gear still run on DOS

Would you entrust mission-critical business functions to obsolete,
unsupported software?

On industrial environment, which is not a business environment, yes, I
would.

Post by Lawrence D'Oliveiro

Post by The Natural Philosopher
you dont upgrade kit that works, for functionality, only to fix problems

The trouble with “if it ain’t broke, don’t fix it” is when you wait until
it *is* broke, and only then discover that you have no idea how to fix it.

You don't replace an industrial setup worth millions just because the
computer is "obsolete". The computer is just part of it. An industrial
setup is intended to keep working decades.

Back in the 80s worked on a terrible project - software to go in
underwater fibre repeaters.
Everything was a muddle, but one of the permies remarked 'at least we
are allowed to use silicon, now'
They had to stick with GERMANIUM until silicon devices had been around
25 years -  the guaranteed product life span.

Heh :-)

Post by The Natural Philosopher
There are still more than a few PDPs and vaxen doing mission critical
stuff out there.
As the saying goes, 'A VAX is like an erect penis, It will stay up as
long as you don't fuck with it'

:-)

[Lawrence D'Oliveiro]

Post by Carlos E.R.

Post by Lawrence D'Oliveiro
The trouble with “if it ain’t broke, don’t fix it” is when you wait
until it *is* broke, and only then discover that you have no idea how
to fix it.

You don't replace an industrial setup worth millions just because the
computer is "obsolete".

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.

[Carlos E.R.]

Post by Lawrence D'Oliveiro

Post by Carlos E.R.

Post by Lawrence D'Oliveiro
The trouble with “if it ain’t broke, don’t fix it” is when you wait
until it *is* broke, and only then discover that you have no idea how
to fix it.

You don't replace an industrial setup worth millions just because the
computer is "obsolete".

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.

Which probably they have. They get what they pay for, subject to terms
and conditions.

[Lawrence D'Oliveiro]

Post by Carlos E.R.

Post by Lawrence D'Oliveiro

Post by Carlos E.R.

Post by Lawrence D'Oliveiro
The trouble with “if it ain’t broke, don’t fix it” is when you wait
until it *is* broke, and only then discover that you have no idea how
to fix it.

You don't replace an industrial setup worth millions just because the
computer is "obsolete".

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.

Which probably they have.

Then the computer is not “obsolete”, if you can still get support for it.

[The Natural Philosopher]

Post by Lawrence D'Oliveiro

Post by Carlos E.R.

Post by Lawrence D'Oliveiro

Post by Carlos E.R.

Post by Lawrence D'Oliveiro
The trouble with “if it ain’t broke, don’t fix it” is when you wait
until it *is* broke, and only then discover that you have no idea how
to fix it.

You don't replace an industrial setup worth millions just because the
computer is "obsolete".

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.

Which probably they have.

Then the computer is not “obsolete”, if you can still get support for it.

You can still get spare parts for 1950s cars. That doesn't mean they are
flawless or not obsolete.

Let's rephrase it. 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.

To replace it, a large software company quoted you $5m.

What do you do?

[Rich]

Post by The Natural Philosopher

Post by Lawrence D'Oliveiro

Post by Carlos E.R.

Post by Lawrence D'Oliveiro

Post by Carlos E.R.

Post by Lawrence D'Oliveiro
The trouble with “if it ain’t broke, don’t fix it” is when you wait
until it *is* broke, and only then discover that you have no idea how
to fix it.

You don't replace an industrial setup worth millions just because the
computer is "obsolete".

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.

Which probably they have.

Then the computer is not “obsolete”, if you can still get support for it.

You can still get spare parts for 1950s cars. That doesn't mean they are
flawless or not obsolete.
Let's rephrase it. 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.
To replace it, a large software company quoted you $5m.
What do you do?

You should make the senario closer to actual reality.

To replace it, the low bid software company has quoted $5m and two
years work to replace it, but you know from past experience with the
"low bid" winners of all prior projects that this actually will mean
~2x the quoted time and ~2x the quoted budget, so you are really
looking at a 4-5 year timeframe and a $5-6m budget overrunn for a total
of $10-11m to replace.

And your yearly budget line item allocated to system upgrades is $1m
(so we are talking a minimum of five years of your budget line item up
to eleven years of your budget line item).

And your choices are "accept" and "reject" (as you are far enough away
from the procurement process inside the bureaucracy that there is no
"negioate" available to you in any way).

[Carlos E.R.]

Post by The Natural Philosopher

Post by Lawrence D'Oliveiro

Post by Carlos E.R.

Post by Lawrence D'Oliveiro

Post by Carlos E.R.

Post by Lawrence D'Oliveiro
The trouble with “if it ain’t broke, don’t fix it” is when you wait
until it *is* broke, and only then discover that you have no idea how
to fix it.

You don't replace an industrial setup worth millions just because the
computer is "obsolete".

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.

Which probably they have.

Then the computer is not “obsolete”, if you can still get support for it.

You can still get spare parts for 1950s cars. That doesn't mean they are
flawless or not obsolete.
Let's rephrase it. 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.
To replace it, a large software company quoted you $5m.
What do you do?

Even if they used IBM PCs, the company still exists, they have the
schematics, and there are still people alive from that time. You buy
trains that are computer controlled. The trains are expected to run for
well over a decade, they are very expensive. So are the computers.

Getting spares for the trains is easy. Getting spares for the computers,
no. Obviously, replacing the entire trains is ridiculous.

Instead of trains, it can be any industrial thing. A factory making peas
preserves (a computer stamps the date, for instance). Anything that uses
machines controlled by computers. You can not replace the computers
every five years. The office may, the machine shop can't. Not profitable.

[Lawrence D'Oliveiro]

Post by The Natural Philosopher
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.

[The Natural Philosopher]

Post by Lawrence D'Oliveiro

Post by The Natural Philosopher
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.

[Lawrence D'Oliveiro]

Post by The Natural Philosopher
Software costs way more than hardware.

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

[The Natural Philosopher]

Post by Lawrence D'Oliveiro

Post by The Natural Philosopher
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.

[Lawrence D'Oliveiro]

Post by Lawrence D'Oliveiro

Post by The Natural Philosopher
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?

[Rich]

Post by Lawrence D'Oliveiro

Post by The Natural Philosopher
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.

[D]

Post by The Natural Philosopher

Post by Lawrence D'Oliveiro

Post by The Natural Philosopher
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.

[Rich]

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.

[D]

Post by Rich

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

[Lawrence D'Oliveiro]

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.

[The Natural Philosopher]

Post by Lawrence D'Oliveiro

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

[Lawrence D'Oliveiro]

Post by The Natural Philosopher
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.

[Marco Moock]

Post by Lawrence D'Oliveiro

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.

And most of those systems will never have their OSes updated. Most
vendors of embedded systems seem to develop their products with a
“ship and forget” mentality.

That is their problem. A fix is being available - if vendors refuse to
use it, developers can't change that.

[Marc Haber]

Post by Marc Haber
The change in package name for 64 bit architectures is because the
build process for .deb packages is essentially the same regardless of
the architecture it happens for. Rebuilding the entire archive on
64bit systems is a largely automated process, while building
infrastructure to have different build processes, dependencies and
package names depending on architecture bit width is something that
must be done by humans.

I forgot to mention that the changed package name (and the changed
symbol names inside the compiled libraries) allow the 32bit time_t and
the 64bit time_t version of the library to be co-installable, which
allows the _applications_ to transition one at a time in "their own
sweet little time". Once no package uses a certain 32bit time_t
library any more, the corresponding package can¹ be uninstalled,
eventually only leaving the 64bit time_t library around.

I don't know whether we² are going to transition back to the
unsuffixed names of packages and symbols once all libraries are 64bit
time_t. Personally, I'd consider that a waste.

Greetings
Marc

¹ and will, in apt's default configuration
² Debian

[Marco Moock]

Post by Marc Haber
I don't know whether we² are going to transition back to the
unsuffixed names of packages and symbols once all libraries are 64bit
time_t. Personally, I'd consider that a waste.

I think this will break many 3rd party package dependencies. It already
did with Seafile.

[Marc Haber]

Post by Marco Moock

Post by Marc Haber
I don't know whether we² are going to transition back to the
unsuffixed names of packages and symbols once all libraries are 64bit
time_t. Personally, I'd consider that a waste.

I think this will break many 3rd party package dependencies. It already
did with Seafile.

That's why Debian tesiting is public, so that 3rd party package
vendors can adapt¹ before we² release.

Grüße
Marc

¹ and identify their 32bit time_t bugs
² Debian

[Lawrence D'Oliveiro]

I don't know whether we² are going to transition back to the unsuffixed
names of packages and symbols once all libraries are 64bit time_t.
Personally, I'd consider that a waste.

You think so? I think it makes sense to get rid of the superfluous suffix,
once it has served its purpose.

[Marc Haber]

Post by Lawrence D'Oliveiro

I don't know whether we² are going to transition back to the unsuffixed
names of packages and symbols once all libraries are 64bit time_t.
Personally, I'd consider that a waste.

You think so? I think it makes sense to get rid of the superfluous suffix,
once it has served its purpose.

That would practically mean touching hundreds if not thousands of
packages, and another transition of this epic size.

[Woozy Song]

Post by Marc Haber

Post by Lawrence D'Oliveiro
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?

[candycanearter07]

Post by Woozy Song

Post by Marc Haber

Post by Lawrence D'Oliveiro
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

[The Natural Philosopher]

Post by candycanearter07

Post by Woozy Song

Post by Marc Haber

Post by Lawrence D'Oliveiro
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

Post by candycanearter07
dl6

[David W. Hodgins]

Post by The Natural Philosopher

Post by candycanearter07

Post by Woozy Song

Post by Marc Haber

Post by Lawrence D'Oliveiro
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

[Charlie Gibbs]

Post by David W. Hodgins
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.

Post by David W. Hodgins
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.

[Lawrence D'Oliveiro]

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.

[Marc Haber]

Post by Lawrence D'Oliveiro

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]

Post by The Natural Philosopher

Post by candycanearter07

Post by Woozy Song

Post by Marc Haber

Post by Lawrence D'Oliveiro
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

[Lawrence D'Oliveiro]

Post by Marc Haber
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.

[Marc Haber]

Post by Lawrence D'Oliveiro

Post by Marc Haber
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

[Lawrence D'Oliveiro]

Post by Marc Haber

Post by Lawrence D'Oliveiro

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.

[Marc Haber]

Post by Lawrence D'Oliveiro

Post by Marc Haber

Post by Lawrence D'Oliveiro

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.

[Lawrence D'Oliveiro]

Post by Marc Haber

Post by Lawrence D'Oliveiro
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.

[Marco Moock]

Post by Lawrence D'Oliveiro
Lately, in Debian Unstable, I have noticed package names starting to
appear with “t64” on the ends. No doubt this will percolate through to
Debian derivatives as well.

If they use packages from Testing or Sid (both unstable version still
in development), this will be the case.

Post by Lawrence D'Oliveiro
I wondered what this was about, and found
this forum thread
<https://www.antixforum.com/forums/topic/t64-at-the-end-of-a-package-title/>.
This has to do with the “year-2038” problem, which should only affect
32-bit systems anyway. But it seems some people are sufficiently
concerned about this to ensure that their code will build with a
64-bit size for time_t (the POSIX type for holding the number of
seconds since 1st January 1970), even on 32-bit systems.

Which is important because if it fails, it should be noticed before it
is in a productive system.