shawnz

I confess I have instructions in my CLAUDE.md to avoid such cliches. But I think it's important to consider that we don't really know what subtext an LLM is associating with a given idiom/analogy/etc. It could be much different than the subtext a human would associate with that choice of words, conveying additional details which are only meaningful to the LLM itself. So impeding its ability to talk in the manner it prefers could subtly hinder its performance.

Related, in a sense: "Reconstructing the Menu of a Pub in Ancient Pompeii" https://news.ycombinator.com/item?id=26210774

See also this exploration from Strange Aeons: https://youtu.be/vMOMa-4D1yQ?si=t1uxfY1pEDh2a44Y

Yeah, I know chargebacks are a frequent vector for abuse and of course I don't mean to imply that customers doing chargebacks ought to always implicitly be given the benefit of the doubt.

Given that you are responsive to inquiries, it makes sense that you'd rarely if ever have a legitimate chargeback -- because there's no reason for a customer to resort to chargebacks if the vendor is willing to work with them to resolve legitimate issues.

But I know of many examples of people needing to resort to chargebacks due to ineffectual customer support, and then having their accounts banned and being cut off from other unrelated services from the same vendor as a result. I don't think that's an appropriate response and vendors should be careful not to let that happen if they instate such a policy.

You'd better be promptly responsive to legitimate customer support inquiries if you are going to have a policy like that

Your entire codebase is already at risk of being blocked by a spinlock or CPU-intensive operation, so what's the difference?

cPanel is 30 years old, are you saying it's not battle tested, boring, proven, and widely audited?

In fact PHP is only a few months older than it.

Thinking summaries might not be useful for revealing the model's actual intentions, but I find that they can be helpful in signalling to me when I have left certain things underspecified in the prompt, so that I can stop and clarify.

Note that for Claude Code, it looks like they added a new undocumented command line argument `--thinking-display summarized` to control this parameter, and that's the only way to get thinking summaries back there.

VS Code users can write a wrapper script which contains `exec "$@" --thinking-display summarized` and set that as their claudeCode.claudeProcessWrapper in VS Code settings in order to get thinking summaries back.

Supporting only Server grade hardware and ignoring laptop/consumer grade GPU/APU for ROCm was a terrible strategical mistake. A lot of developers experiments first and foremost on their personal laptop first and scale on expensive, professional grade hardware later.

NVIDIA is making the same mistake today by deprioritizing the release of consumer-grade GPUs with high VRAM in favour of focusing on server markets.

They already have a huge moat, so it's not as crippling for them to do so, but I think it presents an interesting opportunity for AMD to pick up the slack.

I don't think it's a single axis even in the original poster's conception, since you could be both incorrect and also not pragmatic.

But if a fix needs to be described as pragmatic relative to the alternatives, that's probably because it couldn't be described as correct. Otherwise you wouldn't be talking about how pragmatic it is.

Damn, I was working on exactly the same idea not too long ago. It never really went anywhere because I couldn't find a speech rate detection algorithm that worked well enough to make it practically useful. I hope some more mathematically inclined people take a look at this idea and find a way to make it work.

While I agree with the sentiment here, you might be interested to see that there are a couple hack approaches to override Claude Code feature flags:

https://github.com/anthropics/claude-code/issues/21874#issue...

https://gist.github.com/gastonmorixe/9c596b6de1095b6bd3b746c...

I mean, yeah, it's entirely possible that the operator is a teenager, isn't it?

This is essentially Jevons' paradox

If their whole business is based around being an established standard and making users happy is not a relevant goal, then why do anything at all? They already are an established standard, so why would they bother taking any further actions whatsoever, making any changes or rolling out any new products? Clearly they are trying to achieve something, right? So what is it?

AFAIK my humidifier uses an ESP32 chip.

Wow, these preassembled ESP32 plus touchscreen boards are extremely cheap, and there are tons of them in all kinds of different form factors on Amazon. I didn't realize this kind of thing was so plentiful, this seems like a great way to bootstrap many kinds of electronics/IoT projects

IIRC Apple has attempted to implement some defences against this, for example by requiring the passcode to be inputted before an update can be installed to prevent another San Bernardino scenario. A cursory search indicates that they also have some kind of transparency log system for updates, but it seems to only apply to their cloud systems and not iOS updates.

The table has two categorizations: "In transit & on server" and "End-to-end". The former, which covers iCloud backups in the default configuration, is explicitly NOT end-to-end, meaning there are moments in time during processing where the data is not encrypted.

However, iCloud backups actually are listed as "End-to-end" if you turn on the new Advanced Data Protection feature.

What's the joke here? If they are better than average drivers, that's a huge win which improves road safety for everyone

Furthermore it seems like it's specific to Azure AD, and I'm guessing it probably only has effect if you enable to option to back up the keys to AD in the first place, which is not mandatory

I'd be curious to see a conclusive piece of documentation about this, though

Why would you need to create a local account? You can just not choose to store the keys in your Microsoft account during BitLocker setup: https://www.diskpart.com/screenshot/en/others/windows-11/win...

Admittedly, the risks of choosing this option are not clearly laid out, but the way you are framing it also isn't accurate

This interpretation basically waters down the meaning of end-to-end encryption to the point of uselessness. You may as well just say "encryption".

There's FHE, but that's probably an even more difficult technical challenge than doing everything locally

I don't agree that this is end to end encrypted. For example, a compromise of the TEE would mean your data is exposed. In a truly end to end encrypted system, I wouldn't expect a server side compromise to be able to expose my data.

This is similar to the weasely language Google is now using with the Magic Cue feature ever since Android 16 QPR 1. When it launched, it was local only -- now it's local and in the cloud "with attestation". I don't like this trend and I don't think I'll be using such products

Ah yeah, factoring in the whitespace might make this a bit more practical

I don't think I see the vision here. If you want to maximize the number of tokens representable as a prefix code while still being able to output any sequence of characters, how could you possibly pick anything other than the one-character-long tokens?

Are you saying you'd intentionally make some output sequences impossible on the basis they're not likely enough to be worth violating the prefix code for? Surely there's enough common short words like "a", "the", etc that that would be impractical?

And even excluding the cases that are trivially impossible due to having short words as a prefix, surely even the longer words share prefixes commonly enough that you'd never get tokens longer than, say, two characters in the best case? Like, so many words start with "st" or "wh" or "re" or whatever, how could you possibly have a prefix code that captures all of them, or even the most common ones, without it being uselessly short?

Regarding the first part: that's an interesting idea, although I worry it would bias the outputs in an unrealistic way. Then again, maybe it would only impact scenarios that would have otherwise been unparsable anyway?

Regarding the second part: you'd effectively just be limiting yourself to single character tokens in that case which would drastically impact the LLM's output quality

I can't imagine they consider it a bug, it is a common and beneficial property of essentially every LLM today. You want to be able to represent common words with single tokens for efficiency, but at the same time you still need to be able to represent prefixes of those words in the cases where they occur separately