From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <43f7b141be8c64cc35e328e0f83b9352@coraid.com>
From: erik quanstrom <quanstro@coraid.com>
Date: Wed,  7 Mar 2007 13:38:59 -0500
To: 9fans@cse.psu.edu
Subject: Re: [9fans] interesting potential targets for plan 9 and/or inferno
In-Reply-To: <9094a33e30aa804bfb00bb5b8ce20509@9netics.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 1a0c29ee-ead2-11e9-9d60-3106f5b1d025

On Wed Mar  7 13:18:26 EST 2007, 9nut@9netics.com wrote:
> > (e) 9p appliances.  the cannonical example of this would be ken's
> > fileserver.  it doesn't run the same kernel as the cpu server.  but it
> > does speak 9p.  thus it is able to be a very high-reliablity, well-
> > featured, efficient plan 9 appliance without a large or complex codebase.
> > (even the slightly crunchy pc port.)
> 
> drawterm and sns/rangboom to name a few more..

perhaps i didn't make myself clear.  i would contrast drawterm with
what i mean by "appliance".  by appliance, i would mean something
like ken's fs, which serves files via 9p.  it is unencombered by other
programs or the existance of userland at all.  another example would
be the coraid SR appliance, which serves blocks via AoE.

drawterm is an application.

the upside of an appliance is realiablity, performance and the lack of
a need to make everything work in the same space.  the downside
is that everything the appliance needs must be custom-made for the
appliance and it's a totally inflexable platform.

(ease of use should be mentioned, but i think we're still lacking in
that department.)

this level of effort and lack of flexability make sense for some things.
nobody wants their fileserver to crash.  but if a terminal or cpu server
go down, it shouldn't take more than a minute to get them going again.

- erik