Friday 14 February 2014

Re: remove i386 from foreign arch on server install?

On Fri, 14 Feb 2014, Iain Lane wrote:

> On Fri, Feb 14, 2014 at 12:42:09AM -0500, Scott Moser wrote:
> > On Thu, 13 Feb 2014, Scott Ritchie wrote:
> > […]
> > I personally think its an extremely high cost bandwidth cost spread across
> > Canonical, other mirror providers and the end user to account for a very
> > rare case where someone would want to do this.
> >
> > That fresh install I just did, when I type 'apt-get update' (after rm -Rf
> > /var/lib/dpkg/lists), apt tells me:
> > with i386 enabled:
> > Fetched 27.6 MB in 16s (1,655 kB/s)
> > du /var/lib/apt/lists: 133M
> > without i386 enabled:
> > Fetched 20.2 MB in 11s (1,687 kB/s)
> >
> > du /var/lib/apt/lists: 94M
> >
> > So 40M of space and 7M of network traffic and 5 seconds of time (having
> > hit a local proxy).
>
> This analysis is misleading, because the release pocket (the big one)
> doesn't change for stable releases. Downloading all of that data isn't
> something which is done all of the time for every user.

Fair. However, the 40M of space *is* permanent waste.
And HEAD'ing *is* done all the time for every user, and -updates
and -proposed change frequently. It is real cost, and I'm suggesting it
comes at very little gain.

To see that cost, using a local caching proxy, I did repeated 'apt-get
update' with and without i386 in the foreign arch list. The *best* case
scenario I saw (local proxy all of this cached) was real time of 7.5
seconds for without, and 9.5 seconds with.

It is inarguable that there is cost. Ignoring source debs, it is exactly
a doubling of the number of http requests.

No one seems to be suggesting they install lots of i386 packages on their
amd64 server systems. (Remember, this wasn't even *possible* 30 months
ago).