Selling drinks in mislabeled containers should warrant a fraud report to your local consumer protection agency. A crowdsourcing app seems like the wrong tool here.

Interesting idea, but the results seem almost suspicious? even accounting for the extra bits used to store the 16-bit start value for each block - ~5% for k=64

The code does funky things, like the encoder updates the reference value for each encoded token, using the non-quantized value! [1] But the decoder just ignored all that. [2] how can this work?

[1] https://github.com/cenconq25/delta-compress-llm/commit/f185f...

[2] https://github.com/cenconq25/delta-compress-llm/commit/f185f...

How much would better would your hire be considering that you managed to check all 1000 of them, rather than just 50?

Assume that candidate fitness is a number normally distributed around 0 (half of them obviously being negative), that both you and the AI can perfectly pick out the best candidate, and that you picked the 50 to interview completely at random. The average actually seems to be around 40% better? Suprisingly decent. Is that improvement worth 1000 man-hours?

So attempt two here: maybe instead of each company sending candidates through an interview, there should be a common gatekeeper. All working age people take the same 1-hour AI interview, and the glorious overseer assigns them to the position they are best suited for.

(An actual answer here is you assess how important it is to get "the best candidate", and you interview enough people to get a reasonable approximation. The hour cost on your side is what keeps you honest. If wasting candidate time is free on your side, you're going to waste 500 man-hours of work for a 5% better result for you.)

Connecting verified humans for a mutually respectful chat is a trust problem that companies like LinkedIn should be creating solutions for, instead of offering both sides automated shovels to shovel slop faster.

Aren't you ignoring the reports of companies receiving thousands of ChatGPT-written resumes, bots sending applications, and interviews with applicants being live coached by AI?

This is a breakdown of trust on both sides.

I strongly assume the long tail is shifting and expanding now and will eventually mostly be software for one-off purposes authored by people who don't know how to code, and probably have a poor understanding of how it actually works.

  - 90 days is a very long time to keep keys, I'd expect rotation maybe between 10 minutes and a day? I don't see any justification for this in the article.
  - There's no need to keep any private keys except the current signing key and maybe an upcoming key. Old keys should be deleted on rotation, not just left to eventually expire.
  - https://github.com/aaroncpina/Aaron.Pina.Blog.Article.08/blob/776e3b365d177ed3b779242181f0045cd6387b3f/Aaron.Pina.Blog.Article.08.Server/Program.cs#L70-L77 - You're not allowed to get a new token if you have a a token already? That's unworkable - what if you want to log in on a new device? Or what if the client fails to receive the token request after the server sends it, the classic snag with use-only-once tokens?
  - A fun thing about setting an expiry on the keys is that it makes them eligible for eviction with Redis' standard volatile-lru policy. You can configure this, but it would make me nervous.

  - none of the "final" fields have changed after calling each method
  - these two immutable objects we just confirmed differ on a property are not the same object

Are any of these statements public, or is this all private communication?

> We are also working with GitButler team to integrate it as a research feature.

Referring to this discussion, I assume: https://github.com/gitbutlerapp/gitbutler/discussions/12274

Just a reminder that "this probably isn't worth replying to" should help a lot. But alas, it would directly reduce precious engangement.

Except that the generator script generates dates relative to time() ?

As a case study of Github UI friction, take merging a Dependabot PR from the PRs tab, with code approval required before merges. By my count this takes 6 clicks, and none of them approach a 'snappy' response time.

This is for mostly trivial single-line diffs. The entire thing could be 1 click - a hover preview on the PR list, and an 'approve and merge' button.

(To list them out: Click PR, "Files changed", "Submit review", "Approve", "Submit Review", "Merge")

E.g. https://www.anthropic.com/research/tracing-thoughts-language...

IMO Microsoft is right at the nexus of opportunity for solving some of the the large _problems_ that AI introduces.

Employers and job seekers both need a way to verify that they are talking to real identified people that are willing to put in some effort beyond spamming AI or wasting your time on AI run filters. LinkedIn could help them.

Programmers need access to real human-verified code and projects they can trust, not low-effort slop that could be backdoored at any moment by people with unclear motives and provenance. Github could help.

etc. etc. for Office, Outlook ...

But instead they've decided to ride the slop waves, throw QA to the wind, and call every bird and stone "copilot".

I'm amazed that a company that's supposedly one of the big AI stocks seemingly won't spare a single QA position for a major development tool. It really validates Claude's CLI-first approach.

E.g.

"A random drunk guy on the subway suggested that this wouldn't be a problem if we were running the latest SOL server version" "Huh, I guess that's worth testing"

What else could possibly have happened? Surely every one put their money in with the express intention of participating in a pump and dump.

Not taking the money would have been the high road. I don't think basing the economy on gambling and scams is good for society. But who could realistically claim to be a 'victim' here?

Here you are imbuing a "master of FUD" angle to a letter that might as well be written with crayons.

Showing substantial copyright infringement of the New York Times seems about the only thing it wouldn't be any good for.