FWIW, I’m still using Canon Scangear (originally available in this PPA, I’ve recompiled it for newer releases) for my Canon scanner. There’s an open-source SANE driver as well, but it is so buggy that it’s unusable.
The Linux drivers and application were originally available on an Asian Canon support site. Not sure if that site still exists.
I might be the only one still using that particular software, but I definitely need it to use my hardware.
The disk space hog that is snap is painful. Having a large amount of slightly different compressed bits that are in fact the same bits when uncompressed multiple times over taking up space really aggravates me. Currently I use separate bottles for each app and use hard links to save space. I know you can use parallel installs of snaps and content snaps, but it seems like too much hard work, and then making sure that the user space Mesa libraries don’t have incompatibilities with the kernel drm / gpu drivers. And GPUs bought after 19.04 in particular will be a very tricky problem with the current decided direction.
I still don’t understand the rationale here.
Dropping the i386 architecture I can understand. Removing the installer images and repositories for an architecture which represents a very small part of the userbase has been done for other distros too.
What I don’t understand is how or why this stops updated lib32-* packages of 32-bit libraries being provided in the amd64 repos for 64-bit installations, or why this means “i386” libraries must be frozen. I suspect the whole “i386” and “32-bit” nomenclature is also getting confused.
Surely all 32-bit applications running on a 64-bit host which currently use $library:i386 should be able to use a lib32-$library instead? Isn’t this essentially what multiarch support was supposed to take care of?
This should also mean that wine32:i386 could just be wine32:amd64 instead, and steam can just depend on e.g.
lib32-alsa-lib lib32-alsa-plugins lib32-atk
lib32-cairo lib32-curl lib32-dbus-glib lib32-fontconfig lib32-freetype2 lib32-freeglut lib32-gconf lib32-gdk-pixbuf2
lib32-glew1.10 lib32-glib2 lib32-glu lib32-gtk2 lib32-libgudev>=230 lib32-libappindicator-gtk2 lib32-libcaca
lib32-libcanberra lib32-libcups lib32-libcurl-compat lib32-libcurl-gnutls lib32-dbus lib32-libdrm lib32-libgcrypt15
lib32-libice lib32-libjpeg6 lib32-libnm-glib lib32-libpng12 lib32-libpulse lib32-librtmp0 lib32-libsm
lib32-libtheora lib32-libtiff4 lib32-libudev0-shim lib32-libusb lib32-libva1 lib32-libvorbis lib32-libvpx1.3
lib32-libwrap lib32-libxcomposite lib32-libxcursor lib32-libxft lib32-libxi lib32-libxinerama lib32-libxmu
lib32-libxrandr lib32-libxrender lib32-libxtst lib32-libxxf86vm lib32-nspr lib32-nss lib32-openal lib32-openssl-1.0
lib32-pango lib32-sdl lib32-sdl2 lib32-sdl2_image lib32-sdl2_mixer lib32-sdl2_ttf lib32-sdl_image lib32-sdl_mixer
lib32-sdl_ttf lib32-libvdpau
etc. as it already does in other 64-bit distros.
Edit:
It’s not like software no longer compiles with -m32. I could understand the issue if you were trying to retain non-SSE2 support in 32-bit binaries (à la -march=i686 vs -march=pentium4), but that’s irrelevant for lib32-*.
Similar case to Madrid Linux. It is a distro based on Ubuntu LTS used in a lot of schools in Madrid, Spain (if not all schools, there was a mass migration recently).
There is a ton of educative proprietary software that is made to run with 32-bit libraries and a lot of it is win32 only (thus it needs 32-bit Wine to work). In a school environment where the majority of people don’t have technical knowledge of computers it is important to keep simplicity. Ubuntu made things simple that was the reason for choosing it as the base of that distro, containers will always be more complicated than maintaining a set of system libraries due to the new challenges and possible performance penalties.
Why do we have to reinvent the wheel and confuse everyone?
This is exactly what me and others have suggested before, thanks for explaining it further.
Thanks for the info, that’s an interesting feature. Why didn’t you just mention it in the other thread? It doesn’t fix all of the problems I mentioned, but at least one of them.
My aim is to explain how all this works in a layered way. For example, I did not cover audio, because it would make the guide a bit more compicated.
You cannot imagine how fragile is the process of composing a guide that many people will manage to follow.
If you are running Wine to run Windows apps on Ubuntu, then you are running Windows apps, one way or other. Wine appears to have some inability to move to 64bit, but that is not a problem of Ubuntu or Linux in general. There’s such a cry over the matter that 32 bit apps (say games) might not be able to run on Ubuntu 64bit. The games (developers) would do 64bit, if and when the gaming platform (meaning Windows) stop supporting 32 bit. The developers of apps (games) don’t dictate terms, the OS dictates the terms.
We, at Linux sort of can’t dictate terms, which is really sad.
One day, the OS owner would stop supporting the 32 bit OS, and the 32bit software and I’ll be left with nice little 32bit Windows OS device. I don’t game, but all those 32 bit software would be obsolete. The thing is, all the app developers would have to move to 64 bit, or lose business.
So, Ubuntu , if it wants/needs should move to 64 bit right away, without any outside dictate. By the time, the rest of the world is forced to move to 64 bit, Ubuntu would be miles ahead.
Community/users needs are complete valid dictates as Ubuntu is made for human beings. Unless Ubuntu axiom changed, your last paragraph has no sense for me.
What about legacy software written fifteen years ago? It’s really shortsighted to drop support for 32bit if there’s no solution available.
And I don’t share moderator’s view to split the discussion as this thread is the one which is linked to in multiple discussions. It feels like moderators are hiding the negative comments into another thread, out of view.
This seems like one of the most self defeating & user-hostile moves in history
I wouldn’t to call it “hostile”. I like to think that it is just a bad move that affects more users than they though.
Next year is the eol for W7 and Ubuntu based distros are always the first suggestion for any friend/relative that doesn’t like W10 or wants to try something new. From my point of view, Ubuntu devs must understand that 32 bit support is not mandatory but necessary in order to make life easier to people that comes from other OS. This discussion is more UX than technical, so users requirements inputs should be handled very seriously (and I think that they understood it in that way is as we already have some sort of backtracking to the original idea).
So yeah, what users wants/needs has a big weight on this topic.
It just seems to cack-handed, just when gaming on Linux was making some great ground one of the biggest distributions that’s designed with new users in mind pulls something like this and when objections are raised the response is “should have said something sooner”
Even if the decision is reversed why would users trust Ubuntu going forward? Why would companies like Valve or Crossover & big projects like Wine trust Ubuntu going forward?
I’d be hard pressed now to recommend Ubuntu to anyone considering migrating
Very few dispute dropping i386 install media & we can agree there’s no point maintaining an i386 tree of every linux utility & program when there are x86_64 versions available
Pare all that back, absolutely but there was no need to throw the baby out with the bath water
Reading that makes me sad, I hope it was just a poor choice of words on your part …
No, the OS certainly does not dictate any terms. It enables the user to actually do useful (to the user) things with the hardware, that’s it. Yes, Microsoft (via Windows) do dictate terms, but that’s neither natural nor in any way desirable. IMHO, FOSS’ raison d’être could be summarised as “so nobody gets to dictate terms” – it’s certainly one of the main attractions for me.
Also, where’s this idea that it’s desirable or even necessary to move everything to 64 bits come from? It’s not like it’s inherently better. Removing multiarch is not a step forward, it’s a step back. Literally. I’m just a user, but I’ve been running Debian amd64 since before it became an official architecture, Ubuntu on & off since the beginning, and I remember the struggle for the comparatively elegant multiarch solution we have now.
There’s no technical reason for removing it, it is, at best, done for cost-cutting reasons. That’s fine, I just wish people wouldn’t frame it as progressive.
Hi everyone, thanks for all the feedback. There is an official response here:
This is a promising reply. However, snaps are still not a long-term solution. Please stop acting like they are.
That’s an improvement, but it doesn’t address why, given that it was said that “On the list of known blockers for removing the i386 port are Steam and Wine (sic)” over a year ago on the mailing list linked to, zero work or discussion seems to have happened with Steam and the WINE developers in the past twelve months.
Instead, this came as a surprise to them. Why?
I get that servers are where Canonical makes most of its money, but the cost in reputation for doing this to a large chunk of desktop users in the way it’s been done is substantial.
You use an older OS for that. Ubuntu can’t stop developing, just to keep old apps, devices going. Everyone knew 32 bit is going away, a long time. Also, when Windows pulls the plug, all 32bit software have to move to 64bit or close shop.
Ubuntu is a Linux distro that goes forward all the time. It cannot wait until someone dictates to it. Best move to 64 bit now, and concentrate on that than wasting resources on older dying system.
I once used 8bit and 16bit, nothing is left now. I don’t even have a 32 bit device for a decade or so, only that 64 bit device that runs a 32 bit Windows 10. One day, it is going to be a museum piece.
All 32bit apps that Wine runs, would stop existing when MS decides to pull the plug. Btw, why should Ubuntu or any other Linux distro be dictated by Wine or what Wine can or cannot? Wine has nothing to do with Linux and its apps, only Windows apps, so what does Wine advertise?
You use an older OS for that.
That’s not necessarily an option. Older OSs generally speaking do not work on modern hardware because the hardware requires support which hadn’t been developed yet. That’s only an option if you’re also running older hardware.