All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Eric S. Johansson" <esj@harvee.org>
To: Jacob Gorm Hansen <jacobg@diku.dk>
Cc: Harry Butterworth <harry@hebutterworth.freeserve.co.uk>,
	mark.williamson@cl.cam.ac.uk, Stefan Berger <stefanb@us.ibm.com>,
	xen-devel@lists.sourceforge.net
Subject: Re: Another migration question
Date: Thu, 17 Mar 2005 20:27:12 -0500	[thread overview]
Message-ID: <423A2E70.7060604@harvee.org> (raw)
In-Reply-To: <4239F5B0.1030006@diku.dk>

Jacob Gorm Hansen wrote:
> There is an argument against making any of this transparent. If you 
> migrate stuff somewhere, you would like to be independent of the 
> originating machine once you arrive. Network transparent IPC/RPC, 
> filesystems, and process migration, were all hot topics in systems 
> research some 10-15 years ago, and, apart from NFS (which is now being 
> replaced by iSCSI) none of these fancy transparent schemes survived in 
> the real world.

from an operational perspective, I could not agree with this more.  If 
the task is moving from machine A to machine B, I am comfortable with 
specifying everything *as long as* there exists a tool to compare source 
against destination and point out to me what is different.

for example, if the source requires three disk images, I should be able 
to clear the system and be that three disk images are necessary.  I also 
should be able to change the size of the destination images and even the 
file system (in theory) used.

in other words, there's no crime in not automating as long as sufficient 
information can be provided in a way that leads the user to a reasonably 
correct solution.

as for the USB issue, moving from one system to the other is exactly the 
same as unplugging the device.  get out of the chair and move the 
device.  No need for fancy technological solutions there.  ;-)

> But that is just my view. I am likely to be wrong, or at least suffering 
> from the 'second system effect' ;-).

having acquired much scar tissue in the OS realm almost 20 years past, I 
don't believe you are suffering from second system effect.

---eric


-- 
http://www.wired.com/wired/archive/13.03/view.html?pg=5

The result of the duopoly that currently defines "competition" is that
prices and service suck. We're the world's leader in Internet
technology - except that we're not.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

  reply	other threads:[~2005-03-18  1:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-17  4:13 Another migration question Stefan Berger
2005-03-17  9:27 ` Keir Fraser
2005-03-17 14:31 ` M.A. Williamson
2005-03-17 15:29   ` Harry Butterworth
2005-03-17 21:25     ` Jacob Gorm Hansen
2005-03-18  1:27       ` Eric S. Johansson [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-03-17 10:42 Ian Pratt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=423A2E70.7060604@harvee.org \
    --to=esj@harvee.org \
    --cc=harry@hebutterworth.freeserve.co.uk \
    --cc=jacobg@diku.dk \
    --cc=mark.williamson@cl.cam.ac.uk \
    --cc=stefanb@us.ibm.com \
    --cc=xen-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.