Ubuntu Reverses Decision, Says It Will Continue To Support 32-bit Packages (betanews.com) 94
Canonical has issued a statement on Ubuntu's 32-bit future, saying it will continue to build and maintain a 32-bit archive going forward. From a report: Of course, there was some negativity surrounding the decision -- as is common with everything in the world today. In particular, developers of WINE were upset, since their Windows compatibility layer depends on 32-bit, apparently. In a statement, Canonical said: "Thanks to the huge amount of feedback this weekend from gamers, Ubuntu Studio, and the WINE community, we will change our plan and build selected 32-bit i386 packages for Ubuntu 19.10 and 20.04 LTS. We will put in place a community process to determine which 32-bit packages are needed to support legacy software, and can add to that list post-release if we miss something that is needed. Community discussions can sometimes take unexpected turns, and this is one of those. The question of support for 32-bit x86 has been raised and seriously discussed in Ubuntu developer and community forums since 2014. That's how we make decisions."
Oh joyous news (Score:1)
now my life is complete!
Re: (Score:1)
Cool story bro. Whether you realize it or not a lot of software is still only written for 32bit architecture. A 64bit processor can still handle 32bit software, so a lot of people don't even realize when they're using it. The problem here is not that people can't us a 32bit OS. It's that they weren't going to have 32bit libraries in their repos anymore for people that need them on a 64bit OS. One of the common uses for 32bit software on Linux is game launches.
Re: (Score:2)
It is joyous news if you use Steam with ubuntu
https://www.pcmag.com/news/369... [pcmag.com]
Re: (Score:2)
How many years will a true 64-bit transition take - 50??
I can't believe that it took less time to rollout broadcast HD.
Re:Seems to kind of suck (Score:5, Insightful)
What do you mean by "a true 64-bit transition"?
I have been running 64 bit linux distro for 10 years. Very few people still run 32-bit linux systems. Mostly they are running them on 32-bit processors. (You still find some on the cheap end.)
Having the option of 32-bit compatibility is not a bad thing. Most people won't use it and the applications using the 32-bit interface probably don't need to be running in 64 bits.
Re: (Score:1)
Re: (Score:2)
Except it can be a bad thing. 32bit libs are rarely used and can harbour attack vectors.
Except they are built from the same source as the 64 bit libraries and thus essentially have the same vulnerabilities. So any issue that gets fixed for 64 bit will be fixed for 32 bit and vice versa. Even integer overflow are going to be the same since an int, for instance, is 32 bit regardless.
Plus I disagree with your assessment that the 32 bit libraries are 'rarely used'.
Re: (Score:2, Informative)
Some people like actually being able to run old software. If you don't, then you can go ahead and delete all of those nasty 32-bit libraries that are "holding you back".
Sounds like an excellent trade-off for a few cents of disk space.
Re: (Score:2)
And that's about all it is, because Debian, which Ubuntu is based on, still supports the 32 bit libraries. It even supports pure 32 bit systems.
Re:Seems to kind of suck (Score:5, Informative)
Based on this comment and others you made last time around, you don't seem to have a good understanding of what the issues here are and what Ubuntu has decided to do.
You keep saying things like "holding back Linux." How does multi-arch library support do this?
Besides, why is a 64-bit pure transition needed? Linux is going to be supporting 32-bit architectures for many many years. There's just simply no need for 64-bits in many environments and on some architectures. There is zero benefit in these situations.
Re:Seems to kind of suck (Score:4, Informative)
Also, like was said by the other commenter, Linux is already 64-bit, and most people are already running 64-bit clean distros. 32-bit packages are only installed if you need them to support a 32-bit binary. So on further reflection, your comment strikes me as being just wrong. Linux isn't being held back; it's already 64-bit. There's no transition that needs to happen. It already happened 10 years ago. Period. The fact that some people need 32-bit libraries doesn't change this fact.
That is true (Score:5, Insightful)
you don't seem to have a good understanding of what the issues here are and what Ubuntu has decided to do.
I fully admit to that, it's been several years since I've run a Linux distro on my own equipment.
How does multi-arch library support do this?
By not fully committing, it drains some dev resources.
Besides, why is a 64-bit pure transition needed?
It just makes development that much more complex if you have something else you need to test or think about.
But like I said, I really don't have a close relationship with the issue, so possibly it is fine. It just looks strange from an outside view.
Re: (Score:3)
The upstream source code for these libraries already need to compile on 32-bit as well as 64-bit. Someone else mentioned 32-bit code could be an attack vector. If that's true, then it's a bug that the upstream devs need to address, because there are plenty of posix 32-bit architectures out there. The same source code builds either 32-bit or 64-bit versions of the library. So the dev resources are not stretched very much by having some 32-bit multi-arch libraries in the repo. Also Debian, which is the up
Re: (Score:3)
If you need 32-bit support for some binaries, you can install multi-arch support
The issue was that it costs money to maintain multiarch support.
Re: (Score:2)
Does it though? Debian already maintains a 32-bit pure distro which feeds into Ubuntu. The cost to Ubuntu is very low given the benefit to Ubuntu as a company having Steam run on their distro.
Re: (Score:1)
I fully admit to that, it's been several years since I've run a Linux distro on my own equipment.
So, person with no real knowledge in this area formed a cursory opinion then demands it be treated as fact and used to action his desired changes to a system he doesn't even use. Sod off.
By not fully committing, it drains some dev resources.
What resources? Lots of platforms are still 32-bit, even if x86 has largely gone 64-bit. Devs and kernels are still supporting that for the foreseeable future. If Linux were to remove i686 support from the kernel today it would still run on a large number of non-x86 32-bit platforms.
It just makes development that much more complex if you have something else you need to test or think about.
It doesn't make anything more complex. St
Re: (Score:2)
By not fully committing, it drains some dev resources.
Multi-arch is also used for cross-architecture development such as compiling for Arm, etc. So dropping 32 bit x86 packages will not let one drop support for multi-arch anyway.
It just makes development that much more complex if you have something else you need to test or think about.
These applications and libraries still need to be compiled for Arm (for Android), and a bunch of other architectures (just last week I saw patches for MIPS for an open-source project I work on). So dropping support for 32 bit x86 will not simplify development much. If anything testing on a diverse set of platforms and architectures hel
Re: (Score:2)
Never thought I'd see the day when Windows was holding back Linux. Yuck.
How is shipping 32-bit support inside a 64-bit OS holding Linux back? It's not as if the presence of 32-bit support in your 64-bit OS prevents you from running the 64-bit programs.
I'm guessing you're one of those "non-technical" computer users?
Re: (Score:3)
Never thought I'd see the day when Windows was holding back Linux
In all fairness this brouhaha steams from a fundamental decision of, "who supports what". WINE developers are the main pushers for i386 compat libs as many of the more modern Linux programs that come with your standard distro are fully 64-bit. WINE devs have for the longest time, relied on distro makers to provide the compat libs and thus they've devoted very minimal resources to that end. Ubuntu doesn't really have a use-case for compat libs in their mainstream distro and see the continued support as a
Re:Seems to kind of suck (Score:5, Insightful)
I'm not sure. Ubuntu didn't blink until Steam said they wouldn't be supporting the newer versions. Wine raised the issue, but Ubuntu didn't care. Yesterday Steam said they wouldn't be supporting the newer releases of Ubuntu, and today the decision is rescinded.
Re: (Score:2)
And that's probably a close reason - Ubuntu is pretty big among commercial software developers, and having everyone suddenly drop support would mean likely mass migration to a new Linux distribution. Remember, people run Linux for the applications, an
x86-64 has more registers (Score:2)
Actually, there's very little value in a 64-bit app if the app's memory footprint won't utilize it.
It's fairly easy to get to a "memory footprint" where x86-64 has an advantage simply because it has more registers than i686. This means a function with more than six variables will spend cycles spilling registers to the stack less often when compiled to x86-64 machine code than when compiled to i686 machine code. For many workloads, this compensates for the data cache hit of 64-bit pointers. But for some users, it doesn't necessarily compensate for the swap file hit of keeping i686 support libraries loaded
Re: (Score:2)
The extra registers is why the x32-ABI was created. All of the added benefits of the extra registers while using 32bit pointers, which should in theory reduce cache misses.
The trouble with x32 ABI is that you have to convince all third-party developers to recompile their software for x32 ABI. Otherwise, you have to keep the x86-64 libraries loaded for third-party x86-64 software and x86 libraries loaded for third-party x86 software. It never caught on, and Linux kernel developers were thinking of dropping it six months ago [slashdot.org].
Re: (Score:2)
Ultimately WINE and a few outliers are the ones with vested interest in compat libs, and it would only seem fair that they take up the mantle on them.
Providing packages for the base libraries is the job of Linux distributions.
Should it come to this, the solution for Wine will not be to provide 32 bit packages for every Linux distribution that drops 32 bit support, but to roll out its own Linux distribution.
Re: (Score:1)
How many years will a true 64-bit transition take - 50??
If you don't need alot of RAM or to multiply 64 bit numbers, then 64 bit processors can slow you down. The 64-bit wide bandwidth going everywhere isn't free, it costs in terms of transistors and performance.
It's not all unicorns and rainbows... (Score:1)
I'm a little apprehensive of the "selected" part of their statement.
Re: (Score:2)
Shades of Tesla and their "we're going to close all our stores/no we're not" recent idiocy.
Not to be confused with the upcoming film, "50 Shades of Tesla" ...
Re: (Score:1)
IA32 is not legacy. not yet anyway.
Re: (Score:2, Informative)
Man, in two posts, you've made it clear you're a blitherint idiot, or a Windows junkie... which are sometimes one in the same, but on to the actual topic. MANY, not just some, Windows SOFTWARE install programs for 64bit software use 32bit installers. That's not a conspiracy, that's a fact. You're not even a good troll. You're just a retard who found an unlocked computer at the insane asylum's visitor center.
What a douche.
Re: (Score:1)
there, do I fit in better?
Re: (Score:2)
I do still occasionally need 16-bit support (usually for running DOS programs that for whatever reason do not have Linux equivalents—e.g. to restore a backup in a discontinued format). I have ended up using QEMU because VM86 is not supported in long mode.
I was previously unaware of it, but apparently (I just checked sandpile.org [sandpile.org]) 16-bit protected-mode tasks are supported under long mode (which does not help with DOS).
Re: (Score:2)
Re: (Score:3, Informative)
For testing on 32-bit hardware you would probably be correct, but that is not what this announcement was about. Many Linux distributions are dropping support for 32-bit hardware with little fanfare and few complaints.
Ubuntu was trying to drop support for 32-bit software. That decision would be dangerously stupid unless they wanted fewer users of Ubuntu.
Re: (Score:1)
Well, the actual maintainers of the relevant software (kernel, glibc, gcc/clang, Debian packaging) are perfectly fine keeping it forward - at least for now. Furthermore, win32 API is a perfectly supported by Microsoft and still relevant on Windows platform.
Perhaps eventually, 32bit software will be less important and some people will want to deprecate it, but it's not Cannonical's call to make.
16 bit (Score:2, Funny)
Re: (Score:1)
Re: (Score:2)
A good decision on Ubuntu's part (Score:5, Informative)
It's not like Ubuntu is maintaining a full 32-bit distro. These are just a relatively few libraries that are called to support 32-bit executables and dlls in Wine.
There are several reasons why the Wine developers are hesitant to ship their own 32-bit binaries of these libraries, like Steam does. The main reason is that different distros ship their own patched versions, often older than mainline, of these libraries, and most package managers require that multi-arch packages be the exact same version across architectures. This is mainly so that overlapping files can be trivially deduplicated. For example, you might have libpng.x86_64.rpm and libpng.i386.rpm, which both might contain some duplicated files such as files in /usr/share, /etc, or /usr/doc, /usr/include, etc, depending on what package we're talking about. Also since wine is both 64-bit and 32-bit, and since the 64-bit packages usually depend on the system-installed 64-bit libraries, it's nice to have the same version of the 32-bit libraries for consistency in terms of debugging and bug reporting. Also if they were to ship their source with the wine tree, that would be quite a burden to keep them all up to date. But not impossible.
Since most of these library packages come with very little change from Debian, which is maintaining 32-bit packages until now and for the foreseeable future, the cost to Ubuntu to do this is not terrible given the benefits to Ubuntu of having users who need to run legacy software (windows or Linux native), or gamers.
Going forward, there are three options for Wine. First, lobby distros to continue support 32-bit multi-arch versions of certain libraries. Red Hat and Fedora will likely do this for years yet. Second, ship their own copies of these libraries in the source code tree, which will build as dependencies of wine. Third, build shims to thunk data between the wine dlls and 64-bit native versions of things like libpng, etc.
Wine developers aren't too keen on the last one simply because of the tremendous amount of time and work it would take, and since option 1 is cheapest and already just works. However, this was the only viable option for the stalled Hangover wine project that was an attempt to use wine and qemu to run x86 win32 binaries on Arm. So there is some precedent for this, and it may be the only long-term, permanent solution. Perhaps some kind of automated tooling could be developed to make these conversion shims.
Re: (Score:2)
Re: (Score:2)
You're right. I had forgotten about that fact. Crossover funds quite a bit of wine development. I'm sure normal wine will get these 32 to 64 bit thunks eventually. I'm sure that many would welcome a 64-bit clean version of Wine that could run 32-bit exes still. Might even simply wine a little bit.
what an oddly slanted article (Score:5, Insightful)
I'm not sure how to break it to this guy, but supporting users and their software is what a distribution is for. People whose software is still going to work won't consider that work wasted, that's for sure.
Re: (Score:1)
You missed the memo, we have moved past developing software for users. It's now developed primarily to turn those users into product. The only time their opinions matter is when it is enough to actually drive them away from your digital coral. The rest of the decisions are purely about decreasing costs or increasing the amount of data they have available to sell or the amount of ads they can get paid for force feeding you.
Double plus good logic right there... (Score:1, Insightful)
Lets start, shall we?
Thanks to the huge amount of feedback this weekend from gamers,
.. Signling out "special" people... (yes, signal, the virtuious kind)
Ubuntu Studio,
Never let an outrage go unoticed, be sure to market something no one's ever heard of and not related
and the WINE community,
Alienating more people out.
we will change our plan and build selected 32-bit i386 packages for Ubuntu 19.10 and 20.04 LTS.
Which had nothing to do with it. You either support it or you don't, this Bullshit answer says nothing about how those packages will be delivered. My guess, snap fap or whatever the hell else they think of. Completley missing the point.
We will put in place a community process to determine which 32-bit packages are needed to support legacy software, and can add to that list post-release if we miss something that is needed.
Funny, you claim that process already exists.
Community discussions can sometimes take unexpected turns, and this is one of those.
Like peop
This is good news if you use Ubuntu (Score:5, Interesting)
I would prefer to run Ubuntu (and Ubuntu derivatives, like Mint) exclusively. There are four things that I use Crossover (a commercial distribution of Wine) for:
1) MS Office (2007). I also use LibreOffice, but I'm a graduate student and docx is supported more than odt in many platforms.
2) EasyMP, the software to connect through LAN to Epson LCD projectors.
3) An old release of MATLAB that I purchased as a student, which doesn't require Internet activation.
4) A Windows-based Euchre game since there's not really a Linux option for that (please let me know if I'm wrong on that one)
In all of these cases, Crossover works flawlessly. I actually bought a lifetime license with Codeweavers because I appreciate how convenient it makes installing Windows applications.
The news that the 32-bit archive was going down was disappointing; I honestly thought I needed to go back to Windows. I think it's fine for them to only have a 64-bit distribution, but they need to keep the 32-bit archive going. This is not just a Wine issue; I have a Microsoft Surface (yes, I know, I'm sorry, but I like the design) and it has a HiDPI screen. The regular version of DOSBox in the repository does not work on the display; I had to install the Daum SVN version, which is 32-bit and requires the installation of some 32-bit libraries from the package archive. I did some research; people have tried to compile a 64-bit version from source but have not gotten very far.
I think Canonical made the right move here. Breaking Wine is not going to help Linux on the desktop. I appreciate their willingness to listen to the community. They have been criticized for that in the past, and they deserve credit for changing their ways.
Re: (Score:2)
3) An old release of MATLAB that I purchased as a student, which doesn't require Internet activation.
I've been using Matlab on Linux for ~20 years on and off. Why not use the Linux version?
Re: (Score:2)
Title is misleading (Score:2)
Ubuntu said they were going to keep "some" 32 bit packages. Eventually a lot. And not necessarily in an useful fashion. Snaps or flatpacks do not allow you to easily install steam on you system partition and then the data and games on another hard disk for example.
IA-32 is needed for a lot of stuff. Not only windows software.
Many printer drivers.
Commercial software which, not being open-source, are not going to be recompiled like, ever. Among them many video games both Windows and Linux native.
Whether you l
how much of this decision has to do be with steam? (Score:1)
Since Steam announced 2 days ago that Ubuntu from version 19.10 onward will no longer be officially supported by Steam and they will switch their focus to a different distribution.
https://twitter.com/Plagman2/s... [twitter.com]
Real costs of fake free (Score:2)
Already half-expired? Worth the effort of commenting? Not really, but...
Here's one minor, but concrete, example of what's wrong with Ubuntu and why it should not be regarded as cost-free. This week, for no reason that I could figure out, mysql-common somehow got corrupted during an update. All the time I spent researching and fixing the problem becomes part of my cost for using Ubuntu. (I didn't time it, but the exact time doesn't actually matter, because it happens so often. Perhaps an hour this time, but
32-bit will hang around, but should be "2nd class" (Score:2)
It's very hard to get rid of 32-bit libraries on Linux, mainly because of legacy closed source Linux (and Windows via WINE) 32-bit binaries. However, anything new, whether closed source or not, should be released as 64-bit binaries only - this includes entire Linux distros, ideally with the latest Windows OS/apps/games also going 64-bit only.
By default, 64-bit distros should not install 32-bit binaries/libraries at all - only if packages that absolutely require 32-bit libraries/binaries (e.g. Steam, WINE) a