Hey, > A while ago Ben Calvert tapped:
> On Thu, 7 Dec 2006 08:14:50 +0900 > Simon Fryer <[EMAIL PROTECTED]> wrote: > > > > A while ago Ben Calvert tapped: > > > > [slow console on imac 333Mhz] > > > > > look at /etc/ttys. you'll notice the following: > > > > > > ttyC0 "/usr/libexec/getty std.9600" vt220 off secure > > > ttyp0 none network > > > > > > > > > the 9600 is the speed that data gets written to your console > > > ( ttyc0 ). Notice that ttyp* (xterms, remote ssh sessions ) have no > > > such restriction? > > > > Um, to my knowledge this disagrees with the /etc/ttys on my 3.9 i386 > > box. > > > > The argument "std.9600" tells getty to set the serial port to 9600 > > baud, which is only relavent if you are using a serial console. > > Hmm.. so then, what's this line for? > console "/usr/libexec/getty std.57600" unknown off secure # for serial The console device. Not all people have the console as the local frame buffer. It seems perfectly possable on OpenBSD i386 at least to have the console set to a serial port and still log in and run a shell using a locally connected monitor and keyboard. The console can be the local frame buffer, or it can be a serial device depening on platform, configuration and machine. /etc/ttys goes back a long way in BSD history. On a number of systems, having the console not marked as secure will prevent the system from being booted single user, or at least that was the intent. Having a terminal line marked as insecure also prevented root from being able to log in. However, in some situatons, it was desirable to not be able to boot single user, but be able to log in as root - acheived by having the console set as insecure and off, while the corresponding serial line is set "on secure". > > I am ignoring the fact that in the example /etc/ttys, getty on ttyC0 > > does not get executed. > > correct - i'm running xdm, so i disable the ttyC0 > > > The real reason was given by an earlier message. > > Well, IANA(obsd)D, and IANTdR, so I'm hesitant to clam that I have > access to the 'real' reason. > > but let me propose the following experiment: > > run an output intensive task on the console, then run X in wsfb mode, > and run the same task in an xterm. > > compare the execution times. > > I bet you'll find that running the same app in an xterm -- using the > same framebuffer -- is much faster than on the console. Yes. Have done this many times on Sun3 and Sun4 machines... Doing anything that had a lot of text output on the console often met with some frustration. It is not the same software updating the screen in the xterm and when using the local frame buffer to generate text. On some platforms, the method of updating the framebuffer for text only is just, slow. Simon -- ------------------------------------------------------------------------ "Well, an engineer is not concerned with the truth; that is left to philosophers and theologians: the prime concern of an engineer is the utility of the final product." Lectures on the Electrical Properties of Materials, L.Solymar, D.Walsh
