Rubénerd!

After eight years of continuous development, QEMU 1.0 came out on the first of December. After assembling our Christmas tree this afternoon, I set to work building it on my Mac :).

Screenshot of my venerable MacBook Pro running Windows 2000, Windows 3.11 for Workgroups under PC DOS 2000 and FreeBSD 8.2 in the all new QEMU 1.0 :). All fully licenced I might add, I don't run pirated software thank you very much!

My build environment

• I like to build my own sources in the default /usr/local like a good FreeBSD-heritage guy, its one of the reasons I went back to MacPorts from Homebrew. Use --build-target during the ./configure stage to change the default.

• To save myself time and only install what I need, I generally only build i386 and alpha. Don't specify any and you'll build them all by default.

• I can't get enough of that authentic retro adlib sound, so I build the optional support for this too, along with the widely supported (and also optional) AC97. You can safely ignore these and it will build with default Sound Blaster 16.

• If you're attempting to build QEMU on a case-insenstive file system, you may run into an error with softfloat.h. I've since written a post about how to fix this.

Installing from source

1. Log in as root (or the closest we can get to it on OS X):
   

   % sudo -s

2. Grab and extract the latest sources, in this case the glorious 1.0! I put mine in /usr/local/src to keep things tidy.

3. Configure with the options you want, for all the available options, use the --help flag. In my case:
   

   # ./configure \
   --enable-cocoa
   --target-list=i386-softmmu,alpha-softmmu \
   --audio-drv-list=coreaudio \
   --audio-card-list=ac97,adlib,sb16 \
   --disable-vnc

4. Now build:
   

   # make
   # make install
   # make clean distclean

All done

Huge amount of thanks to Fabrice Bellard and all the QEMU committers for their incredible amount of wok over these 8 years. I use your software on a daily basis for work and play.

Now all we need is isapc support back ;).

This brings my Rubénerd Database of Anime Pizza Hut References to four, as previously blogged. I'm sure there are far more.

My working theory is the Hidan no Aria writers decided to do this to further differentiate the series from Shana to deflect criticism that it's merely a stopgap derivative. I mean, pizza isn't melonpan!

That looks like a veggie pizza too, my favourite flavour ^_^.

In November of 2006 I uploaded a post called A Closer Look At Apple’s Universal Binaries where I tried to describe what UB's are and how to use the lipo command in the Terminal to remove unnecessary code. Since then I've learned a bit more, and have found a slightly easier way to do it.

Previous post in a nutshell: If you've used Mac computers at all since 2005 you're probably aware of Universal binaries, the fancy name Apple gave to applications that have native code for PowerPC and Intel processors. While they really simplify distribution, they store code on your machine you don't actually need.

Fortunately in Tiger Apple bundled the ditto (and lipo) utility which you can use to create a thin version of a universal binary that only contains code for your processor.

TAKE NOTE! Some older applications that are only compiled for PowerPC CPUs require shared libraries or resources from other applications, some of which may have been updated as Universal. Therefore if you start deleting PowerPC code from them, you may start braking things. If you're not sure, always keep the original universal binary just in case you need to restore it!

ditto --arch i386 FooBar.app ThinFooBar.app
ditto --arch ppc FooBar.app ThinFooBar.app

The first line thins down FooBar.app to include only i386 code, the second preserves only PowerPC code.

The use of an unnecessarily long sword to spit universal binaries is not recommended... unless you're a flame haze... I'm sorry, but I can't stand dry weblog posts that don't have pictures. The thought of weblog posts without pictures keep me awake at night, as I'm sure it does for you too.

Given my current obsession with tables, below is a selection of my favourite Mac open source applications I thinned down on my MacBook Pro to compare the difference between their universal and thin binaries:

	Application	Version	Fat universal	Thin i386	% original	% saved ↓
	VLC	0.8.6c	75.2 MiB	43.1 MiB	57.31	42.69
	Camino	1.5.1int	53.7 MiB	34.2 MiB	63.69	36.31
	Inkscape	0.45.1	84.1 MiB	56.4 MiB	67.06	32.94
	iTerm	0.9.5.x	4.1 MiB	3.2 MiB	78.05	21.95
	Gimpshop	2.2.11	191.0 MiB	149.3 MiB	78.17	21.83
	Smultron	3.1	10.1 MiB	9.4 MiB	93.06	6.94

And here's a similar table looking at bundled Apple applications:

	Application	Version	Fat universal	Thin i386	% original	% saved ↓
	Safari	3.0b3	6.5 MiB	5.1 MiB	78.46	21.54
	iTunes	7.4.1	113.0 MiB	98.8 MiB	87.43	12.57
	Terminal	1.5	5.0 MiB	4.6 MiB	92.00	8.00
	TextEdit	1.4	2.2 MiB	2.1 MiB	95.45	4.55

Some pretty interesting results, the most noticeable of which I would think is that none of the applications even approached a 50% reduction in file size by removing half their compiled instructions. This is due to applications having shared resources such as images, text files and whatnot that are used by both the PPC and Intel code.

In this case, we can see that VLC, Camino and Safari had a sizable amount of specialised code, whereas the bulk of the TextEdit and Smultron applications consisted of shared resources. We can infer just by looking at these results that rendering video and webpages require more processor specific instructions compared to, say, a text editor.

Plus it gave me the chance to show some Mac icons. I use KDE on FreeBSD and NetBSD and have used all the flavours of Windows at some point, and the Mac is still the prettiest ;).