Up: Ultimate Home Box
Previous: Hacking the Rollova: The Nuclear Option
There should be a box in every home.
There have been some major benefits to the centralization of always-on computing power (i.e. the cloud). The ability to shift resources from one customer to another as needed means a net reduction in actual resources needed. Allowing fewer companies to specialize in the skill of maintaining compute infrastructure results in less skill duplication, and so lower costs.
But it comes with some vulnerabilities too, mainly to the customer. Those vulnerabilities include:
One solution to these problems is a best-of-both-worlds combination. A retvrn to on-prem, if you will. But while on-prem has long thrived in the business space, it has effectively zero market penetration into the home. There is an exception to this: the router.
Anyone with an internet connection to the home has a router. It might be a 2-in-1 modem device, but either way they have one. This is a physical appliance: a computer, running software. It’s always on (unless it’s being reset), silent, has a small footprint, low-power, zero-maintenance, and relatively cheap. Clearly this intersection of properties is tolerable to normal people (i.e. not tech people).
Historically, in order to run a server in the home, one has had to compromise on those traits. But as single-board-computer technology improves, it’s becoming more and more possible to meet those requirements.
My intent is to design a single appliance that can serve the requirements of any normal person’s always-on computing ability, using off-the-shelf parts that anyone could buy and put together. The key constraints I plan to adhere to are as follows:
An important aspect to this design in my view is that it will replace and augment the capabilities of a router. The user should think of it as a fancy router. Thus it needs at least two ethernet ports, one for WAN (to connect to the modem) and for LAN (to connect to a computer, an ethernet switch, or a WAP).
Many of these capabilities are only just recently brought together in the form of the Rockchip RK3588. It is an 8-core ARM chip, with quite powerful on-chip graphics that include up to 8k video encoding/decoding. This is essential for high-resolution video streaming. It has enough PCIe channels to drive at least 5 SATA drives, which translates to a maximum storage of 76TB if you feel like spending $2500 on each SSD. A much more reasonable dollar:gigabyte ratio would give you a maximum of 40TB.
Speaking of storage, the biggest size constraint of the device volume is the storage drives. As such, I’ve decided to stick with 2.5" drives. Sandwiched neatly together, they can provide a lot of storage space without taking up too much physical space. Plus, in most cases it will make the most sense to populate with SSDs which typically don’t come in the 3.5" form-factor.
The board I’m currently working off of is the Radxa Rock 5 B. It has a RK3588 CPU, a 2.5gig ethernet port, and two PCIe M.2 ports (which is enough for one SATA controller and one additional ethernet port).
There’s no obvious way to power 5 SSDs off of the SBC, so a separate power supply module will be necessary, to provide both the 5V and the 12V needed by the SATA power connector.
In order to increase the reliability of the system and reduce the effort to maintain, I want to run NixOS. That permits creating a configurable and higly reproducable system to increase the likelihood of the system working together properly. It can also run some applications inside containers. Getting NixOS to run on the Rock 5 B has been the biggest challenge thus far, since the SBC is very new ahd has very poor upstream support in the kernel. I’ll write about that step next, as its one of the most important.
Cobbling some parts into a useful form is one thing. But the vision I have is greater than that, and will require much more work on the software and social side of things. The world I see is one in which the synergy of an interconnected mesh of these devices can provide network redundency.
Your hard-drive fails, or your entire device destroyed? Your data and configuration is encrypted and replicated across other devices on the network so you can recover it.
The mesh could also provide internal compute redundancy, but that would only work with data that doesn’t require encryption. Solving the problem of operating on encrypted data on an untrusted machine is much harder, and maybe impossible.
Obviously the other side of this coin is that part of your storage and compute power may be used by someone else. That’s a highly social problem to solve, but if people can see the trade-off, they might consider it worth it.