[ On Saturday, May 1, 1999 at 00:06:26 (-0700), Jonathan Stone wrote: ]
> Subject: Re: CVSup collections for a NetBSD CVS tree 
>
> Not really.  Modula-3's dominance of the sotware world is conspicuous
> by its absence.

I guess it depends on the circles you frequent in the software world.
I've always been surprised by the number and places it appears.  Try
doing a search through all the papers in various conference proceedings,
such as the Usenix and ACM archives, and I think you'll also be
surprised how often it turns up.  Go read the M3 home page too and have
a look at their "projects" page.

> >> Surely what the NetBSD community is (and should be) aware of is the
> >> truth: that if you run NetBSD, then there's a good chance that you
> >> simply *can't* run CVSUp, even if you wanted to.
> >
> >s/good//
> 
> No, there's a good chance.  

Yeah, right.  I really don't think so.  Does anyone sitting on the fence
have any *real* numbers to determine how many third-party developers are
restricted to each platform type?  I.e. let's find out how many
developers could use CVSup and how many cannot, and let's not just count
the vocal ones, but try to count all the silent ones too.

> >Or alpha or m86k or sparc, all of which I run (or at least own), and all
> >of which are supportable by the existing M3 compiler.  ;-)  
> 
> Not on NetBSD, though, according to the SRC homepage.

True, but the hard work is already done, both for the CPU support and
for a template of the OS runtime support.  I missed DECstation 3100 and
DECstation 5000 and VAX 8800 support the first time around too!  I think
that means all NetBSD supported platforms are theoretically supportable
by M3.

> The extant CVSup implementation is not a solution because it doenst
> run on all the boxes we need to support.  That is not an issue with
> tar, nor ftp, nor with sup.

It's not *the* solution.  It's is *a* solution.  It *IS* the *BEST*
solution for the job too, even if using it requires a specific platform
be dedicated to the job.  It is not the *only* solution -- just the
*BEST*.  This is abundantly clear to anyone who's used it in any
non-superficial manner (and maybe even to those who accept the
testimonials of those who have).  If you can't use the best and you
don't want to, or can't, put the effort into making the best solution
work for you then you will have to settle for the second best.  That's
perfectly fine and OK, just so long as you don't feel put out about it
and try to force everyone else to use only the second best as well.

> >Only
> >really serious third-party developers (i.e. those without CVS access) as
> >well as possibly those with direct but slow CVS access will ever really
> >want to use CVSup.  
> 
> So you're saying all the talk about how not having CVSup will overload
> our servers and eat our bandwidth is just FUD?

No, not necessarily.  It is all speculation, of course, since we don't
yet have a publicly available CVS repository to gauge how many users
will be copying it.  I think though that the FreeBSD repository would be
a good example.  I suspect their growth curve is similar, though
possilby more steep, and that a good guesstimate of what demands will be
put on a public NetBSD CVS repository server could be had by looking at
how may sup users they had before and after adding CVSup to their
toolkit, and looking at how much bandwidth their servers have sucked
before and after.

> >To put it extremely bluntly:  CVSup *could* be a better solution for
> >every NetBSD user that needs it if those that can't yet use it would get
> >off their duffs and port M3 to their favourite platforms instead of and
> >telling everyone else that they have to suffer without it too.
> 
> Greg, telling other people that *they* need to do the necessary
> legwork to make your preferred (but deeply flawed, for NetBDS) tool
> into a viable tool for NetBSD is both arrogant and rude.  

Excuse me?  Are you reading what I wrote?  Or are you trying to put
words in my mouth?  The latter is extremely rude.  I did not say
"need" -- I don't think I even implied it.

-- 
							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>