I started out by visiting the BFO website and doing a bit of reading. The downloads page doesn’t really give you much info on how to proceed with BFO, so it’s best to check out the FAQ. BFO can be accessed in one of two different ways.  You can either download a boot image for some physical media (CD/DVD, USB and Floppy (!) images are available), or you can boot BFO directly from GRUB. The physical media images are of course pretty tiny since you’re not downloading the whole distro, just enough stuff to boot from the network. However, one of the attractions of BFO for me was to do away with physical media all together and so I went for the GRUB option.

In order to boot BFO via GRUB you obviously need to have GRUB installed as your bootloader. This shouldn’t be a problem if you are upgrading from an existing Linux install. To install BFO you run the following commands (as root) from the BFO FAQ:

wget -O/boot/bfo.lkrn http://serverbeach1.fedoraproject.org/pub/alt/bfo/bfo.lkrn
grubby --add-kernel=/boot/bfo.lkrn --title="Boot BFO"
reboot

This will add a new “Boot BFO” entry to your GRUB config and reboot your machine. Technically, you probably don’t want to reboot immediately since you should check that you have a decent length menu time out for GRUB (edit the ‘timeout’ line in /etc/grub.conf and run the ‘grub’ command afterwards).

Once I had completed these steps and rebooted, I was able to access the GRUB menu by pressing ESC. I then selected the new menu entry and proceeded to boot BFO. At first I got an error because my machine couldn’t get an IP address from the router. I had suspected this would happen since I don’t have the ethernet plugged in and these things usually don’t like wifi. I went searching for my long ethernet cable and everything worked on the second try. After a bit of loading (presumably downloading stuff) I was presented with another boot menu, which asked me what I wanted to boot. I selected the Fedora 15 x86_64 installer. BFO then started loading the kernel and initrd images for this (it took a while).

Once the installer booted up it was very much like the normal Fedora installer (in fact it is). I was able to go through all the usual stuff like partitioning, etc. Once nice feature of this installer is the package selection screen. This lets you install groups of packages (like ‘Games’ or ‘Software Development’) as well as individual packages. I can only think that this is a feature of the full Fedora DVD installer which is why I haven’t seen it before (I’ve only installed from Live CD previously). Happily, it enables you to get a much more functional system out of the box rather than the fairly bare Live CD install (for example it installed LibreOffice by default).

Once I’d finished making my package selections the installer started formatting the drives and installing packages. This was significantly slower than the Live CD install since it had to download and install each package separately (rather than the disk-dump approach taken by the Live CD installer). Once this was complete I rebooted and filled in my user details. I then had a fully functioning Fedora 15 install.

My Verdict:

My experience with BFO has been overwhelmingly positive. The install is significantly slower than a Live CD install, but when you factor in all the time that is saved by not downloading an burning (and reburning!) ISO images it’s probably about the same. Everything worked perfectly for me. except the previously mentioned wifi/ethernet issue which was more my fault than a BFO problem. The only improvement I could suggest is that the commands I mentioned above could be wrapped up into an RPM package and made available in the Fedora repository so they are available for everyone very easily. This would make the whole system very polished and easy to use.

Overall, I would highly recommend using BFO for your next Fedora install. It really beats any other install method I’ve used to date.

Download SwallowCatcher 0.2.0

After what seems like ages I’m proud to release a new version of SwallowCatcher – version 0.2.0, codenamed “The Black Knight (Come On Ya Pansy!)”. The reason behind the version number jump is twofold: 1. Bigger numbers are better, 2. I think the new features in this version and improved stability warrant a new version. Notable new features in this release include support for more URL schemes, cover art support and the ability to browse show notes from directly within the app.

I’ve had several contributions to this release both in the form of  bug fixes and in code and artwork. In particular I’d like to thank Nick Clark (@nrlucre on identi.ca) for contributing a great icon and Luke (~nobugs on Gitorious) for contributing bug fixes and adding itpc:// and pcast:// URL scheme support. Also, thanks to everyone who’s given me feedback and sent me bug reports.
As always, please check out the project page and the gitorious page where you can download the source code. Feedback and bug reports can again be submitted via identi.ca, email or via the comments on this post.

Email. We all use it. It works, right? Well for the most part. It’s probably one of the most used and simplest forms of digital communication available today. Shame it’s so horribly complicated then.

My major task over the last couple of weeks has been getting my new server set up so that it hosts my own email and provides accounts for members of my family. I’ve actually been doing this on and off pretty much since I got the server, but with the release of CentOS 6 I decided to cut my losses and upgrade sooner rather than later.

So I set out installing Postfix and Dovecot, following the instructions on the CentOS wiki pages. I managed to get through all the configuration of Amavisd, ClamAV and Spamassasin and I installed Roundcube for webmail access. Then I started thinking about adding users for my family and came to the decision that I didn’t want to add shell users for every email account, so I would modify my set up to incorporate virtual users and domains. After following a dead end of setting this up using plain text files (which turns out to be more fiddly to administer than shell accounts) I settled on using Postfix.admin with a database based system. Then there were my adventures with sieve, managesieve and Roundcube, which turned into a whole afternoon of getting nowhere.

Now my gripe here isn’t with the software. Far from it, all the previously mentioned software is excellent. Nor is it even with the documentation, although that is lacking in some areas, usually a quick web search will find you a useful forum post. No, my problem here is that I had to do all this in the first place in order to set up a Autonomous Free Software based mail system.

Given that I did this partly for the fun of it (yes I appear to like the pain of making tea), this isn’t really a problem for me. When I changed over my DNS everything pretty much worked, but I’m not your average user. Now, I know there are things like iRedMail, which can automate all this stuff and if I hadn’t wanted to learn how a mail system works I probably would have tried it. However, I’m skeptical as to the reliability of such a system.

This brings us to the crux of the problem. Email is too complicated! Think about all those disparate components I listed above, each of which is developed separately and has to interact seamlessly in order for the system to keep going. If one breaks, you’re screwed. I think this is probably worse in a iRedMail based system as the administrator would have no expertise in the inner workings of the system.

This leads me to my actual point (finally!). This is why people use Gmail, Hotmail, etc. It’s not because they would otherwise have to provide their own hosting, it’s because these services make it easy. I think what I’m basically asking for is “WordPress for email”. Something I can just unpack point it at a database and go, without having to know an what an RBL is. Yes, this wouldn’t be as easy as Gmail, but Blogger or Tumblr are easier than self-hosted WordPress and there are still tons of WordPress blogs out there. It would put Free Software based email within the reach of the ordinary computer literate person.

My fear is that the Free Software community treats email as a largely solved problem. We have loads of great software, which works for those of us with beards. However, until we make it easy to use, simple, cohesive and pretty, email is destined to languish in the land of the non-Free.

I started out by creating a new Activity class and a layout XML file for it. The layout XML was taken almost directly from the Android WebView Tutorial page:

<?xml version="1.0" encoding="utf-8"?>
<WebView  xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/shownotes"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
/>

In my Activity class the XML is loaded as normal. We also need to import the WebView class and the URLEncoder class. Additionally, the UnsupportedEncodingException class is required:

import android.webkit.WebView;
import java.net.URLEncoder;
import java.io.UnsupportedEncodingException;

Next, we need to encode the text in the correct format. Weirdly, WebView requires that the text is URL escaped, but without spaces converted to ‘+’ symbols. I used URLEncoder to encode my content then replaced the ‘+’ symbols with spaces. This probably isn’t perfect, but for my purposes it works.

String text = "<html><head></head><body>Content goes here!</body></html>";
text = URLEncoder.encode(text, "utf-8");
text = text.replace('+', ' ');

Finally, we find the WebView from the XML and tell it to load the string as its content:

WebView web = (WebView)findViewById(R.id.shownotes);
web.loadData(text, "text/html", "utf-8");

All the above is encased in a try..catch statement for UnsupportedEncodingException, just in case the URLEncoder has a fit. That’s pretty much it. In SwallowCatcher the ShowNotesActivity is 56 lines, including all the verbose Java imports and bootstrapping and loading the content from the database via ORMLite.

As a wise action hero (and ex-Jedi) once said, “I love it when a plan comes together”.

That is until today, when I discovered the ‘qrencode’ utility. Qrencode does exactly what it says on the tin. It takes some text, encodes it as a QR Code and writes the result as a PNG file. It’s a simple command line tool, which opens up awesome scripting possibilities.

My use case is simply to send the URL of a web page that I’m viewing on my desktop to my phone, via QR Code. I found that qrencode was quite happy to write its output to stdout, which meant I could display the result directly using ImageMagick’s ‘display’ command, e.g:

$ qrencode http://blog.webworxshop.com -o - | display

You’ll notice that by default the QR Code is quite small. We can fix this by increasing the block size:

$ qrencode http://blog.webworxshop.com -s 10 -o - | display

Next, I wanted to automatically pull the text to encode from somewhere to save typing – the clipboard was an ideal candidate. Enter ‘xclip’. Xclip is a command line utility to read and write from/to the X system’s built in clipboard. I used bash’s backtick command substitution to grab text from the clipboard and encode it:

$ qrencode `xclip -o` -s 10 -o - | display

And there you have it, a simple one line command to generate and display a QR Code from the contents of the clipboard. I created a bash script containing the command and assigned it to a keyboard shortcut in Gnome (Ctrl-Shift-Q), so that sharing URLs to my phone is as simple as selecting the text in the location bar and hitting Ctrl-C followed by Ctrl-Shift-Q.

If you want to give this a try, you’ll need to install the utilities discussed, in Fedora these can be installed with:

$ sudo yum install qrencode xclip ImageMagick

Enjoy!