OpenMandriva Is Also Making Plans To Move Away From 32-Bit Support

[duby229]

If your software can't be recompiled to 64bits without fixing it, then it was shit.

I mean, ok, a lot of commercial software is shit like that, but I'm not blaming the architecture change for that.

You're fucking moron. At minimum, long longs need to be changed to longs. That's bare minimum. Almost -all- code needs to have some case modifications to get it to compile for both 32bit and 64bit x86. They -aren't- totally compatible. Plus there is still -HUGE- amounts of x86 asm in production as we speak. And that's a true nightmare.

You can't call something shit just because it uses the features of the architecture it was -designed- for you stupid idiot.

[the_scx]

Like how my 2012 Westmere system with an RX 580 plays Hitman 2 almost as well on Linux as it does on Windows or how Dirt Rally 2 worked on release with very respectable benchmarks or how the Wolfenstein games work well? I'll admit the multiplayer aspect could be better in regards to anti-cheat and some games don't run at their full potential, but a lot of modern stuff actually does work pretty damn well...

I was referring to dropping support for multiarch in Ubuntu 19.10+. This will be a huge pain in the ass, especially when it comes to GOG games, and even worse for Humble Bundle DRM-Free titles. Some of them are barely supported today on modern distros, but this is another story. And Windows 10 doesn't have any problem with games written for Windows 7. You see the difference, right?
And when it comes to WINE, let's say that compatibility with Windows is far from being perfect. There is a myth in Linux community that WINE handles old games better than Windows 7/8.1/10. Well, unfortunately it isn't true.
First of all, WINE support for Windows 9x software and DirectX 1-8 isn't very well. You have a better chance of running patched game for Windows XP or 7 while using dgVoodoo 2 on a DVXK setup, than when you try to run the original game in Windows 98 mode.
And even compatibility with Windows XP is not perfect. I would say that support for Direct3D 9 is quite solid, but there are other things that are not so polished, like for example video codecs support (I had a problem Indeo Video Codec, but it was a while ago, so I do not know if it is still relevant) or network stuff.
The problem is that the main development is now focused on Windows 7+, so we even have some regressions with older stuff. I can believe that there are some titles that may work better on WINE than Windows 7-10, but usually Windows wins here.

Most of my Wine issues come from game modding and things on Windows that rely on scripts...I'd love to be able to patch the Windows version of FFVII on Linux...that's one of the few reasons I have a Windows install.

Most of my WINE issues:
- Crashing or stop working after Alt-Tabbing (or rather while trying return to the game).
- Crashing while playing intros or cut scenes (issue with video codecs).
- Videos not working (blank screen).
- Random crashing.
- Networking not working.
- Incompatibility with anti-cheat software.
- Sound issues: audio glitches either all the time or after some time.
- Graphics artifacts.
- Unable to set proper resolution.
- Unable to return native resolution after quitting the game.
- Controls not working.
- Doesn't work with some copy protection systems.
- Poor performance. Sometimes externally low, like the DirectX 7-8 game from around 2000 year that was unable to reach 30 FPS in some scenes on GeForce GTX 750 Ti.
- Not working at all.
- Regressions.
Some errors occurred only on the NVIDIA graphics card, others on the Intel GPU.

Don't get me wrong. I am not saying that WINE is completely useless. To be honest, I am quite impressive how well it works. But at the same time, I am a little bit disappointed that sometimes it doesn't. It still ~50% chance that something will work or not. I finished The Spy Who Shots me without any noticeable issues and Hitman: Blood Money with only minors issues. I also spent a lot of time in Tony Hawk Pro Skater 2 as well as in many indie games (mainly based on Unity, GameMaker or RenPy engine). However, if I good remember, I was unable to run Air Conflicts: Secret Wars, Kane and Lynch: Dead Men and El Matador. Sometimes bugs were really strange. For example, in Tony Hawk Pro Skater 4 I was unable to control character at all, but there was no such issue in the menu. In GTA 2 I have experienced random crashing. Of course there were more cases, but I do not want to discuss them all here.

[skeevy420]

I doubt it. Currently we see that modern Linux can not even handle native software from this decade...

Like how my 2012 Westmere system with an RX 580 plays Hitman 2 almost as well on Linux as it does on Windows or how Dirt Rally 2 worked on release with very respectable benchmarks or how the Wolfenstein games work well? I'll admit the multiplayer aspect could be better in regards to anti-cheat and some games don't run at their full potential, but a lot of modern stuff actually does work pretty damn well...

Most of my Wine issues come from game modding and things on Windows that rely on scripts...I'd love to be able to patch the Windows version of FFVII on Linux...that's one of the few reasons I have a Windows install.

[the_scx]

If your software can't be recompiled to 64bits without fixing it, then it was shit.

I mean, ok, a lot of commercial software is shit like that, but I'm not blaming the architecture change for that.

Then all open source Linux software are a piece of sh*t. I can give you a lot of examples, where it was necessary to make some fixes to build something:
- To support 64-bit arches.
- To support another ISA.
- To support different bit order (endianness).
- To support different compiler (GCC/G++ → LLVM/Clang)
- To support a new version of the current compiler (e.g. GCC 4 → GCC 7)
- To support a new release of libstdc++, Boost, ICU, etc.
- To deal with new hardening flags.
And I don't even mention the API breaks.

It is not about some examples from the past. Such problems appear constantly. Of course, they are corrected, but new ones are discovered over and over. Just look at RISC-V - a lot of projects need some patches here.
The reality is that complex software will always contain bugs. This can not be avoided. You just can't say that something that was written 20 years ago is sh*t because today it is impossible to build it on a new system without some patches. Following this reasoning, every software would be sh*t, because sooner or later you will find some bug in it.
And games are finished works, just like movies. They will not be improved indefinitely. They are goods of culture, and you have to accept them as they are.

[the_scx]

But, yeah, I agree with all of that. It's going to be really interesting when Linux distributions on random architectures are able to offer just as well or better (legacy) Windows support than Windows itself.

I doubt it. Currently we see that modern Linux can not even handle native software from this decade...

[the_scx]

32 bit have to go sometime, so the line have to be drawn sooner or later.

I think that we should just abandon Linux support on bare metal. It is an ancient system, with kernel written in C (Rust FTW!) and based on UNIX from 1969 (not by source code, but by philosophy). If you have to run some legacy POSIX applications, you can do this on WSL under Windows 10. In long term, everyone should switch to Windows Lite based on WCOS (Windows Core OS). Modern UWP and PWA apps are all you need! We should get rid of this POSIX crap, and the sooner the better!
Insane? Of course! But no more insane than what you are suggesting here.
Microsoft tried to sell Windows RT without Win32 support and they failed. That's why they put a lot of effort into providing support for transparent x86 emulation in Windows 10 on ARM. They know that without it they have absolutely no chance in this market.

What I do not understand is the panic attack some people are having, like if on the day of Ubuntu 19.10 launch suddenly their 32 bit software will stop working, even if they do not update, Y2K stile. My point is, if you really need it, just use a stable release of some distro. For exemple, Ubuntu 18.04 will receive updates until 2028!

I understand that some have a need to be on the bleeding edge for a specific reason, but the rest? Is just a compunction to be there. I now because I had it until the day I realized that all the hassle didn't worth it. Now I sail on LTS releases and couldn't be more relieved.

Public support ends in April 2023. Date 2028 applies to paid support - ESM (Extended Security Maintenance).
Have you ever tried to use Linux distribution on desktop 5 years after the release? I did. And believe me, this is not a pleasant experience.
You know what? Just try to create package of Flatpak 1.0 for Ubuntu 14.04 LTS. It was released before the end of public support for this distribution (April 2019). What's more, Ubuntu 14.04 LTS is still supported via ESM.

https://github.com/flatpak/flatpak/issues/175#issuecomment-249844529

https://github.com/flatpak/flatpak/issues/956

Just try and then tell me if it was easy. And if you fail, at least you understand why using old Ubuntu is a bad idea.

Oh, and one more thing. If you think that 32-bit support is just about some legacy software, you are wrong.

When Windows began targeting 64-bit architectures, Microsoft decided to include a compatibility layer to support their massive universe of 32-bit applications. This kind of subcomponent, nicknamed WoW64 (for Windows on Windows 64-bit), is also implemented in Wine to solve the exact same problem.
64-bit Wine built without 32-bit support will not be able to run ANY 32-bit applications, which most Windows binaries are. Even many 64-bit programs still include 32-bit components!

Many 64-bit applications still use either a 32-bit installer or some 32-bit components. In comparison 64-bit Windows will support 32-bit (probably) forever.

Make that almost all applications. It's very unusual for a program to have a 64-bit installer, because it won't be able to control what happens when a user runs the installer on 32-bit Windows.

In practice, the only cases where 64-bit only wine will be useful are when 64-bit applications are packaged some other way (such as a .zip, Steam Play, or packaging specifically for Wine) or for running Wine builtins like msidb.

Nor do I see much point in packaging a 64-bit-only Wine on our end. It's such a niche case for 64-bit-only Wine to be useful at all.

[Luke_Wolf]

Structure, like what you get with a struct or class keywords.

Sizes of pointers changes, therefore size of every structure containing a pointer changes. Also, size of every virtual class changes (due to pointer to virtual table).

Edit: Ah I forgot about x32. Would it work? Let me think...

If you're a programmer who has to care about struct sizes for being able to compile to 64-bit then you deserve every problem that comes your way for hardcoding it rather than using the sizeof operator in your malloc or just using C++ and the new keyword (or the relevant smart point initializer). Fix your code.

[starshipeleven]

I'm not sure that I'm following you.

you didn't argue your point much, you just said what you would have to do to avoid perceived issues.

[starshipeleven]

Sizes of pointers changes, therefore size of every structure containing a pointer changes. Also, size of every virtual class changes (due to pointer to virtual table).

And this is an issue because?
Don't tell me you were fapping with pointers (doing shenanigans to alter the pointer address) in non-performance-critical code.

Most of the "issues" people face when migrating to 64bit are actually bad coding.

[starshipeleven]

Thanks for the argumented and polite approach.

It's not like you are providing much in the way of argument either. You're just verbosely describing a reaction, not why you should react.