+1. I used to run Linux on my primary laptop. I'm a fairly competent Linux admin. I just got really tired of being forced to be a fairly competent admin so much of the time when I was trying to just get something done.

> writing scripts that listen to DBus or udev

Exactly. Not to mention the preceding step of spending 30 minutes in forums to find someone else who has had this problem on a system with exactly the same motherboard so you don't try the things that didn't work for them.

I'm still 100% Linux on the server, headless Linux doesn't have nearly the warts as GUI Linux.

What you're describing certainly doesn't describe my experience of the last ten years or so with Linux. Sure, there are some things that won't work with Linux by choice of the manufacturer/developer, but external monitors, audio, and Bluetooth generally just work with a Dell laptop. I've been using Dell laptops in a variety of scenarios for years and that sort of stuff doesn't even cross my mind any longer.

Reasons like these are why I switched to using virtualised Linux for most of my development, trying to run it natively on hardware works great 95%+ of the time, but that last 5% is usually tricky to fix without delving into years old mailing lists. And even if you can get things working, there's still often serious quality of life problems like the bluetooth stack randomly failing 5+ times a day

This is all true in Apple and Windows land as well. Especially if you are not "all in" on Apple and have non Apple things you are trying to connect.

> Plugging in an external monitor may or may not work. Audio may or may not switch like folks are used to.

> Want to use bluetooth? It might work.

Sounds like the problem of installing Linux on a hardware designed for Windows. All those things work flawlessly on my Purism Librem 15, which came with preinstalled Linux. (Ok, I did not try Bluetooth, but saw reports that it works.)

A single Gladwell of anecdata: I've got a thermal printer which talks Bluetooth - works flawlessly when sending data from my Macbook; outputs garbage when sending the exact same data from a Raspberry Pi 3+ (which is definitely Linux on hardware designed for Linux.)

That is all true.

In the context of the original comment, though, this does narrow down the market that can be addressed by a company running the Next/Apple playbook.

It seems vastly cheaper to solve these issues than to start a new company to produce its own hardware and OS.

If you did start such a company and prove there was a market, then you're making a bet that Canonical (or KDE devs) won't put you out of business.

100%. That's what Apple got right then and one of the reasons why Linux has never been able to really penetrate the desktop or professional desktop market. Otherwise you're constantly debugging things that should Just Work like external displays, random device drivers, etc.

> Plugging in an external monitor may or may not work

Sadly, this is now true for Macs as well. Were by "not work" I mean: not finding/not supporting the proper resolution and/or refresh rate for the display.

I had a similar experience related to this in the past couple of months. My company issued me a Macbook, and forced an upgrade to Big Sur recently. I'd been working through the pandemic by plugging the laptop into a HDMI monitor using a USB-C-to-HDMI adapter from Anker (purchased on Amazon: https://www.amazon.com/dp/B07THJGZ9Z/). After updating to Big Sur, MacOS refused to recognize the Anker adapter with a notification "USB Accessories Disabled", and a note that it was using too much power. I did a few hours of research trying to figure out what the power draw actually was (with no monitor plugged in) and scoured specifications for other adapters in the hope that I could identify one before purchasing that might work, but found scant information published on the power draw of various adapters.

I never succeeded. I just use the Macbook with only the built-in display now.

Agreed, patching/generating custom edid configs is not my idea of it just works...