Command-line tools usually have very well-documented configuration files, and even when they break, debugging is relatively easy.

Now we often have configuration files (e.g. font configuration and internal stuff used by many GUI applications) spread over many poorly-documented locations. If the GUI is not enough or is buggy, which is often the case, it is quite hard to diagnose the issue even for an experienced user like me.

After all, it usually takes much more work to design and program an acceptable GUI than a CLI with similar usability, at least for frequently-used software and users who can either type fast or do simple scripting. Developer time is scarce, so GUI tools are bound to lag behind in features, stability, usability, etc., and the world is complicated enough that a lot of effort is still needed to make things work at all.

Yes, the LLVM version would be quite similar to a JIT compiler, but it is more efficient than most of the JIT compilers currently available. Unlike e.g. the Java VM, there is no need to do much bounds checking and type checking; for example, on x86-64 the code can have all kinds of buffer overflow problems, but the compiled code is generated in a way that makes it possible to verify before running that all stores can only end up in a 4GB slice of the address space, so other code running in the same process remain unaffected. As a result, it is possible to compile the large body of existing C code to run on the NaCl virtual machine, and have it run at about 90-95% the speed of ordinary C code. This is not possible on the JVM.

Moreover, there remains the possibility of processor-specific optimization using e.g. SIMD instructions. For example, if we want to make the JVM support AVX instructions, we need quite a bit of additional code in the JIT compiler, and usually some kind of API must be introduced so that the application can use these instructions manually (compilers are not yet so smart). On NaCl it is only necessary to modify the verifier so that only valid uses of these instructions are allowed; actual generation of the instructions is left to the ahead-of-time compiler, which hardly has to be changed if the new instructions do not make verification difficult.

I suppose the fee for filing a patent can be increased to a million dollars or so, so that we can pay for a sufficient number of real experts with enough time to show how a given patent is actually obvious.

But money only works up to a point. Examining patents is much less interesting than actually developing new stuff, and the real experts are probably paid well enough for developing stuff. If you tell them that examining patents is a citizen's duty to protect the country from patent trolls, maybe they will more likely listen, but I still doubt it.

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...