From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <00037dfb4d26b0d653b0c6be36fbee99@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Sat, 18 Apr 2009 10:54:34 -0400
To: 9fans@9fans.net
In-Reply-To: <cce0d584dda21c47095f6d7191d1aafb@bellsouth.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] VMs, etc.  (was: Re: security questions)
Topicbox-Message-UUID: e58be86e-ead4-11e9-9d60-3106f5b1d025

On Fri Apr 17 16:22:55 EDT 2009, blstuart@bellsouth.net wrote:
> >> I often tell my students that every cycle used by overhead
> >> (kernel, UI, etc) is a cycle taken away from doing the work
> >> of applications.  I'd much rather have my DNA sequencing
> >> application finish in 25 days instead of 30 than to have
> >> the system look pretty during those 30 days.
> >
> > i didn't mean to imply we should not be frugal with cycles.
> > i ment to say that we simply don't have anything useful to
> > do with a vast majority of cycles, and that's just as wasteful
> > as doing bouncing icons.  we need to work on that problem.
>
> I gotcha.  I guess it depends on what you're doing.  I remember
> years ago running a simulation on the 11/750 we had.  It
> simulated a DSP chip running 2 seconds of real time.  It
> ran for over a week.  (While it was running, I took the time
> to write another, faster simulator that was able to run
> the simulation in about 2 hours.)  For something like that,
> we can certainly use all the cycles we can get.  On the other
> hand, I might look for a faster way to compile a kernel
> a while back, but now it compiles fast enough on most
> any machine that I'm not too concerned about where to
> use the cycles.  (I'm speaking of a Plan 9 or Inferno kernel
> here; not a *BSD or Linux kernel.)  But I suspect that
> virtualization and Dis-style VMs are a pretty good use of
> cycles we have to spare.

people's ideas about what's complicated or hard don't change
as quickly as computing power and storage has increased.  i
think there's currently a failure of imagination, at least on
my part.  there must be problems that aren't considered
because they were hard.

as an old example, i think that the lab's use of worm storage
for the main file server was incredibly insightful.

what could we do today, but don't quite dare?

- erik