There's got to be a significant correlation between having the seasonal flu vaccine recommended for you, and being exposed to swine flu. Surely we should expect that people who choose to get seasonal flu shots do so in part because they're more likely than average to come down with the flu if they don't get a vaccine. Being at high risk for exposure to the flu is a clear mediating factor in leading to both getting every available flu shot and coming down with any strain that goes around that there isn't a vaccine for.

To put it another way, we vaccinate some people go keep them from spreading the flu. If there's a link between getting the vaccine and getting the flu if you don't get the vaccine, then we're vaccinating the right people, and we should go on vaccinating them. (But it's worth making sure people know that they can't act like they're immune to the flu this year.)

Of course, the study could have found an actual danger to the vaccine, but we can't tell until the peer review is complete; peer review is where people will come to some sort of consensus on what the risk is that this value should be compared to.

That's why there's a legal system to which the two parties present their evidence before a judgement is rendered. If this guy can actually present the evidence he says (here) he has, he should win in court. If he's lying here, he should still go to court, and lose big. (Or, more likely, they should go to court-backed mediation, where they can show their evidence to a mediator who can make a decision if it's obvious and make it stick if they both accept it.)

He makes a good point about the weird Ubuntu version scheme: a new user is likely to think that you could update from version 8.04 to 8.10 as a ordinary incremental change. But an expert would know that 8.04 and 8.10 are actually dates ('08.April and '08.October), and everybody actually calls them Hardy and Intrepid whenever they're saying anything that might be useful information. For that matter, the recent code names actually tend to give accurate suggestions about the sort of release it will be, with the LTS one suggesting robustness and the others suggesting ambition of various sorts. (Are you sure you want to move from something Hardy to something Intrepid? On the one hand, you get new stuff; on the other hand, it won't live as long)

$ host www.whitehouse.gov
www.whitehouse.gov is an alias for www.whitehouse.gov.edgekey.net.
www.whitehouse.gov.edgekey.net is an alias for e2561.b.akamaiedge.net.

Reducing their bandwidth and server load is just not a big deal. (See Akamai and note that the whole site takes the path that the "image" request takes in that diagram.)

You can probably simplify the git workflow a lot.

You don't need to update at all until you're done with your branch. If there were any benefit to updating regularly, you could get exactly the same effect at the end by rebasing a dozen times against progressively newer commits in the upstream history. The exception, of course, is if someone has done something you want to use, but you can just update to the point you require. SVN doesn't have a command for "updating all the way is too hard, update only a little bit at a time", which gets people in the habit of updating all the time.

If this is your whole workflow, you shouldn't have any of your own changes on the master branch (except, of course, when you send out your work branch and then get it back in the next pull), so you shouldn't need to fix anything there; in fact, the "pull" should just say "fast-forward" and give you exactly what is in the main repository. In fact, you can skip having a master branch at all, and just rebase against "origin/master" (which is the state of the main repository the last time you looked).

You should use "git commit" all the time. Until you push, you can revise commits after you make them. As soon as you've done any work you wouldn't want to redo, commit it. Then use "git commit --amend" when you do more. Eventually, do another amend to write a real message, inspect the change with "git show", then fetch, rebase, make sure you still like it, and then push.

I generally work with two branches, one which contains just whatever I've written as I write it, with tons of commits with the message "more stuff" or "fixes", and the other formed by getting a diff between origin and the junk branch and applying only those parts that are actually all one logical change and all good, and committing it with a good message. I repeat this until my good branch contains everything worthwhile, and then I dump the branch that's only got unneeded debugging statements, whitespace changes, and so forth.

How can you not mention a line that starts "chomp(my $HEAD..."?

For that matter, why should Red Hat fund development on the sorts of thing that Alan Cox works on, if hardware vendors are willing to fund it? Intel can even get developers internal documentation and (most importantly) face time with hardware designers who can explain things that they didn't think to document (or that they documented in a huge specification that's too big to find the little detail in).

There's no reason for Red Hat to have a collection of kernel developers working on stuff that Red Hat doesn't need more than anybody else does.

I think you're missing the fact that the Wiimote is sufficiently different from other systems' controllers that most games released for both of them will be terrible on one or the other. Trying to sell to the massive Wii install base isn't going to be easy if you're trying to compete with games that are less awkward and more fun on the Wii.

On the other hand, there's no reason there couldn't be a good Wii GTA, except that it would be much more disturbing than other console versions. In ordinary GTA games, your character does all sorts of bad things while you sit around pushing buttons on a controller. In a proper Wii version, you'd be miming doing the bad things yourself, which will seem a whole lot worse.