That's a noble goal. Do you have any examples?

A traditional init script is just a shell script, including almost invariably a couple of nasty race conditions and other subtle bugs. Starting and stopping a daemon safely is close to impossible in shell. I am not a huge fan of systemd, but init scripts written in shell are a nightmare.

PDF::API2 is nice, but unfortunately it doesn't handle newer PDFs with compressed xrefs and/or object streams yet. Also, support for writing text in anything different from ASCII and maybe Latin-1 is close to missing.

SAT solvers usually guarantee that their result is correct. What they don't guarantee is that they finish in reasonable time for every input.

c) One of the groups had better teachers, so they learned more.

Actually, this is a very common reason. In such cases, I don't see why should the better group get the same grades as the other one.

This sounds good in theory, but the reality is that self-signed certificates (or those signed by an authority your browser does not recognize) are several orders of magnitude more common than MiTM attacks.

Otherwise, I agree that a big part of the problem is unusable UI for managing certificates in almost all existing browsers.

I expect the browser to clearly inform the user whether the connection is safe (HTTPS with a verified certificate) or unsafe (either plain HTTP, or HTTPS with an unknown certificate). I also expect the user to check that a connection to his bank is reported as safe. If you are interested in preventing attacks against careless users, the browser might also notify the user that a site previously known to have a safe connection, no longer has one. However, I do not think this is of much help: many users just enter the domain name of their bank and rely on the bank to redirect the HTTP version to the HTTPS one, which is where a MiTM attacker can always succeed. (An interesting special case is invalid certificates: expired ones, or certificates issued for a different domain. Here, a big fat warning could be appropriate.)

Is "as bad as no encryption" a reason for yelling on the user and presenting it like the worst security problem ever? Even if I accept the premise that it is as bad as no encryption, the obvious conclusion is that the browser should present it the same as no encryption.

Actually, it is not as bad. It still keeps you safe from passive attacks (like your ISP collecting all data for a three-letter agency, which analyses them later).

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.