See http://communities.vmware.com/thread/188366 for the gory details. I hope this can get resolved in a timely manner :-/

Update:

Someone with a brighter mind then me suggested to use Windows System Restore feature. Excellent idea, everything is working again. I’ll still go for the VMWare support because such a thing should clearly not happen.

So what happened?

The FF developers decided that their Windows Application should respect the OS security settings. In my case, I use IE only for Windows Update, thus I put the update service from microsoft into the trusted zone and set the default seurity zone settings to high. I just don’t trust IE at all.

Why did this work the years before? Because I used FF for downloading everything else and until now FF didn’t respect this setting, which was a great life safer for me.

To make things worst I haven’t yet figured out a way to disable this behaviour in FF3, which means I’ve to suddenly lift the security settings for the complete system! As you guessed I’m pretty pissed about this.

Update: filed a bug report, excited to see what happens to it.

Update 2: Report closed within hours as Wontfix because it’s a deliberate change.

Update 3: My report has been marked as duplicate in favor of bug 445158 (which contains more information and, interestingly, has been opened by someone with an mozilla.com email address. Does that weight more then my request?)

Update 4: First comment on the report from another pissed user. I couldn’t say it in better words.

Actually, this is the kind of start of revolution you’ve been seeing in every computer generation at the beginning, this is just a repeating pattern. Just remember how the PC started around 1992/1993 with their first 3D games and mobile phones started a few years ago, too.

How long will it take until we’ve something like ScummVM ported to a browser? Or Another World? Or think about the Sierra Classics.

However, back then there existed no practical solution with the software I was using (Mozilla Mail, now Thunderbird), so sieve was just a word but I couldn’t use it (and I probably was lazy to do it by other means). I think I remember that Eudura had support for it.

Anyway, by sheer luck I came across the  sieve extension for Thunerbird! I couldn’t believe, but it is true and it works.

Actually, the extension not a real up to par GUI filter interface what Thunderbird offers natively, it’s a more spiced up telnet to simply access the server side filters and work on them. But that shouldn’t degrade the extension, because it’s really all you need!

I instantly converted all my Thunderbird filters to sieve and, voila, no need to depend on a client to do the mail filtering.

This gave me quite a bite when I starting using my Nokia E61i with my imap server, because there’s no filtering capability available (and if it would, it probably would be too annoying for me to sync all the filters for it), but now that problem is solved too.

In case you’re wondering what IMAP solution I’m using: it’s cyrus imap using sasl. But don’t ask me about details. I set this thing up nearly a decade ago, carried this installation through all my hardware changes, first via chroots, now with vserver, but I almost entirely forgot how I sat it up, nevermind the master password :-)

I’m thinking about upgrading the architecture, switching to DBMAIL, etc, but there’s also this voice inside: never touch a running system. And, yes, cyrus is runnig well and haven’t failed me in years.

Stuff recently added:

• Don’t interrupt  when writing code. The phpdocs get inserted transparently while you’re typing. Automatic insertion is triggered when the ‘{‘ for a class/interface/function are typed or when the ‘;’ of a property is typed.
• Fully document all parameters to functions, with their type and names, default/optional values.
• Flexible way to insert custom tags with whatever content you want.

Basically, there are function which expect strings and the implicit _toString() call on an object will leak memory. Testcase:

< ?php
    class Foo {
        function __toString() {
            return 'foo';
        }
    }
    for ($i = 0; $i < 1e5; $i++) {

        $o = new Foo;

        # leaks
        md5($o);
        # does not leak
        #md5($o->__toString());

        # does not leak either way
        # strstr($o, 'f');
        #strstr($o->__toString(), 'f');

        if ($i % 1e3 == 0) {
            printf("%u: %1.2f KB\n",
                $i, memory_get_usage(true) / 1024);
        }
    }

This patch honors the (hidden) preference zoom.reverse when doing the actual zooming with the mouse (mousewheel.withcontrolkey.action == 5). You can download my custom build of Firefox 3. It’s for Windows only and it’s just a zip file, no installer required. Unzip, change the hidden pref (hint: about:config) to true and there you go. You can start it along any existing Firefox version however you probably want to start it with a custom profile first with -P otherprofile so it doesn’t temper with your existing one. By default you can only run one instance of FF, if you’re sure you want to run them simultaneously, use MOZ_NO_REMOTE.

We currently haven’t the templates connected to the CMS yet, but the raw time is currently between 700 and 900ms. Maybe it can be justified because the layout isn’t Web 1.0 style (i.e. many round corners, shadows, etc.).

What puzzled me was the “loading time of JavaScript was around 300ms”, see this picture:

That’s quite a long time. It may is not that good visible from the chart, but nearly everything following the JavaScript is hold until it is read, which delays the complete loading of the rest of the page.

Since behind the scenes the actual request is in reality using Minify, it’s not just plain serving (but for this scenario the JavaScript has already been cached).

So I took a look just at the JavaScript loading, see this:

What’s that? Roughly 30ms vs 300ms?

The only realistic guess I’ve at the moment is: parsing the JavaScript.

This single request loads the following libraries:

• behaviour
• prototype
• scriptaculous (+effects)
• yui: yahoo-dom-event
• yui: container_core
• yui: menu.js
• our own small JavaScript parts

Maybe I’m too optimistic but it hit me a bit that JavaScript parsing still does take so long. Given that the JavaScript is cached (ideally) things such a huge problem, but still. It was frustrating that I could trim down the >1s request to ~700ms but not further and for most of the part just because it takes as long as it needs it.

My simple goal was: have the shortest possible article URLs, ideally http://server/Article and not http://server/dir/index.php/Article.

With a simple .htaccess file and some modification to the LocalSettings.php I was able to get it working:

.htaccess File:

RewriteEngine On
# Backward compatibility for old installation
RewriteRule ^wiki/index.php/(.*) http://intranet.netcare.at/$1 [R=301]
# Only rewrite uppercase Words because they signal the title for the pages to
# handle. Everything in lowercase is expected to be "internal"
RewriteRule ^([A-Z].*) index.php?title=$1 [L,QSA]


LocalSettings.php changes:

$wgScriptPath = "";
$wgScript = "/";
$wgArticlePath = "/$1";


This is simply a “it works for me” scenario. I did some testing and it seemed everything is working fine. However I also think the way I use Mediawiki just scratches the surfaces. We’ll see if it works out.