boomlinde

The implications of the crash depends entirely on the implementation of the process it crashes. If I use ffmpeg as a library it'll crash my process upon processing the offending file. How is my process designed? How is every process that uses ffmpeg designed? You don't know, therefore you can't say that it's a "self-dos" in every case even if you know that it is in some cases.

Maybe I am clever enough to have read up on the history of ffmpeg vulnerabilities before deployment to an attacker-facing service and have designed a solution where a crash has minimal implications, but maybe I'm not, and haven't. It's beside the point.

It seems bizarre in a way to see this sentiment on hacker news.

- you apply the commits as-is on the target branch and end up with a ton of pointless "fix this" and "fix that" commits that were created during the review process,

- you squash everything and lose what might otherwise have been meaningful, useful commit boundaries for the purpose of bisecting, reverting or just investigating the history of changes or

- you rework your commits and force push changes to the branch you want to pull and create confusion as to what changed because that's not usually how review is conducted with GitHub.

I think the pull request is a bad abstraction. Not terrible, and certainly easy to grasp, but bad enough that everything you do with it is a compromise. At the very best, if you apply with the squash+rebase strategy and limit the scope of your PRs to what makes perfect sense as just one commit in the target branch, it's just a convoluted way of working with individual commits.

It certainly puts pressure on the scope and quality of commits, but I think that's only undue for a short-lived project where you don't foresee a long period of maintenance. Consistently high quality commits with a clear scope is a godsend when you are investigating the history of a project. Some small pressure now is IMO better than greater pressure later when you are debugging an issue at three in the morning and scrolling through either a bunch of "fix stuff" commits or 1000+ line PR squashes.

I use different angle units depending on the application. On a platform with 8-bit index registers, 1/256 of a turn can be useful. IIRC Pico-8 uses turns.

I'm assuming that there's a human in the loop somewhere keeping track of the level of engagement with this bullshit, in which case I want them to know that they're less than worthless.

The socially practical effect of working patent law is that it incentivizes inventors to publicly document their inventions by offering limited exclusive rights to the invention. To that end, an overly broad claim to hypothetical inventions which are not actually documented in the patent is detrimental and instead stifles innovation.

I've seen it during my career as a software developer, too. Heaps of alert spam that remained unread because 99% of them were useless and not indicative of a problem on our end. It's important to be careful about alerts so you know when real problems occur.