Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.

There was that LG CD-ROM drive which treated a CD-RW command (which it should ignore or reject since it's not a CD-RW drive) as a firmware upload command. When a newer Linux kernel started using that command, these drives got bricked (source: https://lwn.net/Articles/55537/ and https://web.archive.org/web/20041204072839/http://www.mandra...).


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.

https://www.phoronix.com/news/UEFI-rm-root-directory

https://www.kernel.org/doc/html/latest/filesystems/efivarfs....


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.


> macOS seems to be considerably worse

Most users will just take their machine in to the Apple Store when this kind of thing happens, rather than try to fix it themselves.


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.


> doesn't make this any less inconvenient though

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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: