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

Tue Jun 28 19:10:22 UTC 2016

Survey is done.  Please only fill this out if you are running a i386 Ubuntu
(any flavor Kubuntu, Lubuntu, Server, Cloud, etc).  I'm going to wait for a
few a bit before posting it on news sites to see if I made any mistakes in
the survey.  Let me know if anything is amiss.
http://goo.gl/forms/UfAHxIitdWEUPl5K2

On Tue, Jun 28, 2016 at 11:31 AM, Dimitri John Ledkov <xnox at ubuntu.com>
wrote:

> Hello,
>
>
> On 28 June 2016 at 16:02, Bryan Quigley <bryan.quigley at canonical.com>
> wrote:
> > Hi Dimitri,
> >
> > I'll work on creating a new public survey (and possibly a separate
> > partner/customer one).
> >
>
> Thank you!
>
> > 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.
> >
>
> From the survey it makes sense to investigate our memory usage and
> figure out if we can lower steady state committed memory throughout.
> Offering zram to cloud instances sounds interesting, this sounds a bit
> like the swapfile package for cloud.
>
> > 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?
>
> Well Ubuntu Desktop should weigh in what they want to do.
>
> > * I'll write and distribute the surveys.
>
> +1
>
> > * Ask specific flavors if they want to drop i386 ahead of these plans
> being
> > finished.
> >
>
> Or even more broadly, what is each flavor current vision w.r.t. i386
> over the next LTS cycle.
>
> > Kind regards,
> > Bryan
> >
> > [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 at 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
> >>
> >> 18.10+:
> >> * 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.
> >>
> >> Regards,
> >>
> >> Dimitri.
> >>
> >>
> >> On 2 February 2016 at 02:12, Bryan Quigley <bryan.quigley at 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 at 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 at lists.ubuntu.com
> >> >> Modify settings or unsubscribe at:
> >> >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
> >>
> >>
> >>
> >> --
> >> Regards,
> >>
> >> Dimitri.
> >
> >
>
>
>
> --
> Regards,
>
> Dimitri.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20160628/d02e336f/attachment.html>