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.

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.

>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
--
----------------------------------------------------------------------------
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 Mon, 15 Apr 2024 08:06:12 +0200, Marc Haber wrote:

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

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Mon, 15 Apr 2024 08:06:12 +0200, Marc Haber wrote:
>> 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.

--
https://www.greenend.org.uk/rjk/

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Mon, 15 Apr 2024 08:06:12 +0200, Marc Haber wrote:
>> 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.

>> ¹ we, Debian, as I am a Debian Developer
>
>Greetings, and thanks, to the mother of all distros. ;)

*bow*

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

Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
>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
--
----------------------------------------------------------------------------
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 15/04/2024 07:52, Lawrence D'Oliveiro wrote:
> On Mon, 15 Apr 2024 08:06:12 +0200, Marc Haber wrote:
>
>> 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

>
>> ¹ we, Debian, as I am a Debian Developer
>
> Greetings, and thanks, to the mother of all distros. ;)
Amen

--
“Progress is precisely that which rules and regulations did not foresee,”

– Ludwig von Mises

On 15.04.2024 um 04:36 Uhr Lawrence D'Oliveiro wrote:

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

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

--
kind regards
Marco

Send spam to 1713148610muell@cartoonies.org

On 15.04.2024 um 06:52 Uhr Lawrence D'Oliveiro wrote:

> On Mon, 15 Apr 2024 08:06:12 +0200, Marc Haber wrote:
>
> > 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.

--
kind regards
Marco

Send spam to 1713156747muell@cartoonies.org

On 15.04.2024 um 08:46 Uhr Richard Kettlewell wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> > On Mon, 15 Apr 2024 08:06:12 +0200, Marc Haber wrote:
> >> 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.

The will start caring at least when it breaks. But then they will have
to listen to a "told you so".

--
kind regards
Marco

Send spam to 1713163566muell@cartoonies.org

On 15.04.2024 um 11:34 Uhr The Natural Philosopher wrote:

> On 15/04/2024 07:52, Lawrence D'Oliveiro wrote:
> > On Mon, 15 Apr 2024 08:06:12 +0200, Marc Haber wrote:
> >
> >> 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.

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

--
kind regards
Marco

Send spam to 1713173668muell@cartoonies.org

On 15.04.2024 um 10:55 Uhr Marc Haber wrote:

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

--
kind regards
Marco

Send spam to 1713171316muell@cartoonies.org

Marco Moock <mm+usenet-es@dorfdsl.de> wrote:
>On 15.04.2024 um 10:55 Uhr Marc Haber wrote:
>> 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
--
----------------------------------------------------------------------------
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

Marc Haber <mh+usenetspam1118@zugschl.us> wrote at 07:53 this Monday (GMT):
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>On Mon, 15 Apr 2024 08:06:12 +0200, Marc Haber wrote:
>>> 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.

>>> ¹ 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.
--
user <candycane> is generated from /dev/urandom

On Mon, 15 Apr 2024 11:34:28 +0100, The Natural Philosopher wrote:

> Many pieces of industrial gear still run on DOS

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

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

On Mon, 15 Apr 2024 10:55:16 +0200, Marc Haber wrote:

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

In comp.os.linux.misc Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Mon, 15 Apr 2024 11:34:28 +0100, The Natural Philosopher wrote:
>
>> 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.

On 15.04.2024 um 22:15 Uhr Rich wrote:

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

--
kind regards
Marco

Send spam to 1713212157muell@cartoonies.org

On 2024-04-15, Rich wrote:

> In comp.os.linux.misc Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Mon, 15 Apr 2024 11:34:28 +0100, The Natural Philosopher wrote:
>>
>>> 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.

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/

--
Nuno Silva
Only following comp.os.linux.misc; this is probably drifting to a topic
that could go to alt.folklore.computers?

On 15/04/2024 23:09, Lawrence D'Oliveiro wrote:
> On Mon, 15 Apr 2024 11:34:28 +0100, The Natural Philosopher wrote:
>
>> 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.

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

--
"Socialist governments traditionally do make a financial mess. They
always run out of other people's money. It's quite a characteristic of them"

Margaret Thatcher

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

--
https://www.greenend.org.uk/rjk/

On 16/04/2024 08:08, Marco Moock wrote:
> On 15.04.2024 um 22:15 Uhr Rich wrote:
>
>> 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.

--
"It is an established fact to 97% confidence limits that left wing
conspirators see right wing conspiracies everywhere"

On 16/04/2024 09:22, Nuno Silva wrote:
> On 2024-04-15, Rich wrote:
>
>> In comp.os.linux.misc Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> On Mon, 15 Apr 2024 11:34:28 +0100, The Natural Philosopher wrote:
>>>
>>>> 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.
>
> 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/
>
(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.

--
When plunder becomes a way of life for a group of men in a society, over
the course of time they create for themselves a legal system that
authorizes it and a moral code that glorifies it.

Frédéric Bastiat

On 16/04/2024 11:48, 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
>
Indeed. Floppy disks were revolutionary in the late 70s on CP/M
computers...hard drives were extremely expensive things ... that you got
on minicomputers in the half a million and up bracket.

I suspect that at the time they might well have used something like a
PDP-11, with no hard drives.

--
It’s easier to fool people than to convince them that they have been fooled.
Mark Twain

On 2024-04-16 12:48, 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.

Er... no. 5.25 floppies coexisted with hard drives. I used such floppies
to make backups of my hard disks.

Now, what density are they using? Ie, 1.2MB or 360KB? That can push the
age back.

However, hard disks could break down if used on a vehicle, the
vibrations could destroy them. On a single purpose dedicated machine, it
could make sense to use floppies instead of hard disks.

I was pointed yesterday to the existence of emulators:

https://en.wikipedia.org/wiki/Floppy_disk_hardware_emulator

--
Cheers, Carlos.