tensixtyone

This weekend (25th to 26th of October) CloudMade will be hosting a Open Street Map mapping party in Manchester at the Marbella Cafe. The weekend will consist of walking the streets on the east side of Manchester, friendly banter and a few pints. Everyone is welcome from hardcore experts to the complete newbies.

The day starts at 10:00am with a introduction and a simple overview of how to map your data, then we’ll head out and meet back at the Marbella Cafe for lunch, then head out again for the afternoon and concluding in drinks in a local watering hole.

Check out the wiki and Upcoming for more details. Hope to see you all there!

Marbella Café
2nd Floor
Sunshine Studios
52-54 Newton St
Manchester
M1 1ED

It’s come to my attention recently that some people don’t understand what “The Hub” project is all about. So let me explain the details of the project.

“The Hub” was originally an idea born out of a talk given at Open Source City. James Wallbank from Access Space gave an insightful talk on the community benefits of a open computer cluster, along with their computer recycling scheme they are able to poliferate computer usage around the local community. As you would expect, with a increase in computer usage and access to a common area a community grew and evolved in the project.

After Open Source City, discussions between the members of The Art Organisation about a similar project being setup in the half empty building they have, Mello Mello. A few interested parties were approached and Vladimir from Liverpool LUG was one of these few. Discussions happened and plans made, but no decisive action was took.

Fast forward a few months, Liverpool LUG was holding its first couple of talks since it’s “rebirth”, stuck for a backup location for when FACT was unavailable the admin team approached The Art Organisation for space in Mello Mello. Greg, who is co-curator of The Art Organisation, talked about the community space project that started months before, and a few members of LivLUGs admin team (myself, Joanne, Graeme and Dan) offered to help out.

The overall plan is to setup four or five PCs in the space, with a common printer, internet connectivity, and a file server. In one of the storage areas we will keep old computer parts in a recycling capacity, but this will not happen until we’ve got the main hub in order. All the PCs will be networked and will be able to share out their media, along with the likes of a “pool” instant messaging system to allow quick transfers between individuals working on the PCs. Exact plans for software and incident tracking haven’t been worked out yet, we think that should be saved to when we have actual hardware on site. The only thing we know at the moment is that all the software will be Open Source.

At the moment we have the space and a load of old computing kit that has been scavenged from somewhere. The area has a lot of “junk”, well, I say “junk” but the items actually belong to a artist who was using the space as storage. We’ve organised the items as much as possible and are trying to organise PCs and desks for the area.

We need help, If you know somewhere we can get some old PCs, some desks, or other useful computing equipment, drop us a line. We’ll be approaching the FreeCycle lists sometime this week so keep your eyes out if your on there.

So, our first day of work inside “The Hub” has gone smoothly; We’ve managed to organise several boxes of computer equipment down to the essentials. The room was full of “junk”, I say that loosely as alot of the items there belonged to the artists so I was unsure of what it would be used for. Greg mentioned that the room would be cleared on Monday so I hope on our return visit it should be easier to move around.

We noticed that the room is wired up for CAT5, this is a massive timesaver as the least enjoyable part of the job would be wiring network cable up. Cream, the previous owners, must of had a fully wired network in the building at some point, so all we need to do is find where the cables drop out at.

We’ll be returning on Wednesday to do some further cleaning and organisation, hopefully we will be able to locate the missing drop point for those network cables. If anyone is interested in doing some heavy lifting and tidying your more than welcome to come along and help out!

As part of our location scouting for Liverpool LUG, Jo made a visit to Mello Mello to ask them if we could use some space in their building for hosting the LUG. The result was quite interesting.

Greg from The Art Organisation (current managers of Mello Mello) has asked if we can setup a open source computer cluster that will hopefully be open to the public and artists alike. We jumped at the chance and we’re going to be visiting tomorrow morning to do some initial scouting and investigation. One of the key requirements that Greg had was to make this completely open source and free as in beer, The TAO have little to no money.

I’ll be able to post a few more details and some photos after tomorrow’s visit.

While writing a new report today I’ve been drove mad while creating a dynamic query that selects the last full week. So here is the code for SQL Server, to save anyone else the pain:

dateadd(dd,0, datediff(dd,0,
   dateadd(day,-1*datepart(weekday,getdate())+1,dateadd(week,-1,getdate()))
))
dateadd(dd,0, datediff(dd,0,
   dateadd(day,7,dateadd(day,-1*datepart(weekday,getdate()),dateadd(week,-1,getdate())))
))

Last night I spent a few hours getting Liverpool LUG’s website on its own Xen VM, so hopefully we can provide some services to members, like webhosting and email aliases. This was my first venture into creating a Xen VM for myself, previously Chris has spent the time to set it up for me.

I’ll name this little adventure: Trip on the Fail Boat

Ok, so I was a little stupid. I didn’t read any existing documentation and bungled through it based on a few commands in the bash_history file. I know, stupid. For a while I hissed and cursed about incomplete setup which I thought debbootstrap would do, reading the documentation this morning has highlited how much of a monumental idiot I actually was. So now i’ll go through my idiotic bitching and explain why I was wrong…

1. 4Gb Fixup error messages
When I started up the VM I was assaulted by thousands of messages regarding a “4Gb memory fixup” or something to that nature. Of course, I was too busy trying to edit files in vi to actually look at the issue but was more than happy to shout and scream at my console formatting getting mixed up.

The fix? Install libc6-xen, or move /lib/tls to /lib/tls.disabled

2. Missing network config
The VM couldn’t see eth0, or lo for that matter. After hammering my head against the table checking the Xen config files I finally realised that updating /etc/network/inferfaces could help.

3. “Why is the hostname dom0?”
Stupidity ensues, thankfully I noticed before I issued the shutdown on dom0.

4. Services randomly failing to start up
Missing loopback network device, no actual 127.0.0.1. You would be suprised how much this can effect your system.

So for now, The VM is working. I’ll get round to posting some more details about LivLUG services soon, but for now i’m going to get some coffee…

So, in my last post I described how it was using the E160G with Debian. All in all it’s very good and i’ve not experienced any major issues, bar a few minor apt-get and NetworkManager issues. So, heres a quick rundown of how to get it on your machine.

So first, you need to get the hardware to work correctly under Debian. Plug in your E160G and check dmesg to see if the device recognises correctly. If you see ttyUSB0/ttyUSB1 appear you can skip this step.

First, you need to download USB_Modeswitch:

# wget http://www.draisberghof.de/usb_modeswitch/usb_modeswitch-0.9.4.tar.bz2
# tar jxvf usb_modeswitch-0.9.4.tar.bz2
# cd usb_modeswitch-0.9.4/
# ./compile.sh

Now you have the usb_modeswitch program, as this will be executed by udev it needs to be in a sensible location, personally i’d copy it to /usr/local/sbin/

# cp usb_modeswitch /usr/local/sbin/

Also, you need to grab the latest config file from the usb_modeswitch website and put it into /etc

# wget http://www.draisberghof.de/usb_modeswitch/usb_modeswitch.conf
# sudo mv usb_modeswitch.conf /etc/

Now, by default the config file comes with the section commented out, so edit the file and uncomment the section for the E220 (which is essentially the same device).

# sudo $EDITOR /etc/usb_modeswitch.conf

One last step, you need to add a small configuration file to udev to detect the E160G and run usb_modeswitch, put this file in you /etc/udev/rules.d/ folder:

SUBSYSTEM=="usb", SYSFS{idProduct}=="1003", SYSFS{idVendor}=="12d1",
  RUN+="/usr/local/sbin/usb_modeswitch"

Restart udev, and plug in your E160G…

sudo /etc/init.d/udev restart

and you should see something similar to:

[   16.085904] usb 5-3: GSM modem (1-port) converter now attached to ttyUSB0
[   16.086033] usb 5-3: GSM modem (1-port) converter now attached to ttyUSB1

So, the device is detected and you have your USB ports, first a quick overview. The E160G shows two serial ports, one is a data port, the other is for control signals. NetworkManager only makes use of one of these ports but the Vodafone Connection Manager uses both. Now you have a choice, install Network Manager 0.7 to gain native GPRS/UMTS data support or use another package. I went for Network Manager, while it’s still in beta and i’ve had a few run-ins in the past with it I decided to give it a go.

So, it was a simple case of adding the 0.7 repositories to /etc/apt/sources.list, updating, then installing the needed packages.

# echo "deb http://debs.michaelbiebl.de/ unstable main" >> /etc/apt/sources.list
# apt-get update
# apt-get -t unstable install network-manager

You might need to remove any old Network Manager packages before you do this, as network-manager-openvpn collides with the new package.

Hopefully thats give you the overview you needed, and you should be up and running!

I went to the post office and got my hands on the Huawei E160G with my reduced contract, and so far I am very pleased with it. The modem itself is a large USB stick, very comparable in size to a cigarette lighter. What is interesting is that the electronics can now be packaged in such a small kit, why ain’t they producing mobile phones of this size?

My first step was to get it working on Windows, I plugged in the modem on my old Windows PC and followed the numerous (and strange) online prompts to setup the software. After a lot of beeping, detecting new hardware and other jiggery pokery, I was presented with the Three Modem Manager application. The modem manager is a simple too that enables you to run the “dialup” connection through the modem. I whipped open the setup manual which informed me that no other setup was required bar setting up the software. So I clicked “Connect”…

… and it failed?

According to the tool I had to check my settings to see if they’re correct. This is a fresh setup of the tool, why would I need to check the settings when Three’s own guide mentions theres no setup needed. After 10-15 minutes poking around in the settings menu I finally threw in the towel. Sod it, I wanted to run this thing on Linux anyway so why am I putting myself through the pain?

Linux is, well, the way it was supposed to happen. I plugged in the stick and straight away I had numerous devices available, the “CD-ROM drive” for the drivers, the MicroSD reader, and the “tty” ports for the actual GSM modem. At this time I could of gone the route of setting up Gnome PPP and related tools to dialout to the provider and start using my new fancy net connection, but I’d heard that Network Manager 0.7 had the features to use 3G/GPRS built in without any extra settings. I decided to investigate the new version of Network Manager.

After much digging around on the ‘tubes, I finally found a Debian repository containing a build of the lastest Network Manager SVN. A little apt pinning and installation later I had the new version of the tool install. I browsed the existing menu and found a new option: “Auto connection to 3G/GPRS” , I selected the option and it connected.

I have to have a little moment to reflect here, “Mobile Broadband” is a new fad at the moment for most telecoms providers worldwide, so you would expect the Linux software support to be a little sketchy and buggy, but as it turns out the Linux method is alot simplier and easier to use. I’m not sure if I was missing anything obvious in Windows, but isn’t this stuff just supposed to work?

So, signed on to 3G I decided to give it a run for it’s money. I’m running these tests at 1:08am so it maybe a little bias, as I doubt many people would be actually using the APs at this time. I seem to be getting a variable speed of about 1-2mbps, and 150kbps upstream, not bad at all for a mobile provider. The documentation mentions that you should expect up to 2.5mbps, not the 7.2mbps advertised on some sites, all in all Three do a good job of pre-warning you that the speed on the box is not always what you get.

So far I’m happy with it, I’ve had a few minor issues with the stick not registering on the network but I’m not sure if this was down to my settings or just a small outage. I’ll post a guide in the next few days on configuring Debian up for Network Manager 0.7 and setting it up to work with the E160G.

I’ve been quite busy over the last two weeks, catching up on home projects and other things. After a few quick fixes and features sent over to the LottaNZB guys I was added to the development team, which is quite a change for me considering the last project I was on was over 4-5 years ago. Anyway, it’s been good to get my Launchpad user ID” back in use as the LottaNZB project is hosted on their services.

As well as LottaNZB, I’m also adding to the Python bindings for MythTV. At the moment the existing bindings only support simple operations and I’m expanding it out to abstract out most of the major concepts within the DB, for example channels and programs. Hopefully, they’ll provide useful in the future when I need to do a channel rescan.

The eee-acpi module, hacked by Asus from the asus-laptop module, currently manages the kill switches for the various extra hardware (wifi, cardreader, webcam) and also handles the extra Fn keys via ACPI events.

While hotkeys via ACPI are well supported by acpid and its ilk it is no longer the best way to handle these types of keys. Generally, the drivers for the mainstream laptops (ibm/lenovo, hp) have moved over to the input framework to communicate these key presses, usually displaying as an extra input device under /dev/input. These input devices can be handled by HAL and notifications of key presses send over the dbus allowing for desktop environments such as GNOME to handle these events without any strange hackery and fakekeys calls.

Thanks to the previous work of the asus-laptop developers there’s a patch that exists to disable the existing ACPI events and provide a input device for the extra keys, I’ve managed to hack together a version of the eeepc-acpi module using the Debian 1.01 source to export the “Asus Extra Buttons” input device.

After you have the inputs available, it’s a simple matter of producing a FDI for HAL to identify the device and map the scan codes to the actual keys. After the initial FDI was created I could use the volume keys without any extra software and also map the two application buttons (marked as VGA switch, and AP button) in GNOME to call scripts. The wifi key (Fn+F2) presented more of a problem, while it was mapped to “wifi” HAL didn’t know how to actually switch off the Atheros card. The killswitch for the card would need to be implemented as a program that listens to dbus, something a little outside my skill set.

The other buttons on the keyboard (sleep, brightness) are pure ACPI calls. This presents a problem that the keys produce events via the input layer and the ACPI layer at the same time, so for example you hit the brightness down button and HAL will pickup the notification and display the brightness OSD, but it quickly goes out of sync as what HAL sees and what the ACPI are doing are completely separate. Again, this is outside my skill set but I’d probably approach it by filtering out the keys in the kernel and let the ACPI events do their work.

The guys over at Fedora have a similar idea of moving over to an input based module, but for the moment no source has been produced. Due to the numerous little issues I’ve had I’ve decided to put this little project on the back-burner until I see what the Fedora people have produced, after all they’ll have people that are more experienced in this type of thing, whereas I am not.

I’ll get round to posting the source deb for the modified eee-acpi tonight or tomorrow.