Your math is good. I didn't make these numbers up.

What happened, I suspect, is that the underlying backlog numbers were re-estimated by the outsource team, based on their rate of progress. So this is in large part the effect of an experienced team familiar with the applications being replaced by an inexperienced team, combined with the additional process load of an external team working with an internal team. It was likely exacerbated by a remaining work force that was pissed off at the process, who had no motivation to make the outsourcers look good. As Gomer Pyle would have said, "Surprise, surprise, surprise."

That being said, will the person at microsoft who decided that the first or default account is an administrator please stand up. You need to be beaten.

Yeah, I agree. That would be as bad as, say, having the admin user be the first user you set up on a linux box, or giving it a UID of 1. Wait...

The protections won't get set by the sender - they're set by the user settings, or by what the mail program causes them to be set as it saves the file to disk. These are usually managed through the umask settings.

It's possibly to get a key logger to run on a *nix system, but getting the logger onto the system is quite a bit less convenient for the bad guy, IMO. That said, if a user who would hit 'OK' to any random UAC popup is running on Linux, there is probably a way to social engineer them into doing something similar on the linux box.

If some some one sells you a car with defective locks, aren't they somewhat liable?

Car door locks are pretty weak, easily bypassed in most cars with appropriate tools. In many not so old cars, all that is needed is a screwdriver. They also don't prevent the car from being stolen by being towed, or broken into by breaking the glass. All of these are recognized and dealt with as criminal acts, and are insured against as an inevitable occurrence in a world that has the occasional nasty person in it. We don't hold the car manufacturer liable for the existence of car thieves, why is Microsoft liable for the existence of bot-herders?

Microsoft has a continual stream of security updates, an easy to use automated update system, that it supplies for free to literally hundreds of millions of people. They create fixes, on their nickel, and proactively push those to the machine. You have to actively resist the updates (or not be connected to the network, in which case the point is moot) in order to not have them applied.

I realize Microsoft is easy to hate, but if there were any reasonable case for liability on Microsoft's part, don't you think some lawyer would have found a way to sue them already?

It only took our company 6 months to figure this out, and they ended up hiring back 400+ people that they had RIF'd. It took Accenture only that long to blow up a 4 month work backlog into a 2 year backlog.

The reason terrorists don't blow people up a) either because there aren't enough of them, which only works if they don't have a single US operative, or b) they don't want to blow people up.

Bing, bing, bing, We have a winner.

Anyone who flies regularly has stories about what has inadvertantly slipped through security. I have had pocket knives slide through twice in the last year, knives that make your little box cutters look like the toys they are. Potential terrorists -must- know this, and could exploit this if they so desired. Since the security is demonstrably porous, and yet we have had no serious attempts to exploit this security weakness, one of two things must be true:

1) the authorities are catching everyone attempting attacks, and are suppressing them without the other passengers, crew, or media catching on, and keeping it a secret from all of us, or

2) there is a very low incidence rate of attack attempts.

Do you think the TSA is competent to keep secrets? I don't.

"Writing off" an expense is only a relevant concept if you are a tax paying institution, which public schools are not. The extra electricity for this is a pure out of pocket expense for the school, however minor.

On my computer, which idles at 130 watts, running seti@home increases power draw to ~180 watts, according to the lil kill-a-watt meter I got from Think Geek. I have a quad core intel 9450 ( i think). I can't imagine the school computers are going to be any worse than that. So, 50 watts an hour, say 20 hours a day, =~ 1 kW/day. I don't know what arizona power rates are, lets assume 12 cents/kWh. That means this would cost around $43/year. If he installed to a couple of thousand computers, that's real money.

It would be interesting to know what proportion of the power bill we are discussing here. This could be a rounding error in comparison to the AC bills.

The systems aren't put in help the doctors. (...). But that's not what the systems are. They should start working now to have all records be electronic, X-rays, MRIs, personal history, etc. should be in formats that can be directly shared between doctors.

I'm going to argue just a bit. My wife just went through breast cancer this summer. The records, MRIs and actions that took place -were- electronic, and at more than one point -were- used to facilitate actions between a group of physicians that were part of her care. Meds were ordered electronically, and the new records generated from the process are all electronic. She had MRI's taken across town, and the pics were sent in electronic form to her surgeon and oncologist, who conferred via something like Net Meeting on them (don't know if it was net meeting or what, just that they had a con call and viewed the films together). One of the challenges that was presented was that she had old records from a prior incidence of cancer ten years ago, which are all still on paper/fiche. These had to get pulled and sent via courier. Overall, the experience that we had was highly electronic, and by and large was pretty efficient.

I won't dispute that a large amount of the systems are oriented towards capturing billing information. This is necessary because of the US's insistence on individual insurance plans, so for every action, someone has to get billed, which means a record has to be made of the actions. I think these systems still arguably help patient care, because they do still aid the physician and nurses in capturing the information, which would likely be slower if they had to use paper. I think it's a flaw to criticize hospital administrators for designing/using these systems, though. The hospitals are just following the mandate of the compensation system that they work under in the US.

Is this appropriate for a one off, one time use application? How about one that will be used by two users once a month until a conversion is completed. And so on

And Scala would be the same. The Odersky book describes it as a hybrid, but the force of the language is functional in nature. I'm not intimate with Erlang, but I think most knowledgeable commentators would use almost identical words for Scala as you use for Erlang. It does allow mutables, but de-emphasizes them. It treats functions as first class objects. Recursion is the preferred approach to repetition. There may be some higher canonical definition that it violates, but it looks pretty functional to me. And if you haven't tried it yet, it's pretty cool. It achieves some of the conciseness of Python, gives you java byte code as output, so it integrates into existing work easily, and lets you leverage any java libraries you have.