Hi. I really appreciate your efforts to keep the discussion clear and civil. Passions are going to run a bit high about this, though, so it might be sensible to allow a bit of discussion to play out for a while. The Linux world is watching, and I think it is important the community forum doesn’t show a deaf ear.
I’m glad that the devs are listening to the community, I hope the feedback and testing is useful to make a good decision.
I also want to remind that it’s good to follow the Ubuntu philosophy, we can all benefit from different points of view.
Am not an ubuntu developer or someone with influence or power to change this decision but I would like to give my personal opinion about this and how it impacts my life for the better part of the last 15 years,just to give a point of view of someone who has personally taken ubuntu to the core.
Since around 2008 I have promoted ubuntu over other distros, over windows and even over mac. Basically a bit more than a decade. I managed to help somewhere around 2k new users to Ubuntu that most still enjoy it today. Of the many points I got asked, one always stands out, which is gaming on linux. In this case, gaming on Ubuntu.
This is my biggest selling point to convince most users to not only use but also stay on Linux. In my particular life, convince, teach and make someone love ubuntu, stay on it and enjoy it everyday.
If you check on askubuntu you will see a wine question that was created a long time ago with the effort of communicating to the public and showing new users that you can potentially play windows games on Ubuntu, run Microsoft products on Ubuntu and do many things that I had to fight, struggle and dedicate myself in order to find ways for new users to end up loving ubuntu (got a bit carried away but it has been10 years dedicated to ubuntu here). So when this announcement came, I actually thought it was a great idea. I mean it’s 2019 and 64 bit stuff is almost 2 decades old. So I was all for it. But then I saw the post about wine developers and the issues they would have, potentially crippling new users and existing users to stay in Ubuntu. Then today I see the one about steam and what their thoughts are about leaving Ubuntu 19.10 and future versions. Basically killing the biggest points I use to promote Ubuntu for everyone.
Obviously this is not critical from a development point of view, but I hope someone reads this and understands the effort I have put for an operating system (and even a community like askubuntu) and then see all of this happening and the negative effect it would have primarily on the community. I hope this small grain of sand helps a bit in reversing this decision, looking for an alternative (which I can see it is being worked on) but not affect the community in a way that would make ubuntu a distro that is npt an option for many users. Thank you.
“Support” is such a nebulous term.
If Valve “supports” any Linux-based distribution, I don’t see why on Ubuntu you wouldn’t be able to put that into a container and then just run it. Games don’t generally need to interact with the rest of your desktop anyway, and my understanding is that kernel support in Ubuntu for running 32-bit userspace processes isn’t going away.
In other words, I don’t see how, technically, it will suddenly become impossible for you to run Steam on an Ubuntu system, assuming that Steam continues to work on some supported Linux distribution. In theory it could become more difficult to get set up to do it, but I don’t see why that couldn’t be automated. There certainly seems to be enough demand that someone is likely to volunteer a tutorial at the minimum, and at best it’d all be encapsulated into a package (deb, snap, shell script or whatever) that you just install.
But what about old printer and MFP drivers that actually need to interact with hardware for things like printing, scanning, sending/receiving faxes, supporting MFP buttons “scan to PC”, etc.? Even if it’s possible to run those things in containers, how they are going to get there if user double click on binary installer or i386 deb downloaded from vendor’s web-site?
As for Steam - keep in mind that games published there need to interact with 32 bit OpenGL implementation, which means not only providing 32-bit Mesa as container dependency (which is Ok) and keeping it updated in timely manner (because in Linux gaming availability of fresh Mesa version make a difference between working system and GPU hang) but also providing every version of 32 bit Nvidia driver that should match version of kernel driver to be operational.
Honestly, I’m all for dropping i386 repo, but solutions for keeping people’s hardware and software running have be tested in real world and be reliable. At this moment there is no solutions, but only blind assumption, that these solutions could be created (which could be possible, but it’s remain to be seen). Dropping i386 now is like putting the cart before the horse.
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.
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.
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?
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.
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.
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.
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.
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.
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?
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.
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?