> 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.  

No, that's _not_ why you have to use 'ed' on any modern system.
a vt102, vt200, and probably even a vt100, can work just fine
with vi and emacs.  the reason you have to use ed is because:
	(1) your system is misconfigured, so the console type
		is not "published" in single-user mode, or
	(2) (and this is quite common, and some would say correct)
		ed is generally the only statically linked
		editor, and generally the only editor that's
		present on the root partition.  i.e. you have
		to mount /usr to use vi, etc.

If your console can't support it, then you're running
a _really_ backward version of UN*X; pretty much ever since
bitmapped consoles came along, a minimal terminal emulation
(of some type) has been built into every system's console
driver.

and before you go knocking the power or usefulness of 'ed':
You know the NFS code in 4BSD?  the same stuff that's been in
NetBSD since its inception?  well, it was written by Rick
Macklem, of U. Guelph.  Would you care to guess what editor
Rick uses?  That's right, 'ed', and only 'ed'.  Real people
can definitely write Real code using ed.

> I did say "I don't necessarily want to run X".  Give me a console driver
> (like the current one is) that gives me multiple screens and I *can* live
> without windows.  Unix (as someone once said ;-) has always been minimalist;
> it operates fine for me without multiple, overlapping windows and icons and
> all that stuff.

ahh, so what you really want to do is use screen!  it'll give you
multiple screens, two-at-a time, etc., and hell, it's already
in /usr/bin!

> > 	(2) uninterruptible operations!  when running in the kernel,
> > 		the system is not preemptible.  that means that the
> > 		scheduling algorithm suffers, and depending on the
> > 		mac's interrupt architecture, can cause system
> > 		performance to go to hell in a handcart!
> 
> I agree on this; yes, tracking a mouse thats in a pull-down menu could cause
> interrupt problems.  But then again, somehow the MacOS manages to do it
> without freezing the machine; I have always assumed that the people who can
> write this stuff know what they are doing.

have you ever programmed in MacOS?  I did it for about 6 years before
I found out about UNIX.  Yes, except for interrupts, tracking a menu
DOES freeze the machine.

> > 	(3) less safety!  If there's a kernel bug, it'll crash
> > 		the system.  I'd rather have a user-interface
> > 		crash than the kernel crash.  more code -> more
> > 		bugs.
> 
> As a normal (non-kernel-hacker) user, a user-interface crash == a system
> crash.

Really?

user-interface crash == "invoke the user-interface program
again".  system crash (for NetBSD/mac) == "watch the machine do cute
things when resetting, boot to macos, boot BSD, clean the
disks, start the daemons, log in (thereby starting the built-in
user-interface program)".

As a user, i'd rather save the several minutes wasted in
the reboot, thank you very much!

> I want the console - the system console - to be improved.  You know, boot
> up - single user mode, that stuff?  Can I do that from the user-world?

Yes.  First of all, given the concerns you mentioned above, it already
does lots of what you want.  however, it's worth noting that _ANY_
binary you can run in multi-user mode you can run in single-user
mode.  If you write your 'console enhancer' correctly (and it's
not hard; see screen), then you can run arbitrary programs under it.

> 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!
> Surely?

Nope.  I suggest you investigate a bit of what single-user mode really
is.  While your investigating, i'd look at what shell scripts
can do (they _can't_ talk to the hardware), and what pty's do.

> Yes, I know I am not running MacOS any more.  Curiously enough, that
> doesn't magically inject any more hardware into my machine.  There is *NO*
> repeat *NO* 80x24 character generator in the Macintosh.  

right.  it's just bitmap.  to get a font, you've gotta include
a font file in the kernel, and blit the characters yourself.

Same on the DECstation, same on the amiga.  yup, that's right.
No built in font on either, and no built in renderer.  OK,
fine, the amiga has a blitter, and the DEC can have one, too,
but that just makes for a faster copy, and has little to do with
the machine's capabilities for font drawing.

> I am fascinated to know which "rules" Unix imposes that define the
> behaviour of the "system console".  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.

205 [mako] cgd % uname -a
HP-UX mako A.09.01 E 9000/730 2007815234 8-user license
206 [mako] cgd % size /hp-ux
1717016 + 278792 + 283392 = 2279200

better yet:

41 [alpha] cgd % uname -a
OSF1 alpha.bostic.com V2.0 240 alpha
42 [alpha] cgd % size /vmunix
text    data    bss     dec     hex
2545728 489552  639136  3674416 381130

(The alpha, like the mac, has no built in support for font
drawing, and may not even have a blitter!)

"that's a kernel that i'd want to run on a 4M machine!"

Saying "the other guys do it therefore it should be done" is not
a stunning argument.  However, doing it because the
other guys do it can lead to quite stunning results.

seriously: our system is a lot leaner and meaner than ANY
commercial UN*X-like OS that's currently being shipped that
i can think of, except possibly BSDI's.  That's _NOT_ a bad
thing.  If you'd like bloat, go run Slowlaris 2.x!

> Amiga comes with support hardware that knows how to do 80x24 support.
> Macintosh does not.  I have no idea how PMAX works but I wouldn't mind
> betting there is hardware in there.
>
> In fact, the Amiga's graphic heritage is why it has the text support built
> in.

"see above."

> And saying "the other guys don't do it therefore it shouldn't be done" is
> not a stunning argument.

No, in this case it's:
"it shouldn't be done, so the other guys don't do it!"

> Emacs would run within the console and would not need any special support
> so no, I would not put it in.  I have heard of people suggesting that it
> might be nice to consider though (probably more of the order of putting
> support for elisp into the kernel)

EVERYTHING YOU'VE SUGGESTED WILL RUN WITHIN A USER-LAND FRAMEWORK!
IT SHOULD NOT BE IN THE KERNEL.

> My point is that we do not need people wasting time hooking up control
> languages, macro facilities, etc to the menu inside a system console.
> 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.

Nope, just one program.  Honestly, before you suggest any more
"good little ideas", FIND OUT WHAT IT TAKES TO IMPLEMENT THEM!
Do you know what spitting screen image or text to disk entails?
They're _NOT_ things that you want done in the kernel!!!

the point is, THE CONSOLE SHOULD NOT EVER HAVE TO KNOW ABOUT
THE INTERNALS OF THE FILE SYSTEM.  THE CONSOLE SHOULD NEVER
HAVE TO KNOW ABOUT THE MOUSE.  THE CONSOLE SHOULD:
	(1) be able to deal with input typed at the keyboard, if
		there's one
	(2) be able to provide textual output to the screen(s),
		with a reasonable terminal emulation.
	(3) provide a memory mapped frame buffer, so that
		programs can do arbitrary graphics ops.

that's _IT_.  UN*X heritage has been "keep the kernel simple,
so that you can do it N ways from sunday in user-land."

> > Bzzt.  More work was done using VT100's than has probably ever
> > been done using macintoshes.  the VT100 has always been more
> > reliable than a macintosh...
> 
> Oh, ha ha!
> 
> More financial transactions have been performed with knots in a piece of
> rope than with a computer - therefore the piece of rope is better.
> 
> Wrong!

I didn't say "a vt100 is better than a macintosh."  I implied
that the people who designed the macintosh might have
learned a bit about modularity and simplicity from the vt100.

I know people who've worked at Apple, who have seen the work done
on porting "MacOS" to the PPC.  do you know how much code was
rewritten because it was completely incomprehensible any more?
MacOS is TOO COMPLEX a system, and was too unmaintainable.
The NetBSD kernel is _NOT_ going to be like that.

> > If you want a "real console," as you'd defined it, put it in
> > user-land.  period.
> 
> If this can be done, fine.

It can be done; X is proof of that.  Given what i've
said above, though, i think X is "stunning" proof of
that.  8-)

In other words, it can be done in user-land.  It can
be done there as easily and almost as efficiently as
in the kernel.

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

There is no such attitude.  However, when you've done
programming of various types on both UNIX and the Mac, you
get to see the flaws and the advantages of both designs.
The Mac has a nice user interface.  The drawback is that
that user interface is 100% at the core of, and can't
be seperated from, the rest of the system!

> All I 
> want is a console driver that actually provides me with access to 
> console functions! Instead I get a tirade about how "Amiga has better 
> graphics than Macintosh" and "If you don't like BSD, take it off your 
> disk" and "Unix has rules - you better like them".  Not to mention the 
> inspired "VT100 is more reliable that Macintosh".  I don't see these 
> as valid technical reasons; they are personal bias.  

That's all you want?  so what you want is a console driver
that just provides (1) and (3) above!  you don't even want
the text output, because the CONSOLE ON A MACINTOSH, as
you've said, doesn't support them!  Please, make up your
mind!

> I am not asking for a standard "APPLE/FILE/EDIT" menu.  I am not insisting
> that all console drivers for all variants of NetBSD go this way.  I don't
> see why this "stick-to-the-lowest-common-denominator" thinking has to stop
> this sort of development.  Being on the wrong side of the US-export laws
> means I can't offer any help in developing - the least I can do is suggest
> ideas and support those ideas that have been suggested.  Having everyone
> say "NO" always incites me to say "YES" when I don't believe adequate, valid,
> reasoning has been presented.

What you've said at various times in this thread indicates
that you want almost _exactly_ what you've claimed just
about to _not_ want.  "Access to console functions" on
a mac has _nothing_ to do with in-kernel menus, or hardware
scrolling, or anything of the sort!

The fact is, for systems that have more support, such as blit
chips, there are ioctls and interfaces to allow their use.
the mac has _NO_ such things, and so you shouldn't put goop
in the kernel to make it look like it does.  hell, macintoshes
don't even necessarily have mice, keyboards, or displays!

also, don't claim "wrong side of the laws" to keep from development!
if you wanted to grab 99% of the source code, just to look around,
and perhaps write a bit of code on your own, you could do so without
violating them.  There's also the fact that those export laws
look like they may be going down in flames, and there is _nothing_
keeping you from getting the binaries anyway... I'm aware
of exactly one ITAR/encryption-code violation that's had
anything done about it in recent memory, and that's the case
of Phil Zimmerman, for exporting PGP.  the 'crypt' code available
in NetBSD has been available outside of the US for _years_,
and is ftp-able from other places, too.  If the Mac files
were kept on sun-lamp, i know of a couple places outside
of the US that, by now, would have defied the export restrictions,
snarfed them, and put them up for FTP...

re: your insistence on saying "YES":
Before you ask for "adequate, valid, reasoning" from others,
i suggest that you inspect your own reasonsing for internal
consistency.  especially on this matter, it's been somewhat
lacking.  I would also suggest that you _look_into_ matters
before you start demanding things about them.  it gets rather
tiresome to have someone demanding that reasonable terminal
emulation (to run vi, etc.) be put in the console driver when
it's already there.  Similarly, it's annoying to have
someone say that it'd be fine to put features in user-land
if that's possible, but then continue to argue that those features
should be in the kernel, when not only _can_ they be put into
user-land, but they'd be easier to do if they were!



cgd

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