Virgil today

This is where I got started. The idea was to build a "Flask for 9P". What this meant in practice was starting with language specific implementation of an in-memory file system, with the ability to define functions that handle specific paths. A full file system implementation isn't strictly necessary if all that you're exposing is a single file. For more than a few files however, it becomes very important.

The reason for implementing an in-memory file system was originally because I needed something to pass the automated tests. Over time however, it became clear that there are a lot of edge cases in how a file is expected to behave that it made sense to default to an in-memory filesystem and make the dynamic files the edge case instead of vice versa.

In any event, an unexpected outcome of having an LLM pass the Virgil tests using a lot of different languages is that new language implementations would sometimes expose subtle bugs that I'm not sure would have been obvious otherwise.

Here is what I had Claude generate, whith comments as appropriate:

I started off this project wanting to make it easy to write 9P file servers. Once I got that ability, the thing that I started working on next was having these servers run on actual hardware. What I didn't realize at the time is that I was poorly re-implementing what is known as a "drawterm" in the Plan 9 world.

Part of why I think I didn't make the connection initially is because drawterms are weird. Not quite ssh, not quite sftp, not quite VNC or RDP, they are an interesting intersection of a bunch of those concepts.

To explain what a drawterm is, I think it helps to start with how those tools work, so we can contrast them with what a drawterm does.

• ssh connects to a remote machine and allows you to run commands on the remote machine.
• sftp allows you to copy files to and from a remote machine.
• VNC connects to a remote machine. Gives you a graphical view of the remote desktop by sending over the raw pixels on the remote machine. Allows you to control the remote machine's keyboard and mouse.
• RDP like VNC except in addition to sending raw pixels, it can also send window draw commands, which can be more bandwidth efficient.

By contrast, what a "drawterm" does is this:

• Implements fileservers for the client's keyboard, mouse, clipboard, local filesystem, and other capabilities as files.
• Implements the /dev/draw filesystem, which is the same filesystem that a Plan 9 machine uses to draw on a directly attached monitor.
• Connects to the remote machine using TLS, and then mounts the filesystems above on the remote machine.
• Launches a shell (e.g. rc) or other program (like the rio windowing system) on the remote machine, binding in the filesystems mentioned above.

This all works because:

1. Everything in Plan 9 is a file.
2. Plan 9 allows you to change what filesystems are bound to a specific process.

So, instead of having to trick the remote system into thinking that your client is local (like ssh, sftp, etc have to do) you can change what filesystems a process sees and things will "just work" because it's using the same "API" that it always uses.

What this means in practice is that once a drawterm is written for a specific hardware platform, that hardware can connect to a remote Plan 9 system (a "cpu" server in Plan 9 terms) without needing to make any changes on the Plan 9 side. Furthermore, you don't need to learn or implement any new APIs or protocols to do remote computing, you can use filesystem mounts instead.

Here are the systems or languages where I had a drawterm implemented:

In the process of experimenting with all of the clients and servers described above, I found the need for two programs that don't fit nicely into any of the categories above