> No, switching DEs fixes the problem. If MacOS were open source, then you'd
>have a community-run fork from before Liquid Glass. (If MacOS were open
>source, you'd also probably have an LTS branch anyways, and no dark patterns
>forcing you to update.)
>Ubuntu users dismayed by Unity were able to stay on GNOME by installing GNOME.
>Ubuntu users dismayed when Unity went away were able to stay on Unity because
>someone forked it. GNOME users dismayed by GNOME 3 are able to stay on forks >of GNOME 2.
And again, all of these solutions are the user being dependent on someone else doing the work they want for them, and are very much not "fixing it themselves" any more than installing Asahi linux on their macbook would be "fixing it themselves"
> Is this an assertion you're making as someone who doesn't use it?
No it's an assertion I'm making knowing that the vast majority of computer users barely understand what it is their computer is doing at any given time or why. And of the subset of users that do have an understanding, an even smaller subset of those users have the necessary skills, time and inclination to fix something wrong with the system. I worked computer retail for years. The vast majority of people I interacted with had no interest in knowing what their computer was doing under the hood or how they could solve their own problems. For every one customer that I had the chance to show how they could do something for themselves, I had 10-15 other customers tell me they didn't want to know, they just wanted it fixed.
I have plenty of experience using Linux. I spent 7 years working at a job where I was thankfully allowed to use a Linux box as my primary development machine. My home network runs stacks of Debian boxes, my 3d printers are running klipper, my home media systems Ubuntu or Debian. I built an arcade system than runs off of a Debian box. I've built remote scanning and printing workstations out of some Raspberry Pis for a company I worked for, and built custom touch screen inventory workstations prototyping them out on "Puppy Linux" installations (some weirdness around needing to work forward from a very old x11 config that didn't work with modern ubuntu at the time). I've been installing and using Linux in some form or another since I first spent 3 days twice in a row downloading the set of 600MB install CDs for "mkLinux" over a 33.6 dialup connection (twice because the first time I pulled the files down in "text mode" which broke the images).
But it's also these experiences that inform my opinion that Linux presents plenty of its own pain points and that plenty of those pain points are simply unfixable by the vast majority of their users. Every other year or so, some updates to Ubuntu would inevitably break multi-display handling or the network or something else on my dev machine at work. I would easily lose a day or two to hunting down esoteric configuration options and work arounds and digging into things that most computer users will never want to touch. My arcade system worked fine for months until an update to something in the Debian/Ubuntu audio stack broke audio on boot. It's been over a year now and it's still broken. You have to manually go into alsamixer, swap which audio "card" the system thinks its talking to (the onboard audio presents as two different cards, one for the normal audio jacks and one for HDMI out) and then toggle the muting on the various outputs until you find the one that was enumerated to be your current output on this boot. As near as I can figure out, it has something to do with a change in the order that the audio system is brought up on boot. It's now loaded much earlier in the boot process and apparently this particular chip and board combination doesn't initialize the second card until after some later step in the boot process pokes it. So when the audio system first comes up, it only sees the one card, can't apply the saved configurations and drops into a default. I've built some work around scripts that try to re-apply the audio settings again later in the process, but so far they're only about 60% effective. In the mean time, it's just broken for me and plenty of other people like me with the same AMD on board audio setup. And I'm someone comfortable digging into debugging hardware boot-up issues and the rats nest that is the linux audio stack.
But this same box also saw me need to switch from XFCE to KDE because some bug with the "notifications" system in XFCE hard hangs any user input for 5 minutes or so if you try to pop up a notification before the first time a user logs into the DE, something that I was doing because the arcade doesn't have a mouse plugged in, but you can hit a hotkey combo to switch to a keyboard mouse control scheme and I wanted a notification to display when you switched control schemes.
I have a raspberry pi running home-assistant that refused to boot if one of the zwave radio devices is plugged in to USB on boot. No idea why and it's been working fine ever since I switched to a different zwave radio, but was certainly a pain if the power ever flickered.
And lets not get into the nightmare that getting each individual linux system to play nicely with DHCPv6 was. Apparently every linux distro does IPv6 DHCP things just a little differently and even across versions of the same distro it can vary wildly.
Are all of these things fixable by AN end user? Yes, probably they are. Are all of them fixable by me? Probably with enough free time and a little luck, yes they probably are. Are they fixable by most people who use a computer day to day and especially the sort of people who aren't already interested in Linux? No almost certainly not. Those users would rely on people like me (or more likely the people I'm relying on) to figure it out and drop a solution in the up stream or provide some package you can install to replace the broken component. And again, I'm not denying that this possibility is a benefit. It's just not the same as "fixing it yourself".