>However, its important to remember that MOND cannot be considered a physical theory; >it is more of an empirical modification of known physical laws (like the Lorentz transformation was), >which still awaits a physical explaination.
And dark matter (or energy for that matter) is not an empirical modification of the known universe to suit the known physical laws?
At least MOND doesn't require huge amounts of matter and energy that nobody can detect to 'fix' the universe...
DVD is 8mbps, this link is 2.5Gbps. A dozen DVD's won't even make a dent in the capacity of this line, you'll need 2 to 3 hundred DVD's playing at once...
If you can show this (videowall) it would be very impressive!
And when will this compatibility end? Since everybody keeps using v4 addresses, there is no need for people to switch to v6. Is there going to be a worldwide 'lets stop using IPv4' day? Or are we going to stay compatible forever?
As lots of other people have already pointed out, they should have made IPv6 inherently compatible with IPv4, so there is no need to switch.
There is a header checksum field in IPv4, that (as far as I know) is only verified at the destination, and is totally useless. Use these 16 bits to extend the destination address, extend the source address using a V4 option field, and you have extended IPv4 addressing to 48 bits and kept the destination in the beginning of the header for hardware routing. And you are compatible with IPv4 so people that don't need to upgrade won't have to. You have also added addresses without increasing the routing complexity for the core.
This is just a little hack of the top of my head, I'm sure there are people out there that can do better. And my prediction is that somebody will do better and write a RFC for this. Two weeks later all free unices will have implemented this, two months later Cisco and Juniper and all the other big guys will add support for this feature in a software update, and a year later nobody will be using IPv6 anymore. IPv6 is like IPSec, designed by a commitee and dead ten years later.
But this is just my 2 cents, who knows what will happen.
Have you actually read the comment before responding? What the previous poster is saying is that sending a UDP packet out of a NATted net will create state that allows inbound UDP traffic with reversed src-dst. This works regardless of where the NAT happens or who configured it.
Multiplayer games have been doing this for years. The author of the originating post suggests using a publicly reachable server to negotiate the portnumbers to use, an alternative is to use high udp ports, eg: I send a UDP packet to your NAT gateway with src-dst ports = 30000. My NAT gateway translates the source IP to its IP, but leaves the source port the same (lazy translation) since it isn't used yet. This packet hits your NAT gateway and is dropped (out of state). But if you send a UDP packet to me at the same time, using the same src-dst port 30000, your NAT gateway will do the same translation, and after a couple of dropped packets, both NAT gateways will pass all UDP packets. (NAT gateways usually assume UDP traffic is bi-directional, so this works)
The net result is that you and I are communicating even though we are both hidden behind NAT gateways.
See http://www.doxpara.com/Black_Ops_Hivercon_Final.pp t slide 65 for source material and more hacks
Funny, I also work for a small ISP (in europe) and we buy our upstream for about 100 euros/mbps. If I check some of the providers in the US, they are willing to sell me uplink (1:1) for about $30/mbps (when I take 100Mbps)
So either you are a very small ISP (5 mbps total uplink) or somebody is screwing someone over somewhere;)
The TAT-14 is a ring between the US and Europe. The underside of this ring also connects the UK to the ring. Both failures were in the underside of the ring. The upper part of the ring is fine, and is currently in use.
This means that the UK cannot use the TAT-14, and some providers in France may have to reroute to Katwijk using landlines.
Yes, Spamcop, I remember that brilliant service. The biggest easiest email-DOS there is. Go over to their website and check out the fine print:
SpamCop administrators do not, and cannot verify the claims made by it's users. Not only are there simply far too many reports filed for anyone to manually review them, but even if we were to, there is no way for us to know whether a user actually did or did not solicit a message prior to reporting it as spam.
Therefore, it is trivial to DOS a domain:
-Get a couple of free emailaddresses -Fake a spam coming from the domain, just use a real spam and change the headers -send a report about the fake spam to spamcop using the free emailaddresses you've got -Bingo, the domain cannot send mail to all mailservers that use spamcop for filtering -if you want to be a real bastard, repeat every day, and they will never get of the blacklist;)
Since the gliders glide for a couple of miles on one buoyancy change, the pumps will be idle most of the time, and are allowed to be very very slow, and therefore very very quiet. The amount of water pumped in or out for the required buoyancy change is minimal, that's why they are planning to power the system using the temperature difference between the internal ballast tanks and the outside water temperature.
It is also possible to design the pumping system without moving parts, use the power generated by the temperature difference to make hydrogen and oxygen from water (totally silent). The hydrogen and oxygen will change the buoyancy of the sub if stored in flexible bladders in the ballast tanks. Then if you need to change the buoyancy the other way, power a fuel cell from the oxygen/hydrogen mixture, and store the energy in a battery for the next buoyancy change. This whole operation is (when properly designed) totally silent. Furthermore, if you create the glider from sonar-transparent (or semi-transparent) materials, and make sure that a large part of it is ballast tanks (further helping the sonar transparancy) the thing could be almost sonar transparent. Now make it small, about as small as a fish, and no sonar in the world will see it unless they have a magic real/fake fish filter.
It was my understanding that this system doesn't use sonar, it just listens with very sensitive mikes. Then when you correlate the soundplots you get from multiple places, you can pinpoint the source of the sound.
If the system is passive, it will not detect these 'gliders', since they are absolutely silent.
I'm not trying to 'pimp' DH as better, I'm just putting quantum crypto into perspective. Most people think of quantum crypto as the 'holy grail of crypto'. This is clearly not the case until somebody invents a quantum way of authenticating somebody.
Quantum crypto 'solves' the key exchange protocol. DH 'solves' the key exchange protocol. Quantum crypto might be safer. The problem is still authenticating Alice and Bob. The only way to do that in a useable way is public key. When you use public key you are dependant on the fact that nobody can factor big numbers. When using DH you are also dependant on that problem (okay, equivalent problem). Your weakest link is 'nobody can factor big numbers' whether you use Quantum crypto or public key crypto. Might as well use public key then, a lot cheaper.
What I'm trying to say is that Quantum Crypto is a very expensive 'solution' that is looking for a problem, and until quantum authentication is useable, nobody should be implementing it except for research purposes.
All these quantum authentication protocols use secret key crypto as a basis. So Alice and Bob have to exchange a secret key before using the system. Might as well use the secret key to encrypt the messages they want to send to each other.
Now if somebody finds a nice secure way of exchanging secret keys that is not susceptible to a man-in-the-middle attack, this quantum crypto stuff might be worth looking into, until then just use RSA/AES.
Eve can only be detected if she tries to eavesdrop on the line, not if she sits in the middle doing her own quantum key exchange protocol. The only way around this is to have Alice and Bob authenticate themselves against each other. Which is not possible with quantum crypto yet, so you have to use public/private key crypto.
When you have to use public/private key crypto, there is no reason to use quantum anymore, since a chain is as strong as it's weakest link so quantum crypto is worthless - QED
If it was written in Erlang or Mozart or Mercury, nobody would use it, since nobody knows anything about these languages.
Sure, in Java it is probably harder to write these kinds of distributed agents, but a lot more people can hack all kinds of interesting stuff onto the agents just because they can read Java code.
Minus 10% cutting loss when subnetting leaves you with more than 16 million ip addresses. So only really big corporations could have this problem (most of them have a public class A already).
Basically, you checksum the memory pages, if one fails its checksum, you try to correct the error, move the data to another page (virtual memory is great), and mark the page bad.
A bit like your harddisk does it.
You will however take a substantial performance hit on checksumming the memory pages, so in the long run ECC memory is probably better.
Slashdot Mirror
>However, its important to remember that MOND cannot be considered a physical theory;
>it is more of an empirical modification of known physical laws (like the Lorentz transformation was),
>which still awaits a physical explaination.
And dark matter (or energy for that matter) is not an empirical modification of the known universe to suit the known physical laws?
At least MOND doesn't require huge amounts of matter and energy that nobody can detect to 'fix' the universe...
--Blerik
.eml files are raw email files.
.eml files so you can doubleclick on them and read them in your email client, reply to them etc.
They are called
So nothing to see here, move along...
--Blerik
DVD is 8mbps, this link is 2.5Gbps. A dozen DVD's won't even make a dent in the capacity of this line, you'll need 2 to 3 hundred DVD's playing at once...
If you can show this (videowall) it would be very impressive!
--Blerik
Read transfer rate is fine, write transfer rate is incredibly slow.
--Blerik
You are correct, a heap overflow is more difficult than a stack overflow. But it is sometimes still possible, for instance:
t
http://www.xfocus.org/documents/200309/4.html
and
http://www.w00w00.org/files/articles/heaptut.tx
--Blerik
>OpenOffice can never get a foothold in academea
>while its chart-making is so poor, for example.
Uhm, OpenOffice can never get a foothold in academia because everybody uses LaTeX and GnuPlot
Which happens to be an open source product, and existed way before Linux.
--Blerik
You could try vivisimo.com, very commercial site, slow searches, but the results are very good.
HTH
--Blerik
And when will this compatibility end? Since everybody keeps using v4 addresses, there is no need for people to switch to v6. Is there going to be a worldwide 'lets stop using IPv4' day? Or are we going to stay compatible forever?
As lots of other people have already pointed out, they should have made IPv6 inherently compatible with IPv4, so there is no need to switch.
There is a header checksum field in IPv4, that (as far as I know) is only verified at the destination, and is totally useless. Use these 16 bits to extend the destination address, extend the source address using a V4 option field, and you have extended IPv4 addressing to 48 bits and kept the destination in the beginning of the header for hardware routing. And you are compatible with IPv4 so people that don't need to upgrade won't have to. You have also added addresses without increasing the routing complexity for the core.
This is just a little hack of the top of my head, I'm sure there are people out there that can do better. And my prediction is that somebody will do better and write a RFC for this. Two weeks later all free unices will have implemented this, two months later Cisco and Juniper and all the other big guys will add support for this feature in a software update, and a year later nobody will be using IPv6 anymore. IPv6 is like IPSec, designed by a commitee and dead ten years later.
But this is just my 2 cents, who knows what will happen.
--Blerik
Have you actually read the comment before responding? What the previous poster is saying is that sending a UDP packet out of a NATted net will create state that allows inbound UDP traffic with reversed src-dst. This works regardless of where the NAT happens or who configured it.
p t slide 65 for source material and more hacks
Multiplayer games have been doing this for years. The author of the originating post suggests using a publicly reachable server to negotiate the portnumbers to use, an alternative is to use high udp ports, eg: I send a UDP packet to your NAT gateway with src-dst ports = 30000. My NAT gateway translates the source IP to its IP, but leaves the source port the same (lazy translation) since it isn't used yet. This packet hits your NAT gateway and is dropped (out of state). But if you send a UDP packet to me at the same time, using the same src-dst port 30000, your NAT gateway will do the same translation, and after a couple of dropped packets, both NAT gateways will pass all UDP packets. (NAT gateways usually assume UDP traffic is bi-directional, so this works)
The net result is that you and I are communicating even though we are both hidden behind NAT gateways.
See http://www.doxpara.com/Black_Ops_Hivercon_Final.p
--Blerik
And how does your cute example solve the address shortage problem with IPv4?
;)
Since you still NEED an IPv4 address to be compatible with your IPv4 peer.
Basically you have reinvented NAT, except for v6 to v4. And everybody knows NAT is evil
--Blerik
Funny, I also work for a small ISP (in europe) and we buy our upstream for about 100 euros/mbps. If I check some of the providers in the US, they are willing to sell me uplink (1:1) for about $30/mbps (when I take 100Mbps)
;)
So either you are a very small ISP (5 mbps total uplink) or somebody is screwing someone over somewhere
--Blerik
Back here in Holland we call it the Pi rule, works the same, but more 'mystically correct' ;)
The TAT-14 is a ring between the US and Europe. The underside of this ring also connects the UK to the ring. Both failures were in the underside of the ring. The upper part of the ring is fine, and is currently in use.
This means that the UK cannot use the TAT-14, and some providers in France may have to reroute to Katwijk using landlines.
Yes, Spamcop, I remember that brilliant service. The biggest easiest email-DOS there is. Go over to their website and check out the fine print:
;)
SpamCop administrators do not, and cannot verify the claims made by it's users. Not only are there simply far too many reports filed for anyone to manually review them, but even if we were to, there is no way for us to know whether a user actually did or did not solicit a message prior to reporting it as spam.
Therefore, it is trivial to DOS a domain:
-Get a couple of free emailaddresses
-Fake a spam coming from the domain, just use a real spam and change the headers
-send a report about the fake spam to spamcop using the free emailaddresses you've got
-Bingo, the domain cannot send mail to all mailservers that use spamcop for filtering
-if you want to be a real bastard, repeat every day, and they will never get of the blacklist
bottom line: do not use spamcop
Since the gliders glide for a couple of miles on one buoyancy change, the pumps will be idle most of the time, and are allowed to be very very slow, and therefore very very quiet. The amount of water pumped in or out for the required buoyancy change is minimal, that's why they are planning to power the system using the temperature difference between the internal ballast tanks and the outside water temperature.
It is also possible to design the pumping system without moving parts, use the power generated by the temperature difference to make hydrogen and oxygen from water (totally silent). The hydrogen and oxygen will change the buoyancy of the sub if stored in flexible bladders in the ballast tanks. Then if you need to change the buoyancy the other way, power a fuel cell from the oxygen/hydrogen mixture, and store the energy in a battery for the next buoyancy change. This whole operation is (when properly designed) totally silent. Furthermore, if you create the glider from sonar-transparent (or semi-transparent) materials, and make sure that a large part of it is ballast tanks (further helping the sonar transparancy) the thing could be almost sonar transparent. Now make it small, about as small as a fish, and no sonar in the world will see it unless they have a magic real/fake fish filter.
It was my understanding that this system doesn't use sonar, it just listens with very sensitive mikes. Then when you correlate the soundplots you get from multiple places, you can pinpoint the source of the sound.
If the system is passive, it will not detect these 'gliders', since they are absolutely silent.
I'm not trying to 'pimp' DH as better, I'm just putting quantum crypto into perspective. Most people think of quantum crypto as the 'holy grail of crypto'. This is clearly not the case until somebody invents a quantum way of authenticating somebody.
Quantum crypto 'solves' the key exchange protocol. DH 'solves' the key exchange protocol. Quantum crypto might be safer. The problem is still authenticating Alice and Bob. The only way to do that in a useable way is public key. When you use public key you are dependant on the fact that nobody can factor big numbers. When using DH you are also dependant on that problem (okay, equivalent problem). Your weakest link is 'nobody can factor big numbers' whether you use Quantum crypto or public key crypto. Might as well use public key then, a lot cheaper.
What I'm trying to say is that Quantum Crypto is a very expensive 'solution' that is looking for a problem, and until quantum authentication is useable, nobody should be implementing it except for research purposes.
Just my 2 cents
--Blerik
All these quantum authentication protocols use secret key crypto as a basis. So Alice and Bob have to exchange a secret key before using the system. Might as well use the secret key to encrypt the messages they want to send to each other.
Now if somebody finds a nice secure way of exchanging secret keys that is not susceptible to a man-in-the-middle attack, this quantum crypto stuff might be worth looking into, until then just use RSA/AES.
--Blerik
Eve can only be detected if she tries to eavesdrop on the line, not if she sits in the middle doing her own quantum key exchange protocol. The only way around this is to have Alice and Bob authenticate themselves against each other. Which is not possible with quantum crypto yet, so you have to use public/private key crypto.
When you have to use public/private key crypto, there is no reason to use quantum anymore, since a chain is as strong as it's weakest link so quantum crypto is worthless - QED
--Blerik
If it was written in Erlang or Mozart or Mercury, nobody would use it, since nobody knows anything about these languages.
Sure, in Java it is probably harder to write these kinds of distributed agents, but a lot more people can hack all kinds of interesting stuff onto the agents just because they can read Java code.
just mod me down to flamebait
--Blerik
Have you tried Apache's ProxyPass directive??? (that is assuming you use Apache)
Instead of using for example https://sub.domain.com/index.html use https://domain.com/sub/index.html
HTH
--Blerik
P2P through NAT works like a charm, just use UDP instead of TCP/IP.
p t slide 64 and 65.
See http://www.doxpara.com/Black_Ops_Hivercon_Final.p
--Blerik
10/16 : 16777216 addresses
172.16/12 : 1048576 addresses
169.254/16 : 65536 addresses
192.168/16 : 65536 addresses
total : 17956864 addresses
Minus 10% cutting loss when subnetting leaves you with more than 16 million ip addresses. So only really big corporations could have this problem (most of them have a public class A already).
IMHO not a problem
--Blerik
Basically, you checksum the memory pages, if one fails its checksum, you try to correct the error, move the data to another page (virtual memory is great), and mark the page bad.
A bit like your harddisk does it.
You will however take a substantial performance hit on checksumming the memory pages, so in the long run ECC memory is probably better.
--Blerik
So the Mac G5's don't use ECC memory...
Interesting. Especially when you consider the chance of bit faults when using lots of memory.
IMHO the only way to fix this in software is to checksum the memorypages itself, but checksumming is an expensive operation for the CPU.
--Blerik