Re: retrocomputing NetBSD style

[David Holland <dholland-tech%netbsd.org@localhost>]

On Mon, Jun 01, 2015 at 03:13:32PM -0700, Greg A. Woods wrote:
 > > There's one other thing I ought to mention here, which is that I have
 > > never entirely understood the point of running a modern OS on old
 > > hardware; if you're going to run a modern OS, you can run it on modern
 > > hardware and you get the exact same things as on old hardware, except
 > > faster and smoother. It's always seemed to me that running vintage
 > > OSes (on old hardware or even new) is more interesting, because that
 > > way you get a complete vintage environment with its own, substantively
 > > different, set of things. This does require maintaining the vintage
 > > OSes, but that's part of the fun... nonetheless, because I don't
 > > understand this point I may be suggesting something that makes no
 > > sense to people who do, so take all the above with that grain of
 > > salt.
 > 
 > You're quite right that it is interesting to run classic software on
 > classic hardware, to the extent that retrocomputing is about preserving
 > a bit of history, or living in the past, or whatever, and to the extent
 > that one might enjoy such a thing.
 > 
 > However there were, and are, a lot of us who want(ed) a modern OS to run
 > on our old hardware because we want(ed) to re-purpose that fine old
 > hardware to do something new and exciting with it.  I.e. I am/was not
 > building a museum, but rather trying to get things done and learn new
 > things.
 >
 > For example [...]

Right, I've been there too. However, it was some twenty years ago when
hardware in general was still a lot more expensive, and a five-year-
old castoff pmax was not all that overtly sluggish compared to what
you could pick up new for a reasonable amount of money. In fact, the
very first thing I did with NetBSD was to raid the source tree for
code to replace bits of Ultrix. (This was before the pmax port was
really runnable yet, and we needed to be in production.)

But nowadays five-year-old hardware (or even ten-year-old hardware) is
just sluggish x86 stuff that's no different from current x86 stuff.
The interesting retrocomputing hardware is 15+ years old, more like 25
for a pmax, and there just isn't much in the way of useful or
interesting things one can do with it. Apart from running software
that doesn't support / won't run on newer boxes.

Furthermore, it's no longer really all that worthwhile to salvage that
five-year-old or ten-year-old hardware, as opposed to acquiring a new
box instead. The cost of hardware in dollar amounts is a lot less than
it was in say 1995, and in real terms it's a lot less still. The
salvaged box has a bunch of secondary costs, like time you spend
waiting for it, or trying to find a suitable way to plug new disks
into it. I used to keep a stable of salvaged parts and machines; I
gave up on that a while back because it's just not worth it any more.
Most of the things one used to want spare machines for back in the day
can be done with VMs, and generally the rest warrant purchasing.

In other words, the landscape's changed.

And this is why I don't really understand the motivation for running
NetBSD on a 20-year-old box. BeOS, sure; RiscOS (the Acorn one), sure;
DOS 5.0 with DesqView, perhaps; maybe even Apple System 7; I can even
see maintaining some of these so they're still in some sense useful.
But NetBSD? You get nothing you don't get from a $400 walmart PC,
except the nameplate on the case and perhaps less nauseating
disassembly if you have to chase a compiler bug.

I grant that some people are attached to old machines such that they
think this is worthwhile, because I see it in front of me, but I don't
*get* it.

 > Also, w.r.t. supporting older and less-capable systems, I would now
 > treat them exactly the same as modern embedded systems with similar
 > limitations.

That's a fine start (and that's how it goes anyway) but it doesn't
really work all that well, as they're for doing different things.
Embedded systems don't run X; they don't have (or don't need to have)
general-purpose file systems, text editors, compilers, or any of the
other things that you would (or did) find on a workstation. They have
other things instead.

And also, it doesn't work that well because the relative speeds (and
sizes) of things are different. You might have an embedded system with
a CPU the speed of a hypersparc (for example) but it will likely have
substantially more RAM than any hypersparc machine, and that RAM will
be much faster relative to the processor; and while it might have a
similar size primary storage (a couple gigs) the embedded device's
storage will be flash, which even given the horrors of embedded CF
controllers and whatnot is vastly faster than hypersparc-era disks.

This has deep consequences for system tuning, which is one of the
reasons NetBSD is not really a good OS for hardware of that age.

 > I don't expect I'll ever do many, if any, full builds on
 > my RPi or BBB, and hopefully not even build many packages on them
 > either, but rather I will cross-compile for them on my far more beefy
 > big build server.  Were I to try to run the latest NetBSD on an old
 > Micro-VAX, Sun3, etc., I would never expect to actually do self-hosted
 > builds on such systems.  I really don't understand anyone who has the
 > desire to try to run build.sh on a VAX-750 to build even just a kernel,
 > let alone the whole distribution.  I won't even bother trying that on my
 > Soekris board!

If you were running a sun3-era OS (e.g. stock 4.3) on that sun3,
rebuilding the world would probably take overnight (and a kernel would
take an hour, per the old rule of thumb) but it would be a reasonable
thing to do, and not take e.g. a week and a half or whatever horrible
time a full build of current NetBSD would take.

It would be sort of interesting to track down where the difference
comes from (apart from the memory usage of gcc, which is obvious);
ascribing it to "bloat" is facile. But that would be a lot of work,
and when it comes down to it nobody really seems to care enough...

-- 
David A. Holland
dholland%netbsd.org@localhost