Proposal: Let's drop i386

[Colin Watson]

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

[Matthias Klose]

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.

[Henri Sivonen]

Post by Matthias Klose

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

[Lyn Perrine]

The other question is does anyone test ubuntu on non SSE2 hardware anymore?

Post by Matthias Klose

However, killing i386 support globally could introduce issues,

including

Post by Matthias Klose

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

Post by Matthias Klose
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
https://hsivonen.fi/
--
Ubuntu-devel-discuss mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/
mailman/listinfo/ubuntu-devel-discuss

[Henri Sivonen]

Post by Henri Sivonen

Post by Matthias Klose

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

[Walter Lapchynski]

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.

The primary Ubuntu flavor already stopped creating 32-bit ISOs before
18.04 LTS. At a minimum, I think this discussion is about whether
*any* official Ubuntu flavor should offer official 32-bit ISOs
starting now with 18.10.

And maybe more appropriately whether Canonical will be providing the infrastructure to build them?

we don't support cross-grading from 32-bit to 64-bit.

Indeed and it's ridiculously difficult. I tried it with multi-arch and it would simply take a lot of extra effort to convert all the packages. Changing kernels is easy but that's a small part of the problem.

But a fresh install using the existing $HOME would do the trick. Just make sure to have a `dpkg -l` to restore all the packages. Should be pretty easy, no?
--
@wxl | polka.bike
C563 CAC5 8BE1 2F22 A49D
68F6 8B57 A48B C4F2 051A

[Gizmo Chicken]

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.

[Steve Langasek]

Post by Gizmo Chicken

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.

[Gizmo Chicken]

Post by Steve Langasek

Post by Gizmo Chicken
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.

[Philipp Kern]

HDDs consume more energy than SSDs; [...]

Unless it's NVMe.

similarly newer (faster clock/dynamicly clocked, and operating at a lower
voltage / amps) RAM
consume less energy.

Didn't RAM power consumption go up with frequency and especially as now
everyone tries to get more and more RAM into their boxes, consuming more
power?

If newer platforms were not more power efficient, we would not see public
clouds / datacentres upgrading their platforms as aggressively as they do.

Well, there are other considerations as well. Floor space. The fact that
you need more compute power and hence you add machines rather than
replacing them. What you really want in these environments is
performance per watt, of course. Outside of these cloud environments
rarely anyone runs their machines that hot. In which case you care more
about idle consumption.

Given that people were talking about replacing machines with new ones
just for environment purposes, there's also something to be said about
the e-waste generated by that. If people keep their power-hungry CPUs
not continuously running but dutifully power them off if not needed, the
trade-off is probably more on the generating waste side than the "we
need to convert everyone to more efficient CPUs"[1].

Kind regards
Philipp Kern

[1] Low consumption also sometimes backfires. Low water consumption now
requires the utilities to waste more water on their side to keep the
pipes operational, also raising prices.

[Bryan Quigley]

I definitely should have included more links to previous discussions -
including this survey I did 4 years ago - https://bryanquigley.com/posts
/crazy-ideas/32-bit-usage-survey-results.html.

Is it ethical to continue to support a platform that we may not be able to
provide meaningful security support for? Ignoring meltdown for a moment,
Spectre V2 requires microcode updates to protect against it - I'm not sure
they will ever come for hardware from 2006.

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.

My laptop is from 2009 (albeit upgraded).. I like holding on to devices
myself. If we fully drop the port, every i386 user still has some level of
Ubuntu support until 2023. In any case as you go back further processors
become much less power efficient - are you sure that you aren't the one
wasting resources?

It happens that Energy Star requirements significantly increased
requirements in 2007 especially around idle power usage which is one of the
biggest wasters of power in computers generally (see
https://www.energystar.gov/index.cfm?c=archives.computer_spec_version_4_0).

Kind regards,
Bryan

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
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
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.
Those two groups could be seen apart from a third one: those, who do not
want to change for convenience (parking on the wheel-chair parking space,
because it is closer to the entrance), thus depriving others from resources
(in our case developers having to care for one platform more).
How to value all those arguments might be more something for a Ubuntu
ethics board (if existing), not just the mailing list? But first to get
more insight, add some online survey link beside each i386-download asking
users for their reasons?
LG Roman

[Bryan Quigley]

Nice catch! I just looked for error stack traces that matched between the
i386 version and amd64 and then compared them. I only removed duplicates
that we're in the flavors I was comparing - my mistake.

Xubuntu error (thunar) - 0.10 - thunar also included in Ubuntu studio

The general process was taking these two links, and finding and comparing
the same stacktrace:
https://errors.ubuntu.com/?release=Ubuntu%2018.04&packageset=xubuntu&period=
week&pkg_arch=i386
https://errors.ubuntu.com/?release=Ubuntu%2018.04&packageset=xubuntu&period=
week&pkg_arch=amd64

engrampa was a very bad choice. i386 for the Ubuntu kylin package set
doesn't seem to have enough specific bugs for another comparison:
https://errors.ubuntu.com/?release=Ubuntu%2018.04&
packageset=ubuntukylin&period=week&pkg_arch=amd64
https://errors.ubuntu.com/?release=Ubuntu%2018.04&
packageset=ubuntukylin&period=week&pkg_arch=i386

Thanks,
Bryan

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

Could you elaborate on the methodology you used to create these Error
Tracker statistics?
I'm not certain engrampa was a representative choice given that it is
also part of the xubuntu-desktop and ubuntu-mate-desktop tasks.
--
Brian Murray
--
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/
mailman/listinfo/ubuntu-devel

[Ian Bruntlett]

Hi Nrbtx et al,

Dear Bryan and all!
Please do not forget about some special hardware configurations such as
Thin Clients.
For example we use about 50 machines as Fat LTSP clients with Intel
Celeron and Intel Atom. Their RAM is limited to 2Gb by hardware. They use
Ubuntu 16.04 LTS with MATE desktop environment.
Even if CPU is 64-bit compatible, it will be impermissible luxury (or high
RAM usage in other words) of 64-bit OS. I prefer 32-bits here as it reduces
RAM usage.
Please take into account my logic about 32-bit LTSP clients. And do not
drop 32-bits completely.

As a hobby, I run a computer refurbishment project where people give me old
computers/laptops and, once they are refurbished, are given to people with
mental health problems, their families or students or other needy people.
As a result, I'm the go-to-guy for a number of old computers out in the
community. The number of 32-bit systems out there actually in active use is
pretty small.

For personal use, I have a Samsung NC10 32-bit netbook whose task these
days is to act as an easily carried computer. I have been keeping an eye
out for a similar system with the exception of having a 64-bit CPU, without
much success.

According to my information, lubuntu 18.04 will be supported for 5 years. I
should be able to find a suitable replacement system in that time.

It isn't convenient but perhaps it is time to start planning the
replacement of existing 32 bit systems? Making computer shops / businesses
aware that you'd like to have "old" (!) 64-bit systems donated to your
particular charities?

HTH,


Ian

[Fiedler Roman]

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

[Jack Howarth]

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.

https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1647184

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.

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
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).
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
Modify settings or unsubscribe at: https://lists.ubuntu.com/
mailman/listinfo/ubuntu-devel

[Nafallo Bjälevik]

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

[Oliver Grawert]

hi,

 
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

[Steve Langasek]

Hi Tobin,

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

[Walter Lapchynski]

Post by Steve Langasek
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?