Hacker News Reader

Comment by coldpie | Hacker News Reader

The change Ubuntu is proposing is far less harsh than what macOS is doing. Unlike macOS, Ubuntu will still run 32-bit processes, you just have to provide all of the userspace libraries. Applications like Steam for Linux already do this for binary compatibility reasons, so their usecase won't change much.

Wine's official Ubuntu packages currently rely on the OS to provide these userspace libraries. They would "only" need to change to also build and ship the rest of the libraries, instead of relying on the OS to provide them. Meanwhile on macOS, you can't even run 32-bit binaries, working around that is a much, much larger task.

View on HN

Remember, though, that the hardware-specific OpenGL library for the user's specific graphics hardware is also a userspace library that has to be provided in a 32-bit version. Even Steam doesn't bother shipping that because it's just not feasible. Without at least some library support from distros it's just not practical to continue 32-bit compatibility.

You can have a little 64 bit process which communicates with the 32 bit process with a named pipe, and acts as a proxy and makes all the syscalls and loads and calls the 64 bit libraries and returns the responses.

Obviously it adds extra context switches and will reduce performance, but if you're running ancient legacy 32 bit code, you can probably afford that.

I believe this is how things like 32lives [1] work.

32/64 bit bridges are really critical when you rely on abandonware, like in media production. I know the classic response is "don't use abandonware" but a lot of that stuff is the equivalent of vintage amplifiers/effects - it has a particular sound to it that doesn't have an equivalent.

[1] https://www.soundradix.com/products/32-lives/

The performance impact makes this a no-go for graphics drivers. Lots of games are 32 bits, even recent ones, because they don't need the large address space and don't want to pay the overhead of 64 bits.

Really, this is an incredibly stupid move that has a high likelihood of killing Linux gaming on Ubuntu.

I wonder why Wine doesn't have those libraries on standby. I can understand keeping installer/total install size and footprint down for any application but especially emulation which is already complex and going to push hardware. If Wine includes the right components, what performance hit may be suffered? Or maybe I have this wrong and it won't really matter.

Yeah, it doesn't really matter as wine would just have to load the 32 bit libraries from a different location (say, /usr/lib/wine/lib32 instead of /usr/lib32).

Also, Wine is not that kind of emulator. It provides windows-compatibile libraries but does not do CPU emulation so there's no real significant performance hit. [0]

[0]: https://superuser.com/a/14600

> [...] but especially emulation which is already complex and going to push hardware.

Wine stands for "Wine Is Not an Emulator". It's a compatibility layer.

I doubt packaging graphics drivers is feasible for Wine, and those are target important for games...

Reply on news.ycombinator.com