There's nothing creepier than showing up for your weekly radiation treatment just to find out there's a delay because they're "installing a Windows upgrade". When I asked the radiologist if there was any failsafe in the device, he assured me there was. When I asked if there was a radiation detector positioned behind the patient that was capable of shutting off the beam if it detected too much radiation, he said "no, nothing like that."

Medical radiation equipment should be designed with a secondary, independent piece of hardware capable of measuring pass-through radiation and shutting off the equipment. Doctors should demand such designs. Do you face much worse risks in your daily life? Sure. But your local Toyota dealer did not swear an oath to "first, do no harm."

The Java repliers are right on the mark. Trying to use app-independent portability layers ensures apps of any complexity will suck. By "suck", I mean "compromised at every turn by lowest-common denominator design decisions". Your app will end up using threads on an O/S designed to make multi-processing beautiful (Linux), or end up using multiple processes on an O/S designed to make multi-threading beautiful (Windows). It'll be clueless about the nifty GUI features that exist on a Mac but not Windows, and vice versa. Knowing up front that your app is going to suck allows you to, in all good conscience, choose a language that highly adapted for creating apps that suck in this manner. When I fire up a Java app on Windows (and I ALWAYS know it's a Java app the minute it finally manages to lumber onto the screen), I know I'm going to get the same sucky behavior if I fire that app up on a totally different platform (well, assuming I can manage to figure out whatever obscure infinite-megabyte downloads are needed to get the right "runtime engine" for the given app). Really, the only way you can make your app suck even more and be even more portable is to just go ahead and make it a web "service". That has the added advantage that nobody really expects anything but poor performance and clunky UI design from the get-go. But if for some reason you can't have your app suck as bad as a web service, then Java is definitely the next-suckiest way to achieve that portability that your end users don't give a crap about, but you hope will make your life easier.

That's the sentence where you stuck your foot in it. How many hundreds of thousands of programmers on the planet? OK, now how many programmers search the patent database for ideas they can buy before coding? 100,000? 1,000? Can you name me even 10? Where is the Eclipse plug-in for searching the patent database for relevant algorithms? Where is the panoply of web startups offering an online search tool that locates the patented algorithms that will help you get your next project done faster if you license them?

When it comes to software, patents have had half their faces blown off. They no longer function at all as a learning tool, or even as an economic engine for a hard-working programmer/inventor to profit from their non-obvious invention/algorithm. With much of their original, intended functionality rendered useless, patents (most especially in the realm of software) have long since passed the point where they offer society more costs than benefits. They are almost entirely the tool of large companies, lawyers, and those who sell services to inventors gullible enough to believe we still live in an age where patents work the way you describe.

Non-oncs generally don't understand that a whole lot of cancer is "clinically irrelevant". That is, it would never go on to kill you. Thus, as early detection gets better in most areas, you detect a greater percentage of cancer that was never going to hurt the patient. However, once you see the cancer, you are duty-bound to slash/burn/poison (Susan Love's famous chapters) to cure it. Statistically speaking, you know you are actually harming some patients, but it is a dilemma -- you hurt all the patients in order to serve a greater good for some percentage of them. A good example is the growing backlash against general PSA screening. Even just a biopsy for prostate cancer can't be 100% risk-free, but the treatment is really risky, assuming you're not enthusiastic about being impotent and/or incontinent for the rest of your life.

So don't get too excited about increased early detection of cancer. Currently, it is usually a double-edged sword that brings suffering to some percentage of patients who would have avoided it before the new test existed. An exciting development would be a detection test for distinguishing cancer that's just sitting there from cancer that's on the move and likely to kill.

Which is why we need 3 geeks, 3 lawyers to shutdown the lion's share of spam and misbehavior like this.

Scenario: the wrong geek gets 2 strikes, gets mad, and fires up a botnet (or just happens to have, say, $20,000 laying around to rent an existing one for a few runs). The botnet causes a significant percentage of users in some country to start getting their "strike warnings". As a result, the fallacy of the idea that IP addresses identify human beings is exposed (or the fallacy that ISPs invest the slightest effort in controlling botnets, if you like).

Your anecdotal data point is representative of how risk is being moved from organizations to individuals, and income volatility is increasing even for highly educated workers (in the U.S., of course). See "High Wire" by Gosselin for detailed statistics. When Suze Orman switched to telling people they need 1 year of income in cash for emergencies, the shift in risk, the increase in income volatility, is the "why".