What's your opinion on Linux?

[Chris]

I think you misunderstood what this was about.
On Windows and Mac the OS provides the facilities so any middleware is on even ground, but it ultimately calls down to the system API as well which ensures that everything is consistent.

Well, this is where you get into complicated semantic arguments. I'm sure you know that Linux-proper is just the kernel. Nothing more, not even an init program/process. What we refer to as Linux colloquially is more aptly called GNU/Linux as it uses the Linux kernel along with GNU-developed software to actually control the system. However, that's not entirely accurate either because, while portions of it may be GNU (particularly the compiler and libc), GNU doesn't cover everything most people need, and most people/distributions may replace some GNU components with alternatives.

Now, obviously you can't have a stable system that people can target software to if everyone is doing something different. This issue is dealt with through ubiquitous packages that have become the defacto standard of a "Linux system". Things like X11, ALSA, etc. There's nothing to say a Linux system will have these, but if you're making software for a general Linux system, you can safely assume they're there if you rely on that task. API standards and compatibility layers also play a part.

That is all just a long-winded way of saying, what you may think of as a system API on Windows or macOS may actually be nothing more than an extra utility library pre-bundled with the OS. Is it really much different for a developer to be told "If you need XYZ, use these functions provided by the OS" or "If you need XYZ, use these functions provided by this ubiquitous library"? As long as it works, the job's done either way. Granted, there are times it would be beneficial to have something pre-bundled that everyone is guaranteed to use, for, as you mentioned, consistency (it's painfully obvious when one app uses Qt while another uses GTK, for example). But other times, that can lead to disaster too (Internet Explorer).

Which makes me wonder why X is still a thing if it's this far behind current technology.

That's been an on-going argument for a while now. Some people say we need to replace it, others say X is good enough and/or can be fixed as needed. I'm sure it doesn't help that Qt and GTK have been effective at covering up most of its issues, so not many people actually have to deal with the lower-level stuff where these issues are most apparent. And X had gotten stuck before when the Xfree86 project was slow to include features people were wanting, leading to Xorg being forked from it which revitalized X for a time.

It's also a big task to replace. A lot has built up around it as both a natural part of extending it with new features, and to deal with the issues as they turned up (GLX, XInput, XRandR, ...). You also need to implement compatibility layers, to ensure all the existing X11-based programs can continue to work, and ideally get the support of toolkits and graphics libraries, so that apps written for them can work natively with the new APIs.

Luckily it seems some headway is being made in that department. Wayland has been coming along, getting native support from Qt, GTK, and SDL, and they're also making sure to have XWayland available, a compatibility layer for X11-based apps to work in Wayland. I couldn't tell you how far along they are to being ready for "prime time", or what obstacles they still have to overcome, but it's much farther along than previous attempts at replacing X in recent memory, and is still going.

[Rachael]

I'm really not a huge fan of Wayland, to be honest, with what limited time I've spent using it. My biggest issue is its lack of compatibility and portability - and I also understand X11's system and how it works, to some extent, which I guess naturally leads me to favor it more.

But overall Wayland feels like another systemd/pulseaudio type thing, where very little consideration is given to standards or compatibility and the whole effort is to just push forward, regardless of the cost or the chaos that it ensues. And I'll resign that in the long run, yes, systemd and pulseaudio turned out to be better for Linux, in the end - but when they were being pushed, it was not fun nor pleasant. Who knows - maybe that will be better, in the end.

[Graf Zahl]

And I'll resign that in the long run, yes, systemd and pulseaudio turned out to be better for Linux, in the end - but when they were being pushed, it was not fun nor pleasant. Who knows - maybe that will be better, in the end.

You know, even Windows had such periods, like the transition from Windows 9x to the NT kernel or the changed driver model in Vista. It definitely created short term problems but was ultimately outweighed by the long term benefits.

In short: No pain, no gain. Those who always want to play it safe will ultimately lose.

[Cacodemon345]

I was forced to move back to Windows after I found it to have issues with MIDI. WINE's MIDI didn't work properly (no music at all.) And then the lack of native games and with higher requirements for those AAA games released on it was another reason. Plus the fact that the lack of proper Windows-only game support in WINE was another reason for it. I would have stayed with it for longer if it had VSTi software, but there's none, sadly. The fact that you have to enter a password everytime you need to install software through package managers is annoying. The fact that pretty much literally FUCKING everything open-source you download from the internet requires compilation, unless if it provides .deb packages.

I also have to say that the speed of Linux Distro releases make it hard to keep with it. I would rather upgrade my computer at will if I'm obligated to do so, rather than seeing repos pulled out for the lack of support and having forced to update Linux.

[Rachael]

I was forced to move back to Windows after I found it to have issues with MIDI. WINE's MIDI didn't work properly (no music at all.) And then the lack of native games and with higher requirements for those AAA games released on it was another reason. Plus the fact that the lack of proper Windows-only game support in WINE was another reason for it. I would have stayed with it for longer if it had VSTi software, but there's none, sadly. The fact that you have to enter a password everytime you need to install software through package managers is annoying. The fact that pretty much literally FUCKING everything open-source you download from the internet requires compilation, unless if it provides .deb packages.

I also have to say that the speed of Linux Distro releases make it hard to keep with it. I would rather upgrade my computer at will if I'm obligated to do so, rather than seeing repos pulled out for the lack of support and having forced to update Linux.

Cacodemon345 - I have always been one of your BIGGEST critics due to the way you say things off the cuff with very little knowledge backing it.

This post is one of the best I've ever seen you write. It has your actual OWN experience here, not parroting a bunch of stuff, and not as much assumption as you normally put into your posts.

This post isn't perfect - for example you blame it being open-source for the fact that you have to compile everything (that's a fault that rests with the community, mostly, and the people who develop for it) - but other than that, this is mostly a very organic post, and I applaud you for it. It's definitely way above your average. So - please keep doing that!

[Marrub]

Linux a good, been using Arch Linux as my primary OS for 4 years now. Only thing I need dual-booting for at this point is games, because I don't have a secondary GPU (or integrated GPU) for VM passthrough.
That said, I don't think people should use a Linux-based OS unless they know what they're doing. Understanding how a computer works is necessary. I feel a strong similarity between current Linux operating systems and old Commodore systems - if you don't know what you're doing, things will likely fall downhill; and I feel if you just want to use a computer, it's not for you, and that there's no necessity for it.

[Caligari87]

Just anecdotally, I've been on Linux Mint for about 5 years now as my daily driver (including school). Switched over my gaming PC about a year ago, only giving up a few games that are impossible to run in WINE. Got my wife using Mint as her daily driver for about two years now, and just got my mom using it on her new laptop.

I'm a computer guy and did the setup. On the other hand, neither of them are computer people (my mom aggressively so), yet they haven't had any issues that couldn't be solved with a phone call consisting essentially of "go here, click this." In point of fact, both of them have had fewer complaints and problems than they did with Windows.

If Windows software compatibility isn't a problem, I feel confident saying Linux Mint is perfectly suitable for "not computer people."

[Graf Zahl]

I feel confident saying Linux Mint is perfectly suitable for "not computer people."

The irony is, Linux is good for those who know their way around computers and do not mind to fiddle around with it, and it's good for those who can make do with a minimal set of standard software and never need to bother with the gory details.

The real problem cases lie between those extremes where you are dependent on some software that doesn't want to work without investing a lot of work.
No, I do not want to fiddle around with my computer. I got a set of software I need to work. That set of software does not exist on Linux, even on Mac only parts of it are available so the end result is obvious: I stick with Windows. I always found Wine to be a horrible crutch because it integrates so poorly into the host system.

[dpJudas]

That is all just a long-winded way of saying, what you may think of as a system API on Windows or macOS may actually be nothing more than an extra utility library pre-bundled with the OS. Is it really much different for a developer to be told "If you need XYZ, use these functions provided by the OS" or "If you need XYZ, use these functions provided by this ubiquitous library"? As long as it works, the job's done either way. Granted, there are times it would be beneficial to have something pre-bundled that everyone is guaranteed to use, for, as you mentioned, consistency (it's painfully obvious when one app uses Qt while another uses GTK, for example). But other times, that can lead to disaster too (Internet Explorer).

The difference is the ability to assess the likelihood of a given "ubiquitous" library being available. And even when they are available, say libfreetype2, there are compile flags for the library that heavily affect its suitability for certain tasks and there's no remote guarantee they are set in a way usable for your program. There are so many Linux folks that like to tinker with their setup that a Linux system can be configured in literally almost any way possible.

Then there's the problem of who gets blamed when a Linux system fails to meet the expectations - it is universally always the app developers that get the hate, even when it isn't remotely their fault. For example, QZDoom linked against LLVM for a short time and it turned out the chaotic nature of Linux made it so certain display drivers also used LLVM for their llvm-pipe backend. Well guess what, LLVM is a library that doesn't like getting initialized twice and when QZDoom initialized LLVM those Intel and AMD drivers would shit themselves. Whose fault is that exactly? The end users most certainly blamed QZDoom because that was the program that made it crash. Also good luck getting the distro package maintainer, the llvm-pipe devs or llvm (Apple) to fix this. None of them give a shit about this problem as it falls between the cracks of each individual project.

There's a reason the only successful consumer Linux distribution, Android, replaced the whole thing with their own system and provided those long sought guarantees to app developers.

[Chris]

The difference is the ability to assess the likelihood of a given "ubiquitous" library being available.

The term "ubiquitous" rather implies it's easily available. If you aren't sure if something is ubiquitous, then get something you can ship with your app so it doesn't matter.

And even when they are available, say libfreetype2, there are compile flags for the library that heavily affect its suitability for certain tasks and there's no remote guarantee they are set in a way usable for your program. There are so many Linux folks that like to tinker with their setup that a Linux system can be configured in literally almost any way possible.

How many Linux folk are there really that would build a version of freetype2 that would break typical apps? I'd wager the vast majority just pull whatever version is in their distro's repository, which is pre-configured and pre-built. It's a very small minority of users that both use a distro where they need to build things themselves and use compatibility-breaking configuration options. Just as on Windows, I'm sure there are ways I can configure it in a way that would break apps despite being a "valid" configuration, but developers don't generally worry about that because the amount of people that may be doing those problematic configuration changes is a very small subset of the whole user-base (and those few who do should also know to expect compatibility issues).

Maybe it's slightly more of an issue on Linux because the ratio of techy people to non-techy is higher, but I would argue not significantly more of an issue. If it was, we wouldn't have things like Steam or the commercial apps we do have.

Then there's the problem of who gets blamed when a Linux system fails to meet the expectations - it is universally always the app developers that get the hate, even when it isn't remotely their fault.

Obviously I don't condone any kind of hate or abuse being thrown at developers. In considering fault though, when you have hundreds to thousands of apps using a particular library or system, and one inexplicably shows a problem, it's not unreasonable to assume it's that one app that's at fault. That of course doesn't mean it is, it's possible for one particular app to hit a bug that other apps manage to avoid, but blame and bug-hunting go hand-in-hand. Assume the app is at fault, check if the app is doing anything wrong. If the app is good, then follow the chain down to what it uses, have that checked out, etc. It would be very inefficient to assume problems in software come from the bottom-up instead of top-down.

For example, QZDoom linked against LLVM for a short time and it turned out the chaotic nature of Linux made it so certain display drivers also used LLVM for their llvm-pipe backend. Well guess what, LLVM is a library that doesn't like getting initialized twice and when QZDoom initialized LLVM those Intel and AMD drivers would shit themselves.

How is the graphics drivers using LLVM a result of "the chaotic nature of Linux"? It makes total sense for them to use LLVM, so I can't say I see what's "chaotic" about it and why that's bad.

if LLVM is a library that doesn't like getting initialized twice, and graphics drivers use it, that must mean no other app that uses the graphics drivers also use LLVM itself. So then either QZDoom was doing something no other similar app was doing (attempting to be bleeding edge, you should expect problems on any OS), or other apps have managed to do it so it does work (in which case, either it was being used incorrectly or you managed to stumble on a bug, both things that can happen on Windows).

[dpJudas]

The term "ubiquitous" rather implies it's easily available. If you aren't sure if something is ubiquitous, then get something you can ship with your app so it doesn't matter.

I chose to put the word in quotes because there are very few actual ubiquitous libraries if you think about it. In particular Qt, Gtk+ and SDL are not ubiquitous.

I extended the definition to roughly include anything you could reasonably assume could be apt-get installed, or at least be there in a typical "desktop install" of a Linux distribution, because otherwise your argument made little sense. Of those that now qualify they tend to vary a lot in quality and what was compiled into them -- I simply do not find it reasonable to state that this is roughly equivalent to Windows, macOS or Android where a simple documentation lookup will tell you where the API is available and what is compiled into it.

How many Linux folk are there really that would build a version of freetype2 that would break typical apps? I'd wager the vast majority just pull whatever version is in their distro's repository, which is pre-configured and pre-built.

Sorry, I meant distribution flavors, not individual custom builds of freetype2. Distro A might have freetype2 with grid hinting turned on, distro B might not. Distro C might have a lazy (or overburdened) package maintainer so that version of freetype2 is 5 years out of date. There is no reasonable way an app developer can assess whether freetype2 can be used or not.

Maybe it's slightly more of an issue on Linux because the ratio of techy people to non-techy is higher, but I would argue not significantly more of an issue. If it was, we wouldn't have things like Steam or the commercial apps we do have.

Notice how all the commercial apps always have two things true for them: 1) they statically link *everything*, 2) they officially only support one or two exact versions of a Linux distribution.

if LLVM is a library that doesn't like getting initialized twice, and graphics drivers use it, that must mean no other app that uses the graphics drivers also use LLVM itself.

LLVM is a compiler backend technology - it is primarily used by compilers (clang in particular) and those typically have no UI in their process. What breaks QZDoom is just that is uses OpenGL alongside linking with LLVM. Mix those two things in a process on Linux and your process goes kaboom.

[Graf Zahl]

The difference is the ability to assess the likelihood of a given "ubiquitous" library being available. And even when they are available, say libfreetype2, there are compile flags for the library that heavily affect its suitability for certain tasks and there's no remote guarantee they are set in a way usable for your program. There are so many Linux folks that like to tinker with their setup that a Linux system can be configured in literally almost any way possible.

If it wasn't so that many of these third party libraries actually stand in for missing parts of the core system I'd just say to build apps that contain all non-system code they reference - just like on Windows ans macOS. But that seems to be a sacrilege, judging by the reactions one often gets.

There's a reason the only successful consumer Linux distribution, Android, replaced the whole thing with their own system and provided those long sought guarantees to app developers.

[/quote]

Wanna bet that this lesson won't have any effect on the big picture? It perfectly confirms what I have been saying all along:
The only chance a Linux-based desktop OS ever has a chance of gaining broader support is to replace that hodgepodge of third party libraries for everything with a coherent system the programmers can actually rely on.
Even just looking at GZDoom: Do we have GTK? If yes, use some GUI stuff, if not use the terminal. At some point this ceases to work.

[Chris]

I chose to put the word in quotes because there are very few actual ubiquitous libraries if you think about it. In particular Qt, Gtk+ and SDL are not ubiquitous.

Are they not? Unless someone is specifically avoiding Qt and/or GTK apps, it's very likely they'll have both of them installed as some dependency of an app they have (though Qt isn't something you can rely on pre-installed anyway; being C++ it's highly prone to ABI breaks, so just like on Windows you're better off shipping with the libs or static linking). Similarly, if you're at all serious about games and interactive apps, there's a 99.99% chance you have SDL already.

And if not, it's super-easy to install them. Providing apps as a .deb package will even have them listed internally and automatically install them if they're not already.

Sorry, I meant distribution flavors, not individual custom builds of freetype2. Distro A might have freetype2 with grid hinting turned on, distro B might not. Distro C might have a lazy (or overburdened) package maintainer so that version of freetype2 is 5 years out of date. There is no reasonable way an app developer can assess whether freetype2 can be used or not.

If a distro has core packages that far out of date, it's likely not a distro you're going to do much current stuff with regardless. Similar if a distro has core packages configured in some way that makes it binary incompatible with preexisting binaries, you're not going to be using third-party binaries on them.

Notice how all the commercial apps always have two things true for them: 1) they statically link *everything*, 2) they officially only support one or two exact versions of a Linux distribution.

So.. just like Windows? Windows apps tend to static link as much as they can, or ship with specific DLLs they require (heck even ZDoom, when I was first adding OpenAL support one of Randi's complaints was that everything needed to be in the download package and OpenAL support would add some more DLLs). They also only support specific versions of Windows. I haven't seen too many people complain that commercial apps tend to "require" Ubuntu*, because if there's enough people that care on another distro they'll find a way to make sure it works. Not-officially-supported Linux distros either work anyway, or can be made to work without much hassle.

* Which is what most new Linux users will be exposed to. It helps that Ubuntu itself is based on Debian, which a number of other distros are based on too, so most often it's inherently compatible.

LLVM is a compiler backend technology - it is primarily used by compilers (clang in particular) and those typically have no UI in their process. What breaks QZDoom is just that is uses OpenGL alongside linking with LLVM. Mix those two things in a process on Linux and your process goes kaboom.

So you're using a (relatively new) compiler backend lib, something very few applications have need of, and using it a context it hasn't been in before (a game engine). I'd not be surprised to see an issue pop up. It's certainly unfortunate that there's a bug, but you're bound to find some sooner or later when trying things others haven't. Have you reported that issue to the driver and/or LLVM devs?

[Graf Zahl]

So.. just like Windows? Windows apps tend to static link as much as they can, or ship with specific DLLs they require.

Guess why! People got burned by DLL hell and try their best not to fall victim to that anymore. It also removes critical dependencies on code installed by third parties.

Yes, that's where Linux will inevitably have to go if it wants to present a reliable experience to its users.

They also only support a specific version of Windows.

Huh? What?

[Chris]

Huh? What?

When a game lists a version of Windows as a requirement, it means only that version is officially supported. For example, I think it was Bethesda with Oblivion, the PC version was made for and listed Windows XP as a requirement. Later on, after Windows Vista came out, they said Vista wasn't an officially supported platform for the game. Obviously you can play it on Vista, but at least at the time, Bethesda's stance was it was an unsupported OS.