Hacker Newsnew | past | comments | ask | show | jobs | submit | shawnz's commentslogin

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

This comment struck a nerve with me and perhaps you didn't mean it in this way but:

Yes, many of us are incredibly responsive to customer support inquiries (I have a <1hr response time unless you send in a ticket when I'm sleeping) and it doesn't matter. Fraudsters gonna fraud. This isn't a case of "they asked for a refund, we refused, they issued a chargeback", it's a case of a scammer being a POS.

I've dealt with my fair share of chargebacks and in every case I've seen it's someone being a jerk and never a legit case.

The fact that Stripe won't help you, the banks don't care about all the evidence you have, and you end up out the money for the product _and_ you get hit with a chargeback fee on top of it is madness. I could literally have video of the person holding up their ID saying "I XXXXX agree to pay YYYY" and banks would still side with a the scummy scammers.

I have, quite literally, never had someone reach out via support and then file a chargeback later. They do it without reaching out, probably because they are a trash person and they have no interest in getting anything fixed and are just scammers.


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.


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

If you haven’t taken a lock, any other code can start executing at any time, so any invariant you might have established on one line may no longer be true on the next line.

If you don’t depend on anything mutable that anyone else can modify then this is mitigated, but that’s a very specific discipline you have to abide by.


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.


30 years isn't really a good thing, here.

I've been coding for more than 40 years, and I probably only took security seriously, in the last 25 or so.

In fact, in Ye Days of Yore, we often deliberately coded in unsecured stuff, for convenience.

Look at some of the old Apple Systems (pre-OS X), to see some stuff that would make secops people defecate masonry.


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.


Here is additional discussion and hacks around trying to retain Thinking output in Claude Code (prior to this release):

https://github.com/anthropics/claude-code/issues/8477


> 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?


Likely, I'd think.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: