==================================================================<

** Original area : "/FIDO/AUDIO"
** Original message from : Wilfred van Velzen@2:280/464
** Original message to : August Abolins
** Original date/time : 03 Jan 22, 10:50 >==================================================================<

Hi August,

On 2022-01-02 18:59:00, you wrote to me:

..I have at least 2 other XP pcs, and
two Win7 pcs as alternatives.

They will all break down in X years! ;-)

You misremember. It's X+6 for 2038. The 2038 issue may indeed
be a little niggly issue. :(

X was supposed to be randomish number, not necessarily the roman numeral for 10 ! ;-)

But indeed 2038 is a real problem for fidonet...

Bye, Wilfred.

-+- FMail-lnx64 2.1.0.18-B20170815
+ Origin: FMail development HQ (2:280/464)

===

Now.. THAT might be an interesting thing to talk about here.
What systems and processes are likely to fail amidst the 2038
deadline, and what hope is there for continued FTN operations?
Is anyone working on converting necessary programs to 64bit?

My understanding is that 2038-matter would affect 32-bit progs
and pcs. That means, my XP machines (and possibly my Win7-
32bit machines) will be non-functional especially for an app
that requires a proper date?


--- OpenXP 5.0.51
* Origin: FUTURE4FIDO = https://t.me/joinchat/SV_BQ0XcbSRoP4bt (2:221/1.58)

Hi August,

On 2022-01-03 11:50:00, you wrote to All:

You misremember. It's X+6 for 2038. The 2038 issue may indeed
be a little niggly issue. :(

...

But indeed 2038 is a real problem for fidonet...

Now.. THAT might be an interesting thing to talk about here.
What systems and processes are likely to fail amidst the 2038
deadline, and what hope is there for continued FTN operations?

Good questions! But this hasn't been investigated generally...

Is anyone working on converting necessary programs to 64bit?

FMail Linux is 64 bits. But it still might suffer the 2038 bug, because of stored data in configuration and other files. I haven't checked it too well.

My understanding is that 2038-matter would affect 32-bit progs
and pcs. That means, my XP machines (and possibly my Win7-
32bit machines) will be non-functional especially for an app
that requires a proper date?

32-bit Programs are more susceptible to this problem, but it isn't just a matter of converting them to 64 bit.

If they treat the time value as an _unsigned_ 32 bit value, they can run happily for another 68 years after 2038. But that has to be tested for software where no source code is available, and no active developpers.

Another matter is the stored file specifications. For instance do the messagebases that are used in fidonet (like Msg, Hudson, JAM, squish, etc...) use these 32 bit time values. You can't just change them, because that would mean breaking compatibility. Maybe it's a job for the FTSC to go through all the current standards, and find the problems?

Yet another matter to consider is, what is the state of fidonet in 2038? In 16 years time I think a lot of the current older generation of sysops will have left one way or another. And will there still be active developpers, who can fix the problems?

Bye, Wilfred.
--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

On 03 Jan 22 18:25:57, Wilfred Van Velzen said the following to August Abolins:

Another matter is the stored file specifications. For instance do the messagebases that are used in fidonet (like Msg, Hudson, JAM, squish, etc.. use these 32 bit time values. You can't just change them, because that woul mean breaking compatibility. Maybe it's a job for the FTSC to go through al the current standards, and find the problems?

And it doesn't matter jack-shit if they did, the FTSC can't do a thing about
it or tell people to switch software.

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

Re: Re: conversion between lossless codecs
By: August Abolins to All on Mon Jan 03 2022 11:50 am

==================================================================<

** Original area : "/FIDO/AUDIO"
** Original message from : Wilfred van Velzen@2:280/464
** Original message to : August Abolins
** Original date/time : 03 Jan 22, 10:50 >==================================================================<

Hi August,

On 2022-01-02 18:59:00, you wrote to me:

..I have at least 2 other XP pcs, and
two Win7 pcs as alternatives.

They will all break down in X years! ;-)

You misremember. It's X+6 for 2038. The 2038 issue may indeed
be a little niggly issue. :(

X was supposed to be randomish number, not necessarily the roman numeral for 10 ! ;-)

But indeed 2038 is a real problem for fidonet...

Bye, Wilfred.

-+- FMail-lnx64 2.1.0.18-B20170815
+ Origin: FMail development HQ (2:280/464)

===

Now.. THAT might be an interesting thing to talk about here.
What systems and processes are likely to fail amidst the 2038
deadline, and what hope is there for continued FTN operations?

I don't think anything in the FidoNet specs requires a 32-bit time_t value. So while a lot FidoNet-era software may break in 2038, it's not really *because* they're FidoNet-related.

Is anyone working on converting necessary programs to 64bit?

I have been converting my use of signed 32-bit time_t's to unsigned 32-bit time_t's (good until the year 2105) and non-time_t-based date/time storage (e.g. ISO-8601 as strings or separate of long ints for date and time).

My understanding is that 2038-matter would affect 32-bit progs
and pcs. That means, my XP machines (and possibly my Win7-
32bit machines) will be non-functional especially for an app
that requires a proper date?

Not exactly. There are 64-bit time_t's available in the C runtime libraries for applications built for 32-bit OSes (e.g. Windows XP). Just because the OS is 32-bit doesn't mean that the time_t value has to be 32-bit. The developer often must "opt-in" to specify the use of 64-bit time_t's in their application, but it is an option available to them.

The other option available to developers is to store unsigned 32-bit integers to represent the least significant 32-bits of 64-bit time_t values. This does limit the range of the time_t to a lowest/oldest date of Jan-1-1970/UTC, but it extends the largest/future date to some time in 2105 without impacting the number of bits/bytes required to store date/time values.
--
digital man (rob)

This Is Spinal Tap quote #1:
Nigel Tufnel: These go to eleven.
Norco, CA WX: 54.2øF, 55.0% humidity, 2 mph NE wind, 0.00 inches rain/24hrs
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)