I believe that the top-level comment you replied to is making the point that there should not be any authority that either allows or disallows what a user can do with the device they own. Purchasing a device should make one that authority, free to decide how much security to trade for how much privilege.
But really it's all about framing. For example on desktop computers it's not possible for people to create new instructions for their CPU to handle. At some layer there will be an API that user needs to use to interact with the device. As times goes on I think it's natural for that layer that users are expected to interact with their device with to become higher level. I believe the top level comment is framing this issue such that current phones don't have an API that matched how it worked for UNIX computers and that is a bad thing. The commenter is too focused on how things worked in the past and doesn't want to allow for things to change.
I just had to update the firmware my HF radio using xmodem protocol. Tons of modern ham radio gear still using serial data... even the modern ones that connect to your PC via USB, still just a USB->serial device built in.
EDIT: actually not ZModem, but it supports X/YModem -- source code, despite the comment at its beginning, finally says "Sorry, zModem not available yet"
As another paying user of Kagi I wonder what prevented you from using another search engine for the six hours that Kagi was unavailable. Search engines are not like your email provider or ISP in that you're locked in.
The thing is, I never thought Kagi was down and thought that it must be a problem with my configuration or connection. That was how much I trusted in Kagi. I didn’t spend whole downtime online though.
Would you say that the Linux kernel is written by mostly "100% subpar C programmers"? Because it's an extremely common pattern to have multiple goto labels at the end of a function.
Yes. There's a reason pretty much every secure C coding standard dictates exact what I said, like CERT C etc. There's a reason they have weird bugs. Just because it's an impressive piece of software, doesn't mean it can't have horrible design pattern written by substandard coders. And in an open source project with as many contributors as Linux, I would say it's not hard to fathom that there's a significant number of substandard people writing code on that codebase. Even MISRA quoted in the article I believe intends that you only have one goto location.
I'm not saying not to use goto. The above example works on any C language, with some tweaks needed to K&R. I've done substantial Kernel work and can tell you that there's no reason to ever break my example and put multiple goto stubs. Can you provide a single situation where it is needed and there's no other alternative? I can't prove the negative you want me to.
I don't see how the number of goto's is relevant. You're still having alot of goto's in each function in the codebase with SESE and only using one goto location, solely for cleanup and exit.
a more interesting discussion between your point and his would be to show simple examples where each of the views break down. When you're dealing with allocation or handle cleanup, SESE sounds good to me. But with multilevel loop break or continues, even observing SESE I can see room for more gotos. But I don't know what either you or he are talking about.
How are they possibly not the victims after the distributor orders a vast quantity of product, goes MIA for months, and then proceeds to go "whoops, just kidding, here's your stale product back"?
They are victims, but also they are in business that should know what they are doing. This stuff isn't exactly uncommon if you do some research. And that is why they should have been entirely sure what they signed up for. They were not forced to enter this contract, but instead choose to.
That's not a fair conclusion from the parent comment at all. Software developers _do_ have the right to prevent their work from being given away for free. Them _choosing_ to develop FOSS is them voluntarily waiving that right.
And most of the small authors think that copyright should not be longer then 5 years, the only one's against it are the big publishers, so as a small author you cannot choose if you want at least a bit money.