Windows SDK download and SQM data
I thought you might enjoy hearing about what the Windows SDK's download and user-submitted data are looking like. This data is as of May 7th, 2007.
Successful downloads of the Windows Vista Client RTM:
ISO 335,909, 37%
Web 577,760, 63%
Total 912,850
The trend towards a higher percentage of web downloads continues. In February 60% of all users had used the ISO; those numbers seem to have flipped.
SQM data:
We use SQM (aka CEIP) information to track which custom install options users choose. This information is collected anonymously and absolutely nothing that shows or implies any user information is collected.
A total of 7286 users have sent us SQM data. Of those, 4874 had successful downloads and 2502 had unsuccessful downloads. The users with successful downloads who sent SQM data represent .798% of all successful users. In other words, 99.2% of all users with successful downloads did not send data.
Of those users that did send data, a good percentage choose other than the standard install options. The table below represents the percentage of those 4784 users who deselected the various install options.
Option |
% deselect |
Win32 docs |
17.2 |
.NET Framework docs |
13.4 |
.NET Samples in Docs |
15.3 |
.NET Samples in Zips |
14.6 |
Win32 samples |
17.2 |
Vista Headers and Libs (parent node) |
16.9 |
Headers |
16.5 |
x86 Libs |
21.6 |
x64 Libs |
77.9 |
VC++ Compilers (parent node) |
20.1 |
x86 Compilers |
24.9 |
x64 Compilers |
78.8 |
FxCop |
22.4 |
WinDbg |
20.9 |
.NET Framework tools |
12.1 |
Win32 tools |
15.6 |
.NET Compact Framework |
91.7 |
What's your take on this information?
Comments
- Anonymous
May 29, 2007
It shows that
- faster network connections becoming more prevalent
- people are getting sick of ever increasing size of the download as it always has also tons of stuff you don't want Solution: You could increase the efficiency and ISO usage by building a WebMounter.exe that instead of installing the SDK to SDK path, creates a lazy-downloading cache there that first caches entire ISO directory & subdirectory listing (as they aren't going to be changing) thus allowing fast indexing of the SDK directory, then upon access of files, accessing the files in the ISO from nearby Akamai mirror. To make this useful for other purposes as well as decreasing exploitability I suggest there to be a managed code user mode service that handles the downloading, caching and verification on fly. The filesystem mini-redirector acts just as a small proxy to relay the readfile/seek into the managed service which then either pulls them from cache or the akamai mirrored ISO.