The guys working on the Rockbox port for the Olympus M:Robe 500 player have now reached a state where adding mrobe 500 builds to the Rockbox build table makes sense and there will soon also be zip files provided for download for ordinary mortals.
The only thing left before that will happen is some basic documentations adapted for this target for user.
I was just told about it by zivan56, and my mi4 page was just updated: the SanDisk Sansa View uses the mi4 file format and it is clearly PortalPlayer based. mi4code can find the crypto key, so decrypting it for disassembly is easy.
In fact, the zip contains two mi4 files and the second one is called “mediaproc.mi4” seems to be for a separate processor or similar, and it makes sense since the PP can’t do the movie playback etc with the specs that they boast for this player.
That media processor might very well be a “nv6110“, referred to many times in the firmware image.
Go crazy in the Rockbox forum thread about it!
I found this article by Jungle Dave titled Leopard DNS Issues (and work-around), which explains how libcurl built with IPv6 support may cause trouble on MacOS X 10.5 (Leopard).
According to him, that’s because getaddrinfo() causes a SRV lookup to be made and that may be either slow or get discarded completely and thus cause trouble.
This just adds another problem to getaddrinfo() resolves then, since we already have the problem with it when resolving round-robin DNSes since more or less every machine has a bad /etc/gai.conf setup that makes getaddrinfo() return a sorted list instead of the “random” one DNS admins in the wild would prefer the users to use…
I know this is a dear subject for many people but I feel I just have to spell it out after having read this engadget notice about Toshiba’s new 3840 x 2400 22″ LCD screen. They call this a WQUSGA resolution!
Man, can they please stop the silly WQZUXZQGA names for the screen resolutions? I’m a hardcore tech geek myself but I lost track of those weird resolution names a long time ago and I want pure resolution numbers in good old width x height style!
My 1600 x 1200 20″ screen does seem a bit old fashioned in comparison! (and no, I don’t know the name of this resolution either!)
As you should know, we maintain this curl comparison table on the curl web site, and it lists a set of free tools and how they compare against curl and each other in various aspects. If you want more features compared or other tools included, please tell. Also if you disagree with any of the facts stated there, just shout!
The other day I got an email asking me to add aget to the table, and since it is a free tool (original BSD licensed) with a similar purpose it would indeed fit.
So I downloaded aget 0.4 and had a go at it.
- The “stable” 0.4 version doesn’t build out of the tarball. It does wrong assumptions on “errno” and thus I had to manually poke on 3 source files to make it generate a fine binary! While this error is claimed to be fixed in the “devel” version, the devel version fails to build on compiler errors instead!
- My first test was to download aget’s own home page with aget… and it failed. It says the page is 0 bytes and it doesn’t download anything and outputs something about a bad seek 0 bytes!
- This really turned me off, but then I thought I should report this back to the guys rather than just blog it… but there’s no email address in the package that seems suitable, and when checking on the site I find a reference to a mailing list but when trying to read the list’s archive it just redirects back to the main page! So blogging it is.
- aget 0.4 from 2002, the aget devel version is from June 2004. Development seems to have stopped.
- I decided aget isn’t going to be added to the table by me at this time. It’ll have to mature some more first (and given the age of the tarballs I doubt that’ll happen…). I also read through the source code a bit and it really gives the impression of being a young project that hasn’t yet have time to settle since there are numerous of suspicious conclusions and source code doing “funny” things.
gmail is fancy and offers lots of space
gmail is often praised these days by people all over, and yeah it is a neat web app and the amount of disk space they offer for this free service is daunting!
I do however have several arguments against using gmail that make me not using it myself for anything that is critical.
gmail blocks zip files
The main and major complaint can be phrased like this:
(reason: 552 5.7.0 Illegal Attachment p9si2809195fkb)
That’s the exact message gmail includes in the reject mail when I try to mail my own account with a zip file attached. The zip file itself is perfectly harmless (and contains source code).
I actually get completely legitimate zip files from people every now and then, perhaps even once per week or so and having it reject these mails without even properly explaining why to the user is quite a show-stopper!
gmail spam filter is inferior
The other issue I have with gmail is its annoying spam filter. This too is often claimed to be one of the better things with gmail, and given that they have millions of users and can do pretty detailed statistics on received mails they do have the opportunity to make a decent filter.
But, given that the spam filter is one huge you-have-no-choice-but-our-way there’s no way for me to alter configs, tweak it for my specific spams or make it better deal with the false positives that it picks. And I’ve had it catch far more false positives than my regular spamassassin filter on my main mail account and then I get probably a thousand times more mail and spam on that account.
My trusty old Sony DSC-W1 is several years old by now and it does show when I compare my camera with those of my friends – and especially when I compare the resulting images. I’m pondering on getting a new one, but I’m struggling to find one that matches my criterias:
- (Ultra-) Compact. I want to be able to bring it with me easily, in a pocket or similar. Otherwise I end up not taking any photos at all… So it shouldn’t be any bigger than my existing really. I also enjoy and mostly do point-and-shoot style photographing.
- 3″ LCD. I got one of the first 2.5″ LCD cameras and I loved how the big screen makes photographing and viewing pics on it more fun. I’ve seen some cameras with >2.5″ screens and I think they look awesome.
- Image Stabilizer. Clearly (according to reviews) they can make a difference, especially with zoom or in low light conditions.
- Good low-light images (at least comparable to the excellent Fujifilm Finepix F31fd). It seems even the more recent Fujifilms has went downhill in that department, based on reviews I’ve read.
- I think I would prefer a camera that accepts SDHC cards so that I can go with 4GB or perhaps even 8GB at once, easily and cheaply.
And what contenders are there really? Lots of them, but I’ve found none that even reaches 4 out of 5 in this list! 🙁
Oh, and note that the number of pixels ain’t terribly important as long as they’re at 6+ something megapixels.
I’m open for and interested in ideas around how we should celebrate the curl ten year anniversary around March 20 2008.
Participating in and maintaining open source projects is great fun, much rewarding and very educating. One thing you always want is bug reports from users who suffer from problems, as you cannot fix problems unless you know they exist!
Yet there are several obstacles along the way that can prevent users’ reports from reaching your project. These obstacles include:
Eager to announce a new problem, a new revealed leak or exploit, people (often) submit security- related problems directly to sites and forums dealing with security. These sites (of course) don’t forward the reports onwards, they simply assume the projects are informed as well…
People who use Linux Distributions very often feel like a user of that distro (no surprise there really!) and they therefore primarily report bugs and problems to the distro’s bug tracker. Unless the people in the distro are keen and interested enough, those reports sit there rotting away and people in the upstream project who would like to know about it are never told and thus the bug isn’t fixed…
Sometimes the bug is even fixed by the distro people and they make a newly built version available, featuring that patch, but the patch isn’t forwarded upstream either!
Related forums/mailing lists
People discussing the project in another list or forum where they are users of it. They talk about workarounds etc and sometimes even talk about “known bugs” and “existing flaws” but without ever reporting them to the originating project so they aren’t fixed. They may thus be known to the subgroup there but not upstream.
Please report upstream!
This is my cry for how this situation can be fixed: make sure that problems you know of are reported upstream to the actual project working on the project. Don’t assume that reporting it to your distro or to your neighbor is enough!
(I could easily point out examples for all these cases for projects I am involved in, but I don’t think pointing fingers will gain us anything.)
7.17.1 – the 102nd release of curl is out, with less than 5 months left to our ten year anniversary!
The previous release (7.17.0) included a few larger internal changes and unfortunately that had the backside that it brought a whole array of new bugs in, that we now have spent almost two months polishing off.
Apart from the twenty or so bug fixes, a range of new things are introduced as well, including improved NSS support, –proxy-negotiate, –post301 (to make curl act more standards compliant on HTTP 301 responses), –hostpubmd.
libcurl hackers will appreciate CURLOPT_OPENSOCKETFUNCTION and CURLOPT_COPYPOSTFIELDS (the latter a complement to the existing CURLOPT_POSTFIELDS that got broken in 7.17.0 if you posted binary data that contains a zero byte).
7.17.1 contains contributions by at least 16 different people (me not included).