Subject: Re: Compiler timings on varous MVII NetBSDs etc.
To: None <wonko@tmok.com>
From: Lord Isildur <mrfusion@umbar.vaxpower.org>
List: port-vax
Date: 01/23/2001 11:17:36
I think a lot of the general problem comes from feeping creaturism, plain 
and simple, in all its various forms. The focus always _tends_ to be on 
adding new features, instead of merely refining and perfecting the ones 
in existence. Instead of trying to be linux and support tons of 
linuxisms, why not just refine the hardware support, fix bugs, patch
holes, etc, and maintain a lot of the more original BSD stuff? I see
the main work of the ports as to keep hardware support in the kernel 
current with the hardware out there. With VAXen, weve got a (mroe or 
less) knwon universe. im pretty certain that (unless i win the lottery :)
there wont ever be another model of VAX, and the ones in existence are
well documented, even if the docs cost a lot. Following the decrees of
the central port-meisters, the other ports i dont think get enough time 
to fix everything in one version before the next version cycle comes 
around.. I'd rather not make a total break from NetBSD, not unless we 
really cant reconcile the bloat issue (and the rc scripts! but im not 
gonna start that argument again now :) with the others. we need to keep the
extra features out! six dozen different filesystems, ipv6 by default, 
linux compatibility, etc etc etc
it's eating us alive! 
The VAX is not a very fast machine, even the fastest of 'em arent speed
demons anymore, but the vax is the granddaddy of BSD UNIX and we really
shouldnt lose our family history, so to speak! no other machines have as
much... style.. as a vax!! that style is being really cramped by the 
creeping bogosity thats is sneakign into netbsd! let's keep it out of here!
*end rant*

isildur

On Tue, 23 Jan 2001, Brian Hechinger wrote:

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