Apple patents another Rockbox idea

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

Explanation for hjsdhjerrddf.com domains

In case you’ve checked some of your spam mails recently you might’ve discovered how a large amount of them include links to sites using seemingly very random names in the domain names. Like hjsdhjerrddf.com or qwetyqfweyqt.com and so on. Hammering-the-keyboard looking names.

The explanation behind these is quite simple and sad: ICANN allows for a “tasting period” before you pay for the domain. Thus spammers register all sorts of random names, spam the world with mails referring the users to these domains and then they return the domain names again before they’ve paid anything, and go on to the next names.

With a large enough set of people and programs doing this, a large amount of names will constantly be kept in use but not paid for and constantly changing owners.

Conclusion: wherever there’s a loophole in the system, someone is there to exploit it for the purpose of sending spam.

More suggested HTTP fun

I’ve already previously expressed my deepest dislike with where the HTML5 work is going, and just yesterday two new internet-drafts appeared on ietf.org that spurred up discussions all around. They’re claimed to be “part of our effort to remove from HTML5 sections that are more appropriate elsewhere” but I’m thinking they’re rather inappropriate everywhere…

The first one named Content-Type Processing Model hits a subject that I’ve been over before, namely the stupidity of having web browsers guess the content based on what it looks like. IE introduced the “I really mean it property“, the HTML5 team wants to standardize the way of the guessing. Personally, I think the world of web will become a better place if the browsers would instead become stricter and more closer follow what the servers actually say the contents is, and then all users would complain to the site admins if things are wrong and then things should be fixed.

Guessing content types allows for sloppy behaviors, it makes it harder to write browsers for the web and it still features a significant risk of guessing wrong.

The second draft propagates for the new HTTP header “Origin”, which according to the authors would help to guard servers against CSRF (“Cross-Site Request Forgery“). The main author says 3% of users on the Internet gets their Referer header stripped while virtually none gets Origin stripped. I claim this is a bogus argument since they strip Referer beacause it is a known and established header and Origin is not. I also completely fail to see the goodness of this and based on several of the other responses on the ieth-http-wg mailing list I am not alone…

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.