On Thu, 24 Aug 2006 20:14:03 BST, n3td3v said:
I believe for their operating system and their web browser Microsoft
take up half or all the original size of the Microsoft product.
So? What's that actually *prove*?
I don't have the resources to carry out this study on my own, and I
some folks do have those resources to release such information to
We need this information to be published professionally so its
media outlet consumption.
No, you don't.
Part of the problem is that the size of the "patch" is *highly*
on the details of the packaging system. If you want to go *that*
you shouldn't hope to *ever* get Linux accepted. Let's take a look at
Redhat/Fedora package kernel "patches":
The original Fedora Core 5 kernel for a single-processor 686:
-rw-r--r-- 1 263 263 14070190 Mar 14 23:23
Updates so far:
-rw-r--r-- 1 2220 2220 15433301 Jul 15 00:13
-rw-r--r-- 1 2220 2220 15442084 Aug 10 14:22
Oh my *GOD*, the patches are twice the size of the original. And it's
over on RHEL 4, where they've shipped:
Plus others I've possibly missed. Size of patches is 5x the size of
Why? Because the RPM format includes a replacement of *all* the files
package (so that it's easily slipstreamed and install the "latest and
greatest"). IBM AIX's "installp" format only ships updated files -
ends up making updates a lot more challenging (it's possible to need
as many as
*4* or even more separate installp files to install a particular
Trying to count the size of the patch also runs astray when you have a
that changes an API (for instance, adding a parameter to a function
Most of the time, this ends up meaning that software tools like 'make'
recompile most of the package, even if only 1/5 of the recompiled
*really* need it. And trying to trim down the list by hand to find
that 1/5 is
*dangerous*, because if you miss one, you *will* have problems. Given
relatively cheap nature of both bandwidth and disk, most software
end up erring on the side of caution.
The metric you *want* to measure is what percentage of patches are
defective and require patching.