It’s been a few busy weekends. Sunday Feb 10th we had an orienteering event at Raven Rock, and Feb 17th was Birkhead Wilderness. Both are awesome parks.
The part of Raven Rock where most of the event happened had a lot of underbrush that made it near-impossible to run - but otherwise the course was very well chosen, with some awesome terrain features. The forest is South of Cape Fear, and the cliffs close to the river are very impressive.
Birkhead was a brand new course for Backwoods Orienteering, a bit far (close to the NC Zoo in Asheboro), but still a lot of fun. The forest is sprinkled with huge boulders, and controls were placed in a variety of features that made it less monotone than usual (where reentrants are the norm).
The orienteering club I am a member of has made the decision to purchase electronic punching equipment. Since I grew up with the classic punching equipment that has probably not changed in the last 40 years, this is pretty exciting.
I was kind of puzzled originally that an e-punch card could cost about $35, while being able to store information about you and up to 33 punches. Assuming a generous 100 bytes per punch, that can’t be more than 4k of storage. 1G USB keys can be bought for a bit over $10 (sometimes even less). I guess there is a lot of research and development invested in making the solution resilient to the elements (the control stations are waterproof and smart enough to save their batteries etc), and there is not a high demand in orienteering equipment either, but I still think there’s a pretty high margin in selling the e-punch cards at $30+.
People are already unhappy that the new cards only work in new control stations and that forces clubs to ditch their older equipment. There may well be valid reasons to force the incompatibility (after all, the newer e-punch cards are more than twice as fast as the old ones, and it may be that the old stations just can’t handle that).
Since I’m not traveling to A-meets, it doesn’t bother me that I will have a new e-punch card. But it does point out one fact: the good old stapler-like puncher lasted for the past half a century and is still a valid option - can you say the same thing about electronic equipment? I am worried we’ll see the same trend as with modern computers: update every 3 years or you won’t find software to run.
The revised version of RFC2440 is RFC4880.
As someone else pointed out, kind of similar to the revised RFC822 being RFC2822.
In case you’re wondering what I’ve been up to lately, here’s a quick overview.
Aside from the weekly Conary releases and the regular bug fixes, I’ve been busy trying to make Conary no longer depend on gnupg. As dumb (to re-implement gnupg) as this sounds, it gives us several advantages, one of them being the ability to customize the trust model to our liking. The lack of a good way to tie into gnupg (other than invoking gpg) is another good reason.
Look for the new code in Conary 2.0.
Conary 1.2 is finally out!
We are very excited, I think this is a great achievement for Conary. It packs three months of work behind the scenes on several new features and a ton of bug fixes, while we were maintaining the former stable Conary 1.1 branch. The release announcement is pretty long, as a result.
Many thanks to the Foresight community, who agreed to try some early releases and provided valuable feedback (not to mention uncovering those minor things that we like to call undiscovered features, for lack of a better term 
).
Here’s an interesting scenario I ran into.
You have a program that:
- looks for an empty port in the high numbers
- forks
- in the child
- it does some computation first (this could take some time)
- it binds and listens to the port determined in the first step
- starts processing requests of some sort (like HTTP requests, but any TCP would do)
- in the parent
- it has to wait for the child to start serving requests, so in a loop it will start communicating with the child. If it gets an ECONNREFUSED, wait some time (a tenth or a hundredth of a second) and try again
- do a bunch of work here
This all looks reasonable so far. Except that, every now and then, (sometimes more frequently, sometimes very rarely) I was seeing the parent process stuck. A quick /usr/sbin/lsof was showing the most disturbing thing: a socket connected to itself!
27945 misa 10r IPv4 73626638 TCP localhost.localdomain:51308->localhost.localdomain:51308 (ESTABLISHED)
All you can do when you see this is scratch your head and wonder what in the world is going on.
After much running around and lots of tracing of the code, it finally occurred to me what happens.
For the explanation that follows, I will call it a local port the port number used by the socket locally (as returned by getsockname(2)).
Every time you have a socket and you try to connect(2) it (to a remote, known port), the socket library will pick an unused high-numbered port for its end of the connection (as the local port). If the attempt to connect(2) the socket fails and you try again, it will temporarily bind to another port (the’re usually consecutive, until they wrap around and start over).
If you try long enough without succeeding (and it is key that the server and client are both on the same machine - I used localhost for both), connect(2) will pick the port you initially assigned to the server as the local port, and will connect to itself!
One possible solution is to pick an unused port and bind to it before connecting. Then connect(2) will no longer bind to random other ports.
I used to use ext2online in conjunction with LVM whenever I had to resize a partition that was already mounted. I haven’t had to do that in a while, so I was surprised that I couldn’t find ext2online anymore.
Turns out more modern versions of resize2fs already know how to do that. Not the ones from e2fsprogs=conary.rpath.com@rpl:1, but I was able to install e2fsprogs=conary.rpath.com@rpl:devel into a temporary root and run the new resize2fs from there. Yay.
I got to play a bit with Gallery 2.2.2 and I noticed it does support mounting albums with a WebDAV client. (You’ll have to configure the plugin). While I didn’t try to actually mount it, I did use cadaver to access it in an ftp-like environment. Very sweet.
Now in a Foresight repository near you (foresight.rpath.org@fl:1-contrib).
I’ve been playing with SCons for the past couple of days. It’s intended to be a replacement for Make, and probably sounds similar enough with Ant or Maven, for those familiar with these tools from the Java world.
It’s pretty powerful in that it lets you use the boilerplate builders or you can build your own builders (and nodes!) too. It also allows you to write custom “freshness checks”. make usually verifies if a node is out of date by comparing the timestamps for the source and target nodes. This can get you in trouble when using CVS, for instance, because clocks are not synchronized. It’s also not very useful when what you build doesn’t live on the filesystem.
I will post some examples shortly. I am currently creating nodes for Mercurial checkouts and they work pretty well. CVC (Conary) nodes will follow shortly.
And yes, it’s written in Python…
Something in the whole chain of sending a fax is bothering me.
(more…)