I’m back, and with a mammoth episode for good measure: a whopping 57 minutes that will guide you through the intricacies and nuances of how everything man-made gets old, and how we can learn to avoid the frustration caused by being unable to update a phone we bought just a few years before.

I focus mostly on technological devices, but I also compare them with cars, fridges, and even a Boeing 787 aircraft just because I love planes and I actively look for any random excuse to talk about them.

Don’t forget to “like” the new Facebook page for Avian Bone Syndrome!

Links of interest mentioned in the episode:

• Moore’s Law
• The timeline of Microsoft Windows releases
• The timeline of Apple Mac OS X releases
• The specifications of the 2006 iMac
• How plane crashes are getting weirder, and why
• The Phoebus Cartel

So, you’ve got the shiny new iOS 4.2 on your iPhone 4 and you have enabled AirPrint sharing on your Mac, using either the free Hacktivator or one of the commercial packages. You are very satisfied (albeit a bit doubtful about actually using it in the future), except for one thing: it prints in color, and you really wish it could print in grayscale, because toner is not cheap.

When printing on the Mac this is easy: in any application’s print dialog, you change the specific settings of your printer to convert to grayscale and save a new preset. Then you just select “use last selected preset” and you forget about it, limiting yourself to changing it to color whenever you feel like wasting money (or printing money, if you’re that kind of naughty boy.)

AirPrint, on the other hand, just doesn’t have any setting, aside from the number of copies. You can’t even choose which pages to print. It’s either all or nothing. And it prints in color. It all seems lost, but fear not! OS X’s print subsystem is based on — or rather, it actually is — CUPS, which stands for Common Unix Printing System. Therefore all you need to is fiddling with it to change the actual default settings. How do you do that? It’s very, very simple.

Go to http://localhost:631/ (the CUPS configuration runs via a pseudo-webserver on port 631; don’t worry, this only works on your own machine for your own machine), and click on Administration on top, then click on Manage Printers. Click on the name of the printer in question, and in the Administration pull-down menu choose Set Default Options. What you see now depends on the actual printer you have, but it should very closely resemble the options you get in the OS X print dialog. In my case, the General tab shows a setting called  Color Mode that lets me choose between Color and Grayscale. I set it to the latter, clicked the Set Default Options button, typed in my username and password, and off I went.

Note that you must have administrator rights, and you have use your short username, the one in lowercase with no spaces. It’s the same one that gives the name to your own home folder.

(Many thanks to Marco F. for the input.)

Keep in mind that this is for my own printer, and that I use OS X 10.6 “Snow Leopard.” Results may vary with different printers and/or operating systems, so make your own tests. If your printer outputs pages “face down,” this will probably work as it is. Most ink-jet printers on the other hand output prints “face up,” so some adjustments will be necessary.

In any case the steps for my own printer are very, very easy (once you’ve figured them out correctly):

1. Print all odd pages in normal order
2. If the total number of pages is an odd number, take the last sheet and put it away for the time being
3. Take the (remaining) sheets and put them back into the tray after rotating them 180°. Do not flip them in any way!
4. Print all even pages in reverse order
5. If you put the last sheet away in step 2, put it back at the end of the stack
6. There is no step 6

Enjoy.

The current version of OS X, 10.6, is called Snow Leopard, while 10.5 was Leopard. Biologically, they are indeed different animals, but Apple’s goal was to make it clear that 10.6 was visually not too different from its immediate predecessor, and that many of the improvements happened under the hood.

As is common in the world of Apple-related rumors, much speculation about the code name of the still-unannounced 10.7 release. It seems that Apple is running out of big cats:

• 10.0 — Cheetah
• 10.1 — Puma
• 10.2 — Jaguar
• 10.3 — Panther
• 10.4 — Tiger
• 10.5 — Leopard
• 10.6 — Snow Leopard

So will we have Lion, or maybe Lynx? Certainly not Ocelot, since it’s not a big/wild cat.

Is Apple saving the name “Clouded Leopard” for a subsequent release that will be focused on, well, cloud computing? That would be neat indeed.

Cougar, of course, would seem out of place, given its sexual implications in American English. But keep in mind that we’re talking about a company who actually named a product iPad, which kind of proves that don’t have any women in their marketing department. Not that iPod makes much sense either, but come on, iPad?

Yet… think about it: OS X is quite a mature operating system at this point, and it will certainly love new machines. So bring it on, OS X 10.7 Cougar!

I scouted my iPhoto Libraries for pictures, and simply dragged them into a folder I had created. I quickly stumbled across two problems:

1. The Finder almost immediately reported that the drive was full, even when it still had over 350 MB available, or that one or more files couldn’t “be read or written”;
2. 8-megapixel images are just too big for a Full HD screen, so you end up wasting a lot of space and possibly slowing down the TV.

Did I fix them? You bet I did. Read on to find how.

The first problem was the trickiest to solve. After trying to copy it directly using cp in a shell, and getting the same error, I decided to try copying the files without their resource forks. To do that, use the -X flag on cp. It magically worked, even though I’m not sure what the problem was, but using cp -X gives you the clean, data fork only images, and everything is merry again.

The second problem is more of an hassle, but going from 182 MiB to 63 MB (for 167 images) is certainly nice. After all, the output screen only has a resolution of 1920 x 1080 pixels, and it’s absolutely pointless to use it to display images sized up to 3456 x 2304 pixels.

So, how do you resize them in a pinch? Enter ImageMagick, an open-source image conversion suite. If you are on a Mac and you have MacPorts installed, you can simply run sudo port install ImageMagick and let it do all the work for you.

For the sake of the example, let’s suppose that the images are in a directory called stuff, and that they have the most random names; some of them have names ending in .JPG (capitalized), some of them end in .jpg (not capitalized). Isn’t that a nightmare? Not really.

Please note that this example implies that you use bash on any a Unix-like system. ImageMagick is available for many platform, including Windows, but you will need to find another way to run it on each file you need to resize. I personally use OS X.

Here is the sequence of steps we need to take to convert everything to HDTV size:
octavarium:~/stuff jollino$ mkdir _
octavarium:~/stuff jollino$ for f in *[Jj][Pp][Gg]; do convert $f -resize "1920x1080>" _/$f; echo Image $f converted successfully; done
Image 1b371a9f-a59c-4c5e-b9f2-9a8aa24c807e.original.jpg converted successfully
Image 2fb7c7da-999d-4744-b8e8-dffa5d466736.original.jpg converted successfully
Image 3a39767c-b830-4fb8-90ce-40d97e793c65.original.jpg converted successfully
[...]
Image IMG_0737.JPG converted successfully
Image IMG_0742.jpg converted successfully
Image IMG_0745.JPG converted successfully
Image IMG_0746.jpg converted successfully
Image IMG_0750.JPG converted successfully
[...]

The first command obviously creates a directory called _. You can name it any way you want, but I personally prefer very short names when dealing with batch processes, especially when there is little risk of confusion.

The second command is where the magic – no pun intended – happens. It can be read as folows:

1. Iterate over each file in the current directory whose name ends in any case combination of ‘jpg’;
2. In each cycle, call the name $f
3. Run the command: convert $f resize "1920x1080>" _/$f
4. Run the command: echo Image $f converted successfully
5. Repeat for the next file

As can be easily inferred, the actual conversion takes place in step #3. If the file name is IMG_1891.jpg, for instance, the command is expanded as convert IMG_1891.jpg resize "1920x1080>" _/IMG_1891.jpg.

The > character in the output image size is not a mistake: it tells convert that we want it to be 1920 pixels wide and 1080 pixels high… but the aspect ratio is our main priority.
This means that images will not be smared to fill the 1920 x 1080 canvas; the output images will be at most 1920 pixels wide or 1080 pixels high, whichever can be optimized, and the other dimension will be changed accordingly. Okay, now that’s confusing. Let’s look at a few examples.

• A 2816 x 2112 image (4:3 horizontal) will be resized to 1440 x 1080. If it had been resized to 1920 x 1440, it would have had to be cropped to fit on a 1920 x 1080 screen.
• A 2112 x 2816 image (4:3 vertical) will be resized to 810 x 1080. That sure beats a 1920 x 2560 image (which would end up bigger than the original anyway!)
• A 3456 x 2304 image (3:2 horizontal) will be resized to 1620 x 1080.
• A 3456 x 1944 image (16:9 horizontal) will be resized to 1920 x 1080.
• A 1048 x 699 image (3:2 horizontal) will not be resized and will stay at 1048 x 699.
• A 2148 x 2148 image (1:1 square) will be resized to 1080 x 1080.

As you can see, most images will have a shorter horizontal side in order to accommodate for a as-tall-as-possible vertical side, as that is still shorter.

After doing all of this, make sure that the USB drive has a MBR rather than a GUID partition table and a FAT partition, and simply run:

octavarium:~/stuff jollino$ cp -Xv _/* /Volumes/nameofyourdrive/

Gracefully eject the drive, remove it, and enjoy your pictures!

Installing the module alone doesn’t work, because MAMP installs no headers; and copying the headers from the vanilla MySQL distribution doesn’t help either, because a few of the required files are generated on the fly during the installation of MySQL itself.

The solution, it turns out, is relatively simple. Follow along.

Step 1: download the latest MySQL Community Server in DMG format for x86-64 from this page, and install the main package. Worry not: nothing is going to be started on boot, so this is not going to mess with your pre-existing MySQL installation. The package is going to be installed in /usr/local/mysql-5.1.45-osx10.6-x86_64/, with a handy /usr/local/mysql/ symbolic link.

Step 2: download the latest MySQLdb Python module from this page, and unpack it somewhere.

Step 3: set the $PATH environment variable to include /usr/local/mysql. That’s because the module’s setup.py is going to need to call mysql_config, and you want it to find the one you just installed, as it comes with all the stuff it needs.

Step 4: do the classic build and install dance, making sure you prepend the commands with ARCHFLAGS=’-arch x86_64′. This is because you want to compile a 64-bit module.

In short:
tar vxfz MySQL-python-1.2.3c1.tar.gz
cd MySQL-python-1.2.3c1
export PATH=/usr/local/mysql:$PATH
ARCHFLAGS='-arch x86_64' python setup.py build
ARCHFLAGS='-arch x86_64' python setup.py install

If all went fine, you should be able to do this without getting any errors:
octavarium:~ jollino$ python
Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import MySQLdb
>>> print MySQLdb
<module 'MySQLdb' from '/Library/Python/2.6/site-packages/MySQL_python-1.2.3c1-py2.6-macosx-10.6-universal.egg/MySQLdb/__init__.pyc'>

Enjoy!