Linux

Since I became a regular Linux user around 2003 I was a KDE user. I stuck with it on half a dozen distros along the way. On a whim, two weeks ago, I switched to Gnome and haven't been sorry, yet. This post specifically focuses on KDE within Kubuntu, compared to Gnome in Ubuntu.

Many of these are personal observations which have lead to my switch. It's a rant at times but I want to say very clearly that these comments concern the software and I appreciate the effort of all the volunteers on KDE and Kubuntu very much.

Why choose?

Most people from the community who I have met tend to prefer one desktop environment (DE) over another, or at least choose one and mostly stick with it. There are a plethora of choices when it comes to window managers, file managers and so on. Personally, I could never really appreciate the more bare-bones ones, such as Fluxbox, simply because it soon became too annoying to set up every little detail by hand.

More importantly, though, the underlying libraries in the DE often add additional benefits. For example, in KDE your address book could be accessed by the mail and IM application. Throw in a Gnome application and it has no clue about the address book, at least not without customization.

Many things have improved over the years, such as a common user notification method. The user, however, can often still assess quickly that one app simply does not fit when it is placed next to apps from another DE with different HIG. It's probably superfluous to mention that Apple excels so very well in this department.

Switching costs

When you consider moving from one of the main DEs to another, there are some opportunity costs. You will have to relearn ingrained tasks and shortcuts (e.g., hitting ALT+. reflexively in the Terminal window and nothing happens, is annoying) and finding appropriate replacements for each application. Nonetheless, if the perceived benefit from switching exceeds those costs, it should be worth it.

In my case, it was clearly worth it. From earlier short stints into Gnome-land I had the impression that I'd probably have to keep several KDE applications because I would be missing key functionality but it turned out that this was not the case.

Issues

It is difficult to disentangle Kubuntu from KDE here to see where the problems and thus reasons to switch originate. It seems to be a combination of several factors:

Community distribution:

It's plainly visible that the primary support to make Ubuntu a great distribution goes into the Gnome part. Kubuntu often has to adjust to architectural changes for a release, whether or not KDE upstream has caught up to those as well. This makes Kubuntu work less seamlessly. Examples: Pulseaudio, NetworkManager, Bluetooth, etc. It's probably also the toughest problem since Kubuntu as a distribution could probably not function, when detached from the rigid six month release cycle of Ubuntu. Apart from using a completely different distribution, such as Mandriva, I don't see a realistic solution to this.

Kubuntu's & KDE's priorities:

When KDE 4.0 came out I was excited and switched to it and stayed until 4.4.2. Initiatives like Plasma and Nepomuk are cool ideas. However, it really doesn't matter so much that the weather widget is pretty and the network widget is shareable if you can't get on the VPN without using vpnc & openvpn directly. Or if attaching an external monitor hard-locks Xorg (but Gnome has no problem), or half a dozen other issues every single day. 28 months after the official release of KDE 4.0 all these minor issues should have become a priority to make KDE a reliable DE in current distributions.

KDE's planning:

While there were release schedules and clearly plans for changing underlying technology such as Akonadi over the individual releases, a clear outcome seems to elude them. Ignoring for now the three iterations of indexing backends we went through with Nepomuk/Strigi, it's just not OK to have two embedded MySQL instances running solely to write an email and listen to music. Especially if upgrades result in core parts, such as Akonadi, crashing on each first start, no matter how many tutorials you try out.

In the future

Today, from my point of view, KDE is overbuilt and lacks stability as well as too many critical features for me to work effectively. I'd certainly consider going back at some point. I don't think this will be any time soon. Especially since the benefit from KDE's advances would also have to go beyond the switching costs, again.

Nonetheless, I'd like nothing more than to be proven wrong.

In the first part we created a list of things we want to block on occasion. The point of this part is to make it easy to switch from full access to limited access. Enter, OpenWrt.

OpenWrt

A large chunk of wireless routers on the market today can not only run their stock firmware but also OpenWrt. It's useful for creating wireless mesh networks and all sorts of things but the most common task is just a free-as-in-speech router. There are countless tutorials online for installing it and resources for which devices are supported, so I'm not covering that here.

Apart from being able to SSH into your router, OpenWrt now exposes many things such as buttons and LEDs, which you can use in your scripts. These examples have been tested with Kamikaze 8.09.1. In older releases, several things were elsewhere, such as /proc/diag.

Tinyproxy

Due to the size limitations on many models and feature limitations on certain solutions I ended up using Tinyproxy. Definitely also install the luci package for Tinyproxy, it makes setup a lot quicker. Due to several smaller bugs in the current releases it's probably still necessary to move the Busybox web interface from 80 to 8080.

At this point, you should let Tinyproxy listen on your router's IP on port 80. Also allow access from your subnet and 127.0.0.1. Most often this will be 192.168.1.0/24. Finally upload your filter list and turn your proxy on.

Due to the way the current OpenWrt releases works this will not yet router your traffic through the filter. Also, if Tinyproxy doesn't seem to start properly, make sure the logging directories are also present.

Putting it together

All that's missing is a script, to run once a button is pushed, let an LED blink as long until it is pushed again and toggle routing the traffic through the proxy.

My script is largely based on a howto from the OpenWrt wiki (as is much in this second part). It uses the SES LED and works with a Buffalo router running a 2.4. kernel due to the wireless drivers (otherwise iptables redirect could be used). Placing it into /etc/hotplug.d/button/, for example as 01-nettoggle, should make it work. Though you'll probably have to adjust LEDs, buttons, and maybe also the router IP.

Now have fun with tricking that dumb part of your brain into getting things done, to paraphrase Merlin Mann.

The dilemma

This semester I had a handful of exams rather late in the year, weeks after classes ended. Now, the Internets are a pretty interesting place and I find it extremely difficult to not glance at the feed reader and all the other gizmos rather often, when in front of the screen. I saw three possible solutions:

a) Work analog. (Pretty unrealistic, and think of the poor trees…)

b) Force yourself to not get distracted. (Sounds as likely as most New Year's resolutions.)

c) Turn off only the distractions, or at least minimize them.

Naturally, I went for C. It gave me an excuse to go write the scripts for it. The first attempt consisted of a list of domains added to /etc/hosts on my main machine. It worked, but just blocking domain names often gives inconsistent results in respect to subdomains and other problems.

I have split this tutorial into two parts to make it more readable. The first part deals with collecting domain names, the second with filtering them by hitting a button on an OpenWrt router.

Collecting URLs

Many programs dealing with RSS today will often export to OPML (just an XML file) and manipulating these with XmlStarlet works great. Let's try it on Miro. We have a list of outline elements, some are groups, some are feeds. The following will extract the URL from all outline elements.

xmlstarlet sel -t -m //outline -v @xmlUrl -n ~/miro_subscriptions.opml

Appeding | grep . should also get rid of the empty lines. Just repeat the procedure for the other XML variants your programs produce.

Without proper XML

Sometimes, even when an XMLish notation like HTML is used you get nonvalidating files. For example with Firefox bookmarks (other browsers do it, too). Tidy is an easy way to automatically fix those problems. The following will produce a validating bookmarks file.

tidy -asxml -o cleanbookmarks.html bookmarks.html

With this you can run it through XmlStarlet without problems. I adapted the following somewhat cryptic line from the XmlStarlet User Guide. Additionally, | grep -v "place:" removes the lines from Firefox which aren't URLs.

xmlstarlet sel --html -T -t -m "//*[local-name()='a']" -v @href -n -n a.xml

Getting domains

From the previous steps you now have a list of URLs. With these, you could already jump ahead to step 2 since the proxy in this project can also filter on URLs or patterns. If, however, you want to broaden it to domain names, there is one more step.

The following Python script takes two arguments, a file with URLs and a filename to write the domains to. Download it directly. Example usage:

./getdomains.py urllist domainlist

If you quickly look over the script, you might notice the four lines below. Since many sites have inconsistent uses of the www prefix, the script looks for all domains with a www prefix. If successful, the domain is added to the list with www and without. This does not cover any other subdomain.

domainshort=domain[4:]
o.write("%s \n" % domain)
if domain[:3] == "www":
    o.write("%s \n" % domainshort)

If you don't have OpenWrt, you can also download a version with two tiny changes to make the ouput readable by /etc/hosts. Just append your entries at the end of that file.

Upcoming

In the next post, we'll see how one can easily switch using this list on and off with a button, rather than meddling with configuration files each time.

If you have an amplifier (or something similar) with a remote and your computer attached to it, there are probably several buttons that don't do anything in this configuration. In my case, it's the buttons available to control a CD or tape deck. Wouldn't it be neat to repurpose those?

In short, all you need is an IR receiver, LIRC and a handful of commands. There are already quite a few tutorials on the net for doing this but many are a bit dated and so I think this post still brings something new, if simply by addressing installing LIRC on Ubuntu Jaunty to use Amarok 2.

IR Receiver

First off, get an infrared receiver. I got a serial one off of ebay very cheaply, just search for "lirc." You can often reuse receivers from other gadgets, LIRC is quite flexible that way. Let's now begin with a plugged in receiver but nothing else. How do you know it's even working?

First, load the appropriate module. In my case, lirc_serial. You could let the LIRC script load it but /etc/modules works just as well. Put the model name for your remote in /etc/lirc/hardware.conf, start /etc/init.d/lirc and you should be mostly done. The command irw should now return correct values for the remote on individual button signals. If the device cannot be found, consider running the command with root privileges and make sure the LIRC device exists. In Ubuntu, you often have to reference /dev/lirc0 because /dev/lirc is the default many scripts assume.

If your remote doesn't work, try adding it to /etc/serial.conf with "/dev/ttyS0 uart none", of course, adjust ttyS0 as necessary and consider rebooting.

Unknown Remotes

However, what do you do if your remote isn't in the list of remotes LIRC knows? No problem, LIRC can learn new remote signals, too. Just call irrecord and follow the on-screen instructions. After that you can move the resulting file to /etc/lirc/lircd.conf and the remote should work.

To complete the setup you still have to tell LIRC what to do when you press a button. There are several alternatives to settings things up but calling "irexec -d" from the autostart folder is probably one of the quickest. Irexec by default calls ~/.lircrc. Here is a short excerpt from my configuration, of course the button names of your remote might be completely different.

begin
prog = irexec
remote = abc123
button = play
config = dbus-send --type=method_call --dest=org.kde.amarok /Player org.freedesktop.MediaPlayer.Pause
end

begin
prog = irexec
remote = abc123
button = stop
config = dbus-send --type=method_call --dest=org.kde.amarok /Player org.freedesktop.MediaPlayer.Stop
end

Last.fm

Now, what was this talk about Last.fm earlier? Well, Amarok has decent support for Last.fm built-in and even has a little ❤ button on the main toolbar so you can favorite a song. You can easily call this feature over DBUS, too:

dbus-send --type=method_call --dest=org.kde.amarok /amarok/MainWindow org.kde.amarok.MainWindow.loveTrack

So, now you can flip through your music collection from your couch, skip a track and even favorite it in Last.fm without having to to use your computer. What could be improved? Lots. For one, moving to the MPRIS namespace in DBUS would make the whole thing more flexible, but I'm skeptical that it will ever support things like the ❤ button. Also, I tried org.freedesktop.MediaPlayer.Seek but it didn't work as expected.

The end of the semester is finally inching closer and one course in particular ended with a quite successful final presentation for our team of 3. The objective was to use several crates of Lego Mindstorms material to build a working model of two atm machines.

Rebooting ATM image is CC BY-NC-NA from n2b. Our ATM not quite identical to original.

And that's what we did. OK, not quite, our currency consisted of square wooden blocks (about 50mm*50mm*4mm) and our bank cards only contain a black and white strip that encodes a binary number. We reused some old credit card sized plastic cards and used the pattern on the right for the cards.

Then we built a PIN pad with a cut up connector cable, a project box, 6 buttons and a handful of resistors. Additionally, we had team members that were tweaking the construction until every single "bill" dropped perfectly. Then, all that was missing was an actual backend.

For this we simulated a database with an array (loaded from, and saved on exit to, a text file) and set aside one of the NXT control units to serve as the bank server. Then, our ATMs send requests as a string over the weird Bluetooth stack to the server and got a reply back, depending on the account's state.

Here is the end result. It comes in at just about 1200 lines of NXC code with support for German, English and French, as well as administrative functions on the bank to manage accounts.

Three more videos.