It seems this comparison would be much more interesting if it were based on dollars and not units. This article makes as much sense as saying "the sale of toothpicks is outpacing chopsticks". BTW, I don't plan on doing any of my software development on my Android phone since my current seven virtual desktops is hardly enough real estate to do my work.

Normally the migration from optional to required is much more gradual, methodic and covert; more like behavioral modification. We all knew that when the stories of these first came out and they were sold as optional, but you knew the plan. I am just amazed at the speed and blatant progression.

Here is a solution I have not heard yet: quid pro quo. A passenger (victim) should be able to choose their TSA pat-down agent (assailant) and the passenger should be able to pat-down the TSA agent to the same extent. I am sure the agent selection would be just as random as the TSA passenger selection, with absolutely no profiling.

Can you imagine the liability the city has opened themselves up to? This would be an entirely different story if there was a clerical mistake. If he really wanted to get the fire put out, he should have called and said he paid the bill. At that moment, they couldn't dispute it, no matter how good they thought their accounting was, they would have had no choice but to show up and put it out. If there was a check postmarked the day prior that appeared in their mailbox, they would be screwed! "I paid that on Monday!"

Yes, what do people think the word insurance means? It is like getting a health insurance policy after you are already sick, with like a pre-existing condition, and still expecting to get coverage... oh wait... nevermind

Duh! Just ask any Johovah's Witness and they will tell that it is 144,000. If you want it in writing, see the Bible verse Revelation 14:1.

Look. I had problems reading his 3D message too, but all I had to do was cover one eye.

From experience, the steeper the ridges the greater the impact. My old partner picked me up at my local airstrip in a Piper Tri Pacer (a lighter, tube and fabric airplane). We had to climb and then cross perpendicular to the ridge line, the least you can do to avoid the well known affects of a hill that rises 1000' in less than a mile. Even though we had at least 500' above the ridge, it was a bumpy ride. And when we were well past ridge face, it tipped us really hard and really fast! Thank god for padded radio headsets! It tipped us past 45 degrees in a fraction of second, with the window hitting my head and rang my bell some.

Very cool device! It does lack in accuracy. Pitted dice are off balance and the 1 will land on the bottom more often than not. That is why Vegas does not use that type of die. There is error in the machine; look closely at the video where the dice get stuck at the top.

Ah. But they were. The list was meant to highlight the milestones in the historical pendulum swing. The first web browsers were definitely dumb terminals. Dumb terminals, in the before time, used special characters in the data stream, often called Field Attribute Characters or FACs, that would signal whether or not the following characters were a data entry field, or highlighted and/or blinking text (showing my age here). The browser protocol just replaced these with verbose HTML tags (which provided only slightly more flexibility).

Add-ons are just hacks. I know that sounds bad or derogatory, but it is true. They are features the original browser designers had never imagined. Browsers are evolving, which is good, but they are way beyond their original intent and struggle to find common ground. But this goes to my case in point. As they evolve, with add-ons, to make up for what the core lacks, you are moving the pendulum back to client-side processing. You are migrating activities from the server to the client. Your client is getting fatter (richer). Why? Is the server overloaded? Bandwidth? More likely, it is to fill the gap in usefulness, by reducing the server round-trip response times.

Browser applications with add-ons are evolving to replicate the same immediacy and usefulness that we had 20 years ago with LAN-based enterprise applications. We grew fat and happy with 10Mbps of bandwidth on the LAN. And of course, eventually 10Mbps wasn't enough, many applications grew to need 100Mbps to handle client traffic. Gigabit anyone? We had to retreat to dumb terminals (browsers) to deal with the limited Internet bandwidth, which is exactly why terminals were dumb years ago, when the LAN cabling was coaxial (or twin-axial).

Remember, at the dawn of the Internet era, most people had only a 23Kbps modem. Most pages were sparse and you had to click on a link to a picture if you wanted to view it, ...and wait. Therefore, the concept of HTML was nothing new, it was just a luxury that we had enough bandwidth that we could send verbose formatting, whereas before we used terminal protocols to format text responses. But of course now we have so much bandwidth, we can assemble fancy pages with ample pictures and even video content (with required add-on of course).

Why struggle with a browser to build an add-on to do your client work? Why not just build a rich client that communicates directly with the server and does exactly what you need? Lean and mean custom protocol for massive speed! It will do whatever you want and not contend with browser deficiencies and incompatibilities? Of course, this is in the context of an effective enterprise application and NOT a public portal, which is best suited for browsers.

It sounds as though you are championing the thin-client-server model with a browser. You are the "boots on the ground" that must take care of the systems. You can conveniently fix the user's computer, fire up a browser and off they go. And of course, since you know which browser works best for the application, you install the right one.

Our application is also client-server model but with a custom rich interface. It is written in Java, and in the last 8 years we've only had one incompatibility issue across operating systems. We may be the guys in the White Towers developing the software, but with our framework, we developed a deployment utility, aptly name Connex. It is a 256K program that you download to their desktop. You run it, enter your credentials, pick your app (optional), pick your server (optional) and the software installs all by itself. If the user is having a problem, even perhaps corrupt files, they can press one key (F5) before they login, and the utility will inspect each file (checksum) and replace any that are missing or invalid. What is not to love about that.

We have never encountered a cross platform incompatibility or collided with other software. If we do encounter an error, we can retrieve the Java stack traces from the user with a simple download through our user administration utility.

Since we control the whole tool chain, from client to server, including the UI, we don't spend ages getting the various browsers to behave, act consistently and suffer through the browser wars version after version.

Therefore, the browser is convenient for you, saving you time and headaches. I admit it saves time, and as a tech, it saves expensive time. But what about the user? Assuming you only need to correct such problems occasionally, the user must deal with the browser interface for hours on end. What about their convenience, time and headaches?

We've seen all of this before and we will see it again... (I've heard that line somewhere before)

• The pendulum swinging...
• Mainframe Era - dumb terminal + big iron server
• PC Era - user independence with client side, single-user apps
• PC Server Era - single-user apps hacked into multi-user apps with server file sharing/locking
• SQL Era - stored procedures required to do heavy data work for clients
• Internet Era - browser (dumb terminal again)
• AJAX Era - swinging back to client side processing to relieve server of mundane tasks and reduce the dialog latency that breaks the user's train of thought

So where do rich clients apps fit in the pendulum swing? I think rich client apps give developers absolute control over where a process runs. They take more planning and deliberate server communications, but I believe the payoff is huge. We developed a Java rich client framework for our applications development. We develop under Linux and test and deploy to Windows users. We never tested it on Mac, yet we just had a Mac savvy user install it and run without issue!

Don't buy the argument that rich clients apps are too hard to distribute. We built our own tool that will reconcile the installed Java class files at user login. TALK ABOUT A MASSIVE TIME SAVINGS in both support and debug! It ensures all users are running the same version, all files are checksum validated, and since we deploy files at the .class level (not by the jar), it is like an rsync, often requiring less than 10KB transfers to perform an upgrade. All of this was developed before things like Sun's Webstart, except we have extended features like user authentication, and server, application and service selection all before they even start the application. These features have made managing rich client apps a breeze!

As for performance, we run rings around browsers! Our framework implements both in-memory and persistent object caching. It is a true n-tier architecture where a hierarchy of caching servers receive and broadcast updates which optimizes slower connections. For high volume customers we install a caching server behind their firewall to consolidate traffic over the net to the server.

The payoff? Users can view large sets of data, change sort orders and instantly change their view on the data, all of which occur solely on the client side. It happens quickly, without breaking the users train of thought. Our framework regularly can easily deliver 50,000 objects to a client application for them to view and manipulate, and should any one of those objects change, they will see that change immediately. Not going to happen with a browser any time soon.

We have customers running our software as a service using only a cellular connection for an office of four users. The framework is completely optimized for slow connections; once I gave a 30 minute demonstration of our inventory software using a laptop and cell connection. Afterwards, I showed them the connection stats; the total download was 4MB and the upload was 750KB. For contrast, I then spent less than five minutes browsing their current website which quickly racked up over 15MB of bandwidth.

The web has it's place. We would not expect any anonymous visitor to download and install an application. It is the right solution for the broader market, but I refused to roll back the user interface and usability 20 years and abandon the power of the desktop computer to use a web browser for enterprise solution. The web is convenient for everyone, optimal for no one.

This announcement has had an immediate impact on my use of the service. I got notice this morning that they received my returns and that I could rate the returned selections. I cringed (in anger) and figured rating them would be completely pointless. There is no way their suggestion feature will even come close with three profiles rolled into one. The signal-to-noise ratio will be pathetic with the induced noise from my wife and kids profiles.

"Fix" one part of the service and break another. Oh, and piss off your customers too.

Perhaps some miracle movie selection algorithm has evolved from their netflix prize contest, requiring all movie ratings be rolled into one profile. (Yeah, right.)

Motivated by money? Surely. Careless with greed? Likely.