[107352] in Cypherpunks
Re: COMMENTARY: Why You Will Survive Y2K
daemon@ATHENA.MIT.EDU (Jim Burnes - Denver)
Tue Jan 12 02:04:09 1999
Date: Mon, 11 Jan 1999 23:46:56 -0700 (MST)
From: Jim Burnes - Denver <jim.burnes@ssds.com>
To: Robert Hettinga <rah@shipwright.com>
cc: cypherpunks@cyberpass.net, owner-libertywire@mtx.harrybrowne2000.org
In-Reply-To: <v04020a0cb2c021141d85@[139.167.130.248]>
Reply-To: Jim Burnes - Denver <jim.burnes@ssds.com>
On Mon, 11 Jan 1999, Robert Hettinga forwarded:
> Date: Mon, 11 Jan 1999 07:23:23 -0700
> From: LibertyWire <Distribution@HarryBrowne2000.org>
> Organization: Harry Browne 2000 Exploratory Committee
> To: Subscriber <LibertyWire@mjx.harrybrowne2000.org>
> Subject: COMMENTARY: Why You Will Survive Y2K
> Sender: owner-libertywire@mjx.harrybrowne2000.org
>
>...
>
> Why You Will Survive Y2K
>
> By Harry Browne
>
> There is good news and bad news regarding the Y2K computer problem.
>
> The good news: Civilization isn't going to collapse in the year 2000.
>
> The bad news: I don't know where you can unload all the coins and food
> storage you've acquired.
>
Very amusing. I assume you can sell junk silver at the market value.
Food you can obviously eat.
> The Y2K problem has been exaggerated by people who don't understand
> computers, and by computer experts who don't understand how the free market
> works.
Unfortunately that presumes that Harry is a software engineer. Last time
Browne talked about his computer experience it was a singularly
unimpressive excercise. He likely understands free markets better.
Unfortunately there are problems even the free markets can't solve.
Most of these problems are time constrained. For example: TWA Flight
800 is going down in flames. There is definitly a profit motive in
fixing the problem. Quick, Free Market, save the passengers!
>
> Many large companies do need to upgrade old computer systems and databases
> (although your personal computer probably will have no problems). Changing
> a computer system is a formidable task. But so is moving into a new
> factory, changing a product line, or dealing with new regulations.
Harry isn't a software engineer and it shows. These are completely
different problem domains. How about this, Harry. Jane Dough has
inherited a genetic disease that causes accelerated aging. We know what
the problem is. We've finally invented a powerful nanite that patches
the miscoded gene. But wait, Jane Dough is dying of old age in 10 minutes.
It will take the nanites two months to fix the problem. Even then it
can't fix the degenerative damage the body has accumulated. Calcium loss
from bones. Dead brain cells. Liver damage. Occluded arteries. That will
take at least another year worth of nanite therapy. Remeber, Jane Dough
dies in 10 minutes. They inject her with the magic nanites and the
actually fix 20% of the miscoded genes before she expires. Before
she dies her hormone profile is back to normal. But the stroke that
killed her didn't care. Its very difficult to "un-ring" a bell.
Put in other words:
-------------------
Roy: Can the maker repair what he makes.
Tyrell: Would you like to be modified?
Roy: Stay here. [ pause ] I had in mind something a little more radical.
Tyrell: What-- What seems to be the problem?
Roy: Death.
Tyrell: Death. Well, I'm afraid that's a little out of my jurisdiction,
you--
Roy: I want more life, fucker.
Tyrell: The facts of life. To make an alteration in the evolvment of an
organic life system is fatal. A coding sequence cannot be revised once
it's been established.
----
Of course Roy is not the worldwide information infrastructure, but I
wouldn't be suprised if they were nearly as complex. The worldwide IS
infrastructure is very much like a huge organic life form. Once that life
form has been created and is running, its understanding of time is
critical. The Y2K problem encodes its "understanding" of time. Those two
digits are good for 99 years, much like each mitochondrial DNA strand in
the human body has 500 telomeres on it. Every time the cell divides, one
telomere is removed. When the telomere count is 0 the cell has reached its
Hayflick limit and dies. You could fix the human problem (maybe) by
resetting the telomere count to, say, 150 with some telomerase. The human
body would resume at 21 years of age. Its hormone profile might go back.
Its immune system may be able to fix most problems in time. Other
processes would come back also.
But Y2K is not like this. You can't just say, "Lets all pretend its
1921." Once the counterspace expires, lots of things don't work. To
pretend that we could reliably fix 30 years worth of software engineering
in the span of a year or so is, at best, intellectually dishonest and
at worst fraudulent.
Sure, there are lots of people working on this. There are lots of people
running automated software tools searching for those mysterious dates.
There is just too much code, and not enough time. All it takes is some
old creaky system where the porgrammers are dead., the code is poorly
documented or the source code is simply gone. A critical error in the
wrong place could start a chain of events that might not be stoppable. It
all depends how fast that component has to work, whether its been
identified as a problem, whether someone has corrected it.
Look at the Challeger disaster. A single brittle seal in a hypercritical
subsystem started a chain of events that "screwed the pooch".
That could never happen to the worldwide IS infrastructure. Of course
not. We have too many checks and balances. The free market uber alles.
What Mr Browne fails to see is that the bloated central bureaucracy that
he so much abhors is the equivalent of the Challenger disaster. All the
middle managers say everything is go for Y2K. All the upper level
managers say everything is just fine. Were right on schedule!
Maybe Mr. Browne's problem is that he mistakes the US Federal and State
bureaucracies, as well as the central banking system as a free market.
In that he deludes himself. For in the end, its the centralized feeding
troughs and thieves guilds which are the vectors of the Y2K infestation.
Y2K may inhabit my lowly Linux box, but then I don't cut the checks
for the welfare mothers. I don't cut the checks for the hundred
other "entitlement" programs leeching on the body politic. I don't
collect revenue to recyle US bonds that are due. I don't trade
megawatt hours across the regional power grid in realtime. I don't
calculate the critical steam temperature of a nuclear reactor's coolant
system 10 times a second. I don't manage arrival times and flight paths
at LAX. But don't worry. This will all be fine. Go back to sleep.
Dare I continue?
> Companies deal with such problems as they arise, and one way or another
> they usually solve them.
>
Usually. Were talking about an unusual situation.
> The Y2K problem seemed uniquely dangerous because millions of companies
> have to deal with it at the same time. Hundreds of thousands of COBOL
> programmers would have to be found -- to examine old computer programs,
> change every date reference, and test the corrections. But, in truth, a
> widespread problem is easier to handle, because it offers bigger profits to
> people who can devise solutions.
>
> So now there are products like Revolve, Restore 2000, Milligration, and
> dozens more -- computer programs that go through old programs, fix the date
> problems, and test the results. These automated solutions eliminate the
> need for thousands of programmers.
Bwahaha. Thats why Browne is making bad financial predictions rather
than programming computers. The obvious conclusion is that every bug
can be fixed and every path can be tested. I hope the medical marijuana
laws get passed soon, so they can find you something better to smoke
Harry.
>
> The Internet flourished in a similar, unpredictable way. If in 1994 someone
> had said there would be _millions_ of World Wide Web sites in 1999, you
> might have assumed he didn't understand computers. Websites are written in
> a complicated computer language called HTML. Where are the hundreds of
> thousands of HTML writers necessary to build millions of sites?
Sorry Harry, different problem domain. Those HTML coders are writing
new HTML code. Comparing a complex accounting system to a web page
is crazy. In any case, fixing Y2K with automated date fixers is like
saying automatted HTML generators can fix CGI bugs.
>
> But software companies came forward with computer programs that enable
> people to build websites without understanding HTML.
Thats because HTML is a page description language, not a programming
language. Understanding this difference requires a subtle mind
and maybe a whole year of computer programming experience. There are
a lot of postscript printer drivers, (another page description language)
but I wouldn't get my hopes up that the same algorithms will fix Y2K.
> Other programs help
> specialists to produce the more sophisticated, animated, interactive sites.
> The result is that we do have millions of websites after all.
Again, faulty logic.
>
> Websites abound and Y2K is being handled because the computer industry is
> the freest in America -- providing computers thousands of times faster than
> those of 1985, while selling at a fraction of 1985 prices.
>
> Of course, if the Justice Department defeats Microsoft, we may soon have a
> Federal Computer Agency that delays new products for years -- until it
> satisfies itself that the products are safe, effective, and
> non-monopolistic. Then computers and software will become continually more
> expensive -- just like a hospital stay or health insurance.
Unfortunately he uses faulty logic as a premise to argue for legitimate
concerns like keeping Janet Reno out of people's churches and computers.
> Does that sound too good to be true?
>
> Freedom always does.
>
> But somehow -- in ways we can never foresee -- it always delivers the
> goods.
>
Y2K may not be the end of the world, but Harry really should not
mix freedom (a subject he has a passing knowledge of), with computer
systems, the internet, emergent phenomena and large scale software
systems management and maintenance -- subjects he apparently doesn't
understand very well if at all.
jim burnes
jim.burnes@ssds.com
