Rockbox is NOT Linux
Rockbox is NOT Linux
Rockbox is NOT Linux
There. Now please read this post again. It really isn’t. It never was, it never will be. It’s an entirely separate thing, an operating system written entirely from scratch with its own kernel and OS primitives.
Rockbox is NOT Linux
There have been fierce activity in the dusty corners of the Rockbox project known as the SanDisk Sansa v2 hackers guild (no not really but I thought it sounded amusing) and this has so far resulted in early code like LCD drivers and NAND drivers on three new upcoming targets: The e200, Fuze and Clip.
There’s still work to do before the celebrations can start for real, but it’s still nice to see good progress.
Now run over and help out!
(picture by Bertrik Sikken)
Just days after the nice Sansa v2 LCD screenshots, the guys on the Meizu front brought this picture (photo taken by Frank Gevaerts).
It does show a working LCD driver although of course the colours are all messed up due to some glitch still remaining in there…
It’s somewhat confusing with another model called M3, as Rockbox already runs on the iAudio M3 since March 2008. I think we need to refer to the Meizu M3 as MM3 or perhaps always with Meizu prepended or similar to differentiate between them properly.
Nice job!
The small team of Rockbox hackers working on the Sandisk Sansa v2 architecture have been doing some great progress recently and I think it’s fair to say that we all enjoy Rafaël Carré’s photo on the left here (showing a Sansa Clip) that shows the state of where things are right now.
There is code running. There’s a start on a LCD driver and there’s a working concept to put our own bootloader code onto the device that can load and start rockbox in a future.
Nice work on this guys!
Randal Schwartz and Leo Laporte interviewed our own Paul “Llorean” Louden about the Rockbox project on FLOSS Weekly and we were a bunch of Rockboxers hanging out on the IRC channel #rockbox while it was streamed live. This will be in the FLOSS Weekly episode #43 that’s supposedly going to become available on friday the 3rd of October.
I think Paul did a great job explaining a lot of things, big and small, around the project and how it works and runs.
Ok so the guys on the Linux Action Show podcast don’t really get a lot of bonus points from me lately. The episode after they had their “we need to sell proprietary software” outburst, they slammed the Rockbox 3.0 release (roughly 23:40 into the episode for you who want to fast-forward to it).
They started off the news about Rockbox 3.0 claiming it is based on Linux (which it isn’t and never was), only to mention that they failed to install on their ipod 3rd gen at their first attempt (but succeeded at a second attempt), whined somewhat on the installer and then again complained about the inability to install themes even though this is 3.0 yada yada yada.
All in all, pretty much a complete non-understanding for the hard work and endless time that hundreds of people have put into Rockbox. Nothing particular to hear or care about, just a bit annoying.
In the Rockbox project we’ve been using a rather sophisticated build system for many years that provide updated binary packages to the public after every single commit. We also provide daily built zips, manuals, fonts and other extras directly off the subversion server fully automatic every day.
I used to be in the camp that thought that this is a very good system to the extent that it makes ordinary version-numbered releases somewhat unnecessary since everyone can easily get recent downloads whenever they want anyway. We also had a general problem getting a release done.
But as you all know by now, we shipped Rockbox 3.0 the other day. And man did it hit the news!
lifehacker.com, gizmodo.com, engadget.com, slashdot.org, golum.de, boingboing.net, reddit.com and others helped us really put our web server to a crawl. The 4 days following the release, we got roughly 160,000 more visits on our site than usual, 5 times the normal amount (200,000 visits compared to the “normal” 40,000).
Of course, as a pure open source project with no company or money involved anywhere, we don’t exactly need new users but we of course want more developers and hopefully we do reach out to a few new potential contributors when we become known to a larger amount of people.
So I’m now officially convinced: doing this release was a good thing!
We finally shipped it!
Corbet mocked us a bit about the very very long time since the previous Rockbox release, but we finally released Rockbox 3.0 and all is fine and dandy now.
Ryan and Peter from Engadget and Gizmodo fame are now making a new site and podcast series. The latter seem to have climbed the “charts” very rapidly and it is a top podcast in the tech sector on itunes apparently.
Anyway, in the second episode (about 20 minutes into it) they did a very brief and non-explanatory reference to Rockbox about wanting to install it on a SanDisk Sansa e280. Anyway, they didn’t say much about it at all but I simply enjoyed having it reached that level of no-need-to-explain-what-it-is-when-mentioned.
So I wrote this little perl script to perform a lot of repeated binary Rockbox builds. It builds something like 35 builds and zips them up and gives them proper names in a dedicated output directory. Perfect to do things such as release builds.
Then I wrote a similar one to build manuals and offer them too. I then made the results available on the Rockbox 3.0RC (release candidate) page of mine.
Cool, me thinks, and since I’ll be away now for a week starting Wednesday I think I should make the scripts available in case someone else wants to play with them and possibly make a release while I’m gone.
I did
mv buildall.pl webdirectory/buildall.pl.txt
… thinking that I don’t want it to try to execute as a perl script on the server so I rename it to a .txt extension. But did this work? No. Did it cause total havoc? Yes.
First, Apache apparently still thinks these files are perl scripts (== cgi scripts) on my server, even if they got an additional extension. I really really didn’t expect this.
Then, my scripts are doing a command chain similar to “mkdir dir; cd dir; rm -rf *”. It works great when invoked in the correct directory. It works less fine when the web server invokes this because someone clicked on the file I just made available to the world.
Recursive deletion of all files the web server user was allowed to erase.
Did I immediately suspect foul play and evil doings by outsiders? Yes. Did it take quite a while to restore the damages from backups? Yes. Did it feel painful to realize that I myself was to blame for this entire incident and not at all any outside or evil perpetrator? Yes yes yes.
But honestly, in the end I felt good that it wasn’t a security hole somewhere that caused it since I hate spending all that time to track it down and fix it. And thanks to a very fine backup system, I had most of the site and things back up and running after roughly one hour off-line time.