I'm by-and-large fine with XML, having used it for many a year; however I really like working with XML when I can use Guile's SXML layer. For Maven it's not that important because POMs are simple enough, but for more complex things it's nice having a useful tool.
I actually don't mind Ant very much, but I haven't had good luck using Ivy for dependency management. Maven's been very nice in the decade and a half I've used it, Gradle's always felt off to me. I think there was also another Java build tool written in like Ruby or something, but I'm blanking on the name at the moment.
Before Maven came to be, we had built nice macros on our Ant builds that were quite similar to how Maven works, but Ivy wasn't also around.
Eventually Maven grew on me, however I would rather go back to Ant than deal with Gradle, the time using it when I did Android development a few years ago, was more than enough.
Yeah I have long felt that if we think we need gradle, we should consider doing less crazy stuff in our build. Maven is plenty and any time I get back to a repo that has that instead of gradle or sbt I’m much happier.
I've found swearing at a model to be quite effective in getting it to rethink and correct its mistakes. This seems to apply across Codex, Claude, Qwen, and Gemma/Gemini.
I don't know if the model is picking up on a "need to lock in and be more rigorous" signal, or if the model providers are routing to smarter models if they detect a frustrated user. But if a model keeps making the same mistakes, swearing at it often helped kick it out of a glut and onto the right track.
Reminds me of this study: https://arxiv.org/pdf/2510.04950 . It demonstrates that being "rude" or "very rude" increases the accuracy of the results. A dubious but very fun read. The prompts in Table 1 (top of page 3) are awesome. I am sure they tried other prompts, but didn't include them to the paper.
I notice the same. Like you I am not even sure if it really helps, however, every day I find occasions where I see Opus will never do it correctly even though I calmly explain; swearing then suddenly fixes it. I had some issue yesterday where opus kept blaming the api for not sending some field while I knew it was there ; I showed it json, logs etc but it kept repeating that there must have been a glitch; frustration built, I called it all kinds of things in one sentence and the next solution was the right one. This after 10 similar misguesses. It was one of those increasingly rare cases where I should have just done it myself, but I can never know going in how stubborn it will be in continue blaming the (obviously) wrong thing. The around 11 prompts to get to the answer were in a /clear opus 4.7 context (1m) on xhigh.
So the correct strategy is a global CLAUDE.md with couple lines of colourful "you best behave or else" texts, so all your prompts get routed via the frustrated path?
I have a skill for exactly such case! Here's an excerpt :)
```
---
name: evidence-debugging
description: >
Use when debugging any failing test or bug, investigating unexpected
behavior, or tracing the cause of a reported defect.
---
# Debugging Discipline
## When to Use
- A test is failing and you need to understand why
- Behavior is unexpected and the cause is unknown
- The user asks you to debug or investigate a defect
- You need to verify what a value actually is at runtime
*When NOT to use:* proactive code exploration without a specific failure to investigate.
## STOP — Do This Before Anything Else
Before reading code, before forming a hypothesis, before typing anything — answer these:
1. *Do I have actual output from a running system?*
- No → instrument, run, save to file, read. Do not proceed until you have real output.
- Yes → read it. Do not re-run.
2. *Am I about to explain what the issue "probably is" or "must be"?*
- Yes → stop. That is deduction without evidence. It is a violation. Instrument instead.
3. *Am I about to touch passing code?*
- Yes → stop. Only instrument the failing scope.
If you find yourself already reasoning about likely causes — you are already violating Rule 1. Stop. Go back to step 1.
```
No worries! Here's the full prompt if you need it: https://sharetext.io/g6ibuxa5 (you'll probably need to update it, as there're specific things I wanted it to take into account)
Ultimately my point is to define small contexts grounding agents in tasks you expect them to do. Trying to define guidelines for everything will not work = telling it that it shouldn't delete prod AND that it's architect AND that it should review code using this and this principle AND milliard other things that you expect from yourself.
there already is a global claude using any cloud model is a high probability that theyre context stuffing trying to curate output for the normative use cases. see "dont talk about goblins"
Since the source code leaked showed they key off of swearing to trigger certain behavior, I actually intentionally swear when running into things like insufficient thinking and/or hallucinations. It also unironically makes it easier for me to grep later to run analysis on how often its happening.
This is interesting, because in the leaked code, it was found that they detected simple swearing keywords for analytics that get sent to Anthropic, but also had directions to keep the behavior the same for claude. I also have the feeling a 'wtf' does something, but it does feel good and might just be placebo, because 'that is still wrong' sometimes works the 4th time too. Or maybe they changed something.
I only used Claude a bit, but one of the things I dislike about it, is that it starts to 'push back' when you swear at it, saying things like 'if you continue like this, I won't be able to work with you' and such. I'm like MF'er you're a token prediction algorithm, what are you talking about, and it just makes me irrationally dislike it more. Codex otoh just lets you vent and straight up ignores such outbursts.
Wasn't it posted a few weeks ago that the frontend code for Claude or maybe Gemini or one of them had a swearing-at-model classifier that passed a flag to the backend? (Not sure why it was even done in frontend, but it was.)
I don't understand - are people's agents making so many mistakes? I'm using VSCode + Cline + Mimo to refactor big codebases and add features (including payment integrations) and it's rarely making any mistakes.
I use Claude Opus 4.7 on max thinking inside Claude Code and I gotta tell you, as context of the project grows, it starts slipping. No amount of whipping and cursing has helped.
Currently looking to start making my own hooks setup so it can be safer but nothing concrete yet.
I've found this to be effective as well. Claude generally immediately identifies the stupid code pattern it used and tries to fix it (with somewhat varying results).
I've found a mix of peppered in upper case words where you are effectively yelling at the LLM also gives it a strong signal. It is also a bit cathartic.
I tried it too. ChatGPT sometimes hits you with the "Can't help you with that" which was clearly introduced as a post-training highjack. So I just tell it "yes you can", and it proceeds with the previous prompt, slur acknowledgement included.
It's the only time the AI feel strictly like machines. Really simple if/else logic when if slur, no output, and you just tell it to proceed, and it fails the if clause because there was no slur in the last input.
Can you elaborate on this? I'm seen estimates of ~1.5bit per English letter, and tokens encode a lot more than that - sometimes full words, with multimodal even more. If KV cache embedding are storing more than just simple tokens but entire concepts with context and nuance, that'll bump the entropy up quite quickly.
> Can you elaborate on this? I'm seen estimates of ~1.5bit per English letter
The reference I always go back to is the GPT-3 paper. The cross-entropy loss (an upper bound for entropy) got down to 1.75 nats (2.5 bits). I took 2.1 because 2.5 is an upper bound and I wanted the estimate to end up as a round number.
> If KV cache embedding are storing more than just simple tokens but entire concepts with context and nuance, that'll bump the entropy up quite quickly.
Here's the thing: the concepts that the model stores in the KV cache are a deterministic function of the input tokens. Similar to the data processing inequality, this implies that no entropy is actually added.
Looking at it mechanically, a sufficiently powerful model only needs to encode the tokens and can recompute concepts later as needed.
VPS comes at the cost of potential for oversubscription - even from more reputable vendors. You never really know if you're actually getting what you're paying for.
One annoyance (I don't know if they've since fixed it) was that Docker Hub would count pulls that don't contain an update towards the rate limit. That ultimately prompted me to switch to alternate repositories.
How well do we understand the tokenization for Claude? I'd posit that the exact human-representation of this markup is likely irrelevant if it's all being converted into a single token.
Code length will itself become a problem. The instruction cache is limited in size and often quite small. Bloating instruction counts with lots of duplicated code will eventually have a negative effect on performance.
Ultimately, there's too many factors to predetermine which approach is faster. Write clean code, and let a profiler guide optimizations when needed.
Exactly. Memory access is a major factor in runtime, often more important than instruction counts. And in the vast, vast majority of cases it doesn't matter. I trust the compiler to make reasonable choices, something would have to be deployed at a very large scale before the programmer time of considering such things became cheaper than the hardware savings from doing it. And the vast majority of code simply doesn't execute often enough to matter one way or the other.
Save your brainpower for the right algorithms and for the inner loops the profiler identifies (I did not expect to learn that the slowest piece of code was referring to SQL fields by name!) Ignore the rest.
Additionally, so long as we can be sure the human's output is not actively adversarial, we can xor it into the entropy pool. Entropy can only increase this way.
I'm reminded of a diagram from the pitch doc for the original Diablo [0] that made its rounds across the web recently. The dungeon/town split was particularly sharp back then, but the broad design has stuck with modern ARPG design, either in the form of safe zones around town or explicit town zones.
A lot of this seems to be due to modern multiplayer design, with shared town instances and (usually) private dungeon/outside instances.
It might have been filled with mineral oil, those external enclosures often setup that way so that the enclosure is less extreme to manufacture. Not sure if that would work for camera lenses though unless those were also filled.
As someone who was on the product team for a 6000msw video camera, it's probably not filled with mineral oil. I doubt anyone makes subsea camera bodies/optics completely from scratch, and off-the-shelf units are not designed for pressure. In ours we used Sony camera internals, the enclosure was atmospheric, filled with dry nitrogen to reduce condensation, and the sapphire lens was designed to resist 12500psi and reduce distortion from the air-->sapphire-->seawater interface.
Hmm ok that would have explained why the SD card wasn't damaged if it were because when the vessel is filled with mineral oil it wouldn't have imploded like the main body of the craft.
Here; the title focusing on the price is implying that the cheap SD card survived ocean floor environment alone. A surprising amount of stress for its price.
Instead, a pressure-proof deep sea camera module was found at the wreckage site. It’s less interesting that an expensive thing rated for ocean depths was intact at ocean depths.
Its like “missing child found after 4 days in Alaska temperatures!”
gasp! How did they survive!
“The child was on holiday in their grandparents’ holiday log cabin, with their grandparents, a log fire, food, water..”
Oh. Clickbait. Hiding the boring bit to make the story appear more of a tease.
I noticed a pattern a few months ago in my phone's newsbait feed of headlines in the format "[Large familiar company] to close 500 stores on [date]" — and then below the fold "because it's [Independence Day, Rosh Hashanah, etc]" or "because they are moving to summer hours" or whatever.
> Here; the title focusing on the price is implying that the cheap SD card survived ocean floor environment alone. A surprising amount of stress for its price.
I certainly did not read that implication into the title, so it's entirely possible that the author didn't mean it.
The manufacturer didn’t even know encryption was enabled, because as long as the camera was working, it would just provide all files over USB without any encryption.
It was basically enabled by accident, and the only thing it prevented was recovery of files directly from the SD card when the camera was damaged.
I think it depends. Encrypted filesystems typically encrypt contents of each file separately - that way you don't need to read / write the whole disk to read it write any individual file contents. Of course that means metadata may be in plain text or may be separately encrypted - again possibly folder by folder instead of all metadata at once. Exact details would vary with different file system encryption schemes.
Whereas if you image the disk and encrypt the image properly, that gives you all the great confidentially guarantees but no random access.
> Encrypted filesystems typically encrypt contents of each file separately - that way you don't need to read / write the whole disk to read it write any individual file contents.
Ah, that's not true of "full disk encryption". It usually encrypts the disk blocks.
File-based encryption is stronger; you can use different protection classes on different files, you can use authenticated encryption, etc. iOS does it this way and I assume other systems have caught up, but don't know any in particular.
Most FDE systems are not authenticated so you would only lose one block (16 bytes for AES). Can this be bad? Yeah, but it's not that bad for data recovery.
Most unauthenticated encryption modes only mess up a few bits of a block, sometimes the following block too. A few only flip the exact bit in the plaintext.
Citation needed. It might be slightly easier, but most cases where you can get part of the camera, you can get the whole camera. This isn't a little point-and-click with a handy spring-loaded slot either.
Yeah but the Camera's owner is much more likely to notice "my camera is missing" than "the SD card is blank for some reason... the SD card must have failed"
EDIT: The linked PDF has a photo, the camera literally opens up to access the SD card.
The camera's (former) owner may very well notice, but that will have little effect. It's much more common that cameras (security, photography, phones) get stolen with cards inside, rather than someone extracting the card and leaving the camera.
Worth mentioning that I would immediately know if a different SD card was in my camera the moment I turned it on or ejected the card. If somebody knew to buy the same exact model and storage size that would be truly impressive.
Industrial espionage is far far more often done by hard work then being clever. Checking the SD cards you use and buying matching ones before executing a swap isn't noteworthy.
If you look through my case of SD cards I have all sorts of sizes and makes/models. I also have a procedure for dumping and formatting, and someone who is handling this most likely would as well. The moment the storage on screen looks funny or I see the card I don’t recognize, I’ll notice.
I’m not saying it’s impossible or I’m somehow immune to being tricked, but you would be surprised how easy it is to leave evidence of tampering through the simple act of trying to take an SD card, whether you swap it out or not. And people like me who handle them regularly would likely notice it in a split second. Maybe we won’t even catch the perpetrator, but it would not be written off as “oh interesting I guess it didn’t record,” if for no other reason then I would go straight into CYA mode and start looking for any hint that I didn’t make a mistake.
At that point if you have a basic security SoP in place and adhere to it you can start auditing.
Anywho again nothing is airtight and a determined individual could of course get past me. But you would be surprised how many hurdles they have to get over, and it certainly wouldn’t go unnoticed and be brushed off as a read/write quirk, that’s really all I’m saying
If you read the article, the SD card was placed there by the camera manufacturer and then the device was sealed so it would withstand pressure, and then sold to divers. Blame the camera manufacturer's engineers.
Seems like the SD card of all things performed just fine, so it hardly seems like the weak point.
They are surprisingly resilient! There was a blog post a couple of years ago by someone who found a digital camera in the sea which must have been in the water for months. The author could look at the photos to see if they can find the original owner of the camera.
reply