> this hobbyist toy. Linux is fundamentally not ready for anyone who has needs more than a Chromebook

Wow, piss right off you to you, too.

Linux is ready for me, and has been for decades. By your logic, I need nothing but a Chromebook.

Linux is imperfect, like you, but it's never been an ass.

I’ve used Linux since 2011; I know all about it; and I would recommend it to nobody because the community can hear no criticism, bear no criticism, and self-rationalizes everything. Sometimes it takes a bold stance to make a point against one of the most toxic, delusional, and self-righteous communities online.

For my part, I’m back on Windows and Mac. Screw the community’s arrogance more than the project. The community, as even the comments here show, does not deserve a victory.

I think it’s clear that today’s “desktop Linux” distributions are not what you want. That’s ok. Your criticisms come from the point of view of a usage that is poorly supported.

Android is perhaps the closest to what you seem to want, although even it is much more aggressive about deprecating APIs, ABIs, and features than Windows.

The is no Linux distribution today that even attempts to deliver the interface stability you appear to want. And given the development model and business structures involved, I think it’s unlikely there ever will be.

You, and the many computer users like you, will probably never have a suitable Linux distribution. That’s an unfortunate reality. It’s not your fault: what you want is reasonable, but Linux isn’t set up to deliver it.

> …the community can hear no criticism, bear no criticism, and self-rationalizes everything. Sometimes it takes a bold stance to make a point against one of the most toxic, delusional, and self-righteous communities online.

if one’s “criticism” is snarky or just plain needlessly rude, one shouldn’t be surprised when they receive the same in return, this is extremely basic human behavior. very very basic.

we all learn this in like elementary school, if you’re rude, people will treat you like a rude person. it’s not shocking and it’s not unexpected. its extremely basic social shit learned by even small children.

Which community can you walk into telling everyone that everything they care about is shit and they are shit and will never make it, and they will take it productively?

I Certainly admit that some Linux users are heavily in denial about linux's flaws, and don't take criticisms healthily, but this is a trait in humanity, not just in Linux users.

If your version of diplomacy is starting off a meeting with urinating on their flag, don't say diplomacy never works because no other countries can take criticism.

> It can be a miracle, and yet still not be good enough.

"Good enough" is highly subjective. You're entitled to your opinion, of course, but millions of people also think otherwise.

> Even as a business user, knowing that if I build an app and it probably won’t work in 5 years, is all I need to know about this hobbyist toy.

That ultimately depends on your tech stack and app features, much more than your OS. If you build a statically linked ELF binary that runs on the command line, chances are it will continue to work decades from now. If, OTOH, your app depends on a specific version of a GUI toolkit or some esoteric libraries, you might run into issues in the future. This is the same on any other OS. Microsoft does a commendable job at maintaining backwards compatibility for apps written in their supported stacks, but step outside of this and you'll experience problems. Same for macOS to a lesser extent (Carbon -> Cocoa, etc.).

> “Good enough" is highly subjective. You're entitled to your opinion, of course, but millions of people also think otherwise.

Ironically, I might as well point out that billions of people think otherwise of Linux. In some countries, a few trees is “good enough” as a bridge. The IRS, of course, says COBOL is “good enough” to use as a web backend for the moment.

The weirdest thing is how people complain that engineering is a race of the bottom. Scarcely a thread goes by here without a tragedy of the commons reference. Yet inexplicably, business executives are terrified cowards when it involves free software. This of course makes no sense; you can’t have both. Either the complaints are wrong, or Linux is in fact unsuitable for purpose.

> Microsoft does a commendable job at maintaining backwards compatibility for apps written in their supported stacks, but step outside of this and you'll experience problems

Oregon Trail, a game made for Windows 95, still runs on Windows 11. (Edit for below complaint, as I’m posting too fast: You need all the DLLs that came with it on the original CD in the same folder as the EXE.)

Try installing and running any Linux app, be it even GNOME Chess, from four years ago. See how it goes. Consider my allegory of the sand skyscraper.

On that note, the Carbon to Cocoa transition mostly wrapped up a decade ago, and was completed by the majority of apps two decades ago. Try installing a Linux program from 2005 with a UI made in any toolkit of your choice.

The Linux community chases trends and kills APIs more often than Google.

> I might as well point out that billions of people think otherwise of Linux.

These same billions, sans a very small fraction, don't even have "operating system" in their vocabulary. And as far as they are concerned, Chrome browser on one operating system is just as good as Chrome/Chromium on another operating system.

> Try installing a Linux program from 2005 with a UI made in any toolkit of your choice.

Personally I would not have difficulty doing this with containers. But there is no reason to do this at all. No sane and sober person wants this.

> Oregon Trail, a game made for Windows 95, still runs on Windows 11

Fatal error: MSVCRT70.DLL could not be found.

But that's easy enough to fix, right? Just dig through Windows's package manager (sorry, I meant MSDN) trying to guess the right vcredist, and try a few and hope for the best.

The Visual C++ .NET 2002 runtime shipped with Windows 95?

To be fair, I've seen plenty of commercial Windows software ship over the years without runtime components required on the original supported OS (or with required redistributable components that had to be separately installed from the distribution CD-ROM for no well-explained reason).

Alternatively, look it up by reading winetricks’ source code. Wait, would that be cheating considering that winetricks is a UNIX tool? Linux and UNIX systems in general are supposed to be harder, not easier, in comparison to Windows, right?

For those unable to tell, I am using sarcasm in that last part.

> knowing that if I build an app and it probably won’t work in 5 years

Would you say MacOS, Android, and iPhone are also hobbyist toys then?

And by the way, if you statically compile your app for Linux it will basically work forever. Linus's mantra: We Do Not Break Userspace. These are userland problems and can all be avoided with a linker flag if it's a priority for you.

You cannot statically compile a lot of stuff. Too many Linux libraries are GPLed, and that only works for open source applications.

And then one day the underlying libraries will have security problems. Your statically linked application has just become a gaping hole.

And finally, you don't want your statically compiled binary to be hundreds of megabytes and take forever to launch, do you? But seeing how many people here are advocating Snap/Flat/AppImage, I guess it's not a problem? But why would you need a Linux userspace or OS in the first place when all you are doing is running virtual containers? You can run them on Windows or MacOS as well.

Not many libraries use the GPL because “that only works for open source applications”.

That said, you can just copy the .so files if you want to run the old binary.

Furthermore, binaries are mmapped, so even if it is very large, it will still launch relatively quickly since only the parts needed to launch are read into memory.

LD_LIBRARY_PATH again?

Can you stop for a second and realize your "solutions" are absolute unmitigated crap and 99.999% of people of the world wouldn't bother even if they could?

In Windows you don't have to do that. You can compile an application in Windows 11 and run it in Windows XP for Christ's sake (if you don't use new Windows APIs).

Show me a way to compile anything in Ubuntu 24 using only its own libraries and have it run in Ubuntu 6, huh? Without virtualizating/chrooting/crap like that. No, you can't? Fine.

> Not many libraries use the GPL

Let me start: Qt. Before your spew "GTK", who is going to pay for porting the code to GTK/GTKMM (since GTK is C only)?

End of your wonderful story. You really want to bend reality to make Linux look "OK". It's not. It's bad.

First, LD_LIBRARY_PATH works well (or has for me). If for some reason the elf interpreter is unable to use the older libc, just use the old elf interpreter. Second, do static linking to achieve what you want. Then it will run on the older Ubuntu trivially.

That of course requires updating the application when a vulnerability is found in a library, but this is no different from Windows where you have to update many applications to fix vulnerabilities in third party libraries. The number of vendor updates to fix the same libjpeg of libpng issues on Windows is truly staggering.

The Qt libraries do not use the GPL. They use the same LGPL that GTK does. You are making stuff up to bash open source UNIX machines (which is what Linux machines are).

For 99.99999% average people out there none of this utter cryptic crap works even remotely which basically means it doesn't exist.

Can you stop with anecdotal evidence? I don't care that you can make old software works. I can do as well, you know. Been there long before you even knew Linux existed. Had a nice little trip with GCC 2.96 by RedHat if you even remember that fiasco of epic proportions.

Then you acknowledge that what you said earlier was untrue.

> Then you acknowledge that what you said earlier was untrue.

Where did I?

Or something that's available to 0.0001% of its users has become an OS "feature"?

Who are you kidding, man? What else, you gonna claim Linux is "fine" because people can write assembler code for it? It can even run on your PC?

That's not what a desktop OS is about. That's not how it's used.

In reference to running old software, you said:

  > In Linux nothing even close is possible.

Now you say it is possible, but are fabricating figures for how many people can do it. Thus, you acknowledge what you said was untrue. Both things cannot be true simultaneously.

This is a feature of Linux. Linus Torvalds is very adamant about supporting old binaries with new kernels, even if it is not commonly done.

This is a broken mindset, that you should be able to take an app and use it for 5+ years. When computers were in their infancy, and systems were only updated every 4-6 years, it might have made sense, but this doesn't in our modern software environment.

Nowadays all software is built on libraries and frameworks, and they have security issues and even just bugs, and you want to get those fixes. If you want to run 5+ year old software, you can now do it natively in a VM in almost any computer; so why does my shiny new OS have to run ancient binaries again?

Because you might want to run more than one program at a time without having to spin up a VM to do it.

I run many programs at the same time AND run VMs; as long as you have enough memory, this shouldn't be an issue.

Without intending to be inflammatory, I think that the mindset that you are espousing is broken.

Security is is a real issue for a subset of computing tasks. To further your point, for those tasks you can argue that constant vigilance and patching are a necessity of the modern world (an alternative and arguably better approach would be that formal verification and not updating, as often applied in safety critical control systems.) However, security is often used as a pernicious ruse for forcing obsolesence: want the latest security patches? update to the latest OS version. Oh look, the latest OS version no longer runs on your perfectly good hardware. Or similarly, oh look, your perfectly good software no longer runs on the latest OS version.

But now consider the subset of computing that does not need to involve security either because it has literally no security implications, or because it can be sandboxed by the OS (e.g. games, music and video production, architectural design, scientific simulation, mathematical research, ...) There is a large body of this kind of software that works perfectly well for any number of years (modulo forced obsolesce initiatives like "modernising" the UI or moving to the cloud). I would argue that the primary function of the OS should be to provide a stable platform for running such software securely. Yes, the user could learn how run it under emulation, in a container or VM, but then what is the purpose of the OS?

The alternative is a high software maintenance burden/cost to everyone (for applications to just keep the lights on, or users to stay current in a churning software landscape) and/or the destruction of a massive amount value in developed but no longer easily able to be run software: this value destruction here is twofold: (1) the licensee can no longer run the software that they pay for, and (2) the effort expended to develop said software is discarded.

Okay, I understand what you are trying to say, but some of what you are using as examples doesn't support your argument. Games, unless they are simple single player games, need the network. Scientific sims and math research are best served on the latest hardware, which often needs the latest OS/software to get the most out of it. I think your arguing that MOST software should run without needing to be updated, and when we lived in a dial-up world and before, that was a very viable position. But with all of our machines on an always on network, the OS has to be kept up to date.

Most businesses just want things to work; their software/hardware costs are often rounding errors when amortized over their lifetime. I'm sympathetic to users who have paid for programs wanting to run them forever, but software businesses have to make money and sell new versions, so they add new features and follow the OS upgrades. It's hard for businesses to support older software or a big diversity of versions; it's why companies mandate a standard and try to enforce it.

With Microsoft, they are making millions on OS and related basic programs, and so can afford to support things for a long time. With OSS like Linux, there is less funding and less people who are interested in running old versions. As someone who has had to keep some software up to date on Linux, it can sometimes be more of a pain to update a package (because of dependencies) them to just recompile the thing from source. The 5 years that LTS releases get are good for 2 average commercial update cycles, which I think is reasonable. Beyond that, people's skills are going to be out of date.

A statically compiled app that used Xorg won’t run on many Linux distributions at the moment.

A statically compiled app that used Jack for audio might have problems running on PipeWire.

A statically compiled app from 2012 that used PolicyKit for authorization might not work today when asking for sudo. Everyone’s moved on to polkit.

The meme is wrong, don’t regurgitate nonsense. I can guarantee you my Windows app compiled in 2007 still has the UAC prompt and the audio system working correctly.

> A statically compiled app that used Xorg won’t run on many Linux distributions at the moment.

Not a single major distribution doesn't ship Xwayland by default. The entire gaming community relies on X11 continuing to work, just like they rely on x86 libraries to stick around.

> A statically compiled app that used Jack for audio might have problems running on PipeWire.

A statically compiled app that uses Jack for audio might have problems running on Pulseaudio/ALSA/OSS. Jack's never a thing that's generally available, so claiming it's a backwards compatibility issue is nonsense. If your application requires Jack, then you need to ship it.

Note that you'll also have issues on Windows and Mac because Jack - unsurprisingly - is not installed by default on those platforms either.

> A statically compiled app from 2012 that used PolicyKit for authorization might not work today when asking for sudo. Everyone’s moved on to polkit.

If you used policykit correctly you should have either used the dbus protocol, or the command line utilities. These are the APIs for userspace and they haven't changed since 2012.

What distro are you using that doesn't package Xwayland or pipewire-jack? Sure those are compatibility layers, but so is WoW64. The Linux and Windows backcompat strategies aren't all that different here.

pipewire-jack won't work with a program that links libjack statically. Pipewire preloads its own .so and hijacks those library calls.

> It can be a miracle, and yet still not be good enough. Even as a business user, knowing that if I build an app and it probably won’t work in 5 years, is all I need to know about this hobbyist toy

Build a Flatpak, you're done. Your application can depend on a stable runtime and work on any Linux distribution.

> Linux is fundamentally not ready for anyone who has needs more than a Chromebook (which also runs Steam, by the way).

Chromebooks now cover 85% of the U.S. education market, that's most workloads. The Steam Deck is also Linux (SteamOS).

What's left in the world of Win32 apps? Specialty commercial applications like Photoshop, first person shooter games that require an anticheat kernel driver. If you don't need those, a system like Bazzite is much less user hostile than what Windows has become in the era of Windows 11.

>Build a Flatpak, you're done. Your application can depend on a stable runtime and work on any Linux distribution.

Flatpak weakens but does not entirely remove the dependence on the underlying Linux distributon. Flatpak relies on a system service called xdg-desktop-portal to bridge apps inside the flatpak sandbox with the host OS. Applications distributed using flatpak may not work as expected if the distribution ships too old a version of xdg-desktop-portal.

> and it probably won’t work in 5 years

Containers have been around for over a decade now. This "no backwards compatibility" meme is utter horse shit.

At one time I was a big advocate for Unix/Linux on the desktop, but I think that ship has mostly sailed.

But, it seems that FUD about what it is capable of is still actively here, which is good to know. With frameworks and libraries, there is a 0% chance you don't have SOME update for your Windows app in a couple years, forget 5.

Now, there are lots of headwinds against Linux -- Windows is a known quantity, everyone knows the MS Office suite, people hate change and don't want to learn new stuff.

But to pretend that Linux is a house of cards because there are sometimes issues that cause troubles is not being honest. Even Windows can have big issues, or have we forgotten the CrowdStrike outage earlier this year?

All OSes have always had issues; that's why all of them have patches and updates.

I would blame Microsoft for that one, since they had the ability to ban crowdstrike and others who have no business being in the NT kernel from the NT kernel, but instead gave them access by giving them code signing certificates.

Apple on the other hand got them to switch to userspace:

https://www.crowdstrike.com/en-us/blog/crowdstrike-supports-...

>everyone knows the MS Office suite

How many people are running a locally-installed office suite at this point? Mailing files around seems archaic for most purposes. At my prior (open source) employer, even we had mostly given up on running local office productivity apps.