Mindstab.net

Well, with Qemu 0.8.0 out for a while I decided to finally get my networked starcraft working with it. There were several changes but it’s not too bad.

The first simple easy change to take note of is that the ‘-enable-audio’ flag no longer works. They have added support for several sound cards of which you have to pick one. If you want to maintain the Soundblaster you previously had working you should now use ‘-soundhw sb16′. However if this is a fresh install you may find that one of the other drivers ‘-soundhw adlib’ or ‘-soundhw es1370′ work better for you or you could use the ‘-soundhw all’ option and have QEmu emulate them all and let Windows pick what it likes best.

Now, go see Starcraft in QEmu on Linux, the original, and get set up.

Once you’re set up for Qemu 0.7.2 there are some networking changes that I will outline here.

• QEmu now uses a tap device instead of a tun device so go through bridge.sh and cleanup.sh and change all references to ‘tun0′ to ‘tap0′.
• The QEmu command line options for network configuration are now more powerful so you can delete ‘/etc/qemu-ifup’ since it is no longer required. Instead, when you are starting QEmu for Starcraft on the network use ‘-net nic,vlan=0 -net tap,vlan=0,ifname=tap0′.

And that’s it. Now you are good to play networked starcraft in QEmu 0.8.0 on Linux.

I guess I can see why people say Gentoo isn’t suitable for servers because it isn’t stable. They don’t mean any program in particular. They mean the distro.

Tonight a GLSA comes out for pound, the reverse proxy I use for SSL in front of apache because mpm_peruser and mod_ssl don’t play nice. It says pound had a vulnerability so I have to upgrade. Ok. But my only upgrade path leads to a version of pound with a different config file. Hell, it’s a whole different version (1.9 to 2.0.5). Anyways, it takes me some time to figure out the new file format tweaks and get it to ever turn on. But then a bigger problem: Apache and pound aren’t playing nice. After about half an hour of seeing my browser tell me it’s detected the server isn’t handling a forward correctly I figure out is has something to do with my condition in the crypt.mindstab.net’s virtual host file about https being on. It was:

RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule /(.*) https://crypt.mindstab.net/$1 [L,R]

But that’s not working since apparently pound has changed behaviour and now doesn’t tell apache it’s using https. Wonderful. Will I be able to find a way to force security for those pages any more?

Well, after a bunch more reading on pound and mod rewrite and experimenting I seem to have come to a reasonable conclusion. Pound can pass arbitrary strings to the back end server so in the pound config I have a line:

AddHeader "POUND_SSL: yes"

and my vhost config file has the following:

RewriteEngine on
RewriteCond %{HTTP:POUND_SSL} !^yes$
RewriteCond %{REMOTE_ADDR} !^127.0.0.1$
RewriteRule /(.*) https://crypt.mindstab.net/$1 [L,R]

It check to see if pound’s new HTTP header string is there (but since this could be forged, although why?) it also checks to make sure the connection is coming from the same host hopefully meaning that it’s the reverse proxy and not anyone else. This should be sufficient to guarantee ssl is on for crypt.mindstab.net.

But as for the original point, server distro’s would probably notify me of an update, I’d install it and that’d be the end. No hour wasted porting to new configs and whole new major version’s of software. Oh well, I still do like gentoo and I’m not even sure any other distro offers mpm_peruser. So this is the price I get for better customizability. Some extra effort. But on the plus I do always learn more from these sessions…

So I finally got Gnome’s NetworkManager working on my laptop.

The ebuilds are from Gentopia. I had to mkdir /var/run/NetworkManager. Also I had to add to /etc/init.d/NetworkManager in it’s start section before it did anything:

mkdir /var/run/wpa_supplicant
rmmod ath_pci
modprobe ath_pci

Once that was in place I

rc-update del net.ath0
rc-udate add NetworkManager default

And added nm-applet to the Gnome session.

Finally, I added:

RestartServices cpufreqd NetworkManager

to /etc/hibernate/hibernate.conf so that NetworkManager was restarted properly when coming out of hibernation (and the non-perfect ath driver was reloaded because it seemed to stall).

And now everything is working quite well. I’ve been using it for a day or two no problem. It’s a nice piece of software. Only complaint is that the openvpn plugin doesn’t support the ‘float’ command. But I’ll file a bug.

Update: Warnings at bottom but basically this is unstable so DO NOT try it at home.

With all the talk about some of the first MacOSX virii starting to show up and MacOSX users being arrogant and that helping the virii propagate, I thought it’d be at least worth while to investigate some anti virus solutions for Linux. The big two names I came up with were F-Prot and ClamAV. Based vaguely remembered hearsay that there were some kind of licensing bad feelings about F-Prot I went with the more “socially approved” (based on vague remembrances) ClamAV. I decided to go all out and get scan on access set up as well.

To get that working, ClamAV needs something called Dazuko. Upon attempting to emerge dazuko I was informed I needed CONFIG_SECURITY_CAPABILITIES in my kernel. After some investigation it turned out that I had to go into the Security sub menu and select “Enable different security models” and select as a module “Default Linux Capabilities”.

One rebuilt kernel and reboot later I tried to install Dazuko again and loaded it “modprobe dazuko“. This time it worked. After that I installed clamav.

Then I modified /etc/clamd.conf

/etc/clamd.conf

User root

...

ClamukoScanOnAccess

ClamukoScanOnOpen
ClamukoScanOnClose
ClamukoScanOnExec

ClamukoIncludePath /
ClamukoExcludePath /proc
ClamukoExcludePath /sys
ClamukoExcludePath /dev

Then I activated clamd “/etc/init.d/clamd start“. You can check /var/log/clamav/clamd.log for error messages.

The, ideally you should have system protected against virii. The init script should also start freshclam so you’ll also always have up to date definitions. The thing to see now is how badly this impacts performance.

5 minutes and one reboot later: And just like the warning said, it made my system unstable and it hung shortly after turning this on. So this doesn’t look like it’s ready for the prime time yet.
And the security kernel options seem to bugger avahi. So don’t forget to revert them when undoing this mess.

GTD Tiddly Wiki is amazing. I had been looking to put Tomboy on my USB stick, but that wasn’t looking like it would work (the windows port isn’t… done?) and then I remembered this project I’d read about a while ago and looked it up. It’s a Wiki, written entirely in JavaScript and Ajax. But most importantly and amazingly, it’s portable. You just drop the one 120kb (empty, more if you go with the defaults) on a Usb stick and open it in a web browser. You can edit it like a regular Wiki (nicer, cooler, and better interface I might add) and then when you’re done it saves the data to it’s own file and is ready to go. Close the browser and then open it later else where and you’re right where you left off. This app/script/web page is an amazing example of JavaScript and Ajax. One of the best I think. And it’s amazingly useful. I know have a portable Wiki on my USB stick. Serious kudos.

Also, I just got Gaim working off my USB stick. Installed portable Gaim and a few plugins, and ASpell. It all works. Gaim encryption, spell check. I was also shows how to get port forwarding/proxying setup with putty, so I can use MSN with Gaim. Before you connect to your ssh server, just goto the ‘keys’ section of the options menu, and setup a source port of whatever (8080 for example) and then set it to dynamic and ipv4 and hit the ‘add’ button and that’s it. Connect as you normally would. Leave it open, the go into your app (in this case Gaim) and set it for a SOCKS5 proxy on local host on what ever port you setup (8080). That’s it. Most ssh servers are setup automatically to handle this and now I can use MSN with Gaim from school. Rock.

So an enterprising lad by the name of gfoot on the GP2X forums has backported the linux 2.6 USB gadget serial module to the 2.4 kernel and compiled it for the GP2X [Thread, module].

Once you get the module, a fellow named luteijn wrote a script to set up a one shot bash prompt on the GP2X waiting for a connection (the script must be run each time you want to connect, because disconnecting kills the bash session) while the menu runs [bash script]. Then just drop the script and module on an SD card in the same directory and run the script from the utility menu of the GP2X. It will then be ready to receive connections. Once the g_serial module is loaded and working you can’t use the GP2X’s USB storage device emulation at the same time, so I came up with unbash.gpu:

unbash.gpu

#!/bin/sh

rmmod g_serial
cd /usr/gp2x
exec ./gp2xmenu > /dev/null 2>&1

On the client side, you need to have the usbserial and cdc_acm modules loaded (both found in the USB section of the Kernel menu). If you get this right, /dev/ttyACM0 should show up, which is your tty -> USB -> GP2X device.

Once that’s done right you have to setup minicom. Run minicom -s so that you go into setup before minicom initializes. Go into ‘Serial port setup’ and change the Serial Device to /dev/ttyACM0, and hit F to turn off Hardware Flow Control. Exit that menu and go into ‘Modem and dialing’, and hit A and clear the entire ‘Init String’ (it’s useless for this purpose). Then you should be good to go. Save the setup for easy reuse and then exit the menu and you should be greeted by a bash# prompt on your GP2X.

Screen has subsequently been ported to the GP2X. You’ll probably want to add the ‘-m’ switch when running minicom, as this makes it use ALT-key instead of CTRL-A-key for accessing it’s menus. Using ‘-m’ it won’t overlap with screen’s CTRL-A commands.

Obligatory screenshot

So I’ve finally got Starcraft LAN party and battle.net worthy without giving up Linux. What a journey.

So, to start with grab a fresh copy of Qemu, I have 0.7.2, and KQemu.

With recent kernels (2.6.13.2) I’ve found that the /dev/kqemu device isn’t created when the kqemu module is loaded. This will probably be fixed in the next release but in the mean time create:

mk_kqemu_node.sh

#!/bin/sh
modprobe kqemu
mknod /dev/kqemu c 250 0

Once that’s done Qemu should work with the accelerator. It runs at quite acceptable speeds. Then throw on your favorite windows version in QEmu. I find windows 98 is a nice and small installation, perfect for Starcraft.

~/qemu $ qemu-image create hd/win98.img 1G
~/qemu $ qemu -hda hd/win98.img -cdrom cd/win98.iso -boot d

That should be all you need to get windows up and running.
Next install Starcraft.

# Starcraft Install
~/qemu $ qemu -hda hd/win98.img -cdrom /dev/cdrom0
# Broodwars Install
~/qemu $ qemu -hda hd/win98.img -cdrom cd/broodwars.iso

It is a great idea to rip the broodwars cd so you can just use the image and never have to carry the cd around with you. Qemu won’t care and windows won’t know.
Also, you can run qemu with -monitor stdio to get a qemu command prompt in the terminal. From there you can unmount cds and remount new ones while the system is running. Very handy.

eject cdrom
change cdrom /dev/cdrom

Now the easy part is done. Starcraft should run in qemu and you should be able to play single player, and connect to battle.net and get upgrades, but not play online. This is because the default qemu networking is good for making requests but doesn’t accept incoming connections. So we have to make qemu use it’s tun device support, create a virtual network between qemu and our computer, and then bridge that network to the real one.

the tools you need are:

• kernel with tun/tap device support
• kernel with bridge support
• bridge tools supplying the ‘brctl’ command

Equipped with these you can write simple shell scripts (my approach) or more flexible scripts (for another day). I just took the instructions I found and put them in a script for quick use. Still have to edit it for each different network for now but it shouldn’t be too hard to extend.

(Note: I had issues with using this setup with wireless devices. You may too. If you have a choice, go wired. Might make it work.)

qemu-bridge.sh

#!/bin/sh

# The network interface
IF=eth0
# Our computers desired IP address on the network
IP=90.0.0.193

BROADCAST=90.0.0.255
GATEWAY=90.0.0.254

ifconfig $IF down
echo "Creating bridge..."
brctl addbr br0
ifconfig $IF 0.0.0.0 promisc up
ifconfig tun0 0.0.0.0 promisc up
#echo "Bringing up br0 (dhcpcd)..."
#dhcpcd br0
echo "Bringing up br0 ($IP)..."
ifconfig br0 $IP netmask 255.255.255.0 broadcast $BROADCAST up

echo "Configuring bridge..."

brctl stp br0 off
brctl setfd br0 1
brctl sethello br0 1
brctl addif br0 $IF
brctl addif br0 tun0
route add default gw $GATEWAY

qemu-cleanup.sh

#!/bin/sh

IF=eth0

ifconfig br0 down
ifconfig tun0 down
ifconfig $IF down
brctl delbr br0

Also, for qemu to actually know there is a tun device to use, you also need to create:

/etc/qemu-ifup

#!/bin/sh
sudo /sbin/ifconfig $1

Which can be tweaked a bit. I’ve been running qemu as root so you wouldn’t need the sudo front to the ifconfig command, however I may not need to be running as root.

Anyways, to get this to all work, you have to launch qemu in one console first. Qemu creates the tun device you’ll be using so every time you launch qemu you need to run the bridge script and every time it exits you need to run the cleanup script. So in one terminal run something like:

qemu -monitor stdio -hda hd/win98.img -cdrom cd/broodwars.iso -enable-audio

Then in a separate console run the qemu-bridge.sh once you have it configured to your surroundings. You may need to make windows renew it’s IP if you are using dhcp. With windows 98 go to start->run ‘winipcfg’ and select the network adapter and click ‘renew’ to get windows to aquire an address on the physical network.

Then, ideally you should be all done, and ready to play Starcraft on battle.net or at a LAN party. Good luck!

[Update 2005.11.09] I got sound working, as detailed here.
[Update 2006.06.11] Moved to QEmu 0.8.0. A few modifications are required as out lined here.

Well, in the name of helping add to the wonderful and useful infrastructure this city is building of unsecured wifi access points I’ve not been wanting to use WEP or anything. How ever I’ve been concerned about the easy access to my network. So I finally popped another ethernet card into Janus my firewall and routed the wifi box through that. Voila, segregated wireless. But now my laptop Nika wasn’t on my network and couldn’t share files easily etc.

So the solution was to create a VPN. I’d been wanting to do this already so I could use it from remotely, but now I finally had some really good motivation.

So, to start, I pkg_add openvpn with OpenBSD on Janus and emerge openvpn on my laptop Nika. Portage notified my that the 2.x series won’t work with the 1.x series that OpenBSD 3.7 has. So I pkg_delete ed that and downloaded and installed a fresh version on Janus from the openvpn site. One hitch, had to ./compile with –with-lzo-headers=/usr/local/include –with-lzo-lib=/usr/local/lib.

Then came the fun of configuring them and using SSL/TLS. Useful reference in vague order are:

• Official OpenVPN 2.x HowTo
• VPN Guide on Gentoo Wiki
• OpenBSD networking tutorial: Networking, Bridging, and OpenVPN
• OpenVPN 2.x on OpenBSD

A couple points were that while syntax like

dev tap

worked on Linux, you needed

dev-type tap
dev tun0

on OpenBSD

Only the instructions in the official OpenVPN guide that told you to use the easy-rsa directory and tools that openvpn supplies worked for generating SSL certs and stuff that didn’t cause connection errors.

Also, when as a client, and using the remote server name.com, you can also add the ‘float’ command so that the client will accept packets from other IPs (in my case I specify Janus.mindstab.net so it will resolve from any where on the internet, but when I’m at home it resolves to a private network address).

OpenBSD bridging is pretty easy

# cat /etc/bridgename.bridge0
add vr0
add tun0
up

# cat /etc/hostname.tun0
link0 up

Then I added some rules to pf so as to segregate my wireless network and allow the vpn to work.

The relevant parts of my pf.conf are below:

ext_if="vr0"
int_if="vr1"
wi_if="xl0"
vpn_if="tun0"
int="192.168.1.0/24"
wi="192.168.2.0/24"
vpn="192.168.3.0/24"
inferno="192.168.1.2/32"

scrub in all
nat on vr0 from $int to any -> (vr0)
nat on vr0 from $wi to any -> (vr0)

# FTP proxy
rdr on $int_if proto tcp from any to $ext_if port 21 -> 127.0.0.1 port 8021
rdr on $wi_if proto tcp from any to $ext_if port 21 -> 127.0.0.1 port 8021
rdr on $vpn_if proto tcp from any to $ext_if port 21 -> 127.0.0.1 port 8021

# VNC
rdr on $ext_if proto tcp from any to (vr0) port 5900 -> $inferno
# BitTorrent
rdr on $ext_if proto tcp from any to (vr0) port 6881 -> $inferno

# for active mode FTP connections
pass in on $ext_if inet proto tcp from port 20 to ($ext_if) user proxy flags S/SA keep state
antispoof quick for $int_if inet
antispoof quick for $wi_if inet

antispoof quick for $vpn_if inet

# segregate wireless (making it dmz ish)
block in on $wi_if from any to $int_if
block in on $int_if from any to $wi
block in on $vpn_if from any to $wi

# secure janus

block in on $wi_if from any to 192.168.2.1
pass in on $wi_if proto udp from any to $wi_if port 1194
# don't really need since vpn is working
#pass in on $wi_if proto tcp from any to $wi_if port ssh
#pass in on $wi_if proto udp from any to $wi_if port ssh

...

My server’s OpenVPN local.conf:

dev-type tap
dev tun0

server 192.168.3.0 255.255.255.0
ifconfig-pool-persist /etc/openvpn/mindstab/ip_pool

mode server
status /var/log/openvpn-status.log

# extra auth channel encryption.  One of the non official
# tutorials first showed me how to nicely set this up
tls-auth /etc/openvpn/mindstab/mindstab-key.txt 0
keepalive 10 30
client-to-client
#max-clients 150
verb 3

tls-server
dh /etc/openvpn/mindstab/dh1024.pem
ca /etc/openvpn/mindstab/ca.crt
cert /etc/openvpn/mindstab/server.crt
key /etc/openvpn/mindstab/server.key
comp-lzo

user nobody
group nogroup

persist-key
persist-tun

And the laptop’s client’s OpenVPN local.conf:

#float allows openvpn to accept packets from
#ips that aren't what the remote line resolves to
float
remote janus.mindstab.net

dev tap

client
resolv-retry infinite
mute-replay-warnings
verb 3
persist-tun
persist-key
tls-auth /etc/openvpn/mindstab/mindstab-key.txt 1

tls-client
ca /etc/openvpn/mindstab/ca.crt
cert /etc/openvpn/mindstab/nika.crt
key /etc/openvpn/mindstab/nika.key
comp-lzo

# adds a route to the routing table while
# this vpn is active
# in this case any request for my home network
# are routed through this vpn
route 192.168.1.0 255.255.255.0

And that’s about it. A day’s work. Really. Follow the first guide, it’ll save you a lot of time and problems. the others all just didn’t work for me.

Once you’re ready, it’s just /etc/init.d/openvpn start on Gentoo, and rc-update add openvpn default if you’re confident. For testing just run openvpn –config local.conf.

On OpenBSD for persistance, add ‘/usr/local/sbin/openvpn –daemon openvpn –writepid /var/run/openvpn.pid –config /etc/openvpn/mindstab/local.conf
‘ to your /etc/rc.local.

Now weather I’m at home or school I can just open my ssh mount and browse Inferno (my desktop) for files.

I picked up a Toshiba Satellite M40X RH4 laptop that was on sale yesterday. It has a 1.5GHz Celeron M with 256MB ram, an Intel 915 video card with 128 sharred memory, a 40GB harddrive, and an Atheros wlan chip. All for $899. So I’m pleased about that.

The installation took a lot of research to make sure I could optimize things properly and get everything working. The Gentoo live cd does not have the madwifi drivers so I had to rely on ethernet until the install was done. It used the e100 module.

The CPU is exactly a Celeron M 370, which is of the Dothan family (90nm). It’s essentially a stripped down Pentium M. So as far as I could tell, for the kernel, specifying Pentium M was the way to go. As for GCC -march it was a little more tricky. The Getnoo CD ships with GCC 3.3.5 which has no special pentium-m cpu family, however GCC 3.4.4 does. My research said that it was safe to go with pentium3 for -march for the stage1 install (GCC describes pentium-m as a stripped down pentium 3, and the celeron-m is a stripped down pentium-m). However I really wanted GCC 3.4.4 so I could use -march=pentium-m. To get this I created the file /etc/portage/package.keywords and added the following to it:

sys-devel/gcc ~x86
sys-libs/libstdc++-v3 ~x86
sys-libs/glibc ~x86
sys-devel/gcc-config ~x86

This created an override in porage so it would use the unstalbe version of those packages. To check it was working I # emerge gcc libstdc++-v3. I was ready for the stage1 install.

A note to even the experienced Gentoo user. The install process has changed over the years so you should still follow the handbook. There are subtle changes you’d miss if going from memory that are rather important now. Also, the networking for Gentoo has been completely rework. It’s pretty neat and worth reading up on: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=4&chap=0.

Once the stage1 install was done I had GCC 3.4.4, so I changed my -march in make.conf to pentium-m. Then instead of the # emerge –newuse system for stage2 based on stage1 I used the starting from stage2 command # emerge –emptytree system which reinstalls everything and the system all with the new GCC and pentium-m -march. However looking over the list of programs to be installed I noticed gcc 3.4.4 and 3.3.6 were being installed. After a bit of looking I determined that it was doing this to upgrade the 3.3.5 the system came with. I was concerned that since the 3.3.6 install was after the 3.4.4 install it would become the default GCC and miscompile everything not having support for march=pentium-m. The only way I found to remedy this was to remove gcc 3.3.5 with # emerge -C =gcc-3.3.5-r1. Then I proceeded with my stage2 install.

Stage2 install was a bit bumpy. It crashed at openssl because it needed perl, which hadn’t been installed. Brilliant. However after looking at the output of –emptytree versus -newuse I determined that everything from the stage1 should have already been recompiled with pentium-m by the time openssl showed up so I didn’t have to emerge perl and then run emerge –emptytree again to ensure everything got done. I just did emerger –newuse system and it picked up and got that openssl depended on perl.

Next up was the kernel. I went with the gentoo sources since they were more current (2.6.12 as opposed to vanilla 2.6.11), plus they apparently had some better laptop support patches. As stated earlier I went with the Pentium-M cpu family. Then the hardware support. The harddrive was a scsi device so I added scsi support and the piix driver. I added Intel 915 support for DRI, yenta sockets for pcmcia, 8139too for ethernet, and intel 8×0 for Alsa sound. Then compile and install and crossed fingers.

The rest of the install was fairly straight forward. Then I rebooted.

And everything worked. Amazingly enough. I installed the madwifi-driver and madwifi-tools and wireless-tools and a # iwconfig ath0 essid mindstab # dhcpcd ath0 later I had wireless internet! I then set up my wireless chip according to the new Gentoo net configuration. I have to say iplugd rocks my socks. Plug in cable, internet on! Unplug cable, internet off! It’s pretty cute. Combined with the new Getnoo net setup, the combined networking setup of my laptop is pretty sexy. I was really pleased about that.

Next up was the XOrg install. I needed the latest and greatest to get my i915 videocard working so I created /etc/portage/package.unmask and added x11-base/xorg-x11 to it. Then I did an ~x86 install of XOrg getting version 6.8.99.15.

I ran xorg –configure. It gave me some errors but gave me a xorg.conf.new. I had to hand configure the mouse, but then it ran.

The good: the new xorg didn’t need to be told about the 1280×800 resolution, it figured it out on its own.

The bad: Returning to the frame buffer console, it was garbled and unusable. Also, DRI was not working as X was not detecting the ram properly. After some searching I found that this problem is noted and there is a temporary patch. After some more research I was able to get the supplied patch and patch applying ebuild to actually work. You can get the portage overlay at http://www.mindstab.net/~haplo/xorg-patch-overlay.tar.gz. Then emerge xorg-x11-6.8.99.15-r1 with the USE=”dri-patch”. Ideally this will be resolved shortly (fingers crossed for 6.8.99.16 ).

As for the frame buffer, I could probably turn it off and be ok. However I’ll probably only be using it at boot where it looks pretty so I left it on. And hopefully that will also get fixed.

Once the new X was installed I tried it again and got DRI working! Even though it can access up to 128MB ram, the video card is by no means strong. It gets about 1200 FPS on GLX Gears. I’ll see about games later.

Then I started the massive Gnome install and left it over night. I sped it up by running emerge gnome –fetchonly in parallel. When you have hundreds of megs to download, it can help speed things up. Once Gnome was installed I installed the otehr necessary prerequisites like Gaim, Abiword, Firefox, Mpd, more fonts, extra themes and art.

Once it was done I fired up gdm and logged on and a nice Gnome desktop met me. More software installation met me, and I recompiled my kernel moving as many things to modules as I could. I did this because I wanted the initial pre frame buffer splash boot time to be slim.

I was having some responsiveness issues with Gnome and heavy load but I suspect it has to do with a number of IO related things. For some of them I need to wait for the Sata drivers (piix) to mature. On the other hand I had a suspicion the anticipatory IO scheduler was not working right so I switched to CFQ. I haven’t really hada heavy load to test it yet, but a few $ emerge -s seemed to be ok. You can change IO schedulers live through the /sys filesystem. To check $ cat /sys/block/sda/queue/scheduler. To set $ echo cfq > /sys/block/sda/queue/scheduler.

After more work I’ve realized there is definitely a drive driver issues. I tired a lot of things and at best hdparm can seem to only get 20MB/s off the harddrive buffered and 500kb off the dvddrive, which makes it unusable. This remains unresolved for me.

I put Quake2, Quake3, and Unreal Tournament on the laptop. I discovered there is currently a bug in Xorg 6.8.99.15 where only the first X session has DRI so I had to run my games there. Quake3 went first and it wasn’t quite able to launch a game. Then I tried Quake2 and it was somewhat jerky. Finally I tried unreal Tournament. Ater I turned the texture detail to medium it was decently playable even at 1024×768. I’m sure the i915 driver will mature over the next few months up to when Xorg 6.9/7.0 are out at the end of September. I’m also sure Gnome will be a little more responsive with 2.12 because this system only has 256mb ram and the Gnome devs have been spending the summer reducing memory usage.

And that more or less gets me to where I am now. It’s pretty cool but I need some stuff to mature and stabilize more :).

[update 1]
I got the dvd drive to work with the sata controller, as outlined here.

[update 2]
Alsa software mixing with Dmix (allows more than one audio channel) www.mindstab.net/wordpress/archives/42