<div dir="ltr">Hi Dimitri,<div><br></div><div>I'll work on creating a new public survey (and possibly a separate partner/customer one).</div><div><br></div><div>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)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Anyway next steps I see:<br>* 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?</div><div>* I'll write and distribute the surveys.</div><div>* Ask specific flavors if they want to drop i386 ahead of these plans being finished.</div><div><br></div><div>Kind regards,</div><div>Bryan</div><div><br></div><div>[1] <a href="https://bryanquigley.com/memory-usage/ubuntu-16-04-livecd-memory-usage-compared" target="_blank">https://bryanquigley.com/memory-usage/ubuntu-16-04-livecd-memory-usage-compared</a><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 28, 2016 at 9:54 AM, Dimitri John Ledkov <span dir="ltr"><<a href="mailto:xnox@ubuntu.com" target="_blank">xnox@ubuntu.com</a>></span> wrote:<br><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 Bryan,<br>
<br>
Let me resurrect this thread. In the context of what we should be<br>
doing in 18.04 and what to do between now and then.<br>
<br>
In 2018:<br>
- it will be over 2 years since 3rd party ISVs stopped supporting<br>
software on i386, or even never had it officially<br>
- e.g. Google Chrome, ZFS, Docker, etc<br>
- with both desktop and server software developed, tested and deployed<br>
on amd64 only<br>
<br>
And in 2018, the question will come if we can effectively provide<br>
security support on i386.<br>
<br>
Between now and 2018, it would be logical to limit amount of new<br>
installations of i386, because cross-grading between i386->amd64 is<br>
not something we can reliably ship.<br>
We must continue provide the i386 port, to support multiarch and 3rd<br>
party legacy application that are only available as i386 binaries.<br>
<br>
Building i386 images is not "for free", it comes at the cost of<br>
utilizing our build farm, QA and validation time. Whilst we have<br>
scalable build-farms, i386 still requires all packages, autopackage<br>
tests, and ISOs to be revalidated across our infrastructure. As well<br>
as take up mirror space & bandwidth.<br>
<br>
Thus the question is what can we and what should we do to limit i386<br>
installations before they become unsupportable?<br>
<br>
Here is an example draft plan to bikeshed over:<br>
<br>
16.10, 17.04, 17.10:<br>
* continue to provide i386 port to run legacy applications on amd64<br>
* continue to build i386 d-i / netboot installer<br>
* continue to build i386 kernel<br>
* continue to build i386 cloud-images<br>
* stop producing i386 ubuntu-desktop.iso<br>
* stop producing i386 ubuntu-server.iso<br>
<br>
18.04 LTS:<br>
* continue to provide i386 port to run legacy applications on amd64<br>
* stop producing i386 d-i / netboot installer<br>
* stop producing i386 kernel<br>
* stop producing i386 cloud-images<br>
* stop producing i386 ubuntu-desktop.iso<br>
* stop producing i386 ubuntu-server.iso<br>
<br>
18.10+:<br>
* Stop providing i386 port<br>
* Run legacy i386 only application in snaps / containers / virtual machines<br>
<br>
Or some other variation of above things and/or adjusted timelines.<br>
What do you think is appropriate? Can we survey and/or somehow<br>
validate if above would be appropriate or needs to be extended or can<br>
be shortened?<br>
<br>
The key point here is lack of upstream software support and upstream<br>
security support on i386, rather than actual hardware being out of<br>
stock and/or old.<br>
<br>
In essence this would mean April 2021 as the sunset for i386 as the<br>
host/base OS architecture. And April 2023 to run legacy i386<br>
applications with security support.<br>
<br>
Regards,<br>
<br>
Dimitri.<br>
<br>
<br>
On 2 February 2016 at 02:12, Bryan Quigley <<a href="mailto:bryan.quigley@canonical.com" target="_blank">bryan.quigley@canonical.com</a>> wrote:<br>
> The plan from the session we did over a year ago was:<br>
> "Specifically the Ubuntu (x86_32) desktop CD will be moved to cdimage<br>
> around opening of 16.10".   The argument is that it was easy to build<br>
> the CD and it was cheap to do.  It would be a community build that<br>
> wouldn't be promoted on the Ubuntu website or officially tested.<br>
>I think we could drop Ubuntu desktop, server and cloud images tomorrow <br>
> It doesn't make sense to stop building the CD unless:<br>
> * We make the unity packages x86_64 bit only (what's the point in<br>
> having less easy to test latest 32-bit unity packages?)<br>
> * We drop x86_32 bit kernel support (guessing not something to<br>
> consider until after 18.04?)<br>
><br>
> I think it also makes sense to see if other derivatives want to go<br>
> x86_64-bit only like  maybe Kubuntu (like I believe project Neon<br>
> targets just 64 bit).  At some point we are going to want drop x86_32<br>
> kernel support and just have 32-bit compatibility libraries, but I<br>
> don't know when that makes sense.<br>
><br>
> Also, does Valve Steam product rely on i386 multiarch binaries?<br>
> Yes, it does, but it also downloads it's own Steam runtime with it's<br>
> own libraries.<br>
><br>
> And Netflix - does that run on amd64-only without i386<br>
> multiarch?  I believe that runs completely with libs if you use Google Chrome.<br>
> Oh, and also Google Chrome is dropping Linux x86_32 bit support.<br>
><br>
> I'm also happy to revisit my survey [2] and see where people are today.<br>
><br>
> Thanks for bringing this up again!<br>
> Bryan<br>
><br>
> [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><br>
> [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><br>
> [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><br>
><br>
> On Mon, Feb 1, 2016 at 5:14 PM, Dimitri John Ledkov <<a href="mailto:xnox@ubuntu.com" target="_blank">xnox@ubuntu.com</a>> wrote:<br>
>> Hello,<br>
>><br>
>> Ubuntu has an i386 port which is fully supported.<br>
>><br>
>> There a bunch of 3rd party applications that rely on the Multi-Arch<br>
>> technology to support/use i386 binaries on amd64 (e.g. Skype from the<br>
>> partner archive). BTW, can we ask Microsoft to publish native amd64<br>
>> binaries, rather than those that rely on multi-arch i386? Also, does<br>
>> Valve Steam product rely on i386 multiarch binaries? or is it fully<br>
>> amd64? (and e.g. downloads/bundles/ships any required i386 binaries<br>
>> that it needs)? And Netflix - does that run on amd64-only without i386<br>
>> multiarch?<br>
>><br>
>> However, it seems to me that this is done specifically on otherwise<br>
>> full amd64 installations.<br>
>><br>
>> My guess is that: all currently shipped hardware, with enough support<br>
>> to run full Unity (7) Desktop, is amd64. Tested with amd64 kernel, and<br>
>> amd64 graphics drivers. And hardware validation is done on amd64 too.<br>
>><br>
>> In 2016, people with i386-only hardware are unlikely to be capable to<br>
>> run Unity 7 Desktop, and probably run other Ubuntu variants.  I guess<br>
>> there are some accidental i386 users, e.g. those that have installed<br>
>> i386 variant on amd64 hardware.<br>
>><br>
>> Does it still make sense to build ubuntu-desktop-i386.iso? Validate<br>
>> it? Test it on amd64 hardware? Ship it?<br>
>><br>
>> To me this seems like a futile effort. Imho, we should only test the<br>
>> relevant multiarch i386 pieces that are there to support 3rd-party,<br>
>> i386-only apps on amd64 desktop.<br>
>><br>
>> This is specifically about building, validating and shipping<br>
>> ubuntu-desktop-i386.iso, specifically for the Ubuntu Desktop flavour.<br>
>> Which I am suggesting should be dropped. Without any other changes to<br>
>> the archive and/or publishing i386 binaries.<br>
>><br>
>> --<br>
>> Regards,<br>
>><br>
>> Dimitri.<br>
<span><font color="#888888">>><br>
>> --<br>
>> ubuntu-devel mailing list<br>
>> <a href="mailto:ubuntu-devel@lists.ubuntu.com" target="_blank">ubuntu-devel@lists.ubuntu.com</a><br>
>> 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><br>
<br>
<br>
<br>
--<br>
Regards,<br>
<br>
Dimitri.<br>
</font></span></blockquote></div><br></div></div></div>