On 2005.01.21 18:18 Matt Phillips wrote:
> 1) There seems to be argument over how serious the bug could be.
> "Well-written programs can simply be recompiled with a new version of
> the library that uses, for example, 8-byte values for the storage
> format," is one argument I read. How serious a risk do you think it is?

How many programs are well-written?

The commercial world is often not the least bit
interested in source code quality.

They are happy that it works, and will trade
any measure of quality against cost.

So it is rare to be able to guarantee
that a program will work just by switching
to a 64-bit compilation.

So the statement "Well-written..." is either
elitist or extremely naive.

Further it is a common attitude to say: "X is
*unlikely* to happen, so let us not worry about
it." This logic is fallacious. Indeed it is
precisely because we *know* that software might
fail that we *must* worry about it.

For instance we know for certain that programmers
sometimes truncate time values to the size of a
signed-integer. Therefore the only guarantee
anyone can make is that there are *no* guarantees!


> 2) You emphasize that small embedded systems may be most at risk. Is
> there anything that could be done for existing systems? Could you give
> me some idea of what could happen to items such as a toaster or an
> elevator with the bug?

In most cases nothing would happen.

But these are not critical systems. (Critical I
take to mean having appreciable social or economic
impact.)

Even an elevator is not a critical system because
building standards dictate that people can always
safely use the stairs, and because it would take
an awful lot of elevator failures to have an
economic impact.

One doesn't *need* to make guarantees about
non-critical systems. And there is no point in
end-users rushing to fix things. When small
business owners asked me about the Y2K bug:
"Should we call in a consultant? Should we
upgrade?" I asked them: "Will it break your
business if your computer stops working?" The
answer was always "No". So I told them that they
would not loose data; and they should worry about
it only if something stopped working. None of
those systems suffered.

In fact, having a wrong date does not mean that a
system will catastrophically fail. The system may
do nothing different than display the wrong date,
and otherwise continue working normally.

There are no systems that will *directly* put
lives in danger because such systems are always
designed to be fail-safe from an engineering
perspective.

That said, any device that is effected by this bug
will have to eventually be replaced. So there is
still a post facto cost that we ought to try and
minimize.

The warning is NOT a warning for the people
*using* the systems. This was the mistake of the
Y2K media campaign: The Y2K frenzy confused its
audience.

The warning is for the *developers* of systems.
They must plan *now* to save money later. A small
amount of effort now can save an enormous amount
down the line.


> 3) Do you think programmers will start adjusting to compensate for the
> bug? Is it too late in some cases? I read that it is already affecting
> mortgage programs and other long-term ones.

Have you ever known a programmer that didn't leave
a problem till the last possible minute?

Systems with immediate problems should switch
entirely to Dan Bernstein's Tai library at

http://cr.yp.to/libtai.html

Other systems should audit their code for correct
use of time_t throughout. They will also need to
audit there code to be 64-bit clean. These two
measures will enable them to migrate to 64-bit
platforms and compilers. Here is the SUS3 white
paper on 64-bit:

http://www.unix.org/version2/whatsnew/login_64bit.html

All programmers should concentrate on reducing
green-house gases or else we gonna have more to
worry about than dysfunctional computers.


> 4) How did you find out about it? Did you have a problem with it or
> just noticed that it might be a problem?

Well, if you think about it, it is pretty damn
obvious that 2 billion seconds will eventually run
out!! :-)

-paul


>
> I appreciate you taking the time to answer the questions, thanks.
> -Matt
>






On 2005.02.07 22:09 Matt Phillips wrote:
> Mr. Sheer,
> I have just a few more follow-up questions to the ones I asked a couple
> weeks ago. Everyone I showed the story to wanted to know more about
> you. What do you do, what's your background?

I have been a C programmer for most of my typing
life. I am an author of the book, "Linux: Rute
User's Tutorial and Exposition". I studied
Aeronautical Engineering. I currently do contract
work on an in-house enterprise system.


> Why are you leading the charge? Is there a
> story behind what made you think of or notice
> the bug?

I do remember the day I decided to register the
domain: it was during the dot-com frenzy and I had
woken up that morning with one of my "brilliant
ideas". (To put it in context, I had another
"brilliant idea" the week before: to OCR scan the
whole telephone book and put a searchable index
on-line. That idea was stupid for a number of
reasons, not the least being that it was illegal
since telephone books are copyrighted.)

Myself and the people I worked with had a lot of
stupid ideas back then. Monopolizing the 2038 Bug
was just one of about fifty ideas that were
ultimately never going to make any of us rich. But
in the end I kept the domain - I new it was
something socially important that I could help
with because I knew a lot about software.

Note that the 2038 Bug has always been quite well
known even long before the Y2K bug became common
knowledge --- it ought to be obvious to anyone who
understands the C programming language.

> Also, I saw a few people online saying that it may be already
> affecting long-term programs like mortgage programs.

Hmmm - could you send me a URL?

> Could this be possible?

In the first place, I will emphasize that it is
people who WRITE software and not people who USE
software that should worry.

Of course if a program calculates the difference
between two dates, and does it on either side
of the 2038 Bug, then the calculation may be
incorrect. 2038bug.com shows an example of a
real-life time average calculation that is
buggy.

I would expect any resulting financial errors,
like interest calculations and so forth, would be
huge and therefore easily noticeable. Programmers
do strange things in code, so exactly what will
happen is impossible to say. We are currently
33 years from the 2038 Bug. We will start to see
more activity in 3 years time, I suspect.

> What could happen if it did affect the programs?

There are three primary effects that are certain:

- Firstly, programmers are going to be staying
up all night fixing these obscure errors.

- Secondly, media spokespersons who know nothing
about computers are going to create wide-spread
paranoia based on technical and religious
hearsay.

- Thirdly, a lot of gullible people are going to
think the world is coming to an end and take
to the streets.

But aside from the occasional consumer being
inconvenienced (and statistically it is not
likely to be YOU), not much else will happen.

-paul


> Thanks for
> your help, I'll send you a copy of the final draft I'll be submitting to
> magazines if you want.
> -Matt