The basic specs are:

• 2.53GHz Intel Core 2 Duo
• 4GB (2×2GB) 1066MHz DDR3 SDRAM
• 500GB Serial ATA; 5400 rpm

More details as I deal with getting individual components working…

Installation: The install went fine using the latest test iso (2010.04.19-core-i686). The only “trick” was to change the partition table from GPT format (to msdos) before entering the installer. Luckily, parted is included on the install CD so this was simple. Also, install GRUB on the partition holding /boot instead of /dev/sda. There was no need to do anything with rEFIt as many guides prepared me for, but I think that is because I did not dual boot.

The final stage is to boot the OSX install CD and run:
bless --device /dev/disk0s2 --setBoot --legacy --verbose to speed up the boot time before you get to GRUB (3s vs 20s).

Video: This has a NVIDIA GeForce 9400M card, so a pacman -S nvidia and nvidia-xconfig then we are basically good to go.

Screen Brightness: There is mbp_nvidia_bl in the kernel, so you think that would work but no… Any changes made to the backlight level appear to be registered (and gnome-power-manager gives me a nice on-screen indicator that changes are being made) but the brightness stays the same. The Mactel PPA for Ubuntu contains a nvidia-bl kernel module which does the job. Grab the PKGBUILD here.

Keyboard Backlight: Using pommed is supposed to make this work and it did to an extent. The only issue was roll over from almost completely dimmed to fully on that made disabling the keyboard backlight impossible. Instead, I am just adjusting it manually using:
echo 255 > /sys/class/leds/smc\:\:kdb_backlight/brightness(TODO: write a script using this to bind the adjustment keys to.) In OSX, this would automatically come on in low light conditions but I have no idea how to approach that.

Touchpad: This “works” out of the box, although is completely broken as far as I am concerned. I quickly found out that a major touchpad use is to click with your thumb and then use a finger to select text or move/resize a window, etc. That does not work as touching your finger after the click with the thumb is interpreted as some sort of multitouch event. A patched bcm5947 module fixes this (but is a hack and is unlikely to be included upstream…). Grab the PKGBUILD here.

Wifi: It has a Broadcom BCM4322 802.11a/b/g/m wireless card. That does not work with the b43 driver, so requires broadcom-wl driver. Grab the PKGBUILD here.

Suspend to RAM: Worked out of the box. I was only required to tell xfce4-power-manager to use it.

Webcam: Used the isight-firmware-tools package to extract the firmware from the file that I remembered to grab from OSX before wiping (or perhaps used google to find…) and restart.

Sound: Installed alsa, ran alsaconf and everything worked. Shortcut keys required setting up.

Keyboard: Ignoring the lack of Home/End/Page Up/Page Dn keys, the thing that most annoys me is that to by default the “action” functions take preference over F1-12. I use F1-12 a lot more that the action keys. So these need to be swapped (TODO: do this…)

Bluetooth: Untested. I have no real use for this at the moment…

Apple Remote: TODO

Why do you think that even though Arch’s userbase numbers have exploded during the last year, the number of contributors (not counting the AUR) remains almost the same?

Well Greg, here are my opinions on the issue. I should point out that these are my opinions and do not necessarily reflect the opinion of Arch developers as a whole.

Firstly, I tend to agree with this sentiment. Over the last six months to a year, there has only been one new person that has stood out to me as developer material based on the contributions they have made (and one who just will not accept the position no matter how much we ask – you know who you are!).

I think the primary reason for this is a very large change in userbase. The earliest comment by me that I can find noting this change was in the middle of 2008. A lot has changed since then (I was not an Arch developer or forum moderator then and I am now getting a Mac…), but the change in userbase has continued over the years. I think Arch has changed from what was a “Do It Yourself” distribution to one where people expect a lot of help. This is very evident on the forums, where very basic questions are asked on an hourly basis. People think there is a lot of “RTFM” on the Arch forums these days, but ask those same questions on the forum three years ago and that would be considered a polite response. It seems that despite the large increase in the number of users, the number of people with the skills required to fix a problem that they notice has not increased at the same rate.

The second reason I see is that there are less things to be fixed in Arch. The only reason I started contributing to Arch is so that I could fix things that annoyed me and that continues to be my primary motivation. I can imagine that the distribution as a whole runs rather smoothly from a users point of view, at least compared to historically. Also, a lot of the “easy” bugs in the user visible parts of the distribution have already been fixed, so the barrier to entry is higher. Saying that, I have made a couple of patches to pacman itself in the last few weeks and I still know next to nothing about the actual pacman codebase (I focus on makepkg). So there are still reasonably easy pickings for motivated individuals to get themselves familiarised with the code before tackling harder issues.

Finally, I think there is becoming a gulf between developers and users. Perhaps this is an entirely unintended side-effect of the change in userbase. I know that many long term Arch users (including some developers) found the change in the types of questions being asked and demands being made on the forums quite demotivational and now spend far less time there. This means less interaction between users and developers, resulting in the developers being seen as quite a separate group. From a developer point of view, this could not be further from the truth. Arch is a “community distro” and contributions from the community are strongly encouraged. Remember that the x86_64 port started as a community project. If a user comes up with a good idea, and more importantly provides some code or implementation to back it up, it will be considered by the development team just as it would if a developer suggested it. Equally, developers make suggestions that are not taken up (trust me… I have had ideas rejected, taken out the back and shot before being buried in a shallow grave in a forest). But remember, talk is cheap. There have been many, many threads about the importance of package signing in pacman, but no-one has but in a decent effort to get this completed.

In short, we need more community members to step up and help out wherever they can. The core Arch development team is relatively small and our continued progress (beyond pure packaging) relies on contributions from the community. Even packaging could use more people (and we do take applications to become a developer from known community members). I am sure that there is something that annoys every user about their system. Why not try and fix it?

In true Baldrick style, I came up with a cunning plan… What if I called my shell with a linux32 prefix and then my system would think it was always an i686 one. I only need my system to think it is an x86_64 when I enter an x86_64 chroot, so that is much easier to create aliases to deal with. The trick was to create a /bin/bash32 file containing:

#!/bin/bash
linux32 /bin/bash -l "$@"

Then add bash32 to the list of shells in /etc/shells and use “chsh -s bash32” to start using it.

After using this setup for several weeks, the only issue I notice is that when using chroot, it will look for /bin/bash32 in the chroot and likely fail. That can be fixed by prefixing with the SHELL environmental variable pointing at an appropriate shell (more than likely /bin/bash). I am sure that creating a wrapper script to handle that would be easy but using chroots via the Arch devtools does not suffer from this problem so I have not looked into it further.

The installer is live CD based, so boots you into a nice looking desktop [01]. Starting the installation takes you to a graphical install system [02] with the prerequisite warning about being an alpha release and the issues it can cause your hamster. After reading some notes and agreeing to various EULAs [03], the install is all go.

Onto the preparation of your system. The language and time settings looked quite ugly [04], but I have suspicions that QEMU was running this quite slow and maybe this was an artefact. I found it good to know that despite the complexities of installing being hidden, there was options to go in deeper [05] if needed. Partitioning [06] was not particularly simple, but that is being reworked for the future.

The actual installation of packages [07] proceeds with a montage of screenshot to whet your appetite for your new install. Of course you probably have already seen what it looks like from the live CD… Then you create some new users [08] (although I do not know what exactly an “Administrator” is), enter the root password and install the bootloader. I have no idea what the “Configure System” item at the end of the installer sidebar does as after installing the bootloader I got a reboot dialog.

The booting system looks familiar [09] to any Arch Linux user. I had expected a graphical boot-up as I had heard something about it using Plymouth, but I guess that is for the future. The login screen indicates that the /etc/hosts file has issues with setting the hostname [10]. Other than that, I was left with a fully working KDE desktop with no obvious issues. Looking at some configuration files to see how well the automatic set-up went found some interesting points. The MODULES array in /etc/rc.conf both disables and enables the e1000 module [11]. Also, I noticed that kdm is started as a daemon rather than using the inittab method, which I guess is more in line with what Chakra wants to provide but I find that to be less flexible. The supplied pacman.conf has the repos listed in an interesting order [12] (I think [core] should at least come before the KDEmod repos).

Overall, the installer does its job despite a few rough edges. The install booted to the desktop with relatively few configuration issues that I could spot. Not bad for something labelled “alpha”. Is it the “Arch made easy” that is often touted on Distrowatch Weekly comments? Maybe. But with a distro like Arch, that is not necessarily a good thing.

Screenshot index:

[01] – Live CD Desktop
[02] – Installer start screen
[03] – EULAs
[04] – Language and timezone setup
[05] – Hidden “advanced” options
[06] – Partitioning
[07] – Package installation
[08] – User creation
[09] – Bootup
[10] – Login
[11] – /etc/rc.conf
[12] – /etc/pacman.conf

• Check the problem package is up to date (using the package search on the Arch Linux web-site)
• Check the binary files in the package using readelf -d file. If that does not show libpng12.so.0 or libjpeg.so.7, that package is not the problem.
• Try finding the problem package using the lddd script from the devtools package.
• If you are certain this is because of a package in the Arch Linux repos, file a bug report.

Or you could just ignore all that and rebuild cairo-lcd as that is probably your issue…

One such distro is Kahel OS. Breaking through the market-speak on their website, it basically claims to be a newbies distro that has all the features a guru expects. It comes in Server, Desktop and Light Editions. I decided to try the Desktop Edition using the installer released on 2009-12-25. I installed using QEMU as I do not have a spare partition at the moment.

The install CD boots to a horrific orange screen [01]. After selecting the “install” option, you are greeted with bunch of kernel bootup text [02], followed by an Arch style boot process [03]. No graphical boot for this distro, so newbie friendly is a bit dicey already. Once booted, you are presented with a screen explaining why Kahel OS is good [04]. I suppose that was in case all that boot text was scaring us away.

Then we are actually installing. The installer is what I call ascii-graphical [05], although reverts you to text based screens as needed [06] (from that screenshot, you might notice that the answers are not necessarily intuitive…). Partitioning is done in cfdisk [07], followed by reselecting what type of filesystem you really want [08]. I decided for a single partition taking up the whole 4GB image I created and selected Btrfs for something new and given support for new filesystems is one of Kahel’s claimed features. I found it a bit strange that there was no warning about this filesystem still being experimental, but after some searching I found one hidden away on another TTY [09].

The “Install Packages” step goes straight to output from pacman [10], so there is no option to customize your install. The default install uses 3GB of space [11]. The package list is certainly interesting…. it installs the entire base, base-devel, xorg, xorg-video-drivers, gnome and gnome-extra groups. These are supplemented with a variety of other software including banshee, brasero, gnote, firefox, go-openoffice, xsane, and lots of fonts. I do not understand the use of gnote over Tomboy given mono is already installed for banshee. The SVN version of gtkpacman is installed for graphical package management. Other software choices are plain strange, such as libgpod, which is not required by anything else and is fairly useless on its own.

Finally, the installer takes you through some basic setup [12]. This distinguishes three types of users; root, administrators and normal. An “administrator” appears to have been given permissions to perform a variety of tasks via policy-kit.

Once you are done, you can reboot into your nice preconfigured desktop… but I could not. Those of you paying attention earlier would have noticed that I choose to have a single partition using btrfs. Of course, grub can not boot from that so that is a fail on my behalf. But a newbie friendly distro should have stopped me from doing that.

So, here is what I found different form Arch Linux without actually booting the system. There are a couple of extra repos enabled in pacman.conf. The listed Kahel OS repo does not exist yet. I did find a link to another Kahel repo, but it was empty. As a non-working repo breaks gtkpacman, package management is broken out of the box. Also the archlinuxfr repo is present but disabled, probably just so you can easily install yaourt.

Several packages are novel to Kahel OS. These are mainly for automatic configuration of the desktop and fonts as well as providing nice icons. The developers need to learn about makepkg.conf as they have not set their PACKAGER variable. Also, something strange is happening to their kahel-desktop-base-configurations package. It has 22 files, but “pacman -Qk” show that 11 of them are missing from the system so some installer magic has occurred. Not a great use of package management…

Overall, I am not sure what this distribution hopes to achieve. It seems that that it wants to provide a fully functional desktop after install and maybe it achieved that (I can not comment). But the installer is far from what is considered user-friendly, to the point that I do not think someone could achieve an install using it and not be able to do so with the Arch installer. Looking at screenshots on their home page, I can not see a major improvement graphically from a standard GNOME install. From all their “release announcements”, I am not sure that they know what they are trying to achieve either.

As an aside, of the 704 packages installed by Kahel OS, I built 80 (11%). So there is a lot of scope for me to cause breakage for unsuspecting Kahel OS users!

Screenshot index:

[01] – Bootscreen with lots of orange.
[02] – Boot text
[03] – Familiar boot-up from Arch
[04] – Market-speak
[05] – Ascii-graphical installer
[06] – Configuring timezone
[07] – Partitioning disk
[08] – Selecting filesystem type
[09] – Hidden Btrfs warning
[10] – Installing packages
[11] – 3Gb installed
[12] – Set-up

My interest was piqued… Combining that with the joys of building a cross-compiler for an operating system or architecture you do not actually have access too (yes, I am a sad, sad person) and you get a Hurd cross compiler. I built a few packages and even managed to get (a slightly patched) pacman built. Then, having wasted much time, I moved on.

Several months pass and there is a post on the Arch forums, with someone trying to compile a GNU operating system for themselves. I mentioned my previous endeavours and somewhat surprisingly others seem interested in the possibility of making a Hurd distro. Well, Arch users are a weird bunch…

And so, Arch Hurd was born. There is a website, so there is no stopping now! The current status is a bunch of scripts that create a quite up-to-date cross-compiling toolchain (glibc-2.10.1, binutils-2.19.1 and gcc-4.4.2), which can be used to build the GNU Mach kernel, the Hurd, coreutils and bash (the latter two being more updated than the versions in Arch!). That is not far from a minimally bootable (but completely useless) system. Then we can all bask in the microkernally goodness.

I had a bunch of SDL related packages (sdl_gfx, sdl_image, sdl_mixer, sdl_perl) to update. These are usually fun, because they require extensive game playing for testing! My first point of testing is always Chromium B.S.U. Everything looked good there so I upload the updated sdl_gfx and sdl_image packages. Now for the second line of testing: Frozen Bubble. Interesting… SDL_mixer has an soname bump despite being an update from 1.2.9 to 1.2.10. Stranger things have happened (heimdal likes slipping soname bumps into minor version releases). So a rebuild of many other packages is in order. Rebuild frozen-bubble and try again…

FATAL: Couldn't load '/usr/share/frozen-bubble/gfx/loading.png' into a SDL::Surface.

Hmm… looks like an SDL_image issue. I can confirm this using some other games too. It turns out the SDL_image 1.2.9 release is very broken; just not broken enough to break Chromium B.S.U. So much for my extensive testing… It appears fixed in upstream SVN, but I am feeling lazy and just downgrade it while waiting for the new release that appears to be due in the next day.

Now, try Frozen Bubble again. Still no good…

[Graphics..........] [Sound Init] at /usr/games/bin/frozen-bubble line 312


Looks like the SDL_mixer update is causing issues. That may not be surprising given the soname bump. This is confirmed by starting the game with the --no-sound option. While searching for a fix, I discovered that the soname bump was an accident. Apparently, this has been fixed, but either the source was missed or something else was going on. The good news is, I do not have to do a big rebuild now (but the rebuilds I had already done were a waste). The bad new is, SDL_mixer is still broken… The change-log in SVN lists this:

Fixed bug loading multiple music files

Pull that patch and we can all play games again! Luckily, not all updates are that painful.

Edit: updates are now available for both SDL_mixer and SDL_image that fix these issues.

That was when I ran into fun… Once I had built gcc with package splitting, I decided to attempt to rebuild it again with the new packages just to make sure everything was OK. Turns out, that was not the case. The C pre-processor was failing basic sanity checks and that falls into the category of “not a good thing”.

So I compared the list of files in the split packages to the originals as I made quite a few changes and could have plausibly “lost” some files. Everything seemed as expected. The only real difference was the “fixed” include headers were gone. This was also expected as the previous PKGBUILD had this line:


# Remove fixed includes, either no need for them, or they're not complete
rm -rf ${pkgdir}/usr/lib/${CHOST}/${pkgver}/include-fixed/*


That comment is quite correct as the gcc packages are built in a minimal chroot and all headers in the packages within the chroot are in no need of fixing. However, earlier in the package splitting process I noted that the fixed includes directory was actually in /usr/lib/gcc/$CHOST/... and not /usr/lib/$CHOST/..., so I fixed the PKGBUILD.

And here was the problem… As of GCC-4.3, the compiler installs a limits.h file into the private include-fixed directory and that directory is an absolute requirement. So, the unnoticed bug in the PKGBUILD actually was saving us from a far more severe bug and had been for some time.

The only conclusion I can draw from all of this is we should never strive for bug free code as some bugs are good!