Re: [9fans] VMs, etc. (was: Re: security questions)

[tlaronde@polynum.com]

On Fri, Apr 17, 2009 at 01:31:12PM -0500, blstuart@bellsouth.net wrote:
>
> Absolutly, but part of what has changed over the past 20
> years is that the rate at which this local processing power
> has grown has been faster than rate at which the processing
> power of the rack-mount box in the machine room has
> grown (large clusters not withstanding, that is).  So the
> gap between them has narrowed.

This is a geek attitude ;) You say that since I can buy something more
powerful (if I do not change the programs for fatter ones...) for the
same amount of money or a little more, I have to find something to do
with that.

My point of view is: if my terminal works, I keep it. If not, I buy
something cheaper, including in TCO, for happily doing the work that has
to be done ;)

I don't have to buy expensive things and try to find something to do
with them.

I try to have hardware that matches my needs.

And I prefer to put money on a CPU, more powerful, "far" from average
user "creativity", and the only beast I have to manage.

>
> > The processing is then better kept on a single CPU, handling the
> > concurrency (and not the fileserver trying to accomodate). The views are
> > multiplexed, but not the handling of the data....
>
> That is part of the conversation the question is meant
> to raise.  If cycles/second isn't as strong a justification
> for separate CPU servers, then are there other reasons
> we should still have the separation?  If so, do we need
> to think differently about the model?

The main point I have discovered very recently is that giving access to
the "system" resources is a centralized thing, and that a logical user
can have several distinct sessions on several distinct terminals, but
these are just "views": the data opened, especially for random rw is
opened by a single program.

Fileservers have only to provide what they do provide :

1) Random read/write for an uniq user.

2) Append only for shared data. (In KerGIS for example, some attributes
can be shared among users. So distinct (logical) users can open a file
rw, but they only append/write and the semantics of the data is so that
appending the n+1 records doesn't invalidate the [0,n]---records are
partitions, there is no overlapping. Changing the records (random
access) is possible but the cases are rare, and the stuff is done by the
user manager (another logical user)).

So the semantics of the data and the handling of users is so that a user
can randomly read/write (not sharable). A group can append/write but
without modifying records. And others can only (perhaps) read.

--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C