Random stuff

<tt>bgchannel://</tt> Considered Harmful?

  • Post author:
  • Post category:Uncategorized

Recently Bryan posted about background channels — a system for automatic updating desktop wallpaper. One of the features of the design is a new URI scheme based on the same ideas as webcal://, which I think is a bad idea (as dobey has also pointed out).

The usual reasoning for creating a URI scheme like this go something like this:

  1. You want to be able to perform some action when a link in a web page is clicked.
  2. The action requires that you know the URI of the link (usually to allow contacting the original server again).
  3. When the web browser activates a helper application bound to a MIME type, you just get the path to a saved copy of the resource, which doesn’t satisfy (2).
  4. Helper applications for URI types get passed the full URI.

So the solution taken with Apple’s iCal and Bryan’s background channels is to strip the http: off the start of resource’s URI, and replace it with a custom scheme name. This works pretty well for the general case, but causes problems for a few simple use cases that’ll probably turn out to be more common than you think:

  • Serving a background channel (or calendar, or whatever) via a protocol other than http. The first alternative protocol you’ll probably run into is https, but there may be other protocols you want to support in the future.
  • Any links to a background channel will need to be fully qualified since they use a different scheme. If you move your site, you’ll need to update every page that links to the background channel. If you could use relative URIs in the links, this wouldn’t be the case.

One alternative to the “new URI scheme” solution, that doesn’t suffer from the above problems is to serve a “locator file” from the web server that contains the information needed to request the real information. Even though the helper application will only get the path of a temporary file, the content of the file lets the app connect to the server. This is the approach taken by BitTorrent, and various media players like RealPlayer.

The separate “locator file” can even be omitted by placing the background channel location inside the background channel itself. This is the approach taken for Atom, via a <link rel="self"/> link.

29 April 2005

Ubuntu Down Under

I have been in Sydney for the past week for UDU, which wraps up tomorrow. It has been great meeting up with everyone again, but has also been exhausting.

Some of the stuff on the horizon will be quite ground breaking. For instance, I don’t think anyone has attempted something like Grumpy Groundhog (which will hopefully be very useful to both the distro team, and upstream projects like Gnome).

Python

Experimented with using the new ELF visibility attribute support in GCC 4 in Python, and came up with this patch. It restricts the list of exported symbols to just the ones marked with the PyAPI_FUNC and PyAPI_DATA markers, which omits all the private symbols that /usr/bin/python or libpythonX.Y.so export.

In addition, it uses “protected” visibility for all the exported symbols, which means that internal calls to the public Python API don’t have to go through the PLT (which they do if Python is compiled as a shared library).

In the shared libpython case, this speeds things up by about 5% (according to pystone and parrotbench), which isn’t too bad for a small patch. In the static libpython case, it seems to slow things down slightly — by < 1% in my tests so far.

Of course, the shared libpython case is still slower than the static version (which is why /usr/bin/python doesn’t use a shared libpython on Ubuntu), but it does make it less slow than it was before 🙂

Solaris

Glynn: If Solaris feels like a second class citizen, it is probably because hardly any hackers have access to Solaris machines (the same seems to be true of architectures other than i386). A fair number of developers would probably be interested in fixing Solaris build failures if they knew that they existed.

I realise that Sun doesn’t want to provide external access to a build machine (at least, that’s what I was told last time I asked some Sun/Gnome hackers), but maybe running a tinderbox style system and publishing the build logs would help. As well as telling me if my package is broken, it’d give me a way to tell whether the fixes I check in actually solve the problem.

pkg-config

One of the changes in the recent pkg-config releases is that the
--libs output no longer prints out the entire list of
libraries expanded from the requested set of packages. As an example,
here is the output of pkg-config --libs gtk+-2.0 with version
0.15:

-lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0
-lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0
-lgmodule-2.0 -ldl -lglib-2.0

And with 0.17.1:

-lgtk-x11-2.0

If an application is compiled with the first set of -l
flags, it will include DT_NEEDED tag for each of those
libraries. With the second set, it will only have a
DT_NEEDED tag for libgtk-x11-2.0.so.0. When run,
the application will still pull in all the other libraries via shared
library dependencies.

The rationale for this change seems to boil down to:

  • Some programs link to more libraries than they need to.
  • Sometimes programs link to libraries that they don’t use directly
    — they’re encapsulated by some other library they use.

  • The application will need to be recompiled if one of the libraries
    it is linked against breaks ABI, even if the library is not used
    directly.

At first this seems sensible. However, in a lot of cases
applications actually use libraries that are only pulled in through
dependencies. For instance, almost every GTK application is going to
be using some glib APIs as well.

With the new pkg-config output, the fact that the application
depends on the ABI of “libglib-2.0.so.0” is no longer
recorded. The application is making use of those APIs, so it declare
that. Without the glib DT_NEEDED tag, the application is
relying on the fact that GTK isn’t likely to stop depending on glib
…

Furthermore, this causes breakage if you link your application with
the libtool
-no-undefined flag. On platforms that support it, this
generates an error if you don’t list all the libraries the application
depends on. This allows for some optimisations on some platforms
(e.g. Solaris), and is required on others (e.g. Win32).

(interestingly, this problem doesn’t exhibit itself on Linux.
The -no-undefined flag expands to nothing, even though the
linker supports the feature through the -zdefs flag)

For these reasons, I’ve disabled the feature in jhbuild’s
bootstrap, using the --enable-indirect-deps configure flag.
If the aim is just to get rid of unnecessary library dependencies, the
GNU linker’s --as-needed flag seems to be a better choice.
It will omit a DT_NEEDED tag if none of the symbols from the
library are used by the application.

The Colour Purple

If you look at the bottom of Cadbury’s website in the footer of the page, you find the following text:

…, and the colour purple are Cadbury Group trade marks in Australia.

Apparently Cadbury believes they can trade mark a colour, and according to a story on the radio they’ve been sending out cease and desist letters to other small chocolate makers in Australia.

It turns out that even though they are claiming it as a trade mark, they only have a pending application. The details can be found by going to here, choose “enter as guest”, and enter “902086” into the search box at the bottom (it doesn’t seem like you can bookmark a particular application).

It seems that the application has been pending since February 2002, and was deferred at the applicant’s request 5 months later. So it seems weird that they’ve started trying to assert it now. The 17 categories the application mentions include soaps and perfumes, jewellery, kitchen utensils, clothing and leathergoods (it also includes classes that you’d expect a chocolate company to claim).

It seems like a clear abuse of the trade mark system, and I’m surprised it isn’t getting more news coverage.

New pkg-config

I recently pointed jhbuild’s bootstrap module-set at the new releases of pkg-config, which seems to have triggered some problems for some people.

In some ways, it isn’t too surprising that some problems appeared, since there were two years between the 0.15 and 0.16 releases. When you go that long without testing from packages that depend on you, some incompatibilities are bound to turn up. However, Tollef has been doing a good job fixing the bugs and 0.17.1 fixes most of the problems I’ve found.

So far, I’ve run into the following problems (some reported to me as jhbuild bug reports):

  • PKG_CHECK_MODULES() stopped evaluating its second argument in 0.16.0. This caused problems for modules like gtk+ [#300232, fd.o bug #2987 — fixed in pkg-config-0.17].
  • The pkg.m4 autoconf macros now blacklist words matching PKG_* or _PKG_* in the resulting configure script (with the exception of PKG_CONFIG and PKG_CONFIG_PATH). This is to try and detect unexpanded macros, but managed to trip up ORBit2 (ORBit2 has since been fixed in CVS though). [#300151]
  • The PKG_CHECK_MODULES() macro now uses the autoconf result caching mechanism, based on the variable prefix passed as the first argument. This means that multiple PKG_CHECK_MODULES() calls using the same variable prefix will give the same result, even if they specifiy a different list of modules [#300435, #300436, #300449]
  • The pkg-config script can go into an infinite loop when expanding the link flags if a package name is repeated [fd.o bug #3006, workarounds for some Gnome modules: #300450, #300452]

(note that only the last problem is likely to affect people building existing packages from tarballs)

Appart from these problems, there are some new features that people might find useful:

  • Unknown headers are ignored in .pc files. This will make future extensions possible. Previously, if you wanted to make use of a feature in a newer version of pkg-config in your .pc, you’d probably end up making the file incompatible with older versions. This essentially meant that a new feature could not be used until the entire userbase upgraded, even if the feature was non-critical.
  • A new Url header can be used in a .pc file. If pkg-config finds a version of a required package, but it is too old, then the old .pc file can print a URL telling people where to find a newer version. Unfortunately, if you use this feature your .pc file won’t work with pkg-config <= 0.15.
  • A virtual “pkg-config” package is provided by pkg-config. It doesn’t provide any cflags or libs, but does include the version number. So the following are equivalent:
    pkg-config --atleast-pkgconfig-version=0.17.1
pkg-config --exists pkg-config '>=' 0.17.1
    This may not sound useful at first, but you can also list the module in the Requires line of another .pc file. As an example, if you used some weird link flags that pkg-config used to mangle but has since been fixed, you can encode that requirement in the .pc file. Of course, this is only useful for checking for pkg-config versions greater than 0.16.