Re: Removing ARCNET stuffs

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

On Sat, May 30, 2015 at 11:05:30PM +0200, Johnny Billquist wrote:
 > > > I would argue that this has happened already - FreeBSD and NetBSD are
 > > > the results...  at least from the outside, this is how it looks like,
 > > > with FreeBSD focusing on few platforms but modernizing itself quite
 > > > a bit (kernel preempting, zfs, ...) and NetBSD focusing on "it runs
 > > > everywhere".
 > >
 > > Yes, see, this is the problem. "It runs everywhere" now means "it is
 > > an OS for junkyard machines". That was never the intent when that was
 > > NetBSD's market positioning, 15+ years ago. Nor is it the reality now.
 > 
 > We have different views here.

Do we? My position on this subject is somewhat complicated and not
well aired, but you do realize that for years I've been arguing
against removing things just because they're old, right?

I used the term "junkyard machines" in that bit deliberately, because
that's what the perception of NetBSD is becoming (or has become) in a
number of quarters: an obsolete operating system suitable for using on
obsolete hardware, and therefore not to be taken seriously and not
worth much of anything.

 > In my eyes, these "junkyard" machines have forced NetBSD to keep
 > somewhat honest.

Yes. That's why we still have the sun2 port, for example. That's why I
have (though not recently) put some time towards doing a port to a
36-bit machine. And why if possible we shouldn't remove arcnet.
Hanging these things on a fundamentally sound framework adds little
cost and helps to keep the framework sound.

There are two problems though: first, when the framework is not sound,
the extra stuff hanging on (and particularly, the complications that
arise from less elegant phenomena that appear only in old material,
VIVT caches being one example) can substantially increase the cost of
working on the framework. Many of the removal proposals arise from
this: this one, for example, as well as the intermittent suggestions
to prune old m68k ports. This is also part of why softupdates got
removed.

In these cases, keeping the extra old stuff along with its
complications during the framework rototilling usually results in a
better framework; but it makes the rototilling cost a lot more. As the
amount of manpower available has been dropping and the urgency of
certain reconstruction projects (most notably, the multiprocessor
network stack) only increases, there's a point where it becomes a
choice: keep the old stuff, or do the reconstruction. I don't know if
we've actually hit that point yet with the arcnet code or not;
probably not, actually. But unless something changes, we'll get there
soon enough. And then the choice comes right down to the point at
issue: keep the old stuff, which has assorted benefits and enables
continuing use of the old hardware it's associated with, or do the
reconstruction, which is necessary to remain a credible platform for
production use on modern hardware.

Whether or not we've reached it yet, there will fairly soon be a point
where "both" isn't an option. And then what? As much as the
retrocomputing users are a fairly important chunk of the NetBSD user
base, I don't think abandoning the claim/intent to be a serious modern
platform will sit well with the developer community. If we don't come
to some kind of resolution, most likely the same things will happen
that have happened in the recent past: NetBSD must do X and Y in order
to remain a serious platform, so NetBSD does X and Y, and because of
the negative consequences on retrocomputing platforms a chunk of that
community drifts away. This process helps nobody.

Meanwhile, the second problem (arising from instances of this same
process) is that "honest" or not, NetBSD is no longer really a viable
platform for the oldest hardware. This is most notable if you try to
run the compiler: gcc 4.8 is just too big to behave acceptably on a
slow and small platform. (And clang, if anything, is worse.) NetBSD
cannot roll back to an older and smaller compiler, for a number of
reasons the most difficult of which is that delightful moving target
known as Standard C++. We could ship pcc as the system compiler for
certain ports; but that doesn't really fix the problem (only hides it)
and makes those ports fundamentally second class in a way that nobody
will like. A similar problem exists with X, because upstream keeps
dropping support for "old" (as in 10-year-old, not 30) graphics
hardware.

The reason I floated the idea of forking is that an OS that's
specifically intended to be a high-quality Unix for older hardware can
make a different set of decisions (most notably, it can let C++ go
hang) and this allows avoiding a wide and growing range of problems
that currently affect NetBSD on old hardware. Meanwhile, it would also
(one hopes) allow retaining a critical mass of retrocomputing
enthusiasts in one place, as opposed to having them all gradually
drift away in different directions.

I'm not at all convinced it's a good idea; but none of the responses
posted so far have engaged any of these deeper issues, so I'm also not
at all convinced that it's a bad idea yet either.

 > The gradual dropping of "old" stuff
 > means that in my eyes, things are going downhill towards more sloppy code
 > and implementations, and more waste in general.
 > So in my eyes, the "runs everywhere" is what have made NetBSD attractive at
 > all, for all platforms, including modern ones.

Sure.

 > If you drop that, then NetBSD really becomes just yet another Unix clone,
 > for which there is no real reason for it to exist at all. There are plenty
 > of other alternatives in that niche, that have a much larger following.
 > NetBSD will totally fail if they decide that this is where it should be
 > going.

NetBSD, despite a long list of issues, is still by far the least
screwed up Unix available.

 > > > I'm not sure the BSD worlds needs yet another fork.
 > >
 > > No, it doesn't. On the other hand, running the same OS on 32-way
 > > x86_64 and Sparc IPC is increasingly not feasible or sensible.
 > 
 > I don't follow you here. So what are you saying. That people who want to
 > run some more modern software on old hardware should just go away? Or just
 > throw away the old hardware and get some x86_64, and still continue to run
 > NetBSD?

I'm saying that, fundamentally, if you want to run gcc4 or gcc5 on a
Sparc IPC that you're going to have problems. There is no way around
this, except maybe to float a new compiler with the specific goal of
both being modern and running on 25-year-old hardware. (That's an
enormous project.)

 > What about people who actually enjoy running odd hardware? What are the
 > options? From your arguing, I would say that the logical conclusion is that
 > we *need* a fork, since you obviously are saying that supporting old
 > hardware is not in the interest of NetBSD anymore.

No, that is neither obvious nor what I'm saying. See above. However,
what would you say the options are for a system compiler that can be
used on old hardware? That is in some ways the crux of the issue.
Maybe you don't care about compiling on old hardware; but then there
are other things, like X. Most of them right now arise from third
party code, because NetBSD's gone to a lot of effort to keep core
NetBSD things running. But realistically as the gap between (fixed)
old hardware and (still slowly improving) modern hardware grows, there
will be more problems.

One thing to remember is that when NetBSD originally did many of the
retrocomputing ports, the target machines were on the order of 10 to
15 years old. Nobody was trying to run NetBSD on 20-25 year old
hardware. There's no Pyramid port, for example. But those
retrocomputing ports are typically older now than the Pyramid was when
they were added. (More or less -- I don't remember the exact details
and the Pyramid's the only suitable 80s machine I remember offhand at
the moment.) The span of hardware generations that NetBSD's trying to
support has grown a lot over the years; and while the reduced pace of
hardware change in the last 10-15 years has made this less significant
than it otherwise might be(*), it's still inherently difficult.

(I realize the VAX port does not quite fit this pattern, but it's still
the basic pattern.)


(*) imagine if 2015 computers were as different from 2005 computers as
1990 computers were from 1980 computers...

 > Now, a fork for people having old hardware don't have to originate from
 > NetBSD, or from NetBSD-current. But in some ways it probably makes most
 > sense to start from some point in NetBSD.

One obvious starting point is Mouse's 1.4T-derived branch. But it
depends on what you want; there has been a lot of cleanup work since
1.4T, and while some of it is anathema to purists, some of it will be
valuable if what you want is an OS that can be maintained in the long
term, rather than a static artefact that rarely if ever changes much.

Given that there are old and moderately interesting multiprocessor
machines (like those Sequent 80386 things NetBSD doesn't support, if
any of them are still extant) ... the multiprocessorized network stack
is probably, in fact, something such a fork *does* want.

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