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 <[email protected]> wrote: > Hello, > > > On 28 June 2016 at 16:02, Bryan Quigley <[email protected]> > 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 <[email protected]> > > 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 <[email protected] > > > >> 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 <[email protected]> > >> > 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 > >> >> [email protected] > >> >> Modify settings or unsubscribe at: > >> >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > >> > >> > >> > >> -- > >> Regards, > >> > >> Dimitri. > > > > > > > > -- > Regards, > > Dimitri. >
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
