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 dholl...@netbsd.org