Your comment got downvoted, because on this site it is frowned upon to write lazy, confrontative and uninformative comments. If you don't have an argument that furthers the discussion consider not writing instead.
Simple systems have the advantage that there are less moving parts. Less moving parts means less chance of failure. That is a trade-off an engineer will sometimes take even if it means building a new thing, sometimes something with more moving parts is needed and that is okay as well.
Maybe your requirement is to have a doorbell that does work when the internet is out. Who knows? OP might live in a place where this happens more often. Or they might not and like the idea to never again have to think about their doorbell-manufacturers cloud and the latests exploits targeting that IoT product. There are many reasons why simple can be the right choice and any true engineer would say: "depends" instead of "so what".
> If you don't have an argument that furthers the discussion consider not writing instead.
You are correct in general, but I think "so what?" was an adequate response (even though I don't agree with it) in this case that actually furthered the discussion as can be seen from your long reply.
We don't always need LLM-like, long comments. Sometimes "so what?" can be intriguing enough.
It’s 150 comments of back and forth on a change which doesn’t have a concrete reason, the maintainers aren’t in agreement on what the right approach is wrt the field’s behaviour, and the person who submitted it is bouncing between saying he’s keeping it on topic and then adding scope where he believes it should be added.
I also personally disagree with the change, I think the OP has gone ahead and implemented what they wanted but not considered the actual ways it will be used. The PR shouldn’t be merged until the laws have made a bit more progress and it’s clear what they’re _actually_ implementing.
That's the facebookisation or redditisation of open source. Open source used to mean when you got the software you got the source code, but now it means a platform for arguing. And there's no doubt in my mind when people say they can't switch their project from GitHub to Forgejo because they'd lose "contributions", they mean this.
I don't understand your point. The phrase "when you got the software it got the source code" makes no sense. And arguments were just as common decades ago on forums, mailing lists, and IRC. What exactly are you trying to say?
I don’t think this is anything new. There’s been massive blow ups for as long as we’ve been doing this - NetBSD and OpenBSD was a massive, public falling out as was the gnome 3 release, or the python 3 release.
I would never look at a person's github account to evaluate them. The most important things people do will be proprietary, or if they contribute to serious projects will be in that project's gitlab/forgejo's instance.
I'm equally confused as the other person above. Why not just ask participants to report what type of sauna they used? Sure humidity/duration/temp would be awesome to have, but at the very minimum knowing if a dry sauna would get the same results as a traditional steam sauna.
There's quite a wide range of variation between "full dry" (no added humidity whatsoever) and "full steam" (an actual steam room, rather than a sauna). Just asking people was it dry or was it humid won't capture much of that variation. I have a steam room at home and have been a near-life-long lover of them - they are wildly different than a sauna. But I'd still rank a sauna where someone had dumped 1L or so of water over the heater to be "humid", and consider it also very different from a totally dry sauna.
Because to 99.9% people it’s obvious and fair to assume that person asking this question knows that you need a car to wash it. No one ever could ask this question not knowing this, so it implies some trick layer.
so what?