Edit: This is confusing for some people because there are essentially two rule sets with the same name, but Tromp-Taylor rules as commonly implemented for actual play (including by Katago) involves dead stone removal, where as Tromp Taylor rules as defined for Computer Science research doesn't. One might argue that the latter is the "real" Tromp Taylor rules (whatever that means), but at that point it is obvious that you are rules lawyering with the engine authors rather than doing anything that could reasonably be considered adversarial policy research.

That said, the cyclic adversary is a legitimate weakness in Katago, and I found it quite impressive.

Random brute force attempts against SSH are already a 100% solved problem, so doing nothing beyond maintaining the status quo seems pretty reasonable IMO.

> I don't buy your argument nor all the variation on the same theme: "There's a minuscule risk of X, so we absolutely nothing but saying there's nothing to do and we let bad guys roam free!".

Setting this up by default (as is being proposed) would definitely break a lot of existing use cases. The only risk that is minuscule here is the risk from not making this change.

I don't see any particularly reason to applaud making software worse just because someone is "trying".

Your last paragraph isn't correct though, By switching you go from a 1/3 probability to a 2/3 probability. Based on the information the original contestant has, switching gets the car 2/3 of the time.

That is the problem though. It isn't the engineering cost vs the tool cost. It is the engineering cost vs the tool cost PLUS the engineering cost of dealing with the tool once you buy it. Everything you have said so far leads me to believe you are missing this aspect of the cost of buying the tool.

You are right that there is a time and a place for buying over DIY, but in order to make those decisions reliably you need to know how much effort is going to go into dealing with the tool once you buy it. This isn't something you can figure out using Google sheets, because you have to actually evaluate the tool and get a sense of how dangerous the foot guns are.

You're probably right about scaling though. That sounds like an area where the ROI of paying someone else to do it is pretty good.

This is a total fantasy. There is no reason to expect the crappy enterprise tool that costs money will save time relative to the open source tool. In my experience enterprise tools takes more time and average and cost money. This line of reasoning (frequently pushed by dishonest sales people) is seductive because it tricks you into ignore the time cost of dealing with enterprise, not because it is correct.

> What other model leads to instant death, damage to their entire customer base, and collateral damage to the broader system, when a certain number of customers decide to go elsewhere?

None of these things happened because some customers decided to go elsewhere. They were going to happen anyway. SVB was in really terrible shape and was already in the process of collapsing.

A lot of people want to blame depositor panic, but I don’t think that is really fair. In a properly managed bank, the assets exceed the liabilities, which means that if people want their money out, the bank can liquidate their assets to pay them and still have money left over. SVB’s assets are worth far less than their liabilities (to the tune of nearly $100B dollars by some estimates). Panicking depositors didn’t cause that.

Nobody is advocating forcing everyone to live in dense housing. Our current political/legal system massively favors and subsidizes lower density. Removing that favoritism is not unfair at all.