It’s been another year since the last Mageia release, and it’s successor is finally here. Improving on the already stellar Mageia 2, Mageia 3 contains all the standard package and kernel updates, along with the inclusion of Steam for Linux and other applications.

The distro was originally delayed due to various problems with installation, from hardware detection issues to booting problems depending on how and where you were installing it. The issues have apparently been fixed, with a list of bug fixes supplied on the release notes for Mageia 3.

You can download the final release of Mageia 3 from the website, and you can also read our review of the release candidate in an upcoming issue of Linux User & Developer magazine.

Follow @LinuxUserMag

Like the last Linux Mint release, Linux Mint 15 is quick on it’s feet after Ubuntu, with the release candidate out a few weeks after Canonical’s distro hit. While Ubuntu 13.04 itself didn’t really receive any major updates, Linux Mint 15 is bringing with it a whole host of new features and upgrades to the core system and its preferred desktop environments.

The MDM display manager now has three different main login applications, including one that’s written in HTML 5 for a new way to create animated and interactive themes. Cinnamon has a new screensaver mode which allows you to write a lock screen message for colleagues, and a few desktop widgets as well. MATE has received a small overhaul, updating a lot of its core, and there have been other updates to the software manager and driver manager.

The release candidate can be found on the Linux Mint website, and the final version will likely be a week or so away.

Follow @LinuxUserMag

Firefox’s rapid development has pushed the browser over version 20, with 21 out now. The new version comes with built-in Facebook messenger for Firefox, and new social providers such as Cliqz, Mixi and msnNow. These social additions are part of what Mozilla sees relevant to the current usage of the internet.

Firefox for Android now comes with Charis and Open Sans, open source fonts that they think will make the web “more beautiful and easier to read on a user’s small screen” according to a press release. There’s also HTML 5 compatibility improvement, done in conjunction with HTML5test.com.

You can update your browsers now on your systems and Android devices if you haven’t already.

Follow @LinuxUserMag

The Raspberry Pi’s camera has been talked about for a long time it seems, but it’s now finally able to be purchased for use with your Raspberry Pi. The Raspberry Pi foundation explained in their announcement post that the release itself was delayed for a further month while software was sorted out for the device.

The Raspberry Pi foundation have also release a video on how you can go about setting up your camera.

There’s also some step-by-step instructions on the Pi website. You can buy the Pi Camera board from Element14 now for £16.56 (~$25), and the RS Components website will be updated shortly with a way to purchase it.

Follow @LinuxUserMag

Linus Torvalds has announced the first several 3.9 kernel release candidates, following the closing of the 3.9 ‘merge window’ (period of time during which disruptive changes to the kernel and new features are merged). Merge windows are typically up to two weeks in duration (and seldom longer), though Linus has gone to great pains over the past few years to push developers not to post patches for inclusion at the very end of the window. Features merged into the kernel should instead have received heavy testing in the linux-next kernel and elsewhere, be largely complete, and posted for inclusion as early as possible during the two-week window of frantic development for a given release cycle. This is the theory, at any rate.

In his mail simultaneously closing the merge window, and also announcing 3.9-rc1, Linus said, “I don’t know if it’s just me, but this merge window had more ‘Uhhuh’ moments than I’m used to. I stopped merging a couple of times, because we had bugs that looked really scary, but thankfully each time people were on them like paparazzi on Justin Bieber.” Those features that made it into 3.9 include support for Synopsys’s 32-bit ‘ARC’ architecture (following a third posting of reviewed patches from Vineet Gupta), which is designed for use in embedded and DSP applications, particularly those wherein the ability to extend the CPU pipeline with custom instructions is beneficial (though this author notes that butchering a CPU pipeline comes with its own hidden costs and so isn’t something recommended for non- embedded applications).

Another very interesting new feature in the 3.9 kernel is support for Intel’s ‘PowerClamp’ driver. PowerClamp aims to constrain the maximum amount of power used by the system by forcing the CPUs to enter an idle state for a certain percentage of their operating time. At first glance, this may seem to be less than useless. After all, having paid good money for a powerful modern CPU (with multiple cores), most users expect to get all the oomph they can out of it. There are some users, however, where this desire is balanced by overall power constraints – in particular in data centres where there is a hard limit (often 10 or 15kW) of available power for a given rack of server equipment. Exceeding the power available to a rack can cause all of the servers in it to shut down, which is generally not what data centre users want. Google and others have encountered such problems over the past few years, and have used their own custom solutions to (presumably) good effect.

PowerClamp helps to generally solve the problem of hard-limits at the rack level by allowing an administrator or software management tool (‘agent’) to configure the system such that it will inject a certain number of idle states onto a given CPU. Typically, the kernel’s idle thread (idle task or idle process) will run only when there is nothing else to do. It calls a special machine instruction that will efficiently transition the processor into a lower power state from which it can be woken when there is work to do (usually through an external interrupt). In the case of PowerClamp, additional kidle_inject threads are created to run at specific times when there is a need to inject additional idle states (over and above the regular idle thread) in order to remain overall idle for the percentage of time configured by the user. Typically, PowerClamp will be used with some higher-level management software that looks to the whole rack and dynamically tunes many different systems for optimal overall power use.

Ongoing development

David Howells announced that “The end is nigh!” for his ongoing UAPI work. UAPI is a near year- long effort by David to clean up the kernel’s internal header files (source code containing definitions and small inline code functions typically included into kernel or application code), splitting out those parts that pertain only to the API (application programming interface) used by non-kernel ‘user space’ applications, such as the Bash shell or Firefox web browser. A typical Linux system includes many such header files within the /usr/include/linux directory. These are installed as part of compiling the kernel, during the ‘make kernel-headers’ stage.

Until now, the process of building user application usable header files involved selective copying of a limited number of kernel headers (most are not intended to be used by application code) and judicious use of special conditionals within those files to ensure the right thing would happen when they were used by non-kernel code. After David’s work, the ‘user- space API’ is more clearly defined and these pieces are separated out into files specifically intended for direct use by non-kernel code. David’s latest email suggests that only a few changes pertaining to video framebuffers remain “now that the SCSI stuff has gone in”.

Miklos Szeredi posted patches implementing a new ‘overlayfs’ file system. Overlay and Union file systems have been a topic of much debate for many years, particularly because they never seem to work quite right. The problem they generally attempt to solve is one of allowing several distinct file systems to be joined together, with the net result being a virtual file system (only existing as a whole at runtime) that contains selective pieces of each of its constituent parts. A typical use case is one of embedded routers or live CDs. Both contain some storage (flash memory or optical media) that is read-only, and some storage (on a RAM disk or a separate piece of storage – a USB stick, another flash etc) that can be written to. A special file system is then used to present what appears to be a selection of the content of both of these underlying stores. As files from the read-only media are modified or deleted, deltas are written to the separate writable storage instead (including special markers that indicate a file has actually been deleted). Unlike other efforts to do overlays, Miklos’s code tries to be as small as possible by generally passing through operations on open files to the underlying file systems as quickly as possible. It will be interesting to see where this goes.

John Stultz (of Linaro) has posted an RFC patch-in-progress that would pull support for Android’s sync driver into the staging tree. Staging is a part of the kernel source tree where experimental and not-quite-baked drivers can sit inside the kernel source while they are being cleaned up. These drivers are available only if specifically configured for use. The sync driver provides a collection of synchronisation primitives (code routines that can be used by other code to ensure operations happen in the correct order) for use with drivers that provide different parts of the graphics pipeline used with the Android SurfaceFlinger compositor.

Anton Vorontsov posted the latest version of a memory control groups (memcg) patch implementing memory-pressure-level event support. With this patch, applications that “want to maintain the interactivity/memory
allocation cost can use the new pressure-level notifications”. What this means is that it is possible for an application to be aware of the overall pressure a system is under for memory. When Linux runs low on available free memory, it will do one of several things. This includes failing new memory allocations, swapping out certain parts of applications to disk, and freeing up internal caches. All of these have a cost in terms of overall system performance (particularly when the system hits a point of swapping large amounts of data out to slow rotational disks and is said to enter a state of ‘thrashing’) that has not historically been easily visible to end software. Now, applications can easily monitor a special event file descriptor within a memory control group and be made aware of ‘low’, ‘medium’ and ‘critical’ levels of memory as well as set specific limits at which a notification will be given. This allows an application to take steps to release unneeded in-memory caches (such as web browser pages) before the system grinds to a crawl.

Follow @LinuxUserMag

Today, we’ll be learning how to use a Raspberry Pi to act as a Bluetooth keyboard, and writing our own program to relay input to the client device. This will provide a useful insight into how a protocol like Bluetooth works, how sockets work, and how data is sent across simple protocols. We’ll also be learning a little bit about binary data and the different forms that it can take.

We’ll be using the latest Raspbian image as the operating system for our Raspberry Pi- based Bluetooth keyboard. The instructions for flashing an image to an SD card can be found on our original tutorial. You’ll only need to go up to the step where you write the image to the SD card. You’ll have to adapt the instructions slightly for using the latest Raspbian image rather than the Debian one. The image we used was‘2012-12-16-wheezy-raspbian.zip’.

There are multiple ways that you can do this tutorial depending on how comfortable you are with working in a console-based environment. For example, our expert did this tutorial over SSH. If you don’t want to do that then you could do it from the console on the Raspberry Pi, or use the LXDE environment, but you’ll need a USB hub because you’ll need three USB devices: a keyboard, mouse and Bluetooth dongle.

Resources

A Raspberry Pi with all necessary peripherals

A USB Bluetooth dongle

A USB hub – if you want to use a keyboard and
mouse at the same time as the Bluetooth dongle

A device to connect the virtual keyboard to – Liam tested it on an Android
smartphone and his Linux computer

PiTooth

Step by step

Step 01

Setting up the Pi

You’ll need to connect a power cable, network cable, the Bluetooth dongle and a USB keyboard. You’ll also need to connect a screen for the initial configuration and can use SSH from then on. Alternatively, you could use a console-based environment on the screen. If you want to use the LXDE environment then you’ll need a screen and mouse. Raspbian will boot and a configuration menu will be displayed. Choose the option to expand the root file system, as we need to install quite a few extra packages. Once you’ve done that, select Finish and then Yes to reboot the device.

Step 02

Logging into the Pi

A message will be displayed with the current IP address of the Pi during the boot process of Raspbian. This will be useful if you are using SSH, which is enabled by default on the latest Raspbian image. Open up a terminal on your Linux computer and type:

ssh pi@[your Pi’s IP address].

Type yes when asked if you want to connect and then enter the password raspberry. Alternatively, simply type the username pi, and password raspberry at the login screen.

Step 03

Installing the required packages

You need to run the following commands to install the required packages:

sudo apt-get update

sudo apt-get install python-gobject bluez bluez-tools bluez-firmware python-bluez python-dev python-pip

sudo pip install evdev

This may take a while to process, especially the second command.

The first command updates the list of packages available. The second command installs the required Bluetooth packages, as well as Python bindings for them. The remaining two packages are needed for installing a Python module called evdev, to capture keyboard input, that isn’t yet in the Raspbian package repositories. Instead, we need to have the Python development package present and use pip (a Python package manager) to compile the evdev module from source and then install it.

Step 04

Disabling the default Bluetooth plug-ins

By now, we’ve installed the Linux Bluetooth stack, BlueZ. By default, it comes with a bunch of services enabled that we don’t need and it will make debugging much more difficult if the need arises. You can see the list of default services using the command:

sudo sdptool browse local

The configuration file we need to edit is /etc/ bluetooth/main.conf. You can open that file in the nano editor using the command sudo nano /etc/bluetooth/main.conf. You need to change the following line:

#DisablePlugins = network,input

to…

DisablePlugins = network,input,audio,pnat,sap,serial

Then save the changes using Ctrl+O, followed by pressing Enter and pressing Ctrl+X. You need to restart the Bluetooth daemon for the changes to take effect. You can do this using:

sudo /etc/init.d/bluetooth restart

You can use

sudo sdptool browse local

to verify that there are no services remaining.

Step 05

Starting the project

It’s about time we got started on some code, so let’s create a project folder. Change directoryto/home/piusingcd /home/pi and make a directory for our project using the command mkdir PiTooth. You can then change into the PiTooth directory and make a project file using the command touch PiTooth.py. Make it executable using the commandchmod +x PiTooth.py.

Open the file in the nano editor and start the file with the line:

#!/usr/bin/python2.7

This tells the shell that it needs to run the using the Python 2.7 interpreter.

You can also add a short comment about what the program does:

#!/usr/bin/python2.7
#
# PiTooth allows the Raspberry Pi to act as a Bluetooth keyboard, and relays
# keypresses from a USB keyboard to a Bluetooth client. Written by Liam Fraser
# for a Linux User & Developer tutorial.
#

Step 06

Downloading necessary files

There are a couple of files that are needed for this project to work. You could create them yourself, but it would involve spending quite a lot of time reading various protocol specifications like our expert had to do to put this tutorial together. It’s outside of the scope of the tutorial. It will become clear what these files are used for shortly.

Save the changes to the file that you’ve made so far and exit nano. Download the required files using the command wget http:// liamfraser.co.uk/lud/PiTooth- Resources.zip.

Unzip the files from the zip archive using the command unzip PiTooth-Resources.zip. Use ls to verify that the new files have appeared. Once you have done this, you can remove the zip file using the command

rm PiTooth-Resources.zip
pi@raspberrypi ~/PiTooth $ ls keymap.py PiTooth.py sdp_record. xml

Step 07

The imports

It’s time to get back to nano. Our first job is to import the modules that we need, and there are quite a lot. We’ve placed a comment next to the non-obvious ones to explain what they are used for. SDP stands for Service Discovery Protocol. It will become clear what SDP and D-Bus are used for shortly.

import os # Used to call external commands
import sys # Used to exit the script
import bluetooth
from bluetooth import *
import dbus # Used to set up the SDP record
import time # Used for pausing the process
import evdev # Used to get input from the keyboard
from evdev import *
import keymap # Used to map evdev input to hid keycodes

Step 08

The Bluetooth class

We’re going to start our Bluetooth class with an initialisation function as usual. Remember that we’re not using a fancy development environment here, so you need to take care to format your code properly. Our expert typically uses four spaces to indent rather than a tab, as spaces are the same in every editor. We’re going to start off by preparing the Bluetooth dongle for use as a Bluetooth keyboard. We’ll do this using the hciconfig command, which is essentially the equivalent of ifconfig for Bluetooth devices.

So, we set the device class, which is a hexadecimal value representing a keyboard. We then set the device name to Raspberry Pi, replacing the space in the name with a backslash. Finally, we make the device discoverable so that other devices can pair with it.

class Bluetooth:
    def __init__(self):
        # Set the device class to a
keyboard and set the name
        os.system(“hciconfig hci0 class 0x002540”)
        os.system(“hciconfig hci0 name Raspberry\ Pi”)
        # Make device discoverable
        os.system(“hciconfig hci0 piscan”)

Step 09

Bluetooth sockets

Bluetooth HID devices use two sockets to communicate: a control socket and an interrupt socket. The control socket is for initiating the connection, sending handshakes and so on. The interrupt socket is used for sending low-latency data, such as input reports containing key presses, or output reports such as vibration feedback if the device were a gamepad. The standard ports for these sockets are 17 for the control socket and 19 for the interrupt socket.

Before we create the sockets, we’re going to declare a couple of constants to hold the port numbers. The constants can be put outside of the initialiser function as they will be the same for every instance of the class. The beginning of the Bluetooth class should now look like this:

class Bluetooth:
    # Define the ports we'll use
    P_CTRL = 17
    P_INTR = 1

Step 10

Create the certificates

We’re back in the initialisation function now. Once we’ve set up our Bluetooth dongle, we need to create a couple of sockets upon which we can accept connections from clients. We also need to bind them to the appropriate ports. L2CAP is simply a type of Bluetooth socket. When binding the sockets to a port, we pass through a tuple with the MAC address of the Bluetooth dongle to bind the socket to, which can be omitted because we only have one, and the port to bind the socket to. Notice that we access the port constants using the class name, rather than prefixing them with self, because the constants are class members rather than instance members.

# Define our two server sockets for communication
self.scontrol = BluetoothSocket(L2CAP)
self.sinterrupt = BluetoothSocket(L2CAP)
# Bind these sockets to a port
self.scontrol.bind((“”, Bluetooth.P_CTRL))
self.sinterrupt.bind((“”, Bluetooth.P_INTR))

Step 11

Using D-Bus

D-Bus is a framework used commonly on Linux that allows communication and remote procedure calls (calling a function in a different program) between different processes. The BlueZ Bluetooth stack exposes a D-Bus interface which allows access to a couple of things that the Python module doesn’t.

We’re going to use D-Bus to advertise a Bluetooth SDP record. SDP stands for Service Discovery Protocol. This record advertises the virtual keyboard and various information about it, such as the structure of the input reports (which are sent when a key is pressed) and also things such as the language of the keyboard. You’ve already downloaded an SDP record that our expert made earlier, as these are really outside of the scope of this tutorial.

We’re enclosing our D-Bus code with a try- except block because it could go wrong, and so it’s useful to include error messages. We start by getting an org.bluez.Manager interface, and the path to the default adaptor. With that, we can get the service interface for that adaptor, which is used for registering SDP records.

        # Set up dbus for advertising the service record
        self.bus = dbus.SystemBus()
        try:
            self.manager = dbus.Interface(self.bus.get_object(“org.bluez”, “/”), “org.bluez.Manager”)
            adapter_path = self.manager.DefaultAdapter()
            self.service = dbus.Interface(self.bus.get_object(“org.bluez”, adapter_path), “org.bluez.Service”)
        except:
            sys.exit(“Could not configure bluetooth. Is bluetoothd started?”)

Step 12

Reading the SDP record

Now that we’ve set up D-Bus, we need to read the contents of the XML file describing the SDP record into a variable. Again, we’re doing this inside a try-except block in case the file is missing. The sys.path[0] variable contains the path to directory containing the script:

        # Read the service record from file
        try:
            fh = open(sys.path[0] + “/sdp_record.xml”, “r”)
        except:
            sys.exit(“Could not open the sdp record. Exiting...”)
        self.service_record = fh.read()
        fh.close()

Step 13

Listening for a connection

The next thing we’ll do is define a listen function, which adds the SDP record we just read to the SDP server, and then waits for a connection from a client device. A client device will connect to the control socket first, and then the interrupt socket. The accept function of a socket returns a socket for that connection and a tuple containing the client’s MAC address followed by the port they connected on. Our expert created a couple of constants to make the code more readable when accessing the values in the tuple.

class Bluetooth:
     HOST = 0 # BT Mac address
     PORT = 1 # Bluetooth Port Number...
     def listen(self):
          # Advertise our service record
          self.service_handle = self. service.AddRecord(self.service_record)
          print “Service record added”
          # Start listening on the server sockets
          self.scontrol.listen(1) # Limit of 1 connection
          self.sinterrupt.listen(1)
          print “Waiting for a connection”
          self.ccontrol, self.cinfo = self.scontrol.accept()
          print “Got a connection on the control channel from “ + self.cinfo[Bluetooth.HOST]
          self.cinterrupt, self.cinfo = self.sinterrupt.accept()
          print “Got a connection on the interrupt channel from “ + self.cinfo[Bluetooth.HOST]

Step 14

Adding the main function

We now have basic code in place that will let us accept connections from devices. It will drop the connections straight away, but that doesn’t matter for now. We’re going to add a main function at the bottom of the file to create an instance of the Bluetooth class and call the listen function to wait for a connection. We’re going to check that the user executing the code has root privileges as part of the main function. Otherwise it’s pointless to continue, as the script won’t do anything.

if __name__ == “__main__”:
     # We can only run as root
     if not os.geteuid() == 0:
          sys.exit(“Only root can run this script”)
     bt = Bluetooth()
     bt.listen()

Step 15

Pairing with the client device

Before we can accept connections from client devices, we need to pair with them. We’re going to describe this process on an Android device. Now, it’s best to advertise the virtual keyboard’s SDP record while we are pairing, so at this point, you’ll need to open up a second shell on the Raspberry Pi. You can either do this by opening up another SSH session, or using Ctrl+Alt+F2 to switch to the next console if you’re using the Pi with a keyboard and screen connected (Ctrl+Alt+F1 will switch you back to the first console).

So, in the first shell, you need to start PiTooth with sudo ./PiTooth. It will print that the service record has been added and that it’s waiting for a connection from a client device. At this point, you need to go to the Bluetooth settings on your client device and make the device discoverable. Now, switch to the second shell. Once you’re there, run the command hcitool scan. This will tell you the MAC address of the device you want to pair with. Once you’ve found this, you need to use the command bluez-simple-agent hci0 [client MAC address].EnteraPIN,and then enter that PIN on your client device. You should now be paired with the Raspberry Pi.

Note that if you ever have to unpair your client device, you can use the command bluez-test-device remove [client MAC address].

Step 16

Testing the code so far

We might as well test the code we have so far while it’s waiting for a connection. Switch back to your other shell and then scroll down to the Raspberry Pi entry on your client device. Select the Connect option. Note that our expert sometimes had to reset the Bluetooth on his client device by turning it off and on again because it got upset when the code simply dropped the connections as soon as it connected. Our output looked like this:

pi@raspberrypi ~/PiTooth $ sudo ./ PiTooth.py
Service record added
Waiting for a connection
Got a connection on the control channel from [Client MAC]
Got a connection on the interrupt channel from [Client MAC]

Step 17

Input reports

It will be useful to learn about input reports before we start coding the Keyboard class. At the top of the page is a table describing an input report from the Bluetooth HID specification. An input report is 9 bytes long, and prefixed with a byte indicating that the remaining bytes are an input report. The first byte containing Report ID is always 0×01, which is the value for a keyboard input report.

It will help to understand a little about binary data. A byte is made up of eight individual bits which have a value of either 1 or 0. A byte can represent a numerical (decimal) value of up to 255. Anything in the form 0×00 is a hexadecimal value. For example, 0×01 is 00000001 in binary, and represents the decimal number 1. The size of a character, for example, the letter A, is also a byte. This knowledge will come in useful shortly when we need to convert between various data types.

The second byte indicates which modifier keys (Ctrl, Alt, Shift and the Windows key) are pressed. The bit for that key is set to 1 if the key is pressed, or set to 0 if the key isn’t pressed. The third byte is reserved, and the remaining bytes are for up to six key events.

Step 18

The Keyboard class

We’re going to start by defining the structure of an input report, with all of the keys turned off by default. Then we loop until we can get a keyboard device.

class Keyboard():
    def __init__(self):
        # The structure for an bt keyboard input report (size is 10 bytes)
        self.state = [
               0xA1, # This is an input report
               0x01, # Usage report = Keyboard
               # Bit array for Modifier keys
               [0,   # Right GUI - (usually the Windows key)
                0,   # Right ALT
                0,   # Right Shift
                0,   # Right Control
                0,   # Left GUI - (again, usually the Windows key)
                0,   # Left ALT
                0,   # Left Shift
                0],   # Left Control
               0x00,  # Vendor reserved
               0x00,  # Rest is space for 6 keys
               0x00,
               0x00,
               0x00,
               0x00,
               0x00 ]

        # Keep trying to get a keyboard
        have_dev = False
        while have_dev == False:
            try:
                # Try and get a keyboard - should always be event0 as we’re only
                # plugging one thing in
                self.dev = InputDevice(“/dev/input/event0”)
                have_dev = True
            except OSError:
                print “Keyboard not found, waiting 3 seconds and retrying"
                time.sleep(3)
            print "Found a keyboard"

Step 19

Changing the keyboard’s state

Before you continue, you’ll want to take a quick look at the keymap.py file our expert provided. This file contains a dictionary mapping evdev keys to Bluetooth keys, as well as mapping evdev modifier keys to the bit that needs to be set in the Input Report. The Bluetooth values are in decimal rather than hex, but that doesn’t matter since Python will convert hex to decimal anyway.

This function takes an evdev event and changes the keyboard’s state. Firstly, we check if the key is a modifier key (the function returns a negative number if it’s not) and if so, flip the appropriate bit in the bit array of our Input Report. If not, we get the Bluetooth code of the key and then loop through the key elements. If the key is being released (event value of 0) then we find the key and we depress it by setting the value back to zero. Otherwise, we set the first empty space to the key’s value and break out of the loop to be as efficient as possible.

    def change_state(self, event):
          evdev_code = ecodes.KEY[event.code]
          modkey_element = keymap.modkey(evdev_code)
          if modkey_element > 0:

          # Need to set one of the modifier bits
          if self.state[2][modkey_ element] == 0:
                self.state[2][modkey_element] = 1
          else:
                self.state[2][modkey_element] = 0
          else:
                # Get the hex keycode of the key
                hex_key = keymap.convert(ecodes.KEY[event.code])
                # Loop through elements 4 to 9 of the input report structure
                for i in range (4, 10):
                     if self.state[i] == hex_key and event.value == 0:
                            # Code is 0 so we need to depress it
                            self.state[i] = 0x00 elif self.state[i] == 0x00 and event.value == 1:
                            # If the current space is empty and the key is being pressed
                            self.state[i] = hex_key
                            break

Step 20

The event loop

The event loop is actually really simple; it takes an instance of the Bluetooth class as a parameter and reads input from the keyboard in a loop. Evdev keys have three states: press, depress or hold. We only want to deal with press or depress, because the Bluetooth protocol doesn’t require hold. It’s assumed the key is held if its value is not reset to zero again. We ignore the hold events with the ‘event.value < 2’ condition.

With that out of the way, we simply pass the event to the change state function and then call the send_input function of the Bluetooth class, which we are about to write.

     def event_loop(self, bt):
          for event in self.dev.read_loop():
                # Only bother if we hit a key and it’s an up or down event
                if event.type == ecodes. EV_KEY and event.value < 2:
                       self.change_state(event)
                       bt.send_input(self.state)

Step 21

Sending input

Scroll back up to the Bluetooth class and create the send_input function. This function may look a little complicated, but it’s actually just converting the Input Report from the Keyboard class to a string that can be sent with the Python Bluetooth module.

So, we accept an Input Report and define an empty string that we’re going to build up and then send. We then loop through each element in the Input Report and check if it’s an array. If it is the array, then it will be the array of individual bits that make up the modifier byte. We need to convert this array to a string of eight characters by looping through each element and appending it to the bin_str string. We then need to convert this binary data to an integer – using base 2, as a bit can only have two possible states. We then convert this integer (which will have a size of one byte) to a character (also one byte) that can be added to the hex_str string. If the type is not an array, then the element of the input report can be converted straight to a character and appended to the hex string. Once the hex string is complete, it’s sent down the interrupt channel.

     def send_input(self, ir):
          #  Convert the hex array to a string
          hex_str = “”
              for element in ir:
                   if type(element) is list:
                        # This is our bit array - convrt it to a single byte represented
                        # as a char
                        bin_str = “”
                        for bit in element:
                             bin_str += str(bit)
                             hex_str += chr(int(bin_str, 2))
                        else:
                             # This is a hex value - we can convert it straight to a char
                             hex_str += chr(element)
                   # Send an input report
                   self.cinterrupt.send(hex_str)

Step 22

The final piece

We need to finish off our code by initialising the Keyboard class and calling the event loop function, passing through the instance of the Bluetooth class.

    kb = Keyboard()
    kb.event_loop(bt)

Step 23

Testing the code

That’s it! This is a pretty primitive implementation, as you can probably tell. The performance could also be improved, but the proof of concept is there. We don’t even bother with anything on the control channel, and ignore any Output Reports on the interrupt channel that could contain instructions to set various LEDs on the keyboard. You simply need to run the code and start typing on the keyboard to send input to the client. You’ll probably type a load of rubbish into the console if you’re using the Pi with a screen.

Follow @LinuxUserMag

To ensure you can still make the most of the excellent distros, software and tutorial files intended for the issue, though, we’ve set up a direct download to the ISO.

Once downloaded, simply uncompress the Zip and either burn it to a writable DVD or USB stick (4GB or larger) as you would any normal distro. Please refer to page 96 of the magazine if you need any assistance burning an ISO to DVD.

We can’t apologise enough for the mistake and we’re sorry to have inconvenienced you.

Python Masterclass
Everything you need to start writing programs today

System Admin expert guide
Start a career in open source

Raspberry Pi Jamboree
Inside RasPi’s biggest ever event

Crazyflie Quadrotor
World’s first open source ‘copter reviewed

The ultimate RSS Reader revealed
RSSOwl, Liferea, Blam and Akregator reviewed

Also inside
- Make yout own Wiki
- Rock, Paper, Scissors code listing
- Bitcraze interview
- Reviews for the MiraBox, FLIRC, Rasplex, Webconverger 18, FreeNAS

…and much more!

Tutorial Files

Python for beginners tutorial files

Rock, Paper, Scissors tutorial files

Linux User and our sister mags are all available via Great Digital Mags on all major platforms!

Follow @LinuxUserMag

Removed from its packaging, the MiraBox looks remarkably like a desktop Ethernet switch. Its shiny white plastic top and bottom is ringed by an impressively solid-feeling metal centre, and it’s only when you turn the device around to view the two Ethernet ports and two USB 3.0 ports on the rear that you realise there’s a little more to it than a simple switch.

The MiraBox is the latest development platform from Globalscale, the company that commercialised Marvell’s SheevaPlug plug-top computer concept. The plug-type design with its integrated power supply – a source of long-term reliability issues in the original SheevaPlug design – has been ditched in favour of a compact desktop chassis that would clearly be at home sitting near network switches and routers.

Inside, the MiraBox boasts a Marvell Armada 370 system- on-chip processor, featuring a single-core 1.2GHz ARMv7 application processor and plenty of additional input and output capability. Much of this is exploited on the outside of the device: two full-speed USB 3.0 ports, connected to the SoC via one of its PCI Express lanes, provide high-speed connectivity to external storage devices, while a pair of Gigabit Ethernet ports mean the MiraBox can easily do double-duty as a gateway, firewall or intrusion detection system.

Powering the device on, the boot sequence – which can be viewed and, through the ubiquitous U-Boot BIOS, modified via a micro-USB serial console – loads a version of Debian Squeeze based on the 2.6.35 kernel tree. That, unfortunately, is where the MiraBox begins to lose some of its lustre: compiled for soft-float, the bundled Debian OS – pre-installed on a 1GB NAND flash module – is a poor performer.

A SysBench CPU test results in a 95th percentile time of 65.57ms, compared to a much speedier 51.45ms on a Raspberry Pi running the hard-float version of Raspbian – despite the MiraBox boasting a more modern processor running at almost twice the clock speed.

Compatibility can also be an issue with the MiraBox: while most common Debian packages are available within its repositories, some software simply won’t install correctly. Connecting two USB 3.0 SuperSpeed hard drives to the MiraBox and attempting to set up a Btrfs RAID1 array brought the device to a shuddering halt, thanks to a lack of kernel modules – despite the btrfs-tools packages being available and installed.

The software is definitely the MiraBox’s weakest link, which is a shame as there is evidence that Globalscale has thought hard about making the device as accessible as possible: a selection of scripts provide easy ways to enable the off-by- default Bluetooth radio, for example, or to toggle the integral Wi-Fi radio between client and access point modes.

If a community rallies around the MiraBox, as it did with the original SheevaPlug, many of these concerns could go away: all it will take is for someone to prepare a system image with a hard-float version of Debian for the device and provide it as a download and then its true potential will be unlocked. For now, though, it’s certainly a drawback to bear in mind.

For those who don’t mind rolling their own operating system, the MiraBox’s hardware should definitely hold appeal – and if the included connectivity options aren’t enough, the case hides a mini-PCI Express slot for adding in extra hardware.

For developers, an optional breakout box provides access to the Armada 370’s general-purpose input-output (GPIO) capabilities along with JTAG debugging support, but comes at a cost: the breakout box alone costs £45, although when bought with a MiraBox this drops to £40.

Technical specs

Price: £124.17 (excluding VAT)
Processor: Marvell Armada 370 SoC (PJ4Bv7 ARMv7L) 1.2GHz single-core
Graphics: None
Memory: 1GB DDR3
Storage: 1GB NAND flash, 2x microSD expansion slots (1x internal)
Expansion: Mini-PCI Express slot, 2x USB 3.0
Network: 2x Gigabit Ethernet, 802.11b/g/n Wi-Fi, Bluetooth 3.0
Dimensions: 133.2 x 93.9 x 20.4mm(excluding power supply)
Weight: 185g (excluding power supply)
Link: New IT

Verdict

4/5

Excellent hardware let down only by somewhat troublesome software. If you’re willing to spend the time compiling your own operating system, or don’t need the very latest Linux kernel, it’s still well worth investigating – and you’re unlikely to find another single-board computer this compact that packs as much potential for high-performance
networking tasks.

Follow @LinuxUserMag

there’s something to be said for a low-tech approach to life. I once worked in an office where, frustrated at the lack of work being done by his sales staff, the managing director ordered excel to be uninstalled from all of their machines. He also insisted they have days where they switched the computers off. They weren’t popular, but almost inevitably, when the numbers came back (calculated on a computer, of course), they were up.

Conversely, there are jobs that computers are very good at complicating. Just this morning, I left a shop without the morning paper, because it wouldn’t scan at the till. The assistant gamely battled on for a good minute or two to find the right code, but without the magic elixir of numbers, she was unable to register the sale in the till. I gave up, left empty-handed, but with my coins still rattling around my pocket.

My favourite example, although this is a lesser problem in these more sophisticated days, was when pubs and restaurants started to migrate over to computerised ordering systems. If ever you wanted to cause wholesale confusion, all you had to do was order yourself a pie and chips, but ask for it without peas. Sadly, computerised systems in days of old didn’t have a button for no peas, and so a traipse to the kitchen ensued, to deliver the vital message in person. Greenery was thus kept at bay in a way that probably took more time than if the whole system had been human-driven in the first place.

The computer as the scapegoat, of course, is nothing new. Ever since legions of office workers realised that you could blame ‘the system’ for sitting down and doing sweet nothing for a couple of hours, it’s usurped whatever the previous equivalent of the dog eating your homework happened to be.

However, what’s interesting about modern- day computing, outside of the palaces of Microsoft, is how broad the scope of change is happening to be. The big evolutions are all but gone, and so it’s more lateral little moves that continue to take place. As such, especially given community-driven development, small problems – such as a desire to pass on some healthy vegetables – can be quickly fixed. It remains staggering therefore that proprietary system manufacturers still struggle to wrap their heads around a satisfactory way to ensure that the machines they sell can cope with the nuances of the jobs they’re intended to. Granted, there are more pressing concerns than ensuring a newspaper scans at the till, but where’s the contingency? Where’s the methodology by which this can be quickly addressed? And on a smaller level, isn’t it just possible to accept cash, without every system needing a full dose of product information before proceeding with a sale?

The one feature of technology, ultimately, that tends to be overlooked is that it arrives with an off switch in place. Every now and then, there’s no harm pressing said off switch and appreciating some of the jobs that human beings can do better, without glaring at a touch- screen interface in the vain hope of hitting a magical combination of buttons to thus unlock something relatively simple.

Fortunately for me, I never really wanted the newspaper anyway…

Follow @LinuxUserMag

Cloud computing is more than a buzzword. It is an essential part of how we use technology today. On a personal level, we all store and retrieve data and we do this on multiple devices, like PCs, smartphones, tablets and media players. We also want a coherent experience with this data: we want to be able to retrieve and store any data from/on any device. In the old days, we had to manually sync every other device to a central location to have the same copy of data everywhere else. But this is a very cumbersome and confusing process. On top of that, you will also have to limit where data is being saved. In most of the cases this place is the central system from where we are syncing the other devices. This method is still not that bad if you are doing this between just two devices; but when you go beyond that, you will always think that there must be a better way to do this.

Imagine having all your data available to you on every device you own. You are not bound by limitations such as where you can store or retrieve the data. This is where the cloud comes into the picture and makes it all a reality. Cloud computing in a more general sense means making computing resources (like storage, processing power, software etc) available in the form of services (on public or private networks) which can then make those resources available from any other system.

In this feature we will be building our own cloud system, a cloud storage system to be precise. Much like Dropbox, Ubuntu One or SkyDrive, but our implementation will have more features. Before you move on, you may ask what is the point in doing this when we already have such popular services on our disposal. Here is why:

Not your cloud: While these services are popular and easy to use, you do not own them. You use them by agreeing to certain terms and conditions (we bet you haven’t even read them) that can be changed at any given time by the service providers. This may leave your files at risk.

Downtime: Sometimes you may lose access to your files because of server issues faced by your service provider. This can very problematic if you are unable to gain access to one of your important files when you really need it.

Privacy: Since your files are hosted elsewhere, they may be viewable to certain third-party agencies (like governments) without your consent. This worries a lot of people.

Features and restrictions: Most of these proprietary services do not have a lot of features and are very restrictive in terms of what you can do with the files.

Step by Step

We will be building our private cloud using the open source software called ownCloud. The name says it all: it allows you to build your own cloud storage infrastructure. OwnCloud started its life as a The KDE cloud computing project and is now available on almost all popular platforms. Created by KDE developer Frank Karlitschek, it is now developed by the ownCloud team.

Step 01

Installing the prerequisites

The ownCloud core is written in PHP5. Its prerequisites are basic, like those of any typical PHP web application. On the database side it supports SQLite, MySQL, Oracle and PostgreSQL. For our setup we’ll use MySQL to keep things simple yet scalable. If you are only doing a test setup, you can use SQLite, which is a zero configuration database system.

You will need to install the following on your Linux distribution:

PHP packages: php5, php5-gd, php-xml- parser,php5-intl

Database driver: php5-mysql. If you are planning to use any other database you will also need to install the respective database together with its PHP driver.

Curl packages: curl, libcurl3, php5-curl

SMB client: smbclient; this is used to mount Windows share.

Web server: apache2

For a Debian-based distribution, you can run the following command to install all the prerequisite packages:

$ sudo apt-get install apache2 php5 php5-gd php-xml-parser php5-intl php5-sqlite php5-mysql smbclient curl libcurl3 php5-curl mysql-server

Step 02

Installing ownCloud – setting up the web root directory

Download the latest version of ownCloud from http://owncloud.org/releases/. For this tutorial we are using owncloud-4.5.6.tar.bz2 At this point you’ll need to set up the web server root directory. On Debian-based distributions it is /var/www. Extract the owncloud package in the web server root directory When in doubt, look at the Apache configuration file.

$ tar xjf owncloud-4.5.6.tar.bz2
$ cp -r -v owncloud/ /var/www/ ludcloud //

In our example, we are using ludcloud as the root installation directory.
OwnCloud needs to write to certain directories of its installation. To do that, the web server user (www-data for Debian-based distributions) must own apps, data and config directories of the installation. Run the following commands to give the required permissions:

$ cd /var/www/ludcloud
$ sudo mkdir data //

This folder is not present, but is needed during installation.

$ sudo chown -R www-data:www-data data
$ sudo chown -R www-data:www-data config
$ sudo chown -R www-data:www-data apps

Step 03

Installing ownCloud – configuring the web server

In this step we will be configuring Apache Web Server for ownCloud. OwnCloud requires .htaccess to be enabled on the Apache server. .htaccess files (or ‘distributed configuration files’) provide a way to make configuration changes on a per-directory basis. To enable the .htaccess in the web server, edit your web server configuration file (in Debian-based distributions it is /etc/apache2/sites-enabled/000-default) with AllowOverride All.

   <Directory /var/www/>
        Options Indexes
FollowSymLinks MultiViews
        AllowOverride All
        Order allow,deny
        allow from all
   </Directory>

Next we need to enable an Apache module called mod_rewrite. Mod_rewrite provides a rule-based rewriting engine to rewrite requested URLs on the fly. To enable this module, run the following commands:

$ sudo a2enmod rewrite
$ sudo a2enmod headers

Once you have enabled the necessary modules, you can restart the service to apply the changes.

$ service apache2 restart

Step 04

Installing ownCloud – running the installation

Navigate to http://localhost/ludcloud. You will be presented with the installation screen for ownCloud.

The first thing to do here is to create an admin account. Enter the desired username and password to do so. To configure the database, click on Advanced then select MySQL. Then enter the MySQL username password along with the database name. If you do not have a separate database user configured then you can use the root username; ownCloud will create a dedicated database with a dedicated db user for use with ownCloud.

Click Finish Setup to complete the process.

Step 05

Adding extra storage

If you have lot of users on your server you can quickly run out of storage. That’s why it helps to have additional storage available. OwnCloud supports SMB (Windows share), FTP, WebDAV, OpenStack and Local File system.

To enable extra storage you’ll need to create and edit <ownCloud Root>/config/mount.php. Additional storage can be created either for a single user or a user group.

The following is an example mount.php with all the back-ends enabled:

<ownCloudRoot>/config/mount.php
// Example mount.php showing few of the supported backends enabled
<?php
return array(
// Mount options for group
    ‘group’=>array(
        ‘admin’=>array(
            ‘/$user/files/Admin_Files=>array(
// Accessing Local Filesystem
                ‘class’=>’OC_Filestorage_Local’,‘options’=>array(‘datadir’=>’/mnt/admin_extra_storage’)
            ),
        ),
    ),
//Mount options for users
    ‘user’=>array(
        ‘all’=>array(
// Accessing WebDav Storage
            ‘/$user/files/Web_Dav_Files'=>array(
                ‘class’=>’OC_Filestorage_DAV’,
                ‘options’=>array(
                    ‘host’=>’webdavhost.com/webdav.php’,
                    'user'=>'max',
                    ‘password’=>’secret’,
                    ‘secure’=>true)
                ),
        ),
        ‘user1’=>array(
//Accessing FTP Share
            ‘/user1/files/ftpdownloads’=>array(
                ‘class’=>’OC_Filestorage_FTP’,
                ‘options’=>array (
                     ‘host’=>’ftp.mywebhost.com'
                     'user'=>'max',
                     'password'=>'secret'
                     'root'=>'/ftpfiles')
                 ),
             ),
        )
);

Step 06

Configuring user authentication

If you have lots of users for your cloud, then creating individual users again in ownCloud could become tedious. If you already have a user authentication system in place, ownCloud can use it. OwnCloud supports LDAP, IMAP, SMB, OpenID, WebDAV and FTP. This support is provided in the form of apps. Apps are a way to extend ownCloud’s functionality.

To install additional user authentication back- ends, log into ownCloud, click Settings (gears icon) then Select Apps, then select an App which is not represented with bold fonts, then click Enable in the right pane. Bold means the app is already enabled.

You can use the following apps:

For LDAP: LDAP user and group back-end For OpenID: OpenID user back-end

For WebDAV: WebDAV user back-end

For IMAP, SMB, FTP: user_external

The following shows an example of using the user_external app for authenticating from IMAP, SMB and FTP. You will need to edit the <ownCloudRoot>/config/config.php file.

For IMAP:

‘user_backends’=>array(
  array(
    ‘class’=>’OC_User_IMAP’,
    ‘arguments’=>array(‘{imap.gmail.com:993/imap/ssl}INBOX’)
  )
)

For SMB:

'user_backends'=>array(
  array(
    ‘class’=>’OC_User_SMP’,
    ‘arguments’=>array(‘smbserver’)
  )
)

For FTP:

‘user_backends’=>array(
  array(
    ‘class’=>’OC_User_FTP’,
    ‘arguments’=>array(‘ftpserver’)
  )
)

Step 07

Accessing ownCloud over WebDAV

OwnCloud comes with full WebDAV support. WebDAV is an HTTP protocol that allows read/write file management over the web. The good thing about WebDAV is that the clients are already built into all the popular operating systems, such as Linux, Mac OS X and Windows.

WebDAV is automatically enabled on ownCloud. To access it you will need to use the following URL: www.yoursite.com/ludcloud/ files/webdav.php
Log in with your ownCloud credentials when prompted.

To access your ownCloud account from Nautilus (a popular Linux file manager), you can click File>Connect to Server under Type Select WebDAV and enter server details, click Connect.

You can also use the URL in the format
dav://username@yoursite/ludcloud/files/webdav.php and type it directly into the location bar of Nautilus.

If you want to access it from Mac OS X’s Finder, you can click on Go>Connect to Server… and enter the URL in the format http://www. yoursite.com/ludcloud/files/webdav.php. Enter your credentials when asked.

Step 08

Syncing files using desktop sync clients

If you like Dropbox then you will love this feature. You can use desktop sync clients to sync your files across multiple computers and devices. Desktop sync clients are available for Linux, OS X and Windows. Like ownCloud, desktop sync clients are also open source.

On Ubuntu you can install the package using Apt-get:

$ sudo apt-get install owncloud-client

For other distributions (Debian, CentOS, Fedora, openSUSE etc) you can use the following URL to get the ownCloud desktop sync clients: http://software.opensuse.org/download/pack age?project=isv:ownCloud:devel&package=ow ncloud-client

Download Windows and OS X sync clients from http://owncloud.org/sync-clients/

Desktop sync clients can be used for continuous sync, selective folder sync, multi-folder sync. Multi-folder sync means you can sync multiple ownCloud folders to multiple folder locations. This is an important feature which is not even provided by most popular cloud service providers.

Step 09

Syncing files using mobile sync clients

OwnCloud syncing is not just limited to the desktop. You can use ownCloud’s mobile sync clients to sync your files on the go. OwnCloud mobile apps are available for the Android and iOS (iPhone/iPod touch/iPad) platforms. Both allow you to sync files on the go. The Android version of the app also allows you upload files from any Android app and offers automatic favourite file syncing. The latter feature will keep all your favourite files synced with the mobile device all of the time.

You can either purchase the Android app from the Google Play Store (https://play.google. com/store/apps/details?id=com.owncloud. android) or the Amazon Appstore (www. amazon.com/ownCloud-Inc/dp/B00944PQMK/ ref=sr_1_1?ie=UTF8&qid=1352459188&sr=8- 1&keywords=owncloud). If you are not keen on paying, you can either build the client yourself from the source (https://github.com/owncloud/ android) or download a prebuilt APK file from http://alefzero.eu/a/master.

The iOS version of the App is not open source and is only available in the Apple App Store at https://itunes.apple.com/us/app/owncloud/ id543672169?mt=8. The ownCloud developers say that this is because of Apple’s policy on open source applications in the App Store. The Android and iOS apps cost 63p and 69p (both 99¢) in their respective stores.

Step 10

Extending ownCloud functionality using community add-ons/apps

One of the best features about having your own setup is that you can customise it to your own needs. Using ownCloud, you not only get to customise it but also have the ability to add more features to it. OwnCloud has a vibrant community of people building add-ons for ownCloud, called apps, at apps.ownCloud.com. These apps are available in the Multimedia, PIM, Productivity, Games and Tools categories.

To see how to install apps in ownCloud, in this section we will install the Notes app, which provides notes functionality for ownCloud. Notes is a very capable note-taking app which supports MarkDown and syncing to standalone note-taking apps. You can use Papyrusex, a free note-taking Android app on the Google Play Store (https://play.google.com/store/apps/details?id=com.kallisto.papyrusex) to sync notes. You can also use zNotes (http://sourceforge.net/projects/znotes/) to sync notes on Linux, BSD, OS X and Windows platforms.

Download the Notes zip archive from http:// apps.owncloud.com/content/show.php/ Notes?content=155599. Extract the zip file and copy the extracted folder (in this case, Notes) into the <ownCloudRoot>/apps/ directory. Log into your ownCloud instance as an Admin user, then click Settings>Apps. In the Apps list you will notice a new entry called Notes. Click on it, then click Enable in the right pane to activate the installed app. After activation, refresh the ownCloud page and you’ll see Notes in the left navigation bar. Click on it to start using Notes.

Other apps may require additional steps; check with the documentation of the apps you are installing.

Conclusions

As you can see, creating your own personal cloud has some real benefits in terms of the features and the flexibility. Thanks to ownCloud you can now create the cloud of your dreams using open source software. The ownCloud developers have made sure that you don’t miss your data anywhere by creating sync clients for both desktops and mobile devices. OwnCloud installation is also flexible. As we have seen, you can choose from a wide variety of storage (including other cloud services) as well as plenty of very unconventional authentication mechanisms. If you still think there is something missing in ownCloud that you want, well fear not: you can add that feature yourself. Watch out for a future tutorial on how to write ownCloud apps on Linux User & Developer.

Follow @LinuxUserMag

When Miguel de Icaza initiated the Mono project back at the turn of the millennium, his idea was not just to bring what he perceived as the advantages of .NET – a cross-platform development framework and a common runtime – to Linux. Nor was it his intention just to make migration from Windows to Linux easier. His big idea was that Mono would become the default application development platform for the Linux desktop, specifically for GNOME.

For a thousand different reasons this was never likely to happen. Mono was never going to be an easy fit for the Linux desktop. Users didn’t like it, and neither did the developers, and not simply for coding reasons. .NET had been developed as Microsoft’s answer to Java, a middleware platform that could be used to generate web Services; but where Java used one language and was platform independent, .NET was multilingual and platform specific. .NET was intended to neutralise the commercial success of Java and prolong the proprietary dominance of Windows as a client-facing operating system. Mono implemented C#, the common language runtime and the development framework aspects of .NET on Linux, but .NET was never accepted as a model for Linux development.

Nevertheless, de Icaza always hoped that developers would see Mono as a perfect tool for GNOME development. The idea wasn’t well received. From the beginning, doubts were raised about the ‘intellectual property rights’ Microsoft had retained over the code, Nobody really wanted to know, and Mono was never going to be an easy ask. As it was, Microsoft was never as helpful to the cause as it might have been. Just enough rope was dangled to keep the Mono developers happy, but the scope for future litigation was always left in place. Just as Microsoft’s speculative patent indemnification agreement with Novell was intended to sow fear, uncertainty and doubt around the legal status of the Linux kernel, a certain level of ambivalence and discord around the legal status of Mono was always going to suit Microsoft’s purpose,

The objection of developers to Mono wasn’t that a .NET implementation shouldn’t exist, but that it shouldn’t be core to the free software development stack. Richard Stallman’s observation was that “I have always supported the development of free platforms for C#, just as I’ve supported the development of free platforms for any language that users use. I also wouldn’t argue that people should not use C# with a free platform for secondary applications,” but “making GNOME depend on Mono is running a grave risk, and a grave mistake.”

Mono had its followers, and appealed to some developers who had come over from Windows, but had never won its target audience. De Icaza always maintained that the issues over the .NET code patents were wildly exaggerated, and in one sense he was absolutely right. Neither Mono nor the Linux desktop has ever faced a legal challenge relating to .NET patents. But then, neither did Mono succeed in its goal of becoming the development platform for Linux desktop applications. Even if it had wanted to, Microsoft never had sufficient cause to use its legal muscle against the Linux desktop.

De Icaza hoped to prove his point with the development of applications such as Banshee, Beagle, Docky, F-Spot and Tomboy. To some degree he succeeded, and briefly these applications had some recognition but were ultimately replaced as Mono’s star, and the fuss around it, faded.

When Novell was purchased by Attachmate, de Icaza was permitted to take Mono elsewhere, and created a new company, Xamarin, as a vehicle for Mono development. In July 2011 Xamarin was granted a perpetual licence to all the ‘intellectual property’ associated with Mono, MonoTouch, Mono for Android, and Mono for Visual Studio. Xamarin and Mono are now totally focused on the mobile market. Mono has found its niche, and the ideal of GNOME involvement has faded from memory. Out of this, Xamarin has achieved some success and claims a community of more than 200,000 developers producing cross-platform applications for smartphone devices.

Mono is still useful to the Linux desktop as an interoperability and migration tool, and as a means of interacting with .NET and Windows implementations in mixed environments, but was never going to work at the heart of the Linux desktop experience. Stallman’s take on this was that “Microsoft is probably planning to force all free C# implementations underground some day using software patents.”

According to Stallman, the problem was “not in the C# implementations, but rather in Tomboy and other applications written in C#. If we lose the use of C#, we will lose them too. That doesn’t make them unethical, but it means that writing them and using them is taking a gratuitous risk.”

Follow @LinuxUserMag