Uh oh...  That swirl in the water?  That's a beaver.  That grass at my feet?  That's our culvert.  Beavers like to build dams just on the upstream side of our culvert, which leads to trouble like The Big Flood.  So this beaver-project must be removed...

Here's one of the culprits...  Making a getaway...

Here's their handiwork.  This got built in one night (I know this 'cause Marcie and I took a dam out yesterday in exactly the same spot -- the beavers like it so much they rebuilt it overnight).  So this one turned out to be really small and really easy to take out (unlike the one before which was a lot more challenging).

The compleat beaver-dam extraction module.  Note the smile on her face -- taking out beaver dams is a boatload of fun.  I had a little too much fun on the one we took out yesterday and wiped out my finger.  So Marcie sidelined me and took over the job.

This is the "before" picture -- Marcie's getting ready to attack.

Here's the "after" picture.  All gone.  Along with another little one that they'd started just downstream from the culvert (an equally big problem for flooding).

Here's Marcie holding a giant Angelica stem in the downstream-dam.  That's not a little tree.  That's a flower stalk!

Here's the dam -- loaded on Trakdor for disposal.  We'll see whether they try again tomorrow.

This is a series of pictures of our dining-room table.  The cool thing about it is how it folds out -- so most of the time it's a modest little table that four people can sit around.  But folded out, we've crammed twelve people around it.  Also great for poker.  This series of pictures shows how it's put together.

Here's the table, in it's 4-person folded-up configuration.

This is how it looks half way in between -- the four extensions have been pulled out.

Here's the "large" configuration.  Eight people sit in style, a little squishing and you can get twelve around it.

OK, so how does it work?  Here's a picture of the halfway-out view, with the center surface removed so you can see all the wiring.

A closer look at the inner workings, this time with the extensions pushed back into the "small" configuration.

Even closer.  There's some pretty amazing geometry in there.

Here's one extension pulled out -- to show the relationship between pushed-in and pulled out inner workings.  As extensions come out, they also need to rise vertically so that they're bringing that foldout piece of the table up into the same plane as the center part.

Another view -- showing how the "east west" extensions are different than the "north south" ones.

Here's one extension pulled all the way out of its little track -- see the shape under there, that's the trick to the "rise vertically" solution.

Close in view of the complex shape of the extension-support -- the geometry is different on all four of these in order for them to fit together when the table is closed.

Here's the trough that the extension rides in -- more rise-vertically geometry.

Trough II, the sequel.

Now all the extensions are extended.

Leg detail.  About the least complicated part, but look at those matching inner and outer curves.  Sheesh, it would take me years to get that right.

Here's a detail of the hinge on the extension.

And here's a shot of how the "flopping down" end of the extension mates with its neighbor.

The bottom of the top -- showing the two big pegs that align it properly.

Detail of the pegs.

This whole saga started when I read an Ars-Technica article called "Small ISPs use "malicious" DNS servers to watch web searches, earn cash."  Here's the lede that got my attention:

Nearly 2 percent of all US Internet users suffer from "malicious" domain name system (DNS) servers that don't properly turn website names like google.com into the IP addresses computers need to communicate on the 'Net. And, to make matters worse, the problem isn't caused by hackers or malware, but by the local ISPs people pay for access to the Internet.

As I read more about this issue, I came across the ICSI Netalyzr which is a nifty network-diagnostic tool that tests a bunch of dimensions of a broadband connection and will detect this DNS-interception if it's happening.  The good news, is that none of my broadband connections have this problem.  BUT, the Netalyzr did discover another problem called "buffer bloat" on my connection at the farm, which explains some of the erratic network behavior here.  The rest of this post is the saga of a delightful geek project to get this fixed -- and documentation to remind me what I did plus provide some goodies for anybody who'd like to follow along.

Buffer-bloat mitigation -- Background

First up -- what is "buffer bloat?"  I came across a post by Jim Getty called "Mitigations and Solutions of Bufferbloat in Home Routers and Operating Systems" which is mostly focused on a strategy to fix the problem (and is the basis for the stuff I've done here).  Fersure read this post -- but if you're a geek who's interested in understanding what the problem is, also read the "surrounding" posts on his blog.  I'm left pretty completely in the dust by the technical discussion, but I follow it enough to share Jim's concern that this could become a really interesting puzzle.

The short version of what I'm doing with this project is to protect the Internet from my over-eager home computers by putting my own traffic meter (just like the one at a freeway on ramp) on my Internet connection.  I will tell you true -- taking 10-20% off the top speed of my Internet connection makes it "feel" a WHOLE LOT faster.  Formerly-unuseable video streaming (Vimeo streams were the worst, but YouTube was pretty crummy too) is now just fine.  My VoIP phone service from Vonage is now rock solid even when we're doing lots of other uploading/downloading, etc.  I like it a lot and based on this experience I'm going to do the same thing at my other connections as well.

Ingredients -- a new router and Gargoyle

I have been interested in the idea of putting open-source software on a consumer router for a long time, but hadn't had a good reason until I read Jim's piece.  Unfortunately, the Apple AirPort Extreme sitting in the basement isn't on the list of routers that can be treated that way (and, interestingly, also doesn't provide any bandwidth-shaping capability).  So it was off to the Gargoyle site to do some shopping for a new router, one that would be a good target for an upgrade to Gargoyle.   I wound up getting a TP-Link TL-WR1043ND because it's cool looking with its 3 antennae and has lots of CPU-horsepower and memory so performance was likely to be spiffy.

Installation tips

It's always a little nerve-wracking to venture into a whole new realm of activity for me, so I took it pretty slow and easy on the actual set-up process.  I set the new router up with a completely "standard" configuration and ran it that way for a day or two before getting into the exciting Gargoyle stuff.  One thing that interested me was that the TP-Link router software had bandwidth-shaping capability already and I wanted to see if I could mitigate the buffer-bloat just using that.  That didn't work -- see "Tests" below -- but it provided some good entertainment for a day or two, running the tests.  Here's what I did after that:

• Upgrade the router software.  I went out to TP-Link's web site and pulled down the latest version of the WR1043ND firmware and updated the firmware in the router to the current release.  This had the added bonus of providing me with a "factory" copy of firmware if I needed to fall back from the Gargoyle software.
• Install Gargoyle on the router.  I followed these instructions for loading Gargoyle on the WR1043ND that are published on the Gargoyle site.  There are two things to note.  The first is that those drop-down menus aren't really drop-down menus, they're just pictures of them.  To actually get the software, follow your nose through the download section until you get to the place that's described by those graphics.  But here's the other note -- the graphics are a little old and point to the 1.3.14 version of Gargoyle -- I jumped ahead to the 1.3.16 version and it's been fine (for the big 24 hours that I've been running it).  The rest of the installation went without a hitch -- I used the "firmware upgrade" function on the standard software, pointed at the Gargoyle file I'd just downloaded, had a couple sips of a beverage and the router rebooted itself into Gargoyle.
• Test the "fallback to factory software" scenario.  Before messing around with Gargoyle, I tested rolling the router back to a standard configuration.  I used the slightly-modified "factory" software from the Gargoyle page, ran it through Gargoyle's "Update Firmware" process and scared the heck out of myself when the upgrade didn't complete.  I thought I'd turned the router into a brick -- but it turns out that the web-interface just isn't smart enough to know that the router has rebooted itself.  I logged back into the router and found factory screens rather than Gargoyle screens.  Whew.  Then I upgraded the software to the software I'd downloaded from TP-Link and got myself back to a completely-factory router again.  Once I'd gotten through all that I repeated the process of loading Gargoyle on the router and that's where it sits today.

Tests and observations.

One nice thing about Netalyzr is that it leaves permanent copies of the results out on the net so's you can refer anybody to them.  Here's the series of tests I ran at the farm.  Unfortunately, I forgot to capture the permalink of the very couple tests (with the Apple router and the WR1043 in default configurations).  Dang.  So I'll skip forward to a series of tests running the Gargoyle software on the new router.

1st test -- New router, Gargoyle software, default configuration, QoS turned off.  Note the Red-bordered part of the results -- which show 5400ms of buffering on the uplink and 509ms on the downlink.  This is bad -- this is what got me started on this project in the first place.

2nd test -- New router, Gargoyle software, default configuration, QoS turned on.   Buffer-bloat is dramatically lower -- uplink is 220ms and downlink is 44oms.  BUT, there's a cost.  The default settings in Gargoyle limit the speed of the connection to 300k upstream and 3000k downstream, which is almost cutting the bandwidth in half.  On the other hand, it proves that buffering can be mitigated.

3rd test -- New router, Gargoyle software, bandwidth QoS settings increased to 500k downstream x 5000k upstream, QoS turned on.  Uplink buffering remains around 220ms (same as before -- this is good), downstream buffering is starting to creep up at 680ms.  This is where I've left it for now -- more experimentation to follow, but this gives you a sense of the thing.  Upstream buffering is less than half what it was, downstream buffering is reduced almost ten-fold.

IPHouse test -- You want to see a perfect score on the Netalyzr test?  I ran the test from my little server over at IPHouse.  Perfection -- no flags at all.  What else would you expect from IPHouse?  It proves that you CAN configure a network correctly and eliminate buffer-bloat.

So there you have it.  The "real world" results are still coming in, but so far the connection here at the farm "feels" more solid.  I downloaded a few videos and they don't stutter they way they used to.  The Vonage line is now getting top priority in QoS and should be less subject to disruption when we're doing a lot of uploading (although that will have to wait for a teleconference for confirmation).  All good, an easy project and a neat new router/software combo in the basement.

Image: jscreationzs / FreeDigitalPhotos.net

I'm running the current version of WordPress here (3.1.3 as of this writing)

I, and many, would like to be able to insert a gallery of pictures into our posts and specify external links for each picture in the little gallery-editor that comes with WordPress. The problem used to be that WordPress users could not make the Save function work, the Link URL wasn't being saved in the editor. That problem is documented in the WordPress bug-tracking system as problem number 13429 .

Sergey came up with a work-around plugin that people can add to their WordPress which solves part of the problem.  Downloading and enabling this temporary plug-in indeed fixes "I can't save external URLs in the gallery editor" problem.  I've linked all of the images on this page to three of my domains (www.geezercast.com, www.kz0c.com and www.bar.com) to illustrate the problem as it stands right now.

If I add all the images individually, they will all point at external URLs, like this;

BUT that's not what people want to do -- they want to be able to post the whole gallery (in this case all three images) at the same time, and have the thumbnails in the gallery point to external links, not to the image file or an attachment page.  I'll insert the gallery this time, using the "attachment page" option as an example.  What people want to happen is exactly what happened above -- 3 pictures pointing, in this case, to geezercast.com, kz0c.com and bar.com.  What happens instead is this;

Changing that "Attachment page" to "image file" option just makes the thumbnails link to the images.  So in neither case can a person use the WordPress gallery to link a series of pictures to external URLs.

So this may be a combination of a bug and a feature.  The "can't save Link URLs" problem is solved with Sergey's little shim, and will hopefully be released into the production release soon.  But the real problem, "I can't point gallery-thumbnails at external URLs," still exists.

Here's a gallery that behaves "the right way" -- using this great hack of the NextGen Gallery and NextGen Gallery Custom Fields plugins.

a-little-chilly

img_2758

mikesmall

Any chance that we could get that ability in the normal gallery?  The hack wasn't hard, but it's pretty intimidating for "normal" users and seems like an easy add-on to the existing Gallery function.

Here he comes, in for a landing

Woohoo!  pretty happy about the effort

A little tired, no?

Susana joined us a little later and we sat down to have a Marcie home-cooked Indian-cuisine dinner

Here's another picture of the table.  Diwali lamp in the middle -- a little early for "real" Diwali, but close enough...

Carlos is still tired from his ride.

We were hoping for great stars that night so Carlos could do a cool time-lapse photograph but the dang moon was too bright...

Next morning we set out on a walks to see the farm.

We wound up taking pictures on the bench above Big View Prairie.  Susana had better luck with her camera than Carlos did.

But things worked out in the end.

Then, it was time to play with the toys.  Here we're checking Carlos and Susana out on the PowerTracDor.

Carlos had first bash at the "mow down the trees" project.

Looks like he had a pretty good time.

Then I guess I decided to show Susana how to use the PowerTracDor as an airplane or something.  I still haven't figured out what I was demonstrating with that hand motion.

Susana had a pretty good time too!

I think this photo could be used as a publicity photo for PowerTrac.

Then we had a little lunch, booked on down to the Mississippi for a quick check-out ride to see if the motor was finally fixed (it was!) and then off to the Harbor View for dinner.

A great time was had by all.

Ooops.  The law hasn't passed yet -- I misunderstood Rick's letter...  Here's the salient quote (down near the bottom)

pass the law (well, getting closer anyway – should be next week!)

Sorry about that.  I'll leave the original stupid/mistaken post here, but you can ignore it.  On the bright side, I'm hoping for the opportunity to write another "Woohoo" post if the bill does pass.

Sorry about that...

Mikey

_________________________________________________________________

Woohoo!  We did it!

I just got this great news from Rick King, our chair.  Here's his note.  The one thing I'd add is that his leadership is what made this bet worth taking.

All,

I am not a betting man. Had I been one, I would have placed a pretty big bet on the Task Force succeeding as the odds would have been against me. I mean, seriously, who would have thought that 23 people, with diverse backgrounds and conflicting interests, would have worked so well together? That we would put an agreement on paper and influence others enough to likely pass legislation to codify our recommendations?

Well, we did it. And today, almost two years after its inception, the Ultra High-Speed Broadband Task Force ceases to exist.  In what seems like the perfect farewell gift, the Minnesota Legislature approved a bill and it was recently signed into law by the Governor.  Is the new law what I would have written had I had a magic wand and lived in the Land of Unlimited Resources?   Maybe not.

Is it, however, wise, forward-looking legislation that positions Minnesota as a leader in the nation.  Now, with the National Broadband Report released, I think our wisdom as a state shines even brighter.

While the Task Force’s report was almost 150 pages long, our key recommendations were narrowly defined:  we wanted universal access to Ultra High-Speed Broadband in Minnesota, we defined Broadband as a minimum of 10 to 20 megabits per second download and 5 Mbps upload, and we wanted the state to set a comparative goal within the U.S. and the world. Furthermore, we felt that there had to be some sort of ongoing institution to ensure that the objectives were pursued. It’s all in the bill.

With this, my last letter as Chair, I would like to recognize the talent and the hard work of each and every Task Force member and the supporting staff and friends across the state who freely gave us their work, ideas, advice and enthusiasm to create the report and pass the law (well, getting closer anyway – should be next week!).  It has been my privilege to meet and work with each of you.

Together, we have contributed to making Minnesota a better place to live and work.  And, a leader among the States in our great country.

I should have placed that bet.

Warmest regards,

Your ex-chair

I've been rasslin' with two kinds of trouble -- our WordPress blogs all started throwing "missing a temporary folder" errors when we would try to upload pictures.  And logins stopped working on all of my Mediawiki based wikis.  You could logon just fine, but then it would flip right back to not being logged on, and you couldn't do anything or edit pages.

Here's the solution.  Raise, or eliminate, the user-file quota for the IUSR account on the server.  This is a problem unique to the WIMP stack (Windows, IIS, MySQL, PHP) which is why there probably aren't many blog posts about this.  Most folks run these kinda servers on the LAMP stack (Linux, Apache, MySQL, PHP).

Here's how to check to see if you're running into the same problem I had.

• Right-click on the C: drive in My Computer
• Select "Properties" and open the "Quota" tab
• Click the "Quota Entries" button on the lower right corner to see the list of users and quotas
• If you are having the same problem I did, your IUSR account will be at it's limit

Once you know that you're in the same boat I am, you've got all the usual choices -- raise the quota, delete some files, etc.  The big breakthrough for me was just discovering that bottleneck.  In my case, I turned off the quota system altogether.  Our photographs are what's burning through that quota and I'm OK just leaving that feature turned off.  Your mileage may vary.

Click HERE to read a great post (and discover a great blog) about getting rid of surface noise using wood glue of all things.  And then click HERE to get the latest and greatest -- 'turns out that thread generated a LOT of discussion.

The key deal -- the kind of wood glue makes a big difference.  The gang on that blog tend to think that Titebond Extend is the bees knees.  I may have to try this out.  The results are pretty darn spectacular.

Leading off with Michele Neylon's post which explains his reasons for skipping this meeting and the need for thoughtful discussion (comments are really good on all these posts by the way)

http://www.mneylon.com/blog/archives/2010/02/13/personal-reflections-on-icann-nairobi/

Maria Farrel posts a very balanced/detailed note about the situation here (Rod Beckstrom, ICANN CEO, posted in the comments)

http://crookedtimber.org/2010/02/12/14645/

Kieren McCarthy (until recently the ICANN staff person responsible for remote participation) posted a followup here -- which really does a great job of turning lemons into lemonade in my view by saying that this may be the event that really pushes the remote-participation capability to new levels

http://kierenmccarthy.com/2010/02/12/why-icann-nairobi-may-be-a-blessing-in-disguise/

Nick Ashton-Hart (current ICANN staff person in charge of remote participation) posted this in the comments to Michele's post;

"Thanks Michele for your thoughtful and balanced post. I, too, would like to echo the call that people respect each other's choices about attending or not attending the meeting. I think that characterising the choices of others in negative terms doesn't really benefit anyone.

We are working very hard internally on remote participation for this meeting; I'm the overall coordinator of the effort. I think everyone will find that things RP-related at Nairobi take quite a leap forward from previous meetings.

You will find that when the schedule is posted on the 15th, detailed information on remote participation for all sessions is published along with the session information. More details will follow shortly thereafter too."

I'm still on the fence -- read those posts for the reasons why I'm still leaning towards going.  But we'll see...