Reliably Broken

What Adobe’s software update site needs is:

• An RSS / Atom feed of recent updates.

  This way you can subscribe to a list of recent updates in your favourite news reader and be informed when a new update is released without having to scan product-specific blogs, etc.

• Per-product pages listing available updates.

  When you want to find an update for a product you can find it on the dedicated product update page. It will be there.

• Nice URLs.

  URLs make the Web. Putting the product name in the URL makes a human-friendly URL, as opposed to putting the opaque product reference numeric key as a query parameter. Quick test: which updates do you expect to see on http://www.adobe.com/support/downloads/product.jsp?product=1&platform=Macintosh ? And assuming you were so insane as to guess the previous URL correctly, which updates do you expect to see on http://www.adobe.com/support/downloads/product.jsp?product=1

Anyway, those be my principal beefs with the current Adobe software updates site. So I made a site that tries to satisfy my beeves. Beefs.

It is here: http://reliablybroken.com/wavesinspace/

Please provide feedback to david@gasmark6.com

This is written from the point of view of someone looking to keep abreast of software patches for Adobe‘s many excellent products (also Acrobat).

Adobe’s Downloads page is mostly about downloading product demos. Although on that page there is a list on the side with a link to the real product updates page and a very out-dated list of updates.

So then the actual Product Updates page has a menu for all their products that takes you to the updates for an individual product, and a list of “featured updates”. What qualifies an update to be featured is a mystery, so that list is not useful either.

They don’t think to mention it on the Downloads or Product Updates pages, but there is also a New Downloads page which is actually rather handy, although there is no indication what constitutes “new” so it can be difficult to tell if something was released in the time between your last visit and the oldest update mentioned on that page.

My favourite aspect of Adobe’s support pages is the whimsical approach to the page for a product. For example, the page for Illustrator for Macintosh includes the 15.0.2 update for Illustrator that shipped as part of Creative Suite version 5. Meanwhile the Creative Suite for Mac updates page doesn’t admit there have been any updates for CS5 at all.

What Adobe’s software update site needs is…

Nginx is available in Debian Lenny, but the version in stable is the old 0.6.x series. Perusio maintains a useful repository with development versions built for Lenny, but it requires libraries newer than those in stable.

UPDATED: fixed ‘build-essential’ – thank you Carlos

But it is easy enough to build a deb from the Perusio package which uses the stable libraries. Here are my notes. N.B. Editing the apt sources and installing packages needs root privileges.

First, add the Perusio repository to /etc/apt/sources.list:

cat >> /etc/apt/sources.list <<EOF
deb http://debian.perusio.net unstable/
deb-src http://debian.perusio.net unstable/
EOF

Update the apt-get index:

apt-get update

Install packaging tools (if they aren’t installed already):

apt-get install dpkg-dev
apt-get install fakeroot
apt-get install debhelper
apt-get install build-essential

Install headers for libaries required to build Nginx:

apt-get install autotools-dev libgeoip-dev libssl-dev libpcre3-dev zlib1g-dev

Now get the package source and build a deb installation package. This part can be done as a non-root user.

apt-get source nginx
cd nginx-0.9.5
dpkg-buildpackage -rfakeroot -uc -b

When I did this, the version in the repository was Nginx 0.9.5. The flag -uc says to not sign the changes file and -b says build a binary-only distribution. If you were cross-compiling, you can pass the -a flag to dpkg-buildpackage specifying the build architecture.

Assuming the build was successful, your new installation package will have been created in the parent directory (bloody hell Debian tools are unintuitive).

Here I built the deb on amd64. To install this I go:

dpkg -i ../nginx_0.9.5-perusio.1.0_amd64.deb

The advantage of building Nginx from Perusio’s repository rather than directly from the source is we get the hard work of conforming to the Debian layout for free.

I just spent a stupid amount of time trying to figure why Nginx was failing to cache my Django app responses. The Django app is running as a FastCGI backend and I have Nginx using the fastcgi_cache directive to cache responses.

The answer is that Nginx since version 0.8.44 does not cache backend responses if they have a “Set-Cookie” header. This makes perfect sense because you don’t want a response which sets a cookie to be cached for subsequent requests, but I was stupid because I had totally forgotten that my Django app was using a POST form for all responses for non-authenticated clients (due to how Django’s CSRF middleware does its stuff).

The solution was to change the app so that it uses the GET method on the form in question, which in this case is fine from a security point-of-view.

The moral of this story is I should pay attention to my HTTP response headers and that I am badly short-sighted both figuratively and literally. With that fixed the site has gone from 15 requests per second to ~2000 requests per second!

Pierre Igot complains about the font rendering on Microsoft’s Office for Mac product pages:

Why does the web site promoting Microsoft Office for Mac OS X use, by default, a font that no Mac OS X user has on his or her system?

Well, the branding for Mac Office uses Segoe so it makes sense to keep that brand consistent across all the pages. But it was more of a rhetorical question, wasn’t it?

But Pierre has missed that the text is not displayed using a font specified by the stylesheet (he notes that he doesn’t have Segoe installed). What actually happens is it is rendered as canvas elements, one for each word.

This works using a JavaScript library called Cufón which aims to allow text to be rendered using any font the designer specifies, even if the font is not installed on the visitor’s computer. In the good old days the text would have been rendered as a graphic (as the designer did for the ‘Office:mac’ logo at the top of the page) but modern Web designers are too cool for that.

The advantage of the crazy download-able fonts and client-side JavaScript approach is the headline text remains accessible, you can copy and paste it etc. And at larger sizes it looks pretty good; only the smaller headline text renders poorly.

This screenshot shows how well it works for large size text and poorly for the small text (taken in Google Chrome dev version). I’ve selected part of the text to demonstrate that it is “live”:

Pierre is right, the smaller headline text does look terrible for the very same visitors Microsoft wants to sell to. But I don’t mind too much because the whole site is much less of a useability nightmare since the re-design. Microsoft’s Mac Web designers aren’t entirely evil.

Screenshot of App Store.app showing title bar buttons out of place.

Why did Apple allow the new App Store application to ignore the human interface guidelines? It isn’t like the toolbar is doing anything radically different to other information browsers, nothing that might warrant exploring new interface ideas.

It just looks odd, an arbitrary inconsistency that would be simple to correct.

These are my notes on installing minidlna, a DLNA server for Mac OS X. I compiled it from source and installed the supporting libraries from MacPorts.

Most of this was culled from a thread on the minidlna forum.

First install each of the following ports. The command for each would be something like sudo port install libiconv.

• libiconv
• sqlite3
• jpeg
• libexif
• libid3tag
• libogg
• libvorbis
• flac
• ffmpeg

Then check out the Mac branch of the current minidlna source from the CVS repository.

cvs -d:pserver:anonymous@minidlna.cvs.sourceforge.net:/cvsroot/minidlna checkout -r osx_port minidlna
cd minidlna

The current build script appears to miss out pulling in libiconv so I had to edit configure.ac, inserting a line to bring in libiconv.

AC_CHECK_LIB([iconv], [main],, AC_MSG_ERROR(Cannot find required library iconv.))

Now the build will work. Although I found I needed to run autogen.sh twice for it to generate all the necessary files.

source ENVIRONMENT.macports
sh genconfig.sh
sh autogen.sh
sh autogen.sh
./configure
make

This spits out the minidlna executable and a basic configuration file. Copy these to wherever you want them. Edit the minidlna.conf file, pointing it at the files you want to serve. There are examples of what to do in that configuration file.

And for testing purposes you can start the server from the build directory.

./minidlna -d -f minidlna.conf

Bingo.

I did try using ushare, another DLNA server, but I couldn’t figure out how to persuade my Sony telly to successfully connect to it. So I gave up. I feel it is useful to give up quickly when something doesn’t work until you run out of alternatives, I consider this triage. I also consider my telly’s inability to work with ushare and the fact that the telly will only play a very limited set of video formats a mark against the promise of DLNA.

I’m not convinced this is actually a good idea, but I have an approach for using class-based views as handlers for a route with Bottle.

(If you were mad keen on Django’s shift to class-based views you might reckon life wouldn’t be complete with a Bottle-based application until you employ classes for views. However Bottle’s use of decorators for tying URLs to views means it is less a natural fit than the same thing in Django.)

The problem is that you can’t just decorate the method in your class using bottle.route because if you use that decorator on a method in a class you are telling Bottle to use the method before it has been bound to an instance of that class.

So although I wish it did, the following example will not work:

import bottle

class ViewClass(object):
    @bottle.route("/")
    def home_view(self):
        return "My home page."

obj = ViewClass()
bottle.run()

Running that will lead to errors about not enough arguments passed to the view method of your ViewClass instance.

Instead you need to register the route right after the object is created. This can be done in the class’s __new__ method:

import bottle

class ViewClass(object):
    def __new__(cls, *args, **kwargs):
        obj = super(ViewClass, cls).__new__(cls, *args, **kwargs)
        bottle.route("/")(obj.home_view)
        return obj

    def home_view(self):
        return "My home page."

obj = ViewClass()
bottle.run()

It works. It isn’t that pretty. You could achieve exactly the same thing by explicitly passing the obj.home_view method to bottle.route after the instance is created. The advantage to doing this in the __new__ method is it will happen automatically whenever ViewClass is instantiated.

And if you go down this path then you should be aware of threads. Hey! Nice threads! Also I have a cold.

The OS X Deployment and Management Wiki, articles about managing and deploying Macintoshes.

Looks like it is the work of Rusty Myers and Nate Walck (so far).

Considering it is only a PowerPC G4 processor running at 1.5 GHz, I am impressed that my five-year-old little MacMini can go from pressing the on button to the login screen in 45 seconds, of which the first 10 seconds is the system trying to work out from which disk it should boot. (There is only one disk in the mini – you hear me mini? Boot from that one immediately.)

However it is another 15 seconds from login to a usable desktop, running Mac OS X 10.5.8. My Macintosh Classic with an 8 MHz 68000 processor is slightly faster booting System 6.0.8. Both the mini and the classic can run some version of Eudora for e-mail. Neither machine will run Google’s Chrome browser so I reckon it is even splits on which is the more useful.

Also I don’t need an adaptor to plug in the world’s greatest aircraft carrier masquerading as a keyboard on the classic. Little baby Jesus to think that Apple used to sell their considerably expensive computers with no keyboard, no screen, no graphics card, no memory, no hard disk, just a mouse! Progress means you can buy a new MacMini and it don’t come with a mouse neither.