[lynndotpy]

> but in reality for most users most of the time, Linux is as "fixable" as Windows or macOS,

I disagree with this. For most users, most of the time, Linux is significantly more fixable than Windows or MacOS.

In nearly 20 years, I've never had to write a line of C or touch the Linux kernel to fix issues I've had on Linux.

For example, one of my big peeves I've had lately on both PopOS and MacOS are the looooong animations to switch desktops.

On PopOS, I had two paths to fix this: Tweak the COSMIC desktop to fix the behavior, or the simple thing of simply installing GNOME (or KDE or any other DE of choice).

On MacOS, I'm SOL. There's no way to fix that on my Macbook (short of installing Asahi Linux, of course).

> Just like you "can" find all the information you need to diagnose and treat whatever medical condition you might have online and at your local libraries. But most people are still going to pay a doctor, because most people don't have the time or skills to actually do it.

This isn't a great analogy, but it's worth noting: Many conditions are expected to be self-diagnosed and self-treated. I don't go to the doctor for scrapes, bruises, colds, dry eyes, a stubbed toe, etc. By this analogy, Linux users are buying their own aspirin and applying their own band-aids, while MacOS users are waiting in line, dependent on someone else to fix these things.

I say this as someone who uses both MacOS and Linux daily.

[tpmoney]

> On PopOS, I had two paths to fix this: Tweak the COSMIC desktop to fix the behavior, or the simple thing of simply installing GNOME (or KDE or any other DE of choice).

So what did you do? Did you fix the DE? Again, this is effectively outside the skill of the sorts of people who would be "switching" to linux due to the issues with macOS or Windows.

And while installing a new DE is certainly easier than re-programming one, it's still dependent on someone else having written a DE that not only solves your problem, but doesn't introduce entirely new ones and isn't so fundamentally different to the user that they might as well have switched OSes in the first place. And if the user's primary issue was being forced into a major interface re-design like liquid glass, having to switch to a completely new DE is more of a lateral move than actually fixing the problem.

And to be clear, the fact that it's POSSIBLE for someone to fix a problem for you even if you can't, and it doesn't have to be the primary OS vendor is a benefit of using an open source OS. So I'm not saying it's not possible to benefit from this. I'm just saying that for most users, most of the time, the ability to "fix it themselves" is effectively as out of reach for them as it is using macOS or Windows because having access to the source code is only the tiniest part of actually fixing a problem for themselves.

Since my doctor analogy fell flat, let me try again with a traditional car analogy. A kit car is infinitely more open, customizable and user controllable than any car bought from an auto manufacturer. And yet, for the vast majority of drivers, buying a kit car, even if it was turn key and pre-built would do absolutely nothing to make it more likely that they will do their own repairs or modifications to the car. They will continue taking it to the same mechanics they always took their traditional cars to, they will continue to buy off the shelf parts if possible and do without if not.

[lynndotpy]

> So what did you do? Did you fix the DE?

Nope, I swapped to GNOME. Forking the DE was something I was considering doing just to contribute back. It's not something I'd recommend someone to do. (That said, it's Rust and not C, so the barrier for entry is much lower.)

If someone can install Linux, they can install a new DE. It's easy peasy.

> if the user's primary issue was being forced into a major interface re-design like liquid glass, having to switch to a completely new DE is more of a lateral move than actually fixing the problem.

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 it's worth stressing that _none_ of these were so bad as Liquid Glass.

>for most users, most of the time, the ability to "fix it themselves" is effectively as out of reach for them

This is the thing I take contention with. This seems hard to square with the experience of someone using Linux. Is this an assertion you're making as someone who doesn't use it?

I think the most common experience on Linux is that people are able to fix the things that annoy them. It's a tangible and normal thing, not a hypothetical.

[tpmoney]

> 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".