shawnz

> being braindead and in severe cases we do indeed say that they are not conscious or able to suffer

Sure, there are such cases. But in the general case, it seems to be that memory and ability to change specifically are not necessary and are not sufficient for consciousness, so we shouldn't judge machines on that basis

It's not a "trap", it's the real argument which makes me hesitant to dismiss consciousness of machines. Yes, it seems silly to dismiss a sick patient as having a lesser consciousness, which is exactly the point

So if a human loses their memory and their neutral plasticity (with age for example), then they are no longer capable of experiencing suffering?

I have this worded in my CLAUDE.md as "avoid counterfactuals". It still does it anyway, of course, but that language combined with a few rounds of review back-and-forth seems to work for me

I understand that ostensibly it is a statement of who is making the claim. But doesn't the media organization have an expectation to research and validate such claims? And so if they didn't, then that must mean that they weren't able to?

Is it really a different meaning? Isn't the implication that they tried, and failed, to independently verify the claim?

Yeah, I am just providing one contrived example. The cost benefit analysis won't always be so obvious as that in reality. My point was that if you're not using a blend of both comments and code semantics to explain your code, then you're leaving explanatory power on the table. It's unlikely that you're explaining the code in the most efficient manner if you're not using all the explanatory power you have available.

If you are only encoding intent through "self-documenting code", and not with comments, then you are purposefully not using all the tools at your disposal to encode meaning as efficiently as possible.

Imagine a complicated section of application logic. You could break it up into 5 separate functions that document their intent semantically, thus blowing up the LOC by 5x, or you could write a short comment explaining the intent in natural language. What's more effective? I'd argue it's always going to be using all the tools at your disposal when and where it makes sense to use them, whether that is comments or self-documenting code.

Designing a new on-disk format seems like a pretty far reaching architectural decision... I don't think that's an appropriate target for a drive-by fix from a new contributor

It's a shame they weren't able to launch this with the previously rumored Tensor CPU: https://www.androidauthority.com/google-pixel-watch-5-tensor...

There is already some intentional randomness in token selection, because it actually improves the quality of responses if you intentionally don't always pick the most likely next token.

You can hide data in that randomness without impacting the quality of the response by using a sufficiently "random looking" pseudorandom bit stream instead of real random numbers.

I previously worked on a project to do that here: https://github.com/shawnz/textcoder

What's the incentive for third parties to contribute, knowing just one guy stands to benefit if the project gets monetized in such a manner?

If you printed teeth, you'd have to make sure the teeth in the top loop are precisely aligned in relation to the teeth in the bottom loop based on the length of the belt, right? That seems like it could be limiting

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.