Little T in the Cog apple

Still Looking to Scratch That Nostalgic Itch (or how I still *might* buy a PowerMac)

2026-01-27

So I've spent the last week reading through various threads on the Mac Rumors Forums where people are talking about keeping the old PowerPC Macs alive, updating OS components, finding old software, writing new software - it really is quite amazing how far some people have pushed this old architecture!

All of that has made me even more nostalgic for a PowerPC Mac now - I still don't think it's actually a good idea but as has been pointed out to me I do love to scratch a geeky itch and though it serves no practical purpose I would probably get a lot of fun out of the endeavour, and it's hard to quantify that! It also helps that the prices of G5 PowerMacs are pretty reasonable right now, so even if it doesn't get a lot of use I wouldn't feel so bad about it sitting under my desk turned off a lot of the time.

So off to TradeMe and Facebook Marketplace I go! I originally wanted another 12" PowerBook but there don't seem to be any available in our small market here in NZ (though there is a really nice condition 15" 1.67GHz one here, one of the last ones and comes with a high res screen), and after reading through a bunch of the Mac Rumors threads it looks like I'll be better off with a G5 PowerMac anyway, preferably a dual or quad CPU one as the G4's are really slow these days (I mean the G5's are too, but at least they are a lot more usable than the G4's now). So the search is on for a late model G5 to sit under my desk and occasionally fire up to tinker with, I can't wait (unless I change my mind again and realise this whole thing is a bit silly 😀).


Scratching that Nostalgic Itch (or how I almost bought a PowerMac)

2026-01-21

It's been a few years now since I last used a PowerPC based Mac (after holding out until 2013 when I finally retired my then ancient PowerBook and bought an Intel MacBook Pro) but I stumbled across a post that made me all nostalgic for the PowerPC era (and OS X Leopard which I think looks much nicer than macOS Tahoe does, that's for sure!).

What I need to use a computer basically boils down to three things - a terminal of some sort, a text editor and a browser. I'd need something capable of rendering the web in 2026, and as Leopard Webkit (which I used to use back when I had my G4 PowerBook) hasn't seen an update since 2018 I looked into the other alternative from back in the day, TenFourFox, a fork of Mozilla Firefox. Unfortunately major development for that browser stopped in 2020, and though there are occasional updates you need to build it from source yourself.

A bit of Googling showed a few ports of TenFourFox as people stepped in to keep the dream alive, but they too petered out after a few years, until AquaFox picked up the mantel. This project takes the source from TenFourFox and adds some of the latest changes from FireFox ESR 128 for security, plus some other tweaks to make life a bit easier on PowerPC. The main attraction though is that you can now download browser builds once again rather than having to compile it yourself (and I think the icon looks waaaaaay better than TenFourFox ever did!).

So, there is a modern(ish) browser available, I still really like the layout of Leopard and a machine can be had relatively cheaply second hand. After scouring the second hand sites locally here in NZ I was looking at buying a dual CPU G5 PowerMac when I had to stop myself and actually think about what I was trying to achieve here - would I actually use the large, noisy, power hungry G5 beast to scratch that nostalgic itch or would it sit powered down under my desk as the reality of low res graphics, outdated software and slow performance kicked in? I don't have any real use for such a machine, other than it would look cool. Things like YouTube would only run at ridiculously low resolutions to work at all, much of the other software would be very outdated (though I've been impressed at what the hobby community have done to keep things running on these older PowerPC machines - I mean there's a ChatGPT client available!) and I'm now used to things like smooth 4K graphics, mouse gestures, modern apps and things Just Working™. When I realised that a Raspberry Pi 5 had better performance while fitting in the palm of my hand (as it should after 20 years more development!) and only consuming ~6 watts vs the 250 that a dual G5 would, I reluctantly backed away from the "buy now" button.

I'll still keep my eye out for an old G4 Mac Mini or similar (which is waaaay slower than the G5 even) to scratch that retro itch, but I think I need to park the dream that I'd actually use such a machine for anything other than turning on once in a blue moon to reminisce.


Battery Life on the M1 Ain't No Joke!

2022-09-09

So I've snagged a new laptop at work - a 16" MacBook Pro with 10 CPU cores, 16 GPU cores and 16GB RAM. This thing is a beast, way more laptop than I need for the work I do, but hey it was sitting on the shelf and as I'm part of the small IT team I figured I could "borrow" it until someone else might need it. I haven't really been using it for anything fancy, just my normal day to day job (which is mostly writing Terraform code and wrangling storage appliances in the cloud) so it's just like using my 2019 Intel MacBook for the most part, but with one major difference - battery life!

I've been working at the kitchen table for about an hour now, not a lot of apps open, but using Vim in a terminal, Safari with 5 tabs open (for work) and Firefox with 3 tabs open (for pleasure), Mail.app open and writing a few emails, and the whole time I've had YouTube open in a tab in Firefox playing music videos. After one hour of doing all this my battery said... 100%. I don't even know how that's possible, my Intel Mac used to only last about 6 hours unplugged during the day (admittedly with some Zoom meetings which I haven't had to contend with currently, but I'm not sure if that would make a huge difference or not). I had to keep watching videos (and editing etc) for 75 minutes before it finally dropped to 99%.

So yeah, even though I don't need 16 GPU cores, 10 CPU cores, all that RAM in this chunky chassis what I *do* love is that battery life - it's freakin' amazing. Can't wait to see where Apple goes with this new M series ARM platform, as if this is version 1 (or I guess the Pro series is kind of 1.5?) it's only going to get better from here!

UPDATE: So it's been two hours now and the battery is sitting at 95%, so it seems that while it takes a long time for the first percentage point to drop once it has it seems to steadily drop lower - 0% in the first hour and ~5% in the second. Still amazing to my mind.

New M1 Apple Silicon

2020-12-22

The new M1 powered Apple Macs have arrived, at least the first models, and they are genuinely amazing. All the reviews have nothing but good things to say about them - the laptops have great battery life and blazing performance and the new Mac Mini runs cool and quiet while packing more punch than any Intel based Mac (so long as you only need 16GB RAM for your workload!). Not only do native arm64 apps run crazy fast but the Rosetta 2 translation environment runs x86 apps so well that most people wouldn't even notice they're not native.

I can definitely see one of these in my future, but I'm holding off just a bit while the world catches up. Not all my environments are set up for arm64 and it will take a bit of time for everything to come across and work. I don't really need more than 16GB RAM but as the later laptops and Minis are released I'm sure they'll support more so I may just end up buying a Mac with more anyway. It has got me keen to install the aarch64 (which is just a different name for the arm64 instruction set that Apple now uses) version of Linux on one of my Raspberry Pi 4's (probably Raspberry Pi OS or Ubuntu) and have a play - I'm currently compiling packages for a few apps for armhf to run on the 32 bit version of Raspbian and it would be good to play with some 64 bit arm code.

One thing that has got me excited about the new Macs are what they will do to the overall ecosystem outside of macOS - this will probably be a big kick to the Windows ARM efforts, and once Dell and HP see sales going to other OEMs who will be making faster and longer lasting laptops they'll also jump on the bandwagon. Intel will have to adapt to survive (and don't forget they're getting squeezed from the bottom by consumer ARM chips and at the top end by beastly 80 core (soon to be 128 core!!) ARM server chips) so it will be interesting to see what they manage to come up with. They've had it too good for too long so this new Apple Silicon is just the shot in the arm the industry needs to really start innovating.

The future is bright and ARM powered!

Fix for forking when using Core Foundation in PHP on OS X

2014-12-18

For a while I've had an issue on my OwnCloud install when I open a PDF or document the browser often sits for 15 seconds before loading the file. During this time I noticed the load going up on the server and checking running processes I could see that Apache was saving a core dump, so had obviously crashed. Checking through the apache error log I could see multiple entries at the same time as the crash occurred like this:

The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.
After a bit of googling it turns out I was seeing this error due to a library being used by apache having been compiled against the Core Foundation API. Some more googling turned up the "nm" command which you can use to list the symbol table of libraries, then grep for CF to see if they use the Core Foundation API. Checking the Apache module directory (nm -go /usr/libexec/apache2/* | grep CF) turned up a few modules that use the CF API but nothing that was currently being loaded, so I turned my attention to other libraries that get used by PHP by checking all libraries passed during the --configure stage. After much searching it turns out the freetype library supplied by OS X uses the CF API and I was including this library in my PHP compilation:
$ nm -go /usr/X11/lib/libfreetype.* |grep CF
/usr/X11/lib/libfreetype.6.3.16.dylib:single module:          U _CFRelease
/usr/X11/lib/libfreetype.6.3.16.dylib:single module:          U _CFStringCreateWithCString
/usr/X11/lib/libfreetype.6.dylib:single module:          U _CFRelease
/usr/X11/lib/libfreetype.6.dylib:single module:          U _CFStringCreateWithCString
/usr/X11/lib/libfreetype.dylib:single module:          U _CFRelease
/usr/X11/lib/libfreetype.dylib:single module:          U _CFStringCreateWithCString
One solution would be to simply omit freetype from the compilation, though I'm not sure what other implications this would have on the PHP module produced. A better solution is to compile libfreetype *without* the Core Foundation APIs, and this turns out to be very simple:
curl -O http://download.savannah.gnu.org/releases/freetype/freetype-2.5.3.tar.gz
tar -zxvf freetype-2.5.3.tar.gz
cd freetype-2.5.3
./configure
make
sudo make install
Doing this installs freetype into /usr/local so we don't mess with the system included libraries. Then we simply compile PHP following this guide but replacing the configure option "--with-freetype-dir=/usr/X11R6" with '--with-freetype-dir=/usr/local". Once the module is installed there were no longer any pauses when opening PDFs and I've yet to see that error again in the Apache error logs!


Fix for Shell Shock on OS X 10.5 Leopard

2014-09-26

The Shell Shock bash vulnerability that has been doing the rounds lately will never be patched on OS X Leopard as it is simply too old. Luckily Matt White has posted a fix for Debian Lenny and as Leopard and Lenny use the same version of Bash (3.2) the same fix can be applied. I've tweaked his update script for Os X (as by default there is no "wget" or "seq" (sequence) so simply download it from here, mark it executable (chmod +x) and run it to upgrade the version installed to 3.2.54 which includes the needed patch. Your old version will be saved as /bin/bash.broken and the new version will be installed into /usr/local/bin/bash and a symlink created from /bin/bash to it Updated: The script now simply overwrites the old version as having it hanging around could be considered dangerous. If you want to keep a copy then you'll need to manually copy it somewhere safe (eg /var/root/). The script also now removes /bin/sh and creates a symlink to /bin/bash. Once installed simply log out and back in again and you'll be using the new version, and any CGI-BIN scripts you use will also be safe (well, at least from that bug!).

Happy patching and let's hope that it is a long time before a vulnerability like that crops up again.

UPDATE: A few people have asked if they can have a copy of the binary as they don't have the build tools installed. The latest version can be downloaded from here (PPC ONLY! I don't have an Intel install of 10.5 sorry), once downloaded you'll need to mark it executable and copy it to /bin/bash

UPDATE 2: I've just had pointed out to me that /bin/sh on Leopard is actually a copy of /bin/bash, not a symlink so calling /bin/sh will still leave your system vulnerable. To get around this either copy /bin/bash to /bin/sh or better yet symlink /bin/bash to /bin/sh so updates to bash will also result in /bin/sh being updated. Finally, I've changed the script to simply replace /bin/bash rather than install into /usr/local/bin/bash and symlink.

UPDATE 3: And another patch is out - binary has been updated and is available here or for those with the build tools installed you can compile from source using this script. Hopefully this is the last for a while as it addresses all currently outstanding CVEs.


Updated Xserve G5 document

2014-09-26

Since the release of the Shell Shock bug for Bash I thought I'd compile all the fixes I've done for OS X into my updating OS X Leopard for the modern world document as I'm now running a newer version of OpenSSL, PHP, ClamAV etc. The old doc (using php 5.3) can be found here though as PHP 5.3 has been discontinued you should no longer refer to that document.


Upgrade ClamAV on OS X 10.5 Leopard Server

2013-09-11

As part of the modernising of my Leopard install I thought I'd upgrade to the latest ClamAV (the antivirus software that comes with Leopard Server). This isn't strictly necessary as the updates will still work with older versions of ClamAV but it is still good to have the latest version running. Thankfully this is a really easy upgrade and still works perfectly with Server Admin (so will start when starting email etc).

Firstly stop email while you install the new version (stopping email isn't strictly needed but it's a good way of unloading the running ClamAV) then grab the latest ClamAV stable release from clamav.net (0.97.8 at the time of writing) and unpack it somewhere. Thanks to the "clamconf" tool that comes with ClamAV I was able to see the configure options used by Apple to build the software, so we simply run this to set it up for our system, then make, then make install:

$ tar -zxvf clamav-0.97.8.tar.gz
$ cd clamav-0.97.8
$ ./configure '--prefix=/' \
	'--exec-prefix=/usr' \
	'--bindir=/usr/bin' \
	'--sbindir=/usr/sbin' \
	'--libexecdir=/usr/libexec' \
	'--datadir=/usr/share/clamav' \
	'--sysconfdir=/private/etc' \
	'--sharedstatedir=/private/var/clamav/share' \
	'--localstatedir=/private/var/clamav/state' \
	'--disable-dependency-tracking' \
	'--libdir=/usr/lib/clamav' \
	'--includedir=/usr/share/clamav/include' \
	'--oldincludedir=/usr/share/clamav/include' \
	'--infodir=/usr/share/clamav/info' \
	'--mandir=/usr/share/man' \
	'--with-dbdir=/private/var/clamav' \
	'--disable-shared' \
	'--with-user=_clamav' \
	'--with-group=_clamav' \
	'--with-gnu-ld' \
	'--enable-static' \
	'--enable-ltdl-convenience'
$ make
$ sudo make install
That's it! You should now have the latest ClamAV installed. To start using it simply start email, or load it from the shell:
$ sudo launchctl load /System/Library/LaunchDaemons/org.clamav.clamd.plist
$ sudo launchctl load -w /System/Library/LaunchDaemons/org.clamav.freshclam.plist
Check the freshclam log (/var/log/freshclam.log) and you should see the new version being loaded.


PHP 5.4 on OS X 10.5 Leopard Server

2013-07-26

So after finally getting PHP 5.3 compiled and installed it looks like it's being end-of-lifed:

"Please Note: This will be the last regular release of the PHP 5.3 series. All users of PHP are encouraged to upgrade to PHP 5.4 or PHP 5.5. The PHP 5.3 series will receive only security fixes for the next year."

Rather than wait for support to end I thought I'd move to the next version, 5.4. Compiling PHP 5.4 on Leopard Server isn't too much harder than 5.3 but it does seem to trip up over OpenSSL versions - 5.4 needs OpenSSL version 0.9.6 or higher and Leopard ships with version 0.9.71 so it should be fine but I found that while it passed the "./configure" stage it failed when linking, giving errors right at the end of the "make" stage:

Undefined symbols:
  "_EVP_sha224", referenced from:
      _php_openssl_get_evp_md_from_algo in openssl.o
  "_EVP_sha256", referenced from:
      _php_openssl_get_evp_md_from_algo in openssl.o
  "_EVP_sha384", referenced from:
      _php_openssl_get_evp_md_from_algo in openssl.o
  "_EVP_sha512", referenced from:
      _php_openssl_get_evp_md_from_algo in openssl.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [libs/libphp5.bundle] Error 1
It seems to be because though the version of OpenSSL included is higher than needed it gets a bit confused by the version number (0.9.71 rather than 0.9.7.1 I guess?). The fix is to edit /ext/openssl/openssl.c (from the root of the php 5.4 tarball) and change the three instances of
#if OPENSSL_VERSION_NUMBER >= 0x0090708fL
with
#if OPENSSL_VERSION_NUMBER >= 0x0090808fL
The 0x0090808fL isn't super important, it can be any value as long as it's above 0x00908. This disables some features (such as certain SSL algorithms) that OpenSSL 0.9.71 doesn't support. Once that file is changed you can kick off "make" again and it should complete without errors (following the guide for 5.3 here for configure options and support libraries - note that you no longer need the "-lstdc++" fix for ICU). If you're going to use APC (which you really should!) you need to run at least version 3.1.13 to work with PHP 5.4, the same configure options as used for version 3.1.9 can be used.

UPDATE: Just realised that the version of OpenSSL shipping with Leopard is 0.9.7l (with a small "L", not a number "1") so no idea why you need to hack the source file to get it to compile.


How to get some life out of an Xserve G5

2013-07-16

I've written a Howto on installing and patching OS X server on an Xserve G5. I'll probably keep adding to the Howto over time as I discover new things that need updating. If you're using a newer Intel Xserve then this howto will still work of course if you're running an older version of OS X Server, but to be honest seeing as Server is so cheap in the app store you're probably better off simply updating if you can :-)

Anyway I hope you find it useful - let me know if anything doesn't work for you!