Subject: Re: On the topline menu
To: Chris G. Demetriou <>
From: None <>
List: macbsd-general
Date: 06/20/1994 16:59:21
> "a piece of shit?"  i don't buy that.  I use "dumb" terminals almost
> every day, and they do what they do _very well_.

Really?  I haven't had to suffer through a real vt100 - you know, the 
standard one that doesn't have a "READ CURSOR" nor a "DELETE LINE", 
only four function buttons, etc for a long time I am spoiled by the 
workstation I have, I agree.

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.  

Sure, what they do, they do well.  What they don't do can be a pain.

> Ahh, but you're willing to pay other costs:
> 	(1) wired down kernel memory!  how many wired paged are you
> 		willing to waste when you're trying to compile
> 		something?  And when you're running X, this wired
> 		down code will be completely UNUSED!!!

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.

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

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

> If you want to improve the console interface, do so FROM A USER-LAND
> PROGRAM.  don't let your 'wants' dictate what _must_ be used by others
> who have no need for it.  UN*X has always been minimalist, and that's
> what makes it portable to machines like the macintosh.  IF YOU WANT

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

> > Quite frankly, the input from the PC camp (where the console driver is 
> > probably just using some 80x24 text-only mode) is not, imho, relevant.  
> BULLSHIT.  when you boot a UN*X clone, you're not running MacOS any
> more.  period.  You're running UNIX, which means that you play by
> UN*X's rules.  ....................................................

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.  

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.

> > The Mac comes with bitmapped display and nothing else - since it all 
> > has to be bitmapped anyway, I say add nicer features to it.
> The PMAX comes with a bitmapped display and nothing else.  You don't
> see it pulling "stupid console tricks."  same with the amiga, and
> hell, they've got one hell of a lot better graphics heritage then
> the mac does!

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

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

> > The only 
> > excuse I think is acceptable is memory-profile - don't waste my 
> > precious RAM sticking EMACS (for example) into the kernel.
> Even if somebody else out there wants to use emacs?  hell,
> emacs is a hell of a lot more useful than a menu bar is!

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)

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.

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


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

If this can be done, fine.

What is with this "Lets kick the Macintosh" attitude anyway?  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.  

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.

Jeff <>
'I meant,' said Ipslore bitterly, 'what is there in this world that makes living
worth while?'  Death thought about it.  CATS, he said eventually. CATS ARE NICE
	-- Sourcery (Terry Pratchett)