On Tue, Jul 13, 2004, Nadav Har'El wrote about "Re: [hackers-il] The Growing Complexity of UI Design":
> Do you remember by fork-bomb example, which I compared to cancer? A process
All my examples so far were of security violations, so this might lead the
reader to believe that complexity is only an issue when there is a malicious
adversary, or the computer equivalent of an "infection" or "cancer", involved.
But this is not so. I'll give you one example of many I saw in recent years.
A system administrator I know had the problem that every time he tried to
send out mail from a Unix system, the sending process hung for a minute or
so. That was a new problem - before it started, sending never hung for more
than a second.
This system administrator could not find the cause of the problem.
Sure, he had excellent diagnostic tools (ps, ls, cat, etc.) which are far
better than those available now for the human body. But just having these
tools was not enough. He didn't even know where to start. There could be
many concievable reasons that causes the mail sending to take a long time.
Lacking any clue on where to start his investigation, the system administrator
in question made a reasonable assumption - that something must have changed
in the system recently that caused this new problem. He knew that the only
thing that had changed was the installation of a few OS patches the day
before, and so blamed the new problem on these new patches. And since these
were the latest patches, there was nothing to do but wait until the next
round of patches, which fix the problems caused by the previous patches.
Or so he thought. Incorrectly. It turns out that the problem was completely
different. When he told me about this problem, I solved it for him in 5
minutes. I'll cut a long story short: the reason for the hangs was RBL
(anti-spam blacklists) lookups which were done also for outgoing mail.
The system administrator didn't even know that they were using RBL, let
alone for outgoing email (!), and couldn't know that the RBL's name servers
had stopped working recently. Only someone like me with a broad insight of
today's Unix, networking and Mail issues, could figure this problem out in
five minutes without spending a week on debugging, tracing and log-reading.
My insight in computers is similar to that of an experienced doctor on the
human body. And just like becoming a doctor is hard, it is becoming harder and
harder to be a "doctor" for computer problems. As computer software continues
to get more complicated, two things will happen: first, what I described as
"a week of debugging, tracing and log-reading" can turn into a month, and
then a year - until these foolproof techniques are no longer feasable and only
"approximate" techniques that can't solve *every* problem could be used.
Second, the situation where one person can be an "expert doctor" on "everything
on the Unix System" will not be able to continue. You'll have "general
practitioners" that know about common, generic, problems that afflict Unix
systems, and "experts" that each focuses on one thing - mail servers, http
servers, perl programs, etc. This is very much what happened in medicine.
Instead of generic solve-every-medical-problem quacks of centuries ago, we
now have general practitioners (rofe mishpacha) and specialized expert
doctors in various parts of the body, various types of disease and various
types of treatments and diagnostic techniques.
I think now it might be clearer why I am claiming that the complexity of
software is beginning to resemble that of the human body. But I emphasized
that it's just *beginning*. The human body is still many orders of magnitude
more complex than current software. But in a few decades, who knows? If
you remember a book review I wrote some months ago, Ray Kurzweil estimates
that this could happen as soon as the year 2020...
Nadav Har'El | Tuesday, Jul 13 2004, 24 Tammuz 5764
Phone +972-523-790466, ICQ 13349191 |I don't live on the edge, but sometimes I
|go there to visit.