I can reproduce this by covering one of the exterior mics used for ANC when there is a decent amount of background noise in the environment. It results in feedback that causes a high pitch ringing.

The AirPods Pro 2 don’t have this same issue. I can’t reproduce the same behavior regardless of how I cover the exterior on the pro 2s.

Dynamo is AFAIK, not used by core AWS services.

Causal profiling is something I infrequently use but I have been able to apply it outside of micro benchmarks in an orchestration system.

If you have a business process that is complex and owned by many different groups then causal profiling can be a good tool for dealing with the complexity. For large workflows in particular this can be powerful as the orchestration owner can experiment without much coordination (other than making sure the groups know/agree that some processing might be delayed).

What is your point?

Surely you’re not trying to draw some conclusion between an entire countries modern day medical field and a theory a person proposed in the 1800s, right?

Hi, not the parent poster here. I believe the argument being made is that diagnostic criteria, and diagnoses themselves, can be shaped by cultural norms. As the Overton window shifts, so do the thoughts and behaviors that we deem pathological.

> Surely you’re not trying to draw some conclusion between an entire countries modern day medical field and a theory a person proposed in the 1800s, right?

That would depend on whether anything has changed since the 1800s. But that's very clearly not so -- consider that recovered memory therapy (https://en.wikipedia.org/wiki/Recovered-memory_therapy), based on as much science as drapetomania, was practiced in the 1990s, and still has adherents today.

Also, for human psychology to be regarded as a medical field, it would have to be based in science. But human psychology studies the mind, therefore by definition it's not based in science.

I think research consistently shows that adjusting for inflation young adults make less than previous generations.

> women apply, and meet the necessary academic standards, at a much higher rate than men

This is the more interesting observation. Why is it that boys are struggling in school? Why are we not doing anything about it?

Not a particularly relevant question if we're eschewing DEI and just letting the chips fall as they may / operating in a meritocracy.

I don’t know if I buy that this is a conspiracy with bribes but killing the grants reduces the rate of growth of energy generation which reduces its future supply.

Adding energy capacity reduces the prices at which firms can sell energy since there would be more supply. Removing the grants means that existing energy generation firms need to worry less about how increased supply would harm their prices.

This mostly mimics my own experience. I’ve mostly gotten value out of handing off planned/scoped coding tasks to LLMs. It’s faster to have the LLM generate code and the quality is usually fine if the task is properly scoped.

Actually writing software was only like 15-20% of my time though so the efficiency wins from having an LLM write the code is somewhat limited. It’s still another tool that makes me more productive but I’ve not figured out a way to really multiplicatively increase my productivity.

As far as I know, by default Git doesn’t enable the “reuse recorded resolution” feature so if you made a change to the first commit you’d have to manually do the same thing for any subsequent commits.

If you have 5 different branches, sure. Again, the reason you create a bunch of branches for separate review is because that's what the "git forge" abstraction generally expects. It's not actually how code reviews are done by the people who wrote it.

You can also just enable that feature (rerere).

What is the "right" way to do it then?

Also probably most of us are stuck with whatever git*.com supports anyways...

Basically see how the LKML works. Individual commits are typically expected to be self-contained to the best extent possible, with patch sets or patch series being used when that's not feasible. Patches are usually sent over email, but there are a lot of ways to do it.

It's not an ideal way to operate for most shops, but there's really no reason you can't have a PR/MR/changelist/whatever that is a single branch with X commits on it and you ask the reviewer to review each commit individually instead of as a whole unit (as GitHub and other forges usually expect you to).

That and don't let reviews pile up such that you have 5 dependent in-flight reviews, something else is wrong if that's happening.

> Basically see how the LKML works. Individual commits are typically expected to be self-contained to the best extent possible, with patch sets or patch series being used when that's not feasible. Patches are usually sent over email, but there are a lot of ways to do it.

What is the advantage to this, other than maybe being easier to send over email?

To me, the important part is you have a logical "unit of change" that you're proposing to the codebase, whether that's a single commit or a branch or a jj bookmark or whatever seems more an artifact of the underlying transport layer (email or github or whatever) than any kind of intended functionality of the design.

There's quite a few advantages to having a single commit being the unit of change:

- reverts are significantly easier

- bisect will work because the code is expected to code/run at every commit

- rebase becomes easier in the common case

- the transport does not matter, at all. Fully anonymous contributions are possible

- commit messages are easier to write because the changes are smaller and more focused

Several commits could encompass changes necessary to make a particular feature work (ie. patchset) but because each commit is self contained they can be reviewed and tested individually (in order, usually) instead of a one big diff. It's easier on the reviewer, though there's likely a bit more overhead.

Use `--update-refs`.

Think about the word "branch". If you have a linear sequence of commits that's one branch by definition. But you go and label the middle of that branch as branches too and then get annoyed when git, you know, does some branching there.

> It's not actually how code reviews are done by the people who wrote it.

What do you mean by that? Even if you do review by emailing patchsets those are still managed locally using branches, to my knowledge.

I mean the unit of review is the patch (set), which does not necessarily have a branch associated with it. You can use a branch, but you could just as easily send commits from master and the reviewer can apply them directly on their master branch if desired. The idea of "branch per reviewable unit" was largely created by GitHub.

> The CLI has nice syntax highlighting to show you the shortest valid prefix, so for example, right now I have something that looks like lzrvnkxl but the initial l is in purple, while the zrvnkxl is in grey. This means I can just use the l when referring to the change. That can be harder to demonstrate in a blog post, which can't know how to highlight this, and so often they have no highlighting.

This is such a simple UX feature that I have ended up using all the time after I switched to jj a few months back.