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).
Well, not really but at least the recent “jailbreak” for it opens up the possibility…
The jailbreak seems to open up the ability to run apps on the target that are built for it, so I figure it can then theoretically be used to run whatever, and that’s why I say it is an opening for an eager and dedicated person to get Rockbox going on it.
I amuse myself by occasionally reading up on articles and posts “out there” that talk about curl and libcurl, and I often find interesting snippets and data well worth reading. Here’s a few of the ones I’ve stumbled upon recently:
- Tony G wrote a post to a u2 database mailing list and did an indirect praise of curl.
- magnetk.com writes about how to build a recent libcurl with visual studio 2005
Lots of press and people focus on Linux distributions when they check out what happens in Linux land. This and that distro come in new releases and they offer this and that brand new feature. This is also true of the many linux podcasts. They give credit to distros for new things that pop up.
Mostly everyone of us involved in open source projects have a different view on all that:
Distros package the developments that are done elsewhere by other people. Sure they contribute with glue code and they do put pieces together in useful ways but really, most of the real grunt work – the actual sweating, is done by ordinary open source teams working independently of distros (but sure, sometimes people related to or even employed by distros contribute in such projects).
This is also part of the explanation to why most distros are at about the same level of development, why no distro outcompetes the others at one go. When X11 brings a fancy new feature, all distros have it. When compiz can rotate the screen in yet another way, all distros ship that…
Of course the other part of the explanation is that most distros release their own work as open source, free for the other distros to absorb.
In fact, many times the distros actually hinder the work of the open source projects since they add a filter to bug reports, they patch in their own dirty solutions in their distro rather than to work with the projects to do the fix the best possible way and similar.
Distros are exactly what they’re called: distributions – they distribute bundled collections of software, the vast majority of that software is not made by the distro.