PackageKit

Time for another rant. It's a short one: PackageKit needs to be configurable. PackageKit is a good thing, in my opinion - it makes installation of packages much more flexible, for instance, users can install packages directly from web pages simply by clicking on links and authenticating. I particularly like the command-not-found functionality: when a user issues a command that isn't installed on the machine, their shell informs them which package should be installed to use this command and can offer to install the package there and then. Nice.

However. All this is directed rather specifically to a single use-case of the machine: the home desktop user. Home users probably want to have most updates automatically install, and to be able to install packages with a single click on  a web page. In the office environment, this is not always so desirable - automatic updates might be, but perhaps only security updates. Users installing arbitrary packages without authentication, certainly not. In fact, anything that might require authentication should be disabled, as users will almost certainly not have root access to their machines.

One answer is to uninstall PackageKit completely, but it does have some useful features. I have altered the command-not-found function to inform users that they should email the administrators requesting the package to be installed. This makes the system a little more friendly, which is only a good thing. The other, much better, answer is to allow thorough configuration of PackageKit. At the moment all you can do is specify which network devices/daemons to use, specify timeouts and bandwidth usage, and a few other little tweaks. I need to be able to allow automatic updates without authentication, but disable all references to installing new packages. That shouldn't be difficult, it should be easy.

Printing: CUPS rules

Here we have an example of something where Linux is well ahead of the competition: Printing! Fifteen years ago I wouldn't have believed it, but here we are. CUPS rules. It rules so much that Apple recently took it over - a fact which actually makes me a little nervous, but it's released under the GPL so they can't do that much damage.

After using CUPS for a few years, it's very strange when I have to go back to the way Windows deals with printers. Drivers installed on every workstation? But why? And how sodding big are these binary drivers?! With CUPS, the only client configuration you need to do is one line, in one config file, saying 'ServerName foo.bar.org'. When someone gets a new printer, you add it to the print server using the incredibly simple web interface. If it's a new model of printer you may need to download the driver for it - another nice surprise: the drivers in CUPS are single text files. You can even edit them to change the printer settings before adding them to the server, but you can of course change these settings afterwards instead. Once the printer is added to the server, it's immediately available on all the clients.

Let me reiterate, as this is important: immediately available on all the clients. Users can see the printer in their applications right away. No configuration needed, no 'connecting to the printer', no nothing. That's proper enterprise IT, right there.

Linux needs an RDP

This is going to be a really short post, because there's not much to say about this. Something that Windows does very well is RDP, the remote desktop protocol. It's by far the best way of getting a remote (as in over-the-internet) full desktop environment I've used - fast, smooth, no different from sitting in front of the local machine.

Linux has a couple of alternatives to RDP; primarily just using X over the network or forwarded through an SSH connection. You can either launch individual applications on remote computers, or get a full remote desktop using XDMCP. This is great when you have a fast network link to the machine you're working on, but slows horribly when you have a limited bandwidth link. The second alternative is VNC - a cross-platform protocol that works by basically taking screenshots of screen areas that change, compressing them, and sending them to a client running on your computer. It's quite a lot faster than X over the internet, but still not fast enough. Incidentally, this is what Mac OS uses as its remote desktop protocol.

Come on, let's have a good fast remote desktop protocol! It's worth some effort - X is the best window system there is, with an RDP equivalent built in it would be awesome.

gettext - Edit text within GUI elements

Say you want to change arbitrary text within a GUI element, the little pop-up that tells you when new updates are available for instance. You want it to say 'The following updates will be installed when you shut down your computer' instead of 'The following updates are available' or something. It's remarkably straightforward.

A lot of the internationalization (or is it localization?) within Linux GUI elements is handled by gettext .mo files, which list the translations of text elements for all the supported languages. In our example, the GUI element we want to change is part of the Fedora package gnome-packagekit. The English translations for the gnome-packagekit package are kept in /usr/share/locale/en_GB/LC_MESSAGES/gnome-packagekit.mo. To change the text for a specific element, you have to unpack the file using msgunfmt, edit it with poedit, then repack it with msgfmt. Like this:

1) Find the gettext file containing the text you want to change. In Fedora, they're filed by language in /usr/share/locale/ - grep is your friend here.

2) Unpack the file:

cp /usr/share/locale/en_GB/LC_MESSAGES/gnome-packagekit.mo /usr/share/locale/en_GB/LC_MESSAGES/gnome-packagekit.mo.bak
msgunfmt /usr/share/locale/en_GB/LC_MESSAGES/gnome-packagekit.mo > ~/gnome-packagekit.po

2) Edit the file. Search for the text you want to change, and change it:

poedit ~/gnome-packagekit.po

3) Repack the gettext file:

msgfmt -v -o /usr/share/locale/en_GB/LC_MESSAGES/gnome-packagekit.mo ~/gnome-packagekit.po

Bob's your uncle.

Fedora updates

This first rant will be specifically aimed at Fedora, and their update policy.

Here is how I think it should be: Your distribution is released; you support it with updates that either a) fix horrible glaring bugs or b) close security holes. Fedora release a new version of their distribution every six months. Great! That's short enough that users won't get irritated at having to use very out-of-date packages between releases. But wait! What's this I see in my updated packages list? 200 updates, of which most are 'new feature' updates and only 8 security updates?

I have a simple question for the Fedora developers: Why can't those new feature releases wait for the next distribution release? As it is, if I want to let all my Fedora machines use the official update repository, they'll be getting hundreds of updates every month - and some of those updates are broken. Badly broken. I need to be able to test the updates that are applied to my machines, and testing all those updates every month would be a massive time drain. It's simply unfeasible.

My current 'solution' (it's really not much of a solution) is to host a small local repository containing only those official updates that I think are worth using. It contains packages for which regular updates are demanded by users (e.g. Firefox) and packages which fix really horrible security holes. Does it contain all the updates marked as security updates? No, because this information is so hard to find it's like getting blood out of a stone. I know the information is there within the individual packages because the fancy graphical update nagger tells me so, but how can I download only the security updates from the Fedora updates repo? I don't think I can, Fedora!

I certainly don't choose to include packages that mess with the guts of the system, due to Fedora's lamentable record of breaking things in updates. Kernel updates? No way. Certainly nothing to do with sound. kde*? I don't think so. If the Fedora devs are pointing their fingers at the upstream developers, that won't do - you don't need to include broken packages in your updates. Just leave them out. It's easy. Your users will thank you. If the new, broken version of a package fixes an old security issue, patch the old version of the package! It's open source! You can do this!

Well, that's about all I have to say 'bout that. I'll just keep on cherry-picking updates for my local repo. And grumbling, of course.