Reality imitates art:

Waymo Is Getting DoorDashers to Close Doors on Self Driving Cars

Lethal Trifecta

All AI agents must live in the Lethal Trifecta as coined by Simon Willison.

For programming assistants, who need to be online to install modules and to run tests this basically means they cannot have access to private information. So my solution is to run them in a podman container where they have read/write access to a directory where I also check out the code the agent should work on.

This is somewhat in contrast to the current meme of letting an OpenClaw assistant run with your credentials, your email address and input from the outside world.

Setup

My setup choses to remove all access to private data, since for programming an agent does not need access to any data that should not be publically known.

• Claude Code within its own Docker container
• Runs as root there
• Mount /home/corion/claude-in-docker/.claude as /root/.claude
• Mount working directory as /claude
• (maybe) mount other needed directories as read-only, but I haven't felt the need for that

Dockerfile

FROM docker.io/library/debian:trixie-slim
# debian-trixie-slim
RUN <<EOF
apt update

# Install our packages
DEBIAN_FRONTEND=noninteractive TZ=Etc/UTC apt-get install -y npm perl build-essential imagemagick git apache2 wireguard wget curl cpanminus liblocal-lib-perl ripgrep

# Install claude
curl -fsSL https://claude.ai/install.sh | bash

# Set up our directories to be mountable from the outside
mkdir -p /work
mkdir -p /root/.claude

# Now you need to /login with claude :-/

# claude plugins install superpowers@superpowers-marketplace

EOF

# Add claude to the search path
ENV PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/root/.local/bin"
ENTRYPOINT ["bash"]
CMD ["-i"]

Script to launch CC

Of course, the first thing an AI agent is used for is to write a script that launches the AI agent in a container. This script is very much still under development as I find more and more use cases that the script does not cover.

Development notes

While developing the script, I found that Claude Code very much needs example sections to work from. On its own, it comes up with code that is not really suitable. This mildly reinforces to me that the average Perl code used for training is not really good.

Link: https://blog.gitbutler.com/how-git-core-devs-configure-git/

After reading the link, I updated to

• better diff (histogram)
• Column mode
• Autocreate
• rerere
• zdiff3
• sort tags by version

From a HN discussion on that , I also added

whitespace=fix

Tainted Grail - The Fall of Avalon

The game is a quite good RPG. It borrows heavily from Skyrim, Gothic, Morrowind and a bit of the Witcher and Elden Ring, but the mix is quite good.

You start as somebody possessed by King Artus, who wants to regain dominion over Avalon. The island has been taken over by the Red Blight, and the Knights of Kamelot are reigning from afar, not necessarily well. It is a grimdark setting but manages to be not entirely bleak.

Graphics

I'm playing this on an old(ish) PC with an Nvidia RTX 1080, with graphics at 1080p and "low" setting. The graphics are still OK. The world feels very handcrafted, and for example some of the ruins feel hand-placed but without much transition from the landscape to the ruin blocks. It strongly reminds me of Gothic in that regard. The general idea of the landscape reminds me of Elden Ring, except that the landscape is more gray and not in the glorious colors of Elden Ring.

World

The world is compressed, but still feels believable (for a fantasy RPG open world world). It is not littered with Ubisoft-style fetch quests and collectibles, and soulless question marks with nothing to explore there. There are some side things to do, like collecting cooking recipes, collecting ingredients for magic potions, some mild crafting, but it is all for making you a better fighter, or keeping you alive. The crafting feels very close to Skyrim.

The characters inhabiting the world are grimdark, mostly, but there are also some weird characters and even mild attempts at comedy. They are not as present as Jaskier in The Witcher, but not having everybody be within the grimdark framework makes for good entertainment.

Gameplay

The game loop consists of exploring the world, mildly guided by quests, and then selling the loot at merchants, and maybe crafting new stuff. The skills / leveling are taken from Morrowind, where doing any activity improves your ability in it. So, cooking a meal slightly improves your general cooking ability. Running around a lot improves your running ability. And conjuring monsters improves your general magic ability. The fighting feels very much like Skyrim, having bow and arrows, magic and close combat. The fighting forces you to switch weapons more often than Skyrim did, but that adds to the variety.

Story

There are various factions and various side quests that are well-written. There is a lot of (English) voiced dialogue, which can get tedious at times, but on the other hand, it is spoken well and the voices feel in-character. Even the side quests have a lot of spoken dialogue and I haven't found a quest without talking yet.

Conclusion

Overall, the game is interesting and touches the right buttons for me. It's enjoyable to just go through the scenery, finding new caves to explore or citizens to speak with. I am currently in the first act of the game and already am overpowered (summoner magicians usually are), but that's fine.

Last Monday I did the Perl Developer Release of Perl 5.43.7. As usual, I worked from the Release Managers Guide . Everything worked well, even if everything was cutting it a bit close. My video setup on the desktop was not suited for streaming anymore, so I had to do a stream consisting only of the console window and me talking over it, and no floating head of me available.

What worked well

The Twitch chat was the most active that I witnessed when streaming a Perl release. We chatted about organizing Perl conferences and also the Perl release process. One realization for me was that the RMG process is mostly there to exercise the Perl build machinery and testing that the generated tarball does not have deficiencies. This means that testing that Perl can build through Configure is important, but testing different Perl configurations like ithreads or userelocatableinc is not that important.

The dashboard for tracking my progress through the release worked well up to the release. I had modified it in the weeks leading up to the release to not only show the human step description but also to show the command line steps that should be undertaken, where applicable. I see this as a first step in automating these steps where possible and sensible.

What didn't work out

The dashboard can use some improvements:

• The script did not cope well with the events after the release when the repo version number was bumped from 5.43.7 to 5.43.8. This part needs to be investigated but is easy to replicate by simply launching the dashboard with a version number before the current version number.

• The script could highlight the current position in the sequence better. For console output this would likely mean inverting the line where the next applicable step is, but this means moving the output from Text::Table to a custom table generation or post-patching the string from Text::Table with the appropriate console commands.

• The script should generate HTML and terminal output at the same time. Having output visible in a browser feels less retro but makes things like publishing the progress elsewhere easier.

• The script should have a feature to simply output the next step. This could be integrated into the shell prompt to give a guided message in the console window. Maybe the console output and the HTML output should be done as files when in "interactive" mode?

Improvements to the Perl Release Process

• More parallelism - the current release manager guide uses make test in many places. This runs the test suite in serial mode, which takes on my machine about 10 minutes. Running the test suite in parallel takes about 4-5 minutes. This is implemented using the make test_harness command. Whether Perl should move the default of parallel testing to make testfrom make test_harness is debatable. Most likely everybody who cares about speed already runs the test suite in parallel.

• Remove sequences of shell commands - comparing the file names between the previous and current Perl version is done using a sequence of shell commands involving sort, diff`. I have a patch that adds a small tool to do that within Perl (mostly powered by Algorithm::Diff ).