For many of us, E-mail has become our most fundamental tool. It is not just the way we communicate with friends and colleagues, it is the way that a large chunk of the tasks on our "to do" lists and calendars arrive. Of course, many E-mail programs like Outlook come integrated with a calendar program and a to-do list, but the integration is marginal at best. (Integration with the contact manager/address book is usually the top priority.)

Here's a new approach to linux adoption. Create a linux distro which converts a Windows machine to linux, marketed as a way to solve many of your virus/malware/phishing woes.

Yes, for a long time linux distros have installed themselves on top of a windows machine dual-boot. And there are distros that can run in a VM on windows, or look windows like, but here's a set of steps to go much further, thanks to how cheap disk space is today.

• Yes, the distro keeps the Windows install around dual boot, but it also builds a virtual machine so it can be run under linux. Of course hardware drivers differ when running under a VM, so this is non-trivial, and Windows XP and later will claim they are stolen if they wake up in different hardware. You may have to call Microsoft, which they may eventually try to stop.
• Look through the Windows copy and see what apps are installed. For apps that migrate well to linux, either because they have equivalents or run at silver or gold level under Wine, move them into linux. Extract their settings and files and move those into the linux environment. Of course this is easiest to do when you have something like Firefox as the browser, but IE settings and bookmarks can also be imported.
• Examine the windows registry for other OS settings, desktop behaviours etc. Import them into a windows-like linux desktop. Ideally when it boots up, the user will see it looking and feeling a lot like their windows environment.
• Using remote window protocols, it's possible to run windows programs in a virtual machine with their window on the X desktop. Try this for some apps, though understand some things like inter-program communication may not do as well.
• Next, offer programs directly in the virtual machine as another desktop. Put the windows programs on the windows-like "start" menu, but have them fire up the program in the virtual machine, or possibly even fire up the VM as needed. Again, memory is getting very cheap.
• Strongly encourage the Windows VM be operated in a checkpointing manner, where it is regularly reverted to a base state, if this is possible.
• The linux box, sitting outside the windows VM, can examine its TCP traffic to check for possible infections or strange traffic to unusual sites. A database like the siteadvisor one can help spot these unusual things, and encourage restoring the windows box back to a safe checkpoint.

The use of virtual machines is getting very popular in the web hosting world. Particularly exciting to many people is Amazon.com's EC2 -- which means Elastic Compute Cloud. It's a large pool of virtual machines that you can rent by the hour. I know people planning on basing whole companies on this system, because they can build an application that scales up by adding more virtual machines on demand. It's decently priced and a lot cheaper than building it yourself in most cases.

In many ways, something like EC2 would be great for all those web sites which deal with the "slashdot" effect. I hope to see web hosters, servers and web applications just naturally allow scaling through the addition of extra machines. This typically means either some round-robin-DNS, or a master server that does redirects to a pool of servers, or a master cache that processes the data from a pool of servers, or a few other methods. Dealing with persistent state that can't be kept in cookies requires a shared database among all the servers, which may make the database the limiting factor. Rumours suggest Amazon will release an SQL interface to their internal storage system which presumably is highly scalable, solving that problem.

As noted, this would be great for small to medium web sites. They can mostly run on a single server, but if they ever see a giant burst of traffic, for example by being linked to from a highly popular site, they can in minutes bring up extra servers to share the load. I've suggested this approach for the Battlestar Galactica Wiki I've been using -- normally their load is modest, but while the show is on, each week, predictably, they get such a huge load of traffic when the show actually airs that they have to lock the wiki down. They have tried to solve this the old fashioned way -- buying bigger servers -- but that's a waste when they really just need one day a week, 22 weeks a year, of high capacity.

However, I digress. What I really want to talk about is using such systems to get access to all sorts of platforms. As I've noted before, linux is a huge mishmash of platforms. There are many revisions of Ubuntu, Fedora, SuSE, Debian, Gentoo and many others out there. Not just the current release, but all the past releases, in both stable, testing and unstable branches. On top of that there are many versions of the BSD variants.

Most of us, when we travel, put appointments we will have while on the road into our calendars. And we usually enter them in local time. ie. if I have a 1pm appointment in New York, I set it for 1pm not 10am in my Pacific home time zone. While some calendar programs let you specify the time zone for an event, most people don't, and many people also don't change the time zone when they cross a border, at least not right away.

Radio technology has advanced greatly in the last several years, and will advance more. When the FCC opened up the small "useless" band where microwave ovens operate to unlicenced use, it generated the greatest period of innovation in the history of radio. As my friend David Reed often points out, radio waves don't interfere with one another out in the ether. Interference only happens at a receiver, usually due to bad design. I'm going to steal several of David's ideas here and agree with him that a powerful agency founded on the idea that we absolutely must prevent interference is a bad idea.

My overly simple summary of a replacement regime is just this, "Don't be selfish." More broadly, this means, "don't use more spectrum than you need," both at the transmitting and receiving end. I think we could replace the FCC with a court that adjudicates problems of alleged interference. This special court would decide which party was being more selfish, and tell them to mend their ways. Unlike past regimes, the part 15 lesson suggests that sometimes it is the receiver who is being more spectrum selfish.

Here are some examples of using more spectrum than you need:

• Using radio when you could have readily used wires, particularly the internet. This includes mixed mode operations where you need radio at the endpoints, but could have used it just to reach wired nodes that did the long haul over wires.
• Using any more power than you need to reliably reach your receiver. Endpoints should talk back if they can, over wires or radio, so you know how much power you need to reach them.
• Using an omni antenna when you could have used a directional one.
• Using the wrong band -- for example using a band that bounces and goes long distance when you had only short-distance, line of sight needs.
• Using old technology -- for example not frequency hopping to share spectrum when you could have.
• Not being dynamic -- if two transmitters who can't otherwise avoid interfering exist, they should figure out how one of them will fairly switch to a different frequency (if hopping isn't enough.)

As noted, some of these rules apply to the receiver, not just the transmitter. If a receiver uses an omni antenna when they could be directional, they will lose a claim of interference unless the transmitter is also being very selfish. If a receiver isn't smart enough to frequency hop, or tell its transmitter what band or power to use, it could lose.

Since some noise is expected not just from smart transmitters, but from the real world and its ancient devices (microwave ovens included) receivers should be expected to tolerate a little interference. If they're hypersensitive to interference and don't have a good reason for it, it's their fault, not necessarily the source's.

A recent Forbes items pointed to my earlier posts on eBay Feedback so I thought it was time to update them. Note also the eBay tag for all posts on eBay including comments on the new non-feedback rules.

I've thought digital picture frames were a nice idea for a while, but have not yet bought one. The early generation were vastly overpriced, and the current cheaper generation still typically only offer 640x480 resolution. I spend a lot to produce quality, high-res photography, and while even a megapixel frame would be showing only a small part of my available resolution, 1/4 megapixel is just ridiculous.

I've been writing recently about the linux upgrade nightmares that continue to trouble the world. The next in my series of ideas is a suggestion that we try to measure how well upgrades go, and make a database of results available.

I've spoken before about ZUI (Zero User Interface) and how often it's the right interface.

One important system that often has too complex a UI is backup. Because of that, backups often don't get done. In particular offsite backups, which are the only way to deal with fire and similar catastrophe.

Here's a rough design for a ZUI offsite backup. The only UI at a basic level is just installing and enabling it -- and choosing a good password (that's not quite zero UI but it's pretty limited.)

Everybody's pulling out IBM PC stories on the 25th anniversary so I thought I would relate mine. I had been an active developer as a teen for the 6502 world -- Commodore Pet, Apple ][, Atari 800 and the like, and sold my first game to Personal Software Inc. back in 1979. PSI was just starting out, but the founders hired me on as their first employee to do more programming. The company became famous shortly thereafter by publishing VisiCalc, which was the first serious PC application, and the program that helped make Apple as a computer company outside the hobby market.

Yesterday I received a Dell 3007WFP panel display. The price hurt ($1600 on eBay, $2200 from Dell but sometimes there are coupons) and you need a new video card (and to top it off, 90% of the capable video cards are PCI-e and may mean a new motherboard) but there is quite a jump by moving to this 2560 x 1600 (4.1 megapixel) display if you are a digital photographer. This is a very similar panel to Apple's Cinema, but a fair bit cheaper.

It can be very frustrating when a PC decides to send a signal to a monitor that is outside its scan range. Yes, the systems try hard to avoid it, via things like plug and play EDID information on monitor specs, and reverting changes to monitor settings if you don't confirm them after a few seconds, but sometimes it still happens. It happens after monitor swap, it happens if you don't have a monitor turned on when you boot or if you have KVM switch that doesn't talk about the monitor.

Ok, so there's a million things to fix about eBay, and as I noted before my top beef is the now-common practice of immense shipping charges and below-cost prices for products -- making it now impossible to search by price because the listed price is getting less relevant.

I've been playing with various calendar systems, such as Mozilla calendar, Korganizer, Google Calendar, Chandler and a few others, and I'm finding them wanting. I have not used iCal or Outlook so perhaps they solve all my problems, but I doubt they do.

I see two ways to want to merge in additional calendars, neither of which is supported very well.

I get a lot of party invites by Evite, and it's very frustrating. I've missed some events because they refuse to improve their interface.

When I get event invites, I save them to a mail folder. Then I can browse the mail folder later to check dates. If I am not in front of my calendar (which alas is not available everywhere) I can go back and enter items I save.

Most people use wireless access points to provide access to the internet, of course, but often there are situations where you can't get access, or access fast enough to be meaningful. (ie. a dialup connection quickly gets overloaded with all but the lightest activity.)

I've blogged several times before about my desire for universal DC power -- ideally with smart power, but even standardized power supplies would be a start.

GPS receivers with bluetooth are growing in popularity, and it makes sense. I want my digital camera to have bluetooth as well so it can record where each picture is taken.

But as I was drivng from the airport last night, I realized that my cell phone has location awareness in it (for dialing 911 and location aware apps) and my laptop has bluetooth in it, and mapping software if connected to a GPS -- so why couldn't my cell phone be talking to my laptop to give it my location for the mapping software? Or ideed, why won't it tell a digital camera that info as well?

Very technical post here. Among the children of Unix (Linux/BSDs/MacOS) there is a convention that for a program to open a TCP or UDP port from 0 to 1023, it must have superuser permission. The idea is that these ports are privileged, and you don't want just any random program taking control of such a port and pretending to be (or blocking out) a system service like Email or DNS or the web.

This makes sense, but the result is that all programs that provide such services have to start their lives as the all-powerful superuser, which is a security threat of its own. Many programs get superuser powers just so they can open their network port and, and then discard the powers. This is not good security design.

While capability-based-security (where the dispatcher that runs programs gives them capability handles for all the activities they need to do) would be much better, that's not an option here yet.

I propose a simple ability to "chown" ports (ie. give ownership and control like a file) to specific Unix users or groups. For example, if there is a "named" user that manages the DNS name daemon, give ownership of the DNS port (53) to that user. Then a program running as that user could open that port, and nobody else except root (superuser) could do so. You could also open some ports to any user, if you wanted.

The phone companies failed at the fiber to the curb promise in most of the USA and many other places. (I have had fiber to the curb at my house since 1992 but all it provides is Comcast cable.)