I find it noteworthy that the FSF runs a campaign they call playogg in which they detail the importance and stuff why people should avoid non-free formats and instead use Ogg Vorbis in preference to mp3 for example.
Yet, they document a number of alternatives for Mac users, for Windows users etc on the front page, but there’s not a single word of advice for people with portable music players. Then again, it is very hard for people to find free software alternatives to their portable music players and FSF being so very anti-closed source this makes me wonder why there’s no mention of Rockbox, ipodlinux or even sansalinux to be found?
The only place with this info that I could find when following links from their site, was about three clicks away on xiph.org’s PortablePlayers wiki page but the majority of the stuff mentioned there is non-free…!
I’m not aware of any solid plans on a gcc port yet, but I can confirm that TI plans to offer C64x+ C compiler and assembler tools similar to the way we provide the C54x tools for the current OSD. The restrictions and registration might not be exactly the same, but my view is that the important thing is to get something out there that any hobbyist can use for free. It doesn’t make a lot of sense for someone doing coding for use in their own living room to need to pay $3000+ for a full set of development tools when all they need is a C compiler they can run on their Linux box.
I acknowledge that Neuros really seem to make efforts to make things truly open and free, but TI’s ways are often far from straight-forward and obvious. Jason refers to his presentation from Lugradio live, but I don’t see how that clarifies anything on the openness front.
Personally, I’m not convinced when I see TI speak of Open Source since I’m fully aware of their history and I even believe that this brand new “open” platform still requires TI’s restricted-but-free compiler for the DSP. Of course it is more open than many other platforms, but I dislike when someone tries to sound all fine and dandy while at the same time they’re trying to hide some of their better cards behind their back.
A truly open platform would not give TI an advantage. It would offer anyone wanting to do anything with it the same chance. This platform does not. After all, having it built around one of SoC flagships should be enough for them and should be a motivator for them to make this as successful (and thus as open) as possible.
I think it is sad that Neuros repeatedly does this kind of statements. Their original “open source” player was never open source (to any degree). Their OSD player is largely open source but huge chunks of it is not. Now they try to announce even more openness for an entire platform and yet again they fail to actually deliver a truly open product. Neuros shall forever be known as the company who seems to want to do right, but always fails to in the end nonetheless.
Update: Joe replied on the list to my question about the DSP tool(s) and it certainly sounds as if TI may in fact release a more open tool and/or even a gcc port!? If that turns out true it will of course squash most of my complaints here!
Accessibility and localization improvements for Rockbox, which bascially means work on getting speech and translations work for plugins. I will personally mentor this project/student.
ARM Emulator and a set of peripherals, to allow a real ARM-based firmware to execute and run in an emulator. Should be handy for reverse engineering, debugging and optimization. Most likely this will be based on SkyEye.
Rockbox as an application on a Unix based smart phone – the student mentioned a Motorola Linux-based phone, but I’m not sure if that is carved in stone yet.
WPS/Theme Editor – a PC based tool to help designing WPSes and themes for Rockbox.
We should soon have the official wiki page updated to properly mention that the European Rockbox Devcon 2008 will be in Berlin June 28-29th. The exact address being
the HQ of VAMED Deutschland (www.vamed.de)
Schicklerstr. 5-7, D-10179 Berlin
I certainly am gonna go there and I hope as many as possible of all Rockbox hackers will too, at least you who live on this continent.
There’s also a Devcon West 2008 planned, due to be sometime after the summer around the US west coast or something. Personally, I hope to be able to go to that too, but we’ll see how things look later on when they have a fixed time and location.
A lot of people have asked me about my opinions on and comparisons between these babies, the Cowon D2 and the Meizu M6, and here’s my take. Of course a lot of this involves the original firmwares’ functionalities as that’s what I’ve been using on them so far. The Rockbox port for the D2 is progressing at great speed but isn’t yet capable of producing sound, and the Meizu port still has a long way to go (since it’s still in its infancy with research and reverse engineering being the primary doings atm).
Touch screen isn’t really the best idea for a portable media player I’d say, but I must confess that the UI with “pop-up” buttons is rather nifty. See this little video for a grasp on how it works:
I haven’t used it a lot but the UI is working nicely and is fairly easy to use. I haven’t yet got myself an SD card to insert and try out, but I should soon! It does have visible tiny little screws that shows it could be disassembled quite possibly without too much efforts. Some of my other Rockbox friends are interested in the D2 quite a lot because it comes in a DAB model too, but my version is limited to FM radio only and even
Next to the D2 this baby feels extremely small. It also has no visible screws or anything that reveals how it could be disassembled! The bootup procedure is first a bit silly since you need to hold down the PLAY key for a while but it doesn’t actually start until you release it, and you don’t know exactly how long you need to hold it. But then I think it proceeds nicely with the screen not even showing that it started, apart from a little “Loading…” text.
The M6 doesn’t use a touch screen but instead they have a “weirdo” slider pad with four button areas. Most of everything in the UI that goes up and down, like moving in menus, changing values, changing volume etc is done by letting a finger slide on the pad. This could’ve been a nice way of input if it wasn’t far too sensitive and thus I always seem to miss my goal menu item and have to go up and down several times before I manage to “hit” my target. Quite annoying!
Of course one downside with this player that isn’t a surprise at all but can be stressed, is the lack of any expansion slot so the original 8GB I got is all this unit is ever gonna see.
I think I end up liking the D2 somewhat more, mostly because of the slider on the M6 being annoying and that the D2 is expandable. The D2 also has a nicer OF (original firmware), but that’s not really what I care about since I plan to run Rockbox on both. Unfortunately I’ve not had a lot of spare time for actually getting into the hacking recently so right now I can’t comment on that much. I’ve seen interesting progress done by others in the mean time though!
I cannot say that the D2 is twice as good as the M6 so I’d actually say that M6 is a better value purchase.
Ok, that’s it for now. These are my first impressions, I’ll try to come up with some further ones later on after some more usage and hopefully some real rockboxing on them
A while ago I noticed that my gnome-terminals all of a sudden started to do blinking cursors. Oh the guys who thought that is a good idea to add it without any option to disable it should surely be given a proper eh well, lesson on how to do things right.
Then, just today I did apt-get update on my laptop only to find out that multi-gnome-terminal is now removed in Debian so my favorite terminal is no more!
Update: checking with gconf-editor under desktop > gnome > interface, there’s a checkbox for “cursor_blink” that I unchecked and wham, now the blink is gone!
Occasionally people ask me or just mock me because we’re still using CVS in the curl project, even though there are much more compelling alternatives out there now. Subversion, git, Bzr, Mercurial, etc. I am even a contributor and committer in the Subversion project. (Although I’ll be the first to admit that I never committed much and the stuff I did was done many years ago.)
CVS just isn’t bad enough to warrant the work of a replacement. curl is a tiny project (source code wise) and while CVS has several flaws in how it is designed and works, those flaws never hurt us much. Basically the only one is the lack of rename support and that has no major impact on us.
On the contrary, CVS has the upside of being established and rock solid since many years so people on all sorts of platforms can use it and get the curl source code. This is important especially for our automated build-system which we try hard to find volunteers for to run automatically daily around-the-clock (the results and outputs are then mailed to our central autobuild master server that collects and presents them) and then those guys need to be able to checkout the code easily. Using more modern tools will make it harder since those aren’t available as widely as binary packages for as many (outdated) platforms as CVS is.