Found this on the web:
Found this on the web:
I generally like my Cable TV company. This is mostly because they have realized that they won’t be a Cable TV company in ten years and they are running their business according to that mantra. In English, this means that they are putting their effort in being a very very good consumer grade ISP. One of the side benefits that Cable Internet has been offering is access to public hotspots. As a consortium these companies have nearly every urban area that I’ve been to covered in WiFi. On the surface this seems to be a good thing but it has some downsides. Most WiFi uses the 2.4GHz frequency band. WiFi routers ship with a range in open air of about 450m. There are only three non-overlapping channels in the 2.4GHz band. If you’ve debugged WiFi in an urban setting, you are probably painfully aware of these three characteristics of 2.4GHz WiFi. When they Cable TV company starts deploying open hotspots in your neighborhood, they aren’t pushing the system to a solution for this problem.
I have to qualify this as a rant though since there isn’t much that anyone can do to fix the problem. Especially since the Cable TV companies have started enhancing their WiFi offering by giving away high powered WiFi routers which that offer dual SSID to their customers. It won’t be long before anyone who want’s to do anything will be in 5GHz.
In an attempt to make life easier Apple added the Captive Network Assistant App to OS X. I think this addition was made sometime around Lion. Captive Network Assistant is an App that can display a little the very simple web page you get when you connect to a wifi network that has Captive Portal. These are the pages you get when you first log onto your coffee shop WiFi. They usually ask you to agree to some terms and conditions before you can use the network. In the case of hotels, resorts, and cruise ships they will also tie to the site billing system so you can be charged if that’s appropriate. Lately I’ve started to get these sites on both my MiFi hotspot and most lately, my home WiFi. This article explains three major drawbacks to Apple’s approach here. The authors of these web pages will frequently embed logout information into the page when the captive portal mechanism is being used to track usage for billing. In this use case, the app is a hinderance because when it disappears, it takes the logout link with it. Also, Apple triggers the app by attempting to fetch a known page over the web when your WiFi first connects. If it doesn’t get what it expects, it knows it’s behind a Captive Portal. In my case, the Captive Portal App is displaying Apple’s static page which indicates that you aren’t behind a portal.
When I started seeing captive portal on my home network, I decided the turn the thing off. To turn captive portal off do this command:
sudo defaults write /Library/Preferences/SystemConfiguration/com.apple.captive.control Active -boolean false
To restore the old behavior, do this, again in a terminal window:
sudo defaults delete /Library/Preferences/SystemConfiguration/com.apple.captive.control Active
Other people including the article linked above recommend renaming the App. I’m not in love with that solution, mostly because two months from now I don’t expect to remember that I did this in the first place. My solution isn’t much better. One could argue it’s worse because it requires terminal and sudo. It’s the one I went with though.
Old habits and myths die hard. Conventional wisdom asserts that UDP is better because it has lower overhead; then conventional wisdom suggests that you tune the buffer sizes to improve performance. On the face of things that would seem to work but once the the write size exceeds the max packet size, NFS delivers the packet by using multiple packets. Sending multiple packets triggers the issue because dropping just one UDP packet means the whole buffer must be resent. Contrast with TCP: yes the packet header is larger so less data can be sent and yes the receiving side has to ack each packet. But: with TCP if a packet gets dropped, only that packet needs to be resent; with a modern TCP stack the kernel will constantly adjust the window size to make the best use the available bandwidth. In other words NFS over tcp will automatically tune the buffer sizes for the current conditions.
This seems obvious but it’s really handy to have my website setup with DAV access to the backend for administration purposes. I’ve recently setup on of my sites this way and it works out quite nicely.
Looks like something burped on my mailserver and my bogofilter wordlist got too big. Probably something to do with limits anyhow. In any case I was looking for a way to recover from the issue and came across this pearl in the Bogofilter FAQ. Well, the advice is incomplete. If you really hose up the database then bogoutil -d will stop printing entries before the end of the database. The next recovery step is to use the db utilities: db_dump and db_load to fix the database. db_dump -r (on FreeBSD db_dump-<version>) dumps the database into a text file and db_load creates a text file from a word list. The problem is that the advice in the bogofilter faq is out of date. It looks like there are some parameters that have to be specified. My solution: use db_dump without the -r that creates a broken database with a default header. Copy the header into the new text file and then append the output of db_dump -r to that. Et voila!
One thing that really ticks me off the web designer conversation where your web design guy insists on designing to an 800×600 screen resolution to ensure that your pages will be accessible by everyone on the web. Today I ran across this nugget (opens in a new window). I’ve always said that this is so 1998 yet I’ve had this conversation as recently as 2007. Well, if you dissect the table you come up with this:
That’s right. If you design for 1024×768 you reaching nearly 95% of all the web browsers that participated in this survey. Now web designers can partly like it’s 2004!
In Dante’s Inferno there were circles in hell designed to separate the ordinary sinner: the guy who designed the keyboard I’m working with (which provides no feedback when a key has been struck for example) from the guy who deliberately put the “global nuclear war” button right next to the “toast apple poptarts” button. MyÂ “9th circle of hell award” goes to the guys who designed the firewall that I’m working with lately. It appears that in their wisdom they’ve chosen to implement the “Red Alert — all hands on deck” alarm for the following scenario. You have a server connected to a client via tcp. The server is a fairly recent linux box that can do RFC1323 extensions. The client is a boring Windows XP box with a TCP RWin size of 65536 bytes. Between them is a Comcast business class Cable connection. In this scenerio the Windows box is trying to download a file from the server on the Comcast connection. The problem is literally that the connection is too fast for the Windows XP Box to fully cope. Nowadays when I test Comcast Cable connections I’m surprised to see anything less than 25Mbit/s.In whole numbers thats 25,000,o000 bits / sec. In more familiar units that 312.5 kBytes /s. The problem is that I’m starting to see firewalls that see this as an issue because they have been programmed with very conservative specifications about what constitutes a denial of service attack. I’m seeing firewalls that scream DOS when they are connected to a Business Cable modem line and have clients with tcp receive window size of 65536 bytes. Why? it’s simple. On aBusiness Cable line with 25Mbits/s download rate you have to be able to buffer 96kbytes/s in tcp windows just to keep up with a server (or client) at the other end of a fast line. These firewalls are calling DOS becauseÂ the other end can fill their TCP window and then some. The right thing to do is to watch. If the otherside wants to DOS you he’ll send many packets after your Rwin is filled. If he’s just a really fast server on a really fast pipe. He’ll respect your RWin and quit sending. If you’re firewall decides to be agressive and drop the connection (by proactively sending a TCP RST) then you should probably act accordingly.
My thanks to Chuck Skuba on this post. I have to be 100% and fess up that I gathered the data but he did the homework.