mwt

Your explanation doesn't really distinguish high-level human play (not obvious cheating) from engine play (obvious cheating). There are probably plenty of games in which your first 20 moves (or 5-10 for me) are in GM databases and evaluated favorably by the engine, ass a 2200 you're probably booked up pretty well. But you know computer moves aren't so common in openings; they're much more common in complex middlegames and late games when the computer can calculate more combinations that we can and is able to produce lines that break intuition and principles but are strictly best.

I see a lot of comments about the general topic, but none on the actual tool, which appears to have no (public-facing) updates in about three years. Presumably it could be a tool that incrementally improves over time with the explosion of data lichess has, but surely there would be a single commit since 2019. Do we know that this is what's actually running on lichess's backend today?

What time controls do you play? Cheating is much more prevalent in rapid than blitz, with correspondence probably being the worst of all. It's unlucky for people who don't like speed chess.

The only solution to this problem I'm aware of is developing/becoming a part of a community of people you trust. Of course, that's hard and comes with plenty of limitations.

Lastly, please don't get your expectations up. This is a hugely unsolved problem on lichess and the history of its and chesscom's efforts do not inspire confidence. I noticed this repo has no updates in the past three years, during which lichess has maintained its reputation of having tons of cheaters. Chesscom has a team and probably more tools (proprietary, larger company, etc.) but the best case scenario still involves cheaters getting several games in, wasting your time along the way.

I'm not a lawyer or a smart individual but oh boy that's a red flag, just like several other details you offered. With the information available, it sure seems like that's a dependency that should never be brought into a project.

What was the license of this package?

I was also surprised to learn (years ago) BuzzFeed has a decently-sized investigative team

That's not what motivates me, thanks, but it's clearly what motivates the industry

I've never worked somewhere in which mentorship was formalized *and* something for which there was a clear relationship to promotion. Not saying that the only way to get me more into it is by paying me or threatening compensation, but when push comes to shove the things that aren't tied to promotions are the first to go (especially in management).

And also, I've noticed my desire to mentor has (slowly) gone down over time. I'm trying to avoid ageism and certainly not assume that seasoned COBOL devs are less eager to mentor than junior devs, and I hope I'm clear in that I'm projecting what is something of a personal limitation onto my future self.

I don't doubt there's some people like this, but if I cut my teeth on mainframes 2-3 decades ago and was nearing retirement, I'm not sure I'd have the patience needed to be a good mentor. (I'm sure I *should*, but as a personal limitation I might not, and I'm probably not alone.)

There's also an issue of community/people you'd work with. (Fair or not) there's a strong perception that the current COBOL devs are people that are close to retirement and not exactly eager to take a junior dev under their wing and give the sort of mentorship that one can't get from textbooks and hobby projects. I'm not a COBOL dev or part of the community at all, but I doubt it compares at all to the language-based communities that people around here are more familiar with.

There have been some other recent threads on similar subs from people who actually tried to make the jump to a COBOL role in the past year and the social aspects were brought up again and again, on top of the technical issues ... I can dig a few up if people are at all skeptical.

Outside the context of crime: loitering, yes, foot traffic, not really. It's possible this particular phrase is a euphemism used in crime reporting, I don't know, but if it is I don't know why they wouldn't just say "officers no longer suspected dealers were using this place" / "informants/word on the street was that distribution moved to xyz ... "

That sentence read strangely to me as well; I think foot traffic is great and my favorite places in America are built around promoting it.

I'm with you, but I wonder if this is the sort of "only people on this site care and the vast majority of the readership wouldn't use it" thing ... I'm not sure it is, but it could be, and I wonder if somebody with their ear to the ground/access to more analytics knows.

You might be right but that isn't even what I'm saying here. Your description could apply to many sectors of the economy, most of which they have a some amount of presence in

That is the design: business units that are not viable on their own are subsidized by a few cash cows but might gain market share and be profitable in the future

I don't see any analysis?

Folding@home would love to take a swing at a sliver of that compute

Worth pointing out that this is dated Feb 22, 2022, when things in this space were a bit different.

If this sort of thing was effective (and legal, I don't know) you'd think it would be seen regularly.

I can't decide if it's better explained by the power of corporate(/political) PR or simply that people don't actually care

Are they adding costs? The baseline of ~3% to wire money seems already high.

I'm pretty much listing off the subheaders, none of which I dispute nor seem to be disputed by the general consensus. What is still unclear, however, is how to draw an arrow from "I love working here" to "the product is great." I think everybody here has experiences in companies/roles that are large and/or opaque enough to muddy that cause-and-effect.

What obvious truth is acknowledged here?

- They pay extremely well and offer great benefits to their engineers.

- They (not coincidentally) are able to hire great talent.

- That their platforms offer as much reach as any other company

None of this is new information and neither "great company" nor "does great things" follow from what's provided here.

And on your blog you can choose to use common abbreviations like OS, BIOS, and GPS without spelling them out.

It's pretty clearly automation gone wrong. I didn't specify if it's a matter of neglect or abuse.

_They_ didn't _do_ it per se, it was done by a third party (probably for hire) and it seems to have been the result of automation gone wrong (not an excuse IMHO). Of course they bear responsibility for the work they contract out and the third party bears responsibility for their automation being worse than ineffective. But the facts do not seem to point to an evil person in a basement initiating the takedown themselves.

> They need to be sued with the help of NumFOCUS lawyers.

This seems like it could be costly and quickly easily eat away at the small amount of revenue they take in (something like $5MM, mostly from grants and donations) compared to supporting open source projects that are desperate for support.

> You mean the entire developer's thought process behind a change will be represented by a single 12x16 picture?

No, look at the log of FastAPI (or even gitmoji itself: https://github.com/carloscuesta/gitmoji) and you'll see that i.e. the bug emoji serves *only* to replace "bugfix: " at the beginning of the commit message, not the entirety.

Honest question, do you really expect your history to be meaningful long-term? Or are you simply taking the approach that the commit message is meaningless and a developer instead use GitHub search to find a PR relevant to a change they're investigating.

For example, I pulled up one of your projects and the history (https://github.com/transitive-bullshit/kwote/commits/main) is less than meaningless, compared to i.e. using emojis as a shorthand (https://github.com/tiangolo/fastapi/commits/master)

Yeah, I mean my comment more as a criticism of universally squash-merging as a policy since, not so much an endorsement of it in general. I run into cases like you describe pretty often, and I doubt I'm alone. Switching to squash-merging has some benefits but it's also brought out a fresh form of hell when too many changes are happening in too many branches at once.

> github's naive view of history where it shows things in a bafflingly obtuse linear

This hits home, it pretty much describes how I visualize logs in my head (compared to the visualizations I see that are more 2-D, branching off and merging together, etc.). I have a hard time working with some of the more advanced features because of this, and it'll probably always be an uphill battle to shift my thinking from linear to not-so-linear ...

Yep, `--allow-empty` is my preferred solution. It's unfortunately not up to me how other people choose to do this

This is from 2014, but I guess not much has changed since then.