In the Rockbox project we haven’t had an official release in several years. We have >400K lines of code, some 60 committers. Some 300 patch contributors. At least 10,000 users, but probably up to 10-20 times that number.
We produce binary downloads after every single commit. We provide daily builds with a 30 day backlog. We provide a UI-based installer that can install the latest package for you.
So, we have a fair setup that provides releases in a fine way to everone interested. What we don’t have is a stable offer. Nobody can get a recent “stable” release (with a set of known bugs) or similar. We only have this endless series of “beta”-releases. We don’t have any particular push for doing a “real” release and among the developers there aren’t that many who think making releases is any fun, so we’re not really striving towards that.
The last time we tried to put together a release (to be called “3.0”) we decided to have a feature freeze period in which we’d only commit bug fixes and not do any new features. This lead to that most people simply stopped committing and developed their new stuff on the side, waiting for the freeze to go over. Only a few people did any actual bugfixing while we had some pretty serious flaws still in the code, so even with extended freezes we just couldn’t get the bug count down to a satisfiable level… we ended up just dumping the idea of a release 3.0 at that time, and it left some scars in the community that has so far prevented us from returning to this topic.
This said, today we’re more than 18 months further down the road, Rockbox runs on many more platforms, lots of code has changed and been improved since the previous 3.0 effort. Maybe it is time to once again make a release-attempt?
I think there are a few preconditions we need for this to succeed, including:
- We need a single release manager person who single-handedly can decide when the release is finished. This person would also have the final say on the outstanding-issues list etc. We can’t manage to get consensus among this large amount of people for this black-and-white style of questions.
- We need to accept that fact that some bugs just have to be in the release and we can live with them – after all most of these sorts of bugs have been with us for a very long time already and all of us have managed to live and use Rockbox fine for years in spite of their presence.
- We need to accept and realize that most of “us” – the devs, the closest team of followers, will not use the release anyway as the day after the release we will provide a new set of spanking fresh binaries to download and use… We don’t do the release for us. We do the release to the huge audience out there who look for “stable” and “known to work” stuff.
- Less people need to worry and have strong opinions about exactly what goes into the release or not. If we just get one release out, there will follow more further on that will get the stuff that is left out in this!
I am officially not volunteering to be a release manager! 😉
With the recently published jailbreak for iPod Touch, combined with the SDL port for iPhone there should be little in the way for running Rockbox on it as an application, pretty much in exctly the same way I mentioned how Rockbox could be made to run on mobile phones.
It seems a suitable place to start this venture is the iphone-dev project page.
While the iPhone and iPod Touch aren’t 100% identical internally, it seems they’re similar enough to make the differences possible to ignore. Also, the fact that what everyone does is build applications that run under the normal Apple-provided OS, there’s no need to know or learn how to poke on the actual hardware so subtle differences in audio chips etc is abstracted away by the operating system even for applications put on the unit this way.
Update nov 2008: With the recent developments on the linuxoniphone blog, it looks like an iPod Touch version of Rockbox is now a lot more likely to be possible. Still, nobody has yet volunteered to start this work and I won’t even say that it is likely that anyone will make an attempt.
AMS was very friendly and replied to my data sheet requesting email very rapidly, and now I have the data sheet for the AS3525 in my possession. This is good news for an upcoming porting effort to the SanDisk Sansa v2 series of players, but it doesn’t make it all perfectly easy since we still don’t know lots of stuff in them.
The reply even contained these warming words:
“I see your initiative increasingly successful and I just read a good review on PC Magazine. My compliments, an outstanding job!”
If you have one of these players (e200v2, c200v2, m200 v2 or Clip) and you feel like joining this effort, do jump in on the forum and we’ll get something going! I don’t personally have one of these targets, but I’m pondering on getting one…
We’re slowly building a team and effort in the Rockbox project to make a port to the Cowon iAudio 7 player.
It’s a 60 gram 4/8/16 GB flash player with a 1.3″ 160×128 TFT LCD, FM tuner, Telechips TCC771 MCU and a bunch of chips familiar to us from other existing Rockbox ports.
TMM already bricked his first player…
Update: this entry does not allow comments anymore. Go to the Rockbox forums to continue!
There’s a bunch of eager hackers hanging out in the Rockbox forums, working on getting a Rockbox port for the Dell DJ going.
This player has a monochrome LCD at 160×104, features the dreaded TMS320 series MCU and comes with up to 20GB hard drive.
Let me be perfectly clear on this:
Nobody has done any sufficient research or investigation on the iPod Classics for anyone to tell how feasable a Rockbox port is or not. But, based on the assumption that the firmware and design choices are similar to that of the Nano 2nd generation, it offers great challenges to any hacker wanting to go down this road.
Many many people confuse this matter with the recently discussed Apple adding a new checksum to the itunes database, and then the subsequent “crack” of that system. This will only allow Linux-users to use these ipods. It certainly does not in any way make it easier to run alternative firmwares on them.
I would rather say that you should all take this as an indication that Apple really doesn’t care one bit about Linux users. In fact, they only care for those who buy their whole package and that package is Windows with itunes or MacOS with itunes. If you’re not buying that concept, you should avoid Apple. Yes I really mean that.
To get Rockbox running on these models or any of the other newer ipod versions, we need fearless and skilled people to get players, rip them apart and do some actual hard-core research on how their internals work and how the firmware is stored and how firmware upgrades are made etc. The same old new-rockbox port drill.
There might be “an opening” to this device using the DFU mode.
Update: during July 2009 some people in the #linux4nano-dev channel managed to run code on the nano 2g (thanks to an exploit of an buffer overflow) and since then there have been fierce activity and custom code seem to run on the iPod Classics too. Still a lot of work and problems to overcome for a Rockbox port to become reality.
I find it very amusing that Windows users all so often refer to the command line as DOS, and I’ve tried to figure out how we still today frequently get to read users refer to the ancient operating system.
It was in fact still called “MS-DOS prompt” back in windows 98, as shown in this little picture:
I found that even Microsoft themselves refer to the commands you use on the command line as “MS-DOS commands“, so perhaps this is a primary reason? Even the producers of Windows confuse and mix the terms “command line” and “MS-DOS”…
When they launched Windows XP they no longer called it MS-DOS Prompt, it was then plain and simple “Command Prompt”:
We’ve also seen end users in the Rockbox project refer to the interface as DOS or DOS-style, and there is really nothing what so ever in common with MS-DOS in Rockbox. It is just (by default) a basic text-style interface. It is clear that to many people, a text-based interface be it a music player or a command line window, means DOS.
People are weird.
Obviously the CHDK guys have working code for Canon‘s (and other’s) Digic II powered cameras, and reading their wiki they use plain arm-elf for the job and… yeah so does Rockbox and… yeah, well it certainly at least opens a possibility for a Rockbox branch for these toys!
Of course there would be porting involved and I don’t know how these cameras have on the audio front, but those are all just details…