If you search on Google Maps for the address of Google’s offices in London Victoria, you’ll be taken to the correct address. However, if you then click on the location marked ‘Google London’, the address it gives you is for a different office building in Soho about 2 miles away:
(The address given is the location of their separate sales offices that opened last year, but that hardly excuses the place marker being 2 miles out of place).
For me, one of the advantages of Google Apps over Live@Edu is the simplicity of the tool used to automatically provision user accounts based on your Active Directory. While Live@Edu requires you to use the complicated Identity Lifecycle Manager (which consumes significant server resources), Google Apps Directory Sync can be run on the bare minimum of hardware and takes only a very short time to set up.
When used in conjunction with the sha1hexfltr program, you can not only synchronise the user account data, but also the user’s password, ensuring the user does not have to remember two different passwords for their standard computer logon and their Google Apps account. Unfortunately, the way it does so is not the exactly most secure method in the world.
I’ve been doing a bit more testing of using Google Apps for pupil email this week, and all I can say is that if the adverts in GMail really are tailored to the messages in your inbox, this has to be a bad omen:
If you’re wondering, it really was a recipe for spam tortillas.
As part of a recent foray into Google Apps for Education, I’ve once more been learning that Google don’t really take their Windows product testing seriously. Google Apps Directory Sync is a somewhat essential tool if you want to manage even a moderately sized Google Apps deployment, because it will synchronise your user accounts (including passwords) with an LDAP server such as Active Directory. Compared with the somewhat tortuous process of accomplishing the same thing with Live@edu, the Google system is a clear winner.
Apart from when it comes to actually running it on a modern Windows system. It starts off badly when reading the Features and Benefits section of the (otherwise excellent) administration guide:
“Runs on any Windows (XP or Vista), Linux or Solaris server.”
Yes, that’s right, Google thinks that Windows servers run on XP or Vista. Not, say, Windows Server 2003 or Server 2008, the actual server environments. Worse still, it’s clear they haven’t actually tested it on Vista, or its server counterpart, since the instructions fail to mention one crucial thing: the Simulate Sync function of the configuration tool does not work at all with UAC turned on because of insufficient rights to the Program Files directory, which is the default install location for Google Apps Directory Sync.
There are things I like about Google, and things I don’t like.
I like Android. I like Gmail (apart from the UI). Even though I use Bing as my default search engine, I still prefer Google’s image search. And there is no question that Google excel at both traditional web and cloud services.
One thing they do not excel at is desktop software. Particularly on Windows.
Mostly this is because they simply don’t know what they’re doing. Last year it was reported that Google were scrapping internal use of Windows entirely, but even before that, it was obvious they really had no idea how a Windows client/server network operates. Their software installers typically ignored even the most basic rules about where files should be stored, especially when it came to user profiles. On products like Google Earth and Sketchup, they’ve improved, but one product’s data storage model remains as badly designed as ever, and that’s Google Chrome.
The FT reported today that “Google is phasing out the internal use of Microsoft’s ubiquitous Windows operating system because of security concerns“. A lot of people are talking about the same tired and obvious aspects of this; Google pushing their own platforms, Windows being insecure, blah blah blah. I don’t care about that, especially since the benefits of Microsoft vs. Apple/Linux/whoever is one of those topics about which everyone who cares already has an opinion, and isn’t likely to change it.
What I want to point out is that this means Google products that run on the desktop will soon start to be utter garbage when run on Windows.
It is inevitable that without Windows machines in the corporate IT estate, Windows development will not matter as much to the company. When your software crashes and it affects your employees, that drives a fix harder than a thousand times as many customers with the same problem. From now on, crashes in the Windows products will not affect Google employees. And they will care less, even if most of their customers are using Windows. Don’t believe me? I thought you might not.
Just look at Apple.
iTunes is an application beholden to millions – including millions who use a PC – and yet almost everyone I’ve met who has run it on both Windows and OS X has told me that the Windows version is garbage in comparison. I know from years of experience that QuickTime is an utter nightmare on Windows, frequently breaking or delivering dire performance. The simple fact is that Apple never see those problems because, of course, no-one at Apple uses Windows internally. So, no-one at Apple cares to do anything about it.
Apple does of course have a vested interest in iTunes and QuickTime running better on OS X, but I honestly don’t beleive that iTunes is deliberately unstable and cack just to drive people to buy a Mac. It’s simply because their Windows programmers suck due to complete inexperience with the platform, and the same thing is going to happen at Google.
In the long run, it may not matter. If the entirety of Google’s product line-up completes its buzzword-filled move to the “The Cloud”, then hopefully it won’t matter that Google coders can’t produce quality code on Windows. But in the meantime, get ready for Chrome, Google Earth, Google Desktop, Sketchup, and Picasa to start sucking big time. The developers aren’t using Windows any more, and their bosses want every application in the browser.
Why should they care if your Windows program crashes?
I haven’t been a fan of Adobe products ever since Creative Suite became a total pain in the backside to install on a network, and when they took over Macromedia and inherited Flash, I liked them even less. Nor am I a fan of Google, whose laissez-faire attitude to privacy runs utterly contrary to their stated company ethics, and whose Windows software is too often amateurishly designed with support for managed networks either not present at all, or added several months late as an afterthought.
My own distaste, however, pales in comparison to that of the CEO of Apple, as reported by Gizmodo:
“That ‘Don’t be evil’ slogan Google’s known for?… ‘Full of cr**,’ Jobs said, after which he was reportedly rewarded with a big round of applause from the gathered throng of Apple employees… ‘Make no mistake, they want to kill the iPhone. We won’t let them.'”
The attacks became more specific when it came to Adobe:
“Jobs also criticized Flash for being buggy. When a Mac crashes, it’s usually because of Flash, he reportedly told the crowd. ‘The world is moving to HTML5’, he said.”
I’d have to agree with the first part of his assessment: Flash, along with other Adobe software, has more bugs than a world-class entomologist. I cannot recall a single instance of my browser crashing within the last year that wasn’t down to Flash or Adobe Reader. That said, if a browser plugin is taking down the whole system, Jobs needs to level some rage at his own developers, since the OS should be able to cope with one piece of miscreant user-mode software.
However, the world ‘moving to HTML5’? I think that’s a little premature…