10 per hour is slightly lower than 100 per 6 hours, but not in any meaningful way from a bandwidth perspective, especially since image size isn't factored into these rate limits in any way.

If bandwidth is the real concern, why change to a more inconvenient time period for the rate limit rather than just lowering the existing rate limit to 60 per 6 hours?

Running a retail store also has costs associated with it, including, yes, electricity.

Yet if I walk into a store and leave without buying anything, do I feel like I owe the store owner anything?

No. That's not how that works, nor is that how it should work.

Imagine trying to validate that all letters sent to your company are written by special company-provided typewriters and you would run into the same fundamental limits.

Whenever you design any client/server architecture, the first rule should always be "never trust the client," for that very reason.

Rather than trying to work around that rule, put your effort into ensuring that the system is correct and resilient even in the face of malicious clients.

That endpoint will be expensive regardless of whether it's your own app or a third party that's calling it too often, so design it with that in mind.

Your app isn't special, it's just another client. Treat it that way.

If you expose an API, and you want to tell a user that they are "unauthorized" to use it, it should return a 401 status code so that the caller knows they're unauthorized.

If you can't do that because their traffic looks like normal usage of the API by your web app, then I question why their usage is problematic for you.

At the end of the day, you don't get to control what 'browser' the user uses to interact with your service. Sure, it might be Chrome, but it just as easily might be Firefox, or Lynx, or something the user built from scratch, or someone manually typing out HTTP requests in netcat, or, in this case, someone building a custom client for your specific service.

If you host a web server, it's on you to remember that and design accordingly, not on the user to limit how they use your service.

Um... Apple? Shell? Alphabet? Chevron? Target? Caterpillar? Oracle? Orange?

https://pkgs.alpinelinux.org/package/edge/main/x86/nasm

Your argument is that legally purchasing a game and playing that in an emulator is piracy?

In my experience at least, PRs are atomic in that they always leave main in a "good state" (where good is pretty loosely defined as 'the tests had to pass once').

Sometimes you might make a few small changes in a PR, but they still go through a review. If they're too big, you might ask someone to split it out into two PRs.

Obviously special cases exist for things like large refactoring, but those should be rare and can be handled on a case by case basis.

But regardless, even if a PR has multiple small changes, I wouldn't revert or cherry-pick just part of it. Just do the whole thing or not at all.

> Oh, plenty. For one, when looking at `git blame` to determine why a change was made, I hope to find this information in the commit message. This is what commit messages are for anyway. If all commits have this information, following the history of a set of changes becomes much easier. This is helpful not just during code reviews, but after the merge as well, for any new members of the team trying to understand the codebase, or even the author themself in the future.

Yeah but the context for `git blame` is still there when doing a squash merge, and the commit message should still be relevant and useful.

My point isn't that history isn't useful, it's that the specific individual commits that make up a PR don't provide more useful context than the combined PR commit itself does.

I don't need to know that a typo was fixed in iteration 5 of feedback in the PR that was introduced in iteration 3. It's not relevant once the PR is merged.

1) Why are you ever reverting/cherry-picking at a more granular level than an entire PR anyway? The PR is the thing that gets signed-off on, and the thing that goes through the CI build/tests, so why wouldn't that be the thing kept as an atomic unit?

2) I don't think I've ever cared about the context for a specific commit within a PR once the PR has been merged. What kind of information do you expect to get out of it?

Edit: How does it remove the context for a change or make `git bisect` useless? How big are your PRs that you can't get enough context from finding the PR commit to know why a particular change was made?

And no one would pipe a script downloaded with wget/curl directly into bash.

And nobody would copy a script from a code-formatted block on a page, paste it directly into their terminal and then run it.

Im not going to go so far as to claim that these behaviors are as common as installing software on Windows, but they are still definitely common, and all could lead to the same kinds of bad things happening.

I don't know enough to say that he doesn't use an LLM during his writing process, but I do know that I haven't noticed any appreciable difference between his newer videos and ones that were released before ChatGPT was made available.

Is it possible that this is just the way he chooses to write his scripts that you interpret as sounding like they are written by an LLM?

Or, more likely, no lessons will be learned and people will still trust what the company says in the future for arbitrary reasons.

In other words, accept responsibility and earn back your reputation.

Hiding the truth seems like the exact opposite of that.

I guess I struggle to see where reverting entire commits makes more sense than just deleting the offending code in a new commit.

I don't think I've ever found myself in a situation where I needed more granularity than the PR level when looking back through the history of a repo.

What are the situations where this is actually useful enough to make it worth the effort?

I don't know of anyone that regularly does this during code reviews.

In my experience, automated tests help to catch regressions, i.e., they help catch error cases that people have already anticipated. If the system fails in some brand new unexpected way, you won't have tests for it by definition.

Similarly, static analysis can help catch certain classes of bugs, but there's plenty of things they won't be able to spot.

Yes, they're both useful, but neither of these is a replacement for code review. They're all complementary.

From my understanding, this part is not true (though it is widely touted).

There were third parties that made the necessary fixes to run the game in their own forks, but Yuzu proper did not release any fixes until after the game came out, even in the pre-release versions.