benchaney

It's not the same rule set though. The rule set they evaluated the AI on isn't one of the ones that it supports.

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.

No, it isn't related to superko. It has to do with Katago misidentifying the status of groups that are wrapped around an opposing group. I assume the name cyclic has to do with the fact that the groups look like circles. There are images in the paper, but it is a straight forward misread of the life and death status of groups that are unambiguously dead regardless of rule set.

There are two strategies described in this paper. The cyclic adversary, and the pass adversary. You are correct that the pass adversary is super dumb. It is essentially exploiting a loophole in a version of the rules that Katago doesn't actually support. This is such a silly attack that IMO the paper would be a lot more compelling if they had just left it out.

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

So instead of looking, like the author of these new options, for ways to make life for the bad guys harder we do nothing?

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".

This is essentially the Copenhagen interpretation of ethics. If you interact with a problem you become responsible for it. Improving someones situation is unethical while doing nothing isn't. This is because improving their situation makes you become responsible for it still not being good enough (according to the pundits who do nothing).

Can you be more specific about what particular anthropomorphizing you object to? The only place the author uses the word want is in describing the wants of humans.

That’s not how these kinds of trials work. The 13% figure comes from comparing the control and intervention groups, which were observed over the same period of time. The change in baseline mortality over time of the entire population isn’t relevant.

As a result of how the doors were selected one of them is more likely to contain the prize. That is information.

When one door was opened it revealed information about the other two doors.

The best probability estimate you can make is constrained by the information you have available. The new person showing up has less information than the existing constant, so it makes sense that their best estimate would be less precise. Similarly, if someone with x-ray vision walked up in the middle of the game, they could pick the car 100% of the time, because they have access to more information than either of the existing contestants.

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.

I've been in countless meetings with countless executives where the Google Sheet is busted out featuring engineering cost and tool cost and where cost/benefit is aggressively decided.

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.

If a "crappy" tool costs $10k/mo for the team and doesn't require much or any devops time to setup and maintain, it's likely cheaper than the $0/mo opensource but requires part or full time management option.

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.

Well, interpreting the title in that way is incorrect, so it seems like GP kind of has a point then.

Of course they would. The coast guard saves thousands of people every year. Most of them aren't billionaires.

I wasn't talking about you when I was saying that some people are blaming depositors. Some other commenters are really angry at the VCs that participated in the run. Their anger is understandable, but misplaced in this case IMO.

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.

SVB didn’t collapse because of the bank run. There was a bank run because they collapsed. It is true that the bank run may have accelerated the collapse slightly but they were in really bad shape before it started.

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.

Something that I think is pretty important to keep in mind is that when handling a possible XY problem, the key is communication. It is good to ask clarifying questions and questions about context when answering a question. It is good to provide context and be open to the possibility that your question is misguided when asking. Insisting that there isn't or isn't and XY problem and being condescending or combative is bad when asking/answering. I suspect part of the reason this link is so controversial is because the "hero" of the stories screws this up horribly.

Not in Tromp Taylor rules. Basically, this paper is cheesing a win with a loophole in a rule set that no one actually uses. Kind of a shame that it is getting so much attention despite the fact that the result is so heavily exaggerated, and the actual accomplishment is pretty minimal.

Everyone should pay for the resources they consume. Lower density requires massively more resources per person, so the people who want it should wind up paying more.

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.

I had that on the lowest setting already, it doesn't make a difference. I suspect that iOS already thinks its playing music quite softly and therefore won't know to down correct.

This is iOS. I haven't been able to find the ability to lower the minimum volume, and based on posts in the support forums, this seems like a common complaint that has yet to be addressed by Apple. That said, if you happen to know something that I don't, I'd be delighted to hear it.

Thanks for the recommendation! I'll definitely look into them.

I'm currently struggling to find usable bluetooth earbuds. One pair that I found comes flying out of my ears when I moved my head at all. Another is dangerously loud even on the lowest volume setting. The third came with a nonstandard (and therefore essentially useless) charger. It really seems like the entire market is flooded with garbage.

I don't think that's true. The default constructor for std::string creates an empty string. See: https://www.cplusplus.com/reference/string/string/string/

The semantics of c++ object initialization are such that a constructor will always be called.

I had heard that the concern was that there are services very early in boot that rely on /dev/urandom never blocking. I’m not sure how true that is, or why it is no longer a concern now.

This isn’t really true. git is relying on the second-preimage resistance of sha1 rather than the collision resistance. There are few attacks that theoretically are enabled by finding Sha collisions, by they aren’t really practical.

I think this is pretty misguided. If reliability is at all important, you need controls in place so that a single person making a single mistake won't cause an outage. Software engineers are human and humans make mistakes. That's just the reality. That isn't indicative of a lack of trust, but rather an acknowledgement of the constraints we are operating under.

Its possible that people subverting these processes are doing so because there are some actual flaws in the processes, but generally it is just as likely that they are being lazy or just don't think there is any way they would ever make a mistake. That isn't to say that it isn't worth evaluating the processes and the tradeoffs they impose, just that I think you are definitely throwing the baby out with the bathwater.

The issue is that there is no actual evidence that the data is being recorded improperly. Anyone can come up with a just so story to describe how the data could be corrupted, but writing such a blog post does not in fact put a burden on the people doing actual analysis to refute the claim.

This article doesn’t identify any statistical problems. It just points out that it would be possible to get a misleading result if you handle your data incorrectly. It provides no actual evidence that such a mishandling is actually occurring.

That is backwards, because the second person has their own biases, so that person is going to give evidence that is biased against the original claim. The only way to get strong evidence on both sides of the argument is for both participants to supply evidence that supports their own arguments.