Let me say at the outset that I am not trying to put anything about
NetBSD or any of the BSD freaks down.  My goal in all this is to
raise issues, and, hopefully, see if they can be resolved to the
betterment of the entire BSD (including NetBSD and port-vax) crewe.
Hey, I am a BSD freak in the worst way, too...

But, I will bite the bullet, and say, ``Houston, we have a problem!''
This problem is centering around the decided downward trend in
the usability of NetBSD (particularly 1.5, but also to some extent
1.4.x) on older VAX hardware.  I speak particularly to issues of
bloat and slowness on things like MicroVAX II and 11/7xx machines,
typically in the 1.0VUP and under class, but, the issues are
beginning to appear in the MV3100 class machines, and all VAX
machines with 16mb ram and under.

To the extent that raising these issues will help the BSD
community along, I will support all that can be done to to
help resolve these issues.

.....

> ok, i've been meaning to say something here, but there is just too much to
> cover! ;)
> 
> > It is OK to relegate them to the retirement pasture, ane let 1.4.x
> > be their final hurrah.  But, if we are not careful, the same thing
> > will happen shortly to the 3100 class machines.  I can feel the
> > slowness on those, too.  IF we maintain that we are actively going
> > to support the historic VAX machines, then, ``Houston,  we have a
> > problem!''
> 
> and after the 3100, what next?  the 7000 machines being too slow to run NetBSD
> 5.0?  where will it end if we allow it to continue this way.

Good point.  Hopefully it will not require a 4000 class VAX and up just
to run NetBSD, in the future.  That would not be good for the premise
that we support VAXen of all flavors.

> > I know it is heresy to say this, but I will, again..... IF it really
> > is reaching that point in time where the 1.0VUP boxes are becoming
> > priced out of the market, then we need to separate out a code tree
> > for VAX 1.0 VUP machines and under, and then optimize it as a final
> > hurrah for these machines, freeze it, and keep it as the Classical
> > VAX NetBSD.  There is nothing wrong with that, and 1.5 is getting
> > mostly useless on these machines.  It hurts, too, cuz I really do
> > like the ol' MVII critters, and am actively looking for a 730 or
> > 750 box to try.
> 
> i've _got_ a /750 that i've been planning on running NetBSD on for years.  i
> will probably be going and picking it up in the next couple months, i'd really
> like it to perform as well as to be expected.
> 
> if (and again, heresy) we would seperate the code out to form a seperate tree
> i wouldn't want to see it ended at 1.4.x, i'd rather see a VaxBSD, as we thumb
> our noses at NetBSD saying "we can keep the bloat out, why can't you?"  this,
> of course, is assuming that progress can't be made to keep NetBSD in check.
> it NetBSD is becoming bloated, then i personally care to have nothing to do
> with it.  the whole reason i run NetBSD is that it is supposedly /not/ bloated.

Well, the bloat is there over time, but perhaps we should consider it
relative to what is actually required and what could be considered fluff
and not really required for a usable VAX port.

I run several MVII class machines, one with 4x1g mscp scsi drives,
each loaded with a different version of NetBSD (1.0A, 1.1A, 1.2,
1.3, 1.3.2, 1.4.1, 1.4.3, 1.5) and Ultrix  as needed.  Currently,
1.2, 1.3, 1.4.3, and 1.5 are up on it, and my other MVII is running
4.3BSD and Ultrix.  When set up this way, I can really see and feel
the load on the slower machines.  It is becoming such that 1.5 is
essentially unusable on the MVII class (essentially the 1.0VUP
class and slower VAXen) machines.

I tossed out the idea of IFF it is an endemic problem, then one scenario
might be to separate out a Classic VAX tree, and then keep that as the
final hurrah for the old machines.  There is pro and con for that, but,
it is one option.

> > Is there a practical solution?  I dunno, but keep hoping there is.
> > NetBSD-1.5 on the slow boxes is just not practical, anymore.
> 
> i just hope thie new list can help make some inroads to the performance
> problem.  too much of the PC minset is being adopted (well, CPUs and RAM are
> so fast/cheap, who cares) when on the other hand NetBSD is trying to maintain
> this "runs on anyt platform" ideology, but the two DO NOT MIX.

This is an important issue at this time.  Maybe it is time for official
clarification.

> >> Yeah - some of us don't have (read can't be bothered reconfiguring) any
> >> ix86 boxen with NetBSD just to crosscompile, although I may do one day if
> >> things carry on this way.
> 
> my last x86 box died (i don't count my laptop since it runs windows all of the
> time) and i spent no time at all trying to revive it.  i dumped it in the
> corner of my "non-working" pile, and it is there to stay.  i've messed around
> with x86 a very few times in my life, and i hate it so much, i just don't even
> care to look at it.  build a cross-compiler out of an x86 box, not a snowball's
> chance in..................
> 
> > I have taken to compiling big things on my VS3100/M76 box at 7 VUPS as
> > opposed to my MVII at 1 VUP.  That helps some.  I would really hate to
> > have to stoop to a PeeCee to do that, although I have this 7000 class
> > Alpha biggiemachine sitting out in the shed.....(:+}}...
> 
> a few of us are lucky enough to own this cool old iron.  to make it useless?
> i'd rather run VMS.

I can't handle the veddylongextendedwordinessrequirement of VMS.
That is not in my vocabulary.  I prefer cat, du, etc.  It just 
hurts when cat becomes a megabyte in size and takes an hour to run!

But, in the hope that we can resolve some of these issues, let's
go for it!

``Houston, we have a problem!''

Now, lets see if we can fix it and get the NetBSD machine home!

Thanks

Bob