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

[duby229]

Fine, fair enough - so include its dependencies. My point still stands: there's only a finite mount of 32-bit libraries necessary that need to be ported/maintained on the amd64 repo.

But it can, and because of the choice Canonical made, it might have to.

In what scenario are you an Ubuntu user (using the latest version) and cannot use Flatpak?

That I agree is a real problem. But again... they could just pre-package the necessary libraries.


Um... you do realize that Ubuntu has pretty much already done that, right? They're basically just giving up on it. So, wtf are you talking about?

Sorry dude, but it is not application devs job to handle package management. It -NEVER- will be and -shouldn't- be.

[Weasel]

There is a problem windows kernel is 64 bit. 32 bit drivers are deprecated. So when you are using a 32 bit dx or opengl application on windows you are thunking to 64 bit anyhow for all your input/output. So wine needing 32 bit host libraries is more a development short cut not that high in the required really.

Just shut up about programming topics, you are beyond clueless.

Drivers are either services or part of the kernel. None of which are in the address space of the process. There's no problem here unlike libraries. Callbacks are the biggest offenders anyway.

Hangover is slow as hell for a reason.

[Chugworth]

In the long term, if hypothetically most distros deprecate 32-bit user-space wouldn't it lead to emergence of an x86-32 Linux emulator that can reliably run 32-bit OpenGL apps? What else could it lead to other than an emulator?

(The emulator will take advantage of running 32-bit code natively on the CPU, but that does not negate the fact that it would be an emulator.)

Yes, emulation is the end solution to this. That provides a way to run old software on modern hardware. For all we know, 10 years from now ARM processors might hold a significant chunk of the laptop and desktop market.

[schmidtbag]

Sorry dude, but it is not application devs job to handle package management. It -NEVER- will be and -shouldn't- be.

Note how in this context I'm only referring to closed-source software... For close-source programs, yes, it very much is their job to do this because (as I'm sure everyone here who has used closed-source software in Linux can attest to) using your distro's libraries often don't work with the application if you don't have the right version. This is precisely why so many closed-source programs ship their own libraries.

[jpg44]

Like it or not, there is a vast library of games and so on for win32 and come as 32 bit binaries and it will never be rewritten for some other platform. So to say that Games should be written for a universal platform like progressive web apps is idealistic, its not the situation that we have. Making the games work is important for a lot of desktop users. T

he situation with how Linux desktop users are being mistreated is similar with the disregard for people with old hardware. Desktop users are being left in the dust by people who think you should need some super 15 core computer with 20 GB of ram that is 2 years old and has a narrow list of hardware and software that can run on it. Not everyone has cash burning a hole through their pocket and can run out and spend thousands to buy new hardware because some arrogant developer at a whim decides to kill off support for older hardware or software.

Sure apple may have dropped 32 bit, but Apple is a joke, a tyrannical dictatorship that takes away users choice, forces on people hideously ugly, unuseable fischer price user interfaces, and sells overpriced hardware to schmucks, and the apple userbase tends to be different from people who use Linux. Apple users have stockholm syndrome and seem to enjoy the abuse. Linux should not act like Apple because Linux users are trying to get away from that abuse. People who use Linux want to try to get away from the abuse. Apple is for people that want to spend money on overinflated, overpriced hardware, cell phones that cost $1000 and desktops that cost $2000 or whatever and want to use aggravating and idiotic user interfaces. People on Linux want to use Linux to rehabilitate old hardware that is 10 or 15 years old, want sane user interfaces with task bars, icons, desktops, start menus, overlapping windows and so on, that works well with sane input devices that real people with real work to do use like mouses and keyboards, not some horrid asinine touch interface, and want to actually be able to customize things and choose their own window managers and so on. Linux users still want things to just work and for hardware to work and software to work, which is why legacy hardware support and 32 bit binaries is so critical for us.

[Weasel]

You are a mistake. You have the insolence to tell people what they can and cannot use and with that you can go fück yourself. As well as all the people who've liked your post.

Your the cancer of open source. Instead of trying to cater open source for as many people as possible you actually insist on makin open source an elite club for the selected.

Really go fück yourself.

Couldn't have said it better myself.

[Weasel]

Sure apple may have dropped 32 bit, but Apple is a joke, a tyrannical dictatorship that takes away users choice, forces on people hideously ugly, unuseable fischer price user interfaces, and sells overpriced hardware to schmucks, and the apple userbase tends to be different from people who use Linux. Apple users have stockholm syndrome and seem to enjoy the abuse. Linux should not act like Apple because Linux users are trying to get away from that abuse. People who use Linux want to try to get away from the abuse. Apple is for people that want to spend money on overinflated, overpriced hardware, cell phones that cost $1000 and desktops that cost $2000 or whatever and want to use aggravating and idiotic user interfaces. People on Linux want to use Linux to rehabilitate old hardware that is 10 or 15 years old, want sane user interfaces with task bars, icons, desktops, start menus, overlapping windows and so on, that works well with sane input devices that real people with real work to do use like mouses and keyboards, not some horrid asinine touch interface, and want to actually be able to customize things and choose their own window managers and so on. Linux users still want things to just work and for hardware to work and software to work, which is why legacy hardware support and 32 bit binaries is so critical for us.

You forgot monitor stands that cost $999. Yes, monitor stands. Let that sink in.

[callegar]

As of today, ubuntu builds its own wine packages and currently there are wine packages also for eoan (19.10). I wonder if ubuntu plans to drop them together with the 32-bit libs. Is the plan to ship wine only as a snap?

[JPFSanders]

A lot of the blame for this specific situation should be put on the Linux Foundation rather than Canonical....

Linux Foundation.

Son, there is one thing you need to know and I want to be the one who does tell you.

The Linux Foundation is not what it seems, It is a MS puppet show.

Son give these a read:

http://techrights.org/wiki/index.php/Linux_Foundation

Lovingly, dad.

[duby229]

Note how in this context I'm only referring to closed-source software... For close-source programs, yes, it very much is their job to do this because (as I'm sure everyone here who has used closed-source software in Linux can attest to) using your distro's libraries often don't work with the application if you don't have the right version. This is precisely why so many closed-source programs ship their own libraries.

I don't have no problem with binary apps targeting a separately distributed runtime environment that is kept up to date and maintained, but distributing their own libraries is -always- a mistake. Every -single- time. It's -always- binary apps that distribute their own libraries that break. Usually because the libraries they create are compiled against an old glibc. If glibc had a stable user facing interface, it wouldn't be a problem, but it doesn't and never has and everybody already knows this. As an app developer distributing your own libraries absolutely guarantees that when the glibc you compiled against gets old your app -WILL- break.