Hacker News Reader

This is nitpicking and ignoring that the end users have problems because of all of this, and they are not addressed because of this kind of hand waving.

I donate to the FSF, I contribute to FOSS, and I take those kind of articles very seriously. Because they contain very important informations of what we need to work on next.

Of course, that doesn't mean we should take it at face values. Like for the Linux drivers situation, the idea is not to say "yeah, let's change that". But one should recognize the challenges it can bring, and find a way to make it better for those who wants to get hardware support.

Staying on the top of our ivory tower while stating we are technically correct, the best kind of correct, is not a good long term strategy.

Screen tearing is something I've seen happen a few times across different hardware combinations. Sometimes it just works out of the box (e.g. my laptop using Intel graphics on Arch Linux experiences no tearing in any application) sometimes its a huge problem (e.g. my Raspberry Pi using ARM graphics experiences mild to severe screen tearing). Whats really confusing about the Raspberry Pi example is the conflicting info online. Some people swear turning off composting solves it, others say turning if on solves it. For me turning if off sorted it even tho this went against most of the advice I read in Raspberry Pi forums etc. Most of my experiences with Linux has been somewhere in between of the two extreme examples I've just described.

Meanwhile Windows literally just works on every device I've tried it on. I can't remember the last time I saw any screen tearing of any kind on a non-Linux device. Whenever I'm out and about and see screen tearing I'm like "Ah it's running Linux" and chances are I'm right.

For what's its worth I use Linux as the only OS on my ThinkPad and love it. I do acknowledge its flaws though and graphics is an area with room for improvement.

Only time I've seen tearing in windows is when I had no graphics drivers installed.

That really shouldn't be the baseline for an effective graphics driver...

> Weird list of non-problems and not understanding how Linux works

I would like to add this attitude to the list.

Yeah seriously. Been dealing with this attitude from the Linux Desktop community for literal decades now.

It will never be the year of the linux desktop if they can't put their feet in the shoes of a non-linux hacker.

> It will never be the year of the linux desktop if they can't put their feet in the shoes of a non-linux hacker.

My honest impression is that the developers of the software are often quite in tune with the needs and pains of the users, and the sort of "your problem is not a problem" responses lacking empathy you see are largely from other users. This isn't universally true, but I would say broadly. And even in cases where it isn't that one uncaring dev is often not representative of the project as a whole.

What I mean is - I think it's valid to call this a frequent failing of the broader Linux community, with users included. It bothers me as well. But the ones who do the most to make the software are often the ones who do care the most. And for them it's also quite a bad experience when generalizations go the other way.

> My honest impression is that the developers of the software are often quite in tune with the needs and pains of the users, and the sort of "your problem is not a problem" responses lacking empathy you see are largely from other users.

Perhaps you have never perused the GNOME issue tracker then.

It's like "Works on my system" manifested as a person.

Each point he made is really weak too. It puts all the burden on the user compared to other main stream operating systems

> There's no concept of drivers in Linux ...

I'm not well versed in drivers, but this explanation makes it sound like hardware needs to target a specific linux driver to work as intended.

So instead of someone building their own driver against some api and including it with the product, they have to either design their hardware around linux (and maintain compatibility with windows/mac), or make a pull request for support and go through the normal development channels?

Is that really how that works? No wonder graphics + wifi cards have had so much trouble through the years...

> Your hardware generally either works or doesn't work. ... Linux-compatible hardware to purchase ...

I've never bought a device that didn't work with windows. Ever.

I understand what causes that, but for better for for worse, windows wins for usability here. And I'm not entirely convinced no one can come up with a system to smooth this out better.

> ... The distros keep your software working with newer versions of Gtk or Qt, and deal with licensing. It's not something that end users need to worry about.

Until something breaks and I do have to worry about it. Then it's explicitly my problem to solve, with only google on my side to help.

> Also the obsession with "screen tearing" ...

It doesn't bother me either, but "it doesn't bother me so it's a non-problem" is so unsympathetic to the typical user.

Is no one besides techie programmers supposed to being using linux? That's what it seems like most of the time.

>It puts all the burden on the user compared to other main stream operating systems

When I asked for help for my sound (in linux its only 50% volume and sounds like its a cheap speaker inside of a tin can) I was blamed for:

- Using a laptop

- The brand of laptop

- The audio hardware of my laptop (its their fault, not the kernels "generic" driver)

Then was told to either carry around an external DAC + Speakers or buy a desktop with a "proper" audio card.

It was the first time in 6 years I'd installed Linux and it lasted less than a week.

This happens all the time.

And even if a user has had the opposite experience:

"Oh, I had an issue and the community was so helpful, I got my issue resolved in a few days from going back and forth with nice people."

Some may disagree but I shouldn't have to enter communities of people to just get my computer to run. I want to put the flash drive in, wait an hour, and get onto what I actually wanted to do with a computer.

And it's sad, because I believe I share the same vision of people developing this software.

I want a world where every computer can have an OS that's free, completely open source, user friendly for every day computing, and empowers you to truly OWN the hunk of plastic in your hands.

It really seems linux is for no one but kernel hackers, software engineers, or to run on server hardware.

It's a bit like in sports. If you play ping pong, for example, there is a certain group of players that blame the paddle, the balls, the table, the shoes, the floor, etc.

There is only one thing they don't blame.

"Not fair, my controller was broken!"

> Is that really how that works? No wonder graphics + wifi cards have had so much trouble through the years...

No, it's not at all! Linux of course has the concept of drivers. In most cases the drivers are integrated into the Linux kernel codebase itself, and nowadays are in by far most cases contributed by the companies making the hardware (or contractors they pay to do so). In (much) rarer cases drivers are developed by the community. Overall this makes it quite a lot like for example Windows, where hardware vendors develop drivers and hand them off to Microsoft to distribute through Windows Update. Linux is roughly the same, with the drivers coming down through kernel (i.e. system) updates. A few drivers are maintained and distributed entirely separately by their vendors, but this is usually less convenient for the users in the end.

Within the kernel codebase, there are various frameworks catering toward device drivers of specific categories, so that a driver developer doesn't have to start from zero when implementing the driver for their device. Let's say a lot of storage drivers have to solve roughly the same problems, so of course it makes sense to share some code rather than reinvent wheels. This sort of code sharing is encouraged by the developer community, but not enforced.

For some categories of devices there are generic drivers, but those tend to reflect the existence of industry standards enabling their creation. For example USB Mass Storage and USB HID devices are standardized and don't need device-specific drivers (roughly speaking).

The bulk of the Linux kernel source code is drivers, and the bulk of those is contributed or paid for by hw companies.

In some cases kernel drivers also communicate with device-specific userspace components. For example when it comes to graphics drivers, in some cases only part of the driver resides in the kernel and some of the upper layers (e.g. the OpenGL API implementation) is organized through projects like Mesa, again with significant vendor participation.

> Is no one besides techie programmers supposed to being using linux? That's what it seems like most of the time.

There's plenty of Linux desktop devs that would take screen tearing to be a very serious problem :).

Thank you so much for the well explained reply, I appreciate the effort :)

My assumptions are based on my own experience.

Under windows, if a device driver isn't tracked by microsoft, it's typically provided as an installer program from the company that made the product.

But I very rarely see that for linux, besides some passing recollections of nvidia or wifi card binary blobs.

Is there a reason for that? If I made some weird hardware that needed custom drivers, do I target the appropriate kernel APIs then get it submitted for the next kernel version?

And, to save you the breath, could you recommend any blog posts or articles that dig more into these things? I want to learn more.

> Is there a reason for that? If I made some weird hardware that needed custom drivers, do I target the appropriate kernel APIs then get it submitted for the next kernel version?

Yep, there's a few reasons for that:

- Broadly speaking, the Linux kernel has a generic framework for "modules" that can be loaded and unloaded at runtime. Modules can do many things, including provide device drivers. It's possible to develop and build a module separately from the kernel, and within the code of the module make use of the aforementioned targeted driver frameworks.

- However, the Linux kernel intentionally does not provide a stable API or ABI for modules. And the driver frameworks are internal unstable API as well (unlike the kernel userspace API, which is never allowed to be broken). That does not mean it is impossible to develop and release a driver independently from the kernel - in practice, a fair amount of the API/ABI changes rarely - but it makes it much less practical and convenient than contributing the driver to the kernel source tree and developing it in lockstep.

- There's a wide range of (often heated) arguments around the issue of whether there should be a stable API and ABI for (driver) modules. For now the result of a debate spanning decades is I would say a loose agreement that getting hw vendors to contribute their drivers upstream has netted various benefits, such as the ability to maintain/update the driver when vendors cease to exist, get vendors to contribute to shared frameworks, make the drivers do things the vendor never planned for (e.g. expanding support to a new CPU architecture!), allow the kernel to develop faster (want to make a fundamental change somewhere? port all the driver users in one swoop and move things forward), etc.

- Overall this has lead to an ecosystem where this is now business as usual for I'd say the majority of hw vendors, who will make "contribute the driver to Linux before we release the hw" simply part of their dev and business routine.

- Some vendors still stubbornly refuse to (or have historical legal reasons they can't) contribute drivers however and have opted to try and maintain them separately. For those cases there exist some mitigating hacks. For example a little open source glue module that sits between the kernel and a proprietary binary-only driver, and distro frameworks that will recompile the glue module at boot time to fit an updated kernel (this gets around the ABI issue, but also some hairy legal license incompatibilities). Nobody loves these, but they exist and in some cases work OK where the vendor is very active in shouldering their maintenance burden.

A few decades in, I honestly find it hard to say which approach is better for which device. For example, you could say if the OS has a stable driver API/ABI, it means the vendor can cease to exist and their old driver release for my obscure hw will continue to work. This is true, but it also means you can never fix a bug in the driver, and the driver may no longer work with a major new version of the OS (say, Win 95 to Win XP, or Win XP to Vista) or in a computer with the same ports but a different CPU arch (say, x86 to ARM). In many ways the Linux kernel is the biggest actively maintained collection of "runs old obscure hardware" drivers around today, and there are plenty of gaps to "every hw works with Windows" that are filled by it.

Practical example: Recently I wanted to digitize some of my folks' old Hi8 family video tapes. My mother's boyfriend used to do this himself with an old EyeTV video capture stick they bought for their Mac circa OS X 10.3. Its drivers ceased to work around OS X 10.6 and EyeTV never provided support for their old product for newer versions of the OS, because they moved on to newer products. The fix? Capture from Linux using the same HW. Why does Linux have a driver for it? Because all these branded capture sticks map back to a just a few popular chips built into these products, and Linux has a well-maintained driver for the entire family, while the MacOS ones are vendor-specific.

And it runs deep: The entire mythical origin story of the free software movement began with a guy at MIT being upset about a bug in the driver for their expensive laser printer and the vendor refusing to release the source code and holding the device commercially hostage. This motivated the project that gave us modern open source licensing (GNU and the GPL, the latter used by Linux) and changed the entire software industry!

Shipping drivers with the kernel also has some big disadvantages, like the need to run a bleeding edge kernel version if you want support for newer devices.

I had to wait a few months before Ubuntu moved to a kernel version with the support for my motherboard's network adapter.

Yep, definitely. Potential lag time on newly-released hardware can be a major issue if the device vendor doesn't upstream the driver early enough, and/or if the system vendor doesn't provide kernel updates in a timely manner. The optionally more direct channel from device vendor to HW customer can be a big advantage then, or the (maybe?) faster turnaround times of the Windows Update channel (Windows Update seems to do a really good job of addressing the annoying driver hunting and manual updating Windows was plagued with in the past these days).

I've been hit by this as well, when I bought an nVidia card in its launch month years ago and had to fiddle before the drivers became widely available. That said, nVidia is by far the most prominent example for swimming against the tide of the general rhythm of the Linux world and the other GPU vendors do a better job with open sourcing and early upstreaming.

> The distros keep your software working with newer versions of Gtk or Qt

This doesn't help obscure software (like BambooTracker or vgmtrans) which isn't shipped by most distributions.

Additionally a distribution isn't going to port a Qt 5 app to Qt 6 for you; if the original developer doesn't, someone else might do it a few years later, or never. Sure, a distribution might ship Qt 5 indefinitely, but it's going to slowly fall behind over the next few years, like what's been happening to Qt 4.

Worse yet is software dependent on the KF5 KDE support libraries. Ironically, old creaky-looking software like Strawberry (based off Clementine, based off KDE 3's Amarok) and Qsynth/QjackCtl (dated look and feel) are the first ones to port to Qt 6 (before KDE applications), because they don't depend on KDE libraries which need to be ported first.

The desktop application ecosystem is kind of a mess from what I experienced; it's also possible I have the wrong expectations as I'm not usually building desktop apps. Gnome and QT generally have to be installed in order for apps that use them to work. I found that when I was trying to make an app, this ended up getting in my way far more than anticipated.

There's a whole new class of electron-like (usually WebView oriented) frameworks appearing for languages now that make building desktop apps fairly straightforward. This is kinda nice because the framework then deals with environment integration (for instance X11 vs Wayland, or Windows and MacOS) -- but at a minimum it makes it so you can build native feeling apps that are entirely web frontends. The only limitation here is that I've found UI components for OS-native look and feel (as opposed to mobile) to be fairly limited in quantity.

At the end of the day, I guess what I'm alluding to is maybe QT and Gnome are great, but I feel like a lot of applications that are outside of serving a particular OS or ecosystem will need to build with UIs meant to run on multiple machines with minimal dependencies.

On Windows, Electron-based apps generally bundle Electron (Chromium and Node.js) with the app, resulting in a large download size. You can do that with Windows Qt apps as well, and it generally works out too (the app is larger than a Win32 app but smaller than an Electron app). I have less experience with GTK but I assume it works the same.

Linux distributions expect Qt and GTK apps to use a system toolkit. Some like Arch try to package Electron apps the same way (using a system Electron). However Electron releases incompatible major versions often, and you often have to install multiple Electron versions in parallel for different apps, and which version changes over time, so I have to juggle installing/uninstalling "electron" and "electron12/13/..." based on when apps update. (Admittedly, I also have Qt5/6 installed and GTK3/4 installed, but I expect these version numbers to remain stable for the next 5+ years.)

> There's a whole new class of electron-like (usually WebView oriented) frameworks appearing for languages now that make building desktop apps fairly straightforward.

It was already fairly straightforward. Now it's just understandable to people who are mostly familiar with web-centric development, which is a different claim entirely.

Qt is not an ecosystem; KDE is (like GNOME). Qt (like GTK, at least historically) cannot be an ecosystem because it has to be cross-platform.

You can build GUI apps in Qt or in other GUI toolkits and they will just work. They do not need integration into a desktop environment (though it can help in some cases if they are.

"OS-native look and feel" is overrated. There are numerous apps from Apple, particularly in the media creation sector, that do not conform to their own "native look and feel", and several of the most successful apps in this sector from 3rd parties also ignore it. Maybe for "office/productivity" apps it is important...

"OS-native look and feel" - +1 on being overrated. In most cases, I use programs, sometimes with diverging methods for doing common things, but it's not a deal-breaker. If you are not familiar with how a complex piece of software works and you need to use it, you have a bigger problem than if the UI seems a little different than other applications on the platform or if a few keybindings are different than expected.

We work in the programs that we use primarily. Browsers are one such example. I wonder if they break OS UI guidelines; websites themselves certainly do. The only issue is if the look and feel is good enough on desktop applications. KDE makes things look consistent even with non-KDE/Qt programs, so I am happy enough.

Meanwhile the UI framework situation on windows became much worse than on linux. Windows 2000 had comctl, but it was consistent with user32, on XP they became different, vista added ribbons, then came WPF, UWP, Xamarin, Electron, Metro, immersive UI, now windows 11 added something new that looks like tenth UI framework.

Question: If we want to write an gui app and have the binary continue to work on anything linux just about forever, how far does static linking get you?

In most cases disk is not the resources most needed to optimize. Granted you don't get bugfixes in your libraries but you made the call that they were working well enough, and if security is at issue old binaries probably aren't a good answer ever?

Statically linked to everything including libc should be forwards compatible with any kernel upgrade - "don't break userspace"

Your app isn't the xserver. Do X upgrades break it? I imagine a distro switch to Wayland would? Or do they reverse compatible an X abi? Anything else that could change under you? Other servers than X? Anything else I'm missing?

Anyone else remember being told that the answer was Java? What happened to that?

I can't speak to the long-term limitations of static linking. I will say that the JVM is a user-side hurdle which is undesirable. I usually use Rust or Go for cross compilation.

> I watch videos often in X11 which is supposed to be impossible because of this "tearing" thing, but somehow it doesn't bother me at all.

It doesn't bother you or you don't have tearing?

Like OP, I never have tearing in Xorg. I also will never own Nvidia. The issue isn't X11 which is perfectly happy to run in any environment including Wayland or GDI. It's crappy drivers that are handled by the B-team devs.

I think the GUI applications thing is another of those times where it's a tradeoff. Much like the way drivers work, it's fair to be annoyed with it, but it replaces (more or less equally) annoyances in Windows's opposite approach.

Yes, your usual desktop Linux distro doesn't expect you to be running a GTK application that was built twenty years ago. If you do that, you probably need to do some manual steps. (That's why it installs to ~2 GB). On the other hand, GNOME uses one version of one UI toolkit across all of its core applications. If you click through the Settings application, you will not - at any point - come across a control panel from 1995. Meanwhile, want to make a native app for GNOME? Great, you have one option[1]. The lack of screwing around with backwards compatibility - freely dropping stuff when it isn't useful anymore - makes for a thinner, tidier stack in a lot of ways.

It's better if we can have both - obviously it sucks knowing you'll have to "fix" something eventually because Lenart invented a newer better duotronic transporter buffer - and maybe stuff like flatpak will be able to help with that in the future, but I for one am grateful desktop Linux isn't forced to drag around a mountain of shims and forgotten libraries for a minority of users.

[1] https://developer.gnome.org/

> which is the same as any other OS

Apple's value story is that you can get a machine guaranteed to run MacOS by walking into a store and buying their hardware, no Internet search necessary (unless you need directions to the store).

There are a couple companies that do that for the Linux ecosystem, and I suspect it would make Linux easier to use if more were out there (but I don't know if the market would support them).

> There are a couple companies that do that for the Linux ecosystem, and I suspect it would make Linux easier to use if more were out there (but I don't know if the market would support them).

Even then those Linux systems are only supported with whatever distro the vendor ships. If you try to run a different distro that has license restrictions for closed binary blobs that "Linux machine" still may not work right.

Yeah, and that might be as much a marketing problem as a technology problem. We may need to be considering another major category of desktop / laptop OS experience besides Windows, MacOSX, Chromebook, and "Linux (pick your distro)": "Linux (vendor)." Like Linux (pick your distro) but more likely to be working out-of-the-box and more likely to break under exotic manipulations than Linux (pick your distro).

I have a great ThinkPad X1 that I just tried to switch the window manager it shipped with for xmonad. Everything broke. It's not particularly intuitive that the list of things depending on the window manager config involves wifi, audio control, Bluetooth control, power management (machine no longer sleeps when the screen is shut), screen auto-configuration when a monitor is plugged in or unplugged, and what happens when you plug a USB drive in... But they do.

From an adoption standpoint, there might be meat on the bones of the messaging "Linux on the desktop is great if you buy from a vendor; just don't assume that any old hack you do to the default install is going to just work." Then widen the set of "blessed" hacks that do work from that base template of well-verified default configuration.

Screen tearing is like keming - once you see it, you see it everywhere.

It's least that one is possible to fix, at least with Intel graphics drivers. I get a little obsessed when I see deviations like this on the screen. That's one example, but there is also burnt pixels or pressure spots on the screen that can drive me nuts.

Here's hoping for distros to make that solution the default.

Wayland fixed screen tearing. There's also the TearFree setting for Xorg.

No video tearing in years. Sure, I can haul an old laptop out of the basement. QT 5.6 is holding me back a bit. That is about money though and not linux. It is easier to absorb license fees in commercial software, sure. Need to read what the KDE people are doing.

Have you read the Security category?

> you'll need to do a few internet searches first, which is the same as any other OS.

For everything I can buy in a store I can be sure there's a Windows driver/userspace software, and for everything above a couple hundred dollars I can be reasonably sure there's an OS X solution (although that one seriously changed in the last years with the deprecation of 32-bit in 10.15 and the shitshow that is 11+).

For Linux? Oh jesus. That requires dedicated research and, worst case, manually compiling stuff from some random github repository where someone hacked a solution.

About third-party drivers, especially from random Chinese vendors, I like to treat them like they don't exist. Mainline drivers tend to be higher quality, and they are more or less guaranteed to keep working indefinitely. The only exceptions I currently have are an nVidia GPU in a secondary computer (GPU compute box) and a Brother printer. Both have a long history of working well, and have packages, not tarballs or Git repositories that need compilation. The Brother drivers are also user space only.

So, IMO, if you are doing it right, it's more a matter of research and less a matter of compiling your drivers from an obscure repository.

So, how to do it right? What are THE right steps to crosscheck stuff available from local vendor (to make eventual warranty claims easier) with linux compatibility?

I am actually using linux desktop 20 years and still it feels like groping in the dark every time i buy some peripheral.

Plus I can confirm the regressions mentioned in the article caused by relentless churn in the kernel are very real. Oh and userspace churn too. I have whole system from gcc4.9/Qt4 era saved to chroot into whenever I need some "old" software. For lay user such hoops are impossible.

> I have whole system from gcc4.9/Qt4 era saved to chroot into whenever I need some "old" software. For lay user such hoops are impossible.

A simple "docker run -it -v /:/mnt debian/eol:$CODENAME bash" should give you a working Debian chroot without any hassle - you can go as far back as Debian potato from 2000 per https://hub.docker.com/r/debian/eol/. In theory according to a SO post (https://askubuntu.com/a/1161647) you should even be able to get GUI applications working inside a Docker container.

You're missing the point, confirming the generally dismissive or even ignorant attitude. What if there's no deb package? How to make home directory accessible?

The point was, every time Gtk/Qt major version is updated, whole desktop gets obsolete. Perfectly fine applications must be reworked or abandoned or mucking with chroot/docker. Throw in the transition to systemd and wayland.

> You're missing the point, confirming the generally dismissive or even ignorant attitude.

I get the issue if you're still dealing with chroots. I hated this with a passion, too - but using Docker is a real breeze in comparison.

> What if there's no deb package?

A Debian archive docker image behaves just like an ordinary Debian install would - they are fancy chroots. Install the dependencies, run the usual "./configure && make && make install" dance, that's it.

> How to make home directory accessible?

Add a "-v /home:/home" in the invocation.

> The point was, every time Gtk/Qt major version is updated, whole desktop gets obsolete. Perfectly fine applications must be reworked or abandoned or mucking with chroot/docker. Throw in the transition to systemd and wayland.

Agree with you on that one, with one exception... systemd unit files are so much easier to deal with than init.d shellscripts.

I don't trust systemd and docker, sorry. No idea if it's my bad luck or what, every time I tried out such a complex thing with "easy" interface, I ran into some insidious bug.

I recently got a TI-99/4A and ran a program that did a pretty poor job of waiting for vblank to do sprite position updates. Result: Horrible, horrible tearing.

You "don't have a problem with" tearing because tearing has always been with us and some people are just used to it. But other people are bothered by it and it doesn't have to be this way. Notably, one of the goals of Wayland is to solve for tearing when X hasn't.

> Your hardware generally either works or doesn't work. If you are looking for Linux-compatible hardware to purchase, you'll need to do a few internet searches first, which is the same as any other OS.

I'm sorry, but this simply isn't true. I've seen this specious argument for almost 30 years now. It was not true in 1994, and it is not true in 2021. The fact that this is still making the rounds, is perhaps the most damning indictment of desktop Linux.

When making a hardware purchase for Windows or Mac, pretty much everything is supported right out of the box. I pick up a webcam, it works. I pick out a printer, it works. I don't have to worry the hardware is supported on Windows or Mac. It is, right out of the box. It's a very rare occurrence if I have to download anything to support it, and usually then it turns out to be needless OEM crapware.

When it comes to Linux it's a crapshoot. Hardware description often don't say if it's supported. So you have start to google around and see if it's supported, and if you're lucky, you'll get get answer, but often you don't. Instead, you just find people asking if it is supported, or maybe talking about how it's kind of broken. A lot of this has to do with the fact that the kernel support is based on chipsets -- which makes sense from an engineering perspective -- but makes zero sense from a consumer perspective. This information isn't easily available.

Purchasing desktop hardware for Linux is like walking in a minefield, and it's always been like that. You'll never get everything to work all at the same time, so you'll just have to satisfy yourself with which subset of features you want supported, but of course, you won't actually know what features are broken until you actually start using it, because you'll never list and test all your cases before purchase.

While not stated in the above post, the lack of hardware support is often followed up with either a hopeful, "It's open source! It will get better!" Or a dismissive, "You've got the source. Fix it yourself."

That's a lie. Even as a software engineer, I don't have the time or knowledge to develop my own driver for some sound card, or figure out why everything coming out of my printer has a pink a hue. I don't even know where to begin to debug that, and that's assuming I have the time to do it. If an SWE can't do it, there's zero hope for anyone else to fix their own problems.

So what about the developer community? Surely they'll fix it! In my experience, the answer is probably not. I've never seen partially supported hardware go to full support. Either the developer moves on because it's "good enough" for him (e.g. see your comment about how screen tearing "doesn't bother me at all"), or some newer version comes out, and everything stops to (partially) support the new one.

"Linux on the desktop" sounded great 20 years ago, and I really wanted it on my desktop. But then I realized that it's always tinkering. Desktop linux is like having a broken down car for your daily driver. What I wanted wasn't "Linux", but rather a unix for my desktop.

Then MacOSX came out. An honest to god unix, but with hardware support. Once I made the jump, I haven't looked back. Now the only linux device I own are a raspberry pi and and an underused NAS. I'm cool with that.

Plus a million.

As for MacOS, yeah, it's truly great but the hw is quite expensive and limited to what Apple sells to you. And then Apple deprecates older devices all the time and you're left with an OS where you cannot run any modern apps including the web browser which makes using them a major threat to your security.

Until you try to compile your Qt-4 software and… dang!

> which is the same as any other OS.

Did you ever used Windows?

The author has monetised all outgoing links by showing an ad before redirecting. They are making money off this publicity, nothing more.