[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cap-talk
Subject:    Re: [cap-talk] Summer of Code
From:       "James A. Donald" <jamesd () echeque ! com>
Date:       2007-02-26 23:41:26
Message-ID: 45E37026.3050207 () echeque ! com
[Download RAW message or body]

Kevin Reid wrote:
> On Feb 26, 2007, at 14:33, Mark Seaborn wrote:
>> Would you want a Python implementation of E's Pluribus protocol?  (Is
>> it still called Pluribus or is it called CapTP?)
> 
> If I understand correctly, Pluribus is CapTP + VatTP.
> 
> VatTP is the encryption/vat-identity component, and CapTP is the  
> distributed reference component.
> 
> MarkM once told me [approximately] that CapTP is sufficiently complex  
> that he considered it a better idea to write an E implementation and  
> run (the as yet unwritten) CapTP-in-E on it than to reimplement CapTP  
> in other languages.

An interpreted language can be easily sandboxed, since the interpreter 
stands between the source code and every access to the machine.  So it 
is easy to do capabilities and suchlike in interpreters.

However, interpreted languages are always slow and inefficient.  I keep 
hearing people tell me that Java with JITC has only x% overhead, where x 
is a quite small number, yet I notice a striking difference in the 
performance of similar applications, where one is implemented in Java, 
and the other in C++.  Furthermore there is a great deal of open source 
and public domain C code around.

The primary area where interpreted languages are useful is where only a 
small number of copies of the program will ever be used, when, for 
example, one is writing code for one particular web site, in which 
situation programmer resources are vastly more limited and important 
than machine resources.

So we really do need a cap based VM environment that runs ELF files 
(Executable and Linking Format files), though I realize this is a rather 
  huge amount of work.  To get it done, really needs funding, perhaps by 
some deep pockets organization with a real need for a secure operating 
system.

Such a system can live within existing operating systems, and, over 
time, increasing amounts of code are executed within the capabilities 
system, and only old code, (therefore code that is likely to be somewhat 
trustworthy) is run within the outer operating system.

The OLTP operating system, bifrost, where everything runs in chrooted vm 
sandbox, is a big step in this direction, but it is still chrooted linux 
for compatibility with existing code, therefore fundamentally 
permissions based, not capabilities based.







> 

_______________________________________________
cap-talk mailing list
cap-talk@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk
[prev in list] [next in list] [prev in thread] [next in thread]