boolemancer

There's already a rate limit on pulls. All this does is make that rate limit more inconvenient by making it hourly instead of allowing you to amortize it over 6 hours.

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?

> The average user doesn't even recognize that running a website literally cost electricity that must be paid for. Who pays for it? Who will carry the boats?

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.

It's not a limitation of the internet, it's a fundamental property of communication.

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.

If an endpoint costs a lot to run, implement rate limits and return 429 status codes so callers know that they're calling too often.

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.

In my personal view, this seems a little overbearing.

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.

> Single English words cannot be trademarked.

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

If all that's missing is 'a nasm compatible assembler', did they try just swapping it out for nasm, which seems to have a readily available alpine package?

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

> and game dumping.

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

> Because it often isn't. I don't know about your experience, but in all the teams I've worked in throughout my career the discipline to keep PRs atomic is almost never maintained, and sometimes just doesn't make sense. Sometimes you start working on a change, but spot an issue that is either too trivial to go through the PR/review process, or closely related to the work you started but worthy of a separate commit. Other times large PRs are unavoidable, especially for refactorings, where you want to propose a larger change but the history of the progress is valuable.

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.

> At the risk of sounding judgemental, I think this preference for always squashing PRs comes from a place of either not understanding atomic commits, not caring about the benefits of them, or just choosing to be lazy. In any case, the loss of history inevitably comes at a cost of making reverting and cherry-picking changes more difficult later, as well as losing the context of why a change was made.

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?

Yeah, because no one on Linux or Mac would clone a git repo they just found out about and blindly run the setup scripts listed in the readme.

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.

Is this the first Summoning Salt video you've seen?

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?

Maybe that's a harsh lesson in making promises that can't be delivered?

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

Seems like the best way for somebody to get over a bad thing that they did in their past is to be forthright in acknowledging that they did the bad thing, and show through their actions how they've become a better person.

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

Hiding the truth seems like the exact opposite of that.

> It also allows for much easier reverting of specific changes in case some part of a topic needs removed.

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

That seems like significantly more work for marginal (if any) benefit over just having a single squash commit per PR.

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?

> When reviewers look for these logic issues, they often run through the code line-by-line using different inputs and see if any lines cause the code to produce the wrong output.

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.

When you are charging people extra for the features you're promising will exist in the future, it seems reasonable to call that fraud if you never deliver.

> _and_ charging for early access to an update to make it playable with Yuzu.

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.

I think what they're getting at is that for something low quality is less likely to have survived for a hundred years to even be a contender in this race.

> Withholding too much is literally required under the law. If you don't withhold enough, at tax time you could be liable for penalties unless you also pay quarterly to make up the difference.

You only need to withhold 90% of the taxes you owe to avoid an underpayment penalty, so you don't need to withhold too much.

> Personally, I think these companies are just stealing copyrighted works, and should be sued for that. It's against the law, it's pretty simple.

Is it copyright infringement to count how many times each letter appears in a book?

I don't know that it is, and if it's not, then there is at least some line you can draw where mechanically reading and learning from a copyrighted work is not copyright infringement.

The question of whether training a transformer model is on the legal side of that line remains to be seen, but I don't think it's as clear cut as you make it out to be.

I assume that an "ATR turboprop" does not count as a commercial jet.

How on earth is it Canon's fault when Apple releases a breaking change?

I would imagine you would call yourself a Software Engineer if what you do for a living is software engineering. I'm not sure that schooling needs to be a factor.

As far as I'm aware, the DMCA doesn't have any sort of exception for archival, but it does have one for software interoperability, which emulators definitely are, regardless of how current the hardware being emulated is.

> (It is true that Yuzu can also play homebrew software. I think the situation would be different if Yuzu was tested exclusively on Homebrew, and only emulated features which homebrew software uses. But then no one would care about Yuzu. Yuzu has tons of game-specific fixes for commercial titles.)

Yuzu can also play games that were backed up by people who legitimately own the game. The legality of that might be questionable in the US, but not everywhere.

> Given how much money they were bring in on patrion, it isn't much different than if they tried to make a physical knock off switch that could run switch games.

Why would that be a problem? As long as they're not actually violating trademarks or patents and making an actual counterfeit product, there is no reason why they shouldn't be able to make their own hardware that is compatible with Switch games.

These products already exist for other systems, and they are a good way to allow you to play your existing games on more modern hardware.

Just because it upsets some executive at Nintendo doesn't make it illegal.

> Often yes. Sometimes, no. You haven't enjoyed C++ until you get reports of the app intermittently crashing, and your build at the same version just won't.

That's okay, it's probably just some bank in a random country that requires some software package to be installed, presumably in the interest of security, which injects a dll into every process on the machine and unsurprisingly has a bug which causes your process to crash at random in only that part of the world.

Perhaps that's true, but not because it would be piracy. Backing up media for personal has a pretty strong fair use claim, so I don't think it should be considered copyright infringement.

But there is also the DMCA, and the anti-circumvention provision, which can be attributed a lot more to the user backing up their game than it can be to the developers of the emulator. But that wouldn't be the same thing as copyright infringement.

That said, if the"interoperability exception" applies to anything at all, I feel like it should apply here. You are circumventing copy protection mechanisms for the explicit purpose of interoperability with other software.

On moral grounds, I also have absolutely no qualms whatsoever with someone circumventing copy protection mechanisms to make a copy of a thing they bought to use for personal use. The fact that that could be potentially illegal at all is disgusting.