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.
5 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.
7 Likes
The explanation “What we are dropping is updates to the i386 libraries, which will be frozen at the 18.04 LTS versions” means that users won’t be able to upgrade to newer GPUs because the i386 libraries frozen to their year-2019 state will only support GPUs released in 2019 or before. Users won’t be able to easily run 32-bit legacy OpenGL/Vulkan apps after buying a new GPU in 2020+.
There seem to be two options available for Ubuntu:
- continue on this course and lose some Linux market share
- revert the course and keep the current Linux market share
Make the right choice.
4 Likes
I haven’t seen any official communication from Valve just angry individuals talking on the Internet.
1 Like
https://twitter.com/Plagman2/status/1142262103106973698?s=09
Valve developer stating their stance on this mess.
Not knowledgeable or experienced enough to make a suggestion on what Canonical should do concerning this, but I am very, very concerned about how this plays out. I jumped ship from Windows entirely because I could finally run everything, both old and new, through Ubuntu (Wine’s recent blaze of progress and Steam support via native and Proton playing a large part). It’s not just games for me either. Some hardware and software are pretty important here, as in important because it’s why I have and use a computer. Snaps are mentioned as solutions, but on my hardware, which is far from ancient, they have so far been slow and the disk usage is enormous.
Ubuntu- whatever you do, please play this right. I’ve been behind you since Hoary Hedgehog and this could make or break for me.
1 Like
I would say that’s is their problem! Snaps offer real solutions to real problems, if they don’t want the solutions that is both their choice and their problem. We should try to use the best solution, we can disagree on what the best solution is, and we can listen to input from people with different opinions, but it’s up to the people actively doing contributions to do the decisions. Free Software is great because it offers the chance to influence the development of software, but in order to do that you have to actively participate, and this is something people seem to have forgotten.
That said I do agree, that for some subjects getting feedback and therefore contributions on a even more public way, is something that should be considered. But we should also keep in mind that the process is already public and transparent, things can’t discussed forever and it’s written on the CoC, that we value discussion, data and decisiveness, and are an open meritocracy, and leadership should be bold and considerate.
Does the personal twitter account of an individual, which is not even the CEO, represent the company official positions? I would be amazed if this is how Valve communicates to their costumers.
3 Likes
Hardware enablement stack is backported from the most recent LTS to the previous supported LTS versions.
2 Likes
Feel like I should at least and stop to thank all the devs involved with Ubuntu for the nice OS over more than a decade since I am expressing concerns, so all that (which I imagine will get resolved) set aside, THANK YOU 
4 Likes
You’re missing the entire point about no one testing snaps and anyone being able to provide them. That makes them a HUGE security risk, but that is not the topic of this discussion, and we should probably not derail this topic with these comments.
4 Likes
Yes: https://www.support.xerox.com/support/phaser-3400/downloads/enus.html?operatingSystem=linux&fileLanguage=en
Both CUPS and SANe old blobs do work on Ubuntu 18.04 (with some additional tweaking IIRC)
I continue to miss because I don’t see that happening, and if it does, they’re contained, so the risk is lower, and often way lower than the one with packages on universe with scarce maintenance from the community, and lower than running software unmaintained and untested by the upstream projects (reasons pointed out to do this in the beginning).
Do I understand correctly that you are going to just copy binary i386 packages from the bionic repository to eoan repository?! Are you really sure that it will be easier to maintain this than just continue building i386 packages? You may just drop Chromium, Firefox, Thunderbird, Linux kernel and some other things on i386, all other packages will be buidable with a near to zero maintanance effort.
2 Likes
Whatever excuse you feel like using to feel better. But that is official communication from a Valve developer, not just noise on the internet, which you claimed.
4 Likes
There have been multiple instances of malware being uploaded to the snap store. Nothing has changed. The same attack vectors exist and will continue to exist as long as any user can upload snaps without anyone testing them. But, again, I’d prefer to not derail this topic further.
1 Like
As far as I know there was one instance, and it was removed extremely fast. Also measures have been taken to improve the situation and as far as I know it didn’t even escaped the confinement.
1 Like
- CANON printers (https://wiki.debian.org/PrinterDriver/Canon/UFR-II). For newer models there is some “CQue driver” but it didn’t work well for me.
- Semi-official drivers for Unisystem printers (http://img.pos.in.ua/files/35/UNS-TP51_linux.zip) though it’s possible to use SAM4S drivers
2 Likes
Hi, I’m jre, (co-)maintainer of Wine in Debian, and the one who worked to bring our packages to the Ubuntu archives. I was only aware of dropping the i386 images (talked to xnox about this in 2016), but unfortunately not the current plan. AFAIK the same goes for Wine upstream.
Upstream started discussing Ubuntu’s plan here. Please have a look at that discussion and take part in it.
A few points:
Wine heavily relies on i386. Not only for legacy 32-bit software, but also “almost all” 64-bit software uses a 32-bit installer.[1] “It’s practically impossible to implement 32-bit on top of 64-bit”, so that you wouldn’t need i386 at all.[2]. 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, …).[3] 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 in [4] 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.
Upstream is not planning to ship all dependencies for their OBS build, and will probably just stop to build for 19.10+.[5] This is not to say that they are not interested in working on a solution.
About solutions, can you confirm these assumptions:
- the kernel will still support 32-bit executables
- you can’t use i386-PPAs for 19.10+
I’ve been told that users already leave Ubuntu, because our Debian packages are not providing good enough system integration (most notably they don’t install a wine.desktop file, but ship it as example only). The 6-line instructions for upstream’s packages are also frequently criticized as too difficult. With whatever solution whoever comes up with, I fear this would drive even more Ubuntu users away.
[EDIT] I was a new user, so could only post 2 links. Here’s the rest:
[1] https://www.winehq.org/pipermail/wine-devel/2019-June/147874.html
[2] https://www.winehq.org/pipermail/wine-devel/2019-June/147959.html
[3] https://forum.winehq.org/viewtopic.php?f=8&t=32061
[4] https://lists.ubuntu.com/archives/ubuntu-devel/2018-May/040348.html
[5] https://www.winehq.org/pipermail/wine-devel/2019-June/147904.html
16 Likes