Astronomers, as a group, are every bit as smart as rocket scientists. I've worked with both at NASA. I think they can handle the name change.

I searched for 'faster than light' on the CERN website, got articles posted in 2012, 2014. They put this new discovery to work right away!

taking a toll on privacy without bringing added security?
cameras don't add security for the citizens, that is, if someone's gonna get mugged, the camera won't stop it. The number of convience store robbers caught on tape is proof that cameras are not a deterent.
What it adds is statistical accuracy to the reports written by the cops as they examine each victim's violent death.

to feel that way. I'm 50-mumble, am learning java, Qt, c++, Apache, mySQL. Developing is what I do, and I'll not stop while my fingers can reach a keyboard. You're not old, kid.

try this: use several unrelated dictionary words, strip the vowels, and make it look like math: prpl=rckt*grnt (purple = rocket * granite) or some similar small set of rules. passowrds are secure, you only have to remember three words, and once you've memorized the simple rules, you can even write down the three words without compromising the real password. You also get longer paswords (14 chars is current recommendation).

Approx 20 years ago I wrote code for a system at work to do this, list was 100's of possible, including acronyms from work, userids and real names, stupid stuff like variations of 'password', etc. We had to do it cuz the customer (nasa) considered it "old hat, everyone else is doing this, why aren't we?"

I design realtime simulation kernels, and use a combination. One simple design a few years back: Separate processes (signals) perform drastically different tasks - sequence control, unique device or network I/O, etc. Separate processes were used because each task's execution profile is subtly different: network I/O is all about filling/draining or assigning buffers; device tasks are about waiting on physical devices that will get back to you just whenever the hell they want; sequence control is right now, don't wait, gotta stay on top of it or it all comes crashing down. Within a process, such as sequencing, a single, unique method of communication is used; In sequencing, I used semaphores/condition variables, etc, the Posix mantra we all know and love. They're usually the fastest, because I used separate threads for posting the zoo of myriad programs and functions in the simulation (the "payload" from the view of the sim kernel). Between the various critters in the zoo, shared memory and the various locking mechanisms preferred by their programmers. Each of these mechanisms is different, and the differences are just as important as the similarities.

Pidoma == Pulled It Directly From My... uh... Mid Air.

"Gunny! Double the charge in the clue cannon!"
Gunny: "Aye,aye cap'n!"
Capn: "And stand ready to reload. I think it's gonna take more than just a few rounds!"

The filter I propose isn't based on "submitted userid == any valid userid" but "submitted userid (is X% similar to) any valid userid". X would be a tunable value. In spam email filters, this usually works out to "if incoming email (is less than 20% similar to) previously accepted emails" or some such. It turns out that spam emails, even if containing dictionary words, still don't resemble human communications when bayesian statistics are applied to it.
Since the attacker doesn't know what userids are valid, the chance of any guessed userid being more than a few percentage points similar to a valid userid is vanishingly small.
Try it - pick a thousand "valid userids" out of the dictionary. Now pick a thousand more, omitting variations like "library - librarian". How many attempts will have more than a few characters in (almost) the same position and (almost) the same order as the "valid userids"?
The reason to use the userid list is because it is invisible to the attacker. The only result the attacker sees is suddenly one of the bots is blocked from the target host. No reason why, and no indication which of the last 20 or 100 or so userid attempts were "way off" and thus contributed to the decision to block.
A valid login attempt with a typo in the userid will be right in all but 1 or 2 characters nearly all the time. The bruteforce attacker will be wrong by more than 1 or 2 characters nearly all the time. Statistically, that's significant.
Since the block doesn't happen because of a single match or failure to match the list, the attacker learns nothing. The attacker doesn't even know the bayesian testing is occurring, thus the attacker would have no knowledge of which its attempted userids was valid or close to valid. It doesn't matter even if the attacker knows this filter is in place. Blocking the entire botnet will be a function:
Block = (v/b)*p
Where v == count of valid userids
b == count of hosts in the botnet,
p == average number of attempts required to guess a password.
B == point at which entire botnet is blocked.
With strong 8 character userids and passwords, the botnet would require billions of hosts in order to breech the system before being blocked.

I wasn't talking about the product to use to do it, but a detection approach that isn't present in any product I know of.
I described how to detect a specific kind of behavior that would be unique to the attack and the attacker, and to which attackers can not mount a meaningful countermeasure. Implementing the filter requires statistical analysis of not just incoming data, but also resident data (the userid list).

Would a bayesian filter work on this? The filter would match bad userids against the set of valid ones; bad userids that do not resemble any valid id by more than X% will score a demerit against the host that submitted the bad ID. Enough bad ids will probably identify an attacking bot, which can then be blocked. This is a slow defense, but the attack itself is slow and will probably statistically require far more attempts than a bayesian filter requires to identify the attacker.
Since the attacker doesn't know the set of valid userids on the target system, it's hard to see how this could be countered. Spam authors know how normal email looks, but still can't defeat bayesian spam filters.

and use the FORTRAN source to port to JS. Sure, it's like crayons and a big chief tablet, but IIRC that's what Colossal Cave was first coded in. I know I ran across a FTN version in 1979.