{"version":"https://jsonfeed.org/version/1","title":"Xe Iaso's blog","home_page_url":"https://preview.xeiaso.net/","feed_url":"https://preview.xeiaso.net/blog.json","description":"Thoughts and musings from Xe Iaso","items":[{"id":"https://preview.xeiaso.net/blog/2026/dancing-mad-sandboxing/","url":"https://preview.xeiaso.net/blog/2026/dancing-mad-sandboxing/","title":"Dancing mad with sandboxing","content_html":"
\"Cadey
Cadey

What is an operating system, really?

\"Aoi
Aoi

I mean, isn't it obvious? It's something like FreeBSD or Fedora that has a\nkernel, userspace, graphics stack, core set of programs, and everything else\nyou need to be able to use a computer. Is this a trick question?

\"Numa
Numa

Well it depends, is the Nintendo Switch OS an operating system? It doesn't\nhave a shell in the same way FreeBSD does. Is SEL4 an OS? It doesn't ship\nwith core utilities. Is Linux an OS? Is Windows an OS?

\"Aoi
Aoi

Oh gods here we go again…

\n

The definition of an operating system gets really fuzzy when you start looking at the edges of it, but let's say that an operating system is any part of a computer system that doesn't involve pure math. When you print to the screen, render 3d graphics, connect to the internet, and write to files your code calls into the underlying system to do that work. These system calls are defined by your operating system and are exposed as functions*.

\n
\"Mara
Mara

Okay they're not actually functions, but they quack enough like functions that\nyou can treat them like functions and not have to worry about the details too\nmuch.

\n

System calls are injected into each operating system process via a process kinda like how you inject dependencies into your applications for database sessions or object storage operations.

\n

Bashing your head into the wall

\n

A while ago a new JavaScript package got into the meme sphere at work: just-bash. It's a sandboxed environment with a shell interpreter that was originally intended for use with AI agents after its author observed that AI agents know how to use a tool called bash a lot better than a tool called search_documentation. This is backed by a "fake" shell with "fake" core utilities (cat, ls, etc, hereinafter coreutils) so that when an agent decides to rm -rf /, nothing important actually leaves the room. One of my coworkers made @tigrisdata/agent-shell on top of this that uses Tigris as its storage layer.

\n

This is great for people in the JavaScript ecosystem, but I am not mainly a JavaScript developer. I really wanted to play with it so I started thinking what it would take to have something like this in Go. mvdan's shell package makes this a heck of a lot easier, meaning that this "fake" shell would be powered by a real shell instead of either porting half of bash to JavaScript or making up hopefully-compatible behaviour.

\n

After a bunch of thought, hacking, and a spot of vibe coding while I did some Dawntrail extreme mount farms, I ended up with Kefka, a "fake" shell with coreutils implementations that lets you put your programs in clown jail. This package lets you add a sandboxed-in-userspace shell to your existing projects without shelling out to the actual implementations of coreutils on your machine.

\n
\"Mara
Mara

The name is inspired from Kefka\nPalazzo, the final boss\nof Final Fantasy VI. Need to chain uncontrollable demons? Use the power of a\nmad god driven to the brink of insanity with raw access to magic! What could\npossibly go wrong!

\n

So I did that

\n

So after some thought, I came up with this interface for the "commands" to use: Execer. This takes process context and passes it as an argument to a function named Exec. Exec then does whatever the process needs it to (list files, write to stdout, etc.) and returns an error if things went wrong and no error if things didn't.

\n
type ExecContext struct {\n\tStdin          io.Reader\n\tStdout, Stderr io.Writer\n\tDir            string\n\tEnviron        expand.Environ\n\tFS             billy.Filesystem\n\t// Runner is the active shell runner. Commands that need to dispatch a\n\t// child command (for example, `time CMD`) should call Runner.Subshell()\n\t// and re-enter the shell so the call goes through the same exec handler\n\t// chain instead of poking at the registry directly. May be nil in\n\t// embedders or tests that have not wired up a runner.\n\tRunner *interp.Runner\n}\n\ntype Execer interface {\n\tExec(ctx context.Context, ec *ExecContext, args []string) error\n}\n
\n

This is where I started vibe coding things, mostly via a skill that ports a just-bash command to the Execer interface and filesystem in Go. just-bash itself looks vibe coded from help output and manpages; I tried to go further and stay POSIX compatible, down to matching flag syntax (and in some cases output formats). If your muscle memory fails you, it's a bug in my book.

\n
\"Aoi
Aoi

If I recall, some POSIX utilities like false aren't usable as Go identifiers, how did you handle package names for that?

\"Cadey
Cadey

By naming them things like falsecmd:

package falsecmd\n\n// ...\n\ntype Impl struct{}\n\nfunc (Impl) Exec(ctx context.Context, ec *command.ExecContext, args []string) error {\n\treturn interp.ExitStatus(1)\n}\n

Honestly the implementations of true and false are my favourite part of this implementation. Here's the implementation of true:

package truecmd\n\n// ...\n\ntype Impl struct{}\n\nfunc (Impl) Exec(ctx context.Context, ec *command.ExecContext, args []string) error {\n\treturn nil\n}\n

This is a fully POSIX compliant implementation of true! Here's the relevant part of the spec if you don't believe me:

\n

true - return true value

\n

SYNOPSIS

\n

true

\n

OPTIONS

\n

None.

\n

OPERANDS

\n

None.

\n

Really, check out the POSIX spec for true. It's trivial to implement, here's a oneliner to implement it in Linux:

touch ./true && chmod +x ./true\n
\n

I made an operating system*

\n

This is basically an operating system: it provides interfaces for programs (well, in this case functions) to get input from a user, send output to a user, interact with a filesystem, and more. Eventually I want to add networking via a network stack on ExecContext, probably with tsnet or wireguard-go's netstack package for the user-level side. Maybe there's room for adding CEL based network filters there too.

\n

Porting applications with WebAssembly

\n

Once I got basic coreutils working, I thought it would be fun to get Python, jq, and ripgrep working. From previous experimentation back in the strawberry era of AI, I had already gotten Python running in WebAssembly via wazero. This used the stdlib io/fs#FS interface to allow me to inject virtual filesystems into the WebAssembly context. I used this to isolate my chatbot's filesystem state so that it (hopefully) wasn't able to delete anything important by accident.

\n

io/fs#FS has methods for the important stuff, and runtime interface assertions let you bridge the gap for things like writes. But it was really designed for embedded filesystems, and writes get hairy fast once you're talking to object storage or anything that isn't a tree of bytes on disk.

\n

At some point I hit a wall and had to switch from io/fs#FS to billy, another filesystem interface that I think predates the standard library one. This gives you a bunch more methods that map a lot closer to filesystem semantics in ways that coreutils crave. The interface was also mostly compatible with io/fs#FS so most of the hard part was really changing out the type and then chasing down compiler errors until I found enough of a pattern to have Opus automate the rest of it.

\n

From there it was a matter of adapting billy's filesystem to wazero's experimental sys interface. Mostly glue code, except where I had to translate Go errors into POSIX errno values. I had to read both the POSIX spec, the WASI spec, and the wazero source to figure out how to map errors between the two worlds. I think I'm at least 95% correct, which is likely within the margin of porting error.

\n

Adapting that codeinterpreter/python library to the new interface was mostly straightforward, and I ended up with a flow like this:

\n
// from https://tangled.org/xeiaso.net/kefka/blob/main/command/internal/python3/python3.go\n\nfunc (Impl) Exec(ctx context.Context, ec *command.ExecContext, args []string) error {\n\tfsConfig := wazero.NewFSConfig().\n\t\t(sysfs.FSConfig).\n\t\tWithSysFSMount(billyfs.New(ec.FS), "/")\n\n\tconfig := wazero.NewModuleConfig().\n\t\t// Pipe ExecContext stdio\n\t\tWithStdin(ec.Stdin).WithStdout(ec.Stdout).WithStderr(ec.Stderr).\n\t\t// Pipe argv\n\t\tWithArgs(append([]string{"python3"}, args...)...).\n\t\tWithName("python3").\n\t\t// Pipe filesystem\n\t\tWithFSConfig(fsConfig).\n\t\t// Pipe system time\n\t\tWithSysNanosleep().WithSysNanotime().WithSysWalltime()\n\n\tmod, err := runtime.InstantiateModule(ctx, compiled, config)\n\tif err != nil {\n\t\t// Fit the square peg into the round hole\n\t\tif exitErr, ok := errors.AsType[*wsys.ExitError](err); ok {\n\t\t\tif code := exitErr.ExitCode(); code != 0 {\n\t\t\t\treturn interp.ExitStatus(uint8(code))\n\t\t\t}\n\t\t\treturn nil\n\t\t}\n\t\treturn err\n\t}\n\treturn mod.Close(ctx)\n}\n
\n
\"Mara
Mara

See? The dependencies such as stdin, stdout, and stderr get injected\ninto the WebAssembly guest. Wazero also makes you inject the implementation of\ntime for boring reasons involving deterministic computing, but I'm sure you\ncan see the ways things hook in. This basic dependency injection flow is how\nthings like the linuxulator in FreeBSD\nor the old version of the Windows Subsystem for Linux work (WSL1 before it was\nmade into a Linux VM with WSL2). The table of system calls and filesystem\ncontext is effectively an argument to the process.

\n

Same trick got me ripgrep and jq. jq was annoying — wasi-sdk doesn't love jq's (ab)use of cmake — but 30 or so minutes of tweaking compiler flags got me a binary that works enough.

\n

I could see it being pretty easy to port over arbitrary programs to Kefka using WebAssembly like this. There's just one small problem: WASI preview 0.1 doesn't allow you to open arbitrary network sockets. This has been a huge pain in practice (it means you can't do HTTP requests, database connections, or other common internet things from inside the WASM sandbox) and future work probably would include adapting wazero to use wasix instead of WASI 0.1.

\n

Using filesystems that don't exist

\n

OK, that handles filesystems that (arguably) exist, like the btrfs volume on my dev box. What about filesystems that don't? For the sake of argument, let's say you want this fake shell to interact with object storage as its main filesystem. At some level all you need to do is adapt the billy interface to object storage using something like storage-go.

\n
\"Cadey
Cadey

Disclaimer, I work at Tigris and developed this library for them. It's\nbasically the S3 client with more methods to handle additional Tigris features\nlike forks and snapshots. I'll be writing more about it soon.

\n

After finding a basic implementation of an S3 -> Billy adapter, I vendored it into the Kefka repo and swapped out the "real" filesystem in cmd/kefka for an s3fs implementation pointed at a sample Tigris bucket. From there it was down to an iterative process of running commands, finding feature gaps when errors showed up, implementing them, fuzzing, and making sure things work mostly the same against Tigris as they do against a local filesystem.

\n

WASI is cursed: it has no process-level "current working directory," which most programs assume exists. You patch around it by passing a CWD envvar, or just use absolute paths. I haven't hit anything broken in casual use, but expect rough edges. Here be dragons and this code may be known by the state of California to cause cancer.

\n

Why does it have to use the command line?

\n

Once everything got working with s3fs and a local shell, I wondered how hard it would be to make this work as an SSH server using the github.com/gliderlabs/ssh package. Hooking things up was pretty easy:

\n
func HandleSSH(sess ssh.Session) error {\n  // Convenience variables for SSH session values\n  var stdout io.Writer = sess\n  var stderr io.Writer = sess.Stderr()\n  var stdin  io.Reader = sess\n  ctx := sess.Context() // cancelled when the user disconnects\n\n  // Kefka command registry with coreutils/python/jq/etc\n  commands := registry.New()\n  coreutils.Register(commands)\n  wasmprog.Register(commands)\n\n  // Base envvars for all programs, needed by POSIX\n  env := expand.ListEnviron(\n    "HOME=/",\n    "PWD=/",\n    "IFS=\\n",\n    "HOSTNAME=localhost",\n    "USER="+sess.User(),\n    // not strictly required, but just-bash sets it\n    "MACHTYPE=x86_64-pc-linux-gnu",\n  )\n\n  // Create shell engine\n  sh, err := interp.New(\n    // Set the "interactive" flag so the shell expands aliases\n    interp.Interactive(true),\n    // Forward our envvars\n    interp.Env(env),\n    // Wire up stdio\n    interp.StdIO(stdin, stdout, stderr),\n    // Change the shell exec handler such that it's constrained to the\n    // Kefka registry.\n    //\n    // Strictly speaking you don't have to do this, but if you don't\n    // then any time the registry doesn't have a command\n    // implementation, interp falls back to its default ExecHandler that\n    // executes the command as a subprocess. This is almost certainly\n    // not what you want.\n    interp.ExecHandlers(constrainToRegistry(commands)),\n    // Wire up per-command pwd state to the filesystem implementation\n    interp.CallHandler(billysh.CallHandler(commands, fsys, stdout, stderr)),\n    // Handle shell-level filesystem I/O (redirects, glob expansion, etc)\n    interp.StatHandler(billysh.FsysStatHandler(commands, fsys)),\n    interp.FsysOpenHandler(billysh.FsysOpenHandler(commands, fsys)),\n    interp.ReadDirHandler2(billysh.FsysReadDirHandler(commands, fsys)),\n  )\n\n  // Read shell commands\n  parser := syntax.NewParser()\n  fmt.Fprintf(stdout, "$ ")\n\n  // Split input into commands\n  for stmts, err := range parser.InteractiveSeq(stdin) {\n    if err != nil {\n      return err\n    }\n\n    if parser.Incomplete() {\n      fmt.Fprintf(stdout, "> ")\n      continue\n    }\n\n    for _, stmt := range stmts {\n      err := sh.Run(ctx, stmt)\n      if sh.Exited() {\n        return err\n      }\n    }\n\n    // Show prompt\n    fmt.Fprintf(stdout, "$ ")\n  }\n\n  return nil\n}\n
\n

The real handler is much messier because Python's REPL needs careful buffering, Ctrl-C has to actually cancel things, and pty wiring is its own can of cans of worms. None of that shows up if it's working. Tab completion and readline polish are easy enough; I'll let you wire those up as an exercise for the reader.

\n

If you want to try it today, you can ssh into sophia.xeiaso.net:

\n
$ ssh sophia.xeiaso.net\n
\n

You'll get an isolated sandbox in your own bucket fork/branch. Every ls is a ListObjectsV2 against the bucket. Every qjs or python3 runs WebAssembly on the server, wired to that same bucket.

\n
$ cat ./samples/hello.js\nconsole.log("Hello, world!");\n$ qjs ./samples/hello.js\nHello, world!\n
\n

The demo bucket is seeded with examples. You'll probably have to poke around to find everything. Worst case, run help.

\n
\"Cadey
Cadey

I should really hook up session recording to this.

\n

I want more experimental WebAssembly hacks like this to exist. I'll keep poking at it.

\n

Put your programs in clown jail

\n

With some effort, yeet could use Kefka's shell utilities to run Anubis builds on Windows; and if management ever makes you babysit AI agents, clown jail is a decent answer.

\n

The code lives on Tangled. I'm wiring it into an agent harness so I can automate small tools against a local model (I'm loving Qwen3-36B-A3B).

\n

There's a sister post on the Tigris blog that goes deeper into the AI-agent angle and the porting work using Claude Code. If you want, you can check it out here:

\n
Tigris DataGive your agents disposable environments in GoKefka is a userspace shell sandbox in Go that gives every AI agent its own copy-on-write Tigris bucket fork plus Python, jq, and ripgrep via WebAssembly.
","date_published":"2026-05-28T00:00:00.000Z","tags":[]},{"id":"https://preview.xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2026-45250/","url":"https://preview.xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2026-45250/","title":"\"No way to prevent this\" say users of only language where this regularly happens","content_html":"

In the hours following the release of CVE-2026-45250 for the project FreeBSD, site reliability workers\nand systems administrators scrambled to desperately rebuild and patch all their systems to fix a kernel stack overflow when validating permissions of the setcred(2) system call, allowing arbitrary code execution in the context of the kernel. This is due to the affected components being\nwritten in C, the only programming language where these vulnerabilities regularly happen. "This was a terrible tragedy, but sometimes\nthese things just happen and there's nothing anyone can do to stop them," said programmer Mrs. Gregoria Doyle, echoing statements\nexpressed by hundreds of thousands of programmers who use the only language where 90% of the world's memory safety vulnerabilities have\noccurred in the last 50 years, and whose projects are 20 times more likely to have security vulnerabilities. "It's a shame, but what can\nwe do? There really isn't anything we can do to prevent memory safety vulnerabilities from happening if the programmer doesn't want to\nwrite their code in a robust manner." At press time, users of the only programming language in the world where these vulnerabilities\nregularly happen once or twice per quarter for the last eight years were referring to themselves and their situation as "helpless."

\n","date_published":"2026-05-21T00:00:00.000Z","tags":[]},{"id":"https://preview.xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2026-45584/","url":"https://preview.xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2026-45584/","title":"\"No way to prevent this\" say users of only language where this regularly happens","content_html":"

In the hours following the release of CVE-2026-45584 for the project Microsoft Windows, site reliability workers\nand systems administrators scrambled to desperately rebuild and patch all their systems to fix a memory safety vulnerability resulting in arbitrary code execution inside the virus scanner Windows Defender. This is due to the affected components being\nwritten in C++, the only programming language where these vulnerabilities regularly happen. "This was a terrible tragedy, but sometimes\nthese things just happen and there's nothing anyone can do to stop them," said programmer Dr. Annabelle Connelly, echoing statements\nexpressed by hundreds of thousands of programmers who use the only language where 90% of the world's memory safety vulnerabilities have\noccurred in the last 50 years, and whose projects are 20 times more likely to have security vulnerabilities. "It's a shame, but what can\nwe do? There really isn't anything we can do to prevent memory safety vulnerabilities from happening if the programmer doesn't want to\nwrite their code in a robust manner." At press time, users of the only programming language in the world where these vulnerabilities\nregularly happen once or twice per quarter for the last eight years were referring to themselves and their situation as "helpless."

\n","date_published":"2026-05-20T00:00:00.000Z","tags":[]},{"id":"https://preview.xeiaso.net/blog/2026/tekton/","url":"https://preview.xeiaso.net/blog/2026/tekton/","title":"Slowly going mad with power using Tekton","content_html":"\n

GitHub has been the foundation of my career since before it began. I've been using it since 2010 (almost half my life, wow) and I have over 400 repos there from all stages of competence and my career. I'm not feeling good about its future given how unreliable it's been lately.

\n\n

As part of the planning for a post-GitHub future, I've been looking at one of the hardest things to move: GitHub Actions. I've used GitHub Actions for most of my career and only have vague memories of Jenkins, Travis, and the other things I've used before. Most of my repos only have GitHub Actions (with a small fraction of them having Gitea Actions from when I experimented with that) and a lot of my assumptions around how CI works are centered around the implementation of GitHub actions.

\n
\"Mara
Mara

CI/CD (Continuous Integration / Continuous Delivery) is a software practice\nthat makes servers run tests and deploy code automatically as changes are\ncommitted. In practice, this means that you have something running tests and\ndeploying software when changes are committed. The group of build/test/deploy\nsteps is usually called a pipeline.

\n

The other thing I'm gonna have a hard time getting over is all the basically free compute that GitHub Actions provides, which is significant when you look at how much Anubis does per commit. However, I do have a mildly absurd amount of compute laying around, so that may just even itself out I guess.

\n

If I have to move my CI to a new solution that's going to require me to rewrite it all from scratch or adapt it over, I really want to settle on a vendor-neutral implementation that isn't beholden to a single platform. This would make me slightly more resilient against future enshittification (it's a matter of when, not if).

\n
\"Mara
Mara

In this article, KubernetesTerms will be in JavaClassNameCase. If you're not sure what one of them is, search this in DuckDuckGo:

site:kubernetes.io KubernetesTerm\n
\n

Tekton and you

\n\n

Recently I discovered Tekton, a Kubernetes operator (read: plugin) that breaks CI/CD pipelines into Kubernetes objects. It's also as far as I can tell the only real vendor-neutral CI/CD pipeline solution. There's also a really neat bridge between Tangled.org and Tekton called Tack.

\n

For the sake of this post, let's say that I'm going to settle on the TTT stack: Tangled, Tack, and Tekton.

\n

Tekton in a nutshell

\n

In order to help you understand where/why Tekton fits into the stack, let's think about it like this: Tekton is the layer under something like GitHub Actions. Tekton takes CI pipeline jobs and schedules them onto Kubernetes. Kubernetes handles scheduling pods across machines, durable storage between steps in the pipeline, networking between pods, logging, and other orchestration that you need in practice.

\n

In Tekton, your CI/CD jobs are broken out into a few basic categories:

\n\n

Here's an example Task:

\n
apiVersion: tekton.dev/v1\nkind: Task\nmetadata:\n  name: kubectl-apply\n  labels:\n    app.kubernetes.io/version: "0.1"\nspec:\n  description: |\n    Run kubectl apply\n  params:\n    - name: image\n      description: Docker image for kubectl\n      default: "cgr.dev/chainguard/kubectl:latest"\n    - name: args\n      description: Args to pass to `kubectl apply`\n      type: array\n      default: []\n    - name: subfolder\n      description: subfolder that the repo is actually in\n      default: "/repo"\n  workspaces:\n    - name: repo\n      description: Repo to operate in\n  steps:\n    - name: chown-chmod\n      image: $(params.image)\n      workingDir: $(workspaces.source.path)$(params.subfolder)\n      args:\n        - apply\n        - $(params.args[*])\n      securityContext:\n        runAsUser: 0\n
\n

This looks like a lot, but that's mostly because Tekton is completely unopinionated. It places a lot of the assumptions that GitHub Actions or Travis makes out of the way so you build up your desired pipeline from scratch. I copied this Task out of my Tekton tasks repo in case you want to dig through the other ones I use.

\n

Those Tasks are then chained together into Pipelines like this:

\n
apiVersion: tekton.dev/v1beta1\nkind: Pipeline\nmetadata:\n  name: xeiaso-net-alrest-autoapply\n  namespace: ci\nspec:\n  description: |\n    Autoapply for xeiaso.net/alrest manifests.\n  params:\n    - name: repo-url\n      type: string\n      description: "Git repo to clone"\n      default: "https://tangled.org/xeiaso.net/alrest"\n    - name: "commit"\n      type: string\n      description: "Git revision to check out"\n  workspaces:\n    - name: repo\n      description: |\n        Cloned repo files.\n  tasks:\n    - name: fix-permissions\n      taskRef:\n        name: fix-permissions\n      workspaces:\n        - name: dir\n          workspace: repo\n    - name: clone-repo\n      runAfter: ["fix-permissions"]\n      taskRef:\n        name: git-clone\n      workspaces:\n        - name: output\n          workspace: repo\n      params:\n        - name: url\n          value: $(params.repo-url)\n        - name: revision\n          value: $(params.commit)\n    - name: kubectl-apply\n      runAfter: ["clone-repo"]\n      taskSpec:\n        workspaces:\n          - name: repo\n        steps:\n          - name: do-apply\n            workingDir: $(workspaces.repo.path)/repo\n            image: cgr.dev/chainguard/kubectl:latest\n            args:\n              - apply\n              - -k\n              - $(workspaces.repo.path)/repo\n
\n

You would then invoke this Pipeline by creating a PipelineRun object:

\n
apiVersion: tekton.dev/v1\nkind: PipelineRun\nmetadata:\n  name: tack-autoapply-yaml-7c5e518b6c60\n  namespace: ci\nspec:\n  params:\n    - name: commit\n      value: 838e7e0e83df04d54c035b9c60b852ff56852b4a\n  pipelineRef:\n    name: xeiaso-net-alrest-autoapply\n  taskRunTemplate:\n    serviceAccountName: xeiaso-net-alrest-autoapply\n  timeouts:\n    pipeline: 1h0m0s\n  workspaces:\n    - name: repo\n      volumeClaimTemplate:\n        spec:\n          accessModes:\n            - ReadWriteOnce\n          resources:\n            requests:\n              storage: 4Gi\n
\n

You can see how this fits together, right? PipelineRuns bind values to Pipelines, which bind values to Tasks, which sequence running Pods in your cluster. This then gets turned into green and red commit statuses in the Tangled UI via Tack.

\n

Walking through a single pipeline

\n

From here I think it'd be useful to walk through a single CI pipeline, the one I use in kefka (a work-in-progress port of just-bash to Go, I plan to write more about it soon, I just need the energy/time). I had to make some compromises in my cluster because of how my storage system works, but you'll see more when it's time.

\n","date_published":"2026-05-17T00:00:00.000Z","tags":[]},{"id":"https://preview.xeiaso.net/notes/2026/amazonbot-respecting-robots-txt/","url":"https://preview.xeiaso.net/notes/2026/amazonbot-respecting-robots-txt/","title":"Amazonbot is finally respecting robots.txt","content_html":"

I just got an email from Amazon saying they're finally going to respect robots.txt. Here's the verbatim email I got:

\n
\n

We are writing to inform you that starting Monday, June 15, 2026, crawl preferences for Amazonbot will be managed solely through the industry-standard directives. This gives you direct, ongoing control over how Amazonbot accesses your site, rather than relying on manual requests. If you do not implement robots.txt directives by that date, Amazonbot will follow standard web crawling practices when accessing your site.

\n

How to maintain your current preferences: The robots.txt protocol allows you to control Amazonbot’saccess at the page-, directory-, or site-level and update your preferences at any time. Please find detailed information on Amazonbots approach to these directives here: https://developer.amazon.com/amazonbot.

\n

Best,

\n

Amazon Publisher Support

\n

amazonbot@amazon.com

\n

Get Outlook for Mac

\n
\n
\"Numa
Numa

Amazing, they even kept the "sent from my iPhone" message proving they sent it\nfrom Outlook for Mac. Looking at the email headers it has a bunch of\nExchange-specific headers so it's probably actually from Outlook for Mac. This\ntimeline is absolutely wild.

\n

This makes me feel kinda weird because Amazon's scraper is why Anubis exists.

\n

I'm gonna make sure to merge these robots.txt changes into Anubis if they aren't already there.

","date_published":"2026-05-14T00:00:00.000Z","tags":[]},{"id":"https://preview.xeiaso.net/notes/2026/gitlab-layoffs/","url":"https://preview.xeiaso.net/notes/2026/gitlab-layoffs/","title":"I'm really frustrated that GitLab is doing layoffs","content_html":"

GitLab announced layoffs today. They don't state how many people are affected, but honestly I find this really frustrating for several reasons:

\n
    \n
  1. This is the one time where they could have won by doing relatively nothing. GitHub is having big outages on a daily cadence. All they have to do is market themselves as "we're the stable one" and maybe add tooling to run your existing GitHub Actions in GitLab to make the transition easier. They could have won so hard it's not even funny because GitLab makes it trivial to host it yourself.
    2. \n
  2. This is yet another case of "the stock price has gone down but we don't want to look bad to investors so we'll say that AI is going to help us more". I'm increasingly skeptical of this claim, but it's what makes the company look good to the people with the money sooo...
    3. \n
  3. They claim that one of their main goals is "Speed with Quality". Usually this is a "of two, pick one" type of scenario. I shudder to think what may happen when GitLab turns into a feature factory powered by something on the lines of Protos.
    4. \n
\n

Maybe GitLab did need to trim the fat, maybe they will come out of this stronger, but damn I just can't help but think about a world where they could have won without AI and just by being more stable than GitHub.

\n
\"Numa
Numa

One small problem with that: what you are suggesting makes sense. We live in\nclown world with clown world logic. Why would we be allowed to have things\nthat make sense in clown world?

Also yes, I do know that clowning is actually a very difficult art to pull off correctly. Humor is one of the most difficult things on the planet because if you do it wrong you offend people. People that are offended generally aren't people that are laughing. As a character that largely amounts to being a jaded contrarian comedian this is something that comes up a lot when planning what I say.

Also maybe I'm just oversensitive to it at this point, but the layoff announcement really reads like Claude Opus output. What a fuckin' world.

\"Aoi
Aoi

I don't want to live on this planet anymore.

\n

Apropos of nothing, I'm really enjoying my experimentation with Tangled. More to come soon when I have more to say.

","date_published":"2026-05-11T00:00:00.000Z","tags":[]},{"id":"https://preview.xeiaso.net/blog/2026/abstain-from-install/","url":"https://preview.xeiaso.net/blog/2026/abstain-from-install/","title":"Maybe you shouldn't install new software for a bit","content_html":"

In the wake of copy.fail, there are more vulnerabilities that have been announced:

\n\n

Right now would be one of the best times for a supply chain attack via NPM to hit hard.

\n

Outside of Linux kernel patches from your distro, I think it's probably a good idea to put a moratorium on installing new software for a week or so.

","date_published":"2026-05-07T00:00:00.000Z","tags":[]},{"id":"https://preview.xeiaso.net/notes/2026/claude-code-wins-april-fools/","url":"https://preview.xeiaso.net/notes/2026/claude-code-wins-april-fools/","title":"Claude Code won April Fools Day this year","content_html":"

April Fools Day is somewhat of a legendary day among nerds. Historically it's been when the nerds at GMail introduced GMail Custom Time, where you could interrupt causality by making GMail look like you sent a message before it was actually sent. It actually worked.

\n

Sometimes this gets taken too far and the joke falls flat, causing a lot more problems than would exist if the joke never happened in the first place. Incidents like this have resulted in many companies just putting in policies against doing that to avoid customer growth impact.

\n

It's refreshing to see the Claude Code team introduce the /buddy system this year. When you run /buddy, it hatches a coding companion that hangs out in your Claude Code interface like a tamagochi. Here's my buddy Xentwine:

\n
╭──────────────────────────────────────╮\n│                                      │\n│  ★★★ RARE                     ROBOT  │\n│                                      │\n│     (   )                            │\n│     .[||].                           │\n│    [ @  @ ]                          │\n│    [ ==== ]                          │\n│    `------´                          │\n│                                      │\n│  Xentwine                            │\n│                                      │\n│  "A methodical circuit-whisperer     │\n│  obsessed with untangling logical    │\n│  snarls; speaks in patient,          │\n│  patronizing riddles and will        │\n│  absolutely let you sit in your own  │\n│  bug for three minutes before        │\n│  offering the blindingly obvious     │\n│  fix."                               │\n│                                      │\n│  DEBUGGING  █████░░░░░  47           │\n│  PATIENCE   █████░░░░░  47           │\n│  CHAOS      ██░░░░░░░░  21           │\n│  WISDOM     █████████░  92           │\n│  SNARK      █████░░░░░  49           │\n│                                      │\n╰──────────────────────────────────────╯\n
\n

Here's what it looks like in the Claude Code app:

\n
\n

I think this is the best April Fools Day feature in recent memory because it seems intentionally designed to avoid impacting users in a way that would cause problems:

\n\n

This is the kind of harmless prank that all nerds should aspire for. 10/10.

","date_published":"2026-04-01T00:00:00.000Z","tags":[]},{"id":"https://preview.xeiaso.net/notes/2026/ai-gpus-cant-process-graphics/","url":"https://preview.xeiaso.net/notes/2026/ai-gpus-cant-process-graphics/","title":"Small note about AI 'GPUs'","content_html":"

I've been seeing talk around about wanting to capitalize on the AI bubble popping and picking up server GPUs for pennies on the dollar so they can play games in higher fidelity due to server GPUs having more video ram. I hate to be the bearer of bad news here, but most of those enterprise GPUs don't have the ability to process graphics.

\n

Yeah, that's right, in order to pack in as much compute as possible per chip, they removed video output and graphics processing from devices we are calling graphics processing units. The only thing those cards will be good for is CUDA operations for AI inference, AI training, or other things that do not involve gaming.

\n
\n

On a separate note, I'm reaching the point in recovery where I am getting very bored and am so completely ready to just head home. At least the diet restrictions end this week, so that's something to look forward to. God I want a burrito.

","date_published":"2026-03-30T00:00:00.000Z","tags":[]},{"id":"https://preview.xeiaso.net/notes/2026/dns-fight/","url":"https://preview.xeiaso.net/notes/2026/dns-fight/","title":"Homelab downtime update: The fight for DNS supremacy","content_html":"

Hey all, quick update continuing from yesterday's announcement that my homelab went down. This is stream of consciousness and unedited. Enjoy!

\n

Turns out the entire homelab didn't go down and two Kubernetes nodes survived the power outage somehow.

\n

Two Kubernetes controlplane nodes.

\n

Kubernetes really wants there to be an odd number of controlplane nodes and my workloads are too heavy for any single node to run and Longhorn really wants there to be at least three nodes online. So I had to turn them off.

\n

How did I get in? The Mac mini that I used for Anubis CI. It somehow automatically powered on when the grid reset and/or survived the power outage.

\n
xe@t-elos:~$ uptime\n 09:45:55 up 66 days,  9:51,  4 users,  load average: 0.37, 0.22, 0.18\n
\n

Holy shit, that's good to know!

\n

Anyways the usual suspects for trying to debug things didn't work (kubectl get nodes got a timeout, etc.), so I did an nmap across the entire home subnet. Normally this is full of devices and hard to read. This time there's basically nothing. What stood out was this:

\n
Nmap scan report for kos-mos (192.168.2.236)\nHost is up, received arp-response (0.00011s latency).\nScanned at 2026-03-18 09:23:09 EDT for 1s\nNot shown: 996 closed tcp ports (reset)\nPORT      STATE SERVICE   REASON\n3260/tcp  open  iscsi     syn-ack ttl 64\n9100/tcp  open  jetdirect syn-ack ttl 64\n50000/tcp open  ibm-db2   syn-ack ttl 64\n50001/tcp open  unknown   syn-ack ttl 64\nMAC Address: FC:34:97:0D:1E:CD (Asustek Computer)\n\nNmap scan report for ontos (192.168.2.237)\nHost is up, received arp-response (0.00011s latency).\nScanned at 2026-03-18 09:23:09 EDT for 1s\nNot shown: 996 closed tcp ports (reset)\nPORT      STATE SERVICE   REASON\n3260/tcp  open  iscsi     syn-ack ttl 64\n9100/tcp  open  jetdirect syn-ack ttl 64\n50000/tcp open  ibm-db2   syn-ack ttl 64\n50001/tcp open  unknown   syn-ack ttl 64\nMAC Address: FC:34:97:0D:1F:AE (Asustek Computer)\n
\n

Those two machines are Kubernetes controlplane nodes! I can't SSH into them because they're running Talos Linux, but I can use talosctl (via port 50000) to shut them down:

\n
$ ./bin/talosctl -n 192.168.2.236 shutdown --force\nWARNING: 192.168.2.236: server version 1.9.1 is older than client version 1.12.5\nwatching nodes: [192.168.2.236]\n    * 192.168.2.236: events check condition met\n\n$ ./bin/talosctl -n 192.168.2.237 shutdown --force\nWARNING: 192.168.2.237: server version 1.9.1 is older than client version 1.12.5\nwatching nodes: [192.168.2.237]\n    * 192.168.2.237: events check condition met\n
\n

And now it's offline until I get home.

\n

This was causing the sponsor panel to be offline because the external-dns pod in the homelab was online and fighting my new cloud deployment for DNS supremacy. The sponsor panel is now back online (I should have put it in the cloud in the first place, that's on me) and peace has been restored to most of the galaxy, at least as much as I can from here.

\n

Action items:

\n","date_published":"2026-03-18T00:00:00.000Z","tags":[]}]}