tomsmeding

Dialogue is super effective for this, but it's also a skill: you're suddenly a teacher. You should have no judgement of the other not knowing something, and be able to effectively build up that delta in a way that is understandable and interesting to the other. This can be more difficult than it sounds, but it's also rewarding.

I've been doing some benchmarking recently and I've observed that on certain workloads, my CPU cores are not equivalent. (And this is an Intel CPU from 5 years ago, all cores are the same on paper.) In a particular very bad case I have a reproducible 50% performance difference between (physical) core 0 and core 5.

You might want to taskset to particular cores too, especially if you are looking at computational code with many almost-but-not-quite-random memory accesses.

This is hilarious as someone who hasn't used the gmail composition interface in years. I left it to use my own domain, but it seems like I get to enjoy this mess with popcorn too instead of tears.

Possibly, but at least a cursory internet search of the person's name doesn't being up this article. Which is a good thing.

It's an existing joke: https://www.reddit.com/r/keming/

Similar experience to sibling: a disinterested human isn't going to ask for 30 different detailed things to add to, or change in, the paper that could technically be improved but aren't worth the additional page real estate. An LLM reviewer definitely does this.

I can't help but read VSMOW as Very Standard Mean Ocean Water.

It ought not to, indeed. However, if you want "save my file" to include awareness of other developers concurrently working on the same project -- even the same file -- with a decent way to handle conflicts, it suddenly becomes complicated. Git is probably not the optimal way of designing a UI around this, but it's not like this is an easy problem.

scḧon

Egraphs fundamentally require a first-order language, i.e. no lambda functions, because they do not handle scoping well. There are workarounds that work in some circumstances, but no general solution (that I'm aware of).

Additionally, egraphs express rewrites on a single language. Compilers are fundamentally translators between different languages; how do you write typechecking as an egraph rewrite rule? Or conversion to assembly?

The method proposed is just A - B mod n. The two are entirely equivalent.

Do you really think that `*(a + i)` is clearer than `a[i]`?

It is thoughtful, that's not the problem. It's just not written in the standard language "written English", but instead in "spoken English" with some attempts towards the former ("My final thought on ...") that sound like someone trying formal writing for the first time.

Well, it is the type of that, in TS syntax. Few are the statically-typed languages that can even express that type.

Hypothesis: that Qualcomm and that Macbook have higher memory bandwidth than your i9 system. This is dependent on your memory and your mainboard, not so much on the CPU itself. Perhaps Teams just uses way too much memory, and actually uses it all the time.

> According to Breyer, the existing voluntary system has already proven flawed, with German police reporting that roughly half of all flagged cases turn out to be irrelevant.

A failure rate of only 50% is absurdly good for a system like this. If we have to:

> Imagine your phone scanning every conversation with your partner, your daughter, your therapist, and leaking it just because the word ‘love’ or ‘meet’ appears somewhere.

then apparently either there are so many perpetrators that regular conversations with partners etc. are about as common as crime, or such regular conversations don't have such a high risk of being reported after all.

I don't think chat surveillance is a good idea. But please use transparent and open communication. Don't manipulate us just like the enemy does.

That, and the main author of CompCert [1], as well as (apparently) the author of the original threading support in the Linux kernel [2].

[1]: https://en.wikipedia.org/wiki/CompCert

[2]: https://en.wikipedia.org/wiki/Xavier_Leroy

Nitpick, but IEEE float operations are commutative (when relevant and appropriate). Associative and distributive they indeed are not.

Sure, but that has a resolution of seconds at best. The coil whine in the power electronics is milliseconds-accurate.

There is some recent work on this too: https://dl.acm.org/doi/10.1145/3632880

I don't doubt there are interesting things in that book, but this particular one feels just so unsurprising: people are likely to notice that the flip-flops in the two bins are remarkably similar, and see that one is cheaper. They don't see a reason to buy the more expensive one so they choose the cheaper one.

It would have been more interesting had people chosen the more expensive one. There is a folk theory that you can get people to do this if you add an even more expensive option -- the "middle" option is the most attractive.

This just sounds like you haven't been using transactions. SQLite upholds transaction guarantees.

Not quite this, but still relevant: https://www.ty-penguin.org.uk/~auj/spigot/

I don't think ChatControl is a good idea. I also think that if you want to convince people of that, using the same misleading language tactics as the other side is not the way to go.

> These scanning systems get it wrong most of the time. [...] Irish law enforcement confirms this: only 20.3% of 4,192 automated reports actually contained illegal material.

Wrong most of the time that they report something. Technically correct, although a somewhat tricky formulation.

Literally next paragraph:

> Even with hypothetical 99% accuracy (which current systems don’t achieve), scanning billions of daily messages would generate millions of false accusations.

This is a different accuracy percentage: here the author means 99% of all messages, not only the reported ones, which the previous 20.3% referred to. Furthermore, these two paragraphs together sound very fishy: if current systems are not accurate enough to generate "millions of false accusations", presumably (?) they generate at least that. But with the 20.3% true positives fraction, that would mean hundreds of thousands true accusations per day.

Which part am I misunderstanding?

> Its also inconvenient enough that most people wont bother. > in Arch AUR is very much a non essential component.

While somewhat true, we are talking about a user who has installed Arch on their machine. If a user wanted to not bother with installation details, they would've installed Ubuntu.

But... it's a title, not a sentence. Many book titles are even a single word, which is even less a sentence. Why would a grammatical convention for sentences apply to book titles?

Clicking links from an email is still a bad idea in general because of at least two reasons:

1. If a target website (say important.com) sends poorly-configured CORS headers and has poorly configured cookies (I think), a 3rd-party website is able to send requests to important.com with the cookies of the user, if they're logged in there. This depends on important.com having done something wrong, but the result is as powerful as getting a password from the user. (This is called cross-site request forgery, CSRF.)

2. They might have a browser zero-day and get code execution access to your machine.

If you initiated the process that sent that email and the timing matches, and there's no other way than opening the link, that's that. But clicking links in emails is overall risky.

It is sometimes possible to detect server-side whether the script is being run immediately with `| sh` or not. The reason is that `sh` only reads from its input as far as it got in the script, so it takes longer to get to the end than if you'd curl show the result in the terminal directly (or pipe it to a file).

A server can use this to maliciously give you malware only if you're not looking at the code.

Though your point about trust is valid.

Not sure if this is the one you meant, but https://esolangs.org/wiki/Shakespeare is relevant.

Group selfies are a thing, but one-person selfies also are.