Mandelbrot and Julia generator

Over the past couple of days I've been working on what started as a Mandelbrot Set generator, but has expanded into a Julia Set generator and, with the growing number of command-line parameters, can generate other stuff too, like Tricorn and Multibrot sets. Currently I'm using the simple escape-time algorithm for generating colours, which looks a bit rubbish, but it's a start to having wonderfully coloured fractals.

I plan to write a viewer program at some point, to provide a graphical interface to generate and zoom fractals generated by the current program. The source code can be found on github and is written in C.

My mandelbrot function is a slight variation of the original which allows an initial parameter.

Mandelbrot

Mandelbrot

Mandelbrot (b = -0.5 + 0.5i)

Mandelbrot, b = -0.5 + 0.5i

Julia (K = 0.5 - 0.3i)

Julia, K = 0 + 0i

Tricorn

Tricorn

Multibrot (d = 3)

Multibrot, d = 3

XMPP Status Updates

Yesterday I had the idea of writing a cronjob to, every five minutes say, check things like the CPU load and temperature, and send me a message via Jabber is anything was amiss. I then realised that I could have this script send me a list of new posts in my RSS feeds, and a list of package updates, and even a notification when a torrent is done.

Today, I found sendxmpp, which, according to the website, “is a perl-script to send xmpp (jabber), similar to what mail(1) does for mail.” This seemed perfect for my needs, so I installed it, wrote the configuration file, ~/.sendxmpprc, which is in the following format and must be mode 0600:

# A comment
username@hostname password

The command itself is invoked as follows:

echo "message goes here" | sendxmpp jid

A subject can be given, but for my purposes that was unnecessary. I wrote a script to run be run by cron at 5 minute intervals to alert me if the fan speed, CPU and HDD temperatures, or load average crossed certain thresholds, as well as checking on my torrents and telling me if any had finished since the last message:

#!/bin/zsh

memmax=993.0

fanspeed=`sensors | grep fan1 | sed -e "s/fan1:\s*\([0-9]*\).*/\\1/"`
cputemp=`sensors | grep temp3 | sed -e "s/temp3:\s*+\([0-9]*\).*/\\1/"`
hddtemp=`sudo hddtemp -n /dev/sda`
memusage=`free -m | grep "buffers/cache" | sed -e "s/-\/+ buffers\/cache:\s*\([0-9]*\)\s*\([0-9]*\).*/\\1/"`
loadavg=`uptime | sed "s/.*load average: \(.*\)/\\1/"`

memcheck=$[ `free -m | grep 'buffers/cache' | sed 's/.*\([0-9][0-9][0-9]\).*[0-9].*/\1/'` / $memmax * 100 ]
loadcheck=`echo "$[\`uptime | sed "s/.*load average: \([0-9\.]*\)/\\1/" | sed "s/, .*//"\` * 100]" | sed "s/\..*//"`

# Add notifications about the system not acting as it should - 2 spaces after the ] to line up with torrent messages.
[ $fanspeed  -ge 4750 ] && echo "[status]  Northbridge fan speed too high: $fanspeed RPM" >> /tmp/xmppmessages
[ $cputemp   -ge 50   ] && echo "[status]  CPU temperature too high: $cputemp °C"         >> /tmp/xmppmessages
[ $hddtemp   -ge 45   ] && echo "[status]  HDD temperature too high: $hddtemp °C"         >> /tmp/xmppmessages
[ $memcheck  -gt 33    ] && echo "[status]  Memory usage too high: $memusage / $memmax MB" >> /tmp/xmppmessages
[ $loadcheck -ge 50   ] && echo "[status]  Load averages too high: $loadavg"              >> /tmp/xmppmessages

# Only show torrents whose status has changed
if [[ ! -f /tmp/torrentstatus ]]; then
    w3m -dump "http://localhost/rtorrentinfo.php?seed=1" | awk '{print "[torrent] " $0}' > /tmp/torrentstatus
    cat /tmp/torrentstatus >> /tmp/xmppmessages
else
    w3m -dump "http://localhost/rtorrentinfo.php?seed=1" | awk '{print "[torrent] " $0}' > /tmp/torrentstatus2
    comm -1 -3 /tmp/torrentstatus /tmp/torrentstatus2 >> /tmp/xmppmessages
    mv /tmp/torrentstatus2 /tmp/torrentstatus
fi

# Send and clear the messages
sendxmpp mike@barrucadu.co.uk < /tmp/xmppmessages
echo > /tmp/xmppmessages

The reason I use a file to store the messages and then send them all in one go is because various other scripts append text to it—such as my hourly pacman database sync to notify me of new updates, and my hourly RSS sync, to notify me of new messages.

rtorrentinfo.php is a simple script I wrote to list seeding or leeching torrents, along with how much is complete (for leeching packages). I don't think it's overly relevent to the topic of the post, so if you want it, ask in the comments or send me an email.

Why Hurd?

A thread by opengl_cpp on the Ubuntu forums got me thinking about, well, why Hurd? Why Arch Hurd? I posted a short answer in that thread but now I'll try to answer more in depth here.

I always wonder why gnu project uses mach microkernel as its design basis. since there was a lot of advances to microkernel design such as l3 and l4 microkernels, it may not be a good decision to insist on old mach.

it has been proved that mach has some performance drawbacks in addition to its complex design, since l4 kernel is by far easier to understand and implement and also has performance superiority over mach.

Well, I don't know much about the variety of microkernels out there. In case you (reader, not opengl_cpp) didn't know, there have been ports of Hurd to different, or even completely new, microkernels, such as l4 and viengoos. They seem to have fallen out of favour with the Hurd dev community, though, so it seems we're stuck with Mach for the time being.

A reason for that could be inertia—so much effort has gone into writing Hurd for Mach it would be a pain to get everybody to learn the l4 or viengoos way of doing things. Which is a shame, really, if a different kernel could improve Hurd, it should really be given a fair try rather than just being an offshoot project with a handful of developers hoping it'll be an improvement.

blur xc asked a few questions about the Hurd and Mach itself:

1- What will the Hurd kernel offer than the Linux kernel lacks, besides the more fitting title "GNU Hurd" to the operating system?

Well, probably not much. The Hurd is a great idea, and they're doing brilliantly given the near-total lack of interest amongst open source users (not so amongst the Free Software crowd though). We can all, as Allan so brilliantly put it, bask in microkernally goodness. And, of course, we can play around with it—it's different, that's fun—but it probably won't offer much to us, for a while at least.

2- Driver support. Will the Hurd kernel need completely new drivers for all the hardware that's already running well under the Linux kernel? I understand the open source drivers could be ported across, but that's still a lot of work to do for a lot of hardware.

Currently, the Hurd uses drivers from Linux 2.6.0. Unfortunately, these are ancient, so it doesn't support fancy modern technology such as, oh I don't know… SATA. A problem, obviously, I can't even boot it on my laptop as it uses (to my surprise) a SATA HDD. I can boot it in a virtual machine, though.

There is work by Zheng Da to port DDE Linux26 to the Hurd from L4. This will, theoretically, bring support for Linux 2.6.29 drivers without any patching or rewriting needed. This also bring the possibility of, one day, having a DDE FreeBSD, or for any other OS, able to run their drivers in Mach.

OS-specific DDEs (Device Driver Environment) are a lower-level interface between what the OS drivers expect, and what DDEKit, the higher level driver abstraction layer, provides. As the OS-specific DDEs are only dependent on DDEKit, there is the possibility of porting DDEKit to another OS, and having all of the OS-specific DDEs come with it. Now that would be something wonderful.

3- w/ RMS being a FOSS zealot- does that mean there won't be any proprietary drivers permitted for hardware that doesn't have acceptable open source drivers?

I don't imagine RMS has supreme absolute control over the Hurd (well, I suppose he does, but you know what I mean…); third-party developers would still be able to develop non-free drivers, even if RMS did influence them away from the main Hurd distribution.

I don't imagine he'd be too happy about it… but I don't really imagine companies will begin porting their proprietary drivers to another OS, though in theory the DDE layer would allow you to run the Linux ones with Hurd just fine.

4- Same deal as above- but regarding Flash. Does this mean no adobe flash?

Heh, nor can I really see Adobe porting Flash any time soon.

5- in the end- what does that gain us?

A new kernel to play with, a new set of distributions to play with, and a great way to waste time. Isn't playing with the OS why most of us like Linux in the first place?

Arch Hurd has a logo and a package!

So, the logo contest I started on the 16th is now over, voting has been done, and a winner has been selected. I present to you, created by thoughtcrime and fastfret79, the new official Arch Hurd logo!

Arch Hurd

Now the project has a website, developers, a proper logo… surely everything we need, right? Well, not quite. We still need packages, but wait, we have one! Ok, so it's the archhurd-artwork package containing all the logo submissions but it's still a package.

Regarding the current status of Arch Hurd, we don't have a native toolchain or pacman running on the Hurd yet. Allan and I have been writing build scripts for everything we need, though, so it shouldn't be too long before we can run pacman and/or compile stuff. As always, help is welcomed, check the Arch forum thread to see what we're up to and contribute a build script or two if you're feeling helpful.

Arch Hurd is bootable!

Arch Hurd has hit a big milestone, it can be booted! We can all bask in microkernally, if not particularly Archy yet, goodness. Now we need to improve our bootable environment (it has no config files, /dev is empty, et cetera) and start work on a toolchain, autotools, pacman, and all the other things we need to build packages. Currently, it's a pretty useless system—but not for long :)

Building

Firstly we need to build Arch Hurd with Allan's crosshurd scripts:

mkdir hurd
wget http://repo.archhurd.org/crosshurd/crosshurd-20100116.tar.gz
tar xvf crosshurd-20100116.tar.gz

# You might need to edit ./scripts/prepare first.

source ./scripts/makeall

mkdir $HURD_DIR/servers
touch $HURD_DIR/servers/exec
mkdir $HURD_DIR/servers/socket

mkdir $HURD_DIR/tmp
chmod 1777 $HURD_DIR/tmp

Now you can either install to a partition or to a virtual hard disk for use with a virtualisation program such as qemu. GNU Mach doesn't support SATA drives yet, so I opted for qemu:

# Create the image
qemu-img create -f raw hurd.img 1GB

# Make and format partition
losetup /dev/loop0 hurd.img
fdisk /dev/loop0
losetup -d /dev/loop0
# partition should start at sector 63. Check with fdist -ul hurd.img
losetup -o 32256 /dev/loop0 hurd.img
mkfs.ext2 -b 4096 -I 128 -o hurd -F /dev/loop0

# mount image
mkdir $ROOT/mnt
mount -o loop /dev/loop0 /mnt

# Then, build hurd and copy to /mnt
cp -a /path/to/hurd /mnt

# Unmount
umount /mnt
losetup -d /dev/loop0

# Download a grub boot image
wget http://www.dolda2000.com/~fredrik/grub.img

# Note: Networking doesn't seem to work in qemu 0.12.1, downgrade to 0.11.1
qemu -boot a -fda grub.img -hda hurd.img -net nic,vlan=1 -net user,vlan=1

And now, you have a minimally bootable Hurd system.

After booting

I imagine one of the first things you'll notice is the complaint about the lack of /dev/console. So, let's set up some devices.

settrans -c /servers/socket/1 /hurd/pflocal
cd /dev
./MAKEDEV console null zero time hd0 hd0s1

And, you have no config files. Let's start to create those:

echo "/dev/hd0s1 / ext2 defaults 1 1" > /etc/fstab
echo "root:x:0:0:root:/root:/bin/bash" > /etc/passwd

If you opted for qemu, we can also set up the network at this point:

settrans -afgp /servers/socket/2 /hurd/pfinet -i eth0 -a 10.0.2.15 -g 10.0.2.2 -m 255.255.255.0
echo "nameserver 10.0.2.3" > /etc/resolv.conf

Extra Software

I have started writing build scripts for extra software, so first set the appropriate *_VER= lines in your ./scripts/prepare file:

SED_VER=4.2.1
NCURSES_VER=5.7
NANO_VER=2.2.1

sed

#!/bin/bash

cd $SOURCE_DIR
if [ ! -f sed-$SED_VER.tar.bz2 ]; then
  wget ftp://ftp.gnu.org/gnu/sed/sed-$SED_VER.tar.bz2
fi

cd $BUILD_DIR
rm -rf sed-$SED_VER
tar -xf $SOURCE_DIR/sed-$SED_VER.tar.bz2

rm -rf sed-build
mkdir -p sed-build
cd sed-build

../sed-$SED_VER/configure \
  --host=$TARGET \
  --prefix=/usr
make DESTDIR=$HURD_DIR install

cd $ROOT

ncurses

#!/bin/bash

cd $SOURCE_DIR
if [ ! -f ncurses-$NCURSES_VER.tar.gz ]; then
  wget ftp://ftp.gnu.org/pub/gnu/ncurses/ncurses-$NCURSES_VER.tar.gz
fi

cd $BUILD_DIR
rm -rf ncurses-$NCURSES_VER
tar -xf $SOURCE_DIR/ncurses-$NCURSES_VER.tar.gz

rm -rf ncurses-build
mkdir -p ncurses-build
cd ncurses-build

../ncurses-$NCURSES_VER/configure \
  --host=$TARGET \
  --prefix=/usr \
  --mandir=/usr/share/man
  --with-shared \
  --with-normal \
  --without-debug \
  --without-ada \
  --enable-widec

make
make DESTDIR=$HURD_DIR install

cd $ROOT

nano

#!/bin/bash

cd $SOURCE_DIR
if [ ! -f nano-$NANO_VER.tar.gz ]; then
  wget http://www.nano-editor.org/dist/v2.2/nano-$NANO_VER.tar.gz
fi

cd $BUILD_DIR
rm -rf nano-$NANO_VER
tar -xf $SOURCE_DIR/nano-$NANO_VER.tar.gz

rm -rf nano-build
mkdir -p nano-build
cd nano-build

../nano-$NANO_VER/configure \
  --host=$TARGET \
  --prefix=/usr \
  --sysconfdir=/etc \
  --enable-color \
  --enable-nanorc \
  --enable-multibuffer \
  --disable-wrapping-as-root

make
make DESTDIR=$HURD_DIR install

cd $ROOT