I'm surprised it took this many comments to reach this solution, as it's what immediately popped into my mind when offline, versioned access was being requested.

One or more CSV files (or another line-based text format) in Git would allow for multiple simultaneous updates, offline, to be merged at a later date, and it would provide offline access to the most recent updates that you fetched when you were last able. Additionally, all historical changes, plus descriptive messages at each commit to say why the network changed the way it did.

The Humble Bundles seem to be helping with this, though. They're getting a lot of independent game studios to think about releasing for Linux, and they show that Linux controls nearly 1/4 of the gaming market. I'm hoping that this helps push similar changes up to the bigger studios.

Except the fusion drives on the comets would make them visible as soon as you light up the fusion drives. At least, if anyone is watching... http://www.projectrho.com/rocket/spacewardetect.php#nostealth

... so just pick one and stick to it.

I'm partial to "input" and "output" myself, from the perspective of the object using them (so a client's output goes to the server's input and vice-versa).

If you need to reference both objects' streams at the same time, you've got "myInput", "myOutput", "hisInput", and "hisOutput" for clarity.

Or just pick something fun; "spinwise" and "widdershins" isn't bad, but may confuse your users.

I was basing it on the average atomic weight of each element, in the first periodic table that came up on Google. It's been a while since my last chemistry class (11 years, I think), so I may have gotten it wrong.

But it looked like, since they said there were no radioactive byproducts of the reaction, that they were talking about the most stable (and therefore common) isotopes of each. Therefore, Ni-58 and Cu-63, resulting in an atomic weight difference of 5, which means they need to create 4 neutrons out of thin air.

But, like I said, high-school chemistry was a while ago.

I'm curious how they can get more energy out than they put in, at the same time as getting more MASS out than they put in. Copper is more than just a proton heavier than Nickel (63au vs 56au, I think). Conservation of energy/mass, anyone? Hydrogen+hydrogen fusion produces energy because the resulting helium is lighter than the inputs, and E=mc^2.

I was very disappointed to see that it was a misspelling of "learn" instead of "leer." I was quite curious how a computer could leer from the Net...

If you write your own, you may not want to include propagation beyond any single machine. No risk of getting out that way. Just make it tricky for a user to remove, to show the various techniques that may be needed (hiding in multiple places, being started from registry keys and other locations, running multiple processes that each monitor the others so it's tough to kill them all, ...). Good luck, and ask for permission before doing it!

Umm... It IS executable. It prints "EICAR-STANDARD-ANTIVIRUS-TEST-FILE!" to the console when run as a COM program. It's just been added to the virus definitions of every piece of antivirus software to allow for simple, risk-free testing.

Well put. Anyone got some spare mod points? Parent could use a few.

Well put, I'll agree with that.

However, he did not prove that Dvorak was an inferior layout, only that nobody has done a proper study in the 80 years since it was invented.

By not showing it to be an inferior layout, he cannot prove his own point that the market always chooses the best product.

He referenced many old studies, but did not conduct his own. Every one of those old studies was biased in one way or another.

The few studies that he presents as unbiased, which found for QWERTY or for a tie, involved retraining typists, which is definitely a bias of some kind.

Nobody seems to have performed a study involving teaching first-time typists to see how long it takes to get to X WPM, or to see how fast they get after Y hours of training. That would be my definition of an unbiased study.

Of course, at this point, it'd be pretty tough to find someone who has never typed on anything before...

Um... no, a single dimension is a line. How do you measure a point? :-P

I use git at work because we were told to, but I am actually quite fond of it. I've even started using it to keep track of personal projects at home.

I like it because it has pretty good documentation and I can figure out most of what I need with a quick search, and because it generally does what I want when I want it to.

We switched to git from cvs about a year ago, and I am much happier for a few reasons that will also apply to subversion:

1) Repository info is only stored in one place, so you don't ever need to search out all of your CVS or .svn directories

2) Local commits make it easy to check stuff in whenever you need to, and then make it pretty (with git rebase -i commitid) before pushing to a central repo (assuming that's the model you are using)

3) There is a two-stage commit. You have the working tree (aka working copy), which is what you are editing, the 'index', which is where the changes you want in the current commit go, and the actual repository, which holds commits. With that extra step in between, you can check in only the parts of a file that are relevant to the current commit (with git add --patch filename). I have a tendency to do a bunch of editing everywhere, forgetting to commit, and then go back to make multiple commits of discrete features/bugfixes at the end of the day. I'm pretty sure you can't do that with CVS, and although I'm not sure about subversion, it would surprise me if you could do it there.

4) The repository keeps track of changes across multiple files, instead of tracking each file individually. That makes applying a bugfix from another branch really easy, since you don't need to hunt down every file that was modified by it.

So anyway, I'd suggest sticking with git, but there's no harm in trying other systems; you never know, what I like and what you like may be completely different.