short answer: no. long(winded) answer: well, maybe. LCDs can suffer a "burn-in" effect of sorts, if a pixel is in the "on" (dark) state for a long period of time. LCDs work by applying an electric field to a liquid (the "liquid" in liquid crystal), which causes it to organize its internal structure (the "crystal" part). when the field is removed, the liquid "relaxes", and the pixel disappears. if the field is held on the liquid for a very long time, it's possible for the liquid to get kind of stuck in the organized state, and it won't relax into the disorganized state right away when the field is turned off. it's rare, but it does happen. if it happens to you, just leave the display off for a day or so. the vacation will help the pixel unwind. (no, I'm not making this up.) on some PDAs, the more fragile bit is the backlight. most pocketPCs use cold-cathode flourescent (CCFL) sidelights, but some inexpensive models use electroluminescent (EL) panels. EL panels are subject to wearing out with time, often in surprisingly little time (on the order of a couple years' use in some cases). CCFL sidelights can also wear out eventually, but they generally last a pretty long time.

um..."E, none of the above"? I've got a variety of metabolic-related problems, and the only thing that's managed to keep them under control is a ketogenic diet. so it's fiber, fat, and protein for me. no sugar, and as little starch as I can get away with (it pops up everywhere!). lots of water. I'm pretty careful about avoiding trans-fatty acids and nitrates/nitrites, and I take reasonable vitamin supplementation. so overall I'd say I eat more "healthy" than your average joe, and probably an order of magnitude or so better than your average coder. when I was much younger in school, my all-nighters were fueled with donuts and soda.

when I was learning C++, one line from a book stuck with me: "only friends can see your private members"

each of the monitors you want to drive needs to have a video source. that doesn't just mean some data (like a movie) that you want to display, it means a real live display controller. for most applications that means a VGA-style adapter (although there are other options). so if you want your box to run three different monitors, you need three video controllers, plain and simple. I realize that you *want* to be able to drive the video via some simple connection like USB, but it unfortunately doesn't work that way. you'd need to have a box at the other end of that USB with a display controller in it, that could read the data you send it and reconstruct the display for the monitor. the simplest device like that is a windows terminal, and you'd drive the display as if it were a separate windows session. given the cost and bulk of a windows terminal, you're better off using multiple video cards in your main PC, and running a separate video line to each monitor. if you have multiple video cards in your main PC, you can construct a desktop that "covers" all of them, and position a window on each monitor separately. I *think* that's what you're after.

I've worked with a few different (some would say bizarre) embedded controllers, including the ubicom SX series (don't get me started...). you'll find lots of "hobbyist" support for the PIC series of chips, and if you want to experiment with embedded "stuff" without getting too deeply into the details all at once, check out the basic stamp that will give you a lot of the features of the PIC with an easy programming language and a simple programming interface. I've recently started investigating the zilog Z8encore series, and the more I look, the more I like. they're cheap, relatively fast, vaguely familiar (based on the Z80 instruction set, which is distantly related to the x86 set), come with lots of on-chip goodies, and the developement system (chip, eval board with fancy doodads, in-circuit programmer, C compiler, debugger, and IDE) is going for around $40. that's just plain hard to beat.

funny...I'm doing something similar here right now (installing a "trampoline" server to assist in migrating the domain to 2K3 server). since all of our machines are "live" on the net, the sequence we have to do here is: 1) install the base OS (first phase) on the new machine 2) disconnect the WAN (leaving the LAN running), and install the network on the new machine 3) get a copy of the software firewall from the LAN 4) install and configure the software firewall 5) reconnect the WAN 6) run updates on the new machine until we succumb to fatigue if we don't do it this way, the machine will have been probed and infected by some random internet worm in the thirty seconds or so between installing the network support and beginning the update process.