Canonical have released a statement on Ubuntu and 32bit support, will keep select packages

Quoting: chancho_zombiethere might be a time were removing 32bits would be a good decision, now it's not that time. There is still 5% of pc users that use windows xp, how many of those machines are 32bits?? 5% is a lot more than all the Linux userbase.

Thing is, almost everyone was thinking like you. But what they intended was not dropping support for 32 bit machines, but to drop ability to run 32bit software an 64bit system. Like 95% of Linux games, for example

Quoting: F.Ultra

Quoting: eldaking

Quoting: F.UltraNo I didn't say that others did such stuff all the time. What I said was that in the real world companies announce their plans, then they await comments from users and partners to see how said plans will be received after which the plans are either amended or put into production.

The problem here is that the Linux fanbase decided to see the announcement of plans as a foregone conclusion and then run around screaming.

When they "announced" this years ago, did they set a date? Was it fully decided and plotted out? How much did they broadcast their intentions so that people could prepare their transition?

Or was their announcement now still just a "plan" to be discussed, despite the fact the changes takes effect in a few months?

Everyone was surprised by this because information was not communicated clearly enough and in advance enough. Yeah, we are probably overstating the impact... but this a panic Canonical created.

Here is the initial announcement from last year: https://lists.ubuntu.com/archives/ubuntu-devel/2018-May/040310.html so it was just one year ago and not years as I first claimed (shame on me there).

edit: further research shows that they also made an announcement back in 2016: https://lists.ubuntu.com/archives/ubuntu-devel/2016-June/039420.html

OK, so those are not official announcements, those are discussions. In their mailing list, so they didn't communicate this to the general public. In the 2018 e-mail, which is a proposal and not a final word, they mostly talk about dropping the image, about hardware support, and that the first step should be dropping the image (which I think everyone agrees). No timeline is given to drop multilib other than "we should eventually do it", no final decision is reached (on that one e-mail at least). On the 2016 e-mail, it is actually discussed dropping the libraries and surprisingly a tentative timeline is given. It is still only a suggestion, with plenty of questions asked, and the timeline was obviously discarded (it should drop compatibility on 18.10).

So no, not communicated clearly and in advance.

Quoting: F.UltraThis whole fiasco is a fiasco of the Linux fanbase, nothing more.

As I said in a previous comment, I think an acceptable resolution (i.e. delay) has been reached, but the matter was not initially well-handled by Ubuntu devs.

Quoting: F.UltraClose to two years ago they announced that they planned to drop 32-bit (IA-32) support and since no one back then voiced any concern they moved forward to the decision they now made for 19.10.

A couple of times during that email chain, it was indicated that the current discussion was only about discontinuing the 32-bit installation images, and that ceasing updates of 32-bit package builds altogether would take place in a separate discussion. The question about what exactly was being discussed was brought up several times, and some people were obviously unclear about it. Some people also voiced concern.

E.g.
1) ["On the #ubuntu-release IRC channel, it became clear that the purpose of this thread was not entirely clear, so we need to clarify specifically:

Are we discussing dropping support for i386 *installation images*, or are we talking about dropping i386 altogether, including in the repositories in general?

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

So with the scope of this email chain, I would like to request a clarification before we go forward much more with this email chain: Are we discussing dropping 32-bit for *installer images* this cycle, or are we talking about the complete global death of i386 as a supported architecture?"](https://lists.ubuntu.com/archives/ubuntu-devel/2018-May/040315.html)

Reply:
"Let's make it simple and reserve this thread for discussion about dropping 32-bit installer images now.

Someone else is welcome to start a separate thread to discuss the more controversial and complex topic of dropping i386 completely."

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

Reply:
"I was hoping that the question about 32-bit packages would be split off into a separate thread."

Quoting: F.Ultra...they announced yet again that it would be done. Then they again waited for comments which this time came in droves and after that they changed their mind.

This is how things are done and decided in the real world all the time, the only difference now is that the immature Linux fanbase for some reason decided to run around in circles screaming that the world was ending.

The problem was this announcement wasn't presented as the start of a discussion, it was presented as a matter of fact.

"The Ubuntu engineering team has reviewed the facts before us and concluded that we should not continue to carry i386 forward as an architecture. Consequently, i386 will not be included as an architecture for the 19.10 release, and we will shortly begin the process of disabling it for the eoan series across Ubuntu infrastructure."

That there was mostly consensus among stakeholders was supposition on the part of Ubuntu devs. Hence why Ubuntu's new statement says "we felt we had sufficient consensus", which people in an echo chamber often do feel.

Another example of the disconnect is the Q&A they released.

Q. Doesn’t Steam use 32 bit libraries? How can I play my games?

Steam itself bundles a runtime containing necessary 32-bit libraries required to run the Steam client. In addition each game installed via Steam may ship 32-bit libraries they require.

Pierre-Loup A. Griffais:
"Steam and thousands of its games rely on a 32-bit glibc from the host system, as well as OpenGL and Vulkan userland graphics driver libraries for Mesa and the NVIDIA driver. Steam as it currently exists will be broken on 19.10..."

Q. How can I run 32-bit Windows applications if 32-bit WINE isn’t available in the archive?

Try 64-bit WINE first. Many applications will “just work”. If not use similar strategies as for 32 bit games. That is use an 18.04 LTS based Virtual Machine or LXD container that has full access to multiarch 32-bit WINE and related libraries.

Rosanne DiMesio:
"And when they're handing out advice like 'Try 64-bit WINE first. Many applications will “just work”,' I'd say the people making this decision seem to know less about Wine than a typical Ubuntu user."

"Unfortunately, based on what the Ubuntu article says, I don't have any confidence that they even understand what Wine needs, let alone plan to provide it."

Andrew Eikum:
"Yes, I agree. From the FAQ it doesn't seem like they understand Wine's needs."

Jens Reyer:
"Wine heavily relies on i386. Not only for legacy 32-bit software, but also 'almost all' 64-bit software uses a 32-bit installer. 'It’s practically impossible to implement 32-bit on top of 64-bit', so that you wouldn’t need i386 at all.. So although Wine will still be available in the Ubuntu archive on amd64, it’ll be basically useless.

To support current features in new Wine releases you need recent versions of a few libraries (e.g. faudio, vulkan-loader and vkd3d, and those require other recent stuff like sdl2, …). If you use our Debian packages also current versions of unicode-data and khronos-api. 18.04 is already too old to fully support current Wine with (all) current features. So the solutions proposed . . . like containers and snaps based on 18.04 will not fully work. I’m not sure how well Wine (which uses the same libraries from amd64 AND i386) would work with a static /lib/i386-linux-gnu."


Last edited by vector on 24 June 2019 at 11:23 pm UTC

Quoting: Gryxx

Quoting: F.Ultra

Quoting: eldaking

Quoting: F.UltraNo I didn't say that others did such stuff all the time. What I said was that in the real world companies announce their plans, then they await comments from users and partners to see how said plans will be received after which the plans are either amended or put into production.

The problem here is that the Linux fanbase decided to see the announcement of plans as a foregone conclusion and then run around screaming.

When they "announced" this years ago, did they set a date? Was it fully decided and plotted out? How much did they broadcast their intentions so that people could prepare their transition?

Or was their announcement now still just a "plan" to be discussed, despite the fact the changes takes effect in a few months?

Everyone was surprised by this because information was not communicated clearly enough and in advance enough. Yeah, we are probably overstating the impact... but this a panic Canonical created.

Here is the initial announcement from last year: https://lists.ubuntu.com/archives/ubuntu-devel/2018-May/040310.html so it was just one year ago and not years as I first claimed (shame on me there).

edit: further research shows that they also made an announcement back in 2016: https://lists.ubuntu.com/archives/ubuntu-devel/2016-June/039420.html

Basically, they said in 2016: "What do you think is appropriate?"
In 2018 as i understand they talk about dropping i386 images- not whole legacy 32 bit support, at least in your linked post
In 2019 we get: BANG!, you have 4 months to prepare your software/game/library for 64-bit only Ubuntu. You need 32 bit? Stay on older system until it runs out of support.
There was never a plan to migrate software. There was discussion about dropping, but until recently we had no timelines or guides how to prepare. That's not fair.

Here is a quote from the 2016 post:

Quote18.10+:
* Stop providing i386 port
* Run legacy i386 only application in snaps / containers / virtual machines

And that is exactly what they proposed to do in the now famous 19.10 announcement. And while I agree that 4 months is a very small time frame, it's quite obvious that they consider non LTS versions to be mere testbeds and that people would remain on 18.04 for quite some time:

QuoteQ. I have 32bit 16.04 LTS / 18.04 LTS installed, what are my upgrade options?

18.04 LTS has Standard Security support until 2023. Extended Security Maintenance runs for a further 5 years until 2028. You can stick with your current installed version until then and still be safe and secure.

This should give plenty of time to migrate away from 32-bit legacy applications before the next LTS which will be available in April 2020, or the following LTS in 2022. Alternatively place the legacy application inside an 18.04 LTS i386 container, on top of a newer 64-bit installation of Ubuntu.

I think a major problem here is that many people never read that far or just thought that, well let's worry about that in 2018 and then forgot about it. This whole rally that happened now should have happened back in 2016, perhaps then we could have avoided all the name calling.

Quoting: F.Ultra

Quoting: x_wing

Quoting: F.Ultra

Quoting: TobiSGD

Quoting: GuestI can see why they want to remove 32 bit libs because it's a ton of work.

But a ton of work for whom? They still get the majority of their packages directly from Debian, throwing a patch on one or the other package and just compile. If Debian still supports newer versions of 32 bit libraries, how much work is there really to be done for canonical?

They get the base source code of each package from Debian, then they have to build the IA-32 version themselves, and provide support themselves. Considering the amount of packages in the repo it will take quite some time to build the packages for IA-32 and that is time taken from building for other archs and so on. If there where no cost for providing IA-32 builds then they clearly wouldn't have planned to throw them out to begin with.

The only real cost is QA. Building is normally cheap.

Currently Ubuntu have 6391 packages in Main, building that will take hours even for Canonical.

Seriously, do you people really think that Canonical decided to drop IA-32 for some other reason and then have their devs lie that it had to do with resources? What is next, UFO conspiracies, 9/11 Truthers, Freemasons, anti-vaxxers and anti-GMO fools?

Never said such thing. But if you have the build pipeline for amd64, adding the i386 is trivial, not to mention that server processing time is quite cheap. Also, they already had the idea to keep supporting some essential 32 bit libraries as packages in the amd64 arch. So, the building scripts would still be there.

The discussion here is more about on what users need and not if "i386 is legacy and we should user resources in something else". When you have a lot of people that uses application that requires 32 bit libraries, you can't just drop support when you still doesn't have a working solution for that group.

Quoting: eldaking

Quoting: F.Ultra

Quoting: eldaking

Quoting: F.UltraNo I didn't say that others did such stuff all the time. What I said was that in the real world companies announce their plans, then they await comments from users and partners to see how said plans will be received after which the plans are either amended or put into production.

The problem here is that the Linux fanbase decided to see the announcement of plans as a foregone conclusion and then run around screaming.

When they "announced" this years ago, did they set a date? Was it fully decided and plotted out? How much did they broadcast their intentions so that people could prepare their transition?

Or was their announcement now still just a "plan" to be discussed, despite the fact the changes takes effect in a few months?

Everyone was surprised by this because information was not communicated clearly enough and in advance enough. Yeah, we are probably overstating the impact... but this a panic Canonical created.

Here is the initial announcement from last year: https://lists.ubuntu.com/archives/ubuntu-devel/2018-May/040310.html so it was just one year ago and not years as I first claimed (shame on me there).

edit: further research shows that they also made an announcement back in 2016: https://lists.ubuntu.com/archives/ubuntu-devel/2016-June/039420.html

OK, so those are not official announcements, those are discussions. In their mailing list, so they didn't communicate this to the general public. In the 2018 e-mail, which is a proposal and not a final word, they mostly talk about dropping the image, about hardware support, and that the first step should be dropping the image (which I think everyone agrees). No timeline is given to drop multilib other than "we should eventually do it", no final decision is reached (on that one e-mail at least). On the 2016 e-mail, it is actually discussed dropping the libraries and surprisingly a tentative timeline is given. It is still only a suggestion, with plenty of questions asked, and the timeline was obviously discarded (it should drop compatibility on 18.10).

So no, not communicated clearly and in advance.

That mailinglist is how they communicate changes, and that is also where the recent post for 19.10 was picked up.

Quoting: F.Ultra

Quoting: Gryxx

Quoting: F.Ultra

Quoting: eldaking

Quoting: F.UltraNo I didn't say that others did such stuff all the time. What I said was that in the real world companies announce their plans, then they await comments from users and partners to see how said plans will be received after which the plans are either amended or put into production.

The problem here is that the Linux fanbase decided to see the announcement of plans as a foregone conclusion and then run around screaming.

When they "announced" this years ago, did they set a date? Was it fully decided and plotted out? How much did they broadcast their intentions so that people could prepare their transition?

Or was their announcement now still just a "plan" to be discussed, despite the fact the changes takes effect in a few months?

Everyone was surprised by this because information was not communicated clearly enough and in advance enough. Yeah, we are probably overstating the impact... but this a panic Canonical created.

Here is the initial announcement from last year: https://lists.ubuntu.com/archives/ubuntu-devel/2018-May/040310.html so it was just one year ago and not years as I first claimed (shame on me there).

edit: further research shows that they also made an announcement back in 2016: https://lists.ubuntu.com/archives/ubuntu-devel/2016-June/039420.html

Basically, they said in 2016: "What do you think is appropriate?"
In 2018 as i understand they talk about dropping i386 images- not whole legacy 32 bit support, at least in your linked post
In 2019 we get: BANG!, you have 4 months to prepare your software/game/library for 64-bit only Ubuntu. You need 32 bit? Stay on older system until it runs out of support.
There was never a plan to migrate software. There was discussion about dropping, but until recently we had no timelines or guides how to prepare. That's not fair.

Here is a quote from the 2016 post:

Quote18.10+:
* Stop providing i386 port
* Run legacy i386 only application in snaps / containers / virtual machines

And that is exactly what they proposed to do in the now famous 19.10 announcement. And while I agree that 4 months is a very small time frame, it's quite obvious that they consider non LTS versions to be mere testbeds and that people would remain on 18.04 for quite some time:

QuoteQ. I have 32bit 16.04 LTS / 18.04 LTS installed, what are my upgrade options?

18.04 LTS has Standard Security support until 2023. Extended Security Maintenance runs for a further 5 years until 2028. You can stick with your current installed version until then and still be safe and secure.

This should give plenty of time to migrate away from 32-bit legacy applications before the next LTS which will be available in April 2020, or the following LTS in 2022. Alternatively place the legacy application inside an 18.04 LTS i386 container, on top of a newer 64-bit installation of Ubuntu.

I think a major problem here is that many people never read that far or just thought that, well let's worry about that in 2018 and then forgot about it. This whole rally that happened now should have happened back in 2016, perhaps then we could have avoided all the name calling.

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

That's not announcment. That's question. And,, beeng quite rude- Why the fuck i need to stay with old distro, that does not support recent hardware? What can i do if i want to play Steam on my Ryzen 7 3500x an RX 5000?

Quoting: Mohandevir

Quoting: F.Ultra

Quoting: EikeWell, actually "immature" and "world was ending" were part of your statement, too.

I take it that you don't frequent Phoronix and Slashdot much. If so then don't let the curiosity get the better of you, it's not pretty.

I see it as a clash between two diverging factions: From a dev ops (it's larger than that) perspective, 32 bit support is useless and doesn't need to be maintained anymore... On the other side gamers are left with a crippled gaming library. For them, it's just unacceptable.

I think that we all agree that 32bit support has to go, but not yet. The "tooling" required is non existent or not performant enough, from what I understand. The call seems premature.

Am I wrong to think so?

It's not "gamers who are left with a crippled gaming library" that complain about the 32-bit deprecation, Linux doesn't even have that many gamers among its users to begin with; it's people who simply desire a future where Linux is a major player in the desktop OS market, and who realize that the only way to make this possible future into a reality is to make Linux a viable gaming platform, because like it or not, gaming is the #1 reason that Windows is still the #1 OS nowadays.

Canonical being a desktop focused Linux company should have known this better than anyone, so if they really had Linux's best interests at heart, and also if their own interests were really aligned with those of Linux, they should have been best pals with Valve and fighting tooth and nail to realize this dream of making Linux a viable gaming platform, because that would also serve to promote their own interests and increase their market share as Linux's foremost desktop distro. The fact that not only are they not best pals with Valve, but that they also either actively or at least out of ignorance and/or indifference seek to harm Linux's interests by removing 32-bit support and thus break the future of gaming and thus the future of the whole platform in the process, reeks of terrible incompetence - and that's the best case scenario (imho the strange timing of the announcement without any serious warning, along with their weak and not really thought-out arguments against 32-bit support, are more than a bit worrying when one considers their relationship with Microsoft, which of course has every reason not to want Linux to ever become a viable gaming platform).

So, no, 32-bit support does not have to go, at least not until Microsoft itself decides to deprecate it and remove it from Windows; as long as Windows still supports it, which means that vendors still support it, then Linux should also support it, unless the Linux community manages before that time comes to develop a good way to run 32-bit binaries in a pure 64-bit environment with a negligent performance hit. If and when that happens then, by all means, be my guest and deprecate the hell out of it. But not one second sooner.

Quoting: F.UltraHere is the initial announcement from last year: https://lists.ubuntu.com/archives/ubuntu-devel/2018-May/040310.html so it was just one year ago and not years as I first claimed (shame on me there).

edit: further research shows that they also made an announcement back in 2016: https://lists.ubuntu.com/archives/ubuntu-devel/2016-June/039420.html

Neither of those were announcements, they were proposals/discussions.

The 2016 thread proposed sunsetting support of 32bit ubuntu installs ("host/base OS architecture") in 2021, and sunsetting legacy i386 applications (chrome was specifically mentioned; these are the main software applications that are for use on 32bit installs that are not used on 64bit installs) in 2023.

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

From the 2018 proposal (which, in addition to the aforementioned host architecture and included 32bit apps, also looks to sunset *all* i386 software libraries), it listed 2 main blockers (Steam and Wine), the latter of which they had no idea what they were going to do about, and never actually came up with a plan for before deciding to go forward with dropping the i386 libraries. For steam, they basically just assumed everyone would be fine using a Snap:

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

There was no formal announcement of exactly what changes would be made until recently, and even then it was confusing, since the wording didn't distinguish between hardware support, application support, and system library/driver support.


Last edited by lectrode on 24 June 2019 at 10:48 pm UTC

Quoting: Gryxx

Quoting: F.Ultra

Quoting: Gryxx

Quoting: F.Ultra

Quoting: eldaking

Quoting: F.UltraNo I didn't say that others did such stuff all the time. What I said was that in the real world companies announce their plans, then they await comments from users and partners to see how said plans will be received after which the plans are either amended or put into production.

The problem here is that the Linux fanbase decided to see the announcement of plans as a foregone conclusion and then run around screaming.

When they "announced" this years ago, did they set a date? Was it fully decided and plotted out? How much did they broadcast their intentions so that people could prepare their transition?

Or was their announcement now still just a "plan" to be discussed, despite the fact the changes takes effect in a few months?

Everyone was surprised by this because information was not communicated clearly enough and in advance enough. Yeah, we are probably overstating the impact... but this a panic Canonical created.

Here is the initial announcement from last year: https://lists.ubuntu.com/archives/ubuntu-devel/2018-May/040310.html so it was just one year ago and not years as I first claimed (shame on me there).

edit: further research shows that they also made an announcement back in 2016: https://lists.ubuntu.com/archives/ubuntu-devel/2016-June/039420.html

Basically, they said in 2016: "What do you think is appropriate?"
In 2018 as i understand they talk about dropping i386 images- not whole legacy 32 bit support, at least in your linked post
In 2019 we get: BANG!, you have 4 months to prepare your software/game/library for 64-bit only Ubuntu. You need 32 bit? Stay on older system until it runs out of support.
There was never a plan to migrate software. There was discussion about dropping, but until recently we had no timelines or guides how to prepare. That's not fair.

Here is a quote from the 2016 post:

Quote18.10+:
* Stop providing i386 port
* Run legacy i386 only application in snaps / containers / virtual machines

And that is exactly what they proposed to do in the now famous 19.10 announcement. And while I agree that 4 months is a very small time frame, it's quite obvious that they consider non LTS versions to be mere testbeds and that people would remain on 18.04 for quite some time:

QuoteQ. I have 32bit 16.04 LTS / 18.04 LTS installed, what are my upgrade options?

18.04 LTS has Standard Security support until 2023. Extended Security Maintenance runs for a further 5 years until 2028. You can stick with your current installed version until then and still be safe and secure.

This should give plenty of time to migrate away from 32-bit legacy applications before the next LTS which will be available in April 2020, or the following LTS in 2022. Alternatively place the legacy application inside an 18.04 LTS i386 container, on top of a newer 64-bit installation of Ubuntu.

I think a major problem here is that many people never read that far or just thought that, well let's worry about that in 2018 and then forgot about it. This whole rally that happened now should have happened back in 2016, perhaps then we could have avoided all the name calling.

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

That's not announcment. That's question. And,, beeng quite rude- Why the fuck i need to stay with old distro, that does not support recent hardware? What can i do if i want to play Steam on my Ryzen 7 3500x an RX 5000?

It was a clear indication that they where thinking in those terms and incidentally that is exactly what they then announced would happen for 19.10, a problem here is that users, Valve and WINE didn't pick this up in 2016 while the Ubuntu devs apparently thought that they did so when no one complained they went ahead with the plans.

Ubuntu have what they call HWE which basically is when they will release a new kernel in order to support the newest hardware on older LTS systems. So your RX5000 will be supported on 18.04LTS.

Anyway we are all beating a very dead horse right now since Ubuntu have decided to continue with 32-bit support for selected packages. So if we continue this too long we will end up just like the People's Front of Judea.

https://www.youtube.com/watch?v=WboggjN_G-4