Haxx – the first year

Last year I left my former employment, and focused on Haxx full-time. My brother joined me a few months afterward (January 2010). Today, at October 1 2010 we celebrate the official one year anniversary of Haxx AB as employer.Haxx

The history of Haxx goes far longer back than so. Linus Nielsen Feltzing and I first registered the company Haxx back in October 1997 and we used it then primarily as a way to market and do business on the side of our “real” jobs. To have a way to charge and do things we wanted to, that wasn’t conflicting with our day jobs. And of course we also bought the domain and could setup our “permanent” email addresses etc, which turned out great since I’ve thus used the same email address since back then and I hope I never need to change it again!

The first year of Haxx has been nothing but great fun and a major success.

As we’re contract developers and consultants, we of course need to make sure that our employees are sold to customers to a high degree with as little gaps as possible. Our projects are typically going on from a few months up to a year or two. During this year, both me and Björn have worked with several end customers and we’ve thus both managed to change assignments several times and none of the times caused any gaps – at all. Our services seem to be in high demand.

Being only two employees brings challenges on how to deal with sales, financial accounting etc as we’re just a few guys and we’re experts on development! We have found a few great partners that “sell” us (and of course we pay them a certain amount of percentage, but that’s a price we need to accept and is nothing but fair anyway since we can then remain doing what we’re good at and what we love) and we’re buying the bookkeeping etc from another company that is specialized at doing it for companies like us.

We’re looking forward to many more years of great fun. We also hope to be able to grow the company slightly over time, so if you’re a kick-ass embedded open source guy with networking experience and some 10+ years in the business and you live in the Stockholm Sweden area, do get in touch! As I’ve mentioned before, we’re gonna start out our second year with Linus onboard.

I’ll get back with an update next year! 🙂

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!

Haxx gets Linus over to the good side

Linus Nielsen Feltzing and I founded Haxx a long time ago, so therefore it is extra fun to welcome him to join me and Björn to work full-time for our small but already now skill-packed company. Starting December this year, Linus will do all his consultancy and contract work wearing his Haxx hat and no other. Employee number three.

He comes from an employment at the same consultant company I was employed by before (and Björn was too a while ago). With this addition Haxx is now having three full-time consultants with more than 20 years of experience each within software development and embedded systems. We have a long and thorough experience in Linux and networks, in embedded and in larger systems.Haxx

Björn and I originally got to know Linus back in 1988 when we visited a “copy-party” in Alvesta Sweden. There we (the C64 demo group named Horizon) competed against the other teams in the demo competition. We won the competition with our demo “Love This Now” while the fellows in Microsystems Digital Technology (MDT) came at second place with their “Bonanza“.

MDT consisted of two persons, and one of them was Linus.

After Alvesta, Linus and Jörgen (the other MDT member) joined Horizon and we’ve known each other since. We’ve worked on the same companies since the late 90s something until the day last year when I started working full-time for Haxx.

Linus is a hardcore embedded developer, working close to hardware and the OS, writing primarily C and assembler code. He has worked a lot with various RTOSes and Linux.

Linus is also known as one of the founders of the Rockbox project together with me and Björn.

My projects will never be GNU

I’m maintaining a bunch of projects and at times I think about joining some kind of umbrella organization to find a foster family for the project. An organization that’s bigger than just that single project that possibly could be helpful in a lot of ways.

A gnu head!

One large and famous such umbrella project for free and open software is GNU, Gnu’s Not Unix. To submit your software to GNU, they have a set of rules you need to obey. and here’s my reasons why the projects I maintain most likely will not ever become GNU projects:

  • GNU programs should come with documentation in Texinfo format – Oh man, so we need to provide an inferior documentation format of the docs for our software just to be GNU? It doesn’t make sense. And of course, info also sucks.
  • A GNU program should use the latest version of the license that the GNU Project recommends ”not just any free software license. For most packages, this means using the GNU GPL” – for many existing projects the selected license was carefully chosen and if the project has existed for a while changing license is not an easy task. I would also consider it out of the question for many projects. A true stopping requirement for most of my projects.
  • the documentation files and comments in the program should speak of GNU/Linux systems, rather than calling the whole system Linux, and should use the term free software rather than open source – blah. I often speak of “open source” and I like the term “Linux” because of its simplicity and it being easier to pronounce than GNU/Linux.

In all, this just proves that I don’t share the religious and strong philosophical views on life and everything that the GNU people posses.

I’m quite simply not a GNU person. I sympathize with their general goals and I know and support a lot of GNU hackers and projects. I just can’t make my projects join the project.

Linuxträff 2010

I’ll be brief:

On the Software Freedom Day 2010 (September 18th), the guys in “The Swedish Linux Association” (Svenska Linuxföreningen) are organizing a day with talks and presentations about Linux and foss related subjects, which they call Linuxträff 2010. It takes place in Stockholm city, Sweden.

At that event, in the 11:00 – 12:00 time slot, you will be able to see and hear me do a little talk about Rockbox and reverse engineering to get free software on consumer electronics.

See you there!

selinux-pingvin-gnu-demon

curl, open source and networking