Makyen/EC2-linux received failover signal. <-- This probably shouldn't have happened. Check if Thoth is operational (e.g. !!/location) and consider executing !!/standby Makyen/EC2-linux to put this instance back in standby. (@Makyen)
@SmokeDetector 3/3 of the user's answers link to the same blog, which has no other hits on SE. No evidence of affiliation, but is suspicious. Custom flagged.
@DavidPostill Per Wayback machine, the link went to what the OP described 4 years ago when the answer was posted, but yeah, the domain appears to be porn now. Thanks.
sdc report unix.stackexchange.com/a/720424 "Likely spam, given it doesn't really answer the question, and domain was spammed recently. Custom flagged."
@Ollie I don't actually know, but I've assumed they are similarly configured virtual machines. It's possible that cruft just built up in Osiris. Thomas Ward also mentioned that there might have been some data corruption on Osiris. The watch/blacklist process also includes some network traffic, so it could be that one just happened to be quick and/or Thomas Ward's been doing a lot of networking work. The fresh git clone might also be of benefit.
Although, the full repository on GitHub could really use a git gc --aggressive (as in, the repo goes from >1GB to <80MB), but as far as I've been able to tell, the only way to do that for the repository on GitHub is to completely delete the GitHub repository and recreate it, which would loose all history outside the commits themselves (e.g. Issues and PRs; well, Issues could be individually transferred).
@Makyen My internet is being unusually quick today, so that might be playing a part. I don't know much about Git; is there a way to preserve all the history while still reaping the benefits of that gc cleanup? That's a pretty big difference in memory space.
@Ollie That pattern looks like it's already caught by Potentially bad keyword in body and Potentially bad keyword in answer Append -force to the command word(s) if you really want to add the pattern you provided.
@Ollie Nope. As far as I've been able to determine, there's no way to make it happen on the repository data stored by GitHub. It's been requested as a feature, but hasn't been implemented by GitHub. There are potential reasons why not. Doing an --aggressive garbage collection on a repository can take a lot of CPU time (e.g. even with four cores working on it, doing it for the SD repo can take on the order of an hour). So, it's not something which GitHub should permit repositories to trigger at will.
OTOH, there are substantial resources, both GitHub's resources (particularly for CI testing) and everyone using the repository, which are consumed by having a repository which is so significantly larger than what it could be. So, an --aggressive pass is something which should be permitted/done at some points.
Perhaps it should be something that GitHub does every 10k or 20k commits, if the project has requested it, or if the repository is some multiplier larger than the total files on the current comment and has either not had an --aggressive pass performed or the current repo is X times larger than it was at the end of the last --aggressive pass.
@SmokeDetector I think this is positive. Video is 1 day old and has 10 views. Blog is 2 days old. So I'm not really buying their "I came across across this" line
@SmokeDetector A Google result indicates the user has contributed to the linked site. Although the specifically linked page doesn't show as this user's authorship. At a minimum, there's affiliation, which should be disclosed.
