Non X console removal

[Nifty Fedora Mitch]

On Mon, Sep 15, 2008 at 11:56:21AM -0400, Alan Cox wrote:
> On Mon, Sep 15, 2008 at 11:37:16AM -0400, Matthias Clasen wrote:
> > Colin merely stated his opinion (which is widely shared) that the vt
> > subsystem is one of the most horrible kernel subsystems, api-wise and
> > otherwise, and the world would be a better place without it. 
> 
> Let me explain as tty layer maintainer exactly how many emails I've had from
> Red Hat employees or Fedora developers wanting to discuss the VT consoles
> 
> - One - and that was about saving fonts over a hibernate.
> 
> You actually need the vt layer for a few things
> - boot up
> - a way to cope when X breaks again (most updates on some boxes)
> - a way to undo things when selinux screws up on a package update and breaks
>   pam
> - a way for end users to be guided for debugging problems
> - a way to reliably see kernel messages
> 
> Longer term the last one should go away, but the others won't.
> 
> Users don't need to know about the VT consoles unless it breaks and there is no
> reason to fire up more than a single console I suspect, but you do need the one
> hidden console somewhere for the user to be able to reach when stuff breaks.
> 
> Now as the API - it has interesting design features that go back ten years to
> a different model of usage. Right now that code is all getting revamped, fine
> grain locked and tidied so now is a very good time for the distro folks to
> produce and send out a "What we hate about the console and how we think it
> could be addressed" email...
 
It seems to me that there are three display topics....
	- physical serial terminal (hmmm... bidirectional modems -- skip them for now)
	- virtual console Control-Alt-F[1234..]
	- X (with a list of window managers and desktop features...)

As long as all three are live it makes sense to address the cruft 
and revise/ recode (one at a time) the most difficult to maintain.
In some cases difficult code that works is easy to maintain....  

Each has a real and valuable place in the system so while revision
of any one may make sense -- elimination does not.

Some old timers may recall the terminal IOCTL race where emacs users would 
open a file and Ctl^S to search in it.  Fast typers would trigger
Ctl^S stop and the terminal would lock because a moment later the terminal
now locked would see the IOCTl to place it in raw mode.   With a second
terminal or a network login a user could issue commands to reset the locked
line...   Issues like this bug are structural design problems
that I suspect are the class of design issues open to discussion.

So the compliment of "what we hate" what I would like is
	two configured active terminals... with the ability to configure more 
		I seem to limit out at three or four... with the aid
		of job control and emacs more than two is a lot.

	I do like the ability to use a mouse on a virtual console -- but can live without it.
	Fonts on virtual consoles are less than ideal but work fine enough.

	Sleep and hibernate for laptops is important... If there are
	virtual console issues it may make sense log out or turn off 
	virtual console activity on laptops if X works fine enough.....

What I find interesting is just how complex this topic is and how
little I know about it all.


-- 
	T o m  M i t c h e l l 
	Found me a new hat, now what?