As I suspected and guessed in my blog post yesterday, Jason Kridner of Texas Instruments responded to the mailing list and confirmed that the “open platform” currently doesn’t even have a free-to-use assembler for the DSP in the DaVinci (which thus has less free tools available than the DM320 series!) and the gcc port seem to be mostly an idea so far:
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!
It was just publicly announced that Rockbox will get 4 slots from Google for this year’s Summer of Code:
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).
Cowon D2
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
Meizu M6
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.
Conclusion
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!
Grrr.
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.
On the libcurl list the discussion popped up how to best add support to do HTTP over unix domain sockets instead of TCP/IP and the discussion took off trying to figure out how to specify this the best way from an application’s point of view.
I hadn’t gotten myself a new DAP in ages, and the last time I got one I had it donated to me from SanDisk. So it was really due time to get back into low-level fighting with Rockbox ports again. I ordered myself an 8GB Meizu M6 (SL) and a 8GB Cowon D2 (DAB-less), since both are very interesting flash-based targets with two very promising early Rockbox-porting efforts and we have data sheets for the SoCs used in both of them ( Samsung SA58700 and Telechips TCC7801).
I decided I should dive right in and also be able to do some nice comparisons of both these targets as they are quite similar spec-wise. Both units arrived at my place at the same time, so I got the chance to get a feel for them at once without any discrimination against either one.
Some first impressions without even having switched any of them on:
The M6 comes in a much smaller box indicating it’s “mini player” style already there. It was also much cheaper, almost half the price of the D2.
The D2 comes with a wall-charger but otherwise both boxes include earplugs, a driver-cd (windows stuff I presume) and a USB cable.
Comparing their physical appearances next to each other, there’s no doubt that the M6 is much smaller (even perhaps amazingly small – but yet with a screen that is considerably larger then for instance my Sansa e200) and I can’t help think that the D2 design is a bit weird has it looks as if it has something that can slide out but it doesn’t. I assume some of the D2’s extra size (thickness) is due to its SD slot (yes that’s full size SD not microSD) which is something the M6 doesn’t feature, not even a micro version. Both have USB mini-B slots and charges over that. The D2 has a small protective cover over the slot.
I’ll provide more fluff like photos comparing them against each other and against other targets soon as well, and perhaps something about how their firmware compares, the status of Rockbox on them etc. Stay tuned!
It’s been a while since we had this discussion so I figure it is about time to re-iterate it and this time I thought I’d do a little blog post to put the lights on my stand-point regarding this issue:
I’ve had this discussion at length with Anthony Bryan (the main man behind the metalink format) privately in the past and I’ve bounced back a lot of feedback on the actual XML format to him and I believe some of that were taken into account and changed the format. Of course this was before it “settled” and started to get adopted. I think metalink is a great idea and the file format is (the last time I checked it out, I can’t seem to find the docs now) mostly making sense.
I have little to no understanding for the idea that libcurl should add support for this natively. metalink is just an XML format that sets up resources for an application to where and how it can download files, and libcurl does indeed support most of the protocols that such URLs can use. libcurl is a data transfer library that is oriented around a given URL and the URL in question has a 1:1 relationship to what protocol it is and it is always content-agnostic.
metalink is application layer, not transport. Adding metalink to libcurl would mean that all of a sudden libcurl would transfer a file and actually parse the (XML!) contents of that file and then get (possibly) multiple streams using multiple protocols based on what that parsing gave. It is just so many new things and violations against key libcurl concepts that I cannot see this done.
Metalink isn’t even a standard so we would then more or less open the gates for further random efforts to introduce similar ideas and whatnot and where would we draw the line? Currently I think we have a pretty solid border drawn in the sand and we don’t cross that line (on purpose).
And frankly, there is only one and one reason only (mentioned and that I can think of) for libcurl to support this feature and I that is because libcurl is already widely adopted it would be easier for metalink to conquer the world by sneaking in the back-door with libcurl as then a large amount of applications would support it with no additional efforts at all. But sorry, I don’t think that’s a good enough reason to break or change these important key concepts/limits of libcurl. (Actually, I think it is a bit foolish to think that adding metalink to libcurl would make all these applications automatically support metalink as there would be several arguments against that too.)
As I’ve said before, I think one of our biggest challenges in this project is to limit what libcurl does, to not allow it to grow in all directions, to keep the scope and to maintain focus.
A metalink file transfer library could be made as a layer on top of libcurl, and I think that is the only logical and sensible way.
Adding metalink support to the curl tool however, seems like a good idea to me…
