On Thu, 29 Apr 1999, Greg A. Woods wrote:


.define DEVILS_ADVOCATE

# > Somebody mentioned porting M3 to (n-2) NetBSD architectures. Well, it's
# > doable, but M3-based CVSup has some more disadvantages:
# > 1) not many programmers are common with M3 (the amount of such
# > 	programmers is IMHO compared with COBOL programmers) -- 
# > 	modifying CVSup to better fit NetBSD environment and
# > 	bug fixing would be quite hard or near to impossible
# > 2) need to install (potentially huge) environment for M3 for just
# > 	ONE application (not such a big problem with binary packages,
# > 	but still)
# 
# I find that people not willing to install larger packages are often the
# very same people who are comfortable with binaries....

Not necessarily.  You're taking a very cash-centric point of view.
We are not all sufficiently endowed to just "go get more disk".
I cannot justify a budget for my own system which I'm lucky enough
to have.  I'm really hoping nothing hits MTBF any time soon.

# > NOT porting M3 to all NetBSD archs or CVSup to C is not an option.
# > I would be really sad, if NetBSD way of thinking would change to:
# > "Well, we distribute our source tree via highly efficient and
# > fast CVSup service. Enjoy."
# > "Ah, forgot to mention. You have to have i386 or alpha to use it."
# 
# You've not been paying attention!  That *is* the option!

Ah, yes.  The option either to run popular hardware and an optimal
protocol or to run better hardware and suffer the consequences.

# Besides, it's
# merely a matter of attitude adjustment and expectation management:
# 
# 	There are several ways to access the NetBSD CVS repository:
# 	1. CVS itself using anonymous CVS access.
# 	2. FTP a copy of the entire repository.
# 	3. Use SUP to track a copy of the repository.
# 	4. If you have an i386 or alpha (and soon m68k and sparc) then
#            you can also use the CVSup system.

How nice to support the exclusive club of "i386 and alpha".  "Soon"
doesn't mean jack in the computer world (see RSN).

# 
# > One reason I love NetBSD is we are treating all the archs equal -- I can
# > choose whatever hardware I happen to have and am still able to work
# > more-or-less the same way.
# 
# That's the biggest load of "bull stuff" there is!  Not all NetBSD ports
# are treated as equal.  I challenge anyone claiming this to obtain at
# least one, and possibly two, machines in every supported architecture
# and to use all of those machines on a daily basis and to dilligently
# upgrade each machine to the latest NetBSD software every time.  You'll
# find so many differences, discrepancies, etc., that you'll probably
# start pulling your hair out long before you've done one iteration of
# upgrades.

Define "upgrade".  Are you talking release or development?

# In any case, we're not talking about the basic OS functionality -- we're
# only talking about one highly specialized and narrowly used application.
# Get off your high horses and try it before you put it down.  Don't tell
# me that *I* can't use something just because *you* don't want to, or
# can't use it.

.undef DEVILS_ADVOCATE

In this case, actually, despite my previous flamage, I think I'd be
open to a binary package if..um, *when* it becomes available.  Trying
something new is a good thing.

.define POTENTIAL_FLAME_BAIT
[now if we can write sane dependency generators for startup without
degenerating into the atrocities which comprise System V run levels...]
.undef $LASTDEF

				--*greywolf;
--
When will people learn how to think!??  I long for the day to come when
software is purchased on the basis of technical merit and usefulness and not
on the basis of marketing bullsh*t.  And when is intelligence going to become
a prerequisite for survival?