Re: vc scrollback

cjs (
Wed, 18 Oct 1995 14:25:43 -0700 (PDT)

> [ 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 (*).

Point!! I love reading through the stuff from CMU. It starts out with
something along the lines of "Wooho!! We implemented a micro kernel!
We're so hip! We're so with it!" followed by dozens, if not hundreds,
of papers saying "Thanks to our skill at opimizing C code and
algorithms, we *almost* have Mach running as fast as a traditional
kernel!" And the funny part about it, is that their improvements would
probably have just as much effect on a traditional kernel as a micro
kernel. I really don't see any benefit whatsoever to having a
microkernel, other then it'll get you a higher grade in Andrew
Tandbaumn's CS class. ;)

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

At least until you get the latest binutils and discover that they
removed support for library revision numbers because noone could agree
on how to assign version numbers.

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


Who started this thread anyway?