Spork Bomb

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?

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!

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 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

This has already been covered by other bloggers but, as I did found the project (albeit accidentally), I think I'm justified in writing a post about it :)

The Arch Hurd Project is a crazy-sounding project of porting Archlinux to the GNU/Hurd platform so we can all, as Allan McRae put it, bask in microkernally goodness. We're currently working on building a good cross-compiler and cross-compiled system (most of the pieces are in place, it seems), after which we'll cross-compile pacman, autoconf/automake, make, et cetera until we can start packaging things up. The first release is likely to be a QEMU image.

So, what exactly makes an OS Arch-like? As Arch is what you make it, that's a rather difficult question to answer, I did, however, narrow it down to a few things which I think are truly important for any Arch system:

• Use of the pacman package manager.
• Some form of ABS tree.
• System-wide config file like /etc/rc.conf.
• i686 optimisation.

Currently the i686 optimisation is proving to be a pain: we're not sure if it's something we've done, or something else. Yet. Pacman will, obviously, have to wait until we can actually boot it first, the ABS tree is begun (as well as repositories), and I don't think anybody has even thought about an /etc/rc.conf file yet—though it shouldn't be too difficult to alter the Hurd initscripts to pluck data from a config file.

Other sites/blog posts you might find interesting:

Arch Hurd

The official Arch Hurd website

Parabola GNU/Linux

A project to provide an entirely free Archlinux

Arch Hurd?

Allan's post about Arch Hurd

A … “Hurd” work to do

Flamelab's post about Arch Hurd