My new camera hasn’t yet arrived (Update: it just arrived!), and I’m already thinking about my next camera. I guess that’s what I get for choosing super saver shipping and it actually taking up to 9 days. Idle hands makes my mind wonder.
Why? Well, there was a paragraph in A camera is only a tool that I never got around to writing once I’d finally decided on the Canon A570 IS. In my head, it went something like this:
Other than weight, the number one bummer of the current crop of affordable digital SLRs is their field of view crop factor. Because their APS-C-sized sensor is smaller than a standard 35mm negative, the corresponding view through the lens gets cropped. This has a number of disadvantages, for one it makes every lens less “wide” (or more “telephoto”)—and in doing so, it wastes weight and glass. It’s also a bit of a challenge to match up a decent prime lens with the desired field of view and aperture, given the crop factor, without having to sell the farm.
The obvious solution? Get a digital SLR with a full frame, “35mm” sensor. Apparently making a flawless 24×36mm hunk of CCD/CMOS is neither easy nor cheap. And so the most portable and affordable SLR with a full frame sensor, the Canon 5D, costs a sweet two grand. This is A Lot Of Money™. The body alone weighs 895g. Hence, the big dog.
But at least with a full frame sensor, I can buy a 50mm f1.4 normal lens and not have it transformed into a semi-telephoto 80mm on the Digital Rebel. Same goes for the 28mm f1.8, a nice wide-angle perspective that would be transformed into a non-wide 45mm field of view.
I dunno, I think I’m finally coming around to Jonathan’s advice: different cameras for different situations. The A570 IS when portability is key or when I’m worried about possible camera causalities, and something like the Canon 5D (or its love-child with the new 40D) in safer scenarios and indoors.
Now I just need to find my photographic benefactor.
I’ve been a little disappointed with Gutsy Gibbon, the latest release of Ubuntu. I’m not sure if it’s the older hardware I’m running, but things seem a little flakier. For starters, the upgrade process locked up about 1/3 of the way through. And this time I wasn’t working on the computer at the same time.
When I rebooted, I got to the Gnome login screen and logged in, but it didn’t go any further than that. I was able to set things so I could log in to a terminal instead, and I continued the installation using dpkg --configure -a (I think). That seems to have completed the process, but now I’ve got several lingering problems that I didn’t have with Feisty.
First, my ThinkPad X23 doesn’t resume out of suspend anymore. The fans and hard drive start spinning, the LCD backlights flash on and then off, but the “moon” light just blinks and blinks and blinks. I tend to use suspend regularly whenever I shut the screen, so this is totally cramping my style. Googling around reveals that I’m not alone (and that it might be a problem with the kernel—I’m running 2.6.22-14-generic), but the suggested fixes I tried had no effect.
Occasionally when I login, I can’t click on anything. I can move the mouse cursor, but I can’t do anything with it. I’m not sure if this is because I’m clicking on the Firefox icon in the top panel too quickly or not, but pretty much all I can do when this happens is Ctrl+Alt+Bksp and re-login. This has occurred 3-4 times.
Selecting justified text in Firefox (e.g. in my blog) makes the text wiggle back and forth by a pixel or two. WTF? I’m wondering if these issues are all Gnome 2.20 related? Here’s a screencast I took to illustrate what I’m talking about:
Finally the Live Comment Preview plugin I use for displaying comments as they’re typed delays the appearance of the characters I’m typing so drastically that composing that way is not usable.
The GNU Core Utilities are the basic file, shell and text manipulation utilities of the GNU operating system. These are the core utilities which are expected to exist on every operating system.
This post is an elaboration on a feature request I recently sent to the GNU Coreutils mailing list.
I’ve been playing with backups a bit lately, and my favorite command line tool in that effort (other than rsync of course) has been du—usually known for its annoying recursive and verbose output—but which I just learned to tame with the --max-depth=1 option, e.g.
Perfect! Helps me quickly home in on which directories to trim, and which aren’t worth the bother. The -h “print[s] sizes in human readable format (e.g., 1K 234M 2G)” but as the list of directories gets longer, it gets harder to differentiate the 153Ms from the 652Ks.
If I don’t use -h, I can pipe the du output through sort -n, but human-readable sizes are so nice. So I proposed to the coreutils group that sort be extended with an option for sorting by human-readable disk size values. Using the example above, the hypothetical usage and output would look like this:
