According to the Actions log for that repository it generally takes about 11-16 seconds per scrape, nowhere near a full minute. Worst case, if it’s 16 seconds every time, for a 31-day month that’s 31 days * 72 actions/day * 16 sec/action = 595.2 minutes, well within the free tier limit.
And if it does become a problem it can easily be scaled down to once per hour or something with a single git commit.
I assume you mean the table on the last page of the paper, which indeed shows WireGuard is safe against the second attack.
If you go back one page (to page 17) it has another table for the first attack. That one is less positive about WireGuard:
You produce a hundred 24 core cpus, then you test them rigorously. You discover that 30 work perfectly and sell them as the 24 core mdoel. 30 have between one and eight defective cores, so you block access to those cores and sell them as the 16 core model. Rinse and repeat until you reach the minimum number of cores for a saleable cpu.
Except the ratios of consumer demand do not always match up neatly with the production ratios. IIRC there have been cases where they’ve overproduced the top model but expected not to be able to sell them all at the price they were asking for that model, and chose to artificially “cripple” some of those and sell them as a more limited model. An alternative sales strategy would have been to lower the price of the top model to increase demand for it, of course, but that may not always be the most profitable thing to do.
If you’re using OpenSSH, the IdentityFile configuration directive selects the SSH key to use.
Add something like this to your SSH config file (~/.ssh/config):
Host github.com
IdentityFile ~/.ssh/github_rsa
Host gitlab.com
IdentityFile ~/.ssh/gitlab_rsa
This will use the github_rsa key for repositories hosted at github.com, and the gitlab_rsa key for repositories hosted at gitlab.com. Adjust as needed for your key names and hosts, obviously.
If we ever figure out FTL travel, FTL communication is relatively simple: worst case, you send your message to a ship (possibly a drone) with instructions to FTL-travel to the destination and deliver the message. It’s kind of the high-tech equivalent of a man on a horse delivering a sealed parchment, but it’d work.
If by that point we haven’t figured out a better way to do it, at the very least we should have that method available.
We did build stuff on ActivityPub: Lemmy, Kbin, Mastodon etc. are all based on that underlying protocol.
Because you need a way to be reachable over HTTPS for other instances to be able to securely send you updates (new posts/comments/votes etc.), so you need a trusted certificate. While HTTPS does not strictly require a domain name1 it vastly simplifies the process.
1: It’s possible to get a trusted certificate for an IP address, but not nearly as easy as getting one for a domain. And it’s probably also more expensive than just getting a domain and using Let’s Encrypt to get a certificate.
Many piracy sites run ads though, don’t they? Unless everyone visiting runs ad blockers (unlikely) the people running those are making at least some money. Presumably it at least covers the cost of running the sites.
It’s probably just as the comment you replied to said: “stuff bought with stolen credit cards (and resold on those sites) actually costs us money, as opposed to piracy which merely ‘costs’ us money”.