Tuesday, 28 June 2016

Re: Installation Media and supportability of i386 in 18.04 LTS Re: Ubuntu Desktop on i386

Hi Dimitri,

I'll work on creating a new public survey (and possibly a separate partner/customer one).

Based on my previous one, my biggest concerns were for Lubuntu/Xubuntu.  With recent memory testing [1] it's even more true for Lubuntu.  (And if you only <512 MB of Ram - Docker, ZFS and system intensive games likely won't matter to you, and Firefox is much better in low-memory than Chrome anyway)

I don't see any point in continuing to build i386 cloud-images for 16.10/17.04/17.10 if we're just going to drop them for 18.04.  If we're concerned with memory usage in small cloud instances we could just work to provide something like zram by default.

I'd like to see most flavors drop i386 before 18.04 (might as well do it now..) but we keep the 18.04 kernel and d-i (and Lubuntu) for i386.  I don't see much reason to separate the userspace security support, but we will see what the surveys say.

Anyway next steps I see:
* We discussed dropping Ubuntu-desktop i386 images for 16.10+ previously.  That seems like the obvious one to drop i386 first.  Anyone against doing that now?
* I'll write and distribute the surveys.
* Ask specific flavors if they want to drop i386 ahead of these plans being finished.

Kind regards,

[1] https://bryanquigley.com/memory-usage/ubuntu-16-04-livecd-memory-usage-compared

On Tue, Jun 28, 2016 at 9:54 AM, Dimitri John Ledkov <xnox@ubuntu.com> wrote:
Hello Bryan,

Let me resurrect this thread. In the context of what we should be
doing in 18.04 and what to do between now and then.

In 2018:
- it will be over 2 years since 3rd party ISVs stopped supporting
software on i386, or even never had it officially
- e.g. Google Chrome, ZFS, Docker, etc
- with both desktop and server software developed, tested and deployed
on amd64 only

And in 2018, the question will come if we can effectively provide
security support on i386.

Between now and 2018, it would be logical to limit amount of new
installations of i386, because cross-grading between i386->amd64 is
not something we can reliably ship.
We must continue provide the i386 port, to support multiarch and 3rd
party legacy application that are only available as i386 binaries.

Building i386 images is not "for free", it comes at the cost of
utilizing our build farm, QA and validation time. Whilst we have
scalable build-farms, i386 still requires all packages, autopackage
tests, and ISOs to be revalidated across our infrastructure. As well
as take up mirror space & bandwidth.

Thus the question is what can we and what should we do to limit i386
installations before they become unsupportable?

Here is an example draft plan to bikeshed over:

16.10, 17.04, 17.10:
* continue to provide i386 port to run legacy applications on amd64
* continue to build i386 d-i / netboot installer
* continue to build i386 kernel
* continue to build i386 cloud-images
* stop producing i386 ubuntu-desktop.iso
* stop producing i386 ubuntu-server.iso

18.04 LTS:
* continue to provide i386 port to run legacy applications on amd64
* stop producing i386 d-i / netboot installer
* stop producing i386 kernel
* stop producing i386 cloud-images
* stop producing i386 ubuntu-desktop.iso
* stop producing i386 ubuntu-server.iso

* Stop providing i386 port
* Run legacy i386 only application in snaps / containers / virtual machines

Or some other variation of above things and/or adjusted timelines.
What do you think is appropriate? Can we survey and/or somehow
validate if above would be appropriate or needs to be extended or can
be shortened?

The key point here is lack of upstream software support and upstream
security support on i386, rather than actual hardware being out of
stock and/or old.

In essence this would mean April 2021 as the sunset for i386 as the
host/base OS architecture. And April 2023 to run legacy i386
applications with security support.



On 2 February 2016 at 02:12, Bryan Quigley <bryan.quigley@canonical.com> wrote:
> The plan from the session we did over a year ago was:
> "Specifically the Ubuntu (x86_32) desktop CD will be moved to cdimage
> around opening of 16.10".   The argument is that it was easy to build
> the CD and it was cheap to do.  It would be a community build that
> wouldn't be promoted on the Ubuntu website or officially tested.
>I think we could drop Ubuntu desktop, server and cloud images tomorrow 
> It doesn't make sense to stop building the CD unless:
> * We make the unity packages x86_64 bit only (what's the point in
> having less easy to test latest 32-bit unity packages?)
> * We drop x86_32 bit kernel support (guessing not something to
> consider until after 18.04?)
> I think it also makes sense to see if other derivatives want to go
> x86_64-bit only like  maybe Kubuntu (like I believe project Neon
> targets just 64 bit).  At some point we are going to want drop x86_32
> kernel support and just have 32-bit compatibility libraries, but I
> don't know when that makes sense.
> Also, does Valve Steam product rely on i386 multiarch binaries?
> Yes, it does, but it also downloads it's own Steam runtime with it's
> own libraries.
> And Netflix - does that run on amd64-only without i386
> multiarch?  I believe that runs completely with libs if you use Google Chrome.
> Oh, and also Google Chrome is dropping Linux x86_32 bit support.
> I'm also happy to revisit my survey [2] and see where people are today.
> Thanks for bringing this up again!
> Bryan
> [1] https://blueprints.launchpad.net/ubuntu/+spec/development-1411-drop-x86-32
> [2] https://bryanquigley.com/crazy-ideas/32-bit-usage-survey-results
> [3] http://summit.ubuntu.com/uos-1411/meeting/22353/when-should-we-stop-making-32-bit-images/
> On Mon, Feb 1, 2016 at 5:14 PM, Dimitri John Ledkov <xnox@ubuntu.com> wrote:
>> Hello,
>> Ubuntu has an i386 port which is fully supported.
>> There a bunch of 3rd party applications that rely on the Multi-Arch
>> technology to support/use i386 binaries on amd64 (e.g. Skype from the
>> partner archive). BTW, can we ask Microsoft to publish native amd64
>> binaries, rather than those that rely on multi-arch i386? Also, does
>> Valve Steam product rely on i386 multiarch binaries? or is it fully
>> amd64? (and e.g. downloads/bundles/ships any required i386 binaries
>> that it needs)? And Netflix - does that run on amd64-only without i386
>> multiarch?
>> However, it seems to me that this is done specifically on otherwise
>> full amd64 installations.
>> My guess is that: all currently shipped hardware, with enough support
>> to run full Unity (7) Desktop, is amd64. Tested with amd64 kernel, and
>> amd64 graphics drivers. And hardware validation is done on amd64 too.
>> In 2016, people with i386-only hardware are unlikely to be capable to
>> run Unity 7 Desktop, and probably run other Ubuntu variants.  I guess
>> there are some accidental i386 users, e.g. those that have installed
>> i386 variant on amd64 hardware.
>> Does it still make sense to build ubuntu-desktop-i386.iso? Validate
>> it? Test it on amd64 hardware? Ship it?
>> To me this seems like a futile effort. Imho, we should only test the
>> relevant multiarch i386 pieces that are there to support 3rd-party,
>> i386-only apps on amd64 desktop.
>> This is specifically about building, validating and shipping
>> ubuntu-desktop-i386.iso, specifically for the Ubuntu Desktop flavour.
>> Which I am suggesting should be dropped. Without any other changes to
>> the archive and/or publishing i386 binaries.
>> --
>> Regards,
>> Dimitri.
>> --
>> ubuntu-devel mailing list
>> ubuntu-devel@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel