you're also forgetting that by traveling at near light speed, time comes to a virtual standstill. so 'we'll be ariving in alpha centauri in about 5 minutes' takes relativistically a few million earth years.
Of course not. AC is ~4.3 light years away, so in Earth's frame of reference a ship travelling at 99.9999% lightspeed will get there is just over 4.3 years, not "a few million".
Surely time dilation effects would significantly lessen the amount of air and food that needs to be carried?
Yes, that was exactly my point. There's another odd effect caused by near light-speed travel: If you fly straight at an observer at near light-speed, the observer sees you approaching faster than the speed of light. This is, of course, an illusion, but an illusion that affects all measuring devices (e.g., radar, eyes, telescopes, etc.). This happens because your ship is following very closely behind the photons it emits and reflects.
This is a great way to surprise an enemy that is light years away. Approach at close enough to light-speed, and the enemy will see you cross the last few light years of distance in just days, leaving them no time to prepare.
Well, considering that the nearest star systems are greater than 4.3 light years away, you do not have to worry about it, as you would be dead from starvation.
If the vehicle travels close enough to the speed of light, the trip will take just months, weeks, or even days for those onboard. Near light-speed travel is a great way to conserve life-support resources for long trips.
Sure. But first can you find me something to store a key that is approximately 2.247x10^290 Exabytes.
Good point. There aren't even 2^1024 subatomic particles in the visible universe (including photons), so there isn't even enough stuff to store a 2^1024 bit key (assuming 1 bit per particle).
Can't you exponentially increase the difficulty of breaking encryption just by adding bits to the key?
No. That's how it works with conventional computers, but as an earlier poster mentioned, adding bits to a key will only result in a linear increase in difficulty for a quantum computer. That's why quantum computing is so potentially troublesome.
So why not add an exponential number of bits to the key instead of adding a linear number of bits? Instead of adding 1024 bits to the key, add 2^1024 bits? Quantum computers still have to do work, and that work takes time. If you use quantum computers to encrypt with exponentially larger keys, then even a quantum computer will have more work to do to crack the key.
Are there any one-way functions that are exponential even when executed by a quantum computer? If so, those would be candidates for QC-resistant cryptosystems.
Interesting, Doug Stanhope doing a similar thing that Jim Norton has been doing on Opie & Anthony for years now. Looking forward to hearing if he brings anything to the table.
I would like to hear what kind of show lil Jim Norton would do on XM if he had one of his own, but I also hope he wouldn't leave O&A's show. The three of them are very funny together.
On another note altogether, what are the chances that the industry can't support two satellite radio companies? It's like Betamax and VHS all over again -- people don't want to buy two different kinds of hardware to have choice. I don't need an NBC television to watch NBC programming and a CBS television to watch CBS television. Long term, XM and Sirius may merge (or XM may buy Sirius), thus unifying their hardware (and their audience).
One again, O&A may end up working for the same company as Mel and Howard. Hoo hoo.
I would think that a DHT should be searchable with O(1) complexity. After all, it's fundamentally a hash table. Imagine a DHT that maps an album name (the key) to a BitTorrent swarm IP list (the value), which it exactly what Azureus and the new BitTorrent client do. Naturally, if you know the song name exactly, you can search for it in O(1) operations, but if you want to search for just one or two words in the album name, there's no way to do it.
But if you inserted key/value pairs in the DHT where the key was a word from the album name and the value is a list of full album names, you can find all swarms sharing all albums containing the word "umbrella" (for instance) in two O(1) lookups (which I think still has O(1) complexity). The first lookup is: search("umbrella") -> list-of-full-albums-names. And the second lookup is: search("a full album name") -> swarm-IP-list.
Either that, or someone will write a new protocol that doesn't require trackers. [...] Sooner or later someone less lazy than me will graft [...] decentralized peer discovery onto BitTorrent, and trackers will be a thing of the past.
Umm. BitTorrent and Azureus already have decentralized peer discovery. See this Slashdot article for details.
Distributed Hash Tables (DHTs) are scalable peer-to-peer systems
that support exact match lookups. This paper describes the
construction and use of a Prefix Hash Tree (PHT) -- a distributed
data structure that supports range queries over DHTs. PHTs
use the hash-table interface of DHTs to construct a search tree
that is efficient (insertions/lookups take O(log log |D|) DHT
lookups, where D is the data domain being indexed) and robust
(the failure of any given node in the search tree does not
affect the availability of data stored at other nodes in the PHT).
It's impossible for 2 clients who are both behind different NAT firewalls to initiate connections to each other...
Not true. If at least one of the NAT firewalls supports UPnP configuration, then the client behind that firewall can request the firewall to forward inbound connections to a given port (e.g., 6881 for BitTorrent).
Anyone who has read up on DHTs will know that there a solid, theoretically proven, distributed storage system. However, they also have two flaws: neither fuzzy searches nor load-balancing can easily be done. For bit-torrent only the latter matters, but I'd still like to know how the nodes (A constant n number of nodes, according to the linked article) that are assigned the torrent for Star Wars Ep III are supposed to survive the onslaught of downloaders.
The data stored in the DHT by Azureus and the new BitTorrent is not the content being distributed (i.e., an album or movie) but instead the list of swarm IP addresses. For a swarm with 1000 nodes, that's only a few KBs of data -- far less for smaller swarms. Plus, a node can store copies of its DHT data at nearby nodes to provide redundancy and some amount of load sharing. (Here, "nearby" means "nearby in the hash function domain" not "nearby physically" or "nearby in network hops".)
A much more interesting but similar system is the dijjer project at dijjer.org.
It's different in that all of the data being distributed exists in a single system, not in grouped systems of people interested in the same file. Therefore there's a lot less concern about there being too few peers signed on to make the system work. [Emphasis mine. -- franl]
But the main point of BitTorrent is that downloaders reduce the bandwidth load on the publisher by contributing their upload bandwidth to the swarm. If "all of the data being distributed exists in a single system", then that system bears the entire bandwidth load.
Apparently BitTorrent, Azureus and Mainline all use the same protocol.
BitTorrent:
A clever protocol, based on a Kademlia distributed hash table or "DHT", allows clients to efficiently store and retrieve contact information for peers in a torrent.
Azureus:
Azureus uses an implementation of Kademlia for its distributed database. Kademlia is a type of distributed hash table (DHT). The basic idea behind DHTs is that they are flexible enough to support new users and leaving users while storing and finding information efficiently.
Mainline/khashmir:
Khashmir is a Distributed Hash Table (DHT) based on Kademila and written in Python.
I'm not convinced that the above prose shows that the protocols are interoperable. Even slight differences in implementations can make the clients non-interoperable. They may all use Kademlia, but if they encapsulate the Kademlia traffic in different (incompatible) ways on the wire, then there's a problem.
What got me about the picture was the amount of stars visible BEHIND the supposed dark matter galaxy.
The thing is 50 million light years away. The stars you see in the picture are in our galaxy, and thus in the foreground. The only things you would see behind it are normal galaxies.
Hydrogren gas is not dark matter. Dark matter is non-baryonic (i.e., not made of baryons -- the nucleus of a Hydrogen atom is a baryon). Dark matter does not interact electromagnetically, so it is probably more accurate to call it "transparent matter" (but the name "dark matter" has stuck).
Slashdot Mirror
This is a great way to surprise an enemy that is light years away. Approach at close enough to light-speed, and the enemy will see you cross the last few light years of distance in just days, leaving them no time to prepare.
Hoo hoo, Robin. I invented Warp Drive.
Sounds like someone was trying to tell you about Louis Slotin's demise, caused by "tickling the dragon's tail":
Are there any one-way functions that are exponential even when executed by a quantum computer? If so, those would be candidates for QC-resistant cryptosystems.
Their XM show is great. Better than ever. Go to xmradio.com for a free 3-day streaming audio trial.
On another note altogether, what are the chances that the industry can't support two satellite radio companies? It's like Betamax and VHS all over again -- people don't want to buy two different kinds of hardware to have choice. I don't need an NBC television to watch NBC programming and a CBS television to watch CBS television. Long term, XM and Sirius may merge (or XM may buy Sirius), thus unifying their hardware (and their audience).
One again, O&A may end up working for the same company as Mel and Howard. Hoo hoo.
But if you inserted key/value pairs in the DHT where the key was a word from the album name and the value is a list of full album names, you can find all swarms sharing all albums containing the word "umbrella" (for instance) in two O(1) lookups (which I think still has O(1) complexity). The first lookup is: search("umbrella") -> list-of-full-albums-names. And the second lookup is: search("a full album name") -> swarm-IP-list.
Can this work?
My understanding is that Dark Matter does not interact electromagnetically, so it neither reflects nor absorbs light.
Hydrogren gas is not dark matter. Dark matter is non-baryonic (i.e., not made of baryons -- the nucleus of a Hydrogen atom is a baryon). Dark matter does not interact electromagnetically, so it is probably more accurate to call it "transparent matter" (but the name "dark matter" has stuck).
'nuf said.
Based on last night's observations, the impact risk is now up to 1-in-42: http://neo.jpl.nasa.gov/risk/2004mn4.html