Flux player no longer open source?

Back when I last experimented with Flux Player and Flux Studio, I seem to recall their website still contained references to the player being open source. The source code in CVS at the sourceforge project was however three to four years out of date but there was an archived snapshot of a more recent release (fluxsrc-2006-07-09.zip) which is still available here and other places.

Now unless I am mistaken, all such references to it being open source are gone from the main Media Machines web pages. There are references in various other places to a later source code release from this year but all the files have been deleted from the sourceforge project.

It is still possible to find the deleted files if you google for the file names and substitute them into the standard sourceforge download paths:

• fluxserver0-1.zip
• fluxsrc-build634-2007-05-06.zip

This isn't the first time I have seen the wind down of the open source release of a commercial product on sourceforge. It is nice to know that with a minimal amount of effort you can track down the released files.

Given the four year old age of the files checked into CVS I wonder whether it was released based on an initial open source faith which waned in the face of reality or from buying into the false promise of there being volunteers who would pop up and help out.

Giles Coren's restaurant reviews

Food blogs are a large part of the subscriptions I have in Google Reader. What makes a good food blog for me are good photos mostly, along with a description which adds colour to whatever is pictured. I find food blogs which lack photos mostly disinteresting.

I find it surprising that I enjoy Giles Coren's restaurant reviews on The Times Online website. But I do and I make a point of reading the new one each week when it is published.

A good piece of fluff that leads into the latest review about some Gary Rhodes restaurant:

What the phrase “hotel dining” mostly brings to mind is arriving in a strange city too late, or too tired, to check in your bags and then to scour unfamiliar streets in search of food, and so retiring to your room and dithering between room service and raiding the minibar.

The advantage of room service is that if you’re lucky they might do a cheeseburger, generally the only hot food worth risking from a hotel kitchen at 11.30pm; the downside is having to then wait until 1.30am for it to turn up. The advantage of the minibar is that it’s available immediately. The disadvantage? It’s that its contents have been chosen by someone who believes that (a) what you want when staying in a hotel is to eat macadamia nuts, a snack which no person has ever been known to crave at any time of year, and that (b) you are happy to pay for this jar of macadamia nuts a sum only slightly less than what you pay to get your car serviced. There is a third hotel dining option, available at 11.30pm, of strolling the hotel corridors helping yourself to other guests’ leftovers that they have parked outside their doors on room-service trays ready for collection: think of it as a floor-level buffet table. But few hotel guests are bold enough.

Preventing javascript redirection

For some reason, I wasted a lot of time this afternoon trying to make use of Firefox customisability in order to avoid having to log into Gamasutra in order to view the articles. I have no idea why, the article I was trying to get to, I didn't find interesting when I eventually got to see it. But I feel obliged to document the process for future reference.

When you visit an article on Gamasutra, it loads the page you want to see and in the process executes some javascript which checks if you have a cookie set and if not redirects you to its login page. I wanted to do something to disable this redirection.

var login_link = "https://www.gamasutra.com/php-bin/login.php...

//if the Gama Demo string does not exist, send them to login screen
if (pos == -1)
location.href  =  login_link
else {

My first attempt was in installing Greasemonkey. This seems to get invoked after the page has been loaded, at which point the redirection is already in progress. I could change the document.location value back to what it was being redirected from, but this just resulted in an infinite loop of redirection. I could catch the unload event and tell the browser to stop with window.stop(), but it seemed to stop after the redirection had started giving a blank page. Unless there is a formal way to stop what a previous assignment to document.location starts, Greasemonkey doesn't get invoked soon enough to help here.

The next attempt was with something I stumbled across when googling for "redirection". Firefox security policies. These have no user interface, but seem to be fully implemented. They enable you to do things like disable javascript for all sites or specified sites. Or disable access to various parts of the DOM, like document.location.

These lines would be added to a user's "prefs.js" file ("nogo" is just the random name I gave the profile myself):

user_pref("capability.policy.nogo.location.set", "noAccess");
user_pref("capability.policy.nogo.sites", "http://www.gamasutra.com");
user_pref("capability.policy.policynames", "nogo");

However, I could see myself wondering why the Gamasutra website wasn't working properly, so I just went with disabling javascript instead:

user_pref("capability.policy.nogo.javascript.enabled", "noAccess");
user_pref("capability.policy.nogo.sites", "http://www.gamasutra.com");
user_pref("capability.policy.policynames", "nogo");

More information on customising Firefox security policies can be found here.