I'm just going by reviews that use superlatives like "insanely quiet". Apple claims an impressive 12bDA at idle, which is going to be hard to hear even with the unit on top of a desk, but it is easy to turn the fans off at idle. I am assuming that the unique thermal design is really being exploited to minimize fan noise.

I disagree that about the competition being "very quiet". Quiet in a relative way, sure, but not as quiet as I would like. For reference, consider the recent Xeon powered HP workstation (non-liquid-cooled) under my desk for reference. It is actually quite nice compared to the screaming hair dryer fans of old, but, under load, the whooshing of air through it is plainly audible even with a gas fireplace fan blasting away 2m from my ears. Turning off the HP under these circumstances gives me a sense of relief from its noise. Compare that with this description: "during an Apple demo, a high-end Mac Pro, complete with upgraded processor and graphics cards, was live-rendering multiple 4K videos, and we couldn’t hear the fan over the normal room noises."

What hard drive? These come with SSDs.

By all means choose a computer with the features you want. For my part, I think I've finally found a serious computer without distracting fan noise.

FWIW, the Mac Pro (base model) is said to consume 40W at idle. It is also very quiet.

Not really evolution - after the layout of the linkage was determined, Jansen used an optimization heuristic to improve choose segment lengths for better performance. The algorithm is closed to simulated annealing, but the word "evolution" is a better fit with the artistic goals.

You are kidding yourself if you think you can write programs in assembler that run faster than the equivalent in C. Look at what my compiler generates for the C statement "return x/372;" with 64 bit ints on x64:

movslq %edi, %rax
imulq $738919105, %rax, %rax
movq %rax, %rcx
shrq $63, %rcx
sarq $38, %rax
addl %ecx, %eax
popq %rbp
ret

Your only practical approach as a human writing this in assembler is to use the slower 64 bit divide instruction. Puzzling out optimizations like this is a job much better suited for a the code generator in a compiler.

This is just one example among many arithmetic tricks of the trade. Register allocation and loop unrolling are two more low level optimizations that are no fun. At least not for me. I'd rather write the program in C, profile it, optimize my algorithms, and only then consider rewriting inner loops in assembler. Actually, I'd rather write the program in a proper modern programming language, and speed up its inner loops by rewriting them in C/assembler.

The paper assumes "that in the 100 m sprint he is able to develop a constant horizontal force F0 during the whole race", fits an air drag formula to laser measurements of an actual race, and concludes that Bolt expends 81.58kJ of mechanical work during a 100m sprint lasting 9.58 seconds. That may sound OK on the face of it, but 81.58kJ/9.58s is about 8500W (11.5HP) - more than four times the 2000W instantaneous maximum power output of elite track sprint cyclists. OK, maybe you believe in the overwhelming superiority of runners over cyclists. In that case, consider the drag of a body traveling at sprinting speeds. According to this bicycle power calculator, a non-aerodynamic rider might use as much as 500W at the maximum speed attained by Bolt. It is simply not possible that a runner's drag would be 17 times greater than an upright cyclist with knobby tires. This seems to prove that the paper's main assumption is wrong.

So what is going on? Well, we can see that there is an incredibly good fit between experimental data and the model. Clearly a combination of linear and quadratic force terms make the equation fit. However, the obvious answer is that these terms must primarily influence the force the sprinter is able to exert as a function of velocity. As I said, I'm not much of a runner, but I distinctly recall running out of leg speed when I used to attempt to sprint. Bolt's advantage seems to have more to do with muscle speed than raw power.

The failure to discuss this glaring discrepancy suggests the paper should not have been accepted for publication in its current form.

There is hope: Not long ago Colorado approved 35mph neighborhood electric vehicles, conditional on a federal safety standard for such vehicles (and change in DOT reg to allow them on the roads).

Traction control has pretty much eliminated the risk of oversteer that used to be associated with rear wheel drive. I'm all for teaching folks how to drive, but you no longer have to apply the pedals differently depending on drive wheels.

I think you misunderstand the engineering behind these tires. Much of the improved performance in wet conditions and lower rolling resistance can be chalked up to their higher air pressure. Contact area is approximately vehicle (corner) weight divided by air pressure, so these tires will have smaller contact area than conventional tires. The larger diameter allows the tire to deform less to achieve that contact patch, further reducing rolling resistance. And a narrower tire has less air resistance.

Charge time is often limited by battery chemistry and construction. Lithium ion batteries, for example, are typically limited to a rate of 1C (a theoretical 1 hour charge time from empty to 100%). In practice, those li-ion batteries take several hours to reach 100% charge because the rate slows down dramatically near as the battery reaches full.

Consider the Tesla S sedan: Not coincidentally, Tesla's 300A Supercharger stations "can charge about half the battery in 30 minutes." We are not likely to see faster charging options until new battery technology becomes available. Of course "the plug" (or more likely the socket in this case) substantially limits charging rate: Tesla's 1.4kW wall socket charger provides a mere 5 miles of range per hour of charge.

Secure voice is as easy as loading a ZRTP capable softphone (I use Jitsi) and registering on a SIP or XMPP network. Unencrypted connections to the PSTN are available from VOIP providers at reasonable prices.

If you want to run your own PBX, try Asterisk or FreeSwitch. You can set it up to connect to an ATA for use with a regular telephone.

It sounds like you prefer a DIY solution. If not, you might want to check out Phil Zimmerman's Silent Circle.

Oops thanks for catching my typo. The probability is 99.999994% = 0.99999994.

ZRTP looks solid to me. If the short authentication strings (SAS) check out, there is minimal likelihood of a successful attack on the protocol*. If you still don't trust it, jitsi can run peer to peer behind a vpn. If that's not good enough for you, you should be holding your conversations in a noisy location, away from all electronic devices, and out of sight of lip readers with telescopes.

*Jiti uses a 4 character SAS, which works out to around 24 bits for a 0.000006% chance of successful attack. Attack opportunities are strictly limited by the nature of the protocol (e.g. early commitment to an SAS; the use of cached secrets from previous conversations for authentication). Technically, this may not meet modern cryptographic standards for non-negligibility, but with a 0.999994% chance of an attack being made obvious, you will almost certainly know something is up and can take measures should it happen.

I wish Linux just worked.

My living room computer has problems with audio, video, application crashes, ACPI and update breaks because /boot fills up with unused kernels. I have to grab the TV remote when booting because the X server decides to switch to analog output. Windows runs fine.

Not so. Java was distributed as part of OS X 10.6.6. It is there in a nearly virgin partition set up for troubleshooting when I first got the computer. It's also on the 10.6.6 install DVD as Java.pkg and JavaTools.pkg in System/Installation/Packages.

(MadMaverick9: you completely missed the point. See the reply in my blog if you care, I'm not going to encourage a bad thread here.)