Companies have gotten extremely used to having people on the electronic leash. Not just IT folks (though this is a large part of the population in question), but anyone whose job has been defined such that they need to be reachable within 30 seconds. I'll pick on IT folks just because so many people think of them as the type who have to jump the instant the cell phone rings.

Consider a typical IT team. At some point during the morning, they're all on the road to make it in to the office for the start of the business day. And at some point in the evening, they're all on the road heading home. During those times, none of them would be legally able to answer a call. Before someone says "well, pull off the road or go find a parking space", I'll speak for my own commute and say that there are long stretches of it where there is no shoulder to pull off onto, and when you only have 30 seconds to answer the phone before it kicks to voice mail, getting to a side street or gas station or whatever where you can park isn't often possible.

So what would the company do? Have the staff work staggered shifts so that there's always someone who is either at home or in the office during commute times, and could therefore legally answer the phone? Allow telework for part of the day so that commute times could be staggered without forcing people to adjust their whole day? That second one works fine for the morning, but it wouldn't help for the evening commute, or vice versa. Have a designated telework day for each staffer to keep them off the road? And so on. All decent ideas, but the current climate of "this is our business day and it's when you are to be at your desk" wouldn't want to embrace them.

Precisely. My distance vision isn't great even with glasses, but when I know the name of the road I'm looking for (even if I've never driven that way before), I know what the word is supposed to look like on the sign and I can recognize the pattern of letterforms long before I can "read" them clearly.

It's a hierarchy, and one in which things (usually) happen the way they're supposed to in a hierarchy.

The top CIO can indeed give an order, say "consolidate these email systems". This order is given to the next level of CIO's (it's government, you have CxO's down to the branch level sometimes) who are ultimately responsible for those 21 systems.

Once the order is given, the top CIO has relatively little say in how those orders are carried out, other than letting the guys below him know that their performance reviews are on the line and occasionally stepping in when things get too nasty. Now you have 21 people fighting each other over how the email systems are to be consolidated. And how many people report to those 21 CIO's? The top CIO has no authority to give direct orders anyone who does not directly report to him. So the people responsible for actually implementing the consolidation are two, three, four, maybe more levels down on the org chart.

Early this year, Dell gave our office an M1220 array filled with SSDs (15 of them). To benchmark it, we put it up against an M1220 that we already owned filled with 10K SAS HDDs. Each was plugged into an "identical" (as far as any two individual computers can be identical) machine, we loaded the servers with a fresh Linux install, and booted with a 1G RAM ceiling to avoid RAM caching issues. Same filesystem type and size on both storage arrays. We spent a weekend just writing /dev/zero to the SSD array so that we wouldn't run into any of the "first write goes real fast" phenomenon that sometimes happens.

And then ran iozone3 against both, up to 4GB file sizes (once again, to take RAM caching out of play).

Where the SSD did better, the difference wasn't enough to justify either the initial cost difference or the maintenance cost. Where the SSD did worse, in some cases it did MUCH worse.

We called Dell with the results. We sent them our testing methodology. They first told us that we had to put a specific firmware version on the RAID controller and make a couple of changes to the default controller BIOS settings, to trigger some custom code on the SSD on-board controllers. We tried. No difference.

They've got a lab where they do nothing except benchmark hardware 40 hours a week. We invited them to find a configuration -- no matter how contrived and impractical for real-world usage -- that would demonstrate measurable performance advantages for the SSDs.

Six months later, they called us back and admitted that they couldn't find a way to make the SSDs look better.

We'll wait for the second generation.

My wife and I spent a good 5-10 minutes after Tuesday's show trying to figure out how Watson came up with Toronto. I run big server iron for the day job, she's an editor and language geek, so between the two of us, we're as good as any amateurs can be at analyzing the faults in a natural-language AI. :)

The best we could come up with was a combination of factors. For the sake of completeness, here's the clue again:

"Its largest airport is named after a World War II hero; its second largest, after a World War II battle."

Watson worked on key words/phrases in the clue. If you make an assumption that repeated words are less likely to be key words (a quick way to eliminate articles, prepositions, and other filler), then the only unique words in this clue are: airport, named, hero, second, battle.

It's only a recent trend to name buildings after people using both their first and last names. Most just have the last name, and that last name could refer to a lot of people without knowing other context. Chicago O'Hare...heck, it wasn't until Tuesday night that I realized that it referred to naval aviator Butch O'Hare. (I did guess the clue before time was up.) Watson's word association database wouldn't have had that kind of context available, probably.

Without going into an extensive search of airports in North America (or the world) named after people, we did see that Toronto has an airport unequivocally named after a "battle hero". (That being Billy Bishop). But without other stuff in the clue to work with, that led to a lot of uncertainty. Hence five question marks.

Configuration is relatively easy if all you've got is a couple of zones. Maintenance is what takes work. You don't just turn a switch on and let things go on their own.

Keys expire and need to be rolled over. Signatures expire even more often and need to be refreshed. Your TLD registrar needs to have a robust mechanism for establishing and maintaining the trust chain. And it can all go to hell in an instant if someone's behind a router that is filtering EDNS, or TCP DNS queries, or truncating DNS packets, or doing anything else that speaks of assuming that anything DNS-related that isn't less than 576 bytes over 53/UDP is Evil And Must Be Destroyed.

There are plenty of tools out there for doing this all relatively painlessly, but it takes diligence and a higher level of meticulousness than most sysadmin tasks. On the other hand, for small setups, it's no worse than keeping an eye on your logs for interesting activity.

(For the record, I built my workplace's DNSSEC implementation in about 3 weeks, and got it 90% right before I had to go help my wife give birth. But we have dozens of zones, with subdomains, and multiple field offices running their own masters, so we had to deal with TSIG-signed zone transfers with external entities in addition to our primary master. And now that we've got it turned on, we get at least one report a week of someone having issues getting to one of our sites because of said upstream routers that are messing with DNSSEC queries.)

And as someone who used to work for a company operating satellites in GEO, I'll say that this would be a hell of a trick if they could pull it off. Let's start with the process of disposing of a spacecraft in GEO. You do a series of burns that alternately raise the apogee and perigee until the orbit is somewhere between 50-100 km higher than GEO.

Now let's look at the geosynch transfer orbit. Apogee at GEO, perigee at 200 km. Even if you raised the apogee above GEO to the level of the graveyard orbit, you would need to raise the perigee above GEO as well in order to avoid crossing other orbital paths. So your rendezvous vehicle needs to be able to reach GEO, first and foremost. This takes four or five burns to get that perigee up -- sure, you could do it in one (and they did do it in one in the early days), but that doesn't afford you a lot of control over the final position once you do reach GEO. Which is what they'd need in order to make a rendezvous.

Yes, you could drift the disposal vehicle to the G-15's position. When we drifted satellites to other orbital slots, we'd drift them at about half a degree per day. They could drift this one faster, but it would still not be a quick fix.

And, finally, you'd have to BUILD THE BLOODY THING. Nobody currently has a vehicle that could pull this off. By the time someone could even do a back-of-the-envelope design on how to do it, G-15 will have arrived at the 105W libration point, and it'll settle there along with the other GEO sats that were allowed to run out of fuel before we realized that we had to dispose of them.

Sure, it had some D&D-obligated women in skimpy clothing, but everything else that made it good was clearly targeting a mature audience:

- 100,000+ words of text to tell the story -- sure, kids read books like that these days, but at a video game's pace? Not so much.
- Your character could do almost anything to anyone purely out of self-interest, and most of it wasn't physical. If you didn't manipulate a particular someone to your own ends over the course of the game, you probably didn't talk to them at all. Like in the first Fallout, you could talk the final boss to death if your stats were high enough.
- The best way to build up your companions' strengths was to help them explore their pasts and personalities.
- You never actually find out what it is that you did to curse yourself with immortality...but it was so heinous that your continued existence is threatening the fabric of the universe. Just try to imagine what it might have been. Go on, I'll wait.

Modern games, though, are getting into "show, don't tell".

The systems may have come out of the west, but without the extra moisture that they picked up when they started swinging out over the Atlantic (or in the case of the huge weekend one, from when it swung through the Gulf on its way north out of the SW), they wouldn't have dumped nearly as much snow as they did.

And this is why I get all bunchy whenever some congresscritter trots out the phrase "the best health care system in the world". With sufficient money and knowing where to go and who to talk to, you can indeed get some of the best care here in the US. But that ignores the fact that the methods of payment (and the focus on treatment rather than maintenance/prevention, which are also part of the system) are completely screwed up.

And aren't we also being told to consolidate trips and minimize our local travel to save gas and cut vehicle emissions? What's better for the environment, a single 10-mile round trip to Wally World, or making an 18-20 mile aggregate circuit of town to hit all of the local businesses, assuming that your town still has everything you need in places that aren't big-box retailers?

I'm all for supporting local businesses, but nothing in this world comes without a tradeoff.

I had a job where I got 25 days PTO, plus the standard holidays. I walked away from it to go become a government contractor.

The problem was that I could barely take any of it. Six week-long software deployments each year, and effectively being unable to take time off for 2 weeks after each deployment (in case something went HORRIBLY WRONG), or the 2 weeks before the deployment (make sure that nothing affects the coders' ability to get their code changes in!)...do the math, that's 30 weeks that were pretty much unavailable. For the last 2 years I was there, I was pretty much capped out at 35 days of accumulated PTO and even started taking every other Friday off to stay under the cap. Finally after about 3 months of this, my manager practically ordered me to just take a week off and be done with it.

In my exit interview, I named this as one of the primary reasons I was leaving. If companies are treating employees as "resources", then they need to properly schedule "maintenance downtime" for those "resources" just like they do for the servers and the switches.

I love the idea of LED bulbs (much more so than CFLs, since those die quickly in our 25-year-old house), but they've currently got the same problem that CFLs do: they won't work with a dimmer. Yes, I know that some CFLs are dimmer-compatible now, but they're hard to find.

I'm nothing resembling an electrician or electrical engineer, but I have a conceptual idea of how you would make it work. Add a microcontroller that reads the incoming voltage. As the voltage steps down, turn off individual LEDs in the array in a fixed sequence. Half voltage == half of the LEDs are off, for instance.

Is the science sound on this? And would it add more than, say, $2/bulb?

b) Stop the users typing so fast.

Typing too fast caused people to die, in one case:

http://en.wikipedia.org/wiki/Therac-25

Specifically, go down to near the bottom of the entry where it mentions that: [t]he equipment control task did not properly synchronize with the operator interface task, so that race conditions occurred if the operator changed the setup too quickly. This was missed during testing, since it took some practice before operators were able to work quickly enough for the problem to occur.