Coding Horror

Microsoft's Remote Desktop is incredibly convenient. It's the next best thing to physically being in front of the target computer-- and it's by far the fastest remoting protocol I've ever used. Over a fast network, you can almost convince yourself that you're using the local machine. Remote desktop is great stuff, and it's basically free. It does have a few annoying limitations, though:

1. it insists on treating every remote login as a separate user session. Except in the special case where you log into your own session.
2. it can't handle multiple monitors in any way; you'll only see the primary monitor. Fortunately, UltraMon has a convenient one-click taskbar enable/disable function for the alternate monitors. It even remembers the position of windows when moving them back.
3. in fine Microsoft tradition, it's intentionally crippled. You can only have one active Remote Desktop session under XP, and two sessions under Windows 2003/2000 server. I suppose this is to keep us from setting up our own OS/360 timeshare boxes.

Point #1 is in stark contrast to "old school" remoting programs such as pcAnywhere and Carbon Copy, which simply displayed whatever happened to be on the client's screen-- sort of like virtual video adapters. Sometimes, this is what you want. And in those situations, you want TightVNC. VNC follows the older model of simply showing whatever is on the screen with no forced logins required. Of course, this has security implications; if you remote into a machine that an Administrator is logged into, you'll effectively be an Administrator. And if you're both trying to use the computer at the same time, it's even more fun!

VNC has been around for years in various incarnations; what makes TightVNC so useful is that it's free, natch, but more importantly, it implements a video hook driver. One of the long-running historical weaknesses of the VNC protocol was that it didn't interface at the video driver level with Windows; it had to poll for screen changes. This works, and it's a very cross-platform approach, but it's also hellaciously inefficient and highly CPU intensive. Why poll for changes when the video driver can tell you what the changes were? When you download TightVNC, be sure to download the "developmental" version (at the time of writing, 1.3d7) and the dfrimage.zip video hook driver.

Even with this hook driver, it isn't as fast as Remote Desktop, but it's at least in the ballpark. If you ever used VNC in the past and were disappointed with how slow and CPU intensive it was, you should try again with TightVNC and the video hook driver. There's a world of difference.

If you're feeling really adventurous, there's even an open-source C# VNC client. TightVNC implements a few specially optimized protocols of its own, but it does support the "classic" VNC protocols as well. I was able to remote into a TightVNC server using this C# client.

Unfortunately, neither Remote Desktop nor VNC does a good job of handling multiple monitors on the target machine, so that's a wash. You'll get the primary monitor, and you'll like it. There is some support for multimon in the latest versions of pcAnywhere, as this review at RealTimeSoft points out.

Note that a few key sequences, such as CTRL+ALT+DEL, can't be intercepted by any remote desktop client, even in fullscreen mode. There's a handy list of keyboard shortcuts for the Remote Desktop key equivalents in the online XP resource kit.

Incidentally, there are hardware-level remote desktop solutions which are capable of remotely displaying BIOS setup screens-- even the Blue Screen o' Death! Pretty gnarly stuff.

I recently purchased the DGL-4300 wireless router, mainly because it includes gigabit ethernet, which is still quite rare in routers. It certainly looks cool, as routers go, with its sleek rubbery design and all-blue LEDs. But those blue LEDs-- particularly a bank of them, all blinking away-- are blindingly bright! They're actually painful to look at, which is sort of ironic considering they are status and activity LEDs.

Evidently, this is a known issue with blue LEDs:

Blue LEDs really are brighter than their old-fashioned red and green counterparts. Barney O'Meara, vice president of Canadian LED manufacturer The Fox Group, said blue LEDs have at least 20 times the luminous intensity of old-fashioned red and green indicators. O'Meara said his company has developed technology to manufacture low-intensity blue LEDs.

"Blue tends to cause more discomfort and disability glare than other, longer wavelengths," said Dr. David Sliney, an expert on the harmful effects of bright light sources at the U.S. Army Center for Health Promotion and Preventive Medicine in Maryland. Sliney said the eye's lens cannot focus sharply on the blue lights. While red or green light is focused precisely onto the retina, blue light is focused slightly in front of it, which causes a distracting halo around bright blue lights.

In addition, blue scatters more widely than other colors as it passes through the eyeball, Sliney said. Together, these two effects cause the intense blue light from a point source, like an LED, to spread out across the retina, interfering with other parts of the scene. It's called dispersion: Blue's shorter wavelength makes it refract at a greater angle than, say, red or green.

Also, human vision becomes far more sensitive to blue when ambient light levels are low, a phenomenon known as the Purkinje shift. So a blue light that is merely eye-catching on a brightly lit store shelf can become dazzling when the lights are low, such as when watching a movie on a laptop in a dimly lit room.

Some researchers report that, at night, even low-level blue light may be enough to trigger recently discovered receptors in the retina that can depress melatonin production, disrupt sleep patterns and suppress the immune system.

If there's a bright blue LED in your field of view, your only recourse may be "painting" it with a permanent black magic marker. My room is dimly lit now, and if I glance over to the router, it's like getting tiny little blue LED punji sticks right in the eye. And I wear glasses, which doesn't help, either. Blue LEDs may look cool, but for actual functional use, give me green or red LEDs any day.

Blue LEDs weren't even commercially viable until the mid 1990's, largely thanks to the research of one Shuji Nakamura:

I kept at it, but I was dispirited. For ten years I had worked very hard to make these products. I worked twelve hours a day, seven days a week, except holidays. I had a very, very small budget and had to make everything I needed myself. I even made my own reactors -- the furnaces needed to do the crystal work. The commercial reactors were too expensive. I made three products all by myself, and still my salary and position were not good at the company. My bosses always complained that my results were terrible, because I spent a lot of money, as far as they were concerned, and nothing sold. But for ten years I had been working to make these LED materials and I knew at the time there were no high-brightness blue LEDs. For LED researchers, this was a dream. But my bosses said it would be impossible to create a blue LED at Nichia, because many big companies and many research teams in big universities were trying to do it and were failing.

Except for the blue LED problem, I give the DGL-4300 router a big thumbs up. The Quality of Service (QoS) feature they call "GamerFuel" really works. I can download stuff in BitTorrent while playing Battlefield 2 with hardly any impact on my ping in the game.

Wil Shipley, the entity behind Delicious Library, has a hilarious (and informative) talk on why he develops software for the Mac-- and also netted $54,000 from Delicious Library on the first day with zero advertising.

How to Succeed Writing Mac Software (176kb PDF)

One of the funniest and most oddly inspiring things I've read in a long time. Highly recommended.

(via Steve Makofsky)

I've seen a number of hardware-oriented developers talk about setting up striped RAID arrays on their personal desktops. It does seem like a reasonable idea, given the current strong trend towards "doubling up" on hardware to leverage performance benefits from parallelism in various forms-- dual core CPUs, dual channel DDR, dual graphics cards in SLI, and dual hard drives in RAID 0.

However, except for dual channel memory, none of these parallel hardware approaches are clear across-the-board performance wins. They can be twice as fast in very specific circumstances, but as a general rule they're just somewhat faster, and not without adding significant costs and even risks of their own.

RAID 0 (aka striping) on the desktop, is especially dubious in my opinion. Just because current motherboard chipsets now make it easy and (relatively) inexpensive to do this doesn't mean that you should:

1. RAID 0 literally doubles your chance of drive failure. All it takes is a single drive failure on either drive to render your striped array completely and utterly unrecoverable. A "normal" single drive failure is at least theoretically recoverable, albeit expensive. How expensive? If you have to ask, you probably can't afford it.
2. Of all the hardware failures you can have, drive failure is by far the most traumatic. Losing a CPU, video card, or even motherboard, means you just go out and buy another one. Losing a drive means you've probably lost your critical data, unless you have a good backup regimen in place. And 99% of us don't. Kudos to the 1% of you reading this who do.
3. The performance benefits of RAID 0 aren't that compelling for typical desktop usage scenarios.

So why would you go to the trouble of building a RAID 0 array if it's more expensive, more complex, prone to failure, and not all that much faster? Short answer: you probably shouldn't, unless you know you have a specific scenario that justifies this setup. There are a number of articles on the web that debunk the myth that RAID 0 is a universal performance improvement for a typical desktop PC:

• Western Digital's Raptors in RAID-0: Are two drives better than one?
• Chipset Serial ATA and RAID performance comparison
• TCQ, RAID, SCSI, and SATA

All these articles are variations on the same theme; the AnandTech article summarizes nicely:

If you haven't gotten the hint by now, we'll spell it out for you: there is no place and no need for a RAID-0 array on a desktop computer. The real world performance increases are negligible at best and the reduction in reliability, thanks to a halving of the mean time between failure, makes RAID-0 far from worth it on the desktop.

There are some exceptions, especially if you are running a particular application that itself benefits considerably from a striped array, and obviously, our comments do not apply to server-class IO of any sort. But for the vast majority of desktop users and gamers alike, save your money and stay away from RAID-0.

The original hard drive benchmark review website, storagereview.com, offers this guidance:

The enthusiasm of the power user community combined with the marketing apparatus of firms catering to such crowds has led to an extraordinarily erroneous belief that striping data across two or more drives yields significant performance benefits for the majority of non-server uses. This could not be farther from the truth! Non-server use, even in heavy multitasking situations, generates lower-depth, highly-localized access patterns where read-ahead and write-back strategies dominate. Theory has told those willing to listen that striping does not yield significant performance benefits. Some time ago, a controlled, empirical test backed what theory suggested. Doubts still lingered- irrationally, many believed that results would somehow be different if the array was based off of an SATA or SCSI interface. As shown above, the results are the same. Save your time, money and data- leave RAID for the servers!

If you have your heart set on RAID 0, go for it. It won't hurt performance. But be sure you're making an informed decision. There's a lot to be said for simplicity.

Windows XP isn't known for its powerful command line interface. Still, one of the first things I do on any fresh Windows install is set up the "Open Command Window Here" right click menu. And hoary old cmd.exe does have a few tricks up its sleeve that you may not know about.

The first thing you'll want to do is Start, Run, cmd.exe, then right click the window menu and choose properties. Be sure to enable the following quality of life improvements:

• Options | Command History | Buffer Size | 500
• Options | Command History | Discard Old Duplicates | True
• Options | Edit Options | QuickEdit Mode | True
• Layout | Screen buffer size | Height | 999
• Layout | Window size | Height | 50

Now we've got some room to actually see stuff! QuickEdit mode enables copying from the command prompt by intuitively dragging and right clicking with the mouse. Furthermore, you can paste what's in the clipboard to the command line by right clicking with nothing selected.

And of course, set the font and colors to taste. I use green-screen style colors (background 0 55 0, foreground 0 255 0) with Lucida Console as pictured above. But if you prefer Comic Sans here, be my guest! When exiting this dialog, you'll be prompted to save. Make sure you select "Save properties for future windows with same title" so all future command prompts will benefit from these improved settings.

There are also a few helpful keyboard shortcuts that aren't always widely known:

• Pressing arrow up selects a previous command from your command history; similarly, arrow down selects the next command.
• Pressing F7 pops up your command history list.
• You can drag n' drop files or folders from an explorer window into a command prompt; this inserts the quoted path as if you had manually pasted it.
• Tab completion is fully supported; type edit *.ini then hit TAB to iterate through all matches. Use SHIFT+TAB to move to the previous match. This works for partial filenames as you would expect, and in all commands.
• Tired of the typical "c:windowssystem32cmd.exe" window title? Change it using the TITLE command.
• ALT+ENTER takes your command prompt to fullscreen mode and back again.

If you're really a hard-core cmd.exe junkie (or maybe a UNIX user), you may want to look into the 4nt command shell replacement. It's a direct descendant of the venerable 4dos shell.