There's work ongoing in Wine that will allow 32-bit applications and libraries to be able to call 64-bit host libraries. Hopefully this means that we won't have to mess around with multilib for much longer :)

https://www.winehq.org/announce/8.0

I wouldn't call Apple's decision a mistake, they knew exactly what they were doing and their long term plan required it. The relative insignificant size of user base that still needs 32 bit support is dwarfed by all devices that will never need that. Apple has always been quick to drop backward compatibility to support innovation both at hardware and software. They dropped floppy support and CD/DVD support eons before the rest of the desktop market. Since they own the complete stack at this point and with everything SoC, at some point they will start saving die space not wasted on 32 bit support. To get there however requires they start pushing the software first.

I recently took the list of the commercial software that supported MacOS that I’ve paid for over the years and checked current platform compatibility.

Twice as many packages run under Linux than under MacOS, specifically because of the lack of 32 bit support.

While that may be tragic, it still is the intentional effect and hardly a mistake. Apple focusing on its $250B iPhone market over its < $50B Mac market very much makes sense. When they removed 32 bit support we might have guessed at Apple Silicon on the desktop, and lo and behold that did come to pass. The Intel to ARM transition was much smoother than the PowerPC to Intel move in part because of 2 vs 4 versions in the Universal Binaries. I am going to go out on a limb here and say that Apple was also aware of ARMs forthcoming complete removal of AArch32.

Are you talking about games? Or old versions of apps?

I know of very few actively-maintained 32-bit Mac applications that didn’t make it to 64-bit: MathType and AccountEdge are the ones I remember right now.

I mean to not have 32 bit support by default makes sense. It wastes disk space for nothing. On ArchLinux for example to have 32 bit support you have to enable the multilib repo, that makes sense because in most installations you don't need it.

Plus 32 bit software can still run if it's stacically linked or run inside a container. The only thing that doens't ship is the dynamic libraries for 32 bit executables to run.

It's not installed by default so it's not wasting space if you don't use it.

It does get installed if you want to play games on Linux, though because computer games will require 32 bit libraries for many years to come.

I think they have something a bit like a container built into Steam: https://github.com/ValveSoftware/steam-runtime

Steam definitely can’t run 32 bit games under current MacOS. (Most of those games run under Linux Steam though; I’m hoping Asahi gets an installer working for my 16” M2 soon).

As I understand it, in Apple’s case 32-bit support was also negatively impacting development of Cocoa/AppKit due to some Objective-C technicalities.

I think probably the right way to handle 32-bit compat is well-integrated virtualization ala Classic Mode from OS X’s early days. When the user tries to run a 32-bit binary, boot up a minimal old copy of the host OS and run it there. It’s not as nice as running it directly, but I think that’s fine; it gently pushes devs to bring their antiquated software into the modern era while allowing users to continue to run it and keeps OS development unshackled from the past.

I thought exactly the opposite. Why keep all the old clutter around just for some edge cases that can easily be resolved by virtualization?

Desktop linux has finally found a niche where it can actually compete with Windows - gaming - and the first thing distro developers and some users demand is changes that will make it much worse for that purpose. Require more hoops to jump through. Reduce compatibility. Reduce performance. All for the sake of "muh purity".

There is some serious aversion to providing users what they want in the Linux world.

If Steam doesn't work on Ubuntu, Ubuntu may as well kill off what remains of their consumer desktop product. Barely anyone uses Linux at all, and 9f the few people that do a significant amount of people like to play a video game on their computers every once in a while. Based on the Steam hardware survey and the number of Steam users, I'd estimate about 8 million people would suddenly lose the ability to play games.

Many of them would go back to Windows. Others would move to another Linux distro. Either way, Ubuntu would make a lot of people mad.

Steam works out-of-the-box in Fedora Silverblue, via Flathub.

Ubuntu avoids Flatpak for strategic reasons, which is a valid choice that might make sense for developers, but it also makes Ubuntu less easy-to-use for people who just want to use their computer.

What solution does Flatpak provide, other than the fact the x86 files are now in a special hidden directory? Someone still needs to build all the 32 bit dependencies for org.freedesktop.Platform.Compat.i386.

I suppose Ubuntu could stop packaging these files if they distributed all 32 bit software over snap or Flatpak, but I don't think this solves as many problems as removing x86 multiarch would create.

Meh, why not use Docker for that?

Between a docker or a snap I prefer snap, something simple to package a simple snap.

Whether it is easier to package for snap is debatable. Building docker images is a much more widespread and well established workflow.

I thought that most games run under Proton? Wouldn't Proton eventually adopt WoW64, eliminating the need for 32-bit executables on the host? https://www.winehq.org/announce/8.0

(Threads on x86-64 Linux can freely switch between 32-bit and 64-bit mode.)

Wine is making excellent progress, but you still need specific versions of Proton/Wine for specific applications and games. I don't think we'll be free of 32 bit libraries just yet.

It'll happen eventually, but I think we've still got a few years of multiarch ahead of us.

]barely anyone uses Linux at all

The steam console runs Linux. Android runs a Linux.

Fair enough, Android has actual market share. It's rarely considered "Linux" in this context though.

The Steam Deck is a device serving a few million in a market of billions. The Switch outsold the Deck ten to one, with the Switch being an old console and the Deck in its release year.

Even with Steam Deck included in the survey, about 2% of Steam users (which is a subset of the gaming market) use Linux.

It was clear from the context that he was talking about traditional Linux desktops with Gnome, KDE etc; not systems that happen to use the Linux kernel as a base but are otherwise completely different.

(That's the case for Android at least; I'm not sure about the Steam Deck.)

Android could swap out Linux for some other kernel (e.g. Fuchsia) relatively easily and users wouldn't notice. Google already did that with the Nest Hub.

> (That's the case for Android at least; I'm not sure about the Steam Deck.)

AFAIK, the Steam Deck is a traditional Linux desktop (KDE), which automatically runs the Steam launcher (in full-screen Big Picture mode) by default (but you can easily exit it and go back to the normal desktop if you want).

I would love to see another competitor, but fuchsia is not there yet.

It is simpler for when you have minimal hardware, but phones are no longer minimal.

Because lot of recent desktop linux adoption is being driven by Steam and its huge library of Linux-compatible games.

I wonder though, whether with GeForce (etc), streaming games from the cloud, the local OS becomes even less important after all. Even a MacBook could be a decent gaming laptop (the hardware is already a superb gaming laptop, just apple keeps the software crippled).