HKEY_LOCAL_MACHINE\SOFTWARE\INTEL\LANDesk\VirusProtect6\CurrentVersion\Administrator Only\Security\UseVPUninstallPassword

Change to 0 (zero)  and run the uninstall program again.  Voila!

A pretty poor offer, yet their modus operandi seems to be:

• Do a whois lookup for the billing contact for a domain that will expire in the next N months (N seems to be getting larger)
• Send a letter on good quality paper to this address, vague enough to confuse a non-technical person.
• Take their ridiculous cut for not doing very much.
• Profit!

There’s more information over here about their dodgy practices. People are even implying that they won’t provide the basic service they claim, but I can’t comment on that since I’ll never use their service.

Parasites.

VMWARE_USE_SHIPPED_GTK=TRUE firefox &

With this, the console works correctly as expected.  Lovely.

#
# please add local extensions to this file
#

options nvidia NVreg_RegistryDwords=”PerfLevelSrc=0×2222″
options nvidia NVreg_Mobile=1

This was with a Geforce 8400M GS which shows up in lspci as:

05:00.0 VGA compatible controller: nVidia Corporation GeForce 8400M GS (rev a1)

The difference was pretty dramatic.  KDE 4.1is usable with KWin display effects turned on, tab switching is smooth and generally it’s pretty usable again.  All using the NVidia 177.82 driver.

The first problem was fairly easy to fix – the default version of PHP on the server is 4, but symfony needs 5.0+. A quick entry into the .htaccess file for the site fixes this. Add “AddType x-mapp-php5 .php ” and all is well. It’s a pain to have to remember to type “php5 symfony”to get things working, but no big stress.

The next issue is to get the images to show up in the test index.php page. I installed symfony using the PEAR packages, so the symfony_data/web/sf directory wasn’t visible as it was way outside the web root for the domain. A simple link fixed that. First, I needed to get the directory for my php/symfony data directory using the pear5 comand
> pear5 config-show
Configuration (channel pear.php.net):
=====================================

<snip>
PEAR executables directory bin_dir /kunden/homepages/18/d96003440/htdocs/local/bin
PEAR documentation directory doc_dir /kunden/homepages/18/d96003440/htdocs/local/lib/php/docs
PHP extension directory ext_dir /kunden/homepages/18/d96003440/htdocs/pear/ext
PEAR directory php_dir /kunden/homepages/18/d96003440/htdocs/local/lib/php
PEAR Installer cache directory cache_dir /kunden/homepages/18/d96003440/htdocs/pear/cache
PEAR data directory data_dir /kunden/homepages/18/d96003440/htdocs/local/lib/php/data
<snip>

Next I created a link in the web directory for my new application to the symfony web/sf/ directory in my applications web directory (the bolded one above):

cd web

ln -s /kunden/homepages/18/d96003440/htdocs/local/lib/php/data/symfony/web/sf/

Hit the URL http://www.servername/app/web/app_dev.php and all was well. Now to crack on with some development.

Directions from Thatcham to the City (not that you’d want to drive that route).

It’s possible to drag the blue route line around to different roads, add and remove destinations, all with real-time updates to the description of the route.

Very nice. We just need it linked in with real time traffic and roadworks info and it would be perfect

I think it’s called turd-polishing.
Microsoft Ships First Vista Security Patches

I was also thinking of using Nagios or something like that for remote monitoring of sites, something that could enable a nice recurring revenue by charging support on a monthly basis.  £25 per month x 50 customers  is a healthy income and a good incentive to keep development going

Interesting times

http://www.theopenconsultinggroup.com/content/view/29/51/ -

This is a page of content from the site after SEF has done it’s business.

http://www.theopenconsultinggroup.com/index.php?option=com_content&task=view&id=29&Itemid=51 -

This is the same page as published by Mambo without SEF enabled.As you can see, there’s a big difference, and Google notices the difference. From my reading, the former URL is far more preferable to GoogleBot since it’s not plagued by question marks and ampersands, so that what we’ll provide. Enable SEF in the Global configuration, rename htaccess.txt to .htaccess and all URLs are rewritten nicely.

Is that the end of it? Not really. The home page for the OCG is pretty static, with a javascript menu as the topmenu. This is generated from the database dynamically and it works well – as you add pages, they appear without having to change anything as long as you assign them a place in the menu. The problem with this is that Google (and it seems most search engine) don’t like javascript links – they prefer a nice standard text link with alt text. I could change the system, and might still do, to a CSS based template but in the meantime I thought I’d suggest a sitemap to Google to see if it would trawl it.

Having signed into with Google sitemaps with my regular Google account, I added the Open Consulting Group as a project and used the filename supplied to create an empty file in the root of the web site. Then I tried to verify my access with Google Sitemaps. Nothing. I left it for a few days to see if anything would happen, but the GoogleBot just wasn’t verifying. Crapola.

Finally tonight I had a play with the .htaccess file in the mambo root directory. I commented out the rewriting conditions and rules temporarily and ran a verify with Google again and instantly we were verified – still not being crawled (yet) by the bot, but at least we’re in the picture. I uncommented the conditions and rules after verification and we’re back to where we were. The problem was with the SEF feature of always returning some content, ever if the URL you requested is invalid. As an example, here’s the bot looking for my unique file to verify that it’s my web site…

66.249.72.45 – - [03/Jan/2006:21:41:30 +0100] “HEAD /google66b6xxxxxxxxx51x.html HTTP/1.1″ 200 0 www.theopenconsultinggroup.com “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)” “-”

So far, that’s good. It sees that the file is there. Now comes trouble.

66.249.72.45 – - [03/Jan/2006:21:41:32 +0100] “HEAD /GOOGLE404probeddb8db1a52266114.html HTTP/1.1″ 200 0 www.theopenconsultinggroup.com “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)” “-”

Two seconds later it tried to retrieve what must be an invalid URL from the site, but it gets a status of 200 – OK. The SEF function is rewriting the request to the homepage and Apache is serving something up – this is a no-no in terms of the verification process. The fact the Google knows there there isn’t a web page with that name, yet one is being returned (due to SEF) stopped the verification.

I disabled the rewriting by commenting out the following three lines in the .htaccess file:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) index.php

These state that “for filenames or directories that don’t exist, just go to index.php” (in a nutshell). Commenting these out, then re-verifying, ensured the the sitemaps verification went through (for now).
So there lies the problem. How do I get Google to verify my right to have a sitemap on the OCG homepage, yet still be able to run SEF within Mambo. I suspect I need a little mod_rewrite voodoo, I just need to figure it out or invoke the Lazyweb.

Gay Horney

I’m pretty glad we stuck with names like Luke and Mark for our boys. KISS, as they say.