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

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Dimitri John Ledkov
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 <[hidden email]> 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.
>
> 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 <[hidden email]> 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
>> [hidden email]
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel



--
Regards,

Dimitri.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

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

Bryan Quigley-2
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,
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel



--
Regards,

Dimitri.


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

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

Dimitri John Ledkov
Hello,


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



--
Regards,

Dimitri.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

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

Bryan Quigley-2
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.

On Tue, Jun 28, 2016 at 11:31 AM, Dimitri John Ledkov <[hidden email]> wrote:
Hello,


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



--
Regards,

Dimitri.


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

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

Seth Arnold
In reply to this post by Dimitri John Ledkov
On Tue, Jun 28, 2016 at 02:54:13PM +0100, Dimitri John Ledkov wrote:
> 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.

Thanks for raising this again; it'd be nice to have a plan in place before
we wind up in a difficult situation.

> 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

Note that at some point, we may need to stop supporting specific packages
on 32 bit systems. Some of our larger packages require modifications to
compile and link on 32 bit platforms and we're probably going to see one
or more of Firefox, Thunderbird, Chromium browser, Libreoffice, etc., no
longer buildable on small-memory platforms.

We may need to abandon upstream packages along the way. (And some of these
huge packages are not practical for us to backport security fixes.) (See
also, precise's chromium-browser.)

> 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
I'm afraid this proposal may strand some current i386 users on a release
with no lifetime to it.

16.04's 32 bit support has a five-year lifespan. We may not be able to
support the whole thing for the full five years but it should mostly work.

But if we release 16.10, 17.04, 17.10 i386, we're basically encouraging
users to install them and upgrade them and then find out in mid-2018 that
they've reached the end of their OS life and no way back to the safety of
16.04 LTS.

I propose that 16.04 LTS should be the last release with i386 support.
That way we don't leave anyone with a choice of (a) keep running
known-insecure 17.10 in 2018 or (b) figure out how to do a downgrade
back to 16.04 LTS.

I'm not sure how we acheive this specific goal but I think we shouldn't
encourage i386 (or armhf?) users off of 16.04 LTS.

Thanks

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Jeremy Bicha-2
On Tue, Jun 28, 2016 at 4:08 PM, Seth Arnold <[hidden email]> wrote:
> I propose that 16.04 LTS should be the last release with i386 support.
> That way we don't leave anyone with a choice of (a) keep running
> known-insecure 17.10 in 2018 or (b) figure out how to do a downgrade
> back to 16.04 LTS.

+1 Dropping the i386 install disk is much better immediately after an
LTS instead of immediately before.

> I'm not sure how we acheive this specific goal but I think we shouldn't
> encourage i386 (or armhf?) users off of 16.04 LTS.

We can tell update-manager and do-release-upgrade to not allow
upgrading i386 with an explanation of why. That should send a big
signal that it is no longer officially supported.

Jeremy

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

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

code

Hi,

Excuse the top posting, only have a phone available.

Ubuntu MATE works with a few organisations around the world, one in my own country, that refurbish donated computers, install them with Ubuntu MATE and give (or sell them for next to nothing) to schools, disadvantaged families and people who otherwise wouldn't be able to afford a computer.

I'll get in touch with them and find how, or if, this decision would affect them.

I saw a mention of armhf in this discussion. Does this proposal put the armhf archive in jeopardy?

Regards, Martin.

On 29 Jun 2016 8:02 a.m., "Jeremy Bicha" <[hidden email]> wrote:
On Tue, Jun 28, 2016 at 4:08 PM, Seth Arnold <[hidden email]> wrote:
> I propose that 16.04 LTS should be the last release with i386 support.
> That way we don't leave anyone with a choice of (a) keep running
> known-insecure 17.10 in 2018 or (b) figure out how to do a downgrade
> back to 16.04 LTS.

+1 Dropping the i386 install disk is much better immediately after an
LTS instead of immediately before.

> I'm not sure how we acheive this specific goal but I think we shouldn't
> encourage i386 (or armhf?) users off of 16.04 LTS.

We can tell update-manager and do-release-upgrade to not allow
upgrading i386 with an explanation of why. That should send a big
signal that it is no longer officially supported.

Jeremy

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

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

Mark Shuttleworth-3
In reply to this post by Seth Arnold

Folks, I think we need to understand whether i386 won't be widely used
for very small IoT devices and hence be important for developers
targeting those. I accept i386 i no longer relevant for PC's and
laptops, but I would not be surprised if 32-bit x86 is used in small
'embedded' environments. Please factor this in to the discussion, and
let's circle back to review once there is an assessment that includes
that insight.

Mark


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Simon Quigley-2
Greetings,

Let's also factor in flavors like Lubuntu that aim to use very minimal
resources and that have the ability to run with ~ 300 MB of RAM on an
i386 machine. While I understand modern applications are removing i386
support, we have a nice application base for Lubuntu for both LXDE and
LXQt that provides a minimal but yet functional desktop environment and
we have people to maintain these applications.

So I'm sort of going with what Mark is saying. Please also factor this
in the discussion.

--
Simon Quigley
[hidden email]
tsimonq2 on Freenode

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

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

Oliver Grawert
In reply to this post by Mark Shuttleworth-3
hi,
Am Mittwoch, den 29.06.2016, 14:37 +0100 schrieb Mark Shuttleworth:
> Folks, I think we need to understand whether i386 won't be widely
> used
> for very small IoT devices and hence be important for developers
> targeting those. I accept i386 i no longer relevant for PC's and
> laptops, but I would not be surprised if 32-bit x86 is used in small
> 'embedded' environments. Please factor this in to the discussion, and
> let's circle back to review once there is an assessment that includes
> that insight.

would we expect to actually have debian-installer/ubiquity based images
for such IoT devices ? 

the archive can not go away anyway (too many apps out there that still
need multiarch i386), so we should still have a base for i386 IoT
Snappy images, chroots and containers (to run on amd64 classic). 

i think in that light the classic installer images can go away (we'll
definitely still have an untested mini.iso and netinst images around,
they come from the d-i build itself, in case someone *really* needs a
fallback classic install here)

ciao
        oli
--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Steve Langasek-6
In reply to this post by code
Hi Martin,

On Wed, Jun 29, 2016 at 08:18:54AM +0100, Martin Wimpress wrote:
> Excuse the top posting, only have a phone available.

> Ubuntu MATE works with a few organisations around the world, one in my own
> country, that refurbish donated computers, install them with Ubuntu MATE
> and give (or sell them for next to nothing) to schools, disadvantaged
> families and people who otherwise wouldn't be able to afford a computer.

> I'll get in touch with them and find how, or if, this decision would affect
> them.

For various reasons (e.g. compatibility with legacy 32-bit apps on the
desktop; IoT devices running Ubuntu Core), we should not expect to be
dropping i386 as an architecture from the archive before 18.04.

Individual flavor communities should therefore feel comfortable making their
own decision about whether to continue providing i386 images in 18.04,
independent of what we decide for the Ubuntu Desktop and Server flavors -
with the caveat that, since the forcing function for dropping these flavors
is security supportability of key applications, community flavors should
avoid representing to their users a level of support that they are in no
position to deliver on.

> I saw a mention of armhf in this discussion. Does this proposal put the
> armhf archive in jeopardy?

Neither armhf nor i386 should be dropped from the archive in the 18.04 time
frame; both are supported architectures for snappy Ubuntu Core.

--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
[hidden email]                                     [hidden email]


> Regards, Martin.
> On 29 Jun 2016 8:02 a.m., "Jeremy Bicha" <[hidden email]> wrote:
>
> > On Tue, Jun 28, 2016 at 4:08 PM, Seth Arnold <[hidden email]>
> > wrote:
> > > I propose that 16.04 LTS should be the last release with i386 support.
> > > That way we don't leave anyone with a choice of (a) keep running
> > > known-insecure 17.10 in 2018 or (b) figure out how to do a downgrade
> > > back to 16.04 LTS.
> >
> > +1 Dropping the i386 install disk is much better immediately after an
> > LTS instead of immediately before.
> >
> > > I'm not sure how we acheive this specific goal but I think we shouldn't
> > > encourage i386 (or armhf?) users off of 16.04 LTS.
> >
> > We can tell update-manager and do-release-upgrade to not allow
> > upgrading i386 with an explanation of why. That should send a big
> > signal that it is no longer officially supported.
> >
> > Jeremy

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Matthias Klose-6
In reply to this post by Mark Shuttleworth-3
On 29.06.2016 15:37, Mark Shuttleworth wrote:
>
> Folks, I think we need to understand whether i386 won't be widely used
> for very small IoT devices and hence be important for developers
> targeting those. I accept i386 i no longer relevant for PC's and
> laptops, but I would not be surprised if 32-bit x86 is used in small
> 'embedded' environments.

isn't x32 targeted for these devices? looks like people do the same in the ARM
universe with aarch64ilp32.


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

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

Steve Langasek-6
In reply to this post by Bryan Quigley-2
Hi Bryan,

On Tue, Jun 28, 2016 at 11:02:02AM -0400, Bryan Quigley wrote:
> 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.

+1 for dropping images at the beginning of the LTS meta-cycle, instead of at
the end.  It avoids setting wrong expectations that i386 will continue to be
supported, it saves us effort carrying it forward, and it also gives us
more room to reverse course if it turns out we were mistaken about the need
to continue carrying those images.

> 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.

As a practical matter, as long as we are carrying the architecture in the
archive for a release, we have a requirement internally for some sort of
cloud image for that release (whether or not this is supported publically)
and a kernel to boot it with.  And this base image would need to be de facto
security supported, even if there is no official security support for the
packages in main.

We have the capability to mark different support periods in the archive by
package×architecture, and should certainly do this.  Most people don't look
at this information, however; I think that for packages that we know won't
be LTS security-supportable on a particular architecture, we should consider
dropping those binaries from the archive as well.

--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
[hidden email]                                     [hidden email]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Robert Ancell-3
In reply to this post by Steve Langasek-6


On Thu, Jun 30, 2016 at 4:41 AM Steve Langasek <[hidden email]> wrote:

On Wed, Jun 29, 2016 at 08:18:54AM +0100, Martin Wimpress wrote:
> Excuse the top posting, only have a phone available.

> Ubuntu MATE works with a few organisations around the world, one in my own
> country, that refurbish donated computers, install them with Ubuntu MATE
> and give (or sell them for next to nothing) to schools, disadvantaged
> families and people who otherwise wouldn't be able to afford a computer.

> I'll get in touch with them and find how, or if, this decision would affect
> them.

For various reasons (e.g. compatibility with legacy 32-bit apps on the
desktop; IoT devices running Ubuntu Core), we should not expect to be
dropping i386 as an architecture from the archive before 18.04.

Individual flavor communities should therefore feel comfortable making their
own decision about whether to continue providing i386 images in 18.04,
independent of what we decide for the Ubuntu Desktop and Server flavors -
with the caveat that, since the forcing function for dropping these flavors
is security supportability of key applications, community flavors should
avoid representing to their users a level of support that they are in no
position to deliver on.


It may be worth considering disabling i386 builds for individual packages to reduce the support costs. That way the core packages can build for i386 and be used in IoT systems while the graphical application stacks can stop building for i386. There would be some challenges to negotiate overlap with the flavours (i.e. MATE might want their stack i386 and Unity not) and a practical way to do this (we don't want to have an Ubuntu version of the packages that come from Debian with only a change to the "Architecture" field in debian/control).

--Robert

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

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

Stéphane Graber-2
On Wed, Jun 29, 2016 at 09:33:24PM +0000, Robert Ancell wrote:

> On Thu, Jun 30, 2016 at 4:41 AM Steve Langasek <[hidden email]>
> wrote:
>
> >
> > On Wed, Jun 29, 2016 at 08:18:54AM +0100, Martin Wimpress wrote:
> > > Excuse the top posting, only have a phone available.
> >
> > > Ubuntu MATE works with a few organisations around the world, one in my
> > own
> > > country, that refurbish donated computers, install them with Ubuntu MATE
> > > and give (or sell them for next to nothing) to schools, disadvantaged
> > > families and people who otherwise wouldn't be able to afford a computer.
> >
> > > I'll get in touch with them and find how, or if, this decision would
> > affect
> > > them.
> >
> > For various reasons (e.g. compatibility with legacy 32-bit apps on the
> > desktop; IoT devices running Ubuntu Core), we should not expect to be
> > dropping i386 as an architecture from the archive before 18.04.
> >
> > Individual flavor communities should therefore feel comfortable making
> > their
> > own decision about whether to continue providing i386 images in 18.04,
> > independent of what we decide for the Ubuntu Desktop and Server flavors -
> > with the caveat that, since the forcing function for dropping these flavors
> > is security supportability of key applications, community flavors should
> > avoid representing to their users a level of support that they are in no
> > position to deliver on.
> >
> >
> It may be worth considering disabling i386 builds for individual packages
> to reduce the support costs. That way the core packages can build for i386
> and be used in IoT systems while the graphical application stacks can stop
> building for i386. There would be some challenges to negotiate overlap with
> the flavours (i.e. MATE might want their stack i386 and Unity not) and a
> practical way to do this (we don't want to have an Ubuntu version of the
> packages that come from Debian with only a change to the "Architecture"
> field in debian/control).
>
> --Robert
Doing so would prevent desktop users from installing binary 32bit
packages that rely on Ubuntu's multi-arch support.

I'm not sure how much of an issue this still is, given that a bunch of
them finally have 64bit builds now, but it may still be a problem for a
number of commercial software.

--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Robert Ancell-3


On Thu, Jun 30, 2016 at 9:37 AM Stéphane Graber <[hidden email]> wrote:
On Wed, Jun 29, 2016 at 09:33:24PM +0000, Robert Ancell wrote:
> It may be worth considering disabling i386 builds for individual packages
> to reduce the support costs. That way the core packages can build for i386
> and be used in IoT systems while the graphical application stacks can stop
> building for i386. There would be some challenges to negotiate overlap with
> the flavours (i.e. MATE might want their stack i386 and Unity not) and a
> practical way to do this (we don't want to have an Ubuntu version of the
> packages that come from Debian with only a change to the "Architecture"
> field in debian/control).
>
> --Robert

Doing so would prevent desktop users from installing binary 32bit
packages that rely on Ubuntu's multi-arch support.

I'm not sure how much of an issue this still is, given that a bunch of
them finally have 64bit builds now, but it may still be a problem for a
number of commercial software.
 
This would have to be done within the messaging of "i386 is no longer supported on Ubuntu desktop after 16.04" meaning we would expect that third party i386 software would no longer work. Of course, they should provide i386 snaps with all the libraries installed if they want to keep shipping in that form...

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

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

code
Hi,

Just to be clear, I'm not proposing that Ubuntu MATE absolutely want to continue providing 32bit iso images. 

My daughter has a Dell Mini 9 Atom netbook, it is 32bit only. I think netbooks are in the category of computers sold fairly recently that are still very usable. However, the main concern for me is how often do organisations such as FixIT - Leeds Coop​ and Reglue​ receive 32bit PC hardware donations? And how this decision affects them and the families and organisations they support who simply don't have the money to spend on a computer. I also volunteer for an organisation that refurbishes donated computers and ships them to schools in Malawi.

I have some statistics for the Ubuntu MATE downloads and the i386 downloads are a tiny percentage when compared to amd64 and armhf (Raspberry Pi). That said, the number of blind and visually impaired individuals using Ubuntu MATE is also extremely small but I continue to invest the effort to ensure Ubuntu MATE is highly accessible. Likewise I would be prepared to continue supporting i386 while there is a socially valuable reason to do so.

With that said, if the Ubuntu Security team determine that maintaining the security profile of i386 is not possible, with particular regard to browsers, then that would undoubtedly influence my thinking. I'm simply not prepared to release a desktop operating system that has inadequate security coverage. We've got some polls running in the various Ubuntu MATE communities to survey what hardware people have access to and I've reached out to some of the charities that make use of Ubuntu MATE to better understand how, or if, this decision might affect them and the work they do.

--
Regards, Martin.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

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

Oliver Grawert
In reply to this post by Robert Ancell-3
hi,
Am Mittwoch, den 29.06.2016, 21:33 +0000 schrieb Robert Ancell:


> It may be worth considering disabling i386 builds for individual
> packages to reduce the support costs. That way the core packages can
> build for i386 and be used in IoT systems while the graphical
> application stacks can stop building for i386. There would be some
> challenges to negotiate overlap with the flavours (i.e. MATE might
> want their stack i386 and Unity not) and a practical way to do this
> (we don't want to have an Ubuntu version of the packages that come
> from Debian with only a change to the "Architecture" field in
> debian/control).

there might be IoT devices with LCD attached that run a fullscreen kiosk
app ... that app might be written in tcl/tk for whatever reason but use
gsettings for all its config ...

... where would you actually draw the line to define what an IoT device
needs and what not ?

and would patching the control files to not build i386 actually be less
work than the few architecture related build issues you might have
throughout a cycle ?

i think we should leave the archive untouched and just drop the official
ubuntu install media.

(if you actually have arch related issues you can still decide to handle
them with low priority)

ciao
        oli

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Dimitri John Ledkov
In reply to this post by Seth Arnold
Hello,

On 28 June 2016 at 21:08, Seth Arnold <[hidden email]> wrote:

>> 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
>
> I'm afraid this proposal may strand some current i386 users on a release
> with no lifetime to it.
>
> 16.04's 32 bit support has a five-year lifespan. We may not be able to
> support the whole thing for the full five years but it should mostly work.
>
> But if we release 16.10, 17.04, 17.10 i386, we're basically encouraging
> users to install them and upgrade them and then find out in mid-2018 that
> they've reached the end of their OS life and no way back to the safety of
> 16.04 LTS.

My current hunch is like this at the moment:

- 18.04 to still have an i386 port in the archive, and be upgradable to.

- 18.04 not having desktop/server install media (however maybe even
releases before that)

- 18.04 has "ubuntu-desktop" but without security support

- 18.04 on i386 having a limited security support, driven only by
particular products if any are on the support timeline at the time

--
Regards,

Dimitri.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

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

Dimitri John Ledkov
In reply to this post by Mark Shuttleworth-3
Hello Mark,

On 29 June 2016 at 14:37, Mark Shuttleworth <[hidden email]> wrote:
>
> Folks, I think we need to understand whether i386 won't be widely used
> for very small IoT devices and hence be important for developers
> targeting those. I accept i386 i no longer relevant for PC's and
> laptops, but I would not be surprised if 32-bit x86 is used in small
> 'embedded' environments. Please factor this in to the discussion, and
> let's circle back to review once there is an assessment that includes
> that insight.
>

Indeed. I believe we will continue to have 32-bit x86 port in 18.04
LTS and we will continue to asses which subsets of it are reasonable
to support and ship in various form factors.

Looking at the SoC and Embedded CPU product lines from Intel (Atom and
launched SoFIA), AMD, VIA - they are all 64-bit capable CPUs.

Is the choice to go i386 there is not due CPU capabilities, but due to
memory constraints?

I think it might make sense to investigate if we can optimise and
reduce our minimal required committed RAM usage on 64-bit, from fixing
software bugs to pulling tricks with compressed RAM and swap. If we
can hit low enough memory usage, a choice to use 64-bit will become
less of issue in such devices. And at the same time improve our
deployment density in the cloud scenarios.

Failing that, is there a sufficient demand in the embedded space for x32 port?

Above are some of the questions to resolve in the coming years.

--
Regards,

Dimitri.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
12