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.

But just enough to pay for the litigation hassle. Judges (usually) pay close attention to the level of courtesy and maturity shown by the litigants prior to filing the suit. By bending over backwards being nice and trying to work things out, FSF has set themselves on the moral high ground, which (usually) pays back big time in the judge's decision.

If sufficient 'quality' checks are added to avoid the costs associated with mistakes, the process is 'factoring in' the cost as a normal operating expense. If the checks, testing, paperwork cost more hours to perform 'correctly' than a bug itself would cause when it occurs, then the cost of bugs is added to every release whether the bugs occur or not.
This is paying for bugs the hard way. This destroys the value produced by the good programmers by adding back the costs their good code saves. It's much easier to reach this threshold than most (non-programmer) managers realize.
The advantage seen by managers is a 'better' management of the process due to predictable schedules. The predictability comes from slack in the schedule created by low-bug software that doesn't cause delays. Illusionary schedule gain is then used up in the next release that has a (statistically insignificant) increase in bugs. Over time, it looks better but costs more.

No it isn't. Enterprise was used for ALT (Approach and Landing Tests) in 1980's, pre-first launch. Technically, it has 'flown', but not as part of a launch vehicle or into space. It was 'drop tested'.
Flight software testing only requires the computers and related avionics; currently, some of that is in Bldg 9 at JSC (I think - it's been years since I was there). Flight software testing is done in a variety of ways, including running it in the astronaut training simulators on emulated and actual flight hardware. One of the early flights, STS 2 or 3 IIRC, was delayed a coupla days cuz a bug in flight software. It had occurred in the simulator as well, but nowhere else. Flight crews didn't yet trust the realism of the GNC configuration in the simulator, so the simulator was considered the cause of the bug.
The SMS became a part of the testing process for flight software after that.
Again, this is personal comment only, does not reflect, and I am not authorized to speak for my employer or NASA.

A few years back, an open source project working on a railroad train/computer interface thingum got sued. Google it, it was even here on /.
In any case, you don't have to be directly in the crosshairs to lose money to a troll. In order to get the money, and to avoid losing, trolls will drag into the case most any name they can justify. It's a hassle, it's costly, even if you're not the direct target. In litigation like this, there's no assurance you'll be able to recover expenses if you're just collateral damage.

If you do it because you want to protect yourself legaly, you must know that you do something wrong.
SCOTUS has ruled that desire to exercise one's right to privacy is no indication of suspicious activity. I'm not mentioning US Supremes cuz it's enforceable worldwide, but to show that learned persons who studied the concept in depth disagree with your statement.
Remaining anonymous to protect oneself legally only implies concern and caution that someone is doing something wrong. Yeah, you might win in court, but it's better to avoid meritless litigation, patent trolls,etc altogether. It also helps avoid becoming collateral damage in the ideological/economic war between the proprietary and libre sides of the marketplace.

Using a fake name offers at least the possibility of deciding later if you want to be known with a particular project. Since you speak with both voices, your pseudonum can out your real name when you choose, and when it is to your advantage to do so.
This assumes, of course, you're not outed some other way first. But at least the possibility of remaining anonymous is there. Use your real name first, and you can't ever take it back.