[cap-talk] Applications for a capability platform (was: OS juncture papers)

[Jonathan S. Shapiro]

On Fri, 2008-02-29 at 09:27 -0800, Jed Donnelley wrote:
> At 06:18 AM 2/29/2008, Jonathan S. Shapiro wrote:
> >You are surely aware of PLASH,
> 
> Indeed, as PLASH has been often discussed on this list.  However,
> I don't know what the issues are that PLASH faced with regard
> to getting the GNU applications to run.  I'd be interested to
> hear about those in more detail.  E.g. what fraction of
> glibc can be adapted to run directly over a capability
> infrastructure and what fraction requires "re-engineering"
> at the application level.

As I understand it, PLASH proceeds by establishing a new file name space
just prior to application start, and binding capabilities in the name
space in a way that is consistent with the application's expectations
and requirements.

The net effect of this is that the application is oblivious to the fact
that it runs within a capability environment, and no "caplib" is
required. A major point of PLASH is that application re-engineering is
not required.

That said, however, I think we can then start to look at hybrid
solutions that would augment PLASH with things like a power box. These
would require source-level modification of the applications or their
runtime libraries (e.g. Gnome), but such modifications would be
well-localized within the respective applications.

> >There is a large and
> >growing body of embedded systems that are slowly morphing into
> >application platforms.
> 
> I'm interested to hear more about application level support in
> such systems.

There isn't any to speak of. What is going on at present seems to be
that each of these devices has it's own application infrastructure that
is largely incompatible with all others. Customers aren't yet noticing
that bottleneck, because there is another bottleneck ahead of it: the
device vendors are impeding the transfer of user data.

Consider, for example, that on most cell phones you cannot
straightforwardly migrate your address book to a cell phone from a
different vendor (or even, in some cases, the same vendor).

Since the data is effectively captive, questions of application
compatibility become moot.

> Are you suggesting that this body of embedded systems that are
> 'slowly' morphing into application platforms now have sufficient
> mass that if I was facing the dilemma that Bechtotsheim, Baskett,
> and Pratt faced of needing a body of application support software
> to deliver end user value to a platform, that I could use this
> set of applications written to run over embedded systems to sell
> an end user platform?  Would that mean abandoning the existing
> open source (mostly GNU?) software?

No. I am saying that the platforms on which open source applications now
run are slowly but inevitably becoming less and less significant, and
that the applications which run on embedded platforms have only limited
overlap with desktop applications. This does not entail abandoning
existing open source software (which, aside, is definitely NOT "mostly
GNU"), but it does suggest that a new application platform based on a
different foundation is not out of the question.

> >As to desktop applications, there has been a significant shift. 10 years
> >ago, there simply *weren't* any open source desktop applications worth
> >mentioning.
> 
> Hmmm.  Of course much (most?) of the GNU suite of software was
> available 10 years ago.

Yes. But outside of a few developers, nobody gives a damn (or should).
The applications that actually deliver value to the world at large are
things like Evolution (email), Firefox (browsing), and OpenOffice. It is
also noteworthy that NONE of these are GNU applications.


shap