OS X updates on magazine cover CDs??

G

goynang

Some guy
What do people think about Apple's policy (as I believe it is) of only allowing you to get OS X updates (e.g. 10.2.4) via Apple.

As a modem user at home it's no fun downloading them over the 'net. Luckily we have a stupidly quick connection at work so I just take my iBook in every now and again to get up to date.

It must delay adoption however and surely they want as many people as possible on the latest versions / patches.

What valid reason is stopping them allowing the Mac magazines to have the updates on the cover CDs?

Other than they lose some tracking information - I don't see any goodreasons (and they could always require a quick and small connection to Apple over the 'net as part of the update process?).

What gives....?
 
well, when they distributed the free updates for 10.1, the first thing people did was figure out how to hack them to full install disks. i doubt apple will ever make it quite so easy to get them again after that.
 
I guess as well he meant 10.2.x's. :)

Having e.g. the 10.2.3 (nearly 70 MB) or 10.2.4 (41 MB) *update* itself I imagine is hard to hack it to have the 10.2 itself extracted from it (those 2 installation CDs of it).
 
To clarify - I did indeed mean the smaller updates (10.2.1, 10.2.2 etc and not 10.1, 10.2)

Once they get into double figures in size (mb) downloading over a modem gets a real pain.

So why won't Apple allow them on the mags??
 
I totally agree with goynang.

I'm from England and I'm sick of the update situation. I've just put my penneth into a poll on the macworld.co.uk site about just this topic.

I also added a comment; "To quote a David Bowie song title:'This is not America'".

We don't al have cheap and easy access to ADSL, so it's just nor practicle to download any of the updates, even the minor ones.
 
This is Apple's way of doing a kind of quality control.

They used to allow the distribution of minor OS updates, QuickTime installers, and other things on magazine and user-group CDs but they ended this policy a few years ago.

I'd venture that the logic behind this policy is that, if issues arise due to the magazine or UG's negligence then Apple might have to bear the weight of additional support, which they want to limit as much as possible. This is not unheard-of. I have often tried to install something from a MacAddict CD and had difficulties with the installer, while the downloaded installer worked properly. There have also been some instances of CDs being distributed with the autostart worm or other viruses.

It's inconvenient to be sure, but Apple provides upgrade CDs for $19.95 - less than the cost of a month of DSL service.
 
In fact, in the back of my mind, I've been drawing up the specs for an entire protocol, like ftp or http for this. It's called CAWD.

Centrally Authenticated - Widely Distributed

I haven't gone into details as to the transmission method, that parts not really so important. The only important thing is that it's extensible. CD, type it in yourself, gzip, gnutella, ftp, it shouldn't matter. What matters is that what you get is what you think you're getting.

You get a package, the package is verified locally for completeness and lack of errors. Then there is a connection with Apple proper, at which point your computer states that it has a package with such an identity, and requests confirmation. A secure channel is brought up using a known public encryption key to eliminate faking of communication, man in the middle corruption, etc. Now, Apple says, the MD5 check sum for this package should be blah, creation date, and size are like so, and check sum for bits 3700-4929 should be such and such, also, give me check sum for another group of random bits.

So now your client does some checksumming, and you get a confirmation from Apple as to the package's authenticity. It's the last two authentications that are really important to this. They allow information that could not be known without having the package to be transmitted both ways. Because the asking question would be random, no two question answer pairs would be alike, so faking data shouldn't be possible, even if you've heard another full transfer take place. It's also important that the client is in charge of this and that the information is simply supplied to the client for intelligent handling. But there would be unfakeable data in the databanks at Apple about whether or not you have the package in question, and if there is a hoax running amok.

Also, any package should be assemble-able from 1M parts. Those are easy enough to throw around. Hell they fit on floppies. This would allow multi path simultaneous download of large files, as well as easy restart of cut off downloads.

Something like this isn't that hard to do, it just needs to be done right by someone big and everyone would follow. It solves so many problems, and alleviates others without creating problems or mandating a workflow change for how things are done now.

So yeah, I agree, it should be done. I'd work on it, but I'm really busy. I'm mostly an idea guy anyway, but that is my idea. :)
 
You must log in or register to reply here.
Back
Top