Re: vc scrollback

Linus Torvalds (Linus.Torvalds@cs.helsinki.fi)
Wed, 18 Oct 1995 07:58:27 +0200


[ This isn't actually a reply to this particular mail, it's just my
frustration with the whole thread. Ignore it ]

Achim Oppelt: "Re: vc scrollback" (Oct 17, 9:07):
>
> I agree that Linux's vc has its advantages over screen, but there are also
> things screen offers that Linux doesn't (longer scrollback, cut and paste
> without a mouse, saving screen contents to a file ... ).

As far as I'm concerned, this discussion is completely insane. Screen
has very few redeeming features as the general console interface, and a
screen-like approach has a _lot_ of problems, not the least of which is
that the kernel can't write to the screen directly when something bad
happens (or at least you couldn't scrollback that part even if screen
was working any more at that time).

In short, I find the current VC interface to be quite superior to any
other unix I have ever had the pleasure of working with, and screen
would only make it worse for no noticeable gain.

People who tout the great features of a microkernel approach in this
matter are quite free to write such a nice microkernel: linux currently
is not and has never been meant to be a microkernel (but as always, it's
GPL'd, so feel free...). My personal opinion on microkernels is that
they look a lot better in theory than they do in practice (*).

Linux is meant to be a pleasure to _use_, not necessarily a pleasure to
_discuss_.

Using (a possibly modified) screen interface for the console and going
for a simpler kernel driver would result in a larger memory footprint
overall, and _much_ worse performance.

So, if anybody really wants a screen interface to the kernel, I'd
suggest he/she disable the console driver althogether (that would
actually save some memory), put a dumb terminal on a serial line, and
run screen on that. That wouldn't detract from the pleasure of others
who actually like the current VC setup.

There are patches that make a serial line act as a console for the
kernel (including kernel panics etc), although I haven't integrated them
because they need to do some ugly thing when it comes to sending the
characters (ie busy looping).

Quite frankly, the _only_ good point of screen I can see in the modern
unix world is the ability to detach and re-attach a screen session, and
that is a completely separate thing from the actual console driver and
should be kept that way (it's a question of session management rather
than of device management - quite inherently different things).

> You should keep in
> mind that screen wasn't written as a replacement for the Linux console or any
> other virtual console system, but to give that functionality to people using
> e.g. VT100 terminals or dial-in connections. I spent half a year at a french
> university and the only computer access I had was through a VT100 connected to
> a DEC Alpha. Screen certainly made my life a lot easier there. I definitely
> don't think it's a joke.

Right. Screen has it's uses, but a console driver isn't that. The
world already has too many bad console drivers, let's not make linux
have one too.

Linus

(*) Lest this degrade into a microkernel war: there are valid points to
a microkernel, but the main point that is seldom brought up is probably
potential scalability in SMP (and perhaps particularly in more loosely
coupled systems). Personally I feel that very few of the other good
points of microkernels are likely yo be true (or particularly related to
MK's).