Category Archives: Open Source

Open Source, Free Software, and similar

Open Source

Project is Standard now

I fell over a (warning: Swedish!) article on the Swedish idg.se site describing the nominees for the yearly award “Guldmusen” (“the golden mouse”). One of them is this year the highly deserving Adam Dunkel, originator of among other things the very cool lwip (light weight IP) open source project.

However, in both articles on IDG that’s not how lwip is described. It is instead claimed to be “an unofficial world standard”.

“world standard” huh? Yes I admit that makes it sound quite a few notches better than “well-used and appreciated open source project”.

But lwip is an TCP/IP stack. A very small one. How can that be a standard, even if you call it an unofficial one?

idg.se continues to be rediculed by me and my friends and the reasons are silly things like this. Let’s hope they continue to amuse us for a long time to come! 🙂

Rockbox

Blame game

I’ve mentioned the fancy distributed build system of Rockbox before, and now it just got even fancier as I’ve introduced a “blame” script that sends a mail to the commit mailing list (that gets mailed with a diff of every single commit) every time one or more builds in the automatic system show up red in the build table. Red builds are for errors (as opposed to yellow for just warnings or green for OK)…

The mail simply mentions that the builds are now red and who did the commit(s) that was included in the failing build. Due to the nature of it, it can be one or more committers and in fact there can be more commits than one from any of them. It’ll help us get alerted about the problems, and hopefully get them fixed again a little faster.

Rockbox

Open Source

Open source personal

I participate in a range of different open source projects. Of course I spend more time on some of them and only a very little time in most of them, but I’m currently listed as member of 18 projects on sourceforge and 16 on ohloh and I can easily figure out a bunch more than aren’t listed on either of those sites.

I’m just the kind of guy who tend to actually get the code and write up a patch for problems, and in fact also in many cases I’ll write an fresh application and publish it openly for the world (not that my typical programs get any particularly large audience but still). I’m not saying everyone has to be like this, I’m just describing me here.

It seems this is a troublesome concept for people to grasp.

I get a large amount of private mail where people talk about “your project” (as in a single one that I am supposed to understand which one they’re referring to) and just about all open source-related interview/questionnaire things I’ve filled in tend to assume My One Single Project. In the first case I can often guess which one they refer to by the phrasing of the mail, and in the second case I tend to answer for the project I’m involved the most in.

So I get this feed of private emails on projects I participate in, but I don’t like private emails about open source projects when people request and expect free support and help. If they want free support, I expect the people to post the questions publicly and open to allow others to reply and read both the question and the subsequent answer online, right there at the time they’re asked but also much later when searching for help on the same subject as then the answers will be around in mailing list archives etc.

These days I have a blanket reply form that I bounce back when I get private support mails and I will admit that most people respect that after having been told about the situation. Every now and then of course I get a violent refusal for sympathy and instead I get to learn I’m an arrogant bastard. This is also related to the fact that:

We (Haxx) run and offer commercial support around curl and libcurl, and for that purpose we have a dedicated support email address. Mail there if you’re willing to pay for support. That’s actually quite clearly spelled out everywhere where that address is displayed, but yet people seem to find that a good place to mail random questions and bug reports. Just today I got a very upset mail response after I mentioned the “paid support” part of the deal there expecting us (me?) to instantly fix bugs regardless since I’ve been told about them per email…

All in all, I’m not really complaining since I’m generally getting along fine with everyone and stuff around this.

Just everyone try to keep things apart: the projects, the people and the companies. They’re sometimes intertwined but sometimes not.

IT Politics, Rockbox

Apple patents another Rockbox idea

2 Comments

We’ve just read about Apple’s patent application (that seems to have been filed on July 17 2007) to alter the volume of a media player based on the external surrounding.

It’s funny how this was suggested to the Rockbox project already back in September 2002 and is logged fine independently by archive.org – and in fact also on Sourceforge where we hosted our request-tracker back then.

This is not the first time we see this consumer electronics giant patent ideas we’ve already implemented or discussed publicly a very long time before in the Rockbox project.

In 2006 Apple filed to patent a system to read up audio clips to the user to help menu navigation, a concept we at that time already had implemented and I must say was fairly polished in Rockbox. (Link to their patent application.)

Two obvious cases of where the ideas certainly were not new. Not that it tend to prevent patent applications, but still…

Rockbox

cURL and libcurl, Development

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?

Rockbox

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 and libcurl

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.

cURL and libcurl, Linux, Security

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.