All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jared Rhine <jared@wordzoo.com>
To: xen-devel@lists.sourceforge.net
Subject: saving domains
Date: Wed, 09 Feb 2005 18:11:26 -0800	[thread overview]
Message-ID: <87zmydb1v5.wl@badger.wordzoo.com> (raw)
In-Reply-To: <420ABA76.6050301@us.ibm.com>

[Nivedita == niv@us.ibm.com on Wed, 09 Feb 2005 17:35:50 -0800]

  Jared> While "lighter weight" xend would be good, maybe C would be a
  Jared> better implementation language for that lightweight tool?
  Jared> Seems like having the fat Python xend implementation use the
  Jared> fat Twisted library makes sense...

  Nivedita> Wouldn't it be better to carve out a more robust
  Nivedita> alternative in C?

Not better, just different.

By definition, the Python codebase will be a whole lot more "robust"
in terms of features up until the point that thousands of lines of
code exist is a C-based replacement.

Make no mistake, we absolutely need a C-based daemon which can be used
on leaner dom0s where Python is not installed.

But I definitely think the existing xend codebase is very valuable,
should retain the xend name, be kept in the tree, and available for
those who like its approach and extensibility.  People will add
features if they want them.

It seems likely that xend will always be a more featureful alternative
to the once-and-future C-based control daemon.  The same people who
want a lightweight dom0 are going to want small, secure, and
well-controlled feature sets in that codebase.

-- jared@wordzoo.com

"We suffer primarily not from our vices or our weaknesses, but from our
 illusions.  We are haunted, not by reality, but by those images we have put
 in place of reality." - Daniel J. Boorstin


-------------------------------------------------------
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-02-10  2:11 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-09 23:54 saving domains Ian Pratt
2005-02-10  1:10 ` Jared Rhine
2005-02-10  1:35   ` Nivedita Singhvi
2005-02-10  2:11     ` Jared Rhine [this message]
2005-02-10  1:52   ` Adam Heath
2005-02-10 16:14 ` Ronald G. Minnich
  -- strict thread matches above, loose matches on Subject: below --
2005-02-10  9:07 Zhiyi Huang
2005-02-10  9:20 ` Arthur Bergman
     [not found] <BAY102-F15E8F04B4950494F7E1C67B3750@phx.gbl>
2005-02-10  6:57 ` Arthur Bergman
2005-02-10  2:13 Ian Pratt
2005-02-10  2:08 Ian Pratt
2005-02-10  1:51 Ian Pratt
2005-02-10  2:00 ` Mark Williamson
2005-02-10  2:06 ` Adam Heath
2005-02-10  2:20 ` Jared Rhine
2005-02-10 16:21 ` Ronald G. Minnich
2005-02-09 23:24 Tim Freeman
2005-02-09 23:30 ` Arthur Bergman
2005-02-10  2:27   ` Tim Freeman
2005-02-10  6:58     ` Arthur Bergman
2005-02-10 10:56   ` tdc

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=87zmydb1v5.wl@badger.wordzoo.com \
    --to=jared@wordzoo.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.