I used to have a habit of imposing an unnecessary ordering structure on my work product. My stack of changes would look like A -> B -> C -> D, even if the order of B and C was logically interchangeable.

jj makes DAGs easier to work with because of how it handles conflicts and merges. Now I feel empowered to be more expressive and accurate about what a change actually depends on. In turn, this makes review and submission more efficient.

Scalable systems need to use heuristics to catch threats. Needing concrete evidence in every case means that an enormously higher amount of malicious resources will not be flagged.

There is a policy argument as to the right balance of concerns here. But there is a clear trade-off to make.

Libel suits can be financially catastrophic, so even a tiny false positive rate could present risk that disincentivizes producing such software at all.

And a threat detection mechanism that has a 0.0% false positive rate is conservative to the point of being nearly useless.

Agreed. Boards like this are helpful for getting RISC-V to the next stage, where it could make sense for more users.

In many countries, it seems that the leader has near total control over candidate selection, and dissent is punished ruthlessly.

In the US, it's easier for a member of Congress to openly dissent against the President's agenda. This was a major thorn in the side for e.g. Joe Biden.

Some Republicans today fear dissenting (though of course, most are enthusiastically on board), but I'm not sure that it would be any different in a place like Canada or the UK.

If there is an objection that giving cash is equivalent to subsidizing Twinkies, I would push back. Child tax credits are in many ways economically equivalent to cash transfers, but we don't usually see arguments that this is a subsidy for Mountain Dew.

Like many Americans, I grew up in a town where unhealthy eating was a major part of the social rhythms of life: a bag of buttery popcorn at the movie theater, an ice cream at the zoo, things like that. Not having the means to participate in these simple pleasures is a kind of social deprivation. I view redistributive programs as a tool to lessen the gap between families. Food regulators can handle the junk food problem.

The success of SNAP comes despite its inherent inefficiency, friction, and the indignity of its limitations. We structure the program the way we do in order to mollify voters who twitch at the idea of the poor ever enjoying anything.

Inequality isn't just about healthcare costs, biological metrics, etc. It is also deeply corrosive socially and psychologically, and this side of things is systemically underappreciated in policy circles.

To be sure, our food and diets are bad. Americans broadly should eat healthier. But are society's interests really better served by insisting that a poor child not be allowed to have a cake and blow out the candles on his birthday, the way all of his friends do?

The leading AI labs are not killing IP. They are taking IP and reshaping/combining it to produce their own highly lucrative proprietary IP package which they sell to you.

The mirror image of IP defenders are AI boosters who argue against IP when it comes to slurping up media but squirm when you say "ok, then publish all of the inputs that go into making your frontier models, and publish the model weights too."

A small anecdote: when ChatGPT went down a few months ago, a lot of young people (especially students) just waited for it to come back up. They didn't even think about using an alternative.

Isn't this what ffmpeg did recently? They seemed to get a ton of community support in their decision not to fix a vulnerability

Getting rid of the staging area and allowing conflicts are the biggest wins for me day-to-day. No more stashing/popping or littering my workspace with WIP commits. It's so easy to whip up a change, send it for review, then ping-pong between writing new code on top of the change and making reviewer-requested edits further down the stack.

There have been many occasions when working in a very verbose enterprise-y codebase where I know exactly what needs to happen, and the LLM just types it out. I carefully review all 100 lines of code and verify that it is very nearly exactly what I would have typed myself.

If the false positive rate is consistently 0.0%, that is a surefire sign that the detector is not effective enough to be useful.

If a false positive is libel, then any useful malware detector would occasionally do libel. Since libel carries enormous financial consequences, nobody would make a useful malware detector.

I am skeptical that changing the wording in the warning resolves the fundamental tension here. Suppose we tone it down: "This executable has traits similar to known malware." "This website might be operated by attackers."

Would companies affected by these labels be satisfied by this verbiage? How do we balance this against users' likelihood of ignoring the warning in the face of real malware?