I’m kind of surprised at this veneration – the concept is nothing new, as there’s already as similar calculator built into Mac OS X and other Unix operating systems, called bc, which is pretty much identical in functionality, with a few quirks.

The first time you load bc up and use it, you’ll probably find that it’s defaults aren’t the best – for example, when dividing a number, you get only the quotient back (the part in front of the decimal place), which isn’t too useful in most cases.

10/3
3

If you set the “scale” variable it will return a proper float with that number of digits:

scale=5
10/3
3.33333

Also, the gnu version of bc prints a gnu advertisement at the front of every session:

$ bc
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.

The fix for this is as follows – bc (at least the common gnu version) will take a set of arguments from an environmental variable (set in your .profile or similar shell init script) like so:

BC_ENV_ARGS='-q /Users/username/.bc'

The -q suppresses the advert, and the path to my .bc file is a set of commands that is executed before every session. Note that it needs a full path supplied – you can’t use ~ to specify your home folder, as bc doesn’t perform shell expansion on it’s arguments passed in this way. My .bc file is simple – it just sets the scale variable:

scale=5

You could also predefine functions and variables as well in there if you cared to.

# dd if=dban-1.0.7_i386.ima of=/dev/disk3
2880+0 records in
2880+0 records out
1474560 bytes transferred in 192.277221 secs (7669 bytes/sec)

That’s over 3 minutes, using a USB floppy drive connected my MacBook Pro.

(I needed a copy of DBAN on floppy so I could erase an ancient 60Mhz Pentium)

If you’re compiling code on Mac OS X 10.5 Leopard from source with standard Unix tools like make, your resulting binary will usually be compiled only for the architecture you’re currently running on. For example, when I first compiled a copy of pwgen for making sets of random passwords, the binary I got was i386 only:

$ file pwgen
pwgen: Mach-O executable i386

But, if you modify the Makefile to include the 4 architectures that Mac OS X (currently) supports:

CFLAGS = -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64
LDFLAGS =  -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64

GCC will be run with those options when compiling the code and creating the final binary, and you’ll get a “fat” binary that supports all the processor architectures:

$ file pwgen
pwgen: Mach-O universal binary with 4 architectures
pwgen (for architecture ppc7400):	Mach-O executable ppc
pwgen (for architecture ppc64):	Mach-O 64-bit executable ppc64
pwgen (for architecture i386):	Mach-O executable i386
pwgen (for architecture x86_64):	Mach-O 64-bit executable x86_64

Note that doing compiling anything on OS X will require that you install the Developer Tools, which you can download from the Apple Developer Connection.

Obviously that’s not correct, as the bluetooth card is built in, and should always be connected.

At first I though I just had a bad bluetooth card, but then I started having issues reading CDs and DVD’s in the optical drive and the lightbulb went on in my head.

Both these components are electrically connected via a mezzanine board inside the Mac Mini. There are some good pictures of this here at AppleFritter.com. Basically, to put memory into a Mini, you have to disconnect and lift off the subframe which contains the optical, hard disk, bluetooth, and a ribbon cable to the audio connectors, all of which connect via the mezzanine board.

To fix, I just popped open the Mini again, lifted the subframe and mezzanine board out then and plugged it back in, and everything was back to normal. It must have worked it’s way loose when I installed it, or due to thermal expansion/contraction after using it for the last year.

Moral of the story? If your Mini is acting weird, try reseating the internal components.

The date format as it comes from the bank looks like this:

20081009120000[0:GMT]

From a datestamp perspective, it’s pretty useful – gives the whole date and time, plus the timezone. In my bank’s case, the time and timezone is always noon and GMT, so I’d much rather have just the date.

Assuming that the above value is in cell B1, this formula will extract a date in the considerably more useful YYYY-MM-DD format:

= LEFT(B1,4) & "-" & RIGHT(LEFT(B1,6),2) & "-" & RIGHT(LEFT(B1,8),2)

This formula prints 2008-10-09 for the above date string. If you want to get rid of the original date column, copy the new column of dates, then do a “Paste Special…” selecting “Values”, and it will no longer be dependent on the original date column.

Why would you want to do this, when Xen can offer better performance than VMware? Portability – I can run a VMware virtual machine on Mac under VMware Fusion, on Windows under VMware Server, Workstation, or Player.

In my office, I’ve got a Dell Poweredge 830 with 8GB RAM, but my desktop computer is a Mac Mini which maxes out at 2GB RAM. It’s a no brainer to use the Dell for setting up the VM’s and then moving them to other machines when the time comes.

If your CentOS 5 box is running the xen kernel and try to install VMware Server 2.0 (currently in beta), you’ll get the following error when trying to install the RPM:

 You cannot install VMware Server on a system running a xen kernel

As a result, you need to switch to a non-xen kernel.

To do this, you first need to install the kernel. yum makes this easy:

yum install kernel

Then remove xen and the kernel-xen packages:

yum remove xen kernel-xen

Then you have to specify which kernel you want to run in /boot/grub/grub.conf. In that file there’s a list of kernels available to boot from:

#boot=/dev/sda
default=1
timeout=5
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-92.1.10.el5)
        root (hd0,0)
        kernel /boot/vmlinuz-2.6.18-92.1.10.el5 ro root=LABEL=/1 rhgb quiet
        initrd /boot/initrd-2.6.18-92.1.10.el5.img
title CentOS (2.6.18-92.1.10.el5xen)
        root (hd0,0)
        kernel /boot/xen.gz-2.6.18-92.1.10.el5
        module /boot/vmlinuz-2.6.18-92.1.10.el5xen ro root=LABEL=/1 rhgb quiet
        module /boot/initrd-2.6.18-92.1.10.el5xen.img

The line that says default= specifies which kernel to load, where 0 is the first one listed in the file. In my case, I had to change the line that says default=1 to default=0 to specify the non-xen kernel.

Reboot, and you’re good to go – the VMware RPM will install, and VMware server runs just fine.

First, you need to find your blog’s feed URL – it’s probably a link labeled something like “RSS” or “Atom” or “Feed” in the sidebar or at the bottom of each blog page. You’ll want the one that has just your posts – some blogging entries will have multiple feeds – for example, one that is just comments other people have made. Copy this URL – you’ll need it later.

Next, log into Facebook, and in the left hand navigation click on where it says “Notes” – you may have to click the “more” link to get it to show up:

Once your notes have loaded, in the right column where it says “Notes Settings”, click “Import a Blog >>”:

In the next screen, paste the feed URL into where it says “Web URL:”, click the checkbox (after reading the copyright warning of course) and then press “Start Importing”:

In a little bit, all the blog posts in your RSS feed should show up as Facebook Notes, with a link back to your blog. When you make a new post, it will be automatically added as soon as Facebook scrapes your RSS feed.

When you start upgrading multiple blogs, you’ll soon realize that the standard process of updating Wordpress is time consuming, and requires a lot of manual intervention, so here’s a way to automate it using two standard unix tools, diff and patch.
diff finds all the differences between two files and folders, whereas patch takes the output of diff and makes the changes described in the patch file to the files and folders it is run on.

This example goes from Wordpress 2.2 to Wordpress 2.2.1, but should work for any combination of releases. This won’t update any of your themes and plugins, and you should definitely make a backup before doing it – don’t blame me if you completely screw up your installation!

Step 1

Obtain copies of both versions of Wordpress you’re going to be using from the Release Archive, and decompress them into two folders (we’ll call these wordpress22 and wordpress221, in this example)

Step 2

Run diff on the directories to generate a patch file.

diff -Naur -x .DS_Store wordpress22 wordpress221 > wp22_221.patch

(The -x .DS_Store argument is only needed on the Mac, which stores directory information in that file. The other options make the diff unified, recurse through the directories, make it ascii, etc. – read the diff’s man page for more information)

Step 3

Apply the patch you created in step 2 using patch. cd into the directory, and run the patch command:

patch -p 1 < /path/to/wp22_221.patch

You will get a lot of output like this:

...
patching file wp-admin/edit-form-advanced.php
patching file wp-admin/edit-form-comment.php
patching file wp-admin/edit-form.php
patching file wp-admin/edit-page-form.php
patching file wp-admin/export.php
patching file wp-admin/install.php
patching file wp-admin/user-edit.php
patching file wp-admin/users.php
patching file wp-admin/widgets.css
patching file wp-admin/widgets.php
...

If there any errors, you'll see them during the patch process.

At this point, you're done. You can use the patch file you created on any Wordpress weblog that you want to bring from version 2.2 to 2.2.1, but it won't work for other versions.