Why the "/troll"? You're 100% right non-ironically: the problem being that on Linux the need to consult forum posts to fix these kind of issues is way more frequent than in macOS.
By the standard of "do you ever need to consult forum posts to solve a problem", sure, Linux is worse than macOS. By the standard of "do you ever need to consult forum posts to fix hardware that has apparently been bricked by a software update", macOS seems to be considerably worse. At least, that's my experience. I've never had hardware damaged by Linux, which I've run almost exclusively. On the other hand the one Apple device I've ever owned got bricked by their software update.
I can't say I've heard of that happening to people on Linux at all other than maybe early days of Xorg. Damage (reversible or otherwise) to hardware is extraordinarily rare on Linux, I can only think of it happening during the very early days of EFI and only under very specific conditions.
> I've never had hardware damaged by Linux, which I've run almost exclusively. [...] I can't say I've heard of that happening to people on Linux at all other than maybe early days of Xorg.
More recently there was "rm -rf /" wiping efivars and bricking some motherboards with shitty uefi implementations thanks to systemd mounting efivars rw by default (and shitty motherboard firmware). The kernel "fixed" this by mounting unknown efivars as (mostly) immutable.
There were also some motherboards with shitty UEFI implementations which got bricked when the efivars storage did not have enough free space to do the garbage collection. The kernel "fixed" this by not allowing more than half of the efivars storage to be used (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...).
Right, this is what I meant by the EFI brick in my comment. And in my comment "I can't say I've heard of that happening", I meant bricking a device on a system update. That's the specific thing which seems to happen on occasion with macOS, but that I've not seen with Linux. I do grant that there have been some (very rare) instances like this where hardware can be bricked by a command run on a Linux system.
Sure, but that's when they get told "you need to replace the logic board, that'll be $500 since it's out of warranty". That's not a theoretical problem either, people were literally told to do this back when the Big Sur brick happened to my model (2014 MBP). Eventually users figured out on their own that you could just replace the I/O board (not the mainboard / "logic board"). Apparently (going by that forum thread) disconnecting and then reconnecting the I/O board fixes it as well for some people (I don't remember whether I tested this), but this isn't something that Apple happily figured out and did for everyone who walked into one of their stores. We had to fix it ourselves.
Sure, doesn't make this any less inconvenient though. I would much prefer to finish whatever I want to finish today (even if I spend a few hours trying to fix an issue) than wait whatever amount of days waiting until my hardware is fixed.
You're right that it's not ideal, but it certainly makes it a lot _less_ inconvenient than being completely stuck forever (as most non-highly-technical people would be if they had to follow instructions on forums to fix Linux).
This is anecdotal, but my last “corporate job” was the closest to thing to shrink-wrapped software, even though it was a SaaS. Every release was meticulously documented. Any public facing UI or API change was approved the appropriate teams.
This is similar to macOS, Windows, or even FreeBSD releases. I haven’t seen any Linux distribution that has such comprehensively coordinated releases. Between systemd and the Linux kernel, I’m not sure it would be possible.
Many distros have good documentation, but, in my experience, far too often the bulk of it is in out of date wikis or forums. Perhaps this is out of date thinking and I’ve missed the train in the past 10 years.
As a counterpoint, OpenWRT has been good, but their main “product”, imho, is LuCI. Lower level issues often require vendor specific forums.
So essentially, the situation you'd have if you'd bought a Mac?
If we want to compare apples to apples, then we compare:
Mac with macOS updates installed regularly, and only those provided by Apple. Non-Apple apps get dropped in /Applications like they should be. If there's an installer that asks for root access, you might get boned.
Linux preinstalled with OS updates installed regularly, and only those provided by the vendor. Apps that don't come with the OS's package manager should be installed somewhere under $HOME, and never installed systemwide as root.
Sure, if you have a Mac and disable SIP (or whatever it's called nowadays) and start mucking around with files in /System or whatever, because you want to install some mod that does something cool, you might have a bad time. Same as if you decide that screwing around in /lib on a Linux machine is a good idea.
But if we actually compare these two apples, I suspect the Linux one would have fewer problems.
>So essentially, the situation you'd have if you'd bought a Mac?
No, worse, with more device incompatibilities, manual fiddling, arcane settings, and so on to make things work.
>Sure, if you have a Mac and disable SIP (or whatever it's called nowadays) and start mucking around with files in /System or whatever, because you want to install some mod that does something cool, you might have a bad time.
Sure, but I'm not talking about that. With Linux you often have a bad time trying to make basic, but not distro configured, functionality to work.
> with more device incompatibilities, manual fiddling
Did you read what I wrote above? "if you buy preinstalled"
If you install Linux on an ordinary "Windows-certified" computer, you will have problems. If you install an alternative OS on a Macbook, you will have exactly the same problems.
>Did you read what I wrote above? "if you buy preinstalled"
And did you understand my point? Buying preinstalled isn't a cure-all, only ensures that the bundled hardware drivers are compatible and configured. That's a pretty low bar.
It doesn't cover doing stuff with third party devices (which on the Mac 99% of the time it works every time).
Not to mention even the bundled-hardware doesn't always work even if you buy pre-installed (like the laptop not sleeping properly for example).
