Posts Tagged ‘linux’

PackageKit presentation

Friday, March 20th, 2009

On Wednesday we had the pleasure of Richard Hughes joining us at Hursley to talk about PackageKit. I’ve heard of it but never quite bothered finding out any more than the name but having gone to the presentation I’m pretty glad. PackageKit is (yet another) attempt at making software updating/installation easier on Linux. There are many existing tools for this already but PackageKit seems to be particularly interesting because it’s not actually trying to replace anything; it works with and makes use of the existing tools whilst providing some real value on top. Below is a very quick summary of Richard’s presentation.

Existing stuff

  • Good packaging formats
  • Depency solvers, downloaders and UIs bolted on
  • Can’t have automatic updates (needs password authentication)
  • Can’t use fast-user switching (lock out install applications/databases)
  • Errors/warnings in English only and really confusing to average user
  • Installation is done by package names not application names (many to many relationships)
  • Can power down during update – bit dangerous!

PackageKit implementation

  • The ‘glue’
  • Integrates with existing tools (including dependency mangement etc)
  • Improves authentication (uses PolicyKit – fine grained control)
  • System activited daemon (only running when you need it)
  • Only need to write simple integration between tools and PackageKit (doesn’t even need to be complete and done for most tools already) plus thin UI
  • Uses DBUS (two layers – one for full control, one “just do it”)
  • Applications can integrate directly (e.g. install clipart from openoffice)
  • Installation/update by application not package (users know what it is they’re installing!)
  • Doesn’t allow shutdown during installs

PackageKit project

  • Easy to contribute (git with anonymous access – merged to release daily)
  • Rapid development (roughly one minor release per month)
  • Shipped with Fedora 9 (and others)
  • Strong interest from OpenMOKO, Ubuntu (and others)

I’ve installed an old-ish release on my Ubuntu machine (straight from the repositories) and it looks pretty good. Definitely gonna pay attention to this project, it looks like a big step in the right direction.

Replacing Python on a Battlefield 2 server

Wednesday, May 7th, 2008

Lately I’ve been doing some work (I promise it is real work) with Battlefield 2. The server part of the game has a cut-down version of Python built in so that you can interact with it, modifying aspects of the game and reacting to events etc. More details on this can be found on this wiki.

Anyway, the Python version it uses is pretty old (2.3.4, current version is 2.5.2) and it’s had functionality cut, e.g. no threading support. For the work I’m doing I needed threading support and a few other things so wanted to swap out the version of Python for another – turns out this wasn’t obvious so here are the steps:

  1. Replace the Battlefield 2 Python library (e.g. ‘bf2/bin/ia-32/libdice_py.so’) with the version of your choice. I just linked to my locally installed version ‘/usr/lib/libpython2.5.so’.
  2. Replace the Python library path at runtime to use the new libraries, e.g. edit ‘bf2/python/bf2/__init__.py’ and putting the equivalent of ’sys.path = ['/usr/lib/python2.5/', '/usr/lib/python2.5/lib-dynload/', 'python', 'mods/bf2/python', 'admin']‘ after the ‘import sys’ line.

I do get the following warning at runtime: ’sys:1: RuntimeWarning: Python C API version mismatch for module host: This Python has API version 1013, module host has version 1012.’ but it doesn’t seem to cause any problems (so far!).

Christmas fun

Monday, December 31st, 2007

Ok, so I got a bit bored at some point over Christmas and decided to play with one of my presents – a USB Rocket Launcher.

The first difficulty was getting it to run on my Linux laptop as the drivers were only for Windows. A quick search and Scott Weston sorted me out. Then I thought it should really be controlled by more than just the keyboard so I hooked it into the Thinkpad accelerometer – now movements of the laptop could direct it. Finally, as I knew Andy Stanford-Clark would be a bit disappointed in me if I hadn’t, I MQTT‘d it so that the accelerometer details are published to a broker, a bridge app subscribes to that info and (where appropriate) publishes commands which are received by a final subscriber that actually sends the commands to the rocket launcher. This way you can easily swap out the accelerometer or indeed rocket launcher for something completely different.

I feel quite pleased with myself and slightly ashamed at the same time.