The Family Compute Center

Author: Alexander Avery

Posted: Thu | Jun 19, 2025

This article is written for those who are unfamiliar with Plan 9 and the 9P protocol, especially if you manage the devices for your household.

The Family Computer

If you grew up some time between 1980 and 2010, you likely had a family computer. Around the year 2004, as the PC became more popular, my family went from having two computers in the house to three.¹ For just about every family I know, computing trends followed this path, to a fault. As a result of this blind rush towards personal computing, the way we use computers has become expensive, finicky, and artificially limited. We just don’t think of it that way.

When I was a junior in high school, I purchased and built my first desktop PC. It had a multicore CPU, 8 GB of RAM, a GPU, a few hard drives, a motherboard, and a power supply. Then, I installed Windows 7, set up my user account, and over time installed the software I needed.

When I went away to college, I received a laptop with a multicore CPU, 8 GB of RAM, and an internal SSD. It came preinstalled with Windows 10, so I set up my user account and installed the software I needed.

When I was a sophomore in college and gained an interest in Linux, I decided to build another computer. I purchased the multicore CPU, 8 GB of RAM, a GPU, hard drives, motherboard, and power supply, and assembled them. Then, I installed Fedora, set up my user account, and over time installed the software I needed. Whenever I required new software, of course I would also need to install it on my laptop and the desktop at my parents’ house. That reminds me, I liked using Fedora enough to install it onto that desktop at my parents’ house, too. So, as you might have guessed, on one break from school I installed Fedora, set up my user account, and installed the software I needed.

This pattern is actually insane and completely detached from what computers have been capable of since 1990. In the rest of this article, I intend to tell you why these repeated actions are wasteful and redundant and how to avoid them.

CPUs

Modern CPUs are mind-bogglingly fast. If you are a decent software developer, you know this and also know how laughably underutilized this power is due to bad software practices. Using the first CPU for sale I see on AMD’s website, allow me to illustrate a point. This (currently) 700 USD CPU has 16 cores, 32 threads, a base clock speed of 4.3 GHz, and two integrated graphics cores clocked at 2200 MHz. Should software use this power effectively, every task performed by the median computer user would be completed instantly, but reality is different.

What Andy giveth, Bill taketh away.

Software is slacking, and people like shiny new things, so this CPU might actually get replaced after only five years. Has it really paid for itself by then? If you purchased a cheaper CPU, might it need to get replaced sooner? In a house with multiple family members, most would just multiply this cost for each person that “needs a new computer.”

Over the course of a day, I accumulated some CPU usage statistics on my desktop computer. I took the samples by reading from /proc/stat and used AWK to calculate how much time the CPU cores are idle while the PC is on!

while true; do grep -e "cpu\b" /proc/stat | tee -a cpulog; sleep 4; done

{ idle+=$5 }
{ for (i=2;i<NF;i++) total+=$i } 
END { printf "idle: %s total: %s idle%%: %s\n", idle, total, (idle/total)*100 }

Over an eight-hour sampling period, I used the computer for VoIP calls, remote screen sharing, running databases and HTTP servers, recording video on OBS, compiling software, and running test suites, among other tasks. Even though I anticipated low utilization, the results still surprised me.

idle: 49134273916 total: 53706525014 idle%: 91.4866

The CPU on the machine I use the most spends 91.4% of its time idle. It’s abundantly clear that the machine is underutilized, and I have therefore overpaid for all the other multicore CPUs in my house. I have overpaid not only financially but also with my time. Every CPU needs eventual upgrades or replacements, and each upgrade will only impact the singular device that it’s performed on. This only makes it more difficult for each CPU to become cost-effective before it must be replaced.

Hard drives

Even the way we use computer hard drives is suboptimal. Let’s take my desktop and laptop, for example. Both are running a minimal version of Fedora, and the total size of all installed packages is 8.0 GB. This isn’t much for each hard drive to hold, but it does introduce difficulty in other ways.

If I update my systems weekly, I find each time it requires that I download around 300 MiB per machine - on a Starlink connection. My internet speed is actually faster than most in my area, but it could be better. Even though updates can mostly take place in the background, on Fedora, you also need to upgrade to a new release at least yearly.² This is performed twice for my devices, and those updates usually involve the full 8.0 GB download or more. Nobody should need to download the same update N times, and for that matter, why should anyone have to install the same software N times either?

Similarly, we often deal with difficulty syncing files between our hard drives. Each device is isolated, so we need to install extra software or perform manual tasks to access our data. For example, as you take photos and videos on your phone, they end up on your phone’s hard drive. If you want those on your PC, you’ll have to plug your phone in, use some sort of “file sync” program, or even email yourself the images - yikes. Maybe the file sync program is the most seamless of the three options, but it still presents issues. Every device that needs to access these photos gets a redundant installation of the file sync program, and every file will be copied N times.

Furthermore, it’s likely that your hard drives are different sizes, and so your phone’s SD card will fill up faster than your desktop’s HDD. Should you upgrade the SD card on your phone or configure your phone file sync to allow only uploads? Perhaps you’ll allow uploads and downloads for small files only, but then you miss out on easy access to your videos. Either choice might keep you from upgrading your smaller devices too often, but before you know it, you’ll need a file from your desktop on your phone, and you’re back to emailing yourself. In addition, large files are the most tedious to transfer manually; if anything, that should be the type of file transfer you automate.

People regularly do this: upload a file from one device just to download it to another. Every time I have to do this, I feel a little piece of myself return to monke.

While we’re discussing hard drives, now might be a good time to decide which hard drives you want to back up to another site. I hope you don’t forget any important devices or files!

Use the network, Luke

We’re already solving some of the problems by syncing files over a network, but in doing so, we have approached a general problem with a specific solution. Why can’t we reduce most of our computing tasks to a shared interface that allows us to unite devices seamlessly across a network? Well, as it turns out, we can, and we’ve been able to since at least the 1980s. The real question is, “Why don’t we?” and the answer is, “I don’t know.”

The CPU server

Our CPU setup from earlier was ineffective and costly. It would be far better to have a single, high-performance CPU that each member of a household could use remotely through a low-power terminal.

When I say terminal, I don’t mean “terminal emulator”. These terminals can run audio and graphical programs locally, connecting to the main CPU server only when needed. Then, when the household requires faster processing, the cost is amortized in a single upgrade of the CPU server’s processor.

If you are imagining this setup comprised of several Linux or Windows machines, it may seem tricky, and you’d be right. Imagine you’re using something like RDP on the CPU server. When editing videos, how would you get the raw files onto the CPU server and the final edits back onto your terminal? Now we’re back to the issues with file synchronization. It turns out that the CPU server is not such a great idea in isolation.

We only need to introduce two more ideas to see the full picture.

The file server

A better way to sync files across many devices is to not store files across many devices.

When you are navigating your computer’s file system, there is nothing that requires the files and directories you see to be located on a hard drive within the same machine. Whether you are using File Pilot, or a shell, the interface presenting your files is metaphorical. Programs such as these can leverage the same interface without necessarily representing a local file system. By using a network transparent file protocol, the files you see and interact with could be from a local hard drive or a remote file server.

Perhaps a remote file server manages a directory /usr/alex/ for my user account. If I can import this directory, I could mount it anywhere in a local namespace; naturally, I’d mount it on /usr/alex/. The interesting thing is that I am not syncing the files from the remote server to my local hard drive. Instead, I am naming those remote files within my local namespace. If a program tries to read /usr/alex/lib/calendar, that’s when the kernel would copy those bytes over the network from the file server into program memory. By asking the kernel to write to /usr/alex/lib/calendar, a similar process takes place. If you could mount /usr/alex/ to your phone and point your camera app at /usr/alex/pics/DCIM/, each photo or video taken would be written to the file server. Then, when you want to edit those photos from your desktop, you can do so without uploading, downloading, copying, or any of the ceremony typically involved. At no point is state being copied to multiple hard drives.

You may already be thinking this sounds like a lot of induced latency. When editing photos, would every single save require your local terminal to send data over the network to the file server? Well, yes, but a better strategy is to perform filesystem-heavy tasks on the CPU server. Within your compute center, the CPU server(s) should have the fastest connection you can get to your file server. There will be latency between your terminal and the CPU server, but the large files will travel a short distance over a high-speed connection.

The final thing to note about the file server is that it doesn’t just share images, videos, and documents. If it did, you’d basically have a NAS. Again, we should apply this general-purpose solution as far as we can. Why not also use the file server to share programs and even the kernel? Even if your machines have distinct CPU architectures, you can have /bin/mips/, /bin/amd64/ and other directories for compiled programs on the file server. If the CPU server has a MIPS processor, it can mount /bin/mips/ to /bin/; if your terminal is x86_64, it can mount /bin/amd64/ to /bin/. In fact, CPU servers and terminals don’t even require a hard drive at all; they can rely on file servers (and the next discussed server) entirely for permanent storage.

The auth server

The final idea to discuss is that of an authentication server. This is an optionally separate machine from the file server that handles user accounts and interacts tightly with other machines in the grid. It enables file servers, CPU servers, and terminals to authenticate each other.

The benefits here are easy to portray. There is no need to set up user accounts per device you own. If a family member purchases a new computer, there is no need to set up the operating system or even create a user for said computer. He or she needs only to PXE boot the computer, log in with an existing user on the auth server, and provision the namespace from the file server.

Plan 9

This article is quite abstract, and I’ve yet to assert that such a system already exists. In the future, I’ll post some short demos of a Plan 9 grid performing some of these tasks.

Let’s bring it back to where we began this article: the family computer. It turns out that adding disparate computers didn’t help us; what we really needed was to enable multiple people to access the resources of the family computer simultaneously. Well, surprise, surprise, that’s precisely what time-sharing computers have been doing since the 1960s. Plan 9 advances this idea to networked computers in a way that personal computing completely missed.

I want to end this by sharing two interviews with Rob Pike and Russ Cox on usesthis.com. In each interview, they talk about their dream computer setup.

When I was on Plan 9, everything was connected and uniform. Now everything isn’t connected, just connected to the cloud, which isn’t the same thing. And uniform? Far from it, except in mediocrity. This is 2012 and we’re still stitching together little microcomputers with HTTPS and ssh and calling it revolutionary. I sorely miss the unified system view of the world we had at Bell Labs, and the way things are going that seems unlikely to come back any time soon.

[…]

I want no local storage anywhere near me other than maybe caches. No disks, no state, my world entirely in the network. Storage needs to be backed up and maintained, which should be someone else’s problem, one I’m happy to pay to have them solve. Also, storage on one machine means that machine is different from another machine. At Bell Labs we worked in the Unix Room, which had a bunch of machines we called “terminals”. Latterly these were mostly PCs, but the key point is that we didn’t use their disks for anything except caching. The terminal was a computer but we didn’t compute on it; computing was done in the computer center. The terminal, even though it had a nice color screen and mouse and network and all that, was just a portal to the real computers in the back. When I left work and went home, I could pick up where I left off, pretty much. My dream setup would drop the “pretty much” qualification from that.

A bit like phones: You have a phone just so you can access who/what is at the other end of the connection.

Twenty years ago, you expected a phone to be provided everywhere you went, and that phone worked the same everywhere. At a friend’s house, or a restaurant, or a hotel, or a pay phone, you could pick up the receiver and make a call. You didn’t carry a phone around with you; phones were part of the infrastructure. Computers, well, that was a different story. As laptops came in, people started carrying computers around with them everywhere. The reason was to have the state stored on the computer, not the computer itself. You carry around a computer so you can access its disk.

In summary, it used to be that phones worked without you having to carry them around, but computers only worked if you did carry one around with you. The solution to this inconsistency was to break the way phones worked rather than fix the way computers work.

My dream setup, then, is a computing world where I don’t have to carry at least three computers - laptop, tablet, phone, not even counting cameras and iPod and other oddments - around with me in order to function in the modern world. The world should provide me my computing environment and maintain it for me and make it available everywhere. If this were done right, my life would become much simpler and so could yours.

I would allow the setup to force me to carry a computer screen around, as long as it rolled up and fit inside something the size of a pen and had touch input when unrolled. As long as it had no local storage.

- Rob Pike

The thing I miss most about Plan 9 was the way that no matter which computer you sat down at, you had the same environment. Because we were working off a shared file server - there were no local disks on the Plan 9 workstations - you could go home and log in and all your work was there waiting. Of course, it only worked because we had good, fast connectivity to the file server, and only file state - not application state - transferred, but it was still a huge win.

Today it’s taken for granted that everyone has local files on disk and you need programs like Unison or Dropbox (or for the power users, Mercurial or Git) to synchronize them, but what we had in Plan 9 was completely effortless, and my dream is to return to that kind of environment. I want to be working on my home desktop, realize what time it is, run out the door to catch my train, open my laptop on the train, continue right where I left off, close the laptop, hop off the train, sit down at work, and have all my state sitting there on the monitor on my desk, all without even thinking about it.

Moving everything into “The Cloud” may be a path to that dream, but we are definitely not there yet.

- Russ Cox