xkcd: Y2K and 2038
https://xkcd.com/2697/

It shouldn't cost more than a trillion dollars or two to investigate this.

Explained at:
https://www.explainxkcd.com/wiki/index.php/2697:_Y2K_and_2038

Lynn

Lynn McGuire <lynnmcguire5@gmail.com> wrote in
news:tkmbd3$uc0u$2@dont-email.me:

> xkcd: Y2K and 2038
> https://xkcd.com/2697/
>
> It shouldn't cost more than a trillion dollars or two to
> investigate this.

I'll start doing so as soon as the check clears.

Or it could end up being as big a nothingburger as y2k was, because
the people who run such systems aren't idiots.

--
Terry Austin

"Terry Austin: like the polio vaccine, only with more asshole."
-- David Bilek

Jesus forgives sinners, not criminals.

On 11/11/2022 5:39 PM, Jibini Kula Tumbili Kujisalimisha wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> wrote in
> news:tkmbd3$uc0u$2@dont-email.me:
>
>> xkcd: Y2K and 2038
>> https://xkcd.com/2697/
>>
>> It shouldn't cost more than a trillion dollars or two to
>> investigate this.
>
> I'll start doing so as soon as the check clears.
>
> Or it could end up being as big a nothingburger as y2k was, because
> the people who run such systems aren't idiots.

A simple recompile with modern C compiler takes you from 2038 to 2106 if
you are using time_t. Maybe.
https://en.wikipedia.org/wiki/Year_2038_problem

Lynn

Jibini Kula Tumbili Kujisalimisha <taustinca@gmail.com> writes:
>Lynn McGuire <lynnmcguire5@gmail.com> wrote in
>news:tkmbd3$uc0u$2@dont-email.me:
>
>> xkcd: Y2K and 2038
>> https://xkcd.com/2697/
>>
>> It shouldn't cost more than a trillion dollars or two to
>> investigate this.
>
>I'll start doing so as soon as the check clears.
>
>Or it could end up being as big a nothingburger as y2k was, because
>the people who run such systems aren't idiots.

We (Burroughs) started preparing for 2000 in 1987. None of our customers
were affected by the rollover (and most customer software on those mainframes
used two-digit year fields in 1987).

And, on the vast majority of unix/linux servers/desktops currently running,

sizeof(time_t)=8 (64 bits)

Which pushes the "2038" date out to December 4th, in the year 292,277,026,596.

For the most part, a nothingburger. However, there are likely lots of
small embedded 32-bit processors in devices like routers which may exhibit
issues, if they're still running 16 years from now.

scott@slp53.sl.home (Scott Lurndal) wrote in
news:l9PbL.74464$1449.32517@fx14.iad:

> For the most part, a nothingburger. However, there are likely
> lots of small embedded 32-bit processors in devices like routers
> which may exhibit issues, if they're still running 16 years from
> now.
>
You sound just like the doom criers ("Give me money or you'll
DIE!!!") in the run up to y2k.

How many appliances with embedded processors running today do you
actually believe will still be functional in another 16 years?

https://www.wired.com/2000/01/y2k-alarmist-wha-happened/

--
Terry Austin

Proof that Alan Baker is a liar and a fool, and even stupider than
Lynn:
https://www.cbp.gov/newsroom/stats/sw-border-migration

"Terry Austin: like the polio vaccine, only with more asshole."
-- David Bilek

Jesus forgives sinners, not criminals.

Ninapenda Jibini <taustinca@gmail.com> writes:
>scott@slp53.sl.home (Scott Lurndal) wrote in
>news:l9PbL.74464$1449.32517@fx14.iad:
>
>> For the most part, a nothingburger. However, there are likely
>> lots of small embedded 32-bit processors in devices like routers
>> which may exhibit issues, if they're still running 16 years from
>> now.
>>
>You sound just like the doom criers ("Give me money or you'll
>DIE!!!") in the run up to y2k.

I said "if they're still running 16 years from now", which is
quite unlikely. However, cheap-ass manufacturers may continue
to use the same software in newer devices, sadly.

On Fri, 11 Nov 2022 14:30:25 -0600, Lynn McGuire
<lynnmcguire5@gmail.com> wrote:

>xkcd: Y2K and 2038
> https://xkcd.com/2697/
>
>It shouldn't cost more than a trillion dollars or two to investigate this.
>
>Explained at:
> https://www.explainxkcd.com/wiki/index.php/2697:_Y2K_and_2038

So, two questions occur:

1. This appears to be a Unix problem. Apart of Unix and Linux and
friends, will anyone /else/ be affected?

2. Why go to 33 bits? If the problem is that 32 is too few, why not
just jump to 64 and save the future some problems? Is doing things in
the clearly least optimal way (you are going to end up with 40 bits
anyway, since they come in 8-bit groups called "bytes") a Unix/Linux
tradition? Do Real Programmers always to things the Most Difficult Way
Possible?

--
"In this connexion, unquestionably the most significant
development was the disintegration, under Christian
influence, of classical conceptions of the family and
of family right."

scott@slp53.sl.home (Scott Lurndal) on Sat, 12 Nov 2022 16:57:44 GMT
typed in rec.arts.sf.written the following:
>Ninapenda Jibini <taustinca@gmail.com> writes:
>>scott@slp53.sl.home (Scott Lurndal) wrote in
>>news:l9PbL.74464$1449.32517@fx14.iad:
>>
>>> For the most part, a nothingburger. However, there are likely
>>> lots of small embedded 32-bit processors in devices like routers
>>> which may exhibit issues, if they're still running 16 years from
>>> now.
>>>
>>You sound just like the doom criers ("Give me money or you'll
>>DIE!!!") in the run up to y2k.
>
>I said "if they're still running 16 years from now", which is
>quite unlikely. However, cheap-ass manufacturers may continue
>to use the same software in newer devices, sadly.

It is possible. As the cliche was "back in my day" - most of the
current batch of programmers have no idea that there are COBOL
programs still running which were compiled before they were born.

The question is, how many people / organizations have a system
which has been running, is running, will be running, with little or no
reason to replace it with a New And Improved Hardware?
--
pyotr filipivich
This Week's Panel: Us & Them - Eliminating Them.
Next Month's Panel: Having eliminated the old Them(tm)
Selecting who insufficiently Woke(tm) as to serve as the new Them(tm)

Y2K was a "nothingburger" because of all the work done to stop it from
being a triple-decker shit sandwitch. If everyone had treated it like no big
deal, it would have been a very big deal.

Dave Van Domelen, really tired of the attitude people have that if a
problem is fixed, then it was never a problem in the first place.

pyotr filipivich <phamp@mindspring.com> writes:
>scott@slp53.sl.home (Scott Lurndal) on Sat, 12 Nov 2022 16:57:44 GMT
>typed in rec.arts.sf.written the following:
>>Ninapenda Jibini <taustinca@gmail.com> writes:
>>>scott@slp53.sl.home (Scott Lurndal) wrote in
>>>news:l9PbL.74464$1449.32517@fx14.iad:
>>>
>>>> For the most part, a nothingburger. However, there are likely
>>>> lots of small embedded 32-bit processors in devices like routers
>>>> which may exhibit issues, if they're still running 16 years from
>>>> now.
>>>>
>>>You sound just like the doom criers ("Give me money or you'll
>>>DIE!!!") in the run up to y2k.
>>
>>I said "if they're still running 16 years from now", which is
>>quite unlikely. However, cheap-ass manufacturers may continue
>>to use the same software in newer devices, sadly.
>
> It is possible. As the cliche was "back in my day" - most of the
>current batch of programmers have no idea that there are COBOL
>programs still running which were compiled before they were born.
>
> The question is, how many people / organizations have a system
>which has been running, is running, will be running, with little or no
>reason to replace it with a New And Improved Hardware?

Most of those workloads are still running on legacy iron, and will
for the forseeable future (IBM, Unisys). Modern workloads based on
current distributed technologies (the world-wide web, for instance)
are either already 64-bit clean. The time_t issue is uniquely an
Unix issue and those, aside from the low-end consumer grade hardware mentioned
above, are largely already 64-bit clean.

The competence of programmers varies, and it is likely that there is
a fair amount of software that treats time_t as interchangable with
the C/C++ 'int' type, which is prima facia broken, but works in 32-bit
environments (and may continue to work post 2038 depending on the
context of the usage).

In article <hekvmhh5jjbjnmefu2sjoecpkqla6pmmg3@4ax.com>,
Paul S Person <psperson@old.netcom.invalid> wrote:
>On Fri, 11 Nov 2022 14:30:25 -0600, Lynn McGuire
><lynnmcguire5@gmail.com> wrote:
>
>>xkcd: Y2K and 2038
>> https://xkcd.com/2697/
>>
>>It shouldn't cost more than a trillion dollars or two to investigate this.
>>
>>Explained at:
>> https://www.explainxkcd.com/wiki/index.php/2697:_Y2K_and_2038
>
>So, two questions occur:
>
>1. This appears to be a Unix problem. Apart of Unix and Linux and
>friends, will anyone /else/ be affected?
>
>2. Why go to 33 bits? If the problem is that 32 is too few, why not
>just jump to 64 and save the future some problems? Is doing things in
>the clearly least optimal way (you are going to end up with 40 bits
>anyway, since they come in 8-bit groups called "bytes") a Unix/Linux
>tradition? Do Real Programmers always to things the Most Difficult Way
>Possible?
>

Most systems have already gone to 64 bits for time_t. The only case
I can think of for going to an unsigned 32 bit int would be if you
are targeting legacy embedded hardware of some sort and 64-bit work
is significantly slower (and/or your legacy compiler doesn't even
support 64-bit ints).
--
columbiaclosings.com
What's not in Columbia anymore..

On 11/12/2022 9:42 AM, Scott Lurndal wrote:
> Jibini Kula Tumbili Kujisalimisha <taustinca@gmail.com> writes:
>> Lynn McGuire <lynnmcguire5@gmail.com> wrote in
>> news:tkmbd3$uc0u$2@dont-email.me:
>>
>>> xkcd: Y2K and 2038
>>> https://xkcd.com/2697/
>>>
>>> It shouldn't cost more than a trillion dollars or two to
>>> investigate this.
>>
>> I'll start doing so as soon as the check clears.
>>
>> Or it could end up being as big a nothingburger as y2k was, because
>> the people who run such systems aren't idiots.
>
> We (Burroughs) started preparing for 2000 in 1987. None of our customers
> were affected by the rollover (and most customer software on those mainframes
> used two-digit year fields in 1987).
>
> And, on the vast majority of unix/linux servers/desktops currently running,
>
> sizeof(time_t)=8 (64 bits)
>
> Which pushes the "2038" date out to December 4th, in the year 292,277,026,596.
>
> For the most part, a nothingburger. However, there are likely lots of
> small embedded 32-bit processors in devices like routers which may exhibit
> issues, if they're still running 16 years from now.

The operating systems arefixed but the customer software is not. The
software at minimum needs a recompile. But the software needs a going
through to see if it is just stuffing the time and date information into
a 32 bit signed integer.

Lynn

scott@slp53.sl.home (Scott Lurndal) wrote in news:cgQbL.91949
$2Rs3.58510@fx12.iad:

> Ninapenda Jibini <taustinca@gmail.com> writes:
>>scott@slp53.sl.home (Scott Lurndal) wrote in
>>news:l9PbL.74464$1449.32517@fx14.iad:
>>
>>> For the most part, a nothingburger. However, there are likely
>>> lots of small embedded 32-bit processors in devices like routers
>>> which may exhibit issues, if they're still running 16 years from
>>> now.
>>>
>>You sound just like the doom criers ("Give me money or you'll
>>DIE!!!") in the run up to y2k.
>
> I said "if they're still running 16 years from now", which is
> quite unlikely.

Unlikely enough to not be worth considering. Or mentioning.

> However, cheap-ass manufacturers may continue
> to use the same software in newer devices, sadly.
>
*Just* like Gary North.

--
Terry Austin

Proof that Alan Baker is a liar and a fool, and even stupider than
Lynn:
https://www.cbp.gov/newsroom/stats/sw-border-migration

"Terry Austin: like the polio vaccine, only with more asshole."
-- David Bilek

Jesus forgives sinners, not criminals.

On 11/12/2022 11:07 AM, Paul S Person wrote:
> On Fri, 11 Nov 2022 14:30:25 -0600, Lynn McGuire
> <lynnmcguire5@gmail.com> wrote:
>
>> xkcd: Y2K and 2038
>> https://xkcd.com/2697/
>>
>> It shouldn't cost more than a trillion dollars or two to investigate this.
>>
>> Explained at:
>> https://www.explainxkcd.com/wiki/index.php/2697:_Y2K_and_2038
>
> So, two questions occur:
>
> 1. This appears to be a Unix problem. Apart of Unix and Linux and
> friends, will anyone /else/ be affected?
>
> 2. Why go to 33 bits? If the problem is that 32 is too few, why not
> just jump to 64 and save the future some problems? Is doing things in
> the clearly least optimal way (you are going to end up with 40 bits
> anyway, since they come in 8-bit groups called "bytes") a Unix/Linux
> tradition? Do Real Programmers always to things the Most Difficult Way
> Possible?

1. Anyone who stuffs a time value into a 32 bit signed integer is going
to have problems at some point. Lots of mainframes did that over the years.

2. The 33 bits is joke and is difficult to implement. Randall Munroe
(the xkcd dude) is a physics dude with an incredibly popular stick
figure comic strip that runs three times a week.
https://xkcd.com/about/

I started off programming on the Univac 1108, a 36 bit machine. When we
ported to the IBM 370 in 1977?, a 32 bit machine, we had tremendous
problems with precision in our floating point. Turns out after all
these years, 32 bit still sucks.

Lynn

dvandom@eyrie.org (Dave Van Domelen) wrote in
news:tkongi$4gc$1@hope.eyrie.org:

> Y2K was a "nothingburger" because of all the work done to
> stop it from
> being a triple-decker shit sandwitch. If everyone had treated
> it like no big deal, it would have been a very big deal.

Indeed. It's almost like critical computer systems that companies and
people depend on for Very Important Things have people whose job is
to keep an eye on things, keep things up to date, and upgrade as
needed.
>
> Dave Van Domelen, really tired of the attitude people have
> that if a
> problem is fixed, then it was never a problem in the first
> place.
>
Cheese Eating Surrender Monkey, really tired of idiots who assume
that because professionals did their job once, they can't possibly do
so again.

It's not a big deal if those professionals keep doing their jobs, and
- this is the part you're apparently too stupid to understand -
*doing* *their* *jobs* *isn't* *a* *big* *deal* *either*.

It's *routine.*

--
Terry Austin

Proof that Alan Baker is a liar and a fool, and even stupider than
Lynn:
https://www.cbp.gov/newsroom/stats/sw-border-migration

"Terry Austin: like the polio vaccine, only with more asshole."
-- David Bilek

Jesus forgives sinners, not criminals.

Paul S Person <psperson@old.netcom.invalid> wrote in
news:hekvmhh5jjbjnmefu2sjoecpkqla6pmmg3@4ax.com:

> On Fri, 11 Nov 2022 14:30:25 -0600, Lynn McGuire
> <lynnmcguire5@gmail.com> wrote:
>
>>xkcd: Y2K and 2038
>> https://xkcd.com/2697/
>>
>>It shouldn't cost more than a trillion dollars or two to
>>investigate this.
>>
>>Explained at:
>> https://www.explainxkcd.com/wiki/index.php/2697:_Y2K_and_2038
>
> So, two questions occur:
>
> 1. This appears to be a Unix problem. Apart of Unix and Linux
> and friends, will anyone /else/ be affected?
>
> 2. Why go to 33 bits? If the problem is that 32 is too few, why
> not just jump to 64 and save the future some problems? Is doing
> things in the clearly least optimal way (you are going to end up
> with 40 bits anyway, since they come in 8-bit groups called
> "bytes") a Unix/Linux tradition? Do Real Programmers always to
> things the Most Difficult Way Possible?
>
Perhaps it's comic, and 33 bits is funnier than 64, and _you missed
the joke_.

--
Terry Austin

Proof that Alan Baker is a liar and a fool, and even stupider than
Lynn:
https://www.cbp.gov/newsroom/stats/sw-border-migration

"Terry Austin: like the polio vaccine, only with more asshole."
-- David Bilek

Jesus forgives sinners, not criminals.

Lynn McGuire <lynnmcguire5@gmail.com> wrote in
news:tkor96$177j$1@gioia.aioe.org:

> On 11/12/2022 9:42 AM, Scott Lurndal wrote:
>> Jibini Kula Tumbili Kujisalimisha <taustinca@gmail.com> writes:
>>> Lynn McGuire <lynnmcguire5@gmail.com> wrote in
>>> news:tkmbd3$uc0u$2@dont-email.me:
>>>
>>>> xkcd: Y2K and 2038
>>>> https://xkcd.com/2697/
>>>>
>>>> It shouldn't cost more than a trillion dollars or two to
>>>> investigate this.
>>>
>>> I'll start doing so as soon as the check clears.
>>>
>>> Or it could end up being as big a nothingburger as y2k was,
>>> because the people who run such systems aren't idiots.
>>
>> We (Burroughs) started preparing for 2000 in 1987. None of our
>> customers were affected by the rollover (and most customer
>> software on those mainframes used two-digit year fields in
>> 1987).
>>
>> And, on the vast majority of unix/linux servers/desktops
>> currently running,
>>
>> sizeof(time_t)=8 (64 bits)
>>
>> Which pushes the "2038" date out to December 4th, in the year
>> 292,277,026,596.
>>
>> For the most part, a nothingburger. However, there are likely
>> lots of small embedded 32-bit processors in devices like
>> routers which may exhibit issues, if they're still running 16
>> years from now.
>
> The operating systems arefixed but the customer software is not.
> The software at minimum needs a recompile. But the software
> needs a going through to see if it is just stuffing the time and
> date information into a 32 bit signed integer.
>
Do you anticipate a lot of problems getting that done in the next
16 years?

--
Terry Austin

Proof that Alan Baker is a liar and a fool, and even stupider than
Lynn:
https://www.cbp.gov/newsroom/stats/sw-border-migration

"Terry Austin: like the polio vaccine, only with more asshole."
-- David Bilek

Jesus forgives sinners, not criminals.

On 11/12/2022 9:48 AM, pyotr filipivich wrote:
> scott@slp53.sl.home (Scott Lurndal) on Sat, 12 Nov 2022 16:57:44 GMT
> typed in rec.arts.sf.written the following:
>> Ninapenda Jibini <taustinca@gmail.com> writes:
>>> scott@slp53.sl.home (Scott Lurndal) wrote in
>>> news:l9PbL.74464$1449.32517@fx14.iad:
>>>
>>>> For the most part, a nothingburger. However, there are likely
>>>> lots of small embedded 32-bit processors in devices like routers
>>>> which may exhibit issues, if they're still running 16 years from
>>>> now.
>>>>
>>> You sound just like the doom criers ("Give me money or you'll
>>> DIE!!!") in the run up to y2k.
>>
>> I said "if they're still running 16 years from now", which is
>> quite unlikely. However, cheap-ass manufacturers may continue
>> to use the same software in newer devices, sadly.
>
> It is possible. As the cliche was "back in my day" - most of the
> current batch of programmers have no idea that there are COBOL
> programs still running which were compiled before they were born.
>
> The question is, how many people / organizations have a system
> which has been running, is running, will be running, with little or no
> reason to replace it with a New And Improved Hardware?

A surprisingly large number would be my guess.

--
I've done good in this world. Now I'm tired and just want to be a cranky
dirty old man.

On 11/12/2022 2:35 PM, Ninapenda Jibini wrote:
> dvandom@eyrie.org (Dave Van Domelen) wrote in

>> Dave Van Domelen, really tired of the attitude people have
>> that if a
>> problem is fixed, then it was never a problem in the first
>> place.
>>
> Cheese Eating Surrender Monkey, really tired of idiots who assume
> that because professionals did their job once, they can't possibly do
> so again.
>
> It's not a big deal if those professionals keep doing their jobs, and
> - this is the part you're apparently too stupid to understand -
> *doing* *their* *jobs* *isn't* *a* *big* *deal* *either*.
>
> It's *routine.*

Not a regular reader of the Risks digest, then.

--
Mark Jackson - https://mark-jackson.online/
Reasoning will never make a man correct an ill opinion, which
by reasoning he never acquired: for in the course of things,
men always grow vicious before they become unbelievers.
- Jonathan Swift

On 11/12/2022 1:37 PM, Ninapenda Jibini wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> wrote in
> news:tkor96$177j$1@gioia.aioe.org:
>
>> On 11/12/2022 9:42 AM, Scott Lurndal wrote:
>>> Jibini Kula Tumbili Kujisalimisha <taustinca@gmail.com> writes:
>>>> Lynn McGuire <lynnmcguire5@gmail.com> wrote in
>>>> news:tkmbd3$uc0u$2@dont-email.me:
>>>>
>>>>> xkcd: Y2K and 2038
>>>>> https://xkcd.com/2697/
>>>>>
>>>>> It shouldn't cost more than a trillion dollars or two to
>>>>> investigate this.
>>>>
>>>> I'll start doing so as soon as the check clears.
>>>>
>>>> Or it could end up being as big a nothingburger as y2k was,
>>>> because the people who run such systems aren't idiots.
>>>
>>> We (Burroughs) started preparing for 2000 in 1987. None of our
>>> customers were affected by the rollover (and most customer
>>> software on those mainframes used two-digit year fields in
>>> 1987).
>>>
>>> And, on the vast majority of unix/linux servers/desktops
>>> currently running,
>>>
>>> sizeof(time_t)=8 (64 bits)
>>>
>>> Which pushes the "2038" date out to December 4th, in the year
>>> 292,277,026,596.
>>>
>>> For the most part, a nothingburger. However, there are likely
>>> lots of small embedded 32-bit processors in devices like
>>> routers which may exhibit issues, if they're still running 16
>>> years from now.
>>
>> The operating systems arefixed but the customer software is not.
>> The software at minimum needs a recompile. But the software
>> needs a going through to see if it is just stuffing the time and
>> date information into a 32 bit signed integer.
>>
> Do you anticipate a lot of problems getting that done in the next
> 16 years?

Hard to tell. There is an enormous amount of custom software in companies.

Lynn

On 11/12/22 11:32 AM, Ninapenda Jibini wrote:
> scott@slp53.sl.home (Scott Lurndal) wrote in
> news:l9PbL.74464$1449.32517@fx14.iad:
>
>> For the most part, a nothingburger. However, there are likely
>> lots of small embedded 32-bit processors in devices like routers
>> which may exhibit issues, if they're still running 16 years from
>> now.
>>
> You sound just like the doom criers ("Give me money or you'll
> DIE!!!") in the run up to y2k.
>
> How many appliances with embedded processors running today do you
> actually believe will still be functional in another 16 years?
>
> https://www.wired.com/2000/01/y2k-alarmist-wha-happened/
>

Do not misunderstand. The Y2K problem was very real, and started causing
serious damage at least as early as August 16, 1972 (9999 days before
Y2K), when tapes on IBM mainframes that were supposed to be marked
“retain forever” started to be marked "ready for recycling” instead.

(It was also about that time that our operating system—to be fair to
IBM, it was a beta—started crashing every day at exactly 7:00PM EST. It
turned out to be caused by a zero divide in the rollover-GMT code—7:00PM
EST is midnight, GMT. And why the zero divide? Ultimately, because one
IBM coder was aware that, in the Gregorian Calendar, AD 1900 had skipped
leap year, while another coder was blissfully unaware of it.)

--
John W. Kennedy
Algernon Burbage, Lord Roderick, Father Martin, Bishop Baldwin,
King Pellinore, Captain Bailey, Merlin -- A Kingdom for a Stage!

On 11/12/22 12:07 PM, Paul S Person wrote:
> On Fri, 11 Nov 2022 14:30:25 -0600, Lynn McGuire
> <lynnmcguire5@gmail.com> wrote:
>
>> xkcd: Y2K and 2038
>> https://xkcd.com/2697/
>>
>> It shouldn't cost more than a trillion dollars or two to investigate this.
>>
>> Explained at:
>> https://www.explainxkcd.com/wiki/index.php/2697:_Y2K_and_2038
>
> So, two questions occur:
>
> 1. This appears to be a Unix problem. Apart of Unix and Linux and
> friends, will anyone /else/ be affected?

Don’t forget that macOS, iOS, iPadOS, tvOS, audioOS, and watchOS are all
built on Unix. However, programs for those operating systems are
normally coded using the Foundation library, and are all 64-bit-only by
now, so they shouldn’t have too much trouble.

> 2. Why go to 33 bits? If the problem is that 32 is too few, why not
> just jump to 64 and save the future some problems? Is doing things in
> the clearly least optimal way (you are going to end up with 40 bits
> anyway, since they come in 8-bit groups called "bytes") a Unix/Linux
> tradition? Do Real Programmers always to things the Most Difficult Way
> Possible?

I’m fairly certain 33 bits is a joke.

--
John W. Kennedy
Algernon Burbage, Lord Roderick, Father Martin, Bishop Baldwin,
King Pellinore, Captain Bailey, Merlin -- A Kingdom for a Stage!

On 11/12/22 12:48 PM, pyotr filipivich wrote:
> scott@slp53.sl.home (Scott Lurndal) on Sat, 12 Nov 2022 16:57:44 GMT
> typed in rec.arts.sf.written the following:
>> Ninapenda Jibini <taustinca@gmail.com> writes:
>>> scott@slp53.sl.home (Scott Lurndal) wrote in
>>> news:l9PbL.74464$1449.32517@fx14.iad:
>>>
>>>> For the most part, a nothingburger. However, there are likely
>>>> lots of small embedded 32-bit processors in devices like routers
>>>> which may exhibit issues, if they're still running 16 years from
>>>> now.
>>>>
>>> You sound just like the doom criers ("Give me money or you'll
>>> DIE!!!") in the run up to y2k.
>>
>> I said "if they're still running 16 years from now", which is
>> quite unlikely. However, cheap-ass manufacturers may continue
>> to use the same software in newer devices, sadly.
>
> It is possible. As the cliche was "back in my day" - most of the
> current batch of programmers have no idea that there are COBOL
> programs still running which were compiled before they were born.

Some say it was only thanks to Y2K that emulated 1401s finally vanished.

> The question is, how many people / organizations have a system
> which has been running, is running, will be running, with little or no
> reason to replace it with a New And Improved Hardware?

--
John W. Kennedy
Algernon Burbage, Lord Roderick, Father Martin, Bishop Baldwin,
King Pellinore, Captain Bailey, Merlin -- A Kingdom for a Stage!

On 11/12/22 1:09 PM, Scott Lurndal wrote:
> pyotr filipivich <phamp@mindspring.com> writes:
>> scott@slp53.sl.home (Scott Lurndal) on Sat, 12 Nov 2022 16:57:44 GMT
>> typed in rec.arts.sf.written the following:
>>> Ninapenda Jibini <taustinca@gmail.com> writes:
>>>> scott@slp53.sl.home (Scott Lurndal) wrote in
>>>> news:l9PbL.74464$1449.32517@fx14.iad:
>>>>
>>>>> For the most part, a nothingburger. However, there are likely
>>>>> lots of small embedded 32-bit processors in devices like routers
>>>>> which may exhibit issues, if they're still running 16 years from
>>>>> now.
>>>>>
>>>> You sound just like the doom criers ("Give me money or you'll
>>>> DIE!!!") in the run up to y2k.
>>>
>>> I said "if they're still running 16 years from now", which is
>>> quite unlikely. However, cheap-ass manufacturers may continue
>>> to use the same software in newer devices, sadly.
>>
>> It is possible. As the cliche was "back in my day" - most of the
>> current batch of programmers have no idea that there are COBOL
>> programs still running which were compiled before they were born.
>>
>> The question is, how many people / organizations have a system
>> which has been running, is running, will be running, with little or no
>> reason to replace it with a New And Improved Hardware?
>
> Most of those workloads are still running on legacy iron, and will
> for the forseeable future (IBM, Unisys). Modern workloads based on
> current distributed technologies (the world-wide web, for instance)
> are either already 64-bit clean.

Lots of business-related stuff on the web is based on code that
screen-scrapes virtual 3270s running on ancient COBOL programs, or at
least was until recently.

> The time_t issue is uniquely an
> Unix issue and those, aside from the low-end consumer grade hardware mentioned
> above, are largely already 64-bit clean.
>
> The competence of programmers varies, and it is likely that there is
> a fair amount of software that treats time_t as interchangable with
> the C/C++ 'int' type, which is prima facia broken, but works in 32-bit
> environments (and may continue to work post 2038 depending on the
> context of the usage).

--
John W. Kennedy
Algernon Burbage, Lord Roderick, Father Martin, Bishop Baldwin,
King Pellinore, Captain Bailey, Merlin -- A Kingdom for a Stage!

Mark Jackson <mjackson@alumni.caltech.edu> wrote in
news:jtaee3F1vqmU1@mid.individual.net:

> On 11/12/2022 2:35 PM, Ninapenda Jibini wrote:
>> dvandom@eyrie.org (Dave Van Domelen) wrote in
>
>>> Dave Van Domelen, really tired of the attitude people have
>>> that if a
>>> problem is fixed, then it was never a problem in the first
>>> place.
>>>
>> Cheese Eating Surrender Monkey, really tired of idiots who
>> assume that because professionals did their job once, they
>> can't possibly do so again.
>>
>> It's not a big deal if those professionals keep doing their
>> jobs, and - this is the part you're apparently too stupid to
>> understand - *doing* *their* *jobs* *isn't* *a* *big* *deal*
>> *either*.
>>
>> It's *routine.*
>
> Not a regular reader of the Risks digest, then.
>
I was for a while. Yes, stupid people do stupid things.

But the world didn't end at midnight, December 31, 1999, despite the
predictions of idiots like you.

And it won't in 2038, either, despite predictions by idiots like you.

--
Terry Austin

Proof that Alan Baker is a liar and a fool, and even stupider than
Lynn:
https://www.cbp.gov/newsroom/stats/sw-border-migration

"Terry Austin: like the polio vaccine, only with more asshole."
-- David Bilek

Jesus forgives sinners, not criminals.