I discovered Linux in about 2001. Weirdly, I was in Tanzania at the time and didn’t have a PC of my own to install it on. That had to wait until 2003, when, as a postgrad on a tight budget, I bought a cheap, ex-corporate Dell Latitude laptop. It had one USB 1.0 port and no built-in ethernet. Yes, it was a longtime ago.

A truly amazing range of laptops, they had a modular drive system, which meant I was able to get a zip drive relatively easily. And that was important because at the time you needed a SCSI card on a desktop to connect to most Zip drives. And I needed Zip for my GIS course. Big files.

Laptops, at that time, also relied heavily on PCMCIA cards for commuincations, be that 56k fax/modems, ethernet or, gasp, wireless.

I imagine most people have their “hardware geek” phase a little earlier than I did. Over the course of 2003/4 I had a fantastic time shopping on eBay for bargain laptop drive modules and various comms cards. They all had to be Linux compatible so lots of careful research was required.

Fast forward to today. Well, I still have loads of this stuff, including the PCMCIA cards shown. I haven’t had a laptop that would support them for about two years. Why have a kept them?

Mainly, I convinced myself that they had some value to someone. Until recently, I had no idea why. Then I started thinking about why I was finding it so hard to get rid of them.

I realised that I felt that, somewhere, there was someone that would get as much pleasure from fiddling with this tech as I did in 2003. At the very least I thought by keeping them I might at some time recapture that “golden” time in my life.

In reality, these things are technologically worthless and ten a penny on eBay and my personal circumstances have changed beyond recognition. I barely have time to write this blog, let alone tinker with ancient technology for hours on end. Also, even if I had the time and the hardware to fettle with, I don’t know if I’d even enjoy it! I have moved on in so many ways.

So, now I know why they were important to me, I do need to let them go. They’re a physical reminder of time that can’t be recaptured and shouldn’t be. It’s better to remember that time fondly, than imagine it might some day come back.

And, besides, if such hazy days did return, in say, 25 years, they’ll be way better things to tinker with!

I’m running Arch Linux ARM on my Pi and I just had WAY too much trouble getting distcc working.

First, my most idiotic mistake was not having distcc installed on the master (the Pi). I know how that happened. I was going to install and decided to -Syu first, then forgot.

Secondly, I was trying to get it to work using the makepkg method, as opposed to the standalone method. What’s the difference? That brings me to…

Thirdly, the guides I was using aren’t great.

What you need to know

If you are trying to cross-compile using distcc on a Raspberry Pi you will almost certainly end up here: https://archlinuxarm.org/wiki/Distcc_Cross-Compiling

Note the warning at the top: “This guide will appear vague and incomplete if you aren’t sure what you’re doing. This is intentional.” That’s rubbish. It’s just very badly written. The only knowledge of “compilation and toolchain components” needed to understand this guide is that the toolchain needs to be installed/built on the client. That’s it.

Once you’ve read the dire warning you are directed here: https://archlinuxarm.org/wiki/Distributed_Compiling

Don’t go there now. The rest of the page is about setting the client up, finish that first.

The biggest problem with this guide is it doesn’t adequately explain just how much of the guide you can skip if you use WarheadsSE’s distccd-alarm package. The fact that WarheadsSE doesn’t explain this in README on his github doesn’t help either. Basically, WarheadsSE’s pkg does everything.

As explained in the guide, WarheadsSE’s pkg builds a toolchain for each ARM architecture and puts them into separate packages. So, build his pkg on your client machine (X86_64 only) and install the pkg for the toolchain you need. For me and my Pi it’s ARMv6l hard.

This package automatically creates the symlinks described in the “Make nice with distcc” section. Further more, it creates it’s own conf file at /etc/conf.d/distccd-armv6h (obviously depending on your ARM architecture). This contains the correct $PATH variable and is sourced automatically when distcc is run on the master. No need to edit /etc/conf.d/distccd at all. You will have to set the allowed hosts in /etc/conf.d/distccd-armv6h, though.

Next, read the recommended guide to setting up the master (https://archlinuxarm.org/wiki/Distributed_Compiling). At the bottom you’ll move to configuring the client but the other guide has already taken you through that step. All that remains is to start the systemd service on the client.

Troubleshooting

I tried to troubleshoot using the makepkg build method. What’s that? Well, it’s the only method explained in the Arch Linux ARM guides. It basically means you use makepkg to run distcc. This is what you want to do in the long run but the error handling is rubbish. So, instead, go and have a look at this guide: https://wiki.archlinux.org/index.php/Distcc

This guide explains how to run distcc without makepkg aka “Standalone” method. Short version:

1) add your client IP address to /etc/distcc/hosts on the master
2) create file on the client called hello_world.cpp and paste this into it:
// 'Hello World!' program

#include <iostream>

int main()
{
std::cout << "Hello World!" << std::endl;
return 0;
}

3) run this distcc g++ -c hello_world.cpp

Now you can see what distcc is trying to do. For me it showed that connection to the client was refused. Obviously (duh) I needed to open a port in my firewall on my client. With that done it just built.

Now you can go back to using makepkg -A.

pacman, the package manager that was created as fundamental feature of Arch Linux, has a long and successful development history. The pace of development might not be speedy but it’s always been very sensible.

Recently install hooks were introduced to pacman. In short this means, for example, that rather than each font package updating the font cache itself, the font cache is updated once when all the font installations are completed. It’s not ground breaking but it’s a neat, tidy and important solution.

However, I was bit concerned when the post-install script that builds the kernel initramfs wasn’t one of the first scriptlets moved to a hook. I was further dismayed when a discussion on arch-dev-public suggested that some developers might not see the point of doing so.

Part of the fun I have with Linux is fixing things. It probably doesn’t sound like fun but it can be a challenge that rewards with knowledge. However, when the problem is that you can’t boot, well, that’s no fun. It means rescue disks and chroot, and a second box to look up solutions on.

The most frequent cause of a non-booting Arch Linux system (after an update) is not having read the recent News Announcements or followed post-install messages. One time, though, I just got really unlucky. A module that needed to updated in the initramfs was installed after the kernel had been updated and the initramfs had already been rebuild. That really sucked. Since then I have rebuilt the initramfs manually after every system update has completed.

So, I was actually very relieved, when other developers did see the point of moving the scriptlet to a hook. This doesn’t fully solve the problem because that hook still needs to run after other hooks to be as bullet-proof as possible and the current process didn’t seem to support that. Fortunately, this was identified too.

Awesome.

This is great example of open source development going right. Too often it disintegrates in to disagreement and death by committee.

This took me ages to find. I started off messing with Xmodmap until I realise GNOME would ignore it.  I finally found the solution here.

navigate to org >> gnome >> desktop >> input-sources

Put your options under xkb-options as a list. Ex: [‘altwin:ctrl_alt_win’,’caps:backspace’]

I hope that I can help others find it faster!

Then

I’ve been using Arch Linux for years. It’s been my main Linux distribution since I decided I needed to switch from an i586 optimised system to an i686 optimised system. Yes, it was that long ago. To be honest, I’m astonished my original distribution is still going but I’m really pleased for them!

When I first got interested in Linux it was because of a distribution called Mandrake. Back then KDE and the Keramik theme were all the rage. It was all so refreshing compared to Windows.

Anyway, I could never really get on with those big desktop managers. With KDE I always wanted some GTK apps (firefox) that ruined the look and Gnome, well, back in the day the word was “cruft”, it was full of dependencies and apps you just didn’t want. Plus it was butt ugly.

The first window manager I really got into was Fluxbox. I even made some popular themes for it. I’d always liked Xfce but, like Gnome and KDE, it still wasn’t very cohesive. At some point Xfce must have grown-up because that became my standard desktop environment from at least 2007. That was probably down to Xfce 4.4.0!

With hindsight, I was lucky to find Arch Linux early on in my Linux experience as I never even considered trying Ubuntu when it was created. Back in 2003 Gentoo was the cause of most flamewars on the Arch forums.

So, my first experience with Ubuntu was around the last noughties when a laptop with an OEM of Windows XP went kaput and we needed an OS. I was pretty pleased with it. It always ran well on the laptop and I didn’t need to mess about with it too much. It almost never went wrong. I went off it a lot when Unity came on the scene but the laptop died permanently shortly after, so I was never really forced to look for an alternative. I always kept half an eye on Ubuntu, though.

Now

A few weeks ago I was at a conference in London for CiviCRM (which is an open-source CRM used by a lot of charities and not-for-profits.) Almost all of the presenters were using either Macbooks or Ubuntu laptops. A few guys from CiviCOOP were also running what I surmised was Gnome so I asked them about their set-up. They simply said it was Ubuntu Gnome and I decided I’d check it out.

As you might know both Gnome and Ubuntu have recently made major releases. I guess Gnome didn’t freeze early enough to make it into Ubuntu’s release window so Ubuntu Gnome still ships with the previous version.

So, yesterday, I decided to try and install. I started out by making sure that the installation wasn’t going to mess with my Arch install. That meant revisiting my bootloader configuration and moving /boot back into the Arch root. Then I had a huge balls-up where I deleted everything in my ESP with some sloppy typing. Yay, me! So out came the Windows disks to restore the Windows EFI bootmgr and, bleurgh. Mission.

Once that was finally sorted (and, as is so often the case with Linux, improved) I got around to installing Ubuntu Gnome in some free space on my Windows drive. I was pretty disappointed. I quickly realised that it was going to a struggle to get the system set-up how I liked; I have so many long forgotten customisations in Arch that I take for granted. Also, the Ubuntu software centre was just weird. There were two versions of Vim and I couldn’t tell what the difference was. Gnome itself was also really unstable; it hanged on me a few times and some widgets vanished, making the UI tough to interpret. However, what really put the tin hat on it was trying to change the Gnome icon theme. I couldn’t find any to install in the software centre and the advice I found while Google was to extract packages straight into /usr! Urgh! That’s like recommending incest!

I decided that Ubuntu wasn’t for me after all and decided to give Gnome a go on my Arch install, especially when Arch is noted by the Gnome Project as already shipping the latest version. It didn’t make long to get it sorted. I’d already decided, while out a on run last night, that I was going to convert wholesale to the “Gnome way” and swap to gdm and NetworkManager.

I can honestly say it’s the most complete Linux desktop experience I have ever had and I think I’ve only scratched the surface. It’s all worked out pretty well in the end!

Send to Mail Recipient in Thunar always gives me this error.

Image

I’m sure I have Googled for a solution this many times before but never found one.  Today I did.  It’s simply that exo depends on perl-uri to complete this action.  It’s even an optdepend in Arch:

 Optional Deps : perl-uri: for mail-compose helper script

See, so

 pacman -S perl-uri

fixes it with no further effort.

Arch Linux has had some major changes recently and this has made updating a neglected installation a bit tricky.

However, I managed a flawless update on a system that hasn’t been touched since May.

Before you do anything, go to the Arch Linux news page and read everything since your last update. If a package needs manual intervention make sure you add it to –ignore list when the time comes.

Firstly, you want to get setup for the new /lib symlink. There is a guide here – however, you will need to ignore some other packages as well. The main goal here is to stop pacman from breaking:

pacman -Ud http://pkgbuild.com/~allan/glibc-2.16.0-1-i686.pkg.tar.xz
pacman -Syu --ignore glibc,curl,libarchive,bash,gpgme,filesystem,fontconfig

So, we’ve installed Allan’s special glibc version and we’ve updated the whole system while ignoring all of pacman’s dependencies. I also ignored filesystem and fontconfig as they need intervention. You will almost definitely be asked to upgrade pacman first and foremost. Do that when offered.

Next I updated the filesystem package:

pacman -S filesystem --force

Then I updated all of pacman’s deps:

pacman -S glibc curl libarchive bash gpgme

Lastly, I fixed the conflicts for the fontconfig package and did another system update.

find /etc/fonts/conf.d -type l -exec rm {} ;
pacman -Su

Word of caution – once your system is up to date and make sure you update the initramfs, just in case.

mkinitcpio -p linux

You will also have to upgrade to systemd compatible settings. Next post is about how I handled that.

Last night I was trying to install mysql on my Arch Linux netbook. Now, this would not be note worthy but for the fact it was going badly. The post-install of the pkg .install script is supposed to do basic set-up so you’re ready to go out of the box. However, it failed with a disk full error.

Hmmm. The netbook has at least a 300Gb disk, would an Arch install really fill that? So, I ran

df -k

And, yes, it showed 0 free space.

Weird. But pacman checks for free space when it installs a package, so when I installed mysql the packaged files miraculously fitted in and used up the remaining space? That seems unlikely.

I uninstalled and reinstalled the package several times (it was late) and when I kept getting the same error. Not exactly the most efficient troubleshooting (it was late). My main instinct was to jump on the forums for help and to tacitly “blame the devs”. Instead I decided to call it a night (it was late).

So, this morning I thought “what can I do to quickly free up some space and check remaining space again?”

pacman -Sc
df -h

…ok, so my disk was full!

du /var

Not much

du /usr

Again, just a few gigs. Paranoia sets in.

du /

Whole thing is less than 5 gigs.

By this point I am suspecting it is something to do with my LVM setup and I head off to work with the intention of investigating on the train.

A small amount of reading and one command later

lvs

I can see that, for a reason I can’t rememeber, I made my root volume 5G. Maybe I didn’t understand what I was doing when I set up or maybe it seemed like enough at the time.

At least I know how to resize it now too!

This article was original posted by me on March 11, 2007 and could be found at: http://thewrecker.net/?p=181

After having spent a fair while looking for the solution to this I thought I’d post it here in the hope that google does more for others than it did for me.

My problem was that I couldn’t get the XFCE desktop to play nicely with conky; either conky or the desktop icons would keep disappearing. I knew the own_window settings in conky were the problem but could not find the right combination, however, these seem to work just fine:

own_window yes
own_window_hints undecorated,below,skip_taskbar
own_window_transparent yes

Now all I need to do is configure it so that it displays the temps from coretemps for my Core 2 Duo