Subject: Re: Inquiry re: rsync replacement
To: None <>
From: Michiel Buddingh' <>
List: tech-userlevel
Date: 04/18/2006 20:04:31
From: Michiel Buddingh' <>
To: "Jeremy C. Reed" <>
Subject: Re: Inquiry re: rsync replacement
In-Reply-To: <>
User-Agent: Mutt/1.5.11

On Tue, Apr 18, 2006 at 08:23:42AM -0700, Jeremy C. Reed wrote:
> On Tue, 18 Apr 2006, Michiel Buddingh' wrote:
> > A final question is wether there's really any pressing need
> > for a BSD-licensed rsync replacement.  NetBSD has sup and
> > mtree in base, which provide for much of rsync's functionality,
> > if not its performance.  
> Can you point us to some example usage? Or can you provide some examples 
> here of using sup and mtree to replace rsync?

I believe rsync is generally used for three purposes:

1.  local synchronisation, where it finds the difference between two
  directories and copies updated files.  some scripting using mtree
  will do this just as well.

2.  fetching the latest updates from centralised software archives.
  sup works for this, if less efficiently.  cvsup and csup should
  be more convenient.

3. 'other' remote synchronisation.  This is where GNU rsync can't be
  beat.  It can cleverly tunnel over rsh and ssh, and it's ubiquitous.
  An incompatible 'bsync' would only be able to talk to other systems
  with bsync installed.  Making bsync compatible with rsync would not
  be trivial.

> > Unless I'm mistaken, csup (
> > provides a BSD-licenced synchronisation tool that uses the 
> > rsync protocol.
> The csup webpage doesn't mention much about that or how it can be used.

I have to admit, looking at the csup sources it seems that the rsync
part isn't quite implemented yet.  cvsup (the Modula-3 implementation
csup is based on) does use rsync.  And I mistakenly used 'rsync protocol'
where I should have written 'rsync algorithm'.

> And can you share an example of using csup to connect to a rsync server?

If you need the rsync protocol, use rsync.

> > The rsync protocol can be improved to decrease server load, but
> > unless there are sound reasons to do so, a project to write
> > a replacement seems like a gigantic waste of effort to me.
> I agree it is a waste of time. To me, it looks like we need 
> documentation  and need to tell people about the alternatives.

It depends.  I'm actually hoping that someone running one of the
netbsd rsync mirrors will chime in about the perceived use of and
load caused by the rsync daemon.  If it is generally felt that the
io load caused by rsync doesn't offset the amount of bandwidth
saved, it is definately possible to write a slightly different 
protocol optimised for central, relatively static software archives.
		-- Michiel