How not to improve your package updater application
Earlier today I tweeted:
Every time I use the Fedora 16 gpk-update-viewer I'm filled with anger for what someone did to a nice, usable program.
Now I feel like explaining that (in the spirit of an earlier entry). First,
gpk-update-viewer is the program behind
the 'Software Update' information display on Fedora systems; it's part
In Fedora 15, the (Gnome) interface for it has two relatively minor issues (which you can actually see in the current screenshots on the PackageKit website): it doesn't group the updates into separate sections for security updates, bugfix updates, and regular updates, and it always shows the 'Details' area even if you're not interested in it. In the Fedora 16 version, someone decided to fix these problems. To properly appreciate the result, I must show you a picture (which I am not going to inline here because it's too big): a screenshot of the Fedora 16 gpk-update-viewer.
The Fedora 16 version has certainly fixed those two little problems; the Details area can now be folded away, and updates are now grouped. However this 'improvement' has created all of the following issues, many of them disastrous:
- the 'Details' area for the details of the updates is not resizable; it's fixed at four and a bit lines, which is completely and utterly inadequate for usefully reading those details without endless scrolling. I am now very glad that I recently contrived a scroll wheel.
- if you scroll the 'Details' area (and you will be) and then move to another package, the area's scroll position is not reset to the top. It doesn't always stay static either; at least sometimes it shifts oddly.
Since the entire reason I'm running
gpk-update-viewer at all is to
read the update details, this change alone is a huge usability loss. (I
check for and actually apply updates through
yum, but as far as I know
g-u-v is the only tool for seeing the update text (which is not the same
as the RPM changelogs).)
- there is no longer any indication of if the update will require
a system reboot or for you to log out and back in again. Fedora
15 annotated such updates with little icons.
- Fedora 15 mostly grouped all related binary packages together as a
single entry (which you could expand to see the list of individual
packages that would be updated). Fedora 16 lists every binary
package separately, even in cases where an update to a single
source package produces a shower of fifteen or twenty updated
(You can see this in the screenshot; in Fedora 15, there would not be separate entries for 'cheese' and 'cheese-libs'. Fedora 15's version of this was incomplete, but it was still much better than not having this at all.)
- Those headings for the type of updates you see in the screenshot ('Security updates' and 'Bug fix updates') are actually selectable entries. You can click on them and, more importantly, if you are scrolling through the list of updates you will wind up on those headings too (and have to explicitly scroll past them). This is especially irritating while you are using the arrow keys to scroll to the next entry because your mouse cursor is in the Details area so you can use your scroll wheel to read the update details.
And on a slightly more minor gripe, the Fedora 16 version always starts up with a completely crazy window size when I run it under fvwm in my normal configuration. No other Gnome program seems to have this problem and the Fedora 15 version was (and is) fine.
(Fedora 15 has gnome-packagekit 3.0.0; Fedora 16 has 3.2.1. Sadly the Fedora 15 binary doesn't work on Fedora 16, but maybe I can recompile the old version from source.)
What debugging info I want from things like SMF and
I've recently been tooling around in both SMF and
systemd, so I've
developed some strong opinions on what startup systems like this need to
provide to help working sysadmins. It will probably not surprise you to
know that neither SMF nor
systemd deliver entirely useful information
There are two sorts of service startup problems, which I'll call the
simple and the complex. The simple question is 'why did this service
fail to start'. To answer this sysadmins need to know exactly what
was run and what happened to it, ideally including its output and log
messages; if the service wasn't started because of missing dependencies,
we need to know what they were. SMF and
systemd both half-heartedly
deliver this today.
(Neither has output that is optimized for making it clear if a service is not enabled at all, is enabled but had missing dependencies, or if it was enabled and failed to start or died later. In fact distinguishing between 'failed to start' and 'seemed to start fine, died later' is actually fairly important but doesn't tend to be reported well.)
The complex startup problems are ordering problems, such as our recent issues with ZFS pool activation and iSCSI disk discovery. To deal with these issues, you need two things: you need to know the actual order that service startup both started and finished in (you need both because in a modern system several services may be starting at once), and you need to know why, ie the service dependency graph. In fact you want several views of the service dependency graph, for example the transitive expansion of dependencies both ways for some service: 'everything that has to be up for this service to start' and 'everything that requires this service to be up'. It's also handy to be able to ask questions like 'does service X depend on service Y in some way, and if so how?'
This is mostly missing in SMF and
systemd today, as far as I can
see. It's possible that
systemd can be coaxed into giving you the
information, but if so how to do it has been carefully hidden from
(As an example of getting it incomplete, SMF will give you direct dependencies in both ways but not indirect ones, which leads to a frustrating game of 'chase the dependency'.)