[jsheard]

For better or worse it's never been Apples MO to keep software working forever, that's Microsoft's schtick. PPC OSX software is gone, x86-32 OSX software is gone even on hardware that could still run it natively, AArch32 iOS software is gone, and if history is any indication it's only a matter of time before x86-64 OSX software is gone too.

[TaylorAlexander]

One time I had to run a very old version of Eagle CAD on Linux and it turned out that even tho I had a native Linux version, it was easier to run the windows version in wine! I guess stable interfaces have their advantages.

[liontwist]

the community has been joking that win32 is the most stable Linux api

[linguae]

I have a half-joking, half-serious thought: has anyone written a desktop environment for Linux that uses the Win32 API? Since Win32 is much more stable than Qt and GTK, it would be easier to target that API. The side bonus is API compatibility with Windows.

This might not have been viable 25 years ago when KDE and GNOME were in their infancy, but WINE has come a very long way since then. Standardizing on Win32 would eliminate the churn of dealing with Qt and GTK major version revisions.

[aleph_minus_one]

> Standardizing on Win32 would eliminate the churn of dealing with Qt and GTK major version revisions.

What makes it so hard to write a GUI toolkit that is long-term (say for 25 years) backwards compatible. If Microsoft is capable of doing this, why can't open-source developers?

[linguae]

In the Linux desktop world, there is no single entity in control over the entire software stack ranging from the kernel all the way up to the desktop environment. In a typical Linux distribution, you have the Linux kernel (run by Linus Torvalds), various command-line tools written by many different developers and managed by different projects (some of them are part of the GNU Project, but others aren't), some type of display system (this used to be solely X11, but Wayland is growing in popularity these days), one or more GUI toolkits (Qt, GTK, some custom ones), and a desktop environment (typically KDE or GNOME, but others exist). The goal of a Linux distribution is to take these disparate parts and present a coherent system to the user.

The problem, though, is that because the Linux desktop is made up of disparate parts from separate teams that have separate, often competing visions for their roles in the Linux ecosystem, often major changes are made with little regard to how they affect the system as a whole. This is the essence of the lack of control over the entire software stack. Thus, the developers of X11/Wayland, Qt, GTK, and other infrastructure can make breaking changes, and application developers relying on those subsystems have to either adapt or lobby for forks. Thus, the churn.

By comparison, Microsoft is in full control over Windows, and Apple is in full control over macOS. Even the BSDs are in full control over their base systems (for example, OpenBSD isn't just a kernel; the OpenBSD team also has control over the command-line tools that make up the base system), though I'm not aware of any BSD (besides macOS) that is in full control over GUI environments. It's not to say there is no churn in these environments; indeed, macOS does not prioritize backwards compatibility like Windows does and thus there's some churn macOS developers need to deal with in order to keep up with the latest releases. But there seems to be a lot of churn at the GUI level in the Linux desktop ecosystem.

[fsflover]

ReactOS comes to mind, although it's not Linux.

[hulitu]

> has anyone written a desktop environment for Linux that uses the Win32 API?

No, but window managers who use Xt, Xaw or Motif are ok.

[IshKebab]

Linux (the ecosystem; not necessarily the kernel) is actively hostile to binary software.

[nullpoint420]

It baffles me as to why. I think it’s hilarious how Linus is so careful to not break user space (for good reason) and all the user space libraries break every week.

[Daishiman]

Because every distro runs it’s compilers with a variety of flags and safety features and library versions and ABI quirks that make supporting stable ABIs a pain in the butt.

[6SixTy]

Distribution maintainers pretty much do whatever they want with the OS level ABI. That on top of whatever those user space libraries want to do anyways makes native application ABI stability basically impossible.

[nullpoint420]

Again, how do Windows and macOS (to an extent) solve this? It’s possible, just not incentivized. Show me the incentives and I’ll show you the outcomes.

[IshKebab]

I think the main thing is that it's common for apps to bundle their dependencies. The default for Linux is to use the system libraries for everything - not just glibc but also things like zlib, libpng, etc. As a result you have to go to significant extra effort to make a portable binary app, e.g. linking against musl.

That's one of the attractions of Go, and to a lesser extent Rust; it's way less work than C to get a portable binary.

I think 90% of the problems I've encountered are due to glibc. They could easily fix all of them by adding a GCC flag that would allow you to compile against old glibc versions.

They'll never do that though because they are ideologically opposed to it.

[JackSlateur]

Of course

Source software is the way to go (compiled specifically for one version of thé targeted OS, you sont have many issue)

Distribution opaque binaries are indeed not the best way, even if you can do it easily with static linking

[aseipp]

Back when IDA Pro for Linux & macOS was finally released, they decided to make every OS a separate license purchase. The net result of this was that every single person I knew who used it just kept buying Windows licenses and using it under WINE when they wanted to use it on their other computers.

[adamc]

You make a good point. It was kind of the breaking point for me when Apple killed 32-bit executables, because it meant even old steam stuff couldn't run.

But that's a casual consumer viewpoint. It's valid to buy them if they solve your problems in the here-and-now. (I used one for a year at work and it was a bad experience, but a lot of that was having x86 libraries I had to use, so... Bad choice for here-and-now.)

[bsimpson]

Interesting juxtaposition against yesterday's front page: Valve updates Half Life 2 for 25th Anniversary.

If the requirements are still accurate, it will run on XP with 512MB RAM.

[shantara]

In addition to this, Steam provides an option for developers to expose the older game versions to the players, which Valve themselves make an active use of. So if you have a specific old mod that’s not compatible with the new update, or don’t want to deal with the update in a middle of playthrough, you don’t have to upgrade

[aspenmayer]

Maintaining the build artifacts and pipelines and testing backward compatibility for a long-lived project like HL2 must be pretty difficult, I would think? That’s a great example and counterpoint.

[TimTheTinker]

I think it's likely x86-64 support (via Rosetta) will continue for quite some time.

Rosetta is giving Apple a competitive advantage by being able to run x86-64 binaries in VMs (Linux or maybe even Windows) at near-native speeds. This enables doing cool things like running MS SQL Server in a Docker container - which enables developing on a full local .NET stack on a Mac.

[hu3]

Maybe I'm missing something but I run SQL Server in Docker under Windows WSL2 at near native speed.

What's the competitive advantage here?

[adamc]

Having tried both, I would in fact say that WSL is a huge advantage for Windows over the Mac in many cases. Sure, the Mac is a *Nix, but there are lots of small differences from Linux that cause issues. WSL runs very, very well.

[easton]

I suppose allowing developers targeting x86_64 Linux to still use Macs and the power efficiency of ARM CPUs, since I don’t think (maybe wrong) that ARM Windows machines support emulation inside WSL.

But that’s more feature parity with x86 Windows machines, not an advantage.

[TimTheTinker]

How is feature parity not an advantage? If it were to be removed, the lack of it would be a disadvantage.

[PittleyDunkin]

Using macos rather than windows.

[jsheard]

Perhaps there will be an intermediate step where they drop support for x86-64 executables, but retain support for x86-64 virtualization. That would still let Apple slim down the macOS system frameworks to a single architecture like they did previously when they dropped the x86-32 frameworks.

[wtallis]

There is no support for x86-64 virtualization on ARM Macs. Do you mean dropping support for Rosetta for macOS apps but keeping support for Rosetta for Linux VMs (which run ARM Linux kernels and use Rosetta to support x86 userspace software)?

[dunham]

Yeah, that's just their MO. I think it's easier to run old windows games on a mac than to run old mac games.

And architecture aside, at one point I had to install an old version of iWork (I thin it was '09) to update a file so the latest iWork could read it. They had code on hand that could read those older files, but decided not to integrate it. They don't prioritize backwards compatibility.

[thfuran]

It's definitely for the worse that they've gone so far in that direction.