I’m sorry that we’ve given anyone the impression that we are “dropping support for i386 applications”. That’s simply not the case. What we are dropping is updates to the i386 libraries, which will be frozen at the 18.04 LTS versions. But there is every intention to ensure that there is a clear story for how i386 applications (including games) can be run on versions of Ubuntu later than 19.10.
Intel 32bit packages on Ubuntu from 19.10 onwards
6 Likes
Perhaps it would have been better to at least agree in advance with Valve and Wine about how this may work. As is stands, neither will support 19.10, according to statements by senior developers. I haven’t used a 32 bit 386 machine in a long, long time. But I use Crossover and I have another computer which has Steam, both run Ubuntu. As you must surely realise (now), neither project is very useful without multiarch. I think there are quite a lot of users like me, and we are hearing that the end of our time with Ubuntu is coming fast.
8 Likes
Good to know, so at least no issues with printer/mfp drivers - honestly, this is relief. But, still, what about 32 bit Mesa?
What will happen with 32 bit only PCSX2 package at least in next release? Revert back to 1.4.0 or keeping it 1.5.0 git? Or updating it to newer git snapshot which is actually necessary to fix some regressions introduced by current git snapshot?
What’s gonna happen once 18.04 is dead? Or there’s a newer version of those libraries?
And besides, most Ubuntu users want simple instructions on how to do it because, while some of us would be willing to go to the terminal and set up containers, most won’t want to go through all that hassle.
You might as well include Pop!_OS’s repo on Ubuntu if you want it to continue being recommended to everyone.
32-bit mesa will be available in the Ubuntu 18.04 repository. Note that mesa already gets updates in 18.04 which track the versions from later Ubuntu releases, as part of hardware enablement. If incompatibilities are introduced beyond 20.04 (which is the cutoff for hardware enablement backports for 18.04), we will need to address them on a case-by-case basis.
PCSX2, as the plan stands today, would be available only in the 18.04 repository - so would be available at version 1.4.0. i386-only application packages currently distributed in Ubuntu are strong candidates for being converted to snaps. It looks like there’s been at least one effort already to package PCSX2 as a snap (pcsx2-tabetai).
Can you clarify why you’re interested to know about newer versions of libraries? Because i386 would be treated as “legacy”, it would not get newer library versions. But since the vast majority of i386-only software is also legacy (closed-source, will never be rebuilt), it also does not generally benefit from newer libraries. Do you have something specific in mind?
2 Likes
The most significant collection of affected printer drivers that we’re aware of are those for Brother printers. We’re exploring a number of options regarding how we can support those. If you’re aware of drivers other than Brother that are in this situation, please let us know what they are so we can assess those as well.
We can and should make the 32-bit nvidia drivers available as part of the amd64 packages. These would then be exposed into the 32-bit containers, ensuring that the 32-bit userspace libraries matched the version of the kernel driver, regardless of what other library versions were available as packages within the container.
I am not a native English speaker so maybe I missed something but I got the impression that i386 was going to be dropped completely (save for containers and workarounds). Good if it’s not going to be this dramatic.
I’ve read a lot of comments on this and I got a feeling the real issue is not about i386 support but that with this decision (and apparently without involving Valve or Wine developers) Ubuntu is no longer a reliable desktop solutions for those who want to focus on desktop users. One cannot work for the environment where things can break at any time (or not work at all). I hope engineers at Canonical can take this into account at this point and in the future.
It also seems this was an exercise in how not to communicate future plans again without involving other important developers.
Btw, I am very grateful to everyone at Canonical. I would have never become a linux user if there was no Ubuntu and I think the linux userland would be much smaller and poorer without your input.
1 Like
Mainly graphics, like Vulkan, NVIDIA, Mesa
And everything that Wine & Steam needs for 32-bit support
Using 18.04 in a container as a base seems to be only a band-aid solution in a massive hole that was created. I was skimming through Wine’s mailing list, and it seems that while you are working with Valve on making sure none of our games from Steam break, they stopped recommending and supporting Ubuntu.
And we need those 32-bit libraries for legacy applications and games.
Say we run Steam and Wine in a container, and we purchased a new, unreleased as of now, Radeon GPU that most likely won’t be supported in 18.04’s kernel, like Radeon RX 5700. IIRC, even the latest AMD GPUs, like Radeon VII, don’t even work well with 18.04. What happens then? Would we still be able to run our games and applications there? What happens when 18.04’s support ends?
I was also reading the Ubuntu Developer mailing list, and it seems that this will negatively affect flavors, like Ubuntu Studio.
5 Likes
For me personally this all seems way to much, much to soon.
I totally understand why the Ubuntu team wants to implement this change and i support them in their vision, it is totally unnessesary to be maintaining a large 32-bit repo if most software is also available in the 64-bit repo. We do not need a 32-bit vim if you can also use a 64-Bit vim.
However as we have seen many people still depend on 32-bit support, which is why i suggest keeping a 32-bit repository with the new requirement that before a package is accepted it has to be documented why this package is required on a 64-bit system. This way we can keep the essential packages / programs that have buggy or inferior 64-bit packages while simultaniously keeping the repo’s at a much smaller more maintainable size.
4 Likes
I agree with this suggestion. There are a lot of packages in the repo that don’t need a 32-bit version, like VLC, Vim, Plasma, etc. Those can be removed since Ubuntu doesn’t have i386 distros anymore.
Remove the unnecessary packages and leave the ones a lot of us need behind. That way, you won’t have to maintain too many i386 packages.
1 Like
The Faq and some replies lack some crucial details.
Where does the 1% user base come from? Is this 32bit installs or does this track 64bit installs that install 32bit libraries?
If I as a user try to install a package that depends on a 32bit library what happens? Does it just fail outright? Does it offer the workaround if enabling the 18.04 repo for 32bit libraries? How does this change get communicated to the end user?
How does this change affect Bug #1? This appears on the surface to be a significant regression in regards to bug #1.
I understand dropping 32 bit only images from the distribution, but cannot fathom a really good reason to drop the common multiarch support that defines linux distributions in general.
4 Likes
As I understand it, the original proposal was to stop doing i386 releases. There’s an argument for that, even though it leaves >1% of your userbase in the lurch.
However, as someone else says…
… is two very different things and that this was what was being proposed was not made at all clear at the start of the process we’re apparently now at the end of.
Users: who needs 'em, eh?
3 Likes
It is taken from the 98.something% of installs of 18.04 LTS using the amd64 version, I suspect.
So… not people using libraries that are going to be killed off.
Or any of the light distros that are based on Ubuntu.
Vorlon, has the Ubuntu team considered just showing warnings when running 32-bit applications before discontinuing support, similarly to what Apple is doing?
This would serve as a transition period, giving a strong incentive for developers to update their apps, and informing users about legacy apps that may not work in the future.
1 Like
How do you intend to resolve the version mismatching issue with dpkg and apt? They both require that the i386 and amd64 versions of packages have the same version number, do they not?
How do you ensure that device driver vendors (namely, nVidia) play nice?
3 Likes
There should be a tool to handle this as automagically as possible.
I don’t understand why are you supposing that the burden to setup lxd would be on users, instead of tools that would do it automagically…
Yes it was a guy that doesn’t maintain distros.
2 Likes
I think you are really causing big problems with your approach. Finally, there must be a solution that “just works” for everything that works now.
If you have not enough ressources, for maintaining Ubuntu with Multiarch, please consider the following ideas:
1. Team up with the dev from the unofficial flavors and do the work together! Some of them mentioned, they want to provide multiarch.
Shouldn’t be that hard, to help each other instead of harming your userbase and the whole Linux Ecosystem.
2. Start a crowdfunding for that and pay devs to do the work, by the money funded
3. Initiate an “Full 32 Bit support” project with volunteers to get help.
In the future you should really do a much better communication work. It does simple not work, to discuss things in forums or mailinglists, to get the attention that is needed for such a big thing.
6 Likes
I’m sorry that we’ve given anyone the impression that we are “dropping support for i386 applications”. That’s simply not the case. What we are dropping is updates to the i386 libraries, which will be frozen at the 18.04 LTS versions. But there is every intention to ensure that there is a clear story for how i386 applications (including games) can be run on versions of Ubuntu later than 19.10.
There’s four main problems with this.
First off, there is a pretty decent chunk of Ubuntu’s user base that will never use a snap ever. I know of quite a few users who instantly run sudo apt remove --autoremove --purge snapd and then sudo apt-mark hold snapd so that it is removed and never installed again on their installs. These users very much value the testing that Canonical puts into packages in the apt repos and do not want packages that are tested by no one and created by anyone. It is not an acceptable solution for them to be forced to use snaps for 32bit applications.
Secondly, Canonical seems to have failed to mention this anywhere before making the decision other than their mailing lists. No developers seem to have been informed. Steam quite obviously didn’t know about this until the announcement was made, and it would seem as if Steam is not at all willing to accept the snap solution either.
Third, what happens when 18.04 is EOL? This statement just says that you are delaying removing 32bit support entirely until 18.04 is EOL. I’m sorry, but my games that are 32bit are not going to magically become 64bit in that time. They will always be 32bit, and I will always need 32bit libraries to run them. I enjoy playing them, and I don’t see this stopping in the future, so I will have to choose some other distro than Ubuntu to play them on as I personally will not use snaps.
Forth, the staff here seems to pushing that users had the time to make comments on this, and now that time has passed. I’m sorry, but this is the first many of us have ever heard of this happening. I assume you discussed this in your mailing lists previous to announcing it, but that is not at all a public form of discussing things. Only people who are either really, really into Ubuntu or developing Ubuntu are going to be following your mailing lists. That leaves out a huge chunk of your community from giving input on something like this.
6 Likes