We've seen where even helicopters can be abused, using thermal imagery, etc. to see into places where they really have no business seeing. Drones are quickly evolving and will exacerbate such problems. We've seen how the warrant process is bypassed or ignored, now imagine drones small enough to see every space you occupy, and autonomous enough that nobody is even providing oversight into what they're recording or observing until after the fact.

Helicopters require effort and cost, and so there is some incentive for their operators to dispatch them only when there is a good cause. Small cheap drones won't have even that barrier.

My experience in pricing these things out is that it's cheaper in-house. I can spin up a virtual machine on our VMWare/UCS infrastructure for about 1/5th the cost of a higher tier provider. I hear a lot about scalability, but so far I've never been in a position of telling somebody "I don't have room to create another VM for you." Flexibility is a semi-valid argument. It depends on what flexibility you want. If you don't need your test servers backed up, you're either paying for separate tiers in the cloud, or you're just paying for something you don't need or use. If I don't need to back up a VM in my own data center, I get direct savings from not doing so. The backups are just one example.

Cloud makes sense as an offering from 3rd party ISVs. If they have a product, they should offer a cloud option for it, where you pay them and they contract to whatever cloud provider they wish and include it as part of your cost. It's just another one of those tools that we will all use the wrong way because we have to satisfy some kind of managerial mandate. And we won't use it the right way because it jacks up the apparent cost of the products that could truly be a good fit.

If the certification is relevant and useful, and the training is good, I'll pay for it. But, often it requires some prep work by the employee.

For instance: Joe wants to get his RHCE. The RedHat prep and test all-in-one class is a good bit of training, outside of being a certification exam. So, as long as Joe puts in the effort to be prepared for the class and exam, and assuming I have the training dollars, I'll invest in Joe and send him to RedHat.

Of course I expect my people to be self-starters, but I'm either going to pay for the class, or pay him enough to pay for it himself. Why not invest in him directly so that he knows I value him. I get not only a skilled employee, but a loyal employee.

I agree with you completely, and for the record I am an IT manager with a corner... cube.

The benefits of cloud are not typically financial. For some small companies they can be, but not if you are of any significant size. The cost of a given cloud virtual machine is much higher than the cost of a local virtual machine if you already have any kind of server infrastructure. When I divide out the labor, data center costs, storage, backup, etc. I find it costs about 5 times more on average to pay for a cloud server, assuming you're using one of the leaders in the cloud provider space than to pay for your own VM.

That extra 400 percent cost can go a long way to buying your own scalability. After all, it buys the cloud vendor scalability.

I think the perfect fit for cloud, outside of the above mentioned small business, is in the 3rd party app space. It makes sense to me for vendors to offer hosted solutions in the cloud, instead of dealing with each client's personal hardware choice, configuration standard, etc. I'm a big fan of cloud in that regard, but too often it's just a stupid buzzword.

That is exactly what I was thinking. I'd be pissed if an empty case dented my new car or crashed through the windshield and injured me or my family.

Think of the managers you have respected, and analyze what made them great managers for you. Some common things that have served me well:

1. Don't try to change your people. They are who they are. Work with their strengths. If you can't deal with who they are, you'll need to work on getting them off your team.
2. Pay attention to your employees' careers. You should be training them to see the broader aspects of what they're working on. You should have a career path in mind for them. Some may want to do what they're doing for the rest of their lives. But you should be looking for the ones who will eventually want to move up or sideways, and you should help prepare them for that.
3. Remember that if you're successful, it's because of the work they do. Don't forget that. You aren't successful all by your little lonesome.
4. When you give them something to do, give them a result. Don't micromanage the way they do it. Certainly standards have to be applied, regulations complied with, etc. But as much as possible, let them work toward the goal.
5. Your authority is in your title. It's in black and white. You don't need to prove it all the time. You don't need to fear challenges to your authority: they're stupid and you can't lose them.
6. Finally, this one is tough, but be aware of the difference in your relationship now. There are some jokes that will not go over like they used to, because although you are still who you are, you are now also boss. Neither you nor they can forget that, and shouldn't. Otherwise what would be the point of making you boss?

For what it's worth, I often see this scenario from the opposite perspective:

Them: We've got a new program that we chose on our own and requires customization and a lot of changes to our default security policies.
Me: It's not that easy, we have regulatory compliance issues to sort out, and the security policies are in place for a reason. You should have consulted us before you spent the money.
Them: I just want to do what I want to do, and you need to help me because I make money and you don't.
Me: That's exactly why we've ended up with all of these regulatory compliance issues, people just doing what they want. I wish it were different, too. I could be a lot more effective.
Them: I don't care about you. My wants are the only thing that matter.

Agreed. Both sides of the debate are doing a good bit of quibbling about how things are being represented, but the truth is that he refused to give the owners of the system the information they needed to run it, information they owned and were entitled to. The result of that action (or inaction, however you wish to represent it) is that a lot of time was spent by a lot of people dealing with the situation, whether they were 3rd party consultants doing the technical work, or city staff who gave reports, depositions, investigated his employment history, argued the case in court, etc.

We can argue about calling it "damages", but the costs are real. And Terry is nobody to hang your hat on. Having a jerk for a boss is no excuse for what he did. Every boss is a jerk in someone's eyes.

Here's a little secret of System Administration: Much of being a good admin is your skill and knowledge; but more of it is your wisdom and caution. You don't have enough people to support convenient one-offs all over the place. Keeping the environment manageable (and not just by you) is most of the battle.

Your fellow Docs want an electronic calendar. You don't say that the current system isn't working, just that they would like the more convenient electronic function. Perfectly reasonable. But, it's not reasonable to do an end run around IT. I know that we're sometimes slow to get something done. I know that we can seem very bureaucratic. But you have to understand why and help us to help you. We're slow to get things done because we have way more work to do than we can get done, so we have to prioritize. Your little calendar is not a high priority. If you want it worked on promptly, make some waves in the budget process so IT can get more staff.

As for the bureaucracy, I really think people don't understand that much, sometimes even most of the regulatory burden falls on IT. We do the rights and access work to the data. We produce the reports. We have to write the polices and procedures. We face the auditors. We burn when something goes wrong. None of this is our core function. We'd rather be coding or installing your calendar. These regulations are written with the operational staff in mind, but IT is the one who achieves (or doesn't) compliance, and IT is the one who is held accountable. Strangely, we get held accountable by both sides. People actually give me grief as if I'm the one responsible for Sarbanes Oxley. It wasn't an IT guy that lied to everybody and wiped out their pension funds. And the really big secret of IT is that we feel the same way you do about the bureaucracy. We wish we could do away with it and get some things done.

I know that you're a smart guy; but I have my job for a reason, and it isn't because I can install BSD and set up a calendar. I could train a monkey for that. I have my job because I can also apply standards, evaluate a given system's impact in the environment, understand the policies and procedures (and the regulatory requirements from which they came), and keep it running when some obscure problem happens. You're certainly capable of doing all of those things; but you don't do them, because it's not your job, and you haven't got the knowledge and experience. I'm pretty smart myself, and I like to think I could be a good doctor; but I wouldn't set a leg just because I know how to mix plaster.

If you think the calendar is a priority, then walk over and beat on Sr. IT Mgt. They'll make it a priority and some IT tech will actually enjoy having a project he or she can complete that will make life easier for someone.

The piece missing from your analysis is that Sully's performance is only half the story, or even less than half. The real story is his quick decision to land in the Hudson, a crazy and terrible decision that was right in this circumstance, and maybe no other.

For all the talk of reflexes vs clock speed, etc., how do you program a computer to make a decision like this, and make it smart enough not to do it the next time? I know somebody is going to say "It made sense. It was the only thing he could do." But even if you believe that, how do you code it? Do you just tell the computer that when all else fails, head for a flat open space? How do you tell it which flat open spaces are school yards, or mall parking lots, vs empty freeways or ploughed fields, or a busy freeway?

Yes, pilots are limited human beings, and will sometimes have the wrong answer, or make a mistake; but you're really only moving that to the programmer when you fully automate air travel. I don't believe you can develop or code enough "proper emergency protocols" to meet the flexibility and perception of an experienced pilot.

I've seen some poor people that fit that mold; but I've also seen a LOT of people below the poverty line who are hard working, spend what little money they have on necessities, and receive assistance with great shame.

I spent about a decade in the restaurant business, doing everything from cook to store manager. The conception of poverty by people who went to college and got a decent job afterward is skewed. Most of us simply do not realize the margins that some people live on. They can't buy that song they heard on the radio because they can't splurge $15 this week on a cd, and don't have internet access to download the song for $.99. They buy more thread than socks.

They work two jobs because they are in debt for the full price of the last visit to the ER. They plan their day around the bus schedule. Weekends don't mean anything to them except that they have to now find a babysitter for the entire day, and the bus schedule is different. Holidays mean lost pay.

The easy retort is that these people chose their life, and that they could improve it if they wished; but it's not as easy as that, and repeating it ever more loudly won't make it true. Many of these people work every minute of the day to maintain their meager living.

They are often intelligent people who by happenstance, or societal conditioning, tragedy, or accident of birth never got many of the little opportunities that allow us who are maybe not rich but live comfortably to achieve the lifestyle we have.

I've been fortunate (or unfortunate, depending upon how you look at it) to spend time with very rich people and some very poor people. Trying to equate IQ with either station is a fool's exercise. Trying to generalize poor people as unmotivated, entitled, profligate spenders is no better.

I actually thought the 3rd was the best. I do echo your complaints; but I thought the battle of Pelenor Fields was done tremendously well.

Theoden stole the whole series, though. His performance outshone everybody in both of the movies he was in.

I highly recommend 2 books for the reader "One Bullet Away: The Making of a Marine Officer" by Nate Fick, and "Generation Kill" by Evan Wright. They both tell the same story of the Second Platoon, Bravo Company, 1st Recon Marines who invaded Iraq. They briefly mention these "moto" missions whereby fighter jets make very low passes over a firefight. They both intimidate the enemy and provide a morale boost to the troops. Fighting spirit should not be underestimated and at the right time, a low pass might be more effective than a danger close bomb.

Not a military pilot; but I'm a commercial civilian pilot and flight instructor.

The time should count. They aren't flying games or even simulations at all. They can't pause or restart the flight. They're flying real airplanes and the resemblance to a sim is only in the interface. But that interface is the same one they have in the real plane: altimeters, directional gyros, airspeed indicators, even tactical computers. They do not have the sensory input or the personal risk; but sensory input can be misleading, and in most situations notions of pilots flying "by the seat of their pants" are quaint at best. And as for risk, you don't get to log flight time because of the risk. You log flight time because it requires skill to do it well and correctly.

Personally, I would give higher honors to the pilots flying manned airplanes; but that doesn't mean I don't respect these guys or the job they do, or believe they shouldn't get credit or professional reward for doing it.

SSDs aren't perfect either. For critical data, you'll see companies deploying their shiny new SSD drives in SSD RAID arrays.