Anthony Bryan seems to have worked hard lately and we’ve seen him submitting his Internet Draft for Metalink XML Download Description Format on the http-wg mailing list, and now the 02 (zero two) version is up for public browsing and commenting at
http://tools.ietf.org/html/draft-bryan-metalink-02
… and his interim versions are also browsable here.
Some clever hackers in the Rockbox community wrote up a tool to access the Meizu players’ DFU mode (while running Linux – which I already mentioned), and using this we can upload and run code on several Meizu targets. The code is put and executed in SDRAM only. It makes it a perfect way to test new code on it.
The Meizu players have their SoC in common with Apple’s Nano 2nd gen and Shuffle 2nd gen.
There are indications that the Nanos have such a DFU mode as well, even though we don’t currently know of any way to trigger it by will. Possibly shorting the NAND chip or destroying the firmware or similar might do it.
If you have such a broken Nano or Shuffle, please get in touch and we can do some poking around!
Obviously, there’s a DFU mode on the iphone and iPod touch that can be triggered:
“Your phone must be off, but attached via USB to the PC. Then you hold the power and “home” buttons for 10 seconds. At the ten second mark, you release the power button, but keep the “home” button pressed for another 10 seconds. At the end of that process, the phone enters DFU mode (the only way to tell is windows will tell you a USB DFU device has connected)” (thanks to GodEater)
Although I’m convinced our limited DFU experiments will not be a lot of fun on those devices (yet).
It seems iPod Classics can also go into this mode.
For the iPod Nano 2nd gen:
“To access DFU mode, reset the iPod with MENU+SELECT, then press and hold BACK+PLAY. A picture of the dock connector should appear with the Apple support URL; according to lsusb, this is DFU mode…Â it seems that you have to first trash the firmware before you can access it.” (thanks to LambdaCalculus37)
Since autumn 2009, Rockbox boots and runs on the iPod Nano 2nd generation!
Here’s a license dilemma for you:
Imagine company X hosting a tarball on their public web server. There’s no publicly available link to this tarball, but if you access the URL with your browser or download tool, you can download it with no restrictions from anywhere in the world.
The tarball contains GPL code. That is, the code in question has GPL license headers (in addition to Copyright (C) by Company X notices).
If you get your hands on said code, is it to be considered GPL and thus valid to be used by a GPL-compatible open source project?
Arguments against this include that the tarball, while being accessible, may not actually have been meant for distribution and thus the license may perhaps not be the one intended for the code in the end.
What if someone would publish the link on a totally unrelated site and say “get the code [here]” and link to the above mentioned code. Wouldn’t that cause at least some people to get the code in good faith and then would the GPL apply?
(Any resemblance to a real-life scenario is purely coincidental. Names have been changed to protect the innocent.)
With almost 40 described bug fixes curl and libcurl 7.19.0 come flying with a range of new things, including the following:
We’ve worked really hard to get this to be a really solid and fine release. I hope it’ll show.
As the primary curl author, I’m finding the comments here interesting. That blog entry “Teaching wget About Root Certificates” is about how you can get cacerts for wget by downloading them from curl’s web site, and people quickly point out how getting cacerts from an untrusted third party place of course is an ideal situation for an MITM “attack”.
Of course you can’t trust any files off a HTTP site or a HTTPS site without a “trusted” certificate, but thinking that the curl project would run one of those just to let random people load PEM files from our site seems a bit weird. Thus, we also provide the scripts we do all this with so that you can run them yourself with whatever input data you need, preferably something you trust. The more paranoid you are, the harder that gets of course.
On Fedora, curl does come with ca certs (at least I’m told recent Fedoras do) and even if it doesn’t, you can actually point curl to use whatever cacert you like and since most default installs of curl uses OpenSSL like wget does, you could tell curl to use the same cacert your wget install uses.
This last thing gets a little more complicated when one of the two gets compiled with a SSL library that doesn’t easily support PEM (read: NSS), but in the case of curl in recent Fedora they build it with NSS but with an additional patch that allows it to still be able to read PEM files.