Actually, people with exceptionally good problem-solving abilities seldom have exceptionally high scores in IQ tests, since they often find multiple solutions to a task, totally unexpected by the test's author.

I have just bought Casio G-Shock GD-200 and I am very happy with it. The construction is very robust and it has all features I need: stopwatch, timer, multiple alarms, and dual time.

Using threads with locks and other traditional synchronization primitives is a walk across a minefield. More than 90% of multi-threaded programs I've ever seen are full of race conditions and other subtle bugs, which are not easily visible, but which make the program unstable on the long term (it is not unusual that a program suddenly deadlocks after running for several months). If you really want to write something parallel, use a language which provides a better abstraction, one of the possibilities is transactional memory.

The core of the problem is that GNOME developers have the habit of releasing as 2.0 or 3.0 something, which is of beta quality at best. It's quite possible that GNOME 3 contains some great ideas, but trying to attract users to software, which will need a year or two more to reach usability of the previous version, is not going to win anybody's sympathies. Exactly this has already happened with the release of GNOME 2.0: its usability was nowhere near that of GNOME 1.x, but still, it was presented as a replacement of 1.x. The users were rightfully complaining. One would have hoped that GNOME developers have learned something from that fiasco...

As of culture resistant to changes: For most people, the computer is a tool. And as with many complex tools, it takes time (sometimes years) to learn how to use them in the most efficient way. The learned experience is very valuable, but a part of it is necessarily lost when the tool suddenly starts behaving differently (people are not used to their screwdrivers changing shape overnight). Sure, changes are necessary for progress, but you should not ignore that changes come with a high cost to the users and radical changes of basic concepts even more so. Changing details is usually fine, removing functionality is worse, and radical changes of established products should be done only in cases, where the benefit is an order of magnitude larger than the loss. GNOME developers seem to ignore this fact of life for years.

UEFI Secure Boot solves a security problem which, while being real, is completely marginal in real world. The extra complexity with key management is simply not worth the gain. There is a zillion of places where you can improve real security of systems at much smaller cost.

Besides, if you have a 1000-line Java program and a 10000-line COBOL program doing the same task, which is going to have less bugs per line? :-)

Technical mistake? I would call it utter incompetence of the investigators, who do not understand the difference between a domain and its subdomain.

The Amdahl's law is a gross oversimplification. It assumes that every problem consists of a part that is unavoidably sequential, while the rest is parallelizable in an unlimited way with no overhead. The reality is that almost every problem is parallelizable (with a few notable exceptions like the lexicographically minimal shortest path or constructing the DFS numbering of a graph where we do not know whether an efficient parallel algorithm exist), but problems differ in overhead imposed by their parallelization.

Nonsense. The only negative externalities are those caused by producing electricity and those are much better handled by a tax on electricity, not by silly regulation of light bulbs.

The important thing is that the government should not dictate people what light sources are efficient and useful for what purpose. If CFLs are so efficient that they are less expensive to use, the people will take advantage of that sooner or later and there is no need for the government to force feed them the truth. In this case, the government has overstepped its mandate too far.

Also, there are many uses of incandescent bulbs where they cannot be easily replaced by CFLs -- e.g., if you need to regulate the light output continuously, or if they are very often turned on and off, or simply if the heat produced is desired.

The Juniper's "experts" talk utter rubbish:

According to Ingram, in a tree structure, 30 to 50 percent of the ports connect switches to other switches.

This would mean that the average number of ports per switch is at most 4 :-)

Every time you double the number of storage and servers in the data centre you have to quadruple the number of switch cores.

Another nonsense. The number of internal vertices of any tree (which does not contain degree 1 nodes) is linear in the number of leaves. Maybe the primary problem with the spanning tree protocol is that the network equipment manufacturers do not understand what a tree is :-)

Can you cite any recent one?

I was speaking about upgrades, not fresh installs.