Playing with Haiku

10 March 2009

A good many years ago, I played around with BeOS R5 Personal Edition, which was a fun and different little operating system from the late ’90s and early ’00s. I first encountered this operating system when it was bundled on a free CD that came with an issue of the PC PowerPlay magazine.

BeOS R5 Personal Edition was fun to play with, but rather limited, owing to the fact that it installed itself into a 512MB loop partition, of which the size couldn’t be adjusted. Also, unfortunately, the hardware on which I ran it wasn’t supported very well (in particular, I had no networking), so I stopped using it after a while.

A couple of years ago, I heard about the Haiku project, which is an open source clone of BeOS that aims to be binary compatible with its applications. Back then, it was quite unstable, had absymal hardware support, and didn’t run very well under virtualisation.

Well, that’s all changed. Though Haiku hasn’t reached 1.0 yet, its daily builds are very impressive. I have been testing Haiku during the last couple of days, doing my usual hacking, and it has not crashed once. Seriously — my Haiku system has not crashed yet. The same could not be said of it two years ago, or even one year ago.

Apparently BeOS (and thus Haiku) uses a microkernel architecture, which is quite cool. They also appear to be the starters (PDF) of the *Kit fad.

Even my Hackintosh system gets unstable after about 18 hours of use (I suspect memory corruption from the video driver), and my Gentoo system will regularly refuse to launch applications (I suspect something is blocking in klauncher) or shut down (udev likes to hang). Haiku has now met the bar in terms of stability, in my opinion.

Haiku supports 2D acceleration on my GeForce 7600GT (also tested on a GeForce 8600, which does not support acceleration yet), and supports my nForce network adapter (it currently uses a driver ported from FreeBSD, although there is also a previous port of forcedeth) brilliantly. One bug forces me to jump through a hoop to get DVI video working, however. The video resolution (GMA950, 1024×600) and Atheros network of my Eee 901 were also supported out-of-the-box, although Haiku has no wireless LAN support yet.

Getting up and running is child’s play. Haiku is distributed in raw HDD images and VMware images. The raw images can be dd‘ed straight to a USB flash drive or hard drive partition and booted, or run in QEMU.

Yep, booting Haiku off a flash drive is as easy as dd‘ing the image onto the drive. (Haiku only supports USB 2.0, not 1.1 at this present time, but I doubt there are many computers with USB 1.1 around that can boot off USB.)

Haiku natively supports SMP (Symmetric Multi Processing), which BeOS also had way back as long ago as 1995. (The BeBox sold between 1995 and 1996 shipped with dual PowerPC processors.)

I’m not sure if it’s just a gimmick, but you can turn off one or more of your processors using the ProcessController applet. If you try and turn off all your processors, however, you are chided:

"This is the last active processor...you can't turn it off!" (Button is captioned "That's no fun!")

That’s an improvement over the original BeOS, where if you turned off all your processors, the system would instantly lock!

Haiku ships with Firefox 2.0 and VLC 0.8.6c, and is fairly POSIX-compliant. Most stock-standard Unix apps should compile fine on Haiku. Haiku is currently shipped as being compiled with GCC 2.95.3, but GCC 4.1.2 and 4.4.3 versions can be compiled from source.

Standard UI font family is good old DejaVu, which I have grown to know and love, and uses FreeType for rendering and hinting. (Binary distributions are shipped without subpixel font rendering, for fear of patent infringement, but support can be compiled in manually.)

The one area which I have had no success in yet is audio. When running under VirtualBox or QEMU, I can emulate an AC’97 audio card. I can play music files, but the resulting audio are garbled and barely recognisable. On my physical systems (Intel HDA), the sound card is not detected at all. Update: If you compile OSS 4.1rc4, audio then works.

Still, it is very fun to play with. Oh, one tip for those of you trying out Haiku: hold down Shift as you drag on the title bar of an application.

Tagged: , , | 1 Comment »

How to get X.Org working on an Apple eMac (ATI Radeon 7500)

20 February 2009

About 8 or so months ago, I bought an Apple eMac, which came with a DVD drive, 1GHz PowerPC processor, 1GB of RAM, and an ATI Radeon 7500 video card.

One of the first things I did was attempt to install Linux on it. Ubuntu 8.04 was my first try, and I was annoyed to find that I couldn’t get a picture with Xorg on it — just a blank screen. I also tried Debian Etch, Debian Sid, and Fedora 8, which also had the exact same symptoms.

The only Linux distro that worked was openSUSE 11, but I couldn’t stand openSUSE because it was slow, YaST was painful to use, I hated RPM, and they customised GNOME way too much.

Initially, I thought it was a refresh rate problem. I have gathered that the optimum screen mode for the eMac is 1024×768 @ 89Hz. Because Ubuntu was trying to set the mode to 1280×800 @ 60Hz by default, I added a modeline for the proper mode. However, that didn’t fix my blank screen, and I almost gave up in despair.

I also ran xrandr under a tty, and it was interesting to see that it thought my Mac had DVI hardware — DVI-0 and DVI-1. The eMac most definitely does not support DVI, so this told me the issue was a little more advanced than refresh rates.

On Saturday, while talking to the friendly folks on #gentoo-powerpc, one of them pointed me to this page (Update: the link is an equivalent page, as the original link is now gone), which contained some ConnectorTable hacks. As it turned out, the hacks worked! Both internal and external VGA worked (internal VGA was called VGA-1, and external VGA was called VGA-0), which makes me really happy.

So, to get X.Org working on your eMac, make the following changes to xorg.conf.

First you need to define the Modeline for the video mode:

Section "Monitor"
  Identifier   "Configured Monitor"
  # 1024x768 @ 89.00 Hz (GTF) hsync: 72.00 kHz; pclk: 99.07 MHz
  Modeline "1024x768"  99.07  1024 1088 1200 1376  768 769 772 809  +HSync +Vsync
EndSection

Then, tell it to use the video mode:

Section "Screen"
  Monitor    "Configured Monitor"
  # Fill in self-explanatory data here.
  SubSection "Display"
     Viewport   0 0
     Depth     24
     Modes   "1024x768"
  EndSubSection
EndSection

Fix the broken ConnectorTable:

Section "Device"
  # Fill in device information here.
  Option      "ConnectorTable" "100,1,0,1,108,2,0,1"
EndSection

After you do that, you should have a working X display. If you still get a blank screen, switch to a tty, run export DISPLAY=:0, run xrandr, and check to see that the eMac is using the correct resolution. Make sure DVI is not mentioned.

The photo by Oswald using -HSync +Vsync depicts the eMac with the picture off-centre. This is because -HSync +Vsync (the default) is wrong! Use +HSync +Vsync, and your picture will be in the centre of the screen.

Instead of the ConnectorTable hack above, one user from the Ubuntu forums points out that it is possible to get a picture by adding the following code to the Device section:

Section "Device"
  # Device information goes here.
  Option "monitor-DVI-0" "iMac"
EndSection

This is not as good a solution as setting ConnectorTable, as the external VGA monitor does not work with this set.

If you used this information to try and fix X on your eMac, please let me know in the comments so I know whether it was helpful or not! Thanks!

Tagged: , , , , , | 18 Comments »

Takeaway lights script

23 December 2008

I just stumbled across a simple yet fun script I wrote over a year ago to animate your keyboard LEDs:

#!/bin/sh

LED="setleds -L"
SLEEP="sleep 0.2s"

$LED -num -caps -scroll

if [ "$1" = "-c" ] ; then
	exit 0
fi

while [ 1 ] ; do
	$LED +num
	$SLEEP
	$LED +caps
	$SLEEP
	$LED +scroll
	$SLEEP
	$LED -num
	$SLEEP
	$LED -caps
	$SLEEP
	$LED -scroll
	$SLEEP
done

It will simply pulsate the keyboard LEDs from left to right. Note that this script only works while logged into a tty — it does not work under X11.

Tagged: , , | 2 Comments »

VirtualBox 2.1.0 does OpenGL 3D acceleration

18 December 2008

VirtualBox 2.1.0, released today (see the changelog), does OpenGL 3D acceleration, which is something I have been hanging out for for a very long time. It doesn’t yet do Direct3D acceleration, but OpenGL is sufficient to run many popular games, namely ones based on the id Tech 3 (Quake III Arena, Jedi Knight II, Jedi Academy, Alice, etc.), Half-Life, or Source engine.

The 3D acceleration works with a Windows guest (with guest additions installed), and works on any host operating system (including Linux).

OpenGL in VirtualBox

The above screenshot shows me running Quake III Arena in Windows XP in VirtualBox 2.1.0 in Gentoo, which is running at 52fps.

It is quite ironic that VirtualBox only supports OpenGL acceleration. VMware has had 3D acceleration for a while now, but they have only supported Direct3D, not OpenGL. So I suppose in the meantime, you can use VirtualBox for OpenGL games, and VMware for Direct3D games. Everybody’s happy!

Update: I filed a bug report in the VirtualBox bug tracker saying that WineD3D should be used to achieve Direct3D acceleration.

Tagged: , , | 17 Comments »

Configuring a chrooted Ubuntu installation

11 December 2008

Installing a chrooted Ubuntu installation (i.e. creating one from scratch) is quite easy. All it takes is a lot of bandwidth, because each chroot installation needs to download about 200MB from the internet. You can save bandwidth by setting up an apt proxy (I use approx, available in the Ubuntu repositories) on your computer or server first, but that’s another story.

When you manually install Ubuntu with debootstrap, the initial setup of the environment is quite different from when you install Ubuntu off the normal installer CDs. There are a few tweaks you have to make to get it out of its default state of insanity for most cases.

First of all, it’s quite easy to make a chroot. Syntax is like this:

sudo debootstrap --arch=i386 hardy \
    /wherever/you/want/to/put/the/chroot \

http://your.isp.mirror/pub/ubuntu

When chrooting into the environment for the first time (and upon subsequent reboots of your computer, as well), you should run the following commands first outside the chroot, otherwise you can get quite strange errors. (Source: Ubuntu 6.06 Live CD customisation guide)

mount -t proc none path_to_chroot/proc/
mount -t sysfs none path_to_chroot/sys/
mount -o bind /dev path_to_chroot/dev/

Also, to get X apps working, type this outside your chroot:

xhost +
mount -o bind /tmp wherever_your_chroot_is/tmp/

I once had a problem with installing the dbus package. For some reason, the dbus-daemon process just bombed out. Eventually, I found the problem was related to forgetting to mount the /proc and /sys directories, so don’t forget to run the above lines.

If Perl complains while being invoked (for example, when installing packages), run the following commands:

export LC_ALL=C
sudo dpkg-reconfigure locales

Your chroot environment may or may not be able to access the internet. In order for it to translate host names (www.google.com) to IP addresses (66.102.7.104) it needs to know about your DNS server.

From outside your chroot environment, run the following:

sudo cp /etc/resolv.conf wherever_your_chroot_is/etc/

resolv.conf is a configuration that simply contains the IP addresses of the DNS servers that the computer knows about. Normally, whenever you connect to a Local Area Network and use DHCP to get an IP address, the resolv.conf file is automatically updated. Because the chroot uses the already-existing network, it doesn’t have to use DHCP, but that means the resolv.conf doesn’t get updated automatically.

If you’re using approx to cache your packages, or your ISP mirrors Ubuntu, copy your local sources.list file into the chroot (be careful if your distro version is different to the distro inside the chroot) so as to download from the same location:

sudo cp /etc/apt/sources.list wherever_your_chroot_is/etc/apt/

Now, if you want to boot into the chroot later on, you’ll find that you have no way to log on. That’s because there is no root password set by default. You’ll want to set it from inside the chroot:

passwd root

That’s all I have for now. If anybody has any improvements they want to suggest, please tell me in the comments, so I can add it to the article!

Soon to come: a script I wrote which automates most of this!

Tagged: , | 2 Comments »

Older Entries
Newer Entries