Not really. It's not even that it's a pet peeve, just them pointing out that projects need to keep safety in mind.
The author even mentions that they have contributed to PinePhone software.
(not to mention they're just plain wrong about the battery/thermal not having hardware-level limits)
If they use the license wording to help get it across, well, I don't necessarily agree but as they state in the article:
> I'm trying to be a bit inflamatory here, to start the conversation.
> Software engineering does not put safety first
I'm 100% agreed.
If the conversation is
> The PinePhone has less quality control than Android/iOS
It's patently false
I would parse the article as the second, as it's referring to a specific phone throughout
And I concur about the second being patently false. I would guess that it has more overall tbh.
> It's patently false
PinePhone is just HW. Android/iOS is SW. Comparison doesn't make sense. Maybe compare PinePhone to Huawei Honor, or Xiaomi and their HW testing:
That's a strawman: author never compared to Android/iOS. What they did spell out,is that some of the code they found is unsafe (e.g. commented-out code to prevent false alerts, that was never being reimplemented in a safer way).
> C. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, THE APPLE SOFTWARE AND SERVICES ARE PROVIDED “AS IS” AND “AS AVAILABLE”, WITH ALL FAULTS AND WITHOUT WARRANTY OF ANY KIND
There are not many reasons not to use my kernel tree for Pinephone. I actually had reports from users that my multi-distro image that uses my kernel for 13 different pinephone distributions makes some distros run better.
I suspect that distro maintainers just think that pine64 community gitlab is somehow more official than any other pinephone kernel developer's tree on the internet, just from the name.
After giving Purism some money for their "Fund Your App"-thingy today I decided to hit your donation button with a small, but recurring donation, because you deserve it for all your work – even if, sadly, my favourite distribution (DanctNIX Mobile) does not use your kernel and I am too lazy to change that on my end.
Those are the safety measures protecting the PMIC, not the battery. Is that temperature cutoff even low enough to matter before the battery is on fire?
It isn't clear that the software protections ever mattered anyway. If the kernel crashes, or is just charging while turned off, I sure hope it's still designed to be completely safe, and not a sudden explosion risk.
Then PMIC operates independently from the kernel, and configuration even persists when powered off/during reboots.
HW is designed to be safe, but SW has to cooperate, including userspace. (some daemon that will help policing the whole device, based on many different inputs and by controling things that affect heat production - like preventing the user from setting backlight at max, limiting modem RF output to something that doesn't need huge amounts of power, etc. etc.)
It's a complicated area.