Proposal: Let's drop i386

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Let's drop i386

Colin Watson
On Thu, May 10, 2018 at 04:25:25PM -0400, Thomas Ward wrote:
> However, killing i386 support globally could introduce issues, including
> but not limited to certain upstream softwares having to go away
> entirely, due to the interdependency or issues with how certain apps
> work (read; Wine, 32-bit support, 64-bit support being flaky, and
> Windows apps being general pains in that they work on 32bit but not
> always on 64-bit).

Is there any possibility of building this kind of thing in biarch style
(i.e. on the amd64 architecture, but with -m32 or similar)?  I know that
may well involve building some more biarch libraries along the way, but
it would give us an exit strategy that doesn't involve dropping things
like Wine.

IIRC Steam is also relevant, and I guess that would involve talking to
Valve?

--
Colin Watson                                       [[hidden email]]

--
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: Proposal: Let's drop i386

Jeremy Bicha-2
On Sun, May 13, 2018 at 1:57 PM, Colin Watson <[hidden email]> wrote:
> IIRC Steam is also relevant, and I guess that would involve talking to
> Valve?

I think our users would be better served by Steam becoming a Snap. I
have more explanation at https://launchpad.net/bugs/1759715

I suppose that could be done for Wine too although Wine doesn't
currently have the unsolved maintenance challenges that Steam does.

Thanks,
Jeremy Bicha

--
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: Proposal: Let's drop i386

Matthias Klose-6
In reply to this post by Henri Sivonen
On 13.05.2018 05:00, Henri Sivonen wrote:

> On Thu, May 10, 2018 at 11:25 PM, Thomas Ward <[hidden email]> wrote:
>> However, killing i386 support globally could introduce issues, including
>> but not limited to certain upstream softwares having to go away
>> entirely, due to the interdependency or issues with how certain apps
>> work (read; Wine, 32-bit support, 64-bit support being flaky, and
>> Windows apps being general pains in that they work on 32bit but not
>> always on 64-bit).
>
> If 32-bit x86 support becomes mainly a thing that's run on x86_64
> hardware as a compatibility measure for things like Wine, it would
> make sense to bring the instruction set baseline to the x86_64 level.
> Specifically, it would make sense to compile the 32-bit x86 packages
> with SSE2 unconditionally enabled.
>
> This would mean dropping support for Pentium Pro and earlier or Athlon
> XP and earlier, but it's pretty sad to leave all that performance on
> the table in order to support the few computers still in use that have
> Pentium Pro or earlier or Athlon XP or earlier.
>
> As upstream software assumes SSE2 as the baseline, it will be less and
> less a run-time check and compiling software without SSE2 will mean
> shipping it in a damaged form performance-wise.

I disagree, until you provide data how many packages fail to build, at least in
the testsuites, when run without the extra x87 precision bits.

--
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: Proposal: Let's drop i386

Henri Sivonen
On Sun, May 13, 2018 at 9:34 PM, Matthias Klose <[hidden email]> wrote:

> On 13.05.2018 05:00, Henri Sivonen wrote:
>> On Thu, May 10, 2018 at 11:25 PM, Thomas Ward <[hidden email]> wrote:
>>> However, killing i386 support globally could introduce issues, including
>>> but not limited to certain upstream softwares having to go away
>>> entirely, due to the interdependency or issues with how certain apps
>>> work (read; Wine, 32-bit support, 64-bit support being flaky, and
>>> Windows apps being general pains in that they work on 32bit but not
>>> always on 64-bit).
>>
>> If 32-bit x86 support becomes mainly a thing that's run on x86_64
>> hardware as a compatibility measure for things like Wine, it would
>> make sense to bring the instruction set baseline to the x86_64 level.
>> Specifically, it would make sense to compile the 32-bit x86 packages
>> with SSE2 unconditionally enabled.
>>
>> This would mean dropping support for Pentium Pro and earlier or Athlon
>> XP and earlier, but it's pretty sad to leave all that performance on
>> the table in order to support the few computers still in use that have
>> Pentium Pro or earlier or Athlon XP or earlier.
>>
>> As upstream software assumes SSE2 as the baseline, it will be less and
>> less a run-time check and compiling software without SSE2 will mean
>> shipping it in a damaged form performance-wise.
>
> I disagree, until you provide data how many packages fail to build, at least in
> the testsuites, when run without the extra x87 precision bits.

I don't have this data, but considering that SSE2 is a mandatory part
of x86_64, it seems implausible that packages would be
SSE2-intolerant. Considering that x86_64 defaults to SSE2
floating-point math (or does Ubuntu override this?) and considering
that ARM doesn't have x87 available, it seems implausible that
packages would rely on x87. (On the contrary, since e.g. Firefox and
Chromium upstreams don't do non-SSE2 x86 builds anymore, it seems more
plausible that there exist packages whose upstream doesn't test x87
floating-point math anymore.)

--
Henri Sivonen
[hidden email]
https://hsivonen.fi/

--
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: Proposal: Let's drop i386

Colin Watson
In reply to this post by Jeremy Bicha-2
On Sun, May 13, 2018 at 02:33:08PM -0400, Jeremy Bicha wrote:
> On Sun, May 13, 2018 at 1:57 PM, Colin Watson <[hidden email]> wrote:
> > IIRC Steam is also relevant, and I guess that would involve talking to
> > Valve?
>
> I think our users would be better served by Steam becoming a Snap. I
> have more explanation at https://launchpad.net/bugs/1759715
>
> I suppose that could be done for Wine too although Wine doesn't
> currently have the unsolved maintenance challenges that Steam does.

Would this involve building with -m32 rather than shipping copies of
i386 packages from the archive?  (If the former, I agree that that would
help with this class of problem.  If the latter, it would at best defer
the problem for a few years.)

--
Colin Watson                                       [[hidden email]]

--
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: Proposal: Let's drop i386

Steve Langasek-6
In reply to this post by Gizmo Chicken
On Sat, May 12, 2018 at 12:56:38PM -0400, Gizmo Chicken wrote:
> > I believe deleting i386 and armhf before 18.10 is the politest thing to do

> Provided that i386 and armhf won't be supported in 20.04 LTS (which
> seems to be the case), I fully agree that such support should be
> removed *before* 18.10.  Those needing such support should be
> encouraged to remain on the current LTS, and not lured to 18.10 with a
> false hope of continued support.

> Removing support before 18.10 would also be a good way to draw out
> early feedback.  If enough backlash (and technically feasible to do
> so), perhaps i386 and armhf could be (reluctantly) added back for one
> final LTS, namely 20.04 LTS (and maybe tested in 19.10).  But
> hopefully that wouldn't be needed.

Rebootstrapping an architecture is a non-trivial amount of work.  It is
exceedingly unlikely that, having taken the decision to drop the
architecture, we would then decide to reintroduce it.

--
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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Let's drop i386

Brendan Perrine
In reply to this post by Henri Sivonen
The other question is does anyone test ubuntu on non SSE2 hardware anymore?

On Sun, May 13, 2018 at 11:48 AM, Henri Sivonen <[hidden email]> wrote:
On Sun, May 13, 2018 at 9:34 PM, Matthias Klose <[hidden email]> wrote:
> On 13.05.2018 05:00, Henri Sivonen wrote:
>> On Thu, May 10, 2018 at 11:25 PM, Thomas Ward <[hidden email]> wrote:
>>> However, killing i386 support globally could introduce issues, including
>>> but not limited to certain upstream softwares having to go away
>>> entirely, due to the interdependency or issues with how certain apps
>>> work (read; Wine, 32-bit support, 64-bit support being flaky, and
>>> Windows apps being general pains in that they work on 32bit but not
>>> always on 64-bit).
>>
>> If 32-bit x86 support becomes mainly a thing that's run on x86_64
>> hardware as a compatibility measure for things like Wine, it would
>> make sense to bring the instruction set baseline to the x86_64 level.
>> Specifically, it would make sense to compile the 32-bit x86 packages
>> with SSE2 unconditionally enabled.
>>
>> This would mean dropping support for Pentium Pro and earlier or Athlon
>> XP and earlier, but it's pretty sad to leave all that performance on
>> the table in order to support the few computers still in use that have
>> Pentium Pro or earlier or Athlon XP or earlier.
>>
>> As upstream software assumes SSE2 as the baseline, it will be less and
>> less a run-time check and compiling software without SSE2 will mean
>> shipping it in a damaged form performance-wise.
>
> I disagree, until you provide data how many packages fail to build, at least in
> the testsuites, when run without the extra x87 precision bits.

I don't have this data, but considering that SSE2 is a mandatory part
of x86_64, it seems implausible that packages would be
SSE2-intolerant. Considering that x86_64 defaults to SSE2
floating-point math (or does Ubuntu override this?) and considering
that ARM doesn't have x87 available, it seems implausible that
packages would rely on x87. (On the contrary, since e.g. Firefox and
Chromium upstreams don't do non-SSE2 x86 builds anymore, it seems more
plausible that there exist packages whose upstream doesn't test x87
floating-point math anymore.)

--
Henri Sivonen
[hidden email]
https://hsivonen.fi/

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


--
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: Proposal: Let's drop i386

Gizmo Chicken
In reply to this post by Steve Langasek-6
>> Provided that i386 and armhf won't be supported in 20.04 LTS (which
>> seems to be the case), I fully agree that such support should be
>> removed *before* 18.10.  Those needing such support should be
>> encouraged to remain on the current LTS, and not lured to 18.10 with a
>> false hope of continued support.
>
>> Removing support before 18.10 would also be a good way to draw out
>> early feedback.  If enough backlash (and technically feasible to do
>> so), perhaps i386 and armhf could be (reluctantly) added back for one
>> final LTS, namely 20.04 LTS (and maybe tested in 19.10).  But
>> hopefully that wouldn't be needed.
>
> Rebootstrapping an architecture is a non-trivial amount of work.  It is
> exceedingly unlikely that, having taken the decision to drop the
> architecture, we would then decide to reintroduce it.
>

Hence, as I wrote, "hopefully [adding back i386 and armhf for one
final LTS] wouldn't be needed."

In any case, in my opinion, the final release to include i386 and
armhf should be an LTS release.

I suggest announcing, as soon as possible, what will be the final LTS
release that will include i386 and armhf.  If 18.04 LTS won't be that
final release, then perhaps 20.04 LTS should be that final release.

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

AW: Proposal: Let's drop i386

Fiedler Roman
In reply to this post by Dimitri John Ledkov
> Von: [hidden email] [mailto:[hidden email]] Im
>
> On 11 May 2018 at 16:32, Fiedler Roman <[hidden email]> wrote:
> >
> > > Von: ubuntu-devel [mailto:[hidden email]] Im
> > >
> > > Hello,
> > >
> > > Less and less non-amd64-compatible i386 hardware is available for
> > > consumers to buy today from anything but computer part recycling
> centers.
> > > The last of these machines were manufactured over a decade ago, and
> > > support from an increasing number of upstream projects has ended. ...
> > >
> > > ...
> >  >
> > > We still have a relatively high number if i386 downloads but that doesn't
> > > mean users machines are not capable of amd64. For the flavors remaining
> > > today on i386 here are some i386 to amd64 ratios for 18.04:
> > >
> > > Lubuntu cdimage - 0.87
> > > Lubuntu tracker - 0.64
> > > ...
> >
> > This decision is not only about numbers, but somehow also about ethics. The
> number of e.g. wheel-chair users or other disabled persons might not be
> relevant for a society/economy in terms of numbers. But we honor the value
> of freedom, also for those, who are not that well off than we are. Those would
> not be able to participate in the same way, if we would not assist them by
> providing support for that minority.
> >
> > So for the i386 discussion, there might be only two distinct groups of users
> worth considering:
> >
> > a) Those, who cannot afford newer systems due to economical reasons.
> >
> > b) Those, who do not want to consume more resources due to ethical
> considerations (that's the one for me): how many people could fed or how
> much CO2 prevented, if all systems were some percent smaller on disk/RAM,
> including IT-system production and operation related resource usage?
> Wasting resources is also about freedom, as we deprive others who cannot
> afford them/fight for them in the same way we can do.
> >
>
> "Consume more resources" is a bit vague. Environmental impact is
> correlated with performance-per-watt measurements. That improves with
> the newer generation of lithography, better support of newer and more
> efficient instruction sets, ability to dynamically clock-down cpu
> cores etc...

That would be true when running software on old hardware. That is why at work I prefer them running as i386 guests on current hardware, both kvm mode and as LXC guests. Hardware is standard rack-based servers (generation 2016?).

As mentioned by others, RAM power consumption is one major source of energy consumption for low TDP-devices (modern boards like Intel-NUC- low-TDP or embedded i386-processors, mostly for PoS-applications, IoT). For private use on those devices, I only install that amount of RAM, that is really required. For company RAM optimization costs in relation to environmental savings would be far too low for considering adding/removing of RAM.

Best regards,
Roman
--
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: Proposal: Let's drop i386

Jack Howarth
In reply to this post by Bryan Quigley-2
I am not sure of the status of the following issue as I no longer have access to hardware to test the issue against current ubuntu.


however supporting mixed-mode systems, 64-bit system with 32-bit UEFI, like Debian Jessie 8.0's  multi-arch installer (debian-8.6.0-amd64-i386-netinst.iso) would increase the pool of machines that can be migrated to the x86_64 by supporting those can can run a x86_64 kernel but need mixed-mode support to help with their 32-EFI.


On Wed, May 9, 2018 at 4:07 PM, Bryan Quigley <[hidden email]> wrote:
Hello,

Less and less non-amd64-compatible i386 hardware is available for consumers to buy today from anything but computer part recycling centers. The last of these machines were manufactured over a decade ago, and support from an increasing number of upstream projects has ended.

Ubuntu and flavors just completed the 18.04 release cycle. This released version will either be supported until 2021 or 2023, depending on the product, team, and willingness to support it. At that point in time, the majority of these machines are approaching two decades old.

>>Previous 2016 thread: And in 2018, the question will come if we can effectively provide security support on i386.
We can't.  Machines running i386 Ubuntu which are capable of running amd64 Ubuntu are vulnerable to the critical Meltdown vulnerability where they wouldn't be if they were running amd64. (Some actual i386 hardware simply isn't vulnerable, but some is).

We still have a relatively high number if i386 downloads but that doesn't mean users machines are not capable of amd64. For the flavors remaining today on i386 here are some i386 to amd64 ratios for 18.04:

Lubuntu cdimage - 0.87 
Lubuntu tracker - 0.64
Lubuntu error (pcmanfm) - 0.11
Xubuntu cdimage - 0.49
Xubuntu tracker 0.30
Xubuntu error (thunar) - 0.10
Kylin tracker - 0.30
Kylin error (engrampa) - 0.10 
Kubuntu cdimage - 0.14
Kubuntu tracker - 0.12
Kubuntu error (kinit) - 0.07

The data retrieved from cdimage is for a limited time period on May 7th. All cdimage statistics included many hundreds to thousands of downloads (except Ubuntu Kylin due to it using it's own CDN, so not being included here). The torrent tracker results are available here: http://torrent.ubuntu.com:6969/
The error tracker statistics come from comparing top bugs shared between i386 and amd64 over last week. Bugs that affect multiple flavors are not included.
It's not fully understood why there is a large discrepancy between the error tracker and other sources - but it's possible apport doesn't work as well in low memory.

With Ubuntu MATE, Ubuntu Budgie, and Ubuntu Studio joining Ubuntu Desktop and Server in not offering i386 support in order to focus their efforts, and these statistics in mind, we (flavors) should all join them. Now is the ideal time to do so, because it's before the Cosmic cycle is really under way, and if support were continued for i386, we don't want users to meet a dead end with respect to upgrade paths, and would support it until 20.04 (which means either five or seven more years of i386). Users still have the support cycle of 18.04 to use their machines and get full support, so these machines will still be able to function. But with no new machines being manufactured, we have to deprecate support at some point.

The first step would be to all agree on dropping images/installers but we should keep the end goal of dropping the port in mind ideally soon as well.

On the list of known blockers for removing the i386 port are Steam and Wine. Solus' snapped Steam is progressing nicely and Steam deb is difficult to maintain as is [See removal bug]. That leaves coming up with a good way forward for Wine.

Thanks!
Simon Quigley
Bryan Quigley

[2016 email thread] https://lists.ubuntu.com/archives/ubuntu-devel/2016-June/039420.html  (was Installation Media and supportability of i386 in 18.04 LTS Re: Ubuntu Desktop on i386)
[removal bug] https://pad.lv/1759715 



--
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: Proposal: Let's drop i386

Nafallo Bjälevik-3
In reply to this post by Jeremy Bicha-2
  Hi,

On 10/05/18 23:13, Jeremy Bicha wrote:
<snip>
> And maybe dropping armhf completely should be a third thread since
> that hopefully will be easier than i386.

I won't speak for or against i386, since I don't use it, but for armhf.

There's still a lot of new boards coming out which are still armhf
hardware, with manufacturers pledging to keep shipping boards at least
until 2020. Hardkernel's Samsung-based boards would be a perfect example.

It would be a shame to buy one of these boards in 2020 and not be able
to run Ubuntu on them, so I'd propose to keep armhf around until at
least the next LTS and look at how things are stacking up for 20.10.

Cheers,
Nafallo

--
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: Proposal: Let's drop i386

Oliver Grawert
hi,
Am Montag, den 14.05.2018, 17:49 +0200 schrieb Nafallo Bjälevik:


>
> There's still a lot of new boards coming out which are still armhf 
> hardware, with manufacturers pledging to keep shipping boards at
> least 
> until 2020. Hardkernel's Samsung-based boards would be a perfect
> example.
>
> It would be a shame to buy one of these boards in 2020 and not be
> able 
> to run Ubuntu on them, so I'd propose to keep armhf around until at 
> least the next LTS and look at how things are stacking up for 20.10.
not only that, an arm64 binary allocates nearly twice the ram at
runtime. while boards like the pi3 are actually capable of running
arm64 it is rather pointless with only 1GB RAM if you want to actually
run some applications (an Ubuntu Core pi2 armhf image shows 40MB RAM in
use when idling right after first boot via htop. the identical arm64
image on a dragonboard occupies above 90MB)

from an embedded POV i think dropping armhf would be a pre-mature step
...

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: Proposal: Let's drop i386

Steve Langasek-6
In reply to this post by Bugzilla from gruemaster@gmail.com
Hi Tobin,

On Sat, May 12, 2018 at 09:40:06AM -0700, Tobin Davis wrote:

> I've been following this thread for a while, and have some questions.  Are
> we talking about dropping Ubuntu x86 images or i386 packages from the
> repo?  If the former, I don't see an issue here, as the subs (Lubuntu,
> core, etc) can still build release images.  But if Ubuntu is dropping i386
> packages, that brings up a huge issue with software compatibility, at a
> very bad time (at least for me and the projects I support).  I work with
> FPGA accelerators, both at Intel and for a startup.  A majority of the
> tools we use (Quartus, Modelsim in particular) only support 32bit (and very
> old at that).  The companies developing these tools are all too happy to
> ONLY support Redhat Enterprise 6 (and barely RHEL 7), and so far refuse to
> budge.  A wide variety of our customer base prefer Ubuntu and have their
> infrastructure geared towards this, so I have had to be very creative in
> getting everything working for them (adding 32bit support, swapping out the
> linker that ships with these tools, etc). If Ubuntu drops i386 all
> together, this can have a major impact on the whole FPGAaaS model.

> Outside of that, I also have a large collection of older software (games
> mainly) that are still fun, but also 32bit only.  Dropping i386 would
> render them entirely useless, or force people away from Ubuntu.

Compatibility with legacy software is important, but it doesn't
automatically follow that the right way to provide this compatibility is by
continuing to build new versions of the OS for a legacy ABI.

- Users who need support for i386 integrated natively into their OS can use
  Ubuntu 18.04 with security support until April 2023.
- 18.04 can be run in a chroot or container on top of later Ubuntu releases
  until 2023 with security support from Canonical, or beyond that without.
- 32-bit software distributed as snaps built with an 18.04-derived library
  runtime can reasonably[1] be expected to work on later releases of Ubuntu
  for the foreseeable future
- Once we're past the point where security support is available for the
  libraries anyway, maybe there's no advantage anymore to having your 32-bit
  compat libraries managed via the packaging system either; so maybe you
  just make /lib/i386-linux-gnu a straight unpacked tarball of the libs you
  need, and no longer have to worry about the version-lockstep constraints
  of multiarch.

So while the use cases you mention should be taken into consideration, I
don't believe they support the conclusion that we should continue to release
Ubuntu on i386 in future releases.

> The real issue is the costs of maintainership.

Indeed, and this is a cost largely paid by Canonical (both in terms of
infrastructure, and in terms of engineering work to keep the base system
working).  It's not very compelling to say that Canonical should continue
bearing these costs out of pocket on the grounds that some other companies
are unwilling to update their software to an ISA from this millennium :)

--
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                                   https://www.debian.org/
[hidden email]                                     [hidden email]

[1] If this becomes a recommended solution, of course, we should work with
the Snappy team to ensure it remains supported

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

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

Re: Proposal: Let's drop i386

Walter Lapchynski
On 2018-05-14 12:38, Steve Langasek wrote:
> this is a cost largely paid by Canonical (both in terms of
> infrastructure, and in terms of engineering work to keep the base system
> working).  It's not very compelling to say that Canonical should continue
> bearing these costs out of pocket

There's been a lot of talk amongst the flavors of dropping i386, but I
think rather than making it a flavor decision, it would be a lot simpler
if Canonical would just put their foot down and say they won't be
providing the infrastructure and engineering for i386 images. Then if
flavors want to continue doing it, they'll have to deal with those
resources on their own. It seems to me the vast majority of flavors are
interested in dropping it and have already. That said, why not just make
the decision for the rest of the folks hanging on to it?

--
       @wxl | polka.bike
C563 CAC5 8BE1 2F22 A49D
68F6 8B57 A48B C4F2 051A

--
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: Proposal: Let's drop i386

Henri Sivonen
In reply to this post by Henri Sivonen
On Sun, May 13, 2018 at 9:48 PM, Henri Sivonen <[hidden email]> wrote:

> On Sun, May 13, 2018 at 9:34 PM, Matthias Klose <[hidden email]> wrote:
>> On 13.05.2018 05:00, Henri Sivonen wrote:
>>> On Thu, May 10, 2018 at 11:25 PM, Thomas Ward <[hidden email]> wrote:
>>>> However, killing i386 support globally could introduce issues, including
>>>> but not limited to certain upstream softwares having to go away
>>>> entirely, due to the interdependency or issues with how certain apps
>>>> work (read; Wine, 32-bit support, 64-bit support being flaky, and
>>>> Windows apps being general pains in that they work on 32bit but not
>>>> always on 64-bit).
>>>
>>> If 32-bit x86 support becomes mainly a thing that's run on x86_64
>>> hardware as a compatibility measure for things like Wine, it would
>>> make sense to bring the instruction set baseline to the x86_64 level.
>>> Specifically, it would make sense to compile the 32-bit x86 packages
>>> with SSE2 unconditionally enabled.
>>>
>>> This would mean dropping support for Pentium Pro and earlier or Athlon
>>> XP and earlier, but it's pretty sad to leave all that performance on
>>> the table in order to support the few computers still in use that have
>>> Pentium Pro or earlier or Athlon XP or earlier.
>>>
>>> As upstream software assumes SSE2 as the baseline, it will be less and
>>> less a run-time check and compiling software without SSE2 will mean
>>> shipping it in a damaged form performance-wise.
>>
>> I disagree, until you provide data how many packages fail to build, at least in
>> the testsuites, when run without the extra x87 precision bits.
>
> I don't have this data, but considering that SSE2 is a mandatory part
> of x86_64, it seems implausible that packages would be
> SSE2-intolerant. Considering that x86_64 defaults to SSE2
> floating-point math (or does Ubuntu override this?) and considering
> that ARM doesn't have x87 available, it seems implausible that
> packages would rely on x87. (On the contrary, since e.g. Firefox and
> Chromium upstreams don't do non-SSE2 x86 builds anymore, it seems more
> plausible that there exist packages whose upstream doesn't test x87
> floating-point math anymore.)

As a datapoint, Fedora is pursuing compiling 32-bit x86 packages with
SSE2 unconditionally enabled (including SSE floating-point math):
https://fedoraproject.org/wiki/Changes/Update_i686_architectural_baseline_to_include_SSE2

--
Henri Sivonen
[hidden email]
https://hsivonen.fi/

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

Follow-up: decision timeline for whether to include i386 in 20.04 [Was Re: Proposal: Let's drop i386]

Steve Langasek-6
In reply to this post by Walter Lapchynski
Hello,

A belated follow-up to this discussion.

On Tue, May 15, 2018 at 02:43:57PM -0700, Walter Lapchynski wrote:
> On 2018-05-14 12:38, Steve Langasek wrote:
> > this is a cost largely paid by Canonical (both in terms of
> > infrastructure, and in terms of engineering work to keep the base system
> > working).  It's not very compelling to say that Canonical should continue
> > bearing these costs out of pocket

> There's been a lot of talk amongst the flavors of dropping i386, but I
> think rather than making it a flavor decision, it would be a lot simpler
> if Canonical would just put their foot down and say they won't be
> providing the infrastructure and engineering for i386 images. Then if
> flavors want to continue doing it, they'll have to deal with those
> resources on their own. It seems to me the vast majority of flavors are
> interested in dropping it and have already. That said, why not just make
> the decision for the rest of the folks hanging on to it?

This is what I tried to make clear up thread at the time: there is no need
for a unanimous decision among flavors about whether to drop i386 images,
/so long as/ i386 is a supported architecture in the archive for the devel
release.  The real question is whether i386 is still supportable (and
justifiable) as a release architecture at all in the 20.04 timeframe.

There are significant technical concerns raised about whether we can
continue to provide the expected security support for i386 over the lifetime
of Ubuntu 20.04.  Certainly, we know that running a 32-bit i386 kernel on
recent 64-bit Intel chips makes for a weaker security story today than using
a 64-bit kernel; and as usage of i386 continues to decrease more broadly in
the ecosystem, we can expect it to increasingly be a challenge to keep
software in the Ubuntu archive buildable for this target.

In preparation for the possibility that we will not want to ship i386 in
20.04 LTS, automated upgrades to 18.10 were disabled on i386, enabling users
of i386 to stay on the LTS which will be supported until 2023 instead of
being islanded on a non-LTS release supported only until early 2021.

A final decision about whether to discontinue the i386 port of Ubuntu for
20.04 LTS will be made around the middle of 2019.

--
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                                   https://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 (849 bytes) Download Attachment
12