Year: 2008

PackageKit support status

The entire purpose of PackageKit is to abstract out all the uninteresting packaging formats and tools into a coherent API that can be used by cool applications and tools in a cross distribution and architecture way.

Of course, this is limited by the distribution guys putting in the effort writing PackageKit backends for their system, packaging it up into packages, and then deploying it in new distributions to hapless users.

So far, we have quite a few distributions shipping PackageKit by default, and there’s every indication that a large majority will be shipping PK by the end of the year. Recently I’ve been very impressed with the work of Sebastian Heinlein integrating PK with APT. It’s been pretty difficult, as he’s been patching (rewriting?) chunks of python-apt so that the PackageKit API can be completed. For SMART, Anders F Bjorklund has also been writing huge chunks of code, which is also great.

Screenshot of some of the tools on Ubuntu (Copyright Sebastian Heinlein)

You can see how the other distributions are doing here.

PackageKit 0.3.x new features

PackageKit development keeps on trucking. After the ServicePack functionality was added in 0.3.0, we’ve got the GetDistroUpgrades functionality in the soon to be released 0.3.1 The latter allows us ask the backend if there are distro upgrades, for example, when Fedora 10 is released. By default we check for this one a week.

I’ve not really thought about the UI for the notification (and traditionally I suck at UI design), and so I welcome advice and comments from you guys. I’ve got this so far:

PackageKit UI Improvements (and 0.2.3)

Well, I’ve just released PackageKit 0.2.3 (stable) into the world. I’m going to build this for Fedora 9, as it’s a massive improvement over 0.1.12 and should have no regressions and plenty of nice features compared to that old version. It’ll sit in updates-testing for a few weeks, and if there are no problems I’ll push it to updates.

Of course, declaring the 0.2.x branch as stable allows us to all do some cool stuff on master. We’re working on making the UIs look beautiful.
Two examples are below, for installing more packages to satisfy deps, and also removing other packages if you chose something with dependants.

We’re also fixing up the file viewer to be a treeview, as a long list of files to scroll though is pretty boring. We welcome newcomers if you want to have a try at this hacking thing.

latency-policy

Latency is the time delay between the moment something is initiated, and the moment one of its effects begins or becomes detectable.

Why do you care? Well, some power management modes save a ton of power, but also increase the time it takes to respond to these interrupts.
Most users don’t care as these delays are typically in the μs or low ms range, but you might if you’re on a server processing financial data or mixing desk with 20 real time music streams.

A new project is born. latency-policy is a set of scripts that allow an admin to define a rough latency that is acceptable. Why latency? Well most of the power saving stuff we are working on saves a bunch of power doing things like turning off hardware or powering down data links. These all have different, non-trivial reinitialisation times, which is why we probably need some sort of simple userspace tool to set these at startup according to some simple metric. We really don’t need to (or want to) export all these settings to the UI as most of them are pretty meaningless to 99.99% of users. At the moment only things like ALPM, ASPM and ondemand are supported by latency policy, but it’s designed to be easily pluggable as other schemes become possible to be used in Linux. There’s a 0.1 release (that may or may not work on your system) here, a noarch rpm for fedora here and a git tree available on my people page (git clone git://people.freedesktop.org/~hughsient/latency-policy).

Patches welcome. There’s no mailing list as this is a super trivial project, but I really would like to see some buy in from distros for this sort of system policy stuff. Thanks.

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”.