Criticisms of his post aside.
Isn't it unfortunate, the absolute degree everything legacy is at least in some way tethered to windows. If only there had been an open alternative, it would allow huge communities to emerge keeping very old software/games working indefinitely. Not that linux was even remotely close to being usable even only twenty years ago. Relying on a giants benevolence is never going to work in the long run. Their contemporary direction is only a function of what side of the bed theyd like to turn on today.
How would an open operating system fix a bug caused by sloppy game developers? I don't think anyone would think "let's not optimize the (equivalent of) critical sections in our operating system so that we don't break GTA", unless you're suggesting providing 100s of different implementations of different parts of the operating system that people can choose from to run a specific game, which I don't think is viable either. Patching individual games is far easier and is actually viable, which is precisely what GOG (Good Old Games) successfully does on a significantly large scale.
If anything, what Microsoft was way, way better at was finding and working around these types of problems in the OS. Many developers have a more idealistic and less pragmatic approach instead of empathizing with their users: "it's the program's fault, why should we deal with it?"
My sister who was at the time a professor had just moved to a Mac. There was some major statistics app that broke on an OS Update. She contacted the stats company and they said that Apple broke them. She contacted Apple and they said the stats company was given notice and access to beta builds. She was just stuck for months with it not working - and eventually loved back to Windows. She says it’s ugly, but it works.
Though at least back then, they provided backward-compatibility modes for old software. You know, back when the expected service lifetime of your Mac was longer than that of your dog.
> Many developers have a more idealistic and less pragmatic approach instead of empathizing with their users: "it's the program's fault, why should we deal with it?"
In the retro-games emulation scene there exist quite some people who write binary patches for popular retro games to fix such bugs. Perhaps this approach (and the necessary skills for it) should become more popular outside the retro-games emulation scene.
> unless you're suggesting providing 100s of different implementations of different parts of the operating system that people can choose from to run a specific game
> it would allow huge communities to emerge keeping very old software/games working indefinitely.
That's a completely backwards take though. Windows is practically the only platform in the world that cares about backwards compatibility. On Windows you can run a 20 year old executable and you've got pretty good chance it runs. With Linux operating systems you have no idea if something compiled on the last LTS release runs on the next one.
This is one of the few issues where having a private company control the entire stack and providing a stable ABI for decades is actually a benefit, to the point where your target if you want to build games on linux is...Win32 (https://blog.hiler.eu/win32-the-only-stable-abi/)
> it would allow huge communities to emerge keeping very old software/games working indefinitely
The Linux community already stumbles at this and needs Windows to help it out. "Win32 is the only stable ABI on Linux" has been said so many times it isn't a joke any more. Keep in mind that the OS being open doesn't make the games open. Wine is possible because of Win32's die-hard commitment to long-term binary compatibility. I'm not so sure we're in a bad situation here. The Linux userspace has never had this degree of backwards binary compatibility. The kernel doesn't break userspace but userspace breaks itself all the time.
Linux userspace gets lots of other benefits from this rapid-iteration approach that doesn't concern itself with literally decades of binary compatibility, but keeping old games running indefinitely isn't one of them.
> Not that linux was even remotely close to being usable even only twenty years ago.
Running Linux on regular consumer hardware in 2005 was not really any harder than it is today. In fact, many of the same problems still exist! GPU drivers and janky wifi and power-saving modes, same shit, different decade.
There's Steam Deck now, and Android, but those are still quite proprietary driven by single companies, so I'm not really sure they fit what you mean about an open alternative.
> Not that linux was even remotely close to being usable even only twenty years ago
I've been using Linux only as a desktop for 30 years, so that's a strange comment. For sure games and other software that was written to run on Windows exclusively, ran best on Windows (who could have predicted it!). But as a desktop, Linux has been usable for many decades.
It works for some domains, but, games ain't the only thing. There is a lot of business software and "technical" software (for controlling manufacturing machines or whatever), which runs on Windows only, as it is the "default" platform. And those applications are low quality special purposes software, nobody knows much about ...
> Windows is actually excellent at maintain backwards compatibility.
Rather: Windows is actually excellent at maintain backwards compatibility for binary programs.
There exist lots of other backwards-compatibility topics like
- being backwards-compatible in the user interface (in a business setting, ensuring that the business-critical applications still run is a problem of the IT, but if the user interface changes, people will complain. I just say "Windows 8" or "Office ribbons" (when they were introduced)). I would for example claim that very specifically for the shell interface, the GNU/Linux crowd cares a lot more about user-interface backwards compatibility than what Microsoft does.
- being backwards-compatible in the hardware requirements (i.e. "will it still run on an old computer"). I just want to mention the drama around Windows 11 because it doesn't run on still actively used hardware so that Microsoft cannot force the update on all Windows 10 users, but on the other hand wants to terminate the support for Windows 10.
> I would for example claim that very specifically for the shell interface, the GNU/Linux crowd cares a lot more about user-interface backwards compatibility than what Microsoft does.
Maybe if you ignore things like systemd radically changing how services and init systems work. Massive changes with Network Manager and firewalld compared to iptables. Gnome today looks pretty much nothing like it did when I first started using Linux. Now we install software through snaps and what not, or move from yum to dnf or other package managers.
Using Linux today feels very different than it did 20 years ago. I bet most scrips I wrote for Ubuntu over 20 years ago would fail to execute today on a fresh modern install.
> cmd.exe is only some mostly deprecated tool that was only used by power-users to do some specific tasks.
And bash isn't "some mostly deprecated tool that was only used by power-users"? Think people are mostly using bash for their interface on their steam decks and Android phones and what not? Do most people boot Ubuntu straight into text mode or immediately launch a DE? Grandma using lynx to browse Facebook?
Explorer is a desktop environment. Which, yes, the desktop environment landscape in Linux these days looks pretty different from what was around 20 or so years ago.
You're constantly moving the goal posts and comparing apples and oranges here. Originally saying GNU/Linux user interfaces, then shifted to only text shells, and then comparing those text shells to entire desktop environments while ignoring the forest of constantly changing desktop environments of Linux.
And even then, most of those bat scrips I wrote since XP that only use system tools and commands will largely all still run and do the same thing today. I can't say the same for the same time frame on most major Linux distros that have changed out large parts of their internal tooling.
Also, Windows containers are a thing (not that I’ve ever used them). Shouldn’t it be possible to containerize old games bundled with versions of win32 libraries that were stable when the game was released? Then the games could be run in perpetuity so long as the low-level interfaces needed by the container runtime is maintained.
Windows containers are definitely a thing, but I think the implementation is at the "how to draw an owl: draw two circles..." stage and needs a lot of "...now draw the rest of the owl" in terms of being usable to the general consumer audience where their eyes are likely to gloss over if you say "go and install docker desktop". Having a simple method to maintain old software as usable would be beneficial, but it's hard to see what organization would want to do work to make it happen.
Legacy compatibility is one of windows biggest strong points, neatly containing 'old windows' and providing the best experience for it would solve the puzzle of why users should stick with windows if MS did want to prune the core OS without giving users reasons to move away.
People say this but I really don't consider it to be as true as it once was. I can't even move my taskbar to the side in windows 11 without installing a third-party program to patch explorer.
> Isn't it unfortunate, the absolute degree everything legacy is at least in some way tethered to windows. If only there had been an open alternative, it would allow huge communities to emerge keeping very old software/games working indefinitely.
Every time I've tried it, from 2007 to now, it's been a buggy hunk of crap. I normally try not to disparage peoples software projects, but I really don't get ReactOS. I tried it again actually just a few weeks ago. It's barely usable. You'll have far fewer problems just using Wine with Linux.
That's the thing with these kinds of projects that aim to run vast libraries of preexisting software — they're crap for a long, long time, until suddenly there's enough compatibility that hey, it's actually usable. The time vs usability graph for them is very non-linear.
Wine was "garbage" for decades as well. For a long time, it wouldn't do a satisfactory job of running anything but simplest win32 apps.
Same for Ruffle, the open source flash player, but it got to that point much quicker because the API surface is orders of magnitude smaller.
That can already be done with Proton for anyone who wants to. But few, if any, are going to step up for the more obscure games. Relying on the benevolence of volunteers is never going to work in the long run either.
