[ On Monday, April 26, 1999 at 16:41:01 (-0700), Jonathan Stone wrote: ]
> Subject: Re: CVSup collections for a NetBSD CVS tree 
>
> Please *think* before you blurt. How many minutes does it take to set
> up cvsup on a server that's a SPARC, or a mips, or a powerpc?
> 
> CVSup is not really a *solution* for *Net*BSD, until it runs on all
> NetBSD platforms. ``Why is this so hard to grasp''?

Whoa!  Wait a minute!  Justin is 100,000% correct!  CVSup is *not* a
threat to NetBSD's ability to be used on low-powered hardware!

It's trivial to set up a CVSup *server* on NetBSD, provided the server
platform is chosen with CVSup in mind (which seems easy enough to do!).

Then, maybe, just maybe, if there was an official cvsup.netbsd.org
server running it then there might just be enough demand for the
advantages it offers that people would become interested in getting
Modula-3, and thus CVSup, working on *more* (or maybe even all!) NetBSD
platforms.  Certainly nobody's going to bother until there's an
incentive like this!

If a CVSup server was available then those who could take advantage of
it (which I think would be the vast *majority* of actual users) would
take a humongous load off the anonymous CVS server(s), not to mention
the resulting bandwidth savings and headache removal, etc.  It shouldn't
be too hard to confirm this either, given that FreeBSD offers CVSup
servers, and if I remember correctly they highly recommend their use
over other download schemes too!

In the end it really doesn't matter if Modula-3 never works on *all*
NetBSD platforms -- there are a zillion other ways for those without
CVSup to use to get their sources.

What matters is that CVSup exists and that it offers valuable
functionality.  CVSup is a tremendous performance enhancement that
*should* be used where possible!  It is *totally* irrlevant what it's
implemented in given that it runs on at least the most commonly deployed
NetBSD platform(s) and that other people are actively maintaining it!
Why is this so hard to grasp?!?!?!?  Why do NetBSD developers seem to
feel threatened by things like this?!?!?!?  If you're a developer on a
platform that CVSup doesn't work on, then go find a junk 486 on which to
run the minimal CVSup client and then use whatever protocol you can
locally to get the sources to your unsupported system!  (It would seem
that there will be literally boat-loads of "junk" PCs available by the
end of the year as companies throw out the machines with non-Y2K and
non-flashable BIOS ROMs on them -- here in Canada there are another ~60
days where government incentives are available to do just this, and as I
understand it the incentive only applies to hardware upgrades, not
software fixes! ;-)

I would strongly recommend that TNF find a volunteer (i.e. go out on the
net and so on and ask for someone to help) and assure everyone you ask
that this project will get full and official "support", and ask for some
suitable hardware to be donated and get it plugged in beside the FTP
server (or wherever's appropriate), and then let the volunteer get a
CVSup up and running before you dis the entire idea.  If TNF doesn't do
this on its own then there *will* be (an) unofficial CVSup server(s)
running almost immediately after the CVS repository is made available
because I for one will set my own up in colocation facilities just so I
can run CVSup over my low-bandwidth home link!  Whether I make it
publicly available or just available to my friends and colleagues will
probably just depend on my mood and other minor factors at the time.
However I think that if TNF does do this under its own initiative then
many concerns and worries about publicly available unofficial ones will
be eliminated.  (Hint: I'm going to set up such a server anyway, so I
*could* do it for TNF and perhaps not have to give up my own hardware
for the purpose!)

BTW, before anyone goes wandering off to re-implement CVSup in something
other than Modula-3, be well aware that much of it's efficiency seems to
come from the fact that it's a multi-threaded application.  It does seem
to require a fair bit of CPU, even just on the client side.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>