JZerf

This isn't entirely true. Most (all?) of the games require the Steam client which they are constantly updating and increasing the system requirements for. Systems that could previously run the Steam client and games just fine can no longer run those same games after a while. If I remember correctly the Steam client no longer supports systems running Windows XP, Windows Vista, OS X versions before 10.10, etc... to name a few. This is currently preventing me from running some games I've purchased and I will no longer be making any purchases on Steam until they resolve this problem.

I would be careful about auto-closing issues after a year. It's quite possible that some issues are genuine but for various reasons (time required, difficulty of the problem, etc...) people might not do anything about it right away. You can check the feature requests or bugs databases for large projects like Firefox or WebKit for example and find plenty of entries that are several years old yet those entries often still have comments being made which shows that at least some people care about them.

If you're reasonably certain that the request is being made by a malicious bot, you could try responding with a ZIP bomb [1] if HTTP 1.1 or newer is being used and the bot accepts compression. It can cause problems for several browser engines.

[1] https://blog.haschek.at/2017/how-to-defend-your-website-with...

Yeah, I'm serious. Even with Twitter, for example, currently allowing accounts to be created and posts to be made for essentially free, real accounts and posts still outnumber those of troll farms and bots from what I've seen. If those troll farms and bots actually had to pay, I imagine there would be far less. I also imagine that those troll farms and bots are less influential than real people. I believe that the endgame is that if a website operator takes enough measures to stop troll farms and bots, the operators of those troll farms and bots will eventually run out of resources and be forced to curtail their activity.

You're right that gating speech behind money could potentially be bad and make problems worse but I only offered that as one suggestion. Instead of or in addition to using money, you could perhaps make a system that uses some type of karma/reputation for instance. Those could still be done anonymously.

I'm already using this timestamp technique on my website and so far no bot operator has bothered trying to work around this. However even if some bot operator were to specifically target a website using this technique and try to decrease the timestamp, I believe you could still force a bot to wait by just changing the website to use something like a cryptographic nonce that includes a timestamp instead of just a simple timestamp that can be understood easily.

Website operators could still take measures to stop abuse from troll farms as well while still allowing people to remain anonymous. A website operator like Twitter for instance could perhaps require users to make a small micro-transaction before allowing someone to make a post. Some equilibrium for the cost of a post could probably be found where most legitimate users would still be willing to pay that cost but most troll farms would not.

I don't see any good reason why people can't be allowed to remain anonymous while still allowing website operators from taking measures to stop bot abuse. CAPTCHAs can already stop many bots. Other commenters have also mentioned that things like Proof of Work systems and micro-transactions could also stop bot abuse. These don't necessarily require giving up anonymity.

I also use essentially the same technique (although I have the server generate the timestamp instead of using JavaScript) on my website and concur that this is a highly effective technique for blocking bot submissions.

The title should really be changed to say that it's the world's fastest single engine business jet. Both Gulfstream and Bombardier make considerably faster twin engine business jets.

I wrote that program in the hope that it would better illustrate why some of the benchmarks on the site aren't very good since for some benchmarks the program performance is highly dependent on the libraries being used and not the programming language implementation itself. I know at least one person opened an issue regarding this on the site issue tracker at https://salsa.debian.org/benchmarksgame-team/benchmarksgame/... and I also believe I recall one of the Rust regex crate developers mentioning this too.

I know that using PCRE2 in a Python program isn't typical but the Benchmarks Game does allow using other libraries and many of the previously submitted programs have been doing this for a long time already. The pidigits benchmark is the other benchmark that is heavily dependent on the libraries being used as is illustrated by their being a nearly ten way tie for second place by a bunch of programs that all use GMP.

I submitted the C binary-trees program. I did check to see if OpenMP increased the performance and it most certainly does. Just looking at the CPU and clock time usage on https://benchmarksgame-team.pages.debian.net/benchmarksgame/... you can see that the clock time used is about one third of the CPU time that was used.

You're probably referring to the C program I submitted.

OpenMP is only available for C, C++, and Fortran so that is why most programs won't use it. However most of the other programming languages have their own ways for doing multi-threading and many of the programs for this benchmark do make use of them.

The rules at https://benchmarksgame-team.pages.debian.net/benchmarksgame/... request that submitters use the same algorithms as existing programs and I try to follow that rule. I believe all the binary-trees programs are using recursive functions so naturally I did the same to avoid breaking the rule about using different algorithms.

I'm the author of that C program. You are correct that the programs are using somewhat different algorithms (and as an author for many other submissions on the site, I can say this is true for many of the benchmarks on the site).

In addition to what you've already mentioned, if I'm not mistaken, the programs also take different multi-threading approaches. One of the tasks in this benchmark involves reversing three very large strings. My C program took a fairly simple approach and does that reversal process for each string serially but processes multiple strings in parallel. The Rust program on the other hand does the opposite and does the reversal process for each string in a parallel manner but only processes strings one at a time. The algorithm the Rust program uses is more complicated which results in a considerably larger program size that also is a bit less flexible regarding the input (it assumes each line of input is 60 characters whereas my program will work with lines of any length) but it results in better CPU utilization, less clock time, and less memory use. I've been meaning to submit a faster C program using this faster algorithm but have simply been too busy with other things.