Subject: Re: Free Software vs. Disruptive Change
From: "Benjamin J. Tilly " <ben_tilly@operamail.com>
Date: Tue, 02 Jul 2002 19:26:53 +0800

Jonathan Shapiro wrote:
> [Ben Tilly wrote]
>
> > I took Jonathan's question to be rather
> > different.  Instead he is thinking of a disruptive 
technology as one
> > which causes us to rethink how we work, and start 
doing things in a
> > different way entirely.
>
> This is indeed what I meant. More to the point, a 
disruptive technology
> is one that resists "drop in compatibility", and 
therefore has a
> significant cost of adoption and/or engineering.

I am glad I guessed that right then. :-)

Unfortunately for you, big bang upgrades are
something that people shy away from for good
reason.  I really think that you are likely to have better
luck with asking how you can reduce the costs of 
adoption and/or engineering, rather than asking how 
you can afford that, while doing commercial 
development on a low-margin model.

> I shall respond on the other comments in this thread 
later -- I wanted
> to head off any confusion on this point before it 
snowballed.

Unfortunately one of those comments should have
been another response of mine, but that seems to
have disappeared into the ether.  (I probably forgot
to press "send"...)

What I wanted to point you at was
http://www.linuxdevices.com/articles/AT7248149889.ht
ml
which does a good job of explaining why the
examples that you are looking for are going to be
rather thin on the ground.

Beyond that, here is my concrete suggestion for
where I (as admittedly nothing more than an
interested bystander) think that EROS should go.

I would strongly recommend that you do a port of
a "user-mode EROS" running under Linux and/or
the *BSD family.  To that add the ability for it to
interact with processes and files in the host
operating system.  This makes EROS usable even
if you do not support the current hardware, and
even if you do not have ports of key packages.

An example use is that a closed device can use
EROS as a flexible secure sandbox for a copy of
Apache that is used to provide an administrative
interface.  The point being that even should
Apache prove to have a security hole (like the
current chunking bug),. the hole will be much
harder to exploit, and the possible exploit will be
limited to just the files being directly administered.

(Note that existing Linux solutions that I am aware
of are rather inadequate for this problem.  For
instance people may need to have root access to
some files in /etc, and no access to others.  This
is hard to do with, for instance, a chroot jail.)

Once people get EROS into systems, its advantages
(assuming that your old benchmarks remain true)
in terms of security, IPC performance, and (if you
have access to raw partitions) disk I/O will amount
to pressure to migrate more and more functionality
from the host OS to EROS.

Is this your desired mode of operation?  No.  But it
solves a lot of interoperability problems, and gives
you an incremental path to where you want to go,
one where a lot of what you want can be filled in by
others.

Cheers,
Ben
-- 
_______________________________________________
Download the free Opera browser at http://www.opera.com/


Free OperaMail at http://www.operamail.com/

Powered by Outblaze