oil prices

Classic.

how to be rich and famous

Stuart Langridge has great Google PageRank. So great, in fact, that his blog entry [how to be rich and famous](http://www.kryogenix.org/days/2003/02/12/famous) is on the first page of results for that phrase.

Take a look at the comments for a good laugh. There sure are a lot of kids who want to live the dream! Good luck guys, but I don’t think you’ll find the answer on Google somehow …

ps call if you need and movie star girl i am 12 …. i have blond hair and a pretty face please call i want to famous like hilary duff thanks

quicktime

Note: I wrote this several months ago. Things may have changed since (but I doubt it)

It’s been a long time since the version 4 release of QuickTime was [slated by usability pundits](http://homepage.mac.com/bradster/iarchitect/qtime.htm). Have they learned anything from this lesson in how not to write software? Let’s take a look at QuickTime 7 for Windows.

## Usability

At first glance, it seems Apple have fixed many of the mistakes they made with QuickTime 4 which is to be expected, given the huge span of time between both releases. It has a title bar now, though still a custom one, but almost everybody on Windows reinvents the title bar these days.

The rotary thumbwheel is gone too, and the volume control is now much more easily accessed although it’s still rather small.

First impressions on startup aren’t bad – it doesn’t take too long to load (though this may be biased by having iTunes running in the background), but there’s some flicker as it opens with the “Welcome to QuickTime” clip, immediately dumps it and resizes to the empty size, then a moment later resizes _again_ to the advert size.

Puzzlingly, when displaying the animated advert you see in the screenshot, the video controls are enabled. Clicking the play button causes the time tracker to move from left to right for about 5 seconds, but nothing on screen changes. Hmm, not good. Likewise, fiddling with the forward/backwards controls moves the time tracker and causes a bit of on-screen flicker, but doesn’t seem to change anything either.

Attempt to resize the window and we hit the first major problem – this thing is *slow* like I’ve never seen before. iTunes isn’t exactly speedy either, due mostly to the way it abuses DIBs, but QuickTime breaks new records in slow. I would guess that on my AMD 1200 I am getting one frame per second or less whilst resizing. Even though my computer is old it’s quite capable of resizing a video player on the fly smoothly – other software can achieve this feat easily yet QuickTime cannot. Unfortunately, this problem is doubly bad: whilst everybody may write inefficient code from time to time there’s no way this problem should have got through QA without somebody suggesting simply falling back to non-opaque resize on hardware that can’t keep up. As is, resizing the window is distracting and it’s hard to judge where it’ll end up.

The resize corner itself looks like it’s attached to something other than the main player, the first thing I tried was to pull it downwards as it looked like the darker grey area was hiding underneath the main player. I might have been biased by having used the earlier QuickTimes which did use such a drawer, but there’s nothing there.

## Movie trailers

I wanted to test it with one of the movie trailers Apple has bought the rights for. As you can see the advert contains links to some trailers. The links themselves look ugly and unprofessional – they appear to have been rendered using MacOS X antialiasing, which I find quite heavy, then badly JPEG compressed. The text in the main QuickTime Pro advert is barely legible. The application does not respect my font settings (which are a bit larger than normal to compensate for my bad eyesight). Compression artifacts are obvious. It even contains typos – King Kong is by “Universal Pictures” not “Universal Picturers”. Again, it seems like the QA department simply weren’t in that day.

Things get even more bizarre once I click a link. I assumed it would open in the movie player itself, but in fact it opens up a web browser and takes me to [a sparten page that asks if I have iTunes](http://phobos.apple.com/WebObjects/MZStore.woa/wa/redirect?url=itms://www.apple.com/moviesxml/s/universal/kingkong/index.xml). Clicking No at this point simply takes you to the iTunes download page. Clicking yes opens up an iTunes specific link, which causes iTunes to go to a rather ugly and boring “page” in its internal browser. Clicking trailer _again_ gives you a choice of sizes, with no guidance as to which to pick (for instance, bandwidth requirements), and finally plays the movie.

A few obvious questions arise here:

* Why do I need iTunes, a music player, to watch videos?
* Why doesn’t the QuickTime Player, a program designed specifically for watching movies, open the trailer inside itself?
* Given that it launches iTunes, and was installed at the same time as iTunes, how comes it cannot detect the fact that iTunes is available itself? Why do I have to tell it? And, why does it need to open a web browser window simply to process a redirect which in Firefox generates a security warning anyway?

This appears to be a case of corporate priorities of the day overriding sane design choices. But OK. Let’s continue and explore the application some more.

## Pro edition and more UI abuse

Things get even more stupid once we look at the menus. QuickTime has always had a “pro” edition, and the basic edition is notorious for nagging you to upgrade at every possible opportunity. I find it hard to believe this is a major revenue stream for Apple compared to things like the iPod or the Mac yet they still insist on annoying customers by blocking off random functionality. Why is “New Player” a pro only option? Why is fullscreen mode – a basic feature of every movie player since time began – only available if you cough up?

I’m a firm believer that you can’t send mixed messaging when you build a platform, which is what QuickTime is. When you build a platform either you charge developers to produce content or you charge end users to consume content. Flash is an example of the first, Windows is an example of the second. QuickTime however tries to be both.

More UI abuse is apparent in this screenshot – the (PRO) options look disabled but in fact are clickable, contrary to the way every other Windows menu works. Clicking on them pops up an advert asking you to buy the Pro edition, which uses MacOS button ordering despite using native widgets (so this screen must have been designed specifically for the Windows port).

Things get worse when you look at the edit menu. Copy is available, yet cut is a pro-only option. There are several Find options under a submenu which at first looks optimistically highlighted …. until you expand it to find that all the sub-options are pro only.

## Preferences window

Prefs windows were long a bone of contention in the Linux community. People would point to them as an example of poor usability and at times it seemed the whole argument revolved around whether a particular setting should be in the UI or not. We’d expect Apple to get this right, surely?

For some reason the Preferences menu has “Register …” as a sub-item. The QuickTime developers just can’t resist cramming a nag screen into every possible corner. It also distinguishes between the player app and the QuickTime framework itself, which is a common mistake made by platform developers. Users don’t give a monkeys about the platform guys! They probably don’t even understand what QuickTime is!

Anyway, the preferences window isn’t too bad relative to the rest, though it exhibits the common bug of not rendering themed tab controls correctly. Interestingly, whatever futzing around QuickTime does to get custom window UI interferes with the GIMPs ability to correctly identify windows: asking it to take a screenshot of the prefs window results in a screenshot of the main player window.

Even so, there are many rookie errors here that a seasoned GNOME developer simply would not make (I hope):

* There is a tab control, but it only has one tab
* It uses GNOME/Mac style grouping, whereby the grouped widgets are indented, but fails to enbolden or otherwise distinguish the group labels
* It has some very questionable UI choices going on: specifically, the “Pause movies before switching users” pref alarms me. When would you ever *not* want to do this? When you switch users the movie is no longer visible and presumably somebody else wants to use the computer – somebody who won’t appreciate a random movie soundtrack in the background.
* Number of recent items can be configured (!) and whilst it allows you to enter your own, it has “None” as an option along with apparently arbitrary choices like 30, 50, and 15. Why is this even configurable in the first place – storing recent items is cheap and nothing stops them from showing the first 5 in the menu and then having a “Older items …” option which opens up a list box.
* “Use high quality video setting where available” – the grammar of this is a bit confusing, how can I “use” a setting? And why can’t the player itself figure out whether I can play high quality video? I am never going to specifically want low quality video am I?

The QuickTime framework settings prefs window is pretty good, all things considered, definitely a big improvement over the old one. One oddity is that the the tree view in the File Types tab doesn’t actually fill the window. The empty space sits there, lonely and unloved.

## Plugin

First off, the plugin is extremely unstable on Windows. Reports of it crashing both Firefox and IE are widespread over the net, and I’ve encountered this problem several times myself. It is intermittent – sometimes revisiting the same video will let it play.
I’m not sure how this problem is still unresolved, but I expect Apple isn’t getting any crash feedback as the minidumps will go to the browser vendors. Hopefully MozCorp and Microsoft are working with Apple to fix this problem pronto.

When it works, it works reasonably well though. Media loads fast, plays smoothly, and the plugin looks quite nice. Unfortunately, it’s let down by Apples decision to drop some older codecs from the package. I do not know what motivated this, but the net result is that some older media online won’t play. Worse, it won’t even tell you what’s wrong, instead a beautiful but useless question mark motif will appear over the QuickTime logo leaving you wondering what is wrong. Is the plugin merely pondering the fact of its own existence, or is there a fatal error?

At least once – and this is what prompted me to write this rant – I’ve encountered a movie for which QuickTime doesn’t have the right codec but which it thinks may be available to download on the net. When Windows Media Player encounters this situation it goes off and consults a codec registry, automatically downloads the right codec if found, installs it then immediately plays the video. Good. I might have been offline so it’s not that amazing but it works smoothly and as a user I don’t have to think or do anything.

QuickTime is the exact opposite of this. When it informs you that it needs a brain download, it has a little “Install needed software” button. I expected clicking it to, well, install the needed software. In fact it takes you to [a page on Apples website](http://www.apple.com/quicktime/resources/components.html) where you can see every codec that QuickTime supports, along with a pretty logo and description. It tells you everything – everything except which one you need. The plugin itself is silent on the matter, whilst older versions would let you see stream info this feature has got lost in the new version. There are 11 codecs on that page making installing them all impractical. Fortunately the same video was offered in WMV format, otherwise I’d have been unable to watch it.

## Conclusion

Whilst the worst usability issues in QuickTime have been fixed, it’s still obvious that the team producing their Windows port is mostly clueless when it comes to writing software. Either that or there are serious management problems at Apple meaning they can’t do their job effectively. From the crashing and unhelpful plugin to the bizarre “integration” of movie trailers into the software, QuickTime 7 feels fragile and half finished.

Combined with the recent cockups in the iPhoto team in which somebody who clearly didn’t understand XML at all was assigned to produce their Photocasting feature, I have serious concerns about quality control at Cupertino. These sort of basic mistakes just shouldn’t get through.

docbook to pdf made easy

DocBook to PDF can be a bit convoluted. Here’s the recipe I settled on for my dissertation, which has produced nice enough looking output. Why DocBook over a word processor? Well, I was originally using OpenOffice but quickly got frustrated with how the formatting kept drifting slightly out of sync across the chapters. My own fault, probably, but DocBook worked well enough for me and I can turn it into a reasonable website in future.

Unfortunately the free “docbook2pdf” script I found on my PC didn’t work too well. So I went hunting for a better solution.

Step 1 – make sure the DocBook XSL stylesheets are installed. On SUSE Linux the package name is “docbook-xsl-stylesheets”, the names and paths may differ on your setup

Step 2 – make sure xsltproc is installed

Step 3 – Now go grab RenderX XEP. This is a commercial Java product but they have a free personal edition, which sticks a little logo and notice at the bottom of each page. That’s kinda sucky, but it’s very easy to use and I had no luck with the free PDF generation tools I tried. It also didn’t come out when printing for some reason. This is the simplest way.

Step 4 – Use a command line “xsltproc -o document.fo /usr/share/xml/docbook/stylesheets/nwalsh/current/fo/docbook.xsl document.xml” to generate a .fo intermediate file

Step 5 – Run XEP on that file. You should get a nice looking PDF document as the output. You can customize the docbook stylesheets using a variety of knobs to get better/worse looking output, see the guide to DocBook XSL.

One gotcha that had me stumped for a few minutes is that XEP will try and download things from the net as it works, so make sure Java knows about your HTTP proxy (-Dhttp.proxyHost=’whatever’ -Dhttp.proxyPort=8080).

damn interesting

In the basement of Phoebe Hearst Hall at Oglethorpe University in Georgia, there is a stainless steel vault door which was welded shut over sixty five years ago. Behind this door lies a 20′ x 10′ waterproofed room containing a menagerie of once-modern artifacts and microfilm records, placed there by men and women in the years between 1937 and 1940. If their goal is realized, the contents of this vault will remain unseen and undisturbed for the next 6,107 years …. To keep knowledge of the crypt alive, plaques of cellulose acetate were made which contain information about the crypt in many languages, and sent them to libraries, universities, monasteries, and temples around the world.

Now that’s what I call damn interesting.

how to gain then drop privs

I often read about Linux programs that are suid root but then acquire what they need and drop privs. I thought I’d add this to Wine so it can raise thread priorities but without needing to run as root. So imagine my surprise when I found that code to do this is nowhere to be found. It seems nearly nothing uses POSIX capabilities, and the man pages are (as usual) obscure.

So here’s some example code.

#include <sys/capability.h>
#include <sys/prctl.h>

void setup_security()
{
    cap_t cap;

    /* don't do anything if we were started as root, or are not suid */
    if (geteuid() != 0) return;
    if (getuid() == 0) return;

    /* keep root capabilities as we transition to the regular user */
    prctl( PR_SET_KEEPCAPS, 1, 0, 0, 0 );

    /* switch back to user that run us */
    setuid( getuid() );

    /* drop all privs except CAP_SYS_NICE */
    if (cap_set_proc((cap = cap_from_text( "CAP_SYS_NICE+pe" ))) < 0)
    {
        perror( "cap_set_proc: failed to drop privs, aborting" );
        exit( 1 );
    }
    cap_free(cap);
}

Just make sure you do it early on in the code, before any potentially exploitable code has run. That includes loading libraries relative to the $ORIGIN. Go index it Google!

status update

Autopackage 1.2 rolls slowly onwards. It will soon have been a year since 1.0. There have been no major crises with the 1.x series, which is a good sign – the long periods of testing we did before releasing 1.0 seems to have paid off. The main reason 1.2 has been such slow going has been lack of time on the part of myself (uni), Hongli (uni) and to a lesser extent Curtis (a baby!) but fortunately Isak, Taj and others have kept CVS warm.

On May 22nd I’ll have all my exams at once (woo, go durham exam schedulers) which sucks, but after that day I’ll hopefully start having more time again. So once we pass that date I’ll be able to really beat the code into shape.

Not much work remains to be done. From the TODO file:

* Documenting the new C++ support and making it fully automatic (right now you have to manually build an old GCC and stuff, which sucks)
* Documenting removeOwningPackage() and making our own packages use it
* Write the 1.0 -> 1.2 migration guide so developers know exactly what they have to do to upgrade their packages to get the new features. It’s likely to be short as much of it can be done transparently.

So that’s the documentation left to write. There is at least one bugfix needed too – we need to add some UI for users to disable the anonymous statistics reporting. Curtis and I argued about this before, IIRC he wanted to ask once at setup time, and I wanted to just provide a checkbox in the launcher. I’d rather keep questions out of the setup process so I’m likely to just repurpose the “Hide in the systray” checkbox we have which was never used much anyway.

APBuild has various reports of odd link failures with particular libraries (wxWidgets seems to cause a lot of trouble). Hongli has not been able to really work on the project for a while, so I think I need to start getting familiar with the apbuild codebase again. It’s not large but it’s in Perl, which isn’t a language I am really familiar with. These don’t block 1.2 though. We can fix them whenever.

Then comes a bunch more testing against existing packages, doing “trial run” upgrades to 1.2 and sending patches upstream to get our most high profile packagers upgraded. That’ll entail yet more bugfixing. And then we can finally start the release candidate process, in which people try it out and report that it doesn’t work on XYZ Distro. So we fix more bugs/compatibility issues, and when enough people seem to be happy with it, we stick a fork in it, call it done and go on a mad alcoholic bender

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!

icon caches

It’s not often I find myself agreeing with the Debian project, but this bug is one of those times. The issue at hand is that the XDG icon theme spec has an obscure requirement that when installing icons you must update the mtime of the theme directory, eg by running “touch” on it.

As far as I know this has always been a requirement of the spec. Nonetheless, most people either didn’t know about it or did but ignored it, as it had no impact. This goes for several hundred packages in Ubuntu. Once GTK+ implemented icon theme caching, these applications started to break, because the caching code in GTK+ doesn’t fall back to a manual scan if the lookup fails.

We were able to fix this in autopackage some time ago, because the icons are installed using an icon-theme specific API, so, updating the implementation of this API transparently dealt with the issue. It’s still not ideal because users may not realise they need to upgrade autopackage, and currently it won’t be updated automatically (if somebody wishes to contribute apt/yum/etc repositories for the core code please do!).

It appears from the comments on the bug that the deb/rpm formats can’t be adapted easily, so instead they are simply not enabling the icon theme caching code. There are a whole bunch of interesting compatibility issues here.

• Should people code to what the spec says, or what people actually do? It can be argued both ways.
• Should the cache logic change to fall back to a manual scan if the lookup fails? IMHO yes, it’d be better to start the program more slowly or worst case with the wrong icon than have it potentially crash at startup. It seems Owen Taylor agrees, but so far nobody seems to have written a patch for this.
• Should RPM/dpkg be changed to deal with this case? The “right” way to fix this using these formats is a postinst script on every package that installs an icon into the icon theme. An easier way would be to change the package managers themselves to detect this case and run touch automatically. This has the advantage of not breaking 3rd party packages, which may never be updated. It’s the approach we took (though actually it isn’t a hack for us due to the design). However, this would compromise the ‘purity’ of most package managers which are supposed to be independent of desktop knowledge and it seems the Debian people refuse to contemplate that.

This sort of “cache” which actually replaces the usual lookup logic is oddly common in UNIX software. I’m not sure why, but IIRC the linker cache is similar, and it’s very common for XDG specifications to require cache updates at install time.

As an aside Microsoft are currently looking at a compatibility issue with Samba – it goes both ways.