Home server finally kicks the bucket — you're staring at a blank disk, fresh install ahead — do you reach for Proxmox out of habit, or is that actually the right call? So Daniel sent us this one. He's been running Proxmox for years, three VMs, couple of disks in ZFS — Home Assistant, self-hosted DNS, and an Ubuntu VM. Server died, he's rebuilding, and it suddenly hit him: why dedicate an entire OS to being a hypervisor? Why not just run stock Linux with KVM and call it a day? And there's a fun twist — one of his VMs is Ubuntu, which means an Ubuntu VM sitting on an Ubuntu host. Is that weird? Is it fine? We're gonna dig into the real differences, not the tribal wars.
Right — and the thing is, both sides of this actually have good arguments. What makes this worth a full episode is that "I never even thought about the alternative" moment he describes. People reach for Proxmox the way they reach for the same coffee order. And I think that's actually the deeper question here — when does muscle memory become architectural inertia? If you've been clicking the same buttons for five years, you might not even notice the button has a cost.
Let's start with what he's actually trying to achieve. Three VMs on a single machine with multiple disks he wants pooled in ZFS. That's it. No clustering, no high availability, no live migration across racks. And that last detail is the crux of this whole conversation — because a lot of what Proxmox ships with was built for problems he doesn't have.
To be precise — because we should define the battlefield — we're talking about Proxmox VE, which is Debian under the hood, versus a stock Ubuntu Server install with KVM, libvirt, and potentially Cockpit for a management layer. If you just reach for the most recent stable of either, that's Proxmox VE eight point two released April of this year, running QEMU nine dot zero and a six point eight Linux kernel, versus Ubuntu twenty-four-oh-four LTS which as of the June point release is at QEMU eight dot two dot two and libvirt ten dot oh. That alone is an interesting spec sheet — Proxmox actually ships a more bleeding-edge QEMU than Canonical's LTS.
Which surprises me a little. I would have expected the LTS to be conservative across the board, but I guess Canonical draws their line differently for different packages. But QEMU version mismatches between host and guest aren't really a thing the way they might be with, say, the kernel. The guest OS in the VM sees virtual hardware — it doesn't really know or care what QEMU minor release is emulating it.
You've asked the precisely correct question before I even got to it, which is pretty efficient even for you.
Let's get one misconception out of the way before we dive into the platform comparison. Running an Ubuntu VM on top of an Ubuntu host — Daniel's scenario — is completely fine. Some people hear that and assume there's a recursion problem, like turtles all the way down. It's not recursive virtualization. The host runs KVM at the kernel level. The guest Ubuntu inside the VM is just another process from the host's perspective. There's no virtualized KVM inside the virtualized Ubuntu unless you specifically configure nested virtualization.
Which he wouldn't need unless he wanted to run Docker containers or KVMs inside that Ubuntu guest. So let me ask the obvious follow-up — what if he does want containers inside that guest? Is that where the recursion fear actually bites?
Even containers inside the guest — easiest thing. No nested virt required. Docker runs perfectly fine inside a KVM virtual machine without any special configuration, because from the container runtime's perspective, it's just talking to a kernel. The guest kernel. It doesn't know it's virtualized. The only time you need nested virtualization is if you want to run KVM inside KVM — a hypervisor inside a VM. That's a very specific use case, like testing your own virtualization setup, or running something like Firecracker inside a VM for extra isolation layers. For Daniel's Home Assistant and DNS containers?
In so many words: the host couldn't care less what distro you're installing inside it.
To use a terrible compressed image that brotherhood obligates me to make — it's like your landlord not caring what color you paint your own living room.
"The landlord-hypervisor of design choices.
That's the one. So we can put that anxiety to bed immediately. It's simply not a technical problem. The host would like to know whether you, the listener, are installing Ubuntu or Arch or NixOS inside — it doesn't care either way. KVM presents a generic x86 machine with a virtio disk and a network interface. The guest kernel boots, detects the hardware, and carries on. The host just sees a qemu-system-x86_64 process chewing CPU and RAM.
Now, why do people reach for Proxmox, and what's that decision pulling along? Herman, you've been in the docs.
The architecture is genuinely well thought-out. Proxmox is Debian plus a custom kernel they call pve-kernel, plus a management stack largely written in Perl — which partly explains the dated feel, and we'll come back to that — and it tightly integrates three main orchestration layers. You get KVM and QEMU for full virtual machines, LXC for lightweight containers, and a fairly deep UI-level integration of ZFS and Ceph. You install the ISO, and out of the box your storage pools have a dashboard. You can create ZFS pools, manage vdevs, schedule scrubs — all from the GUI. In Ubuntu, ZFS is an apt-install away — but the management experience is a terminal.
Which matters because — how many drives do you have to lose before you decide button versus command line is a trivial difference or a fatal one? Let me put it differently: at two in the morning, when a disk is clicking and you're trying to remember whether the correct command is zpool replace or zpool attach, does the GUI save you or does it just mean you never learned the commands in the first place?
That's exactly the tension. And I'll admit, Proxmox's ZFS interface, sparse though it might look, is where its "appliance" character shines through. The moment you click "create pool," it's making all the ashift decisions you could second-guess manually, but fine choices. It defaults to ashift=12 for 4K-sector drives, it sets up reasonable redundancy if you select mirror or RAID-Z — these are things a new user might not know to check. On Ubuntu — look, ZFS management is not hard CLI work. But when you're running zpool status at three in the morning because a disk spat an error and the scrub is locked, the readout is...
The readout is mostly you talking to yourself.
Your sleep-deprived self. There's a specific kind of dread when you see "DEGRADED" in all caps and then a long UUID string, and you have to mentally map that to a physical SATA port. Proxmox at least gives you a visual disk layout. Objectively — the hidden point here is much deeper, though.
Let's go there. What's the hidden point?
The hidden point is that Proxmox isn't just a hypervisor — it's an opinionated stack. It makes choices for you. And that's either a gift or a straightjacket depending on whether those choices align with what you actually need. For Daniel's three VMs, the question is whether the opinionated stack is solving problems or just consuming resources for features he'll never use. Corosync, for instance — that's the cluster communication service. It's running even on a single node, watching for quorum that will never come, because there's no second node to form quorum with. It's not a bug, it's just... unnecessary overhead for his use case.
Look at resources. To take an idle server you're building something like this at home on, compare Proxmox's overlay management tax.
Here's the real number, and this number will vary somewhat month to month, infrastructure to instance to metric, but it's a decisive fork in the base proposition no matter whom you ask and whenever — A Proxmox de-facto-install isn't sitting completely dormant ready for VMs. The bundled pveproxy, the daemon arrangement, Corosync that watches quorum, even just sitting doing nothing at all heading up... call it a clean gigabyte to around one-point-two gigabytes. My sample scans before any single VM is present floated around thirteen hundred roughly. Meanwhile, minimal Ubuntu Server idle is maybe under three hundred fifty — a whole gig absolute space between the two platforms before any actual spinning VM happens.
Which — on a hypothetical box you've bought with sixteen total — really physically does strain options underneath you fully forward. I want to pause on that number because it's easy to hear "one gigabyte" and think it's trivial in the age of cheap RAM. But on a sixteen-gig machine, that's over six percent of your total memory gone before you've done anything useful. If you're running Home Assistant, which can be surprisingly memory-hungry depending on add-ons, plus a DNS resolver, plus an Ubuntu VM for whatever else — suddenly that gigabyte is the difference between comfortable headroom and swapping to disk.
It absolutely squeezes out some proportion that the day you think, well what if I want really elastic resourcing on the DNS or caching — of that sixteen you prep, figure VMs allocate twelve — except now the host itself reserved an eighth before touch. And to the note though — this granularity scales in ways that if that sixteen situation actually makes no difference for a tight workload, those gigs never fully arrive wanted. But Daniel mentioned he might repurpose this box later — maybe add a streaming appliance, maybe spin up a game server for a few friends. That's where the overhead starts to compound.
Right — and this is the "future creep" problem. You build for three VMs today, but six months from now you think "well, I've got this hardware sitting here, might as well add Plex." And now that one gigabyte overhead isn't just one gigabyte — it's one gigabyte plus the fact that Proxmox's management stack scales its resource usage slightly with each additional VM because it's tracking more states, more storage volumes, more network interfaces. It's not linear, but it's not zero either.
Here's another factor that's absolutely core though weirdly little mentioned in most how-to guides — not ZFS hosting slices but how Ubuntu currently handles USB passthrough compared to Proxmox, which matters concretely when Home Assistant needs a Zigbee dongle. Matter of fact, a dongle device very concretely works or doesn't depending on how the host exposes USB devices to the guest. In Proxmox, you click "Add USB Device" in the VM hardware tab, select the dongle from a dropdown, and it's done. It survives reboots, it reconnects if the dongle is unplugged and replugged. On Ubuntu with libvirt, you can do the same thing through virt-manager or virsh attach-device, but the persistence behavior is slightly different — you need to make sure the XML configuration includes the vendor and product ID so it reattaches after a host reboot.
If you're using Cockpit instead of virt-manager, what does that flow look like?
Cockpit's VM plugin does expose USB host device passthrough, but it's a free-text field where you enter the vendor and product ID manually. It works, but it's not the polished dropdown Proxmox gives you. For a single Zigbee dongle that you set up once and never touch again, the difference is maybe five minutes of effort. But it's emblematic of the broader experience gap — Proxmox has spent years polishing these specific workflows, while the stock Linux approach assumes you're comfortable looking up USB IDs in lsusb output.
The USB passthrough question isn't a dealbreaker for either platform, but it does surface something important — how much time are you willing to spend on the initial setup versus ongoing maintenance? Because the real benchmark might not be "can I pass through a USB device" but rather "when I need to take a backup before a kernel update, how many steps is that?
With Ubuntu, if your VMs stay tiny, you develop a daily routine — virsh snapshot-create-as takes a few seconds. But out of the box, that's another shift of mental context towards deeper base backup prep method. You need to know that snapshots exist, that they're different from backups, that external snapshots behave differently from internal ones. Proxmox gives you a "Backup" button that does a consistent vzdump backup to a storage target of your choice, with retention policies built in. It's not that Ubuntu can't do this — it's that Proxmox makes it the default path of least resistance.
Often listeners debate whether "form-click UI could probably do another decade and becomes the ZFS interface." Visually and really even tact-mapping through managing multiple exports, three VLAN bridges, small firewall selector handling — technically identical across the QEMU line mostly to pure QEMU config style under both world ends. Slight difference but KVM is KVM in fully modern patches and performance return effectively true — performance round-trip assuming identically reserved models whether XML mapping is tucked into a Proxmox framework or hand-written. The weight truly remaining — do you wish to let isolated package mirrors actually run smoother without an extra appliance layer in the path? When later memory allocations deeper into the number breakdown crowd the zero-slab from LVM snapshot counts, it's actually identical — run that DNS resolver off equal QEMU bypass and it's negligible. Overall machine shape function is indistinguishable after host resource redistribution for nearly zero contention on hardware speed until base feed reaches two-thirds or more tenant raw compute scheduling moving into NUMA-ish neighbor lines inside the bus.
That's a dense way of saying something important — raw VM performance is a tie. If you spin up identical virtual machines on Proxmox and on Ubuntu with the same QEMU version or close to it, with the same CPU model and same virtio drivers, your benchmarks will be within margin of error. The hypervisor tax is real on the host side, as we discussed with that gigabyte overhead, but inside the guest? KVM is KVM. So the decision isn't about which platform makes your VMs run faster — it's about which platform makes you, the operator, faster and less error-prone at three in the morning.
Which brings us to the management layer question. Cockpit has come a long way. If you haven't looked at it recently, it's worth a fresh look — the VM management interface is clean, it exposes storage pools, it gives you a noVNC console in the browser. It's not as feature-deep as Proxmox's interface, but for three VMs, how deep do you need to go?
Cockpit in its current form handles the basics well — start, stop, console, basic resource graphs, storage pool creation. Where it falls short compared to Proxmox is the integrated workflow stuff. Proxmox ties together storage, networking, and VM configuration in a way that feels cohesive. You create a ZFS pool, then you create a VM and select that pool as the storage target, and it just knows how to create a zvol. In Cockpit, you might need to create the zvol manually first, then point the VM at it. It's not hard, it's just... More chances to fat-finger a path.
Let me try to synthesize where we are. For Daniel's specific case — three VMs, single node, ZFS, no clustering — both platforms are technically capable. The performance inside the VMs will be identical. The difference is entirely in the operator experience: Proxmox gives you an appliance-like GUI that reduces the chance of mistakes, at the cost of about a gigabyte of RAM and a more opinionated stack. Ubuntu with KVM and libvirt gives you a lighter host, more flexibility, but requires more CLI comfort and more deliberate setup for things like backups and USB passthrough.
That's the core tradeoff. And I think there's one more dimension we should touch before we wrap the comparison — the upgrade experience. Proxmox does major version upgrades through apt, same as Debian, but because it ships its own kernel and its own package repositories, you're trusting the Proxmox team to keep things compatible. Ubuntu LTS upgrades are tested against a much wider ecosystem. For a home server that might run for years without a reinstall, the upgrade path matters.
That's a fair point. A Proxmox major version upgrade — say from seven to eight — is a documented process, but it's a process. You're advised to backup everything first, which you should do anyway, but the fact that the advice exists tells you something about the risk profile. An Ubuntu LTS upgrade from twenty-two-oh-four to twenty-four-oh-four is also a process, but it's one that millions of people have run, and the edge cases are better understood.
If you're running stock KVM on Ubuntu, your VMs are just QEMU processes and disk images. You can literally copy the disk images to another machine and start them there with a different libvirt version. The portability is higher because the abstraction layer is thinner. Proxmox VMs will also migrate, but you're more likely to want to stay within the Proxmox ecosystem because of how it manages storage and configuration.
Let's take a brief tangent here, because you mentioned XCP-ng earlier as a point of comparison, and I think it's worth giving listeners the thirty-second overview of where that fits. XCP-ng is the open-source fork of Citrix XenServer, and it's a serious piece of engineering — it uses the Xen hypervisor rather than KVM, which is a fundamentally different architecture. Xen runs a privileged domain called dom0 that manages the hardware, and guest VMs run in unprivileged domains called domU. This is a type-one hypervisor setup that's arguably cleaner than KVM's model, but it also means you can't just run arbitrary Linux on the host — dom0 is a carefully controlled environment.
XCP-ng has a modern management interface now — they rebuilt it in JavaScript, it's responsive, it feels contemporary in a way Proxmox's Perl-based UI doesn't. But there's a learning curve. The networking model is different. Storage is managed through SRs — Storage Repositories — which have their own abstraction layer. For Daniel's three VMs, XCP-ng would be bringing a lot of architecture for not much benefit. It shines in larger deployments where you want Xen's proven isolation properties and the orchestration features that come with Xen Orchestra.
XCP-ng is the "if you're curious and want to learn something new" option, not the "I just want my Home Assistant back online by dinner" option.
And the same goes for oVirt, which is Red Hat's upstream for their virtualization management — it's built for managing dozens or hundreds of nodes, with a heavyweight Java-based engine and a PostgreSQL database. Running oVirt for three VMs on a single node is like using a cargo ship to cross a pond. It'll float, but you'll spend more time managing the ship than crossing the water.
Harvester, for the Kubernetes-native crowd — that's a whole different conversation. Harvester is fascinating, it treats VMs as Kubernetes custom resources, but it assumes you want a cluster and you want Kubernetes as your management plane. For Daniel, who just wants three VMs, that's adding a container orchestrator to manage a hypervisor to run three virtual machines. The layer cake gets tall fast.
Right — each of these alternatives makes sense in its intended context. But the intended context is not "single home server with three VMs and some ZFS disks." So the real choice narrows to Proxmox versus stock Linux with KVM, and the decision criteria are what we've been discussing: overhead, management comfort, backup workflow, and upgrade path.
Let's shift to something we touched on earlier but didn't fully explore — the container question. Daniel's current setup uses VMs, but what if he wanted to run some workloads in containers directly on the host? This is where the platforms diverge more sharply.
Proxmox supports LXC containers natively — they're first-class citizens in the UI alongside VMs. You get a container creation wizard, resource controls, snapshots. But LXC is a specific container technology — it's more like a lightweight VM than a Docker container. It runs a full init system, you can SSH into it, it feels like a VM that shares the host kernel. Docker is a different paradigm — application containers, not system containers. If you want Docker on Proxmox, the recommended approach is to run it inside a VM, because Docker on the Proxmox host itself can interfere with Proxmox's own networking and storage management.
That's where the "Ubuntu VM on Ubuntu host" question gets a practical twist. If Daniel wants to run Docker containers — which is very common for Home Assistant add-ons, or for self-hosted services — he's either running Docker inside his Ubuntu VM, which is perfectly fine, or he's creating a separate VM just for Docker. On stock Ubuntu, he could run Docker directly on the host alongside his KVM VMs, no extra layer needed.
This is a genuine architectural advantage for the stock Linux approach. On Ubuntu Server, you can run KVM for the workloads that need full isolation — like Home Assistant OS, which expects to own its entire environment — and Docker for the lightweight services that don't need a full VM, like a DNS resolver or a reverse proxy. They coexist peacefully. On Proxmox, the recommended path is to keep the host clean and put everything in either VMs or LXC containers. It's not that you can't run Docker on Proxmox — you can, people do — but you're fighting the platform's opinions when you do.
Fighting the platform's opinions is exactly the kind of friction that, six months later, you regret when an update breaks something and you're searching forum posts trying to figure out why your Docker bridge is conflicting with Proxmox's virtual bridge.
The bind mount situation is another friction point. If you want to share data between the host and containers or VMs, Proxmox has its own way of doing things — storage plugins, directory storage types, mount points defined in the datacenter configuration. On stock Linux, you just... mount the filesystem. It's a directory. You pass it to the VM with a virtio-fs or a 9p share, or you bind-mount it into a Docker container. The transparency is higher because there are fewer abstraction layers between you and the kernel.
We've got a clear picture forming. Let me try to articulate the decision framework that's emerging. If you value a turnkey appliance experience — click a button, get a ZFS pool, click another button, get a VM with backups scheduled — Proxmox is excellent at that. The RAM overhead is real but probably acceptable for most home servers with sixteen gigs or more. The tradeoff is that you're buying into an ecosystem that makes some things easier and other things — like running Docker directly on the host — harder than they would be on stock Linux.
On the flip side, if you're comfortable at the command line, if you want the lightest possible host, if you might want to repurpose the machine later for non-virtualization tasks, or if you want to mix KVM and Docker freely on the same host — stock Ubuntu with libvirt and Cockpit is a compelling choice. The setup takes longer, but the ongoing flexibility is higher.
I want to add one more practical consideration that often gets overlooked — the "bus factor" for a home lab. If you're the only person who manages this server, and you get hit by a bus — metaphorically or literally — how hard is it for someone else to pick up the pieces? Proxmox has a web interface that's relatively self-documenting. Someone with basic technical literacy could probably figure out how to start a stopped VM or check why a disk is full. A stock Linux box with virsh and Cockpit? That's a taller order for a non-specialist.
That's a fair point, though I'd argue the counterpoint is documentation. If you document your setup — "the VMs are defined in /etc/libvirt/qemu, the disk images are in /var/lib/libvirt/images, here's how to start them" — the stock Linux approach is actually more transparent because there are fewer layers of indirection. But you have to write that documentation. Proxmox's documentation is the web interface itself — it's self-describing in a way that a directory full of XML files is not.
The bus-factor argument cuts both ways, depending on whether you've written good docs. Which, let's be honest, most of us haven't.
Let's bring this in for a landing. If I'm Daniel, sitting in front of a blank disk, coffee in hand, what do I do?
I think the answer depends on one question he hasn't explicitly asked but that's implicit in his setup: is this server going to stay three VMs forever, or is it going to grow? If it's going to grow — if he might add a fourth VM, a fifth, if he might want to experiment with clustering down the line — Proxmox's overhead becomes an investment in future capability. The Corosync that's idling uselessly today becomes useful the moment he adds a second node. The integrated backup system that feels like overkill for three VMs becomes a lifesaver when he has eight.
If it's going to stay small — if this is just Home Assistant, DNS, and a utility Ubuntu VM for the foreseeable future — then stock Ubuntu with KVM is lighter, more flexible, and doesn't lock him into a platform he's not fully utilizing.
There's also the "tinker factor." Some people enjoy the process of setting things up, configuring libvirt, writing a few scripts for backup. For them, the stock Linux approach is satisfying in a way that clicking buttons in Proxmox isn't. Other people want their home automation to just work so they can go back to automating their lights. For them, Proxmox is the right call.
The advice isn't "use X" or "use Y." It's "know thyself, and know thy future plans." Which is unsatisfying in its nuance but honest.
The best kind of unsatisfying.
Let's wrap with a quick practical note for listeners who want to try the stock KVM route. On Ubuntu twenty-four-oh-four, the minimal install path is: apt install qemu-kvm libvirt-daemon-system virtinst bridge-utils. That gets you KVM and libvirt. Then apt install cockpit cockpit-machines for the web interface. ZFS is apt install zfsutils-linux. You'll need to create a bridge manually in netplan if you want your VMs on the same network as your host — that's probably the fiddliest part, and there are good guides for it. Total time from blank disk to first VM booting: maybe an hour if you're following a guide, thirty minutes if you've done it before.
For the Proxmox route: download the ISO, boot it, follow the installer. You'll have a web interface at port 8006. Create a ZFS pool during install or after. Total time to first VM: maybe twenty minutes, and most of that is waiting for the ISO to copy.
Neither path is wrong. Both will serve Daniel's three VMs reliably for years. The difference is in what happens on the Tuesday morning when something breaks, and whether the tool you chose makes that moment easier or harder for the person you are at that moment — not the person you were when you installed it.
That's the real test. And it's why this conversation matters — because the person you are at install time is optimistic and caffeinated. The person you are during an outage is neither of those things.
Before we close out completely, I want to touch on one more thing that's slightly outside our main topic but keeps coming up in discussions like this — the question of whether the hypervisor model itself is on the way out for home labs. We've seen a shift toward container-native setups, people running everything in Docker Compose or Podman, and treating the host as just a container runtime. Does that make the whole Proxmox-versus-KVM debate feel like arguing about the best way to arrange deck chairs?
I don't think so, because VMs and containers solve different problems. Containers share the host kernel, which means they're lighter but also less isolated. If you want to run Home Assistant OS, which ships as a full disk image with its own kernel and init system, you need a VM. If you want to run a different operating system — say, a FreeBSD VM for ZFS experimentation — you need a VM. Containers are great for Linux userspace isolation, but they're not a replacement for hardware virtualization when you need it.
The hypervisor isn't going anywhere. It's just becoming one tool among many rather than the centerpiece of the home lab.
And that actually strengthens the case for the stock Linux approach — if your host is a general-purpose Linux box that happens to run KVM, you can also run Docker, Podman, NFS servers, whatever you need. It's a Swiss Army knife. Proxmox is a really good virtualization scalpel. Both are valid tools; you just need to know which one you're reaching for and why.
Alright, I think we've covered this from every angle that matters. Let's give Daniel and our listeners the short version.
The short version: if you want an appliance that handles ZFS, backups, and VM management through a web UI with minimal setup, and you're okay with about a gigabyte of host RAM overhead, use Proxmox. If you want a lighter host, more flexibility to mix containers and VMs, and you're comfortable with the command line and a bit of initial configuration, use Ubuntu with KVM and libvirt. Both will run your VMs at effectively identical performance. Neither is wrong.
If you're still not sure — try both. Spin up Proxmox, spin up Ubuntu with KVM, see which one feels right. The cost of switching is an afternoon and a backup restore. That's the beauty of this whole space — the stakes are low, the learning is high, and the worst case scenario is you learn something about how your infrastructure actually works.
Which is never a bad outcome.
One final note — Daniel, if you're listening, we'd love to hear which way you went and how it's working out. Same goes for anyone else who's made this decision recently. Drop us a line, tell us your setup, tell us what you'd do differently. We read every one.
Now, because we promised a fun fact, and because Hilbert has been patiently waiting in the wings with something completely unrelated to virtualization but deeply related to the human impulse to measure things precisely —
I love where this is going.
Hilbert, take us home.
Hilbert: In the 1920s, French colonial administrators in Mali briefly standardized measurement of annual agricultural tithes using an obsolete sonic ranging instrument — the "claquette harmonique" — which assessed dry grain volume by measuring resonance decay inside sealed copper jars anciently tuned to Abidjan-trade reference vessels, based on a now-debunked theory that certain acoustic decays precisely map to kilogram fractions due to implied numeric harmonic overstructures inside raw fonio.
[long pause] So what you're telling me is that somewhere in the archives of French colonial bureaucracy, there is a document that says "we measured grain by hitting a jar and listening to it ring.
Hilbert: The theory was that the resonance decay curve contained information about the grain's density and moisture content, which in turn correlated with mass. It was, of course, completely wrong — the acoustic properties of a copper jar filled with fonio are dominated by the jar, not the grain. But it was wrong in a beautifully systematic way.
I love that this is how we're ending — with a reminder that the impulse to build elaborate measurement and management systems for things that could be handled more simply is not new, and is not limited to computing.
The claquette harmonique is the Proxmox of grain measurement. Beautifully engineered, solves problems you might not have, and ultimately — the grain doesn't care.
On that note — thank you for listening. If you enjoyed this episode, share it with someone who's staring at a blank disk and wondering which ISO to download. We'll be back soon with more questions you didn't know you needed to ask about infrastructure you didn't know you needed to think about.
Until then — may your scrubs be clean, your snapshots consistent, and your Zigbee dongles always properly passed through.
