As a native Chinese speaker fairly fluent in English, I can type about 80wpm in English, while my Chinese typing speed is about 60-80 characters per minute depending on the input method, equivalent to about 40-50 English wpm. While English is faster to type, it takes a bit more time to form the correct sentence, so overall there isn't much difference in e.g. IM.

Wouldn't it be akin to having biological children with your own identical twin, with a high likelihood of birth defects, since your two sets of chromosomes are being remixed, possibly making your child getting two "bad" copies of some gene? It won't be like a clone at all.

IIRC the procedure is still far too expensive to be used commercially on ordinary farm animals. Wait until we genetically reprogram the animals so that they can give birth to their own clones without manual intervention.

Sometimes you want to do some experimental work that is complicated enough to be version-controlled, but not stable enough for other developers to see yet.

In SVN you have to use a branch, and SVN branches are not that convenient to use. Otherwise, when another developer checks out the tree or commits his own changes, he will see the unstable changes you have committed.

In Git you can simply commit your experimental changes and push them (or let others pull them) when they are ready.

And if you frequently want to push immediately after commit, just make such a shortcut.

From what I have looked at, I would not call many of these "legitimate" in terms of whether enforcing them (if even possible) would do the world any good. But then, IMHO hardly any patents in my field, applied in any country or by companies from any country, are what I would call legitimate. Patent trolling is so ethically reprehensible that anyone deciding to join the game might as well commit plagiarism/fraud/bribery/etc. as long as they don't get caught. It's a fair game like spying in a war.

There are a few sensitive files in my home directory, such as my private key in ~/.ssh and a few configuration files that contains passwords in clear text. I really don't want these files to be shared inadvertently, yet they are currently treated as ordinary files by the SELinux on my Fedora 10 system, so any process running under my account can access these files. Of course I can still relabel the files and change my SELinux policy, but this is beyond the ability of most people. It is a shame that SELinux, with its huge potential, is so hard to use that it still provides very little security for an ordinary user.

Truetype fonts generally contain some information for hinting purposes, i.e. they tell the font renderer (Freetype) the best way to render the character at small pixel sizes. The "bytecode interpreter" that makes use of such information is available in Freetype, but the method is patented (IIRC by Apple) in the U.S., so most distributions turn it off by default. Without such information, Freetype has to decide the small-size rendering method all by itself ("autohinting"), and some people may find the result blurry.

If you are not in the U.S. or don't care for software patents, there are plenty of information on the Internet about how to turn on the bytecode interpreter in Freetype. For example, in Fedora you can simply download Freetype's source RPM and recompile it with rpmbuild using some --with options.

I listen to quite a lot of MIDI/XM/MOD stuff already, and some are actually very decent.

The same reason system administrators are reluctant to reboot their production servers in order to apply a kernel patch that fixes serious performance issues. Government downtime is costly. And in this case we have a fairly invasive patch involving a new algorithm, and although the algorithm itself is well researched, the specific implementation needs extensive testing for which good spare hardware is unavailable.

If only we had a good simulator to test political ideas on...

1. An ordinary user has very limited access to your server's internal logic, so it is often hard to know, without actually attempting a harmless exploit, whether some suspicious-looking code is actually a bug and is actually exploitable. Your suggestion is impractical unless the sysadmin has the time to deal with people pointing out false positives rather than real bugs.

2. After a sysadmin finds a security hole in his system, he can avoid cleaning up everything if the logs can be trusted and they say the hole has not been exploited. Now, if the trusted log instead says that the only exploit to your SQL injection bug is that someone did a "CREATE TABLE this_is_a_security_hole ...", this does not take much more effort to deal with.

3. s/your house/the government building containing everyone's personal data. A security hole may affect other people more than it affects you.