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

[Jed Donnelley]

At 06:18 AM 2/29/2008, Jonathan S. Shapiro wrote:
>I am replying only to cap-talk, because this thread is not appropriate
>for cap-conf.

I agree.

>On Thu, 2008-02-28 at 15:02 -0800, Jed Donnelley wrote:
> > I wonder if somebody could share some thoughts or pointers
> > to discussion about application support on other capability
> > systems and it's relationship to GNU or more OS "independent"
> > software development?
>
>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.  I would also find it interesting
to hear how much of any such re-engineering of applications
for PLASH would be considered useful (helpful, directly
applicable?) to other capability platforms.

E.g. could we come up with some sort of "caplib" that
would provide needed facilities at the library level
for adaptation to any underlying capability infrastructure?
The requirement would be that by combining those
routines from glibc that go over directly with replacement
calls from "caplib" for those that don't go over, then
we could start that task of re-engineering and be confident
that the resulting body of software would work over 'any'
underlying capability platform.

>but I think you are asking the wrong question.
>
>Your question tacitly assumes that a desktop-style computing environment
>(e.g. Windows or Linux) is the goal by which we should measure
>capability-based computing systems. I disagree. 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.  As I'm sure you well know there has been a huge
investment in coding in the GNU software.  The GNU applications
are what made Linux as successful as it is (inc. FreeBSD).

When you say:

>None of these have a substantial backwards
>compatibility problem, and there is still opportunity to build good
>systems there.

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?

>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.  As I mentioned above, I believe that body
of software is what made Linux possible and has sustained FreeBSD.

>Today, a comprehensive suite of tools exists in the form of
>OpenOffice, and that suite could be re-engineered.

One can throw OpenOffice into the suite of open source software
that is available for any platform, but what I'm asking about is
the cost of what you refer to as being "re-engineered" above.
That cost seems substantial to me.  How substantial?

Perhaps PLASH is the best example.  It seems to be facing this
problem in the purest form.

On the other hand, the situation that the Apple people faced
when dealing with the transition from the old MacOS to what
is essentially a Unix base might also be illustrative.  I'd
be quite interested to know more about what their API looks
like these days.  Did it just morph more into a Unix form
and thus provide no essential value for an effort like
"caplib" or did they perhaps provide some better isolation
that might be useful for another re-engineering effort?

If all the Apple software was suddenly open source, would
that software provide sufficient additional value to
launch another platform?  Perhaps Unix as a desktop
platform, but perhaps also some sort of platform with
a capability base?

Just so nobody thinks I'm ignoring the Web applications
front and chides me also for that, of course I recognize
that's there as well.  However, I don't see a body of
application software that be easily exploited to support
that 'platform' either.  Certainly rewriting such software
in Caja isn't going to get it done in a reasonable time
frame, even (I believe?) if the Caja code only provides
front end support.  E.g. I could imagine a lashed together
system where you had all the GNU software running on a
Unix platform, but where the user interface never saw it and
instead was pure "Web"/capability even to it's own hardware
platform.  I can't imagine such a system providing sufficient
application support to sell at this time.

More generally, I don't see the present time as another
"OS juncture".  One can argue that SUN took advantage of
the Unix software to sell into such a juncture with their
workstations.  Of course it's well known that Microsoft
developed into such a juncture on the PC platform.  I belive
Linux represented such a "juncture" regardless of how one
might argue that FreeBSD has been supporting that same
platform for so long.

Is there an opportunity like that now where a more
object oriented 'capability' platform could be exploited
for a new set of applications?

It seems that inadvertently I've been sucked into raising a
"big picture" question.  Fire away if you see value in the
discussion or kill the thread if it seems a waste of time.

--Jed  http://www.webstart.com/jed/