Wine Developers Appear Quite Apprehensive About Ubuntu's Plans To Drop 32-Bit Support

[Jumbotron]

This is like stupid web developers and site maintainers bitching about Flash being deprecated. You KNEW this day was coming. You sat on your ass. Deal with it.

[chilinux]

Next questions: My printer and my scanners all use 32-bit plugins. Will they now get worthless?

I wouldn't say worthless as much as it will be a much more involved process to get working. By the time this change makes it into 20.04 LTS, there probably will be guides written by third-party contributes on how to continue to get popular printer binary-only filters working.

A lot of the blame for this specific situation should be put on the Linux Foundation rather than Canonical. Linux Foundation claimed a long time ago they would take on the mission of making printing "just work" for Linux. Once LF claimed the itch was already being scratch, most other people that might have taken on the goal decided not perform "duplicate" effort.

Initially, the Linux Foundation had been handling the OpenPrinting database of compatible printers. Vendors figured out quickly that they could be put on the works "perfectly" list of printers by releasing closed source and restricted licensed printer filters. Only people that click on the listing entry end up seeing the printer only "works" perfect to the extent the binary filter works. The degree to which this "works" is consistent with promoting an "Open" Printing ecosystem is questionable.

At some point it seems like someone at the Linux Foundation seems to have figured out the problems with the OpenPrinting database and it has gone stagnant for a long while. Instead, they seemed to be shifting to promoting a driverless standard called "IPP Everywhere(TM)." But the degree to which they promoted it seems to have also gone into stagnation.

Most people and even vendors haven't heard of or understand what "IPP Everywhere(TM)" is. People don't know to look for it on the printer specification or demand it being available. Vendors confuse it with being the same as just IPP which it isn't. It is possible to be an IPP printer and still not satisfy the requirements for "IPP Everywhere(TM)." So you will get vendors that answer with a straight face the question of if their printer does "IPP Everywhere(TM)" while in reality it does not.

To help resolve this and stay true to the commitment of "just works" printing on Linux, the Linux Foundation seem to now be doing .... NOTHING.

Linux Foundation issue press releases, including in 2019, but don't seem to be involved in promoting educating the public or vendors about "IPP Everywhere(TM)" via any of the press releases.

Linux Foundation attends conferences and summits to promote themselves and things they are involved in. But, again, this involvement does not show promoting "IPP Everywhere(TM)" being a priority for the Linux Foundation.

Several of the major companies that make printers are listed on the corporate membership list and the Linux Foundation should have contacts in those companies to help liaison on shifting the companies towards providing "IPP Everywhere(TM)" compliant printers. But that doesn't seem to be happening either. Instead, the Linux Foundation seems to mostly exist to satisfy the desired direction of the corporate members instead of the LInux Foundation existing to promote it's claimed mission statements to the corporate members. This becomes problem for all Linux Foundation stated goals involving Linux as a desktop OS since the majority of these corporate members either have a vested interested in keeping the established status quo when it comes to the desktop or they simply just don't care about Linux on the desktop.

If you really care this much about printing on Linux to "just works" regardless of what direction distributions go in for the binary architecture, feel free to ask the LInux Foundation on their twitter when was the last time they did anything substantial in 2019 to promote the "IPP Everywhere(TM)" standard and printer certification? The twitter feed can be found @linuxfoundation and I am sure you will love the "answer" they provide.

[mzs.112000]

It looks like the computers that I maintain, which are all still functional, will need to switch to that other major OS, which still supports 32-bit, and is expected to do so until 2023...

Windows 10, which will work on any P4 or newer CPU...

[Guest]

I'm curious to see how no 32-bit support plays out. I personally don't believe I use anything that requires 32-bit libraries (I use Wine, but use 64-bit prefixes and I believe the launchers and games I play also are both native 64-bit executables), but outside of that, I'm pretty confident I'd be ok.

[oiaohm]

https://github.com/AndreRH/hangover

There is already a form of wine that runs on Linux x86 64 bit only systems yet runs win16, win32 and win64 applications. The thunking from 32/16bit wine functions to 64 bit wine libraries is not 100 percent complete. Yes that thunking means it only need 64 bit provided by host. Yes the option in hangover to use qemu means even if the host turns off 32 bit support in kernel this option will still work of course at a performance price.

Ubuntu 19.10 is really not a long term deal breaker for wine. Short term lots of work is need to complete hangover.

[shmerl]

https://github.com/AndreRH/hangover

There is already a form of wine that runs on Linux x86 64 bit only systems yet runs win16, win32 and win64 applications.

Does it have a significant performance hit, compared to native 32-bit / WoW64 Wine case? Gaming use case is very demanding, and performance degradation is not really an acceptable option, when Wine itself already introduces an overhead in comparison with regular Windows.

[elvis]

the people who refuse to drop 32bit support and move forward deserve to be left in the past with other dead projects

wine is a mistake, it makes people rely on buggy solutions rather than unite and offer sane environment for apps/games to prosper

macOS dropped 32bit LONG time ago, and it is doing MUCH MUCH MUCH better than what you are trying to achieve with linux OS's aka stay in the 80's with your anti UX/UI preferences

Preservation and documentation of past human work requires interaction with those things. At no point do we burn museums and libraries and say that they're just taking up space, are old, and we should move on for the rest of humanity to prosper.

Keeping environments alive on modern operating systems that allow running, preservation, investigation and documentation of programs, games, and whatever else we've made in the past is important. Maybe not for you, but it is for millions of people. And the development efforts and resources of these preservation projects in no way take away from new code moving forwards. That is an entirely false dichotomy.

See the efforts of people like Archive.org, GoG and others who put considerable effort in to keeping old art alive. None of it would be possible without open source tools like FreeDOS, DOSBox, WINE and others.

None of that is a mistake. It's all very valuable, very useful, and does not harm new projects or technologies (indeed, anything that teaches new developers the mistakes of the past is VERY valuable).

[BwackNinja]

I'm pretty sure this could be overridden or circumvented in various ways.
For example, a file system driver which just shuffles a few directories around would suffice.

You're making this more complicated than it needs to be. They're the same version because there's no reason for them to be different versions. With central packaging by the OS vendor, these can be kept in sync without extra effort while avoiding redundant storage of duplicate files.

OS producer, in my view, should be the maintainer.

But that isn't the case on any other platform. When you need to use extra libraries, you bundle them yourself on other platforms. The difference is that on LIiux, you're expecting the distribution to be a development platform even before you expect it to be an operating system.

I have no experience there, but I would say: if manpower is lacking, copy from upstream.

There's not always an upstream, and to expect one to exist is a convenient situation brought about by the expectation of distributions to package all available software known to man, despite how its usefulness (in the repositories) is limited to a small number of programs that themselves aren't properly tracking the changes in aforementioned library.

OS should provide common code shared by multiple applications. Therefore, x86-32 libs should be included.

You're missing what it means to be a library and the fact that the distribution has to maintain and/or consolidate several potentially incompatible versions because the software you'd like to have in your repository was created targeting a specific version and not updated properly against a newer one, even when there are security considerations to deal with.

[chithanh]

What's not understandable and not acceptable is giving the world 4 months notice only. Such a change should be announced at least a year in advance.

The 19.10 release is only used by few desktop users, most are on LTS. This means most Ubuntu users won't notice anything until 20.04 (April 2020) release at the earliest, and do not need to act until 18.04 goes EOL (for non-paying customers) in 2023.

The only people shafted are those currently on 19.04, which will may go EOL before a suitable solution is worked out for Wine/Steam/etc.

the functionality required of a desktop OS, like 32-bit backwards compatibility.

I'd contest that. 32-bit is only required by a very small minority of desktop users, namely those that run proprietary games or other legacy 32-bit x86 stuff.

It never ceases to amaze me how Ubuntu still manages not only to survive but also to still stay relevant enough to be able to keep busting the community's balls, despite it having lost most of its credibility and almost gone bankrupt after the fiasco with Mir.

Because Ubuntu actually delivers what people want? And abandoning Mir was also a decision in the same light, take away resources from what benefits only a minority of users, and invest in what benefits the majority.

In fact, I think the Ubuntu decision to drop 32-bit x86 will be a big step towards deterring from using 32-bit for current and future software builds, benefiting all Linux users not just Ubuntu ones. The last time such a thing happened on a major scale was when Apple refused to support Flash on iOS.

Valve's Plagman has responded:

Steam as it currently exists will be broken on 19.10 unless more work is done on our end. That work seems tractable, but fairly involved; what's unfortunate is that it will take away resources that would otherwise be spent on improving performance and functionality."

https://www.reddit.com/r/linux_gamin...m_medium=web2x

Eh, such as releasing a 64-bit version of Steam I guess?

when there are security considerations to deal with.

I do not think anyone using legacy proprietary x86 32-bit software is concerned about security in that software. If the vendor does not even bother to recompile for 64-bit, the security support is probably not much better.

[oiaohm]

Does it have a significant performance hit, compared to native 32-bit / WoW64 Wine case? Gaming use case is very demanding, and performance degradation is not really an acceptable option, when Wine itself already introduces an overhead in comparison with regular Windows.

Using qemu to get around kernel not having 32 would have quite a performance hit. Now thunking to 64 bit without qemu testing will be required to see if it better or worse. There are particular things that in fact run faster in 64 bit that could cover that thunking overhead.