<div dir="ltr">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.<div><div><a href="http://goo.gl/forms/UfAHxIitdWEUPl5K2">http://goo.gl/forms/UfAHxIitdWEUPl5K2</a></div><div class="gmail_extra"> <div class="gmail_quote">On Tue, Jun 28, 2016 at 11:31 AM, Dimitri John Ledkov <<a href="mailto:xnox@ubuntu.com" target="_blank">xnox@ubuntu.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hello, On 28 June 2016 at 16:02, Bryan Quigley <<a href="mailto:bryan.quigley@canonical.com">bryan.quigley@canonical.com</a>> 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. <div class=""><div class="h5"> > Kind regards, > Bryan > > [1] > <a href="https://bryanquigley.com/memory-usage/ubuntu-16-04-livecd-memory-usage-compared" rel="noreferrer" target="_blank">https://bryanquigley.com/memory-usage/ubuntu-16-04-livecd-memory-usage-compared</a> > > On Tue, Jun 28, 2016 at 9:54 AM, Dimitri John Ledkov <<a href="mailto:xnox@ubuntu.com">xnox@ubuntu.com</a>> > 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 <<a href="mailto:bryan.quigley@canonical.com">bryan.quigley@canonical.com</a>> >> 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] >> > <a href="https://blueprints.launchpad.net/ubuntu/+spec/development-1411-drop-x86-32" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/ubuntu/+spec/development-1411-drop-x86-32</a> >> > [2] <a href="https://bryanquigley.com/crazy-ideas/32-bit-usage-survey-results" rel="noreferrer" target="_blank">https://bryanquigley.com/crazy-ideas/32-bit-usage-survey-results</a> >> > [3] >> > <a href="http://summit.ubuntu.com/uos-1411/meeting/22353/when-should-we-stop-making-32-bit-images/" rel="noreferrer" target="_blank">http://summit.ubuntu.com/uos-1411/meeting/22353/when-should-we-stop-making-32-bit-images/</a> >> > >> > On Mon, Feb 1, 2016 at 5:14 PM, Dimitri John Ledkov <<a href="mailto:xnox@ubuntu.com">xnox@ubuntu.com</a>> >> > 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 >> >> <a href="mailto:ubuntu-devel@lists.ubuntu.com">ubuntu-devel@lists.ubuntu.com</a> >> >> Modify settings or unsubscribe at: >> >> <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel</a> >> >> >> >> -- >> Regards, >> >> Dimitri. > > </div></div>-- Regards, Dimitri. </blockquote></div> </div></div></div>