> However, when it drops to console mode, its back to 'ed' because it 
> doesn't drive the console sufficiently for vi, emacs, etc.  This is, 
> in my opinion, really slack.  

I fully agree with this...  I tried to use a DECstation's console
briefly.  I've also found NetBSD 0.9's default console to be lacking
somewhat...  resize(1), for example, throws it for a loop.  I think
that a good VT102 emulator is dandy.  It's highly useful with just
about any system you login to.

> As a normal (non-kernel-hacker) user, a user-interface crash == a system
> crash.

BS.  I'd much rather be booted out to the login prompt than have to sit
through a reboot--especially if the reboot might not be secure.

> I want the console - the system console - to be improved.

How much?  Part of the problem here might be that the console has been
dramatically improved already.  Nobody but Brad and Lawrence have seen
it, and the debate should probably be postponed until we do.

> Can I do that from the user-world?
> Other than write a shell that talks direct to the hardware, I don't believe
> that I can.  At the very least, the console driver must support me!

That depends on how much rope the drivers give you.  X has to do pointer
tracking and bitmapped graphics.  It does so by negotiating with the
various drivers.  Any other user-land program should theoretically be
able to do this.  If additional hooks are put into the console code to
support reduction of the scrolling region of the screen, a user-level
program could, indeed make a menu bar on the top of the screen.

> I have seen some pretty neat HP console
> drivers that managed to map function button labels onto the bottom of the
> screen, even in console mode.  I don't see that this is any different.

I don't think that this, or the PMAX, or probably the suns have a built-in
80x24 (or any other) character generator.  In fact,

> However, functions that allows you to (1) change color depth (2) refresh
> the screen (3) spit screen image to disk (4) log console text to disk etc
> would be useful to most users with minimal expense.  Control of the
> "console".  Sure it can be done with user-mode programs "like 'con' which
> we use at the moment".  Again I say, so what?  Un*x heritage has always
> been that there are >1 ways to do anything.

I think that user-level programs are the best way to do it.  The kernel
provides the "how," the user-level programs provide the action.

> What is with this "Lets kick the Macintosh" attitude anyway?

I don't see it as that.  I see it as a "Let's kick the bloated kernels."
We have some NCR machines at work running SVR4-MP.  They have 16MB of
RAM.  After booting, there are about 5 free.  Yes, I've looked at all
the tunable parameters and made sure that all the extraneous drivers are
removed from the kernel.  It's still taking 11MB.  I have no clue why,
but NCR says that the minimum RAM requirements are 16MB.  ARGH!!!!!!!

> Having everyone say "NO" always incites me to say "YES" when I don't
> believe adequate, valid, reasoning has been presented.

The adequate, valid reasoning that I have to offer is that there are
other things that *need* to be done by the end of this week.

-allen

-- 
Allen Briggs - end killing - allen.briggs@vt.edu ** MacBSD == NetBSD/Mac **
= Over the years you swam the ocean following feelings of your own [...]  =
== It's a shame to have to die to put the shadow on our eyes.  We don't  ==
=== want to care. Under the bridge. Over the phone. Wind on the Water.  ===

------------------------------------------------------------------------------