The Joy of Java

[Perry E. Metzger]

Marianne Mueller writes:
> Perry writes: 
> 
>   You can do that safely without making it dangerous for your machine. I
>   know how I would build a restricted execution environment for such
>   markets. However, Java is 1) too slow, since if you are selling rendering
>   cycles or such you don't want to be running an interpreter, 2)
>   insufficently safe, and 3) paradoxically, insufficiently powerful for the
>   sort of code you would want to run in such an environment. 
> 
> What solution is fast enough and safe enough and powerful enough?  Does
> such a solution exist?  I say, No, it doesn't.

I say yes, it does.

If what you want to do is run a distributed ray tracer, and sell the
cycles for it, you can run an ordinary executable on a machine with an
unusual kernel. If, for example, you could completely revoke access to
the bulk of system calls and only permit I/O to a small number of
inherited file descriptors, you could probably manage to get a
reasonable engineering solution in place that would be suitable solely
for things like markets in CPU cycles. I could probably design such an
execution environment in a few weeks. Such an execution environment
radically differs from Java in so far as it has a "what is not
expressly permitted is forbidden" strategy all the way down to the
kernel interface. It might still be dangerous in the presence of
things like kernel bugs that permit you to write arbitrary memory
addresses, however. My suspicion is that something thats okay from an
engineering standpoint should be possible.

> But let's not have a food fight.  Although entertaining in the short term,
> food fights are actually deathly boring and incredibly unfruitful in the
> long term.  I'm interested in helping people do interesting things in a
> reasonably secure way, on the internet, using Java.

What you are saying, Marianne, is that you work for the Java group at
Sun, Java has become very important to Sun's strategy, and that thus
Java isn't going to be abandoned regardless of techincal problems.

> We're working on a response to the Felten el al. paper, which will
> be posted to the net shortly.  I think some of their points are
> perfectly valid, some of their points are irrelevant, and a lot of
> the presentation is melodramatic.  Melodrama is good for sound
> bites, I guess.

Look, not to be insulting, but your job pretty much dictates that you
have no choice but to declare their work to be incorrect. I mean, your
customers would be very mad for you to say otherwise, and your
management would fire you if you didn't say otherwise. This must
certainly color your commentary. Understand, I'm not accusing you of
being a bad person, but I am noting that you aren't in a position to
be objective.

Perry