Subject: Re: Patch to add console scrollback support.
To: Brian Chase <email@example.com>
From: Bang Jun-Young <firstname.lastname@example.org>
Date: 06/09/2001 18:01:14
On Sat, Jun 09, 2001 at 02:13:06AM -0500, Brian Chase wrote:
> Bahhhh... You're seeing the world through PeeCee tinted eyes. You must
> remember that one of NetBSD's major focal points is its portability. And
> given this, that means it runs on quite a few more systems than just Intel
> PCs with lots-o-memory -- or the 8Meg PC freebies you're taking jabs at
> here. Most of the older machines which are supported tend to have very
> modest amounts of both memory and CPU cycles. This includes systems such
> as the MicroVAX-II on which a memory config of 8Megs or less is fairly
> common. I myself have a number of VAX systems with as little as 4-6Megs.
Why don't you use 1.4.X or 1.5.X? They are much lesser feature-rich
compared to -current and even smaller in sizes. Why weren't you
against UBC when it was committed for the first time? There are a
number of features that will make the kernel even bigger by _default_
to be committed in the near future, such as new pipe, kqueue, etc.
> > Why should we have anything in the kernel at all? Micro-kernels have
> > proved to be pretty useless in reality, so why not strive in that
> > direction?
> I don't know... Linux has sort of strived in the opposite direction.
> Do you really want the NetBSD kernel to become what the Linux kernel has
> evolved into?
Has Linux evolved in a wrong way? I don't think so. It has a number
of features and advantages NetBSD doesn't yet (no, I don't want to
start an OS holy war here).
> I've no problems with these sorts of additions to the kernel as long as
> they're made optional through the kernel configuration file. But, it is
> actually important to keep in mind that NetBSD isn't just an OS for modern
> desktop systems and servers. It also supports a wide variety of older
> systems as well as more conservatively equipped contemporary embedded
> system platforms.
I'm surprised at so many objections to addition of such a little
feature to the kernel which I think good to have.
Anyway, in order to satisfy more people it should be:
* configurable at compile time via
* able to be disabled with sysctl(8) or wsconsctl(8) once it's
compiled into the kernel.
* machine-independent, hopefully
Bang Jun-Young <email@example.com>