Big changes

Today I resigned from my graduate hardware engineer position at BAE Systems. In a little over one months time I will be starting at Red Hat UK, with Jonathan Blandford as my boss. I'll primarily be working on laptop support issues, but with a bit of time spent on PackageKit and other cool stuff. This is a great opportunity for me, and I'm really looking forward to solving new problems. Good news.

Service Packs and PackageKit

Microsoft Windows has the concept of service packs, i.e. a large package containing all the fixes to date. Service packs are really useful if a computer only has no (or slow) network connectivity and the whole system has to be updated on multiple computers.

I think some sort of PackageKit integration with a “service pack” type DVD/CD would be useful. Note, this concept is totally different to one click install, as it has a different perspective.

I think the ideal use case is this:

  • [1] insert CD/DVD/PenDrive with service pack .debs and .rpms on
  • [2a] cdrom is autorun by gnome-volume-manager and the location passed to gnome-packagekit to initiate a service pack update
  • [2b] gnome-packagekit watches for a cdrom to be inserted
  • [2c] packagekitd watches for a cdrom to be inserted and triggers a client side signal (means client doesn't have dep on libhal, and the daemon can Lock() the cd device from ejecting when the transaction starts)
  • [2d] gvfs does a new-fangled thing for autolaunch and tells gnome-packagekit
  • [3] gnome-packagekit asks the user to confirm it's valid update media, asks for PolicyKit auth and runs the ServicePack() backend method on the media device.

For [2] we'll need an identifier that can be recognized by PackageKit, maybe just the presence of the file packagekit-autostart.ini on the CDROM or DVD. The format of this file can be trivial, something like:

[PackageKit Autostart Section]
DataLocation=Fedora/updates/rpm
DistroName=Fedora8

For [3] we can make the ServicePack() method just do something like “yum local update /media/DiscFoo/Fedora/updates/rpm/*.rpm” (backend specific, and within yumBackend obviously).

Michael Vogt has already worked on add-on cds for Ubuntu, and I think there's some momentum for this for Fedora also. I really think this could rock.  I'm also after a better name than ServicePack, maybe UpdateMedia or UpdatePack might be better choices.

Comments?

Cool localisation stuff happening with PackageKit

Package spec files and PackageKit backends are rarely localised. This doesn't matter much if you speak English, but really sucks if you don't. We can't fix all the distro tools and all the packages in the world, but we can do our best to be clever:

This is with my locale set to “en_GB” and the libpackagekit results hardcoded to “fr” – the two will match up eventually of course.

Theres a new GObject called PkExtra in libpackagekit that lets you query (as a user) a small cached sqlite repository containing all the localisations and icon names. The data from this is populated per system (as root) from a few information sources:

  • All the installed desktop files in /usr/share/applications (this works now)
  • Metadata from the online desktop project (to get things like popularity, WIP)
  • Information about non-installed packages generated from the distro builder (WIP)

I don't think caching the installed icons and shipping them seporatly is a good idea, just from a size point of view.

The sqlite database is currently at 200kb in size with 201 applications installed (i.e. things that ship desktop files) so I'm guessing it would be couple of Mb with the entire fedora repository of information in and the online desktop stuff. Of course, being sqlite, it's very quick to query.

Updating the offline repo would be left to the distro packager, as of course, this stuff is all per-distribution. There is lots of stuff still to work out, but slowly, it's coming together. Comments welcome.

Nouveau Progress

I compiled the new mesa today, so I could try out the latest nouveau 3D stuff:

So close….. yet so far.

Some stuff rocks hard with the new stuff, in particular supertux runs really well now :-)

Also, thanks to Stuart Bennett, My LCD panel now uses the same dithering as the binary blob. This means it looks as good with the free driver as with the blob. We're still thinking about how we can work out what bit corresponds to FPDither.

If you are coming to FOSDEM, make sure you add Stephane Marchesin and the other guys in #nouveau to your drinks list. :-)

Dear NVIDIA and LENOVO

Dear NVIDIA and LENOVO,

Please can you tell me what bit in your NV4x BIOS corresponds to if_is_18bit, i.e. if my LVDS panel supports 24 bit colour or not.
I do understand telling the nouveau developers such business-critical pieces of information could impact future profits, and I do understand that documenting magic numbers means that the numbers could be seen by both ATI and Intel robbing you of trade secrets and your interlectual property. Not.

Thanks.

In other news, Richard was annoyed by having to manually add Option “FPDither” in xorg.conf to stop his Lenovo LVDS display looking rubbish.

p.s. Does anyone happen to have a biosmod scp file for a NVIDIA nv40 bios? Beers a-plenty if you share.

Nouveau performance improvements

I blogged a few months ago about performance improvements in nouveau, the free 3D driver for NVIDIA cards. This morning I tested with nouveau ddx from git, drm master from git and kernel 2.6.24-rc6 and used the gtkperf benchmark.

Nouveau 2007-07-13: 25.24s
Nouveau 2007-12-30: 17.88s

Quite an incredible increase in speed.

On another note, I've been able to resize my screen for the first time using the normal driver, although using experimental Randr12 mode I get this:

Fun times with nouveau…