> > IFF, for the sake of discussion, this kind of testing indicated that
> > there really was a hurdle/bloat/crawl/whatever in the code, then, as
> > Isildur suggested, and apparently some others thought might be of
> > merit, perhaps a fork into a cast-in-stone end-of-the-line stable
> > final (or whatever) lean/mean/trimmed-to-the-bone OT-NetBSD-VAX
> > suite ought to be seriously considered.
>
> 	I think that would be a pity. NetBSD continues to be ported
> 	to more machines, including many CPU and memory limited
> 	systems such as arm26, and keeping the older machines
> 	running well acts as a balance to the excesses of designing
> 	for "bigger, better, faster, more" hardware. 1.5 does not
> 	seem to have the right balance, hopefully we can regain it
> 	for 1.6

OK, I will stand in line for the next burning-at-the-stake session...(:+{{...

I agree that balancing needs to be done, and maybe it is just the
1.4-1.5 jump that has caused me problems.

What is left to port for in the old VAX line?  I was under the
impression that that hardware was mostly cast in stone.  That is
a little different than porting things on new hardware architectures.

> 	As another example the disk performance on mac68k has dropped
> 	considerably between 1.4 and 1.5, but someone has sat down,
> 	worked out why, and initial signs indicate that the next version
> 	will be faster than 1.4.

Sadly, I am not a great code jock.  I can assemble machines out of
the dustbin, and run them with spit/glue/bailing-wire, etc, and
usually keep them going, but, my coding skills are just not there
to be of much deep value.  I am good a playing with other's code,
but just not great at new code.  I will offer my dinosaurs for testing
though, and be happy to let them dance all over the floor trying.

.....

> > We know the code and bloat (for whatever modernization reasons)
> > is only going to get greater (and that may not improve efficiency
> > any at all, especially on the old machines).
> >
> 	Some things will - such as softdep for filesystems, and UBC
> 	for more efficient memory usage.

That will be good.

.....

> 	We need to define why 1.5 is slower.
> 
> 	So far we have
> 		- rc.d
> 		- general code bloat

add in:         - slow tcpip (25% or more slower than 1.4.3)
                - no suitable tapebooting system for old machines
                - huge kernels (I dunno if that is a function of
                                gcc or creeping featuritis or both)

.....

> 	Release engineering is also continuing to process pullup requests
> 	for NetBSD 1.4 - I don't know if its planned to make any more full
> 	releases in the 1.4 line, but the release branch is still (for the
> 	moment) being maintained, so the insfrastructure is in place. Its
> 	unlikely however to gain any more hardware support.

Well, the old VAXes don't have much new hardware to support, so that is
not much of an issue?  That was one reason for thinking that a stable
divergent or end-of-the-line system might be appropriate for that class
hardware, which could be optimally tuned for use only on that class
hardware.  But, keeping a well-tuned old-machine-runnable single-code-
line tree is better.

Bob