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.
What’s your take on this?
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!
Update: M6 next to D2 pictures
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…
In Sweden we currently have an interesting situation where a hacking group called “Hackare utan gränser” (should probably be “Hackers Without Borders” if translated) hacked one of those auction sites where you make the lowest unique bid to win. The site in question is called bideazy and according to the hacker group’s announcement (forum posting and following discussion entirely in Swedish) their database is full of evidence of the bidding not having been done correctly and it seems to show that the site and company owner has won a large amount of all “auctions”.
And they also made most of that data publicly available.
This brings many questions in my brain, including:
First of course the evident discussion if one crime (the hacking) can be justified to reveal another (the scam), but what I think is more important: isn’t auction sites and especially the lowest-bid kinds more or less designed to open up for the sites to easily scam the users? It is very very hard for someone on the outside of it all to see if things are done the right way and that all rules are followed. Heck, even a little tweak here and there would make a huge impact for the site but won’t be seen by the public.
I also find it a bit funny that in this case is they seem to have stored the scam data neat and properly in their data base which the hackers found, and I really can’t figure out why. If they wanted a database to show as a front end if someone would ask and blame them for cheating, then this wouldn’t be the one. And since they really seem to be cheaters, why would they need to store and keep track of all the cheats in a huge database?
With an unfortunate Sourceforge registry date of April 1st 2008, it could very well be an April’s fools prank but then I can’t see any real reasons why someone couldn’t port ipodlinux over to the Sansa e200 v1 series.
So Sansalinux is working according to their site, and they also provide some crappy screenshots that aren’t really good enough to make it possible to tell if they are for real or fakes.
The uclinux patch on their download page seems genuine and contains a lot of code originating from Rockbox (including copyright lines from Rockbox hackers).
As in the case with the ipod version, it begs the question what they want with this apart from the fun of getting Linux on yet another target. Also, seeing how there’s really no developers around to hack on ipodlinux it’ll be interesting to see if there will be any on the Sansa version. Seeing that it doesn’t run on the v2 version (no surprise really since Rockbox doesn’t either) so there’s no new Sansa e200 to buy to run this linux on.
If someone actually tries this out, please let us know what you find out!
It is with interest we in the Rockbox camp checked out the recent battle in Creative land where they shot down a firmware (driver really) hack by the hacker Daniel_K as seen in this forum thread.
We’re of course interested since we do a lot of custom firmwares for all sorts of targets by all sorts of companies, and recently there are efforts in progress on the Creative series of players so could this take-down move possibly be a threat to us?
But no.
In the Rockbox community we have already since day one struggled to never ever release anything, not code nor images or anything else, that originates from a company or other property owner. We don’t distribute other’s firmwares, not even parts of them.
For several music players the install process involves patching the original firmware file and flashing that onto the target. But then we made tools that get the file from the source, or let the user himself get the file from the right place, and then our tool does the necessary magic.
I’m not the only one that think Daniel Kawakami should’ve done something similar. If he would just have released tools and documentation written entirely by himself, that would do the necessary patching and poking on the drivers that the users could’ve downloaded from Creative themselves, then big bad Creative wouldn’t have much of legal arguments to throw at Daniel. It would’ve saved Daniel from this attack and it would’ve taken away the ammunition from Creative.
I’m not really defending Creative’s actions, although I must admit it wasn’t really a surprising action seeing that Daniel did ask for money (donations) for patching and distributing derivates of Creative’s software.
So far in our 6+ years of history, the Rockbox project has been target of legal C&D letter threats multiple times, but never from one of the companies for which targets we develop firmwares for. It has been other software vendors: two game companies (Tetris Company and PopCap games) fighting to prevent us from using their trademarked names (and we could even possibly agree that our name selections were a bit too similar to the original ones) and AT&T banning us from distributing sound files generated with their speech engine software. Both PopCap and Tetris of course also waved with laywers saying that we infringed on their copyrights on “game play” and “look” and what not, but they really have nothing on us there so we just blanked-faced them on those silly demands.
The AT&T case is more of a proof of greedy software companies having very strict user licenses and we really thought we had a legitimate license that we could use to produce output and distribute for users – sound files that are to a large extent used by blind or visually impaired users to get the UI spelled out. We pleaded that we’re an open source, no-profit, no-money really organization and asked for permission, but were given offers to get good deals on “proper” licenses for multiple thousands of dollars per year.
Ok, so the originating people of the Rockbox project is based in Sweden which may also be a factor as we’re not as vulnerable to scary US company tactics where it seems they can sue companies/people who then will have to spend a fortune of their own money just to defend themselves and then you have to counter-sue to get any money back even if you were found not guilty in the first case. Neither is Rockbox an attempt to circumvent any copy protections, as if it were it would have violated laws in multiple countries and regions. Also, reverse engineering is perfectly legal in many regions of the world contrary to what many people seem to believe.
If this isn’t sticking your chin out, then what is? 😉
Update 4-apr-2008: Creative backpedals when their flame thrower backfired.