Some stats on curl development

Counting curl 6.0 and up to curl 7.19.3 we’ve done 78 releases during the 9.4 years it took.

In this time, we’ve mentioned 1259 bugfixes and 389 notable changes.

This makes one bugfix done every 2.7 days. One release done every 43rd day with an average of 16 bugfixes done in each. The longest interval ever between two curl releases was 139 days, back in 2000 when we worked to release the first version 7 release (known as 7.1).

To compare with how our work has been more recently, doing the same math limited to the 20 latest releases only (the 3.3 years since and including 7.15.0) shows that we’re still on 2.7 days per bugfix (although we know that the code base has grown steadily for years) but we’re now on 61 days between releases and 21 bugfixes/release…

All this info and more will be visible on a web page on the curl site soonish, I’m still working on polishing it up.

What other useful or useless but interesting numbers could be extracted from this?

Binary size changes over time

Jonas “rasher” Häggqvist is the main man behind behind a distributed effort to gather a huge set of data on Rockbox builds of the past. Currently there are a number of build servers running “out there” providing info back to the master server about the bin size and ram size used by Rockbox builds (for a limited set of selected targets) of basically every single SVN revision since the dawn of time… Or more specifically almost 20000 revisions with rev 1 committed on January 17th 2002 (although the first files with contents were committed in r4, March 25th that year).

The repository was originally using CVS but was converted to SVN using cvs2svn in January 2007.

While this extensive work isn’t finished yet, you can already see the results appearing on Jonas’ site at:

http://rasher.dk/rockbox/graphs/

curl 7.19.3

I just now sent away the announcement of curl and libcurl 7.19.3. With some 30 bugfixes and only two actual changes I hope this will again be a solid release that’ll be appreciated and used all over.

The changes are:

  • CURLAUTH_DIGEST_IE bit added for CURLOPT_HTTPAUTH and CURLOPT_PROXYAUTH – as older Internet Explorers have an “interesting” take at the Digest authentication and servers that speak that dialect doesn’t like libcurl’s regular way
  • VC9 Makefiles were added to the release package, for the VS2008 users of the world

Download here.

Linux distros consolidate crypto libs

For a while already, the Fedora distribution has fought battles, done lots of work and pushed for a consolidation of all packages that use crypto libs to completely go with Mozilla’s NSS.

Now it seems to be OpenSUSE’s turn. The discussion I link to here doesn’t make any definite conclusions but they seem to lean towards NSS as well, claiming it has the most features. I wonder what they base that statement on – if there’s a public doc anywhere that state exactly which has what that makes any contender better than any other for them?

In the Fedora case it seems they’ve focused on the NSS FIPS license as the deciding factor but the license issue is also often brought up in this discussion.

I’ve personally been pondering on writing some kind of unified crypto layer that would expose a single API to an application and handle the different libs as backends, pretty much the same way we do it internally in libcurl at the moment. It hasn’t taken off (or even been started) since I’ve not had the time nor energy for it yet.

FLOSS Weekly #51 on curl

FLOSS WeeklyLate Wednesday evening (middle European time zone) on January 7th 2009 I was up doing a live recording of the podcast show FLOSS Weekly with Leo Laporte and Randal Schwartz. This recording is now available for download as episode #51.

We chatted a bit about curl and libcurl and I think I did a decent job of keeping to the subject and not making a total fool of myself. Enjoy!

(The talk was done using skype and yes my laptop was running Windows at the time…!)

BYO rockbox player partly alive

Jorge “casainho” Pinto is known in the Rockbox circles as the main guy behind the “Rockbox Player” project which strives to build their own portable music player to run Rockbox.

They’ve made some progress latetly, and they’ve now run Rockbox far enough to display stuff on their screen:

Click the image for the full photo. Cortesy of Casainho himself. “I hope to take no more than 1 month to finish the port.

The target is using an Atmel AT91SAM9260 at 200MHz and the screen is a 12bit color 128×128 one.

IETF http-state group created

Over at the IETF another group was just created named http-state (with an associated mailing list) with the specific goal:

Ultimately, the purpose of this group is to create an updated HTTP State Management Mechanism RFC (aka cookies) that will supersede the Netscape spec, RFCs 2109, 2964, 2965 then add in real-world usage (e.g. HTTPOnly), and possibly add in additional features and possibly merge in draft-broyer-http-cookie-auth-00.txt and draft-pettersen-cookie-v2-03.txt.

I’ve joined the list and I hope to follow and participate in this, as I believe the current state of HTTP cookies is a rather sorry mess and the Netscape spec is still what closest describes how cookies work in the wild. Of course I’ll do it with my libcurl experience in my luggage.

While it perhaps would be cool to join the group in more formal way, there’s no way for me to participate in that IETF meeting in San Francisco in March.

emacs!

I haven’t said it here before, but I feel I really should. I’ve been an avid emacs user since I started to learn it back in 1991 on emacs 18. I worked at IBM with their RS/6000 machines at the time and I learned C on AIX with emacs as my editor.

To me there was no alternative at that time and I soon learned all the quirks, got used to things and appreciated all the beautiful parts – my fellow colleagues being emacs fans of course helped pushing me into that team. For the fun of it, I’ve checked when vim was started and I’ve learned that it got available for “unix” in 1992. And it probably was quite far away from a real emacs competitor at that time. The vi editor was of course there, but it had no C syntax indent support and it used and still uses that quirky “mode” approach that I’ve never liked.

I came from hacking the C64 to programming Amiga over to AIX and I was used to and liked full-screen editors without any particular mode switching necessary. Still today I find it a bit curious how vi (in the shape of vim) can be this popular given that (in my view) funny concept.

While I do see some of the benefits of XEmacs over GNU Emacs I always disable all menus, icons and toolbars so to me in real-life editing the differences don’t mean a lot, so I tend to go with the plain GNU Emacs.

So, I’ve pretty much used Emacs just about daily at work and in my spare time hacking since then. Even during the few times I’ve been locked in at a windows desktop I’ve managed to get a windows version installed to survive my days!

Thank you emacs team!

A new year with new fun

I had a great and relaxing winter/Christmas holiday and hence my silence here.

I’m now back up to speed, with a podcast interview done yesterday (I’ll post another entry when it gets available), I do some funded development on libcurl and libssh2 in the background while I’m spending my days at my client’s place working on a 10G traffic analyzer product.

It was rather calm during “the break” but I’ve now noticed that at least the curl project has gotten significantly increased activity again. We’re on a feature freeze now for the January release, but there seems to be at least 4 patches pending adding new stuff for the release planned to come after this (around March if things go well).

Fun with executable extensions in viewvc

A few years ago I wrote up silly little perl script (let’s call it script.pl) that would fetch a page from a site that returns a “random URL off the internet”. I needed a range of URLs for a test program of mine and just making up a thousand or so URLs is tricky. Thus I wrote this script that I would run and allow to get a range of URLs on each invoke and then run it again later and append to the log file. It wasn’t a fancy script, but it solved my task.

The script was part of a project I got funded to work on, that was improving libcurl back in 2005/2006 so I thought adding and committing the script to CVS felt only natural and served a good purpose. To allow others to repeat what I did.

Fast forward to late 2008. The script is now browsable via viewvc on a site that… eh, doesn’t have “.pl” disabled as a cgi extension in its config! The result of course is that each time someone tries to view the script using the web interface, the web server invokes the script locally!

All of a sudden I get a mail from someone, who apparently is admin or something of the site this old script was using, and he mentions that a machine on our network is hammering his site with many requests per second (38 requests/second apparently) and asked me to stop this. It turns out a search engine crawler has indexed the viewvc output several times, and now some 8 processes or so were running this script.pl and they were all looping around getting a page, outputting the URL, getting another page…

While I think 38 requests second is a bit low to even be considered a DOS, it certainly wasn’t intended nor friendly and I was greatly surprised when I slowly realized how it all came to end up like this! Man I suck! It reminds me of my other extension mess from just a few months ago…

Maybe I’ll learn how to do things right in the future when I grow up!

curl, open source and networking