On Mon, Dec 29, 2003 at 04:06:33PM -0500, Thomas Dickey wrote: > On Mon, 29 Dec 2003, David Yitzchak Cohen wrote: > > > it's an inexpensive setup & works with my network > > > > Mutt's also fairly inexpensive, no? > > not the point: works with my network. Outlook doesn't work with your network? > > > I haven't used a real tty for 4-5 years. (The various console emulators > > > are no more real than xterm). > > > > The Linux VTs are far more real than an xterm, in the sense that they're > > not nearly as far removed from the real thing. > > not really - they're programs that paint on the same piece of glass. Ah, but consider the levels of abstraction each one faces. When we're working in plain text mode, the VGA memory contains the actual characters on the screen. That is, communication right up to the "final mile" (essentially, the monitor cable plus a small bit of your graphics hardware) is done in plain text, just as in a real terminal. As soon as you start having "virtual monitors" (a.k.a. windows) implemented in software, the location of text->graphics conversion is moved up considerably in the chain of communiction. A quick glance at your VGA memory will readily indicate that fact. Why's that important, you ask? Well, let's say you had some cool font utility that ran on your graphics card, presumably to convert text into some really nifty cursive (fixed-width, of course) or something. If you ran your apps in the console, you'd be able to take advantage of your new utility without your graphics hardware having to do OCR on your image of the text (which would be rather silly, considering the fact that it _was_ text before, in your very same computer - whatever happened to cooperation?). Other annoyances with xterms have to do with the fact that sofware now has to perform the text->graphics conversion that's normally handled quite nicely by the graphics hardware. That in itself requires your software to make all sorts of assumptions about the appearance of the real terminal it's emulating. (Notice, the same fundamental difference generates two different problems: you first have to figure out how to convert text->graphics, and then you need to figure out a way to convert graphics->text, which can potentially be extremely difficult, since the absolute position on the screen of any given ANSI position on any given xterm may or may not be the top left of the screen, or may not even exist if that part of the xterm is covered, or may only partially exist (try OCRing THAT) if that part of the xterm is partially covered.) The net result is that anything that's going to view/modify the running program's output absolutely needs to run between the xterm and the program. (For instance, the equivalent of /dev/vcs* would have to be provided by the xterm itself (or by an instance of GNU Screen running on top of all other programs in the xterm), which may not have write access to /dev/ (unless your screen is suid/sgid, which comes with its own baggage).) Now, whether or not these (or other) issues really matter to any given user is a matter of personal choice (that is, how you use your computer dictates which capabilities are missed and which ones aren't), but there's no question here that the xterm approach displaces the text->graphics conversion from the graphics hardware (its historical location) to software, hence it's said to be "emulating" the conversion. - Dave -- Uncle Cosmo, why do they call this a word processor? It's simple, Skyler. You've seen what food processors do to food, right? Please visit this link: http://rotter.net/israel
Attachment:
pgpIOkxsHoIBw.pgp
Description: PGP signature