Unless you're talking about building from lunar resources, you're talking about bringing payloads up from LEO, then from LEO to the moon, then from LTO to the lunar surface (in a non-crashing manner). WAY more expensive than building on Earth or in LEO. If you're talking about building from lunar resources, we're nowhere even near to that being economically justifiable due to manufacturing process consumables and the absurd cost of assembly/maintenance (because it's so expensive to get people to and keep people alive on the moon, your labor costs are correspondingly absurdly high).
Even chemical fuels have hardly evolved as far as is physically possible. Metastable compounds offer a whole new class of propellants with performance as much as an order of magnitude greater than current propellants. Cryogenic solid and hybrid rockets have hardly even been studied yet (you can even use solid oxidizers). Etc. And then there's the whole other class of improvements: spacecraft mass. Anyone here want to argue that materials have advanced as far as they're ever going to? Anyone?
Then, as you mentioned, nuclear energy is tremendous -- and need not be harnessed directly (you don't have to have a radioactive plume shooting out the back). There's also external energy delivery mechanisms, so your craft need not carry its energy onboard. And there are even some more radical concepts that I know some people who are working on. I can't discuss all of them, as not all of them have been published about yet, but I'll point out one that has: digital quantum batteries. This involves storing energy in arrays of nanocapacitors, whose small size enables quantum effects to require huge voltages for dielectric breakdown. When you take quantum effects into account for energy storage, the theoretical upper bounds on your energy density are similar to that of nuclear reactions (although the specific case I mentioned has tensile strength limits which are much lower -- but this does not apply to all systems).
And finally, the whole premise of the article is totally wrong. The article acts as though energy costs are the primary -- or even a major -- cost of launching rockets. They're not. If you can make a rocket where your propellant cost is a significant fraction of your launch costs, you're doing something *right*. Rocket costs are overwhelmingly parts and labor. Anyone want to make an argument that parts and labor costs on a complex system can never be reduced? Anyone?
Pretty much everything they wrote is wrong. For example, concerning the difficulty of mining water, etc off-world:
Davies' hope is that the colonisers might be able to survive indefinitely by mining oxygen, water, hydrogen and other resources at the destination. While possible in principle, this would be very difficult in practice because of the low grade of the resources.
*What*? We can't mine ice because it's "low grade"? What on Earth is he talking about? Many bodies in our solar system are covered in, or at least have regions of, nearly pure ice. Mars deposits 100% pure frost on surfaces near its poles. The frost will get contaminated by dust, of course, but it's freaking dust. If you can't filter dust out of water, something is wrong with you. "Other resources"? Like what, iron? Lunar regolith is 1-2% pure iron. Not iron oxide -- *metallic*. As in, "attract it with a magnet and then melt it". Iron miners on Earth would kill to be able to get iron that easily. Low grade resources my arse. The problem with off-planet mining is the cost and difficulty of engineering and transporting light-weight, highly autonomous mining/processing equipment and providing them with their needed consumables and maintenance. It has nothing to do with the quality of the resources.
I think it'd be safe to say that the quality of work they produce is often equivalent to what your average scientific team produces *before* it goes through the peer-review process.
The TV show is not the equivalent of a journal publishing results, but of the team submitting to a journal. The Mythbuster Forums are the closest thing they have to peer-review. They then often "resubmit" to the journal to address the criticisms.
It's not a perfect analogy, but it's not too far off. A team of "not on TV" scientists is hardly immune to mistakes, even stupid ones. The difference is that the peer-review process (usually) catches them.
Actually, "real" scientists are encouraged when their experiment fails. Failure is where they get to expose the true nature of whatever it is they are studying.
The greatest phrase in science, the phrase that most often proceeds revolutionary breakthroughs, is not "Eureka!" but "Huh... that's odd...."
I'm not surprised that sodium silicate worked. I have some of that stuff for hydroponics usage. It crusts up everything it touches even *without* trying -- including the eyedropper I use to measure it. Silica really doesn't like to stay in solution;) Now, yeah, a silica encrustment isn't exactly a permanent patch, but it doesn't need to be, unless they're planning to just abandon the site tomorrow.
4 hours, with the special 70A at 240V charge connector [teslamotors.com] that you have to have installed by an electrician
That is the standard charger that most Tesla Roadster owners buy. And it's 3 1/2 hours (note the "less than 4 hours" -- I assume you know what "less than" means). The standard for home construction in the US today is 200A service. And the vehicle generally charges at night when you're not using much power elsewhere anyway. Or is your impression of people who live in dingy old farmhouses from the 1930s with 60A circuits buying Tesla Roadsters?
What's more, Top Gear were talking about scenarios like a trip to Scotland,
Wait, so now you're presenting the vehicle as instead of a track car, a long-distance cruiser? Anyway, here in the US, where most of their sales are, dryer sockets are 30A/240V, range sockets are 50A/240V, and RV sockets are 50A/240V (same connectors). I don't know what you in the UK use for your high power sockets, mind you. Yes, you *can* charge a Roadster on a normal socket, but it's not designed for that. Normal sockets are basically for emergencies-only, to give you enough power to get to the next *real* charging station.
Let's be clear: Top Gear *lied*. They said it ran out (it didn't). They said that it has to take 18 hours to charge (it doesn't, and almost no Tesla Roadster owner will ever charge their car on a standard socket; that's not what they're designed for).
And you are exactly the reason what's wrong with this show. You took the stuff they made up seriously.
1) It *doesn't* take 18 hours to charge a Roadster. It takes 3 1/2 hours from the normal charger it ships with. IIF you drain it completely dead. 2) *Neither* vehicle ran out of charge. There merely pretended they did.
Can you see why they're suing? People like you take this show seriously and believe the stuff they just made up.
And, FYI, no roadster goes 200 miles in actual track duty. Track duty generally cuts your MPG to 1/4 to 1/3 of what you get on the highway. At least the Roadster has regen for the curves.
There are just so many ways you can bust people using Tor. Here's just some. Any dedicated professional organization -- the RIAA, MPAA, CIA, China, etc -- can find you if they think it's worth their time and effort. Spending the resources to catch one person obviously would rarely be worth it, but the real concern is whether they feel it's worth it to laydown a blanket exploit to catch as many people as possible so they can filter through the ones they want to expose at their leisure.
Here's an example of why it's so damned hard to maintain anonymity on these networks. Alice is trying to do something online that Bob doesn't want her to do. So she uses Tor. Bob sees that someone is using Tor to break their rules. Bob starts a DOS against all IPs of potential infiltrators, one at a time, until suddenly, the bad activity stops. They let up on their DOS and it starts again. Bingo -- you've just figured out Alice's IP. It can happen so fast that all Alice experiences is a tiny network hiccup. But it gets easier. If Bob is a government, they don't even *need* to do a DOS; ISPs under their control can periodically probe their users for them. Or Bob can just rely on natural network outages and just correlate the outages with lulls in people doing the Bad Thing(TM).
This is but one type of attack against anonymity of these sort of networks out of dozens. There's Sybil attacks, where Bob makes a bunch of fake Tor identities, isolating Alice with a bunch of compromised nodes so that what she sends can be known for certainty that it originated with her. There's clock skew attacks, where you look at the user's unique clock skew when doing the bad thing (Tor has only partial immunity to this). There's cookie attacks, javascript attacks, browser property attacks (everything from user agent strings to browser window height), SSL client certificate attacks, and on and on in order to correlate private browsing with hidden browsing. And on and on and on.
What makes you think you need to break crypto to crack Tor? Have you never bothered to do a google search on Tor's known and unfixed vulnerabilities? Here's a top hit.
1) Tor and other such networks haveseveral *known, unresolved* vulnerabilities. Whenever you hear about something like this, you should read it as "another vulnerability discovered". One of the biggest problems such networks have is Sybil attacks, but they're hardly the only ones.
2) While it's technically possible to fileshare over Tor, it is discouraged and they do attempt to block it. If you want to do filesharing, you should be on I2P (which is also faster than Tor -- although still nothing you'd call "fast").
That's what I2P is for. No exit nodes, purely internal. It has a number of neat architectural differences from Tor to make it harder to attack and to improve performance. Also, for those who care, unlike Tor, I2P doesn't try to block filesharing.
Downsides: I2P is Java, so it eats more CPU. Also, it has a smaller userbase, meaning it's been less studied and isn't as resistant to takeover-style attacks like Sybil. And, obviously, you don't route to the outside world from I2P.
But once it was designed that way, you couldn't change it.
What made you think I was talking about something other than the design phase? I was talking about design of nuclear power plants, above, and compared it to the design of the shuttle. The design phase of the shuttle was the collision of hubris and slashed budgets.
You know, at this point, I'm almost tempted to say who cares what's damaged or not? The contamination is happening, no matter what the cause. Residets of Iitate, 40km from the reactor and outside the exclusion zone, are getting a free dental X-ray (40 microsieverts) every 4-6 hours (including pregnant women and children). That's merely considering radiation from external sources; if they feel much like breathing or eating, they'll be getting internal accumulation and exposure, which is orders of magnitude worse.
Sure, what exactly failed matters for the cleanup and post-mortem, but regardless of how it happened, Serious Problems Occurred(TM) that have to be dealt with.
That's the ever-overlooked aspect of these "invulnerable to failure" design scenarios. They seemingly never account for "unknown unknowns" (aka, we didn't realize tsunamis could get that big when it was built, and so simply assumed that they couldn't) and for human error.
One of the new reactor designs calls for a giant bathtub of water to be positioned overhead so, in the case of failure, it opens a valve and floods the reactor, keeping it cool for days. And in case of valve failure -- hey, they thought of everything, right? -- there are multiple valves. Great. Except...
* What if the valves are designed wrong? It doesn't matter how many "wrong" valves you had.
* What if whatever environmental factors caused one to fail -- corrosion, electrical short, whatnot -- was affecting all of the valves?
In these sort of cases, your redundancy turns out to be an illusion. This is what took the Challenger down. There were multiple layers of O-rings; a failure of one would not automatically cause a failure of the rocket. You'd need two failures in a given SRB segment to destroy the rocket. Well, at low temperatures, it turned out that a failure in one O-ring would automatically cascade on to the next. There was no redundancy, just an illusion of redundancy.
Design defects aren't the only kind of production human error that can really screw you up. Think for a second about the Pebble Bed Modular Reactor (PBMR), a much hyped, no-containment structure reactor (let me stress that part). You've got tens to hundreds of thousands of fuel pebbles flowing through the core, with pebbles regularly being evaluated and replaced. Great.... except that when you're talking about such vast number of fuel elements, you're pretty much guaranteed to get manufacturing defects. Pebbles will have poor cladding and leak (and what they leak will make their coolant -- whether in the core or as spent fuel -- contaminated, and potentially corrosive). Pebbles will be missized and jam, causing all sorts of problems (this already happened in Germany). Pebbles will shatter, and you better damned well hope that shattered remnants don't build up in the core, increasing its density. Jamming in the core could potentially be as problematic, leaving the pebbles unable to expand properly from heat stresses.
And here we are just talking about one type of failure mechanism (manufacturing defects) on one component (fuel pellets). I have much to gripe about that design and any other "we're so good we don't need a backup" (aka, containment structure) schools of thought (back to the space shuttle: there was no launch abort stack because, hey, it's so safe, why would they need that?). In the case of the PBMR, I also have serious issues with the "we can't have fire because the primary coolant is helium" claims. Leaks are inevitable in heat exchangers in thermal power plants of any kind. Your primary coolant will NOT stay pure helium. I've seen some Chinese designs, and there's a secondary water loop (even if there was not, there's atmospheric moisture to contend with). Graphite that hot (graphite being the PBMR moderator) reacts with water to produce... you guessed it... hot hydrogen. Without a containment structure, a hydrogen explosion would completely shred the core the same way it did the top of the Fukushima reactor buildings. Even without water/water vapor/steam in the core, a leak will let in oxygen, and contrary to many claims I've seen, nuclear-grade graphite *does* burn (once it's been contaminated/irradiated for long enough, at least). Burning graphite spread the radiation at Chernobyl.
Let's cast aside the hubris and be humble when designing things capable of causing such devastating economic damage (note the word "economic"; nuclear disasters are primarily economic disasters, not life-takers, because radiation exposure is a slow thing).
These sort of things are an inherent property of the very reason people use C/C++: performance/flexibility. A higher level language will automatically use a given assignment method for the members of an object -- usually copying. Got a member array, a member object, even member strings? They're going to be copied in memory -- enjoy your lousy performance. In C++, you can choose how to deal with them. Want to copy them? Go ahead. Want to have a second pointer reference to it? Go right ahead? Want to seize it? Thanks to C++0x move functionality, go right ahead. Deal with it however is most appropriate for your program. But obviously, this means that assignment is nontrivial. So yes, it gets more complicated -- but for a reason.
It's a feature, not a bug. And you know what? Give me that power, that performance. I'm sick and tired of programmers assuming that every program they write is going to be the only program that runs on my computer and can hog as much memory and CPU as they want to, squandering the blessing that Moore's Law has given us on bloat.
One of the main reasons why C/C++ are so popular is precisely the reason why there are so many complications with it. It's fast; it deals at a low level and gives you full control over what you're doing. Want something bounds-checked? Bounds check it. Don't want it bounds-checked? Don't bounds-check it. This sort of stuff falls over to assignment operators. A higher-level language, when you assign from rhs, will generally just automagically duplicate all member arrays and objects, even strings. Do you really want that? Well, it really depends on the situation. Sometimes you want it duplicated. Sometimes you want to point to it. And sometimes you'd rather seize it (thank you, C++0x move operators!). So by default, the programmer has to have flexibility in assignment. Which means that you can't count on simple assignment from any of your children if they can be arbitrary datatypes (such as from a template).
It's a feature, not a bug; it's an inherent complication from giving the programmer power to control how things happen. But, you know what? Give me that power. Contrary to what some would assert, performance *does* matter. I'm sick and tired of lazy programmers assuming that *their* app can afford to waste CPU and memory like there's no tomorrow and yielding up the gains of Moore's law to bloat.
C++ had a lot to criticize before. C++0x gets rid of most of it. You know, we no longer have other languages laughing their arses off at what passed for a foreach loop before with iterators over stl object making the for loop take 150 characters to write. C++ now has coding simplicity in many cases over a lot of languages that run at 1/10th its speed. It's still not perfect (the whole stl library needs an object-oriented makeover -- and can we finally instantiate main as "int main(std::<vector> args)"?). However, it is a big step forward.
Thanks to g++, I've been coding in C++0x for months. Programming without it has now become painful. 0x is such a huge leap. I love, love things like:
while (true) thread( [](shared_ptr p){ p->process(); }, Packet::read()).detach();
That's a one-line network subsystem;) In a loop, hang until you can read a packet, then process it in its own thread, continue reading new packets while it processes, and when a given packet finishes processing, delete it. Your "Packet" base class simply requires a factory read() method and a virtual process() function.
The only "gotcha" for me was that you still have to link in pthread.
Thread pairs very nicely with lambdas. Shared pointers were already fine in Boost, but it's nice to be able to ditch boost where possible. I can't wait for futures to make it into g++ as part of the c++0x standard. Futures + lambdas = trivial inline threading of arbitrary statements.
That's really the issue, now isn't it? If you wear down our roads more and put more !^$@ into our air for us to breathe, why *shouldn't* you pay a larger share of the costs? Why should the rest of us subsidize your personal damage to our roads and your personal damage to our healthcare system?
If their concern is EVs evading the gas tax, then mandate logging of kWh charged on the EV instead of miles logged on all vehicles. But in turn, taxes on EVs should be proportional to *their* damage to the roads and our air. Same with H2 cars, compressed air cars, wind-up crank cars, unicorn power cars, whatever.
Wow, I write a whole post talking about how deaths are not the issue -- long-term economic damages are -- and how the deaths to a nuclear disaster occur during the early chaos before people evacuate. And you write a rebuttal all about... deaths? During the early chaos before people evacuate?
You know, it's not a rebuttal when you're not addressing the point made by the person you're responding to.
The conversation is not "nuclear versus coal". The conversation is "nuclear versus wind", remember? And just to head you off:
Intermittent + Peaking = Baseload Intermittent + Storage = Baseload Intermittent + Geographic distribution = Less intermittent Intermittent + Other type of intermittent = Less intermittent
And to head you off on *that*, no, storage is not abnormally expensive. China already uses it extensively to buffer *demand* intermittency.
Only Unit 1 of Fukushima #1 was due to be decommissioned soon. And show me evidence that "anti-nuclear sentiment" was the cause for its 10-year extension -- as opposed TEPCO just wanting to leech as much profit out of it as they can.
Just an observation concerning evacuation and why the zones are sized the way they are. I pulled up my GeoNames database instance and started issuing some queries. GeoNames has cities from all over the world, but for small towns (under 20k or so), they don't have populations. So I'm assuming an average "small town" + "surrounding rural area" population of 4k. I add to that the size of the known cities within the radius to get an approximation of how many people have to be evacuated for each radius. It really sheds some light on why Japan is loathe to use the US's evacuation radius.
At 20km, the evacuation population is 89,866 -- most of them already evacuated due to the tsunami. (Japan did this early on) At 30km, the evacuation population is 145,866 -- most of them, again, already evacuated. (Japan just did this) At 50km, the evacuation population is 726,407 -- most of them *not* evacuated. At 80km -- the US recommendation -- the evacuation population is 2,376,494.
Japan would have a refugee crisis if they did that.
Plus a ton of smaller ones. So expect Japan to be *very* hesitant to expand their evacuation zone, even if things are found to be worse / get worse.
What's really sad is when you start going each of the evacuated cities and each of the cities destroyed by the tsunami and looking up what they were like. "This place had the longest cherry blossom tunnel in Japan". "This place was a close sister city with Auckland". And on and on. So much destruction, so much loss. Let's hope that the irradiated towns can be returned to before decay sets in, and that the tsunami-ravaged towns can be rebuilt and become habitable again.
Slashdot Mirror
Unless you're talking about building from lunar resources, you're talking about bringing payloads up from LEO, then from LEO to the moon, then from LTO to the lunar surface (in a non-crashing manner). WAY more expensive than building on Earth or in LEO. If you're talking about building from lunar resources, we're nowhere even near to that being economically justifiable due to manufacturing process consumables and the absurd cost of assembly/maintenance (because it's so expensive to get people to and keep people alive on the moon, your labor costs are correspondingly absurdly high).
Even chemical fuels have hardly evolved as far as is physically possible. Metastable compounds offer a whole new class of propellants with performance as much as an order of magnitude greater than current propellants. Cryogenic solid and hybrid rockets have hardly even been studied yet (you can even use solid oxidizers). Etc. And then there's the whole other class of improvements: spacecraft mass. Anyone here want to argue that materials have advanced as far as they're ever going to? Anyone?
Then, as you mentioned, nuclear energy is tremendous -- and need not be harnessed directly (you don't have to have a radioactive plume shooting out the back). There's also external energy delivery mechanisms, so your craft need not carry its energy onboard. And there are even some more radical concepts that I know some people who are working on. I can't discuss all of them, as not all of them have been published about yet, but I'll point out one that has: digital quantum batteries. This involves storing energy in arrays of nanocapacitors, whose small size enables quantum effects to require huge voltages for dielectric breakdown. When you take quantum effects into account for energy storage, the theoretical upper bounds on your energy density are similar to that of nuclear reactions (although the specific case I mentioned has tensile strength limits which are much lower -- but this does not apply to all systems).
And finally, the whole premise of the article is totally wrong. The article acts as though energy costs are the primary -- or even a major -- cost of launching rockets. They're not. If you can make a rocket where your propellant cost is a significant fraction of your launch costs, you're doing something *right*. Rocket costs are overwhelmingly parts and labor. Anyone want to make an argument that parts and labor costs on a complex system can never be reduced? Anyone?
Pretty much everything they wrote is wrong. For example, concerning the difficulty of mining water, etc off-world:
*What*? We can't mine ice because it's "low grade"? What on Earth is he talking about? Many bodies in our solar system are covered in, or at least have regions of, nearly pure ice. Mars deposits 100% pure frost on surfaces near its poles. The frost will get contaminated by dust, of course, but it's freaking dust. If you can't filter dust out of water, something is wrong with you. "Other resources"? Like what, iron? Lunar regolith is 1-2% pure iron. Not iron oxide -- *metallic*. As in, "attract it with a magnet and then melt it". Iron miners on Earth would kill to be able to get iron that easily. Low grade resources my arse. The problem with off-planet mining is the cost and difficulty of engineering and transporting light-weight, highly autonomous mining/processing equipment and providing them with their needed consumables and maintenance. It has nothing to do with the quality of the resources.
Who decided to give this person a platform?
I think it'd be safe to say that the quality of work they produce is often equivalent to what your average scientific team produces *before* it goes through the peer-review process.
The TV show is not the equivalent of a journal publishing results, but of the team submitting to a journal. The Mythbuster Forums are the closest thing they have to peer-review. They then often "resubmit" to the journal to address the criticisms.
It's not a perfect analogy, but it's not too far off. A team of "not on TV" scientists is hardly immune to mistakes, even stupid ones. The difference is that the peer-review process (usually) catches them.
The greatest phrase in science, the phrase that most often proceeds revolutionary breakthroughs, is not "Eureka!" but "Huh... that's odd...."
The yellowcake is a lie!
I'm not surprised that sodium silicate worked. I have some of that stuff for hydroponics usage. It crusts up everything it touches even *without* trying -- including the eyedropper I use to measure it. Silica really doesn't like to stay in solution ;) Now, yeah, a silica encrustment isn't exactly a permanent patch, but it doesn't need to be, unless they're planning to just abandon the site tomorrow.
That is the standard charger that most Tesla Roadster owners buy. And it's 3 1/2 hours (note the "less than 4 hours" -- I assume you know what "less than" means). The standard for home construction in the US today is 200A service. And the vehicle generally charges at night when you're not using much power elsewhere anyway. Or is your impression of people who live in dingy old farmhouses from the 1930s with 60A circuits buying Tesla Roadsters?
Wait, so now you're presenting the vehicle as instead of a track car, a long-distance cruiser? Anyway, here in the US, where most of their sales are, dryer sockets are 30A/240V, range sockets are 50A/240V, and RV sockets are 50A/240V (same connectors). I don't know what you in the UK use for your high power sockets, mind you. Yes, you *can* charge a Roadster on a normal socket, but it's not designed for that. Normal sockets are basically for emergencies-only, to give you enough power to get to the next *real* charging station.
Let's be clear: Top Gear *lied*. They said it ran out (it didn't). They said that it has to take 18 hours to charge (it doesn't, and almost no Tesla Roadster owner will ever charge their car on a standard socket; that's not what they're designed for).
And you are exactly the reason what's wrong with this show. You took the stuff they made up seriously.
1) It *doesn't* take 18 hours to charge a Roadster. It takes 3 1/2 hours from the normal charger it ships with. IIF you drain it completely dead.
2) *Neither* vehicle ran out of charge. There merely pretended they did.
Can you see why they're suing? People like you take this show seriously and believe the stuff they just made up.
And, FYI, no roadster goes 200 miles in actual track duty. Track duty generally cuts your MPG to 1/4 to 1/3 of what you get on the highway. At least the Roadster has regen for the curves.
Default exit policy: Link
There are just so many ways you can bust people using Tor. Here's just some. Any dedicated professional organization -- the RIAA, MPAA, CIA, China, etc -- can find you if they think it's worth their time and effort. Spending the resources to catch one person obviously would rarely be worth it, but the real concern is whether they feel it's worth it to laydown a blanket exploit to catch as many people as possible so they can filter through the ones they want to expose at their leisure.
Here's an example of why it's so damned hard to maintain anonymity on these networks. Alice is trying to do something online that Bob doesn't want her to do. So she uses Tor. Bob sees that someone is using Tor to break their rules. Bob starts a DOS against all IPs of potential infiltrators, one at a time, until suddenly, the bad activity stops. They let up on their DOS and it starts again. Bingo -- you've just figured out Alice's IP. It can happen so fast that all Alice experiences is a tiny network hiccup. But it gets easier. If Bob is a government, they don't even *need* to do a DOS; ISPs under their control can periodically probe their users for them. Or Bob can just rely on natural network outages and just correlate the outages with lulls in people doing the Bad Thing(TM).
This is but one type of attack against anonymity of these sort of networks out of dozens. There's Sybil attacks, where Bob makes a bunch of fake Tor identities, isolating Alice with a bunch of compromised nodes so that what she sends can be known for certainty that it originated with her. There's clock skew attacks, where you look at the user's unique clock skew when doing the bad thing (Tor has only partial immunity to this). There's cookie attacks, javascript attacks, browser property attacks (everything from user agent strings to browser window height), SSL client certificate attacks, and on and on in order to correlate private browsing with hidden browsing. And on and on and on.
What makes you think you need to break crypto to crack Tor? Have you never bothered to do a google search on Tor's known and unfixed vulnerabilities? Here's a top hit.
1) Tor and other such networks haveseveral *known, unresolved* vulnerabilities. Whenever you hear about something like this, you should read it as "another vulnerability discovered". One of the biggest problems such networks have is Sybil attacks, but they're hardly the only ones.
2) While it's technically possible to fileshare over Tor, it is discouraged and they do attempt to block it. If you want to do filesharing, you should be on I2P (which is also faster than Tor -- although still nothing you'd call "fast").
That's what I2P is for. No exit nodes, purely internal. It has a number of neat architectural differences from Tor to make it harder to attack and to improve performance. Also, for those who care, unlike Tor, I2P doesn't try to block filesharing.
Downsides: I2P is Java, so it eats more CPU. Also, it has a smaller userbase, meaning it's been less studied and isn't as resistant to takeover-style attacks like Sybil. And, obviously, you don't route to the outside world from I2P.
So you assumed something other than the obvious topic of the discussion in order to present me as wrong?
What made you think I was talking about something other than the design phase? I was talking about design of nuclear power plants, above, and compared it to the design of the shuttle. The design phase of the shuttle was the collision of hubris and slashed budgets.
You know, at this point, I'm almost tempted to say who cares what's damaged or not? The contamination is happening, no matter what the cause. Residets of Iitate, 40km from the reactor and outside the exclusion zone, are getting a free dental X-ray (40 microsieverts) every 4-6 hours (including pregnant women and children). That's merely considering radiation from external sources; if they feel much like breathing or eating, they'll be getting internal accumulation and exposure, which is orders of magnitude worse.
Sure, what exactly failed matters for the cleanup and post-mortem, but regardless of how it happened, Serious Problems Occurred(TM) that have to be dealt with.
That's the ever-overlooked aspect of these "invulnerable to failure" design scenarios. They seemingly never account for "unknown unknowns" (aka, we didn't realize tsunamis could get that big when it was built, and so simply assumed that they couldn't) and for human error.
One of the new reactor designs calls for a giant bathtub of water to be positioned overhead so, in the case of failure, it opens a valve and floods the reactor, keeping it cool for days. And in case of valve failure -- hey, they thought of everything, right? -- there are multiple valves. Great. Except...
* What if the valves are designed wrong? It doesn't matter how many "wrong" valves you had.
* What if whatever environmental factors caused one to fail -- corrosion, electrical short, whatnot -- was affecting all of the valves?
In these sort of cases, your redundancy turns out to be an illusion. This is what took the Challenger down. There were multiple layers of O-rings; a failure of one would not automatically cause a failure of the rocket. You'd need two failures in a given SRB segment to destroy the rocket. Well, at low temperatures, it turned out that a failure in one O-ring would automatically cascade on to the next. There was no redundancy, just an illusion of redundancy.
Design defects aren't the only kind of production human error that can really screw you up. Think for a second about the Pebble Bed Modular Reactor (PBMR), a much hyped, no-containment structure reactor (let me stress that part). You've got tens to hundreds of thousands of fuel pebbles flowing through the core, with pebbles regularly being evaluated and replaced. Great.... except that when you're talking about such vast number of fuel elements, you're pretty much guaranteed to get manufacturing defects. Pebbles will have poor cladding and leak (and what they leak will make their coolant -- whether in the core or as spent fuel -- contaminated, and potentially corrosive). Pebbles will be missized and jam, causing all sorts of problems (this already happened in Germany). Pebbles will shatter, and you better damned well hope that shattered remnants don't build up in the core, increasing its density. Jamming in the core could potentially be as problematic, leaving the pebbles unable to expand properly from heat stresses.
And here we are just talking about one type of failure mechanism (manufacturing defects) on one component (fuel pellets). I have much to gripe about that design and any other "we're so good we don't need a backup" (aka, containment structure) schools of thought (back to the space shuttle: there was no launch abort stack because, hey, it's so safe, why would they need that?). In the case of the PBMR, I also have serious issues with the "we can't have fire because the primary coolant is helium" claims. Leaks are inevitable in heat exchangers in thermal power plants of any kind. Your primary coolant will NOT stay pure helium. I've seen some Chinese designs, and there's a secondary water loop (even if there was not, there's atmospheric moisture to contend with). Graphite that hot (graphite being the PBMR moderator) reacts with water to produce... you guessed it... hot hydrogen. Without a containment structure, a hydrogen explosion would completely shred the core the same way it did the top of the Fukushima reactor buildings. Even without water/water vapor/steam in the core, a leak will let in oxygen, and contrary to many claims I've seen, nuclear-grade graphite *does* burn (once it's been contaminated/irradiated for long enough, at least). Burning graphite spread the radiation at Chernobyl.
Let's cast aside the hubris and be humble when designing things capable of causing such devastating economic damage (note the word "economic"; nuclear disasters are primarily economic disasters, not life-takers, because radiation exposure is a slow thing).
These sort of things are an inherent property of the very reason people use C/C++: performance/flexibility. A higher level language will automatically use a given assignment method for the members of an object -- usually copying. Got a member array, a member object, even member strings? They're going to be copied in memory -- enjoy your lousy performance. In C++, you can choose how to deal with them. Want to copy them? Go ahead. Want to have a second pointer reference to it? Go right ahead? Want to seize it? Thanks to C++0x move functionality, go right ahead. Deal with it however is most appropriate for your program. But obviously, this means that assignment is nontrivial. So yes, it gets more complicated -- but for a reason.
It's a feature, not a bug. And you know what? Give me that power, that performance. I'm sick and tired of programmers assuming that every program they write is going to be the only program that runs on my computer and can hog as much memory and CPU as they want to, squandering the blessing that Moore's Law has given us on bloat.
I'm going to take a wild guess and assume that you didn't have (or use) the "restrict" keyword?
One of the main reasons why C/C++ are so popular is precisely the reason why there are so many complications with it. It's fast; it deals at a low level and gives you full control over what you're doing. Want something bounds-checked? Bounds check it. Don't want it bounds-checked? Don't bounds-check it. This sort of stuff falls over to assignment operators. A higher-level language, when you assign from rhs, will generally just automagically duplicate all member arrays and objects, even strings. Do you really want that? Well, it really depends on the situation. Sometimes you want it duplicated. Sometimes you want to point to it. And sometimes you'd rather seize it (thank you, C++0x move operators!). So by default, the programmer has to have flexibility in assignment. Which means that you can't count on simple assignment from any of your children if they can be arbitrary datatypes (such as from a template).
It's a feature, not a bug; it's an inherent complication from giving the programmer power to control how things happen. But, you know what? Give me that power. Contrary to what some would assert, performance *does* matter. I'm sick and tired of lazy programmers assuming that *their* app can afford to waste CPU and memory like there's no tomorrow and yielding up the gains of Moore's law to bloat.
C++ had a lot to criticize before. C++0x gets rid of most of it. You know, we no longer have other languages laughing their arses off at what passed for a foreach loop before with iterators over stl object making the for loop take 150 characters to write. C++ now has coding simplicity in many cases over a lot of languages that run at 1/10th its speed. It's still not perfect (the whole stl library needs an object-oriented makeover -- and can we finally instantiate main as "int main(std::<vector> args)"?). However, it is a big step forward.
Thanks to g++, I've been coding in C++0x for months. Programming without it has now become painful. 0x is such a huge leap. I love, love things like:
while (true) thread( [](shared_ptr p){ p->process(); }, Packet::read()).detach();
That's a one-line network subsystem ;) In a loop, hang until you can read a packet, then process it in its own thread, continue reading new packets while it processes, and when a given packet finishes processing, delete it. Your "Packet" base class simply requires a factory read() method and a virtual process() function.
The only "gotcha" for me was that you still have to link in pthread.
Thread pairs very nicely with lambdas. Shared pointers were already fine in Boost, but it's nice to be able to ditch boost where possible. I can't wait for futures to make it into g++ as part of the c++0x standard. Futures + lambdas = trivial inline threading of arbitrary statements.
That's really the issue, now isn't it? If you wear down our roads more and put more !^$@ into our air for us to breathe, why *shouldn't* you pay a larger share of the costs? Why should the rest of us subsidize your personal damage to our roads and your personal damage to our healthcare system?
If their concern is EVs evading the gas tax, then mandate logging of kWh charged on the EV instead of miles logged on all vehicles. But in turn, taxes on EVs should be proportional to *their* damage to the roads and our air. Same with H2 cars, compressed air cars, wind-up crank cars, unicorn power cars, whatever.
Wow, I write a whole post talking about how deaths are not the issue -- long-term economic damages are -- and how the deaths to a nuclear disaster occur during the early chaos before people evacuate. And you write a rebuttal all about... deaths? During the early chaos before people evacuate?
You know, it's not a rebuttal when you're not addressing the point made by the person you're responding to.
Nice change of subject. *Applause*
The conversation is not "nuclear versus coal". The conversation is "nuclear versus wind", remember? And just to head you off:
Intermittent + Peaking = Baseload
Intermittent + Storage = Baseload
Intermittent + Geographic distribution = Less intermittent
Intermittent + Other type of intermittent = Less intermittent
And to head you off on *that*, no, storage is not abnormally expensive. China already uses it extensively to buffer *demand* intermittency.
Only Unit 1 of Fukushima #1 was due to be decommissioned soon. And show me evidence that "anti-nuclear sentiment" was the cause for its 10-year extension -- as opposed TEPCO just wanting to leech as much profit out of it as they can.
Just an observation concerning evacuation and why the zones are sized the way they are. I pulled up my GeoNames database instance and started issuing some queries. GeoNames has cities from all over the world, but for small towns (under 20k or so), they don't have populations. So I'm assuming an average "small town" + "surrounding rural area" population of 4k. I add to that the size of the known cities within the radius to get an approximation of how many people have to be evacuated for each radius. It really sheds some light on why Japan is loathe to use the US's evacuation radius.
At 20km, the evacuation population is 89,866 -- most of them already evacuated due to the tsunami. (Japan did this early on)
At 30km, the evacuation population is 145,866 -- most of them, again, already evacuated. (Japan just did this)
At 50km, the evacuation population is 726,407 -- most of them *not* evacuated.
At 80km -- the US recommendation -- the evacuation population is 2,376,494.
Japan would have a refugee crisis if they did that.
Why the rapid growth? These cities, mainly:
Iwaki (357,309): 43km
Koriyama (340,560): 57km
Fukushima (294,237): 62km
Plus a ton of smaller ones. So expect Japan to be *very* hesitant to expand their evacuation zone, even if things are found to be worse / get worse.
What's really sad is when you start going each of the evacuated cities and each of the cities destroyed by the tsunami and looking up what they were like. "This place had the longest cherry blossom tunnel in Japan". "This place was a close sister city with Auckland". And on and on. So much destruction, so much loss. Let's hope that the irradiated towns can be returned to before decay sets in, and that the tsunami-ravaged towns can be rebuilt and become habitable again.