On Tue, Apr 17, 2012 at 05:04:17PM -0700, Kees Cook wrote:
> On Tue, Apr 17, 2012 at 04:17:22PM -0700, Steve Langasek wrote:
> > The key one is this: 25% of all (~16k) submissions to Ubuntu Friendly are
> > from 32-bit machines.
> Hrm. My sample of x86 CPUs taken from Launchpad Bug reports in Nov 2009
> is smaller (7264), but shows a change in adoption rate (4945 had "lm"
> in /proc/cpuinfo), at 32% 32-bit. So 29 months later, 32-bitness has
> fallen 7%. In 2021 we'll be 0% 32-bit! Well ahead of the 2038 bug! ;)
> The problem, frankly, is this is all self-reporting, and doesn't have
> anything to do with the target of "new installs".
That's certainly a weakness of this method, yes. But I can't think of any
reasons why this self-selected sample would be biased in favor of 32-bit
machines compared with the general population of Ubuntu users, and we don't
have any better sources for this kind of data at present. (OEM installs,
for instance, are non-representative, and aren't affected by the website
Aside from the general trend away from 32-bit CPUs, about which we also
don't have very solid data, I don't see any reason that the incidence of
32-bit CPUs among new installs would be different than among existing
> > Now, this doesn't look at how the ratio is changing over time; but Ubuntu
> > Friendly is itself still a fairly recent initiative, so I don't expect this
> > to have changed much. Switching our default image to a version that just
> > plain won't work on nearly a quarter of the machines users want to use it on
> > strikes me as a non-starter. That's a much higher percentage than anyone
> > was expecting based on the UDS discussion.
> Upgrades will stay on whatever they had before. By definition then,
> all data gathered about existing installs is out of date.
> Regardless, going with the UF measurements, why are we penalizing 75% of
> Ubuntu users? Their experience could be arguably better on 64-bit. It's
> not like we're killing 32-bit. We've killed entire architectures when new
> installs hit 5%. It doesn't seem like it makes sense to wait to change
> the _default_. If things get much lower, people will just want to remove
> the arch entirely. For an LTS, it seems all the more critical to produce
> defaults that will make sense for 5 years. (Assuming the linear 0.24%
> drop per month, at the end of 12.04's LTSness, 14% of the user base will
> have 32-bit CPUs -- seems like it'd be way overdue to change the default
> by then.)
First, it's not penalizing 75% of our users. There's some percentage of
users with 64-bit CPUs who really would be better served by a 32-bit OS; so
if the 25% figure is accurate, the percentage of machines that would ideally
be running i386 is higher than that. (How much higher, we also
unfortunately can't say at the moment. But 64-bit machines with < 2GB RAM
are not uncommon.)
Second, the penalties on each side are not equivalent. The penalty for
installing from an i386 CD when you could be running amd64 is a
difficult-to-quantify performance penalty which, for the average desktop
user, may not actually translate to a degraded computing experience (trading
off CPU performance vs. I/O, memory, and power consumption). The penalty
for installing from an amd64 CD when you need i386 is that you now have a
coaster, or have wasted bandwidth downloading a 700MB image you can't use,
etc. If the user even notices the first, they'll have the option of
upgrading to amd64 or reinstalling. If they run into the second, they'll
definitely notice, and could well give up on Ubuntu as a result.
So certainly, the threshold at which we want to change the default is
somewhere to the left of 50%. How far left I don't know, but I do think 25%
is still too high. IMHO 15% would be about right.
I'd also like to be sure that we have good reason to believe amd64 would be
the *preferred* architecture for over half of our users, not just a
*functional* one, before switching. We don't have data yet on the
prevalence of these 64-bit machines with 1GB of RAM; for all we know they
could make up another 25% of the desktop userbase.
> > So while amd64 is clearly the better option for 64-bit machines with more
> > than 2GB of RAM, it looks like it would be premature to make this the
> > default. Faced with a choice between a default that will be less efficient
> > on higher-end machines, and a default that will fail to boot at all on a
> > quarter of machines, I think we need to be conservative here and stay with
> > 32-bit by default in 12.04. I will therefore not be asking the web team to
> > point at the amd64 desktop image as the default.
> How about changing the way the web presents the default, and move it
> to 64-bit? For example...