And another bird to listen in and etch the response into a stone disc with its beak?

I'll be very surprised if you can't share a single download of it over standard file sharing.

I'll actually be surprised if they don't sell DVD's too - even if not at first. When Snow Leopard came out (at $25 if I recall, was the same price point as previous "Upgrade Only" CDs and they said you *had* to have a copy of Leopard) they said very clearly it was "Upgrade Only". As with Windows CD's Mac OS "Upgrade Only" media had never previously been able to do Fresh Installs (that is, except via hackery).

It transpired how ever it did do fresh installs like every other ~$80 full Mac OS retail media before it, and the only "requirement" for Leopard was actually a note on the box, which just said so (making it, in practice, a purely academic licensing stipulation which it didn't make any attempt whatsoever to enforce).

I suspect they are not actually being straight about it this time round either, not least as it's in their own interest from a support PoV (as all over the world people in remote locations are going to have the same problem for one reason or another). I'm sure it will boost store usage though.

Check out the MSI API's. You can list versions there and handle upgrades/rollbacks just like you would with something like Solaris pkg's (not as automagic as apt-get + dpkg or yum + rpm, but scriptable and it's possible to do rollbacks and decent enough error handling).

Thanks, that's interesting that there is a COM interface to Windows Update and it's that easy to query from PowerShell.

While writing software on Windows is always fairly hideous (especially for mass distribution, i.e. outside of a corporate environment) AutoIT is vastly underrated.

It's used quite a bit - for installer bootstraps (e.g. to do checks before running the MSI's) and on the AOL (UK) signup / support CD's.

By the standards of most UNIX utilities at ~ 500 KB (without compression) for small .exe's it may be a little on the large size (often the app it self I'm installing is only about 1.5 MB, and 500 KB of THAT is the MSI) but you can write something that will deploy on Windows XP (SP0+) through to Windows 7 and work very reliably with minimal development effort.

It's cute that it has a 'perlesque' syntax too (it's a sort of slightly horrible combination of Perl+PHP+VB, but which is immediately familiar to anyone with Unix shell scripting experience). The forums are pretty helpful places, and there are great examples of libraries from everything from simple SOAP clients to Blowfish implementations.

In practice, it more than makes up for the overhead, because effort can go into making better software, rather than spending days coming up with a simple but reliable utility that works on Windows XP SP0 through SP3 + Vista + Win 7, at various user levels (guest standard, admin, guest - with and without UAC) with no dependancies. Due to how much Windows XP has evolved, even if you support only SP2 and above there are large number of dependancies that are not always guaranteed to be there (different versions of Windows Installer, .NET, network support, small patches with fixes you may be relying on without knowing it, etc).

The only major deficiency I find in AutoIT is that while GUI support is enough to be useful, but there is no GUI development interface. Some might argue that's for the best - Real Studio probably better fit's the needs for any serious application development for anyone who isn't ready (or doesn't want to use) Visual Studio for a project. AutoIT is superb for administration, automation, small purpose built utilities and for quickly developing tools to compliment existing software though.

The poster is referring to the GUI I'm sure - in the most recent release of Safari for Windows they have now dropped that (finally!).

The Java analogy is not so far off, even if no Java style VM is involved, it's a throwback to OpenStep on Windows which does some target platform abstraction. Apple keep their own cross platform versions of the development tools running on other platforms - Interface Builder (now known as "Xcode") ran on Windows and on both Windows and Mac could cross compile (for Win/Mac/Solaris).

The approach Apple use for bundling QuickTime and iTunes on Windows is technically very sensible (of course they should re-use components as dependancies).

The problems are (1) the UI for iTunes is not fully native (2) the Apple Software Update app for Windows (which is a clone of the Mac version) is obtrusive to an unwarranted degree and (3) QuickTime has some obnoxious options selected for default install, and while being great on Mac OS X 10.6, sucks big time on Windows (to the extent no-one would *want* it as their default media player).

Most big ISP's have really awful DNS servers, virtually all in the UK. Customers moan about this all the time on broadband forums.

I work for a very large ISP (several million broadband customers) and our suck, but no-one in the networks team will take ownership and fix it, or it seems admit to it. So I use Google DNS, as do my co-workers - we all know full well there is a problem but we are not responsible for the systems.

I worked an similarly sized ISP, same problem. Lousy management not enforcing any meaningful quality control (i.e. just box ticking ... of the wrong boxes) combined with lazy/incompetent/overworked people responsible for designing / build the systems (and a mix of overworked/under-qualified Ops guys).

Smaller ISP's seem to be a lot better at this (my guess is in smaller companies there is less dead weight in the employee pool - especially in the bozo management layer, where plausible deniability and responses of "I'll need more data on that" are king).

The solution to this is middle managers with a clue. Alas, having a clue is no longer as up near the top of the selection criteria as it once was in a more industrial era.

I assert the OP is correct and Akamai's approach is what's broken IMO.

Using geolocation based on the IP of a DNS server is bad approach IMO. Sure there are a lot less DNS servers out there than clients, but there are obvious problems with it and the over head of IP geo location look up and an HTTP direct per request is very small

A redirect system would use a tiny amount of bandwith, and easy to build a system to cope with, and you wouldn't neccerrily need to have it hosted all over the globe like they do with the cache servers, not if it's only doing HTTP 302/303 redirects. It would be simple to impliment and very robust too - much less likely to cause problems than something as crude as DNS server IP geolocation.

You could also have the network layer handle routing traffic to the 'least cost' route, which would be a really good way to do it - apart from it being more complicated to manage, not least given all the different providers Akamai have to do deal with, Though I'm guessing is that's what Google are doing in any case (and I remember managing after DNS servers hosted in different countries but with the same IPV4 addresses 10 years ago, so it's not as if it's a new concept).

I do. I think requiring a Digital Certificate on all plug-ins then displaying a Microsoft ClickOnce type dialog (name of the application / plug-in, certificate owner, etc) and a "Do you wish to allow this plug-in to run?" message on first run. I guess it's about the same as the popup for permission request from a signed Java applet (only the latter is a bit horrible).

Possibly options could be something like "Yes, Always", "Yes, On This Website" (domain based?) "Not Now" and "Never" (Uninstall/Disable) if a user friendly dialog with enough useful options could be devised.

Coupled with an easy-plug-in installation API this would kick ass. I think the Firefox Extensions installation API (which is what they are now saying Plug-in developers should use, since FF ~3.6 I think), is good, and maybe just insisting on a first-run popup for plug-ins installed not using the API would promote both use of the API (even if it's not great - hopefully they can improve it) and keep potentially malicious plug-ins in check.

I would say that better enduser plug-in management interface would be nice too. Firefox is pretty good at this (better than all the other browsers I think), but could still be improved a little. MSIE, in particular, really sucks at this (not so much as an about:plugins - and it has an Extensions/Add-On manager, but things that are only plug-ins are not listed *anywhere* visible to the user, other than by looking in the registry).

Yes really, with Firefox on every operating system you must restart the browser after upgrading an existing plug-in, that is what the documentation says... as I say, unless you fudge the installer (killing an active process also counts as 'fudging the installer' by any definition). However. MSIE, Safari and Chrome have no such issues handling upgrades, as they have better plug-in handling in that regard.

Shift-refreshing a page with the plug-in multiple times (and interrupting plug-in loading the process) will also cause Firefox to falter and reload a plug-in (but simply calling navigator.plugins.refresh or refreshing about:plugins will not).

Not unreadable? == Not unreasonable

Interestingly, from the PoV of a plug-in developer, I have found Firefox has possibly the most annoying environment to deploy plug-ins in. Granted it's open, and uses the NPAPI naturally - (as do Safari, Chrome and Opera) but how the browser handles installations and in particular upgrades makes it very annoying, even compared with MSIE and their ActiveX approach (and that's even given IE doesn't have a working navigator.plugins implementation).

Of all those browsers Firefox (on Windows) is the only one that requires that if you upgrade your plug-in it is not enough to increase the file version and rename the DLL and then register that with Firefox, you also have put your new DLL in a directory that has a name it hasn't seen before (e.g. including the file version in the directory name) because it refuses to look for a new DLL in a directory it thinks it's already looked in for plug-ins. You then need a JavaScript shim to refresh and check it's upgraded.

Even with MSIE all you have to do is give the control a new GUID (which is not unreadable).

Note: The official Firefox line on this is "you should always restart the browser after installing an upgrade to a plug-in". This is what their API for installing plug-ins does (or one of them, they have two, and have deprecated one in favour of combing it with the same installation method as for extensions now, but that and the quality of the documentation is a whole other issue).

Technically, no other browser documentation suggests or requires that and logically there is no good reason to need it. It listens to Restart Manager message (in Vista/Win 7) but you need to suppress those when upgrading because Firefox will invariably display a dialog then crash instead of restarting when it sees an upgrade is happening.

They also have odd rules like "the plug-in file name must begin with 'np' and the filename must be 8.3 format" (thought the documentation just seems incorrect on the latter - and would be super-inconvenient given you need to prefix it with 'np' and include a release number in the filename).

Lastly, Microsoft & Google both install "ClickOnce" and "GoogleOneClick" which, while not the same, perform not dissimilar functions, which kind of hints a market demand for a specific set of functionality.

That Microsoft include a ClickOnce plug-in is actually very helpful for Firefox in the enterprise. Apart from being a very cool and useful deployment mechanism on Windows (that in theory is a lot safer than having everyone always have to run apps with full user level privileges), Firefox doesn't current offer anything that could be an alternative (in either of it's two installation API's) and without it internal IT software teams would, I'm sure, just say "you need Internet Explorer to use that intranet app / HR tool / customer support tool / etc".

The best way to address the perceived problem of "sneaky plug-in installation" is for the Firefox team to come up with a decent, user friendly way of installing (& upgrading) and allowing plug-ins to work that doesn't suck (i.e. no yellow bar along the top [ awful usability ], and certainly no browser restart required). Something like a one-time dialog box displaying the digital signature details of the plug-in on first-run would work for everyone.

* I know most plug-ins, including Flash, suffer from requiring mandatory browser restarts and yellow bar popups, no I don't know why (other than they suck at writing installers). Especially in IE (which is evil in not supporting NPAPI, but *is* fairly well documented).

It was probably using UPnP or NAT-PMP and your FreeBSD box wasn't setup to handle it (I'm not sure what the status of UPnP or NAT-PMP).

Using high ports on non-fixed ports from a known range which client and server negotiate in real time is a legitimate design for a TCP/IP app.

I'd get a decent dedicated router or, if it using UPnP, take a look at something like Microsoft's UPnP testing tool for Windows and see what it reports: http://www.microsoft.com/windows/using/tools/igd/default.mspx

Halo stopped being an RTS long before Microsoft bought Bungie (but it's true that was originally considered at one point, but not publicly). There are plenty of videos of pre-XBox FPS gameplay going about.

The tragedy is that, despite being a decent game (and an impressive X-Box title) the original version never saw levels that were anything like as impressive as the size of levels in the demos (okay, Assault on the Control Room feels huge and *is* very impressive, but it's not one huge outdoor open map loaded at once).

Genius. Now I seriously want Microsoft to do this.