l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: design goals vs mechanisms


From: Marcus Brinkmann
Subject: Re: design goals vs mechanisms
Date: Thu, 27 Oct 2005 18:41:02 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Thu, 27 Oct 2005 11:20:11 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
> 
> On Thu, 2005-10-27 at 15:21 +0200, Marcus Brinkmann wrote:
> > [re persistence]
> > 
> > At Thu, 27 Oct 2005 11:38:06 +0200,
> > Bas Wijnen <address@hidden> wrote:
> > > mechanism for other goals.  I think we may want it as a goal by itself as
> > > well (unplugging the computer without need for explicit recovery is a nice
> > > thing), but probably low priority, so it may very well be dropped.
> > 
> > To be perfectly honest: I think it's pretty cool, even for its own
> > sake.  However, that is not really a good technical argument, and
> > persistence doesn't come for free, so that's why I am putting my
> > "careful hat" on.
> 
> Wait! When you say "pretty cool", you are actually saying "Hey, this is
> something that an end user might actually notice and like." That's a
> really *good* reason to look at it.

Darn, you got me.  This is absolutely right.  So you have proven that
I really am NOT an end user!  (I am actually serious about this.  I
really have to try much harder to put my end-user hat on, at least for
a short while).

> As to cost, yes, I am afraid that EROS-style persistence is
> significantly more efficient than conventional file systems, and we
> would face a definite design burden finding interesting uses for the
> newly available disk bandwidth.
> 
> Yes, it really is faster.

I believe you, but I was not referring to performance.  In fact, maybe
I am totally misattributing the problems.

I am thinking along the lines of lack object perimeter boundaries,
backups, and moving data from one machine to another.  Maybe you can
successfully argue that these are orthogonal problems, and maybe the
problem is not that the solutions are harder, but that the solutions
are different from the ones we already know in conventional systems.
In Unix the paradigm is "everything is a file", and we have mechanisms
to backup files, copy files, etc.  In a purely object-based system,
this seems harder, but maybe it is actually just different.

I attach a picture to illustrate the lack of object perimeter
boundaries.  Did it a while ago when I was bored.

PNG image


reply via email to

[Prev in Thread] Current Thread [Next in Thread]