12.04 LTS: 64-bit desktop by default? - how about 13.04?

[Benjamin Kerensa]

I think that Alan is right in his suggestion that we make amd64 images
default before the next LTS.

I think the hardware out there that won't support amd64 is small and like
our desktop and applications we need to move forward and not stay in the
past.
On Jan 15, 2013 10:47 PM, "Alan Bell" <alanbell at ubuntu.com> wrote:
>
> 1 year on is it time to reevaluate the thinking around bug 585940?
> https://bugs.launchpad.net/ubuntu-website-content/+bug/585940
>
> we now have the added situation that the 32 bit installer does not work
on EFI computers
> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1025555
>
> Personally I think it is now very hard to find computers that won't do
64bit and is getting a lot easier to find computers that won't install the
32 bit image. It would probably be a good idea to get a 64 bit by default
release out prior to the 14.04 LTS.
>
> Alan.
>
> On 16/04/12 07:03, Steve Langasek wrote:
>>
>> Hi folks,
>>
>> Back at last UDS in November, we discussed whether it was time to switch
to
>> presenting 64-bit images as the default image for desktop, like they
already
>> are for server, now that all new desktop hardware is 64-bit and
multiarch is
>> a reality.
>>
>> There was a rough consensus at UDS that the blockers were solved, but
that
>> the question should be taken to ubuntu-devel to gather more input.  That
>> input-gathering is happening much later than intended, but here we are
now.
>>
>> The blueprint at
>> <
https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-64bit-by-default
>
>> includes links to some data gathered by the inimitable Colin King,
showing
>> that in terms of performance, there are both pros and cons for switching
to
>> amd64: memory consumption goes up, and therefore power consumption goes
up
>> if the system is making more use of swap, but on the other side, most
>> CPU-bound operations will be faster on amd64.  So there is no clear
>> performance argument for preferring one over the other.
>>
>> Where multiarch is concerned, we've made good progress on library
coverage;
>> over 400 library packages are multiarch coinstallable in 12.04, including
>> most of the usual suspects in the desktop stack, and indeed there are two
>> packages in the partner repository now that are available only as i386
>> packages installable using multiarch, instead of using ia32-libs which is
>> now just a compatibility wrapper package.  So from what I've seen
>> compatibility with 32-bit binary software is in pretty good shape as
well.
>>
>> Are there problems that we've overlooked with regards to shipping 64-bit
by
>> default on the desktop, or is it reasonable to make this switch for 12.04
>> LTS?  Is there 32-bit binary software that you know about which is not
yet
>> supported on amd64 via multiarch, and ought to be before we consider
making
>> 64-bit the default?
>>
>> Note that we're talking about three changes here:
>>
>>   - Changing the default download link on ubuntu.com to point to 64-bit
>>     desktop images
>>   - Changing the pressed CDs distributed by Canonical to be 64-bit
instead of
>>     32-bit
>>   - Changing the architecture used for preformatted USB disks sold in the
>>     Canonical shop
>>
>> In general, if people can think of reasons not to switch to 64-bit for
one
>> of these, those arguments would apply to the other; so if we think we're
>> ready for a switch, that switch should be applied across the board.
>>
>> And regardless of which we decide to use as the default, both of amd64
and
>> i386 will continue to be supported architectures for the length of 12.04
LTS
>> and will remain available for download.
>>
>> Feedback welcome!
>>
>>
>>
>
>
> --
> I work at http://libertus.co.uk
>
>
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20130115/a46d2f9c/attachment-0001.html>