The weight of the fuel decreases as you burn it out the back of the rocket, increasing efficiency For each second of the burn. Second, did you account for the rotation of the earth underneath the rocket? Zeroing out the forward momentum does eat up most of the fuel, but you don't need a whole lot of forward velocity to fall down a parabolic arc from that height to return home. Landing requires about 60m/s of delta v at it's new mass.
The rocket (1st stage) when empty needs almost no fuel (about 4% of the total fuel at launch) to return to the launch site and land. The upgraded Falcon v1.1 has 10% more fuel at launch as well as increased cargo capacity (more efficient engines). Hitting a floating barge means you have to have good conditions at the launch site, as well as 400 miles out at sea as well. That dramatically limits your launch capability and exponentially increases your recovery costs.
My daughter forgot her iPhone 4 in a pocket while doing laundry (commercial-sized front loader in an apartment building). The door locks when you start these. She panicked when she realized (like all teenagers do when they are without their device for 10 seconds) that she didn't have it and that it was probably in the wash.
No amount of convincing could get that machine to stop or open up, so she sat their crying for the entire wash cycle (I could only imagine what the accelerometer was doing during the spin cycle). When it stopped and unlocked she retrieved the phone and it was fine. Still works today two years later. I suspect the iPhone 4 will go down in history as being a really solid device, although with 10s of millions of them I'm sure there are lots of stories to the contrary.
Thanks for posting this. I had a 15C which I gave to a friend when I got a 28S. The 28S is still on my desk and still works brilliantly. Both calculators are my favourites. The 28S takes "N" batteries which were for "cameras" when cameras still had film in them. So they are getting a little harder to find. It takes a few years for them to die, but I'm starting to stockpile them anyway.
I'm guessing the button cells for the 15C are a little easier to find.
So does that mean you're suggesting the safest course would be to:
(a) tell everyone to shutdown ALL OpenSSL-backed services, urgently.
(b) after 1 day, tell everyone they can bring their 0.9.8 services back online.
(c) after 1 day, tell the remainder that it's okay to come back online, with heartbeat disabled.
(d) have the patch ready for distribution around this time.
I agree with the caution. TBD:
(1) there's the risk that telling admins to shut everything down, all versions, without telling them why, will cause them to ignore the notice
(2) while these services are shutdown, what will admins do instead? will they use insecure services because "the show must go on"?
Yes. You don't have to notify people of the exact flaw and how it can be exploited, to help them protect themselves while waiting for a patch. The immediate response should have been to tell people to disable heartbeat, or barring that, shutdown their affected systems. Yes, it would suck, but since you don't know for sure that the exploit is known only to the researchers, you should assume it's in the wild, and this is the only safe thing to do in the interim. (Could this be used as a form of DoS? Sure, if sysadmins get used to wholly shutting down services anytime there's a warning from anyone, or if the partial shutdown of one service in fact makes another service less secure. TBD.)
All this discussion of disclosing to OpenSSL first, letting them patch, giving distros time to get updates ready
Making a big stink about it is the only way to make sure sites actually get updated, anyway. Distros and whatnot having updates available does not get those updates installed. We don't have auto-update on any servers. As was discussed recently, many sysadmins have to submit patches to change-control boards for approval, and if there's not a furor over the issue, there's no emergency approval.
(a) a blitz identifying only the versions affected and what to do about it,
(b) a patch release sufficiently delayed to give end-users a chance to shutdown affected services,
(c) a blitz about the availability of the update, which people will care about more because they've already had to take action to protect themselves, and are possibly sitting in a shutdown state.
It's interesting what one will do when your political asylum is up for renewal.
The problem here is that people have been using the argument that Open Source is better because these issues can't happen "because" of the visibility.
Pretty much anything built by man is subject to errors. That includes source code -- open or closed. Any sane programmer knows this. The difference with open source is that the code is open to the users. Especially in the case of security, correctness is a high priority for many users, and those users can drive the bug-hunt process. As such, bugs tend to get found and fixed (sometimes proactively) faster with Free and Open Source code than with proprietary code.
For companies, on the other hand, security and correctness, in general, is a cost centre. It's often only pursued to the extent to which ignoring it affects profits. If it's considered better for the bottom line to ignore/hide a critical security bug than to fix it, then it may never get fixed. -- "Better for the bottom line" includes being paid to keep a bug open by the NSA/KGB/MOSAD/etc. The well-being of the customer base is only a (indirect) part of the profit calculation.
"Bad for the bottom line." Includes fixing code that you're no longer actively selling -- unless the bug hurts your public image too badly.
That's why, for example, XP is no longer going to be supported -- despite the fact that perhaps hundreds of millions of machines still use it.
Redhat 7.2 isn't officially supported by Red Hat, either -- but despite the fact that the current user base is probably in the range of hundreds or thousands, somebody who considers it critical infrastructure and can't/won't upgrade it can still arrange to get bug fixes because the source is legally available. RedHat isn't the gatekeeper for support the way that Microsoft is for Windows. RedHat is simply the (highly) preferred source of support.
That's pretty much the exact opposite experience I've had. I've never had an issue with BT audio, even once. Range seems to top out at about 30 ft and for music listening, is perfect. I've run in to audio lag (20-40ms) issues when streaming audio to bottom tier $20 adapters but it's completely replaced physical audio cables in my house. The sounds system in the living room and bedroom both use it exclusively and I just stream to either/or from my phone as the "head unit" and use the speaker system as a dumb Amp.
TIme for a mass refund. period.
(also time for some law firm to make megabucks litigating this issue)
What Netflix is paying for is "a peering tie-in inside of Comcast's data centers".
You can call 'protection money' whatever you want. It's still Extortion.
Not only does TC do a poor job protecting my data, but when an attacker does manage to guess a user's low-entropy password, he can then try that password all over the place to see where else the user has used it
That's not at all unique to TrueCrypt. If someone guesses a user's password, it's the user's fault they used the same password elsewhere.
Password-strengthening before encryption is not the same as salting & hashing passwords for later authentication, where rainbow tables and "guessing" a password makes sense -- we're not talking about storing the resulting strengthened password where it could directly attacked