[cap-talk] Selling capabilities programming

[James A. Donald]

James A. Donald:
 > > [The Xanadu project is] a fairly famous disaster,
 > > and if some people have difficulty perceiving the
 > > cause of the disaster, perhaps they were a little
 > > too close.

Jonathan S. Shapiro
 > be careful about drawing conclusions and/or casting
 > aspersions from folklore of this sort.

The cause of the disaster is apparent in the Xanadu
specifications

And to get back on topic, a similar problem is apparent
in the discussions on capabilities programming, where
people propose that a capabilities system should
simultaneously achieve mutually conflicting goals, and
that a capabilities system is broken if it does not
achieve these goals.

In order to control what matters, it is necessary to let
go of control of what does not matter, or else users
will be overwhelmed by detail, and will proceed to grant
coarse grained permissions.  Every proposed constraint
or goal, every behavior that supposedly must be
monitored or controlled, therefore needs to be justified
by a user interface case and examples of concrete
threats, yet I see no discussions of user interface and
concrete threats, no discussion of bad guys,
adversaries, intrusion, fraud, deception, denial of
service, theft of service, vandalism, violation of
privacy, or wrongful intent.  The limiting factor is not
how much control can be exercised by an all wise and
omniscient administrator, but how to obtain the required
amount of useful control from a very limited supply of
user bandwidth, All requirements on capabilities systems
need to be justified in terms of efficiency in
translating user attention to limits on the misconduct
of malicious software  and limits on the misconduct of
buggy software processing hostile data.  I am not seeing
any such justifications on this mailing list.

 > James: speaking as the last CEO of the Xanadu
 > Operating Company during its active phase, and as
 > someone who even Nelson agrees (somewhat to my
 > astonishment) was an effective leader for the company,
 > I can assure you that I have an exceptionally painful
 > and clear understanding of what went wrong at Xanadu.

The links you provided confirmed to me what I had
inferred from the Xanadu specifications.  I was
entertained but unsurprised to discover that Ted
Nelson's actions during the breakup suggests that he
believed that the most commercially valuable aspect of
the Xanadu project, the crown jewels of the project, was
the aspect that was most difficult to accomplish, and
furthest from accomplishment - the micropayment and
licensing system.

 > The folklore would have you believe that Xanadu was a
 > technical failure. It was not. Technical overreach,
 > while it did occur, was not the fundamental problem at
 > Xanadu. The fundamental problem at Xanadu was all too
 > prosaic: it was about control and money.

Technical overreach is obvious in the specifications -
which were problem statements, not solution statements,
were about what they wanted to do, not how it could be
done and sold and make a profit.

 From the specifications, I had suspected disfunctional
personalities, but was unaware of any specifics until I
checked out the links you posted.  But I have worked
with people much crazier than those described in those
articles - some would no doubt say I am much crazier
than those described in those articles - and yet I still
produced useful programs in considerably less than
thirty years.

Capabilities programming, like Xanadu, focuses on the
key problem of the era.  One should focus on the low
hanging fruit, solving the eighty percent of the problem
that requires twenty percent of the code, while having a
plan to get to most of the higher hanging fruit in due
course, rather than proposing a perfect, complete, and
total solution to the problem, and every closely related
problem, without bothering to check, or even think
about, what users do in practice and need in practice -
without bothering to envisage key details of how the
proposed perfect and complete solution could in fact be
presented to end users and used by end users - with
major aspects of the assumed total and complete solution
being in fact far from total and alarmingly incomplete,
the proposed solution being seemingly accomplishable
merely because key areas of the problem have been
ignored.