Fossgruppen – Swedish fossers

Haxx is dedicated and committed to work with open source as much as possible, and we love and praise the virtues of free and open source software.

We have teamed up with a bunch of friends here in Sweden that share a lot of our mindset and spirit, and together we’ve created Fossgruppen, The Foss Group, and as an umbrella organization the group is all about making it easier for companies and people in Sweden and the world to find open source professionals. We offer open source consultants, foss-related training/courses and more.

If you’re looking for Open Source professionals in Sweden, no other company or association can compete with the amount of experience and core hacker geekness that Fossgruppen possesses. Together we also have contributors and maintainers of a range of foss projects. If you have any insights at all into foss in Sweden, there is no doubt that you will recognize more than one name in our group.

The guys in Fossgruppen are also involved in some of the biggest recent foss-related events in Sweden: foss-sthlm and FSCONS.

Fossgruppen currently consists of this team of elite guys:

  • Daniel Stenberg
  • Björn Stenberg
  • Simon Josefsson
  • Henrik Sandklef
  • Jonas Öberg
  • Johan Thelin
  • Henrik Nordström
  • Andreas Nilsson
  • Jeremiah Foster
  • Mathias Klang
  • Peter Stuge
  • Marcus RejÃ¥s

The web site is basic so far, and we don’t really have a shiny logo to show off with yet but I’m confident we will sort all that out over time!

My presentation on Reverse Engineering

As mentioned before, I visited the event arranged on Software Freedom Day 2010 here in Stockholm Sweden by the Swedish Linux Foundation (Svenska Linuxföreningen). There, I did a one hour talk in Swedish about how we reverse engineer mp3 players in the Rockbox project, and then I ventured in and told them about Rockbox, what it is and what it does etc. I’ve done basically this talk before. I got lots of good questions and general feedback; I believe the audience mostly appreciated it.

curl: ten years of more code and contributors

It feels like I’ve been doing curl forever, while in fact it is “only” in its early teens. I decided to dig up some numbers on how the development have been within the project over the last decade. How have things changed during the 10 most recent years.

To spice up the numbers, I generated some graphs based on them and to then make the graphs nice and presentable I moved them all over to a single graph using my super gimp powers.

Bugs, Linus of code and contributors over time in curl

Click the image to get a full resolution version. But even the small one shows the data I wanted to illustrate: we gain contributors in roughly the same speed as we grow in lines of code. And at the same time we get roughly the same amount of bug reports over the years, apparently independently from the amount of code and contributors! Note that I separate the bug fixed bars from the bug report bars because bug fixed is the amount of bugfixes mentioned in release notes while the bug reports is the count in the web based bug tracker. As seen we fixed a lot more bugs than we get submitted in the bug tracker.

I should add that the reason the green contributor line starts out a little slow and gets a speed bump after a while, is that I changed my way of working at that point and got much better at tracking exactly all contributors. The general angle on the curve for the last 4-5 years is however what I think is the interesting part of it. How it is basically the same angle as the source code increase.

The bug report counter is merely taken from our bug tracker at sourceforge, which is a very inexact count as a very large amount of bugs are reported on the mailing lists only.

Data from the curl release table, tells that during these 10 years we’ve done 77 releases in which we fixed 1414 bugs. That’s 18.4 bug fixes per release and one release roughly every 47 days on average. 141 bug fixes per year on average.

To see how this development has changed over time I decided to compare those numbers against those for the most recent 2.5 years. During this most recent 25% of the period we’ve done releases every 60 days on average but counting 155 bug fixes per year. Which made that the average number of bug fixes per release have gone up to 26; one bugfix every 2.3 days.

A more negative interpretation on this could be that we’re only capable of a certain amount of bug fixes per time so no matter how much code we get we fix bugs at roughly the same rate. The fact that we don’t get any increasing amount of bug reports of course speaks against this theory.

Snaxx 23

For the 23rd time we’re gathering friends in the Stockholm Sweden area who’re interested in technology, open source, beers, Monty Python, reverse engineering, rewriting things into assembler for the fun of it and similar very important topics.A pint of guinness

Snaxx-23

Haxx happily invites you to waste an evening by talking and drinking at October 18th 2010 with us and friends in our spirit.

[ we should get ourselves a snaxx logo, so if you’re reading this and have some talent consider yourself wanted and appreciated! ]

Testing 2-digit year numbers in cookies

In the current work of the IETF http-state working group, we’re documenting how cookies work. The question came up how browsers and clients treat years in ‘expires’ strings if the year is only specified with two digits. And more precisely, is 69 in the future or in the past?

I decided to figure that out. I setup a little CGI that can be used to check what your browser thinks:

http://daniel.haxx.se/cookie.cgi

It sends a single cookie header that looks like:

Set-Cookie: testme=yesyes; expires=Wed Sep  1 22:01:55 69;

The CGI script looks like this:

print "Content-Type: text/plain\n";
print "Set-Cookie: testme=yesyes; expires=Wed Sep  1 22:01:55 69;\n";
print "\nempty?\n";
print $ENV{'HTTP_COOKIE'};

You see that it prints the Cookie: header, so if you reload that URL you should see “testme=yesyes” being output if the cookie is still there. If the cookie is still there, your browser of choice treats the date above as a date in the future.

So, what browsers think 69 is in the future and what think 69 is in the past? Feel free to try out more browsers and tell me the results, this is the list we have so far:

Future:

Firefox v3 and v4 (year 2069)
curl (year 2038)
IE 7 (year 2069)
Opera (year 2036)
Konqueror 4.5
Android

Past:

Chrome (both v4 and v5)
Gnome Epiphany-Webkit

Thanks to my friends in #rockbox-community that helped me out!

(this info was originally posted to the httpstate mailing list)

Beyond just “69”

(this section was added after my first post)

After having done the above basic tests, I proceeded and wrote a slightly more involved test that sets 100 cookies in this format:

Set-Cookie: test$yy=set; expires=Wed Oct  1 22:01:55 $yy;

When the user reloads this page, the page prints all “test$yy” cookies that get sent to the server. The results with the various browsers is very interesting. These are the ranges different browsers think are future:

  • Firefox: 21 – 69 (Safari and Fennec and MicroB on n900) [*]
  • Chrome: 10 – 68
  • Konqueror: 00 – 99 (and IE3, Links, Netsurf, Voyager)
  • curl: 10 – 70
  • Opera: 41 – 69 (and Opera Mobile) [*]
  • IE8: 31 – 79 (and slimbrowser)
  • IE4: 61 – 79 (and IE5, IE6)
  • Midori: 10 – 69 (and IBrowse)
  • w3m: 10 – 37
  • AWeb: 10 – 77
  • Nokia 6300: [none]

[*] = Firefox has a default limit of 50 cookies per host which is the explanation to this funny range. When I changed the config ‘network.cookie.maxPerHost’ to 200 instead (thanks to Dan Witte), I got the more sensible and expected range 10 – 69. Opera has the similar thing, it has a limit of 30 cookies by default which explains the 41-69 limit in this case. It would otherwise get 10-69 as well. (thanks to Stanislaw Adrabinski). I guess that the IE8 range is similarly restricted due to it using a limit of 50 cookies per host and an epoch at 1980.

I couldn’t help myself from trying to parse what this means. The ranges can roughly be summarized like this:

0-9: mostly in the past
10-20: almost always in the future except Firefox
21-30: even more likely to be in the future except IE8
31-37: everyone but opera thinks this is the future
38-40: now w3m and opera think this is the past
41-68: everyone but w3m thinks this is the future
69: Chrome and w3m say past
70: curl, IE8, Konqueror say future
71-79: IE8 and Konqueror say future, everyone else say past
80-99: Konqueror say future, everyone else say past

How to test a browser near you:

  1. goto http://daniel.haxx.se/cookie2.cgi
  2. reload once
  3. the numbers shown on the screen is the year numbers the browsers consider
    to be the future as described above

Nominations for Nordic Free Software Award 2010

Until October 22 you can nominate a person, a project or an organisation for the Nordic Free Software Award.

The Nordic Free Software Award is given to people, projects or organisations in the Nordic countries that have made a prominent contribution to the advancement of Free Software. The award will be announced during FSCONS 2010 in Gothenburg.

To nominate your favorite, email award at fscons.org with the following information:

  • Name of nominee
  • Description/Bio of the nominee
  • Motivation for the award
  • Description of accomplishments

Yours truly was awarded last year together with Simon Josefsson. 2008, the award was given to Mats Östling and 2007 to SkoleLinux.

Now go send in your award nomination.

Disclaimer: I’m a member of the jury this year!