Re: Removing ARCNET stuffs

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

On Thu, May 28, 2015 at 08:06:56PM +0200, Tom Ivar Helbekkmo wrote:
 > Me, too.  What NetBSD offers, that no other O/S offers, is the support
 > for platforms that are no longer mainstream.  I've run it on Sparc and
 > VAX processors for years, and hope to continue playing with these old
 > machines.  I enjoy reading about others running NetBSD on even more
 > exotic platforms.  (Incidentally, and I run OmniNet (an ancient 2Mbps
 > token ring network) between machines in my home lab that are too old to
 > even run NetBSD.)

I don't think (in general) that removing things is a good idea; but
it's increasingly difficult to keep NetBSD running on ancient
hardware. It's already infeasible to run the system compiler on most
such machines; this is only going to get worse with time. Other bloat
accumulates too, less rapidly perhaps but still so. The other day I
observed in chat that Someone(TM) needs to sit down with a slow
machine and a profiler for a while and find and kill all the
gratuitous bubble sorts, linear searches, and other things that run
too fast to be noticed on modern h/w; nobody disagreed, but on the
other hand nobody's been rushing to do it either. And other things
necessary for remaining relevant to semi-current hardware and usage,
like keeping up with X, desktop, and virtualization things, are often
in direct conflict with maintaining support for old hardware.

Meanwhile NetBSD has a persistent problem with marketing and market
positioning; to wit, we don't seem able to market and we haven't been
able to formulate any notion of who to market to or for what, or why
anyone should want to use NetBSD. The result of this is that the
15+-year-old market positioning of "of course it runs NetBSD" is still
floating around, except it's mutated into "NetBSD is an OS for
junkyard hardware". And the problem with that -- no matter how much
some people enjoy working with vintage hardware -- is that it doesn't
attract very many users or developers; especially since, as already
noted, NetBSD is not actually a very good OS for vintage hardware.

On top of this, it doesn't seem to me that there's much space in the
current and near-future computing landscape for traditional Unix; the
department login machine model is dead, and only a handful of
oldtimers use anything that can reasonably be described as a
"workstation". Meanwhile, the "desktop" software for Unix is basically
warmed-over Windows NT squatting on top of (not even integrated with)
a base Unix; and the way server farms are going there's increasingly
little role for multiuser OSes at all. An OS project that wants to
remain current has to adapt to these trends, and that means system-
level and design changes that move away from the traditional multiuser
Unix model that many of us are attached to. (This does not mean
rushing to embrace systemd -- it means things like hotplug disks,
numa-aware scheduling, filesystems for SSDs, streamlined system
configuration, and different security models; it also means keeping up
with moving standards like C++ and 802.11, and staying up to date with
necessary 3rd party software like gcc and X11.)

Because of these trends, I've been thinking for a while now that maybe
it's getting to be time to fork. That would allow having one project
that intends to stay current, with all the attendant requirements,
which probably mostly doesn't make sense on vintage hardware; and
another project that explicitly abandons most or all of that and
instead concentrates on being the best possible traditional multiuser
or workstation Unix, which does make sense on vintage hardware that
was designed for (or could be adapted to) those roles, and which also
makes sense on newer hardware to the extent it's consistent with the
traditional role.

At the moment NetBSD is trying to span both of these goal sets,
leaning somewhat towards the latter through conservatism, and not
doing either very well. I'm not at all sure that forking will improve
the situation (or that forking per se is even necessary to handle both
these foci) but it's probably at least worth thinking about.

(I am not sure, if this fork happened, which project I'd work on;
probably both.)

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.

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