Having very little distribution experience outside of developing Gentoo for the last few years, I’ve found some aspects of Fedora’s binary package (RPM) workflow particularly interesting:

1. Automatically detected dependencies: In Gentoo ebuilds, we have to state that package A depends on library B. In Fedora, when building the binary package, the build tools determine many runtime dependencies automatically so there is no need for developers to manually list all dependencies in spec files.
2. Chroot build environments: All packages are built in an otherwise-empty chroot. The build system creates a chroot, quickly installs all of the base binary packages and the build dependencies, then builds/installs a package, produces a package, and throws the chroot away. This allows for predictable build environments and is good for QA.
3. Community access to the build box: All packages are built by Koji. Koji has a nice “scratch-build” system where you can throw a source RPM at it, and it will build it and serve it back to you on a webpage a few minutes later. Great for build testing and handy if you don’t have a complete build environment locally. The scratch-build service is open to non-developers assuming they have been through the click-through contributor agreement.
4. Subpackages: It’s pretty neat how one spec file (equivalent to an ebuild in some ways - textual build scripts) can actually produce several packages. Your spec file takes one upstream tarball, unpacks/compiles/installs it, and then specifies which of the installed files belong to which subpackage.

Naturally, there are some drawbacks too:

1. Build dependencies: Even though many runtime dependencies are automatically detected, you still need to specify the components required for compilation. Remember, each package is built in a clean chroot. You end up having to specify most of the dependencies anyway (although it is still convenient in that you do not have to specify which subpackage has which dependencies - that is determined automatically).
2. No build customisation: OLPC have to fork a few packages which have wacky dependency chains, just to disable support for a certain feature or whatever. Forking away from upstream is undesirable but sometimes necessary. For example, we had to disable libgnome support in GNOME’s Python bindings to avoid libgnome being pulled into the build. libgnome was pulling in the following packages: audiofile bluecurve-icon-theme control-center-filesystem esound-libs fedora-gnome-theme fedora-icon-theme fedora-logos gail gnome-icon-theme gnome-keyring gnome-themes gtk-nodoka-engine libart_lgpl libbonoboui libgnomecanvas libgnomeui libutempter metacity nodoka-metacity-theme pyorbit. Ouch.
3. Convolution/confusion of build tools: To build a package, you can use rpmbuild to do it on your live system, or you can use mock to do the clean chroot thing I described above. Or you can use koji’s command-line client to upload it to koji. Not everything can be done through koji/mock, e.g. you still need to use rpmbuild to build OLPC’s kernel. Also, rpmbuild is the only tool that can build a source RPM, I think.

I’ve also been impressed by the Fedora development community. The community recently made the realisation that OLPC is Fedora’s biggest deployment (over 400,000 XO laptops worldwide, 55,000 more built and distributed each month, 100% of them running Fedora). Greg Dekoenigsberg recently announced the Fedora OLPC special interest group which sounds promising.

The learning lab is staffed by some key people, including David Cavallo from the MIT Media Lab and Cynthia Solomon, one of the original founders of Logo. These people have years of experience working alongside top scientists such as Marvin Minsky and Seymour Papert.

Last week, David Cavallo gave an enjoyable presentation about the education model behind the efforts of learning group. He shared some experiences from around the world and started a discussion on how to better integrate such ideals into the XO laptop and its software. The session has been published on dailymotion - if you’ve got an hour to kill, I’d definitely recommend watching it.

We have already supported another variant including a biometric co-processor for some time now, but in the absence of the co-processor, the sensor-only variant required a completely different driver. Support for the sensor-only devices is a significant step forward as this hardware can be found in a lot of laptops. I’ve already received some success reports - thanks!

The driver is only available in libfprint development repositories (not any released versions). System76 have created an installation guide which may be useful for keen users.

Download links:

• libusb-0.9.1
• libusb-compat-0.1.0-beta2

Today was my first day of a 14 week internship at One Laptop per Child, an exciting company producing cool laptops to distribute to children in developing nations with the aim of improving education. I’m going to be working on aspects of the XO software, starting by helping the efforts to upgrade to Fedora 9 for the v8.2.0 August release.

OLPC is based in Cambridge, MA, USA, and this is my 2nd time in this area. I’m living in Brookline until September, and then will need to find somewhere else to live for a month.

My plans for after the summer are uncertain. I’m thinking about hunting for some work in Europe somewhere, I might write more about that nearer the time.

The project is Linux driver development for a PCI frame grabber. Kernel experience is essential, and the important areas of knowledge are PCI and DMA. Location does not matter, this is a remote development project.

If you’re interested, or know anyone that might be, please drop me an email.

Lorin reports that his driver works reasonably well with his device - it works with camorama, xawtv, ekiga, amsn, mplayer and xsane. He has also determined how to adjust various camera settings (luminosity, saturation, hue, sharpness, retrolighting, mirror effects, light source, AC power frequency).

Although Lorin doesn’t actually own an 0503 device, he’s attempted to implement support for it based on my earlier efforts. Given that I didn’t get very far, it probably doesn’t work that well. I haven’t had a chance to try it, but there’s no point me sitting on this any longer.

It’s in my git repository in the nvgl subdirectory:
git://projects.reactivated.net/~dsd/gl860.git (gitweb).

All credit goes to Lorin here - thanks! He’s done a great job, but do remember that its experimental code based on a reverse-engineered protocol, so don’t expect it to be flawless.

1. Asynchronous transfer capabilities (in addition to the synchronous style presented by v0.1)
2. Support for transfers to isochronous endpoints
3. Significantly faster bulk transfer performance for large transfers (several kilobytes or more)
4. Detailed API documentation
5. Power saving: on systems running recent Linux kernels, libusb-1.0 does not wake up all the USB devices plugged into the system during device enumeration
6. Greatly reduced CPU usage while waiting for results of bulk/interrupt transfers (libusb-0.1 was waking up every 1ms)
7. Thread safety

Backwards compatibility

As noted on the homepage, libusb-1.0 is entirely incompatible with libusb-0.1. However, it is designed to install in parallel, in the same way that you can have GTK+ 1.2 and GTK+ 2.x installed on the same system and in use at the same time.

I have also produced a compatibility layer which replaces libusb-0.1. libusb-compat-0.1 looks and smells exactly the same as libusb-0.1 (same library name, API, header file, etc) but internally it just converts libusb-0.1 calls to libusb-1.0.

This means that existing libusb-0.1 applications can take advantage of some of the new libusb-1.0 hotness mentioned above: improved bulk I/O performance, decreased CPU usage, power saving. These improvements appear without any modification to the original application, provided that the user has uninstalled libusb-0.1, and installed libusb-1.0 plus libusb-compat-0.1.

Status

I’m hoping this release will result in:

• More testing and adoption
• API review and feedback
• Ports to other operating systems. Only Linux is supported at the moment, but the library is structured internally for other ports to be written, and the internal API is documented in the source.

Further API changes may happen as a result of the above. This is not a finished product.

Source download

• libusb-0.9.0
• libusb-compat-0.1.0-beta1

The source code for this project has been available on SourceForge from early on (GPL-2/LGPL-2 licenses). I’ve now completed and submitted a comprehensive project report (similar to a dissertation) for academic assessment, and I’m making this available under a Creative Commons license. You can find the report here.

The report is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 2.0 UK: England & Wales License.

The academic project is now complete, but I plan to continue development as time permits. There is a lot to be done, and I have already made some good progress on moving libusb-1.0 closer to release.

I am looking to rent a furnished bedroom in a location with access to public transport (I’ll need to get to and from Kendall/MIT each day).

If anyone knows of anything, please let me know.