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."
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.
If your C is faster than your Assembly, that's because your Assembly is crap.
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:
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.
if they weren't grandfathered, the Nanny State would never approve them today.
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.
I think that charging of batteries is mostly limited by the plug that it's connected to.
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.
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.
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.)
That fix did not work for me. It changed the behavior (no more "invalid plug-in" message), but applets did not run. Apple published a system update (on OS X 10.6 at least) yesterday that repaired Java and upped its version above the XProtect.meta.plist minimum.
I called AppleCare as soon as the plug-in showed up as invalid. The two most infuriating aspects of the call were the impression I got that Apple could hack into my Mac at any time (assuming a network connection to Apple) and the claim that Apple had not installed Java on my machine in the first place. After the call, I checked and indeed Java was installed when I bought the computer, directly contradicting the support supervisor's assertion, but I still have no proof of whether or not Apple has the power to silently force updates.
The security implications of promiscuously running Java applets, so Apple was right to do something. The problem is that they did so without warning; without asking permission; and with no obvious way to re-enable the plug-in. I understand that some people successfully re-enable applets by modifying XProtect.meta.plist, but all I managed was to eliminate the "inactive plug-in" message, leaving a completely empty gray rectangle.
Now, with Apple having repaired the problem, I'm calming down, but I've set up a blog, AppleHackedMyMac to discuss this, the possibly encroaching walled garden, security, and the like.
On a downhill slope, if your legs get tired you will start to go faster, eventually to the point that the pedals are turning fast enough that you can no longer synchronize your leg strokes with the position of the pedals to control your speed at all. At that point the unicycle will get ahead of you and you will fall backwards onto your ass at high speed, which isn't much fun.:(
I agree that there is more risk riding down trails than up them, but not for the reason you cite. A rider has no angular momentum when the unicycle shoots forward, and does not "rotate backwards onto your ass" in this scenario. Instead, you put a foot down on the ground and, usually, walk/jog forward (thus the term unplanned dismount). There is a risk of tripping, especially on uneven terrain, but no one said mountain riding was safe.
I beg to differ. While you might argue that a simple model show the same energy requirement for ascending a hill as braking on the descent, I'm a mountain unicyclist and that is not at all the subjective experience. I find riding downhill is an easy skill to pick up; significantly less taxing than riding uphill; not at all comparable to the effort required when climbing. For example, the big bumps at the BMX track can be a serious challenge to climb, but unplanned dismounts on the downhill side are rare.
Ah, you say, but mountain unicycles use massive 3" tires with a lot of rolling resistance, The difference is surely less on a freestyle unicycle with high pressure tires. Yes, that is true, but downhill is still a lot easier. Consider the IUF uicycle skill levels: Riding down a 15cm drop (think curb) is a level 2 skill, while riding over a 10cmx10cm obstacle (n.b. the hard part is going up) is at level 3.
Parent does have a point: It take a little skill to adjust to riding downhill. Beginners will have to practice a little to get the idea, but it does not take long to learn. After all, backpedal pressure (the real difference) is required in normal forward riding, so it is more a matter of degree than being a truly different skill. Until the hill gets steep, anyway.
One more thing: Brute force never works while unicycling. Without finesse, riding around the block would tire out a fit athlete.
It is multiplication. The mixer in radio is nonlinear so that the sum and product signals result from the trig identity: sin(theta)*sin(phi) = cos(theta-phi)/2 - cos(theta+phi)/2. Additive combination of signals does not produce lower frequencies that could be filtered out.
I take that back. Heterodyne is non-linear phenomenon (multiplication of signals, rather than addition). If dog whistle beats are audible, the explanation is different.
And those beats (the mixing products that exist below the sampling frequency) will be captured on the digital recording. There are also high frequency product at the sum of the original frequencies which will be lost, but even dogs won't hear them.
This isn't Zimmerman's first time around the block. His Zrtp protocol for SIP (VOIP) security includes Short Authentications Strings which can be communicated by voice or even out of channel, as well as shared secrets from previous connections. These offer reasonable protection against man in the middle attacks.
Slashdot Mirror
]You can read about Java as the Internet security menace in the link above, but first you need to enable Java Script to read the article.
That, or disable CSS (e.g. View/Page Style/No Style in Firefox).
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."
I guess if ... you don't know about hard drive failure rates, then it could be an attractive choice.
What hard drive? These come with SSDs.
Personally I don't like anything about it except for the dual-gpu support.
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.
If your C is faster than your Assembly, that's because your Assembly is crap.
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.
if they weren't grandfathered, the Nanny State would never approve them today.
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.
I think that charging of batteries is mostly limited by the plug that it's connected to.
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.)
That fix did not work for me. It changed the behavior (no more "invalid plug-in" message), but applets did not run. Apple published a system update (on OS X 10.6 at least) yesterday that repaired Java and upped its version above the XProtect.meta.plist minimum.
I called AppleCare as soon as the plug-in showed up as invalid. The two most infuriating aspects of the call were the impression I got that Apple could hack into my Mac at any time (assuming a network connection to Apple) and the claim that Apple had not installed Java on my machine in the first place. After the call, I checked and indeed Java was installed when I bought the computer, directly contradicting the support supervisor's assertion, but I still have no proof of whether or not Apple has the power to silently force updates.
The security implications of promiscuously running Java applets, so Apple was right to do something. The problem is that they did so without warning; without asking permission; and with no obvious way to re-enable the plug-in. I understand that some people successfully re-enable applets by modifying XProtect.meta.plist, but all I managed was to eliminate the "inactive plug-in" message, leaving a completely empty gray rectangle.
Now, with Apple having repaired the problem, I'm calming down, but I've set up a blog, AppleHackedMyMac to discuss this, the possibly encroaching walled garden, security, and the like.
On a downhill slope, if your legs get tired you will start to go faster, eventually to the point that the pedals are turning fast enough that you can no longer synchronize your leg strokes with the position of the pedals to control your speed at all. At that point the unicycle will get ahead of you and you will fall backwards onto your ass at high speed, which isn't much fun. :(
I agree that there is more risk riding down trails than up them, but not for the reason you cite. A rider has no angular momentum when the unicycle shoots forward, and does not "rotate backwards onto your ass" in this scenario. Instead, you put a foot down on the ground and, usually, walk/jog forward (thus the term unplanned dismount). There is a risk of tripping, especially on uneven terrain, but no one said mountain riding was safe.
Ah, you say, but mountain unicycles use massive 3" tires with a lot of rolling resistance, The difference is surely less on a freestyle unicycle with high pressure tires. Yes, that is true, but downhill is still a lot easier. Consider the IUF uicycle skill levels: Riding down a 15cm drop (think curb) is a level 2 skill, while riding over a 10cmx10cm obstacle (n.b. the hard part is going up) is at level 3.
Parent does have a point: It take a little skill to adjust to riding downhill. Beginners will have to practice a little to get the idea, but it does not take long to learn. After all, backpedal pressure (the real difference) is required in normal forward riding, so it is more a matter of degree than being a truly different skill. Until the hill gets steep, anyway.
One more thing: Brute force never works while unicycling. Without finesse, riding around the block would tire out a fit athlete.
It is multiplication. The mixer in radio is nonlinear so that the sum and product signals result from the trig identity: sin(theta)*sin(phi) = cos(theta-phi)/2 - cos(theta+phi)/2. Additive combination of signals does not produce lower frequencies that could be filtered out.
I take that back. Heterodyne is non-linear phenomenon (multiplication of signals, rather than addition). If dog whistle beats are audible, the explanation is different.
Wrong. The phenomenon is real -- physical, not phycho-acoustic. It is the pressure-wave analog of a radio heterodyne.
And those beats (the mixing products that exist below the sampling frequency) will be captured on the digital recording. There are also high frequency product at the sum of the original frequencies which will be lost, but even dogs won't hear them.
This isn't Zimmerman's first time around the block. His Zrtp protocol for SIP (VOIP) security includes Short Authentications Strings which can be communicated by voice or even out of channel, as well as shared secrets from previous connections. These offer reasonable protection against man in the middle attacks.