Flotilla keeps its capital F again
Reverts the lowercase change: only the app's drawn wordmark is lowercase (the owner, 10 October).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
flotilla is written lowercase, like the logo
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Correct the machine/container relationship — they are siblings, not nested
The central page said "a container runs inside a Linux virtual machine, that VM
is the machine", with a diagram of containers nested in a machine and a claim
that Set as Default "makes it the machine new containers run in". All of that is
wrong, and it was the page telling readers it was the one thing worth reading.
Measured on this Mac rather than reasoned about: with both machines stopped —
including the one marked default — a container ran normally, neither machine
started, and the container took its own address on the same bridge as them
(buildkit .6, machines .7 and .8, the new container .13). Sequential neighbours
on one network, not one thing inside another. `container run` has no flag for
choosing a machine, and a container's own inspect output never names one.
So each container gets its own VM, and a machine is a separate persistent VM you
create and shell into. The page now leads with that, shows the evidence, and says
plainly that the Machines section can be ignored entirely.
Two things it now refuses to claim. Set as Default: `container machine
set-default --help` says only "Set the default container machine" and does not
say what the default affects, so the page says that and stops, rather than
inventing a behaviour twice. And the old "a container cannot exceed its machine"
resource table is gone — a container's CPUs and memory are its own, because a
container is its own VM.
Added what a machine is *not*, since that is what sent the owner looking: the
rootfs is a container image and the kernel comes from Apple's runtime, which is
why images come from Docker Hub, why the disk reads tens of megabytes, and why
only alpine boots. Anyone wanting a real Ubuntu or Fedora VM is pointed at Lima,
UTM or Vagrant instead of being left to conclude the feature is broken.
Swept Home, Machines and First-Run for the same claim.
docs: the one relationship everything else rests on
Beta testing turned up a documentation gap rather than a bug: asked to "Set as
Default on one machine", the owner answered "I don't understand the relationship
between machine and container". If the person who commissioned the app does not
have that model, no reader arrives with it either, and every page that assumes
it is harder than it needs to be.
Machines-and-Containers is now the first page under "Using it": a container runs
inside a Linux VM because macOS has no Linux kernel, that VM is what the app
calls a machine, and that is why Machines sits under Virtualisation rather than
beside Containers. Then the part that decides whether you ever open the section
— mostly you do not — and the three cases where you do: a container failing for
reasons that are really the machine's, resource limits that nest, and wanting a
persistent machine.
It also answers Set as Default plainly (new containers land there; existing ones
do not move), and puts the container-versus-machine resource limits in one table,
since a container cannot exceed the machine it runs in.
Also: tagging is explained rather than just operated. A tester passed that step
and still said "don't understand what it did" — a tag is a name pointing at an
image, not a copy, which is the sentence that was missing.
22 pages. All links resolve and every page is reachable from the sidebar.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>