Month: June 2008

LSB Package API

The LSB Package API is an recently suggested interface that allows ISVs to install LSB-compliant applications in such a way that they are integrated into the distribution’s packaging system.
This enables users to manage third-party software packages as easily as packages installed from the distributor, and frees ISVs from the need to provide packages for different packaging systems in order to achieve integration with the distribution.

This is meant to be a low level library with minimal dependencies that can be used by ISV’s.

Summary:

Uses a DBUS service: check
Uses pluggable backends: check
Use PolicyKit: check
Use an XML parser: check
System activation: check
Define own linked list implementation: check
Try to solve a problem that doesn’t exist: check

This “give packaging power to users thing” has been tried before a few times before and fallen on it’s face each time. There’s a reason that PackageKit uses the distro supplied packages, rather than trying to define it’s own package and metadata format.

I’ve spent nearly a year developing PackageKit on many distros, talking to customers and software vendors and I’m really struggling to see the viability of a LSB Package API. So few people care about the LSB, and the vendors that do, don’t want to be using a PolicyKit enabled dbus-activated service just so an admin can copy files to a disk.

If there was a requirement for a distro-neutral 3rd party application installer (which I don’t think there actually is) then it should be a tiny shared (static?) library that just depends on libc or /bin/sh.

PolicyKit, DBUS, XML should all be left waaaay higher in the stack, something like, cough, PackageKit… I’m afraid the LSB Package API has got caught in the classic new project trap of “wouldn’t it be cool if we used ${technology}” and actually forgotten to ask customers what they want. I just think the committee has lost the plot a little on this one.

LSB Package API: FAIL.

Red Hat (cool)

I’m at the Red Hat summit in Boston. I’ve met loads of cool people I’ve only ever talked to on IRC, and it’s been great to drink beer with them in person. I’ve been staying with Ray and Mo, and they’ve really made me feel really welcome for the last few days, which I really appreciate. I’m not one to normally get emotional, but deciding to work for Red Hat was probably one of the best decisions I have ever made. Red Hat, ROCK ON.

Power trends

Matthias asked me the other day if I could do a longitudinal study of power consumption of Fedora. I used my new T61 with Intel graphics for the study as this is the machine I use every day. Anything older than F8 failed to boot (SATA?) and so the results are a little short. I will repeat the same test on some older hardware when I have a spare couple of hours next week.

So, what can you take from this graph:

  • When suspend works well, it uses hardly any power
  • Playing high fps-movies fullscreen is bad for your battery.
  • Anything involving large amounts of hard-drive and CDROM accesses will drain your battery.
  • You can save about 4W by turning your brightness down, and 10W by turning the panel off completely.
  • As a trend, linux seems to be getting better at this powersaving thing.

Note: F9 starts with the brightness less than 100% due to a kernel/hal/userspace bug.

So my personal 400ft conclusions:

  • We should dim on idle by default, and turn this option on even when on AC power
  • We should make suspend and resume faster so we can automatically sleep and resume when idle.

I’ve also been playing with other powersaving techniques like knobbling dirty writeback, noatime, ALPM, changing the screen refresh rate and also powering down cores on a CPU. I’ll blog about these later.

If you are interested in this sort of stuff, I’m presenting at the Red Hat summit next week in Boston with a paper titled “Laptop power management”.

Jumping over the wall

Quite a few people have been saying we need to break major versions for GNOME, and create something new and exciting to increase our userbase for 3.0. Nonsense. There’s nothing saying you have to develop big new features in one release cycle. Something large like the new gdm2 rewrite can be done over a couple of release cycles, fixing the other broken bits along the way. The only slight problem is the deprecated (and broken) code in GTK, but that’s an argument for another day.

People don’t use GNOME because they can see cool OpenGL widgets whoosh around a screen. People use GNOME to actually do things. People use GNOME to write letters, edit photos, surf the net and read some news. For instance, I run without compiz turned on, as I find I work faster without any of the wizzy visual effects. The 0.1% of uber geeks (I’m not sure if I include myself in that number) that want to write cool new stuff need to remember that just because it’s possible, doesn’t always mean it’s a good idea.

I see this effect a lot with the new KDE, with it’s abstractions on abstractions and also visual widgets that can be spun, twisted and shaped. For example, I saw a preview of KDE 4.1 where there was a circular analogue clock widget. Hover over it, and you can rotate the analogue clock to any arbitrary angle. Just because it can be done, don’t mean it should be done.

So, all those of you who say we need radically new designs in GNOME 3.0, keep that moto in mind.

PackageKit bundles?

There’s one use case that I’m very interested in, and that is getting new users with the correct environment to build and start hacking on software or using other software tools. For instance, on www.packagekit.org in the FAQ section, we can have a link to install build files to start hacking on PackageKit.

Now, this .bundle file is handled by gpk-install-bundle that parses this file and causes the appropriate packages to be installed if they are not already installed. This rocks as we can get GTK+, Xorg hackers up to speed with the minimum of fuss and confusion. It also lets people put links on webpages to “install all the stuff you need” when writing a “how to use a scanner in GIMP” howto.

So, what does a .bundle file look like?

[PackageKit Bundle]

# Just a package on all versions of fedora that can provide the dependency.
# If there are multiple packages then the user will be asked to choose
InstallProvides(fedora)=audio/QCELP

# Just for Fedora 9, install two development files
InstallPackages(fedora-9)=glib2-devel;PolicyKit-gnome-devel

# On any distro, install the package with this file
InstallFiles=/usr/bin/fontinst

# For each architecture on Fedora 8, install one of the two different compat files
InstallFiles(fedora-8-i686)=/usr/lib/pango/1.6.0/modules/pango-arabic-fc.so
InstallFiles(fedora-8-x64)=/usr/lib64/pango/1.6.0/modules/pango-arabic-fc.so

You’ll notice the distro-id in between the ()’s – this lets a packager fine tune the package name, where for instance in Debian the package is called policykit and Fedora PolicyKit. You can specify a granularity of distribution, distribution-version or distribution-version-architecture – PackageKit will process all the entries that apply. It’s of course better to not specify a () if possible, as this lets the file work on as many distributions as possible out of the box.

There’s also no version checking – intentionally – the distro should be specified and have the correct data. If there’s an optional package not in earlier versions then you can do something like this:

[PackageKit Bundle]

# Fedora 9 does not have Unique
InstallPackages(fedora-9)=glib2-devel;PolicyKit-gnome-devel

# Rawhide is fedora 9.90
InstallPackages(fedora-9.90)=glib2-devel;PolicyKit-gnome-devel;unique-devel

There’s also no description of the bundle that needs translating and verifying – they are just lists of packages, files and provides that might be useful. All the translations come from the distributions metadata, and it’s up to the user to verify the package lists that are asked to be installed, so there are no signing or trust issues.

Note: this isn’t designed to replace one click install, it just does something that is similar in a different way.

Comments? Suggestions?