Any black hole produced by a cosmic ray would still be moving at 99.9% of C (or above, but who's counting?). It'd blow right through us.
Any black hole produced by the LHC would be moving at, oh, thousands of miles an hour. It'd take quite a while before one randomly got below escape velocity. Say, a few months.
It's fairly likely that cosmic rays hitting us *do* produce black holes, which then evaporate nearly instantly.
Okay, so far so good, but what would happen if they didn't evaporate? Well, the black holes would still be moving at 99.9% of C, so would have no chance to lodge inside the earth..
LHC, on the other hand, uses two particle streams colliding head on. Any resulting black holes should be standing nearly still in comparison - most likely more than one in a million will in fact be moving less than escape velocity. Of course, that does probably give us time to notice that they're not evaporating before one stays; unfortunately, some of the ones that escape will end up inside the *sun* instead.
Now, as to reactions happening inside the sun.. you may have a point there. I don't know; if you do, I'd like a reference.
While you're probably right, it's worth noting that there is both (a) some doubt about the nature of gravity at small scales and high gradients, and (b) considerably more doubt about whether the hawking effect is at all real.
Hawking radiation is, after all, based on the intersection of quantum mechanics and general relativity. Not the best demonstrated, or even defined, part of science.
Certainly, but then what happens to the energy that was driving the turbine? It doesn't go away; if you stop pulling some-large-number-of-megawatts from the reactor core, it'll overheat in short order and shut down. Which, come to think of it, could have been what happened here. (It isn't, in this case)
I read a blog article a while back that explains one possible solution quite well - one that strikes me as far more elegant than the monster that is IPv6. Yes, I know there are security issues with LSRR, but they certainly aren't insurmountable. Why is nobody looking at this?
Article, verbatim
The Soapbox New ideas in computers, networking, and technology in general " Lightweight Multicast (LWM) Will Multicast kill Packet Switching? " NAT and the Failure of Source Routing
Paul Francis, in the conclusion of his 1994 Ph.D. thesis, traces the evolution of the IPv4 address scheme. After quoting a June 1978 Clark/Cohen paper (IEN 46), Francis notes:
Well, something happened here. An argument was put forth that 32 bits is enough because the address does not have to do routing - the source route can handle the rest. Clearly it was recognized that a variable length something was needed, but the source route was deemed sufficient for that, and the 32-bit address won out in the end. So, perhaps what killed IP is not that the address is too short (though probably it is), but that the ability for DNS to hand a host a source route (which it could then put in the header so that the right thing could happen in the network) was not created.
(p. 177)
Not only did the failure to fully implement source routing (in DNS) make it impossible to address into a private network, it also created the situation where NAT had to be implemented as it was.
Consider the following network:
**** Deleted by lameness filter. Click article link above. ****
H1 is on a private network. H2 is a server of some kind on the public network. The two networks are interconnected by a router with address X on the private network and address Y on the public net.
Can H1 initiate a working TCP session to H2 without NAT tables on the router? The answer is yes! H1 addresses its packet as follows. Address X is the IP Destination Address. A Loose Source and Record Route (LSRR) option is also used with a single address - H2's. What happens?
Well, the packet routes first to X on the private network, then the LSRR is processed. RFC 791:
If the address in destination address field has been reached and the pointer is not greater than the length, the next address in the source route replaces the address in the destination address field, and the recorded route address replaces the source address just used, and pointer is increased by four.
The recorded route address is the internet module's own internet address as known in the environment into which this datagram is being forwarded.
So H2's address is moved into the destination address field. Yet note carefully what else happens. The "recorded route address replaces the source address", and the "recorded route address is the... internet address as known in the environment into which this datagram is being forwarded". So address Y is placed into the LSRR option!
So H2 receives a packet addressed to it (of course), with H1's private IP address as the source address and an LSRR option listing the address Y. This is enough information to construct a return packet addressed to Y with H1 listed in an LSRR option. Now, can H1 count on H2 to do this? According to RFC 1122 (section 4.2.3.8) it can:
When a TCP connection is OPENed passively and a packet arrives with a completed IP Source Route option (containing a return route), TCP MUST save the return route and use it for all segments sent on this connection.
So far, it certainly seems like we don't need NAT! What's the problem, then? Well, consider what H1's routing table has to look like:
Yes, IF the hawking effect actually exists. Given the consequences if they're wrong, though.. um, why are we in such a hurry? Can't we build this on mars or something?
So you use a non-copied area for those, and suffer the fragmentation. The areas that *do* get copied will still be large enough to greatly decrease overall fragmentation.
Those functions look familiar. Let me see... oh yes, they're the most basic manipulations in functional programming, and have nothing to do with threading per se. Mind you, functional languages/are/ a whole lot easier to multithread than ancient creaky things like C++.;)
I have a feeling that, once four cores or more become common, the 30-70% slowdown you get from using Haskell instead of C++ will be dwarfed by the 3-7x speedup from easier parallelization.
Now, I might be mistaken, but what does *that* say about anything? It's easy to find high-permittivity materials; it's very hard (not to say impossible) to find any that don't end up saturating, thus breaking that nice, simple capacitance formulat you'd find on wikipedia.
I'm not going to believe this has any actually worthwhile energy density until they test the density, which as far as we know hasn't been done. Smells like a scam, tastes like a scam.. only the investor they picked makes me think it might not be one, but time will tell.
So what's stopping you from using an incremental, parallel GC and skipping the entire issue?
You could even combine that with aging out old assets. If it hasn't been touched in a while, drop it (and handle the sigsegv if something unexpectedly reads it), then all you have to do is get reasonable preloading in. It's not rocket science.
It further strikes me that if spinning up takes that much power, you can use more time. Or charge some capacitors first, if that isn't an option for some reason.
Slashdot Mirror
Any black hole produced by a cosmic ray would still be moving at 99.9% of C (or above, but who's counting?). It'd blow right through us.
Any black hole produced by the LHC would be moving at, oh, thousands of miles an hour. It'd take quite a while before one randomly got below escape velocity. Say, a few months.
Is nature doing head-on collisions at energies high enough to produce black holes?
Yes, it'd only alter the *velocity* of the resulting black hole, but feel free to calculate how fast a cosmic-ray-induced black hole would be moving.
It's fairly likely that cosmic rays hitting us *do* produce black holes, which then evaporate nearly instantly.
Okay, so far so good, but what would happen if they didn't evaporate? Well, the black holes would still be moving at 99.9% of C, so would have no chance to lodge inside the earth..
LHC, on the other hand, uses two particle streams colliding head on. Any resulting black holes should be standing nearly still in comparison - most likely more than one in a million will in fact be moving less than escape velocity. Of course, that does probably give us time to notice that they're not evaporating before one stays; unfortunately, some of the ones that escape will end up inside the *sun* instead.
Now, as to reactions happening inside the sun.. you may have a point there. I don't know; if you do, I'd like a reference.
While you're probably right, it's worth noting that there is both (a) some doubt about the nature of gravity at small scales and high gradients, and (b) considerably more doubt about whether the hawking effect is at all real.
Hawking radiation is, after all, based on the intersection of quantum mechanics and general relativity. Not the best demonstrated, or even defined, part of science.
Hang on.
I thought pedestrians weren't allowed on your highways?
Of course it's a bug. The problem is, it's a bug in the *OS*, or in the drivers - not necessarily in the games.
What are they supposed to do? Rewrite the OS for each game? Buy out nVidia and force them to write decent drivers?
If you want to do experiments in gravity, we've got some right here.
So, if the power fails *and* the fire alarms fail (for whatever reason, perhaps because it got burnt), you're locked in.
Wonderful design there. Hopefully the building is like ours, with many large windows you can break.
Certainly, but then what happens to the energy that was driving the turbine?
It doesn't go away; if you stop pulling some-large-number-of-megawatts from the reactor core, it'll overheat in short order and shut down. Which, come to think of it, could have been what happened here. (It isn't, in this case)
I read a blog article a while back that explains one possible solution quite well - one that strikes me as far more elegant than the monster that is IPv6. Yes, I know there are security issues with LSRR, but they certainly aren't insurmountable. Why is nobody looking at this?
Article, verbatim
The Soapbox
New ideas in computers, networking, and technology in general
" Lightweight Multicast (LWM)
Will Multicast kill Packet Switching? "
NAT and the Failure of Source Routing
Paul Francis, in the conclusion of his 1994 Ph.D. thesis, traces the evolution of the IPv4 address scheme. After quoting a June 1978 Clark/Cohen paper (IEN 46), Francis notes:
Well, something happened here. An argument was put forth that 32 bits is enough because the address does not have to do routing - the source route can handle the rest. Clearly it was recognized that a variable length something was needed, but the source route was deemed sufficient for that, and the 32-bit address won out in the end. So, perhaps what killed IP is not that the address is too short (though probably it is), but that the ability for DNS to hand a host a source route (which it could then put in the header so that the right thing could happen in the network) was not created.
(p. 177)
Not only did the failure to fully implement source routing (in DNS) make it impossible to address into a private network, it also created the situation where NAT had to be implemented as it was.
Consider the following network:
**** Deleted by lameness filter. Click article link above. ****
H1 is on a private network. H2 is a server of some kind on the public network. The two networks are interconnected by a router with address X on the private network and address Y on the public net.
Can H1 initiate a working TCP session to H2 without NAT tables on the router? The answer is yes! H1 addresses its packet as follows. Address X is the IP Destination Address. A Loose Source and Record Route (LSRR) option is also used with a single address - H2's. What happens?
Well, the packet routes first to X on the private network, then the LSRR is processed. RFC 791:
If the address in destination address field has been reached and the pointer is not greater than the length, the next address in the source route replaces the address in the destination address field, and the recorded route address replaces the source address just used, and pointer is increased by four.
The recorded route address is the internet module's own internet address as known in the environment into which this datagram is being forwarded.
So H2's address is moved into the destination address field. Yet note carefully what else happens. The "recorded route address replaces the source address", and the "recorded route address is the... internet address as known in the environment into which this datagram is being forwarded". So address Y is placed into the LSRR option!
So H2 receives a packet addressed to it (of course), with H1's private IP address as the source address and an LSRR option listing the address Y. This is enough information to construct a return packet addressed to Y with H1 listed in an LSRR option. Now, can H1 count on H2 to do this? According to RFC 1122 (section 4.2.3.8) it can:
When a TCP connection is OPENed passively and a packet arrives with a completed IP Source Route option (containing a return route), TCP MUST save the return route and use it for all segments sent on this connection.
So far, it certainly seems like we don't need NAT! What's the problem, then? Well, consider what H1's routing table has to look like:
Destination
Yes, IF the hawking effect actually exists.
Given the consequences if they're wrong, though.. um, why are we in such a hurry? Can't we build this on mars or something?
Speaking as someone who uses that packages and *does* run a font server on another machine, this is a good thing.
You Do Not Mention the FSAT.
(No, it's actually FAst Search and Transfer)
Wait, what?
How would that be a copyright violation?
You still have a license, right?
Fortunately, that part of the license isn't enforceable in most of the world
Ignore GP; it works that way on unix as well.
He used to be correct, but that was a decade or two ago.
So you use a non-copied area for those, and suffer the fragmentation.
The areas that *do* get copied will still be large enough to greatly decrease overall fragmentation.
Does it, now.
/are/ a whole lot easier to multithread than ancient creaky things like C++. ;)
Those functions look familiar. Let me see... oh yes, they're the most basic manipulations in functional programming, and have nothing to do with threading per se. Mind you, functional languages
I have a feeling that, once four cores or more become common, the 30-70% slowdown you get from using Haskell instead of C++ will be dwarfed by the 3-7x speedup from easier parallelization.
Permittivity testing?
Now, I might be mistaken, but what does *that* say about anything?
It's easy to find high-permittivity materials; it's very hard (not to say impossible) to find any that don't end up saturating, thus breaking that nice, simple capacitance formulat you'd find on wikipedia.
I'm not going to believe this has any actually worthwhile energy density until they test the density, which as far as we know hasn't been done. Smells like a scam, tastes like a scam.. only the investor they picked makes me think it might not be one, but time will tell.
So what's stopping you from using an incremental, parallel GC and skipping the entire issue?
You could even combine that with aging out old assets. If it hasn't been touched in a while, drop it (and handle the sigsegv if something unexpectedly reads it), then all you have to do is get reasonable preloading in. It's not rocket science.
"One may bask at the warm fire of faith or choose to live in the bleak certainty of reason - but one cannot have both."
You can't even make an informed, rational decision. By the time you know enough to do so, the conclusion is inevitable.
It's perfectly possible, you just have to use a volume manager like LVM to concatenate the partitions
Oh, but we do know how it behaves like a wave or a particle. Or, more precisely, neither. Just don't mix in gravity (or, well, movement).
:)
Quantum physics 101.
It further strikes me that if spinning up takes that much power, you can use more time. Or charge some capacitors first, if that isn't an option for some reason.
It's called "insightful".
Now mod me underrated for no actual reason.