Seems like the slashdot effect might even be affecting the apt repositories. I can't "apt-get install" any packages right now and get a big fat "connection refused" in response to that.:(
I always thought latency played a part in "jitter" from my vague understanding of what potentially causes jitter. Such as on a load balanced link, if packets A,B,C,D, and E were sent to a load balancer and by the time packets D and E came in, it felt that the path it sent packets A, B, and C through was now too heavily loaded and there is a less loaded path for D, and E, it would then send packets D and E through the less loaded link, which might also have a lower latency. That less loaded link with lower latency might actually get the packets D and E to the destination before packets A, B, and C come in on the more highly loaded link and cause "jitter". Without a load-balancing router having multiple paths of varying latency to the same hosts, is "jitter" still possible?
If you are at all interested in this service (or one of the alternate offerings from the other VoIP providers) then make sure your line can support a VoIP call by using this free service: ahref=http://testyourvoip.com/ [slashdot.org]http://testyourvoip./ com/>.
Here is a working link for www.testyourvoip.com just incase some people don't feel like highlighting the proper part of that URL and pasting it in their browser.
Probably about 911 routing. Some VoIP providers that say they forward 911 to an appropriate PSAP number in your area don't forward it properly, or forward it to non-emergency numbers that aren't properly equipped to handle the typical 911 emergency call, or forward 911 to completely wrong numbers that either no one answers on when you do call them or are merely answering machine or fax lines or have absolutely nothing to do with any emergency service whatsoever. Short of testing your 911 functionality ahead of time, you might not know of this with VoIP until the time comes that you actually do need to use 911 and then realize it doesn't work.
Mozilla also PGP signs their packages along with providing MD5 and SHA1 hashes for every release. For example, here is the U.S. English, win32 firefox's PGP signature, the signing key, and its MD5 and SHA1 hashes. Sadly, I don't see any direct links to this stuff anywhere on their main download page.
Another idea is to use IPSec or OpenVPN over wireless. Going this route would end up costing a bit more money to achieve better wireless security and may be a bit more difficult to setup, though.
One could use IPSec over wireless by purchasing a separate VPN router and then connecting the wireless access point to the WAN port of the VPN router. VPN client software could then be installed on all wireless client machines that will be connecting to that wireless access point. The VPN router itself could be configured to only allow LAN-side access to clients using IPSec with the proper key.
For OpenVPN, since I haven't seen any dedicated OpenVPN hardware myself (but I haven't tried looking), you would need a dedicated machine that has two network ports. One would be for wireless, the other for your LAN. You would then have to setup that machine to route packets to your LAN only if they use valid OpenVPN keys and also would have to configure each and every machine's copy of OpenVPN individually.
One thing that I am unsure of is how much either IPSec or OpenVPN affect wireless's performance.
Found any gold yet?
Seems like the slashdot effect might even be affecting the apt repositories. I can't "apt-get install" any packages right now and get a big fat "connection refused" in response to that. :(
I always thought latency played a part in "jitter" from my vague understanding of what potentially causes jitter. Such as on a load balanced link, if packets A,B,C,D, and E were sent to a load balancer and by the time packets D and E came in, it felt that the path it sent packets A, B, and C through was now too heavily loaded and there is a less loaded path for D, and E, it would then send packets D and E through the less loaded link, which might also have a lower latency. That less loaded link with lower latency might actually get the packets D and E to the destination before packets A, B, and C come in on the more highly loaded link and cause "jitter". Without a load-balancing router having multiple paths of varying latency to the same hosts, is "jitter" still possible?
Here is a working link for www.testyourvoip.com just incase some people don't feel like highlighting the proper part of that URL and pasting it in their browser.
Probably about 911 routing. Some VoIP providers that say they forward 911 to an appropriate PSAP number in your area don't forward it properly, or forward it to non-emergency numbers that aren't properly equipped to handle the typical 911 emergency call, or forward 911 to completely wrong numbers that either no one answers on when you do call them or are merely answering machine or fax lines or have absolutely nothing to do with any emergency service whatsoever. Short of testing your 911 functionality ahead of time, you might not know of this with VoIP until the time comes that you actually do need to use 911 and then realize it doesn't work.
Mozilla also PGP signs their packages along with providing MD5 and SHA1 hashes for every release. For example, here is the U.S. English, win32 firefox's PGP signature, the signing key, and its MD5 and SHA1 hashes. Sadly, I don't see any direct links to this stuff anywhere on their main download page.
You left off a vital step in showing the finger. Apache has to be installed and the default web page needs to be set to the appropriate image.
Interesting idea. That sounds almost like the diceware method on steroids.
One could use IPSec over wireless by purchasing a separate VPN router and then connecting the wireless access point to the WAN port of the VPN router. VPN client software could then be installed on all wireless client machines that will be connecting to that wireless access point. The VPN router itself could be configured to only allow LAN-side access to clients using IPSec with the proper key.
For OpenVPN, since I haven't seen any dedicated OpenVPN hardware myself (but I haven't tried looking), you would need a dedicated machine that has two network ports. One would be for wireless, the other for your LAN. You would then have to setup that machine to route packets to your LAN only if they use valid OpenVPN keys and also would have to configure each and every machine's copy of OpenVPN individually. One thing that I am unsure of is how much either IPSec or OpenVPN affect wireless's performance.