All posts by Daniel Stenberg

Rockbox on iPod Nano 4th gen

Michael “TheSeven” Sparmann is one of the primary magicians behind the recent linux4nano efforts and he has done a lot of the Rockbox port for the iPod Nano 2nd generation.

Some 10 hours or so he posted this neat picture:

Ipod Nano 4th generation

… showing off custom code running on an iPod Nano 4th generation. If you want to keep track of his/their work on recent iPods, follow @linux4nano on twitter. I do!

While this is not yet Rockbox on the device, this is a least proof it can be done and this could indeed be seen as the first tiny steps towards a full port! Good job Michael!

First month on my own

Yeah, it’s already been a month since I took off and started working for Haxx full time. Starting a company (even though the company already existed in the legal sense) certainly involves a lot of paperwork and talking to banks, insurance companies and getting arrangements with partners etc. A lot of that of course being just an initial phase, but some of it will be a more integrated part of my day now when I don’t have a well-oiled team of admins hired that deal with such matters.

I’m happy to say that I have had a whole slew of good talks with existing and potentially new customers, and I’m already cooperating with a few companies in very constructive ways – so that I can help others succeed with their undertakings. Several things that happened during this month involved open source (although I’m not able to talk about them in public), and I feel really good when my work and my beliefs can go hand in hand!

This said, I’m always ready for more and new missions. If you’re in need, you know where I am!

Spammers now subscribe

During several years I’ve been setting mailing lists I admin to only accept posts from subscribers iA can with spamn order to avoid having to deal with very large amounts of spam posts.

While that is slightly awkward to users of the list, the huge benefit for me as admin has been the deciding factor.

Recently however, I’ve noticed how this way to prevent spam on the mailing lists have started to fail more and more frequently.

Now, I see a rapid growth in spam from users who actually subscribe first and then post their spam to the list. Of course, sometimes spammers happen to just fake the from address from a member of a list – like when a spammer fakes my address and sends spam to a list I am subscribed to, but it’s quite obvious that we also see the actual original spammer join lists and send spam as well.

It makes me sad, since I figure the next step I then need to take on the mailing lists I admin is to either spam check the incoming mails with a tool like spamassassin (and risk false positives or to not trap all spams) and/or start setting new members as moderated so that I have to acknowledge their first post to the list in order to make sure they’re not spammers.

Or is there any other good idea of what I can do that I haven’t thought of?

null-prefix domino

dominosAt the end of July 2009, Scott Cantor contacted us in the curl project and pointed out a security flaw in libcurl (in code that was using OpenSSL to verify server certificates). Having read his explanation I recalled that I had witnessed the discussion on the NSS list about this problem just a few days earlier (which resulted in their August 1st security advisory). The problem is basically that the cert can at times contain a name with an embedded zero in the middle, while most source code assumes plain C-style strings that ends with a zero. This turns out to be exploitable, and is explained in great detail in this document (PDF).

I started to work on a patch, and in the mean time I talked to Simon Josefsson of the GnuTLS team to see if GnuTLS was fine or not, only to get him confirm that GnuTLS did indeed have the same problem.

So I contacted vendor-sec, and then on the morning of August 5 I thought I’d just make a quick check how the other HTTPS client implementations do their cert checks.

Wget: vulnerable

neon: vulnerable

serf: vulnerable

So, Internet Explorer and Firefox were vulnerable. NSS and GnuTLS were. (OpenSSL wasn’t, but then it doesn’t provide this verifying feature by itself) (lib)curl, wget, neon, serf were all vulnerable. If that isn’t a large amount of the existing HTTPS clients then what is? I also think that this shows that it would be good for all of us if OpenSSL had this functionality, as even if it had been vulnerable we could’ve fixed a busload of different applications by repairing a single library. Now we instead need to hunt down all apps that use OpenSSL and that verify certificate names.

Quite clearly we (as implementers) have all had the same silly assumptions, and quite likely we’ve affected each other into doing these sloppy codes. SSL and certificates are over and over again getting hit by this kind of painful flaws and setbacks. Darn, getting things right really is very very hard…

(Disclaimer: I immediately notified the neon and serf projects but to my knowledge they have not yet released any fixed versions.)

Mini 2440 Lyre

On ebay there’s a fancy S3C244-based board named mini 2440 with a 3.5″ touch LCD attached on sale for 85 USD. 64MB ram, 400MHz CPU, a nand flash and more. Lots of stuff for the money.

mini2440

The guys in the lyre project seem to have adopted this as yet another hardware platform to attempt to run Rockbox on. After their Atmel AT91SAM target was ditched, they went the ARMopendous route and now this seems to have entered. This third hardware platform is called the Lyre prototype 2

You should note that this Mini 2440 board has no batteries or anything and thus is not really meant to be a portable device in this shape.

“Bob” seems to have initial Rockbox code running on this device, and well-established Rockbox hackers JdGordon and domonoky have both ordered their own kits so the future looks bright.

Open Android Alliance

In the past: cyanogenmod made one of the most popular 3rd party Android ROMs for HTC devices. Personally I haven’t yet tried it on my Magic, but friends tell me it’s the ROM to use.Android

On September 24th 2009, Google sets their legal team on the ROM creator, asking him to stop distributing the parts of Android that aren’t open source but in fact are good old traditional closed source apps – made by Google. Cyanogen himself (Steve Kondik) responded something in the spirit that since the ROM only runs on hardware that already runs the apps users already have a license to use them. Google responded, saying they protect the Google Phone Experience.

This C&D act triggered a huge reaction in the Android communities as people suddenly became aware of the fact that A) parts of the Android core OS aren’t at all open (source) and B) Google is not the cuddly Teddy Bear we all want it to be.

In the xda-developers.com front, where a lot of the custom ROMs are being discussed and users of them hang out, they created the Open Android Alliance with the intent of creating a completely open source Android.

In another end and indepedently of the xda-developers it seems, lots of participants in the google group android-platform pretty much decided the same thing but they rather started out discussing exactly what would be needed to do and what code there is and so on.

Currently, both camps have been made aware of each other and there have been expressed intents of joining into a single effort. I don’ t think such subtleties matter much, but we just might see the beginning of a more open more free Android project getting started here. I’ll certainly be interested in seeing where this is going…

Updated: they now have their own domain. Link in article updated.

My Nordic Free Software Awards 2009 nominees

Hey, it’s really about time to nominate your favourite Free Software persons and projects from the nordic region for the 2009 awards before the time runs out.

This year, I decided to nominate the following “nordic” heroes:

Simon Josefsson

For his excellent work in GnuTLS, libssh2 and a bunch of other projects.

Henrik Nordström

For his work in the Squid project, and his efforts within IETF and its HTTP related struggles and more.

Björn Stenberg

As the primary founder of the Rockbox project. He started somehting special back in 2001 that now is a huge, thriving and succesful Free Software project.

As you might spot, I favor “doers”. I don’t believe in the concept of “nordic projects” when it comes to free or open software – the entire concept of open and free should mean that projects cross borders and regions.

In fact, it feels so out of the ordinary to think about open source people in a geographical context I find it hard to come up with a lot of names. It would be cool if ohloh had some ways to list people and projects based on where people live.

Then again, if a person from a nordic country moves somewhere else, is he or she still a nordic person? Does it depend on where the person lived during the actual act? Is Linus Torvalds a nordic person since he was born, lived many years and started his big project in Finland?

(yeah I already blogged about this subject but hey, it can’t hurt can it?)

Rockbox presentation video

Robert Menes held a talk at the NYLUG a while ago about the Rockbox project:

I started out the talk by giving a little background on Rockbox; basically how it started, how it was ported around to new targets, and how the community grew as interest peaked. I showed off features of Rockbox, as well as supported targets, nearly supported targets, and even in-progress targets. I then went into describing Rockbox’s features in greater detail, and then a run-down of the development process, as well as how to compile your own builds. Many people asked questions along the way, so I answered them as they were asked. I also think that people were probably shocked at the sheer amount of targets that were shown off (nearly 40 DAPs were there!)

The 76 minute (1.6 GB) video from that event is available from the download.rockbox.org mirrors. Set your video player to stream from there unless you really want to download that entire thing!

Rockbox at NYLUG presentation video

Sandisk: “our sound fidelity isn’t perfect”

Some owners of the SansSanDisk Sansa Clipa Clip player from SanDisk noticed that it does playback of all songs with a minor pitch. Due to a flawed HW setup they don’t do a proper 44,100 Hz but instead 43,791 Hz (0.993 times the target value) or something like that. According to some sources this problem might be fixed in the Sansa Fuze players now.

Bugs aren’t really so surprising, perhaps what is surprising is that this bug has been around now for almost two years. To make matters worse, SanDisk now decided that due to them making cheap players people shouldn’t expect them to be very good sound quality wise and therefore they can simply not fix the problems:

due to trade-off decisions that were made in engineering these products to deliver superior consumer value at what we believe are extremely attractive price points, our sound fidelity isn’t perfect. We have re-evaluated the possibility of reducing the pitch variation and due to the engineering trade-offs the decision was made to stay with the current design. Very few listeners, however, have noticed or complained about it as an issue in actual practice.  For those who can detect sound differences with their naked ears during actual use and not via frequency analysis, our products may not be the best choice for them.

Clip owners out there now put their hope even more on Rockbox for Clip.


Autotool alternatives

Lots of people whine and complain on the set of build tools we often refer to as a collective by the term ‘autotools’. That term tends to include autoconf, libtool and automake.

I think a certain amount of criticism is warranted against this family of aged tools that are unix-centric, have cryptic ways to control them (I think there’s a reason m4 macros  is not widely used…) and they are several independent tools with a tricky mix of cross-breeding.A build tool

The upsides include them being well tested, fairly well known, there’s a wide range of existing tests done for them, they work fine when cross-compiling and they support building out-of-source tree just fine.

But what about the alternatives?

I spend time in projects where the discussion of ditching autoconf come up every once in a while, as sure as that the sun will rise tomorrow. The discussion is always that tool Z is much better and easier to deal with and that everything gets shiny if we just switch. That Z is a lot of different tools that are available today, including CMake, scons, waf or cDetect.

The problem as I always see and why I almost always argue against Z is that autoconf is old, trusty, proven and I know it. The Z tool is often much newer, less proven, less peoeple involved in the project know Z, use Z or know how to customize it (since new tests will be needed and some tests will need to be changed etc). So even though Z is sometimes accepted as a testing ground in my projects, a year or two after the Z was accepted – unless I myself have accepted it and joined its efforts – Z has lagged behind to a point where it isn’t good anymore since I don’t know it and most people are rather fixing the traditional autoconf stuff. So we extract the Z support again.

But if we would never accept new tools we would never evolve, and yes indeed autoconf and friends have their share of flaws.

The question is of course when to switch – what kind of project in what development state etc – and which alternative that is useful for a particular project. Me being a developer primarily working with plain C and working with lowlevel code and libraries mostly will no doubt have a different view than those who use other languages, who do more “apps” or perhaps even GUI programming…

Can you help me point out good build system comparisions and overiews? I’ve tried to find good comparisions but I failed. Just about all of them are written by the authors of one of these tools.

My ambition is to create some sort of comparison document myself. I think the comparison could include autotools, cmake, waf, scons, cdetect, qmake and ant. Any more?

(I got triggered to write this blog post after my post to the trio mailing list on this topic.)