Thought a bit more lately about how to organize the low-level software responsible for recruiting and orchestrating diverse worker devices, such as old smartphones, tablets, laptops, desktops, and servers. This software infrastructure layer that sits below the actual user-facing apps has a few components. First, there’s some kind of daemon shipped to the worker devices to get them to participate in the cluster and listen for jobs. Second, there’s the firmware flashed onto the microcontrollers (MCU) responsible for emulating various USB devices. Third, there’s some process on the microprocessor (MPU) that’s responsible for talking to the previous two and managing them.

Let’s zoom in on the first item, the payload shipped to the worker devices. Its purpose is to tell the MPU about what sorts of resources are available locally, and be able to take on various kinds of processing job on the worker device it’s hosted on. This roughly corresponds to a Kubelet in the world of Kubernetes, but there’s no way we’ll touch that bloated unwieldy ecosystem to link up devices revived from a junk drawer. I was thinking maybe we could write a minimal worker daemon in Rust, such that we can then compile it into a lean binary for any relevant worker architecture.

To allow the worker daemon to natively tap into as much hardware as possible, we can wrap the shared logic into a minimal platform-specific wrapper. On Android smartphones and tablets, this could mean an “app” with no UI, which can nevertheless grant our daemon access to the GPU, wireless, among others. On POSIX-capable systems like laptops, desktops, and servers, this might mean a systemd service wrapping the binary. The worker daemons might, in turn, launch battle-tested tools as subprocesses, such as llama.cpp and ripgrep, as a way to harness local hardware resources using existing libraries. The worker daemon could preserve the underlying tools’ standard APIs, such as the OpenAI-compatible endpoints for LLM inference, or it could abstract these into uniform jobs and resources.

crustacean

I went through the rustlings project again over a couple days, as my knowledge of the Rust language was, well, rusty. It’s a fantastic learning resource, consisting of just under 100 tiny exercises. In each exercise, you get a file with certain compiler or runtime errors, and you need to fix those issues before moving on to the next puzzle. There are a few chunkier quizes after larger groups of chapters, and each exercise also has a hint that tends to link to the relevant documentation.

Going through it again was so much fun, probably the most fun I had “at work” in a while, thanks to the self-contained nature of the puzzles, the progress bar nudging you to complete all challenges, and the smooth increase in difficulty. At the end, you get a visit from a crab in your terminal, bringing you more obligatory puns.

llms

The experience above helped me realize how much I missed actual programming rather than manipulating systems by chatting with an intermediary LLM. I had a similar experience a few months ago, when I was shocked when I realized that I really enjoyed creating an actual slide deck, but mostly because of the direct interaction with the object of work. Extensive mediation makes you feel numb, while direct and reactive interfaces support states of flow.

Beyond the personal satisfaction angle, I also grew more skeptical lately about the long-term maintainability of projects developed with heavy LLM involvement. Actually sitting with the problem, even if tedious or mechanical at times, helps you incrementally build valuable context. And if you aim to be involved with maintaining a project, you might as well understand it deeply. What I can’t build, I don’t understand. And why would I take the time to use a system you haven’t taken the time to develop.

Anyway, I wanted to pull together those few strings related to using LLMs into a coherent policy for this project, partly inspired by Rust’s own. It’s okay to use LLMs to study new topics and debug systems you’ve built, but no synthetic content should end up in the final product. It’s okay to use LLMs to prototype and experiment with different ways of implementing functionality, but the end result should be completely hand-written, someone should be responsible for it. Also, even if education and experimentation are allowed uses of LLMs, the used models must be open weights. This is meant to prefigure the practice of actually relying on local compute.

firmware

Here’s an example of a way in which I plan to use open weights LLMs the moment the development boards I ordered arrive. The firmware we’ll need to flash on the MCUs connected to the worker devices via USB will need to be very good at controlling the physical silicon blocks (PHYs) dedicated to USB communication. There are a few promising libraries and stacks that might be able to grant us control over the USB PHYs found in the incredibly cost-effective MCUs manufactured by WCH.

First, there are the examples shipped by WCH itself, but they appear to be little more than flaky demos. Second, there’s CherryUSB and lwIP, libraries grown out of Asian hardware communities with strong support for WCH chips, but they might be quite low-level. Third, there’s the option to use those two libraries as part of the real-time OS called RT-thread, but it might add bloat and overhead. Fourth, there’s the option to use the Rust library embassy, which would consolidate the codebase, but has only experimental support for WCH PHYs.

I’d like to have LLMs have a go at implementing dummy firmware behaviors using these various stacks, such as getting the MCU to act as a network switch across its USB ports, or emulating a dummy storage device when connected. And I’d study whether it actually worked, the number of lines of code each approach required, and the general shape of the resulting implementation. I wouldn’t use those rapid prototypes as part of the final firmware that ships with the product. Instead, I’d only throw LLMs at the problem to help triage the available options going forward based on concrete findings. And probably with a Flash or Air model variant out of the Chinese labs. Can’t wait for the development boards to arrive.

e-waste

I also had to drop by an e-waste processor this week, and I’m including it here as it’s reasonably related. We picked up a batch of servers to use it in our pilot course that will take place in three schools this coming academic year. Each of them is a veritable mystery box, you don’t know whether you’ll get one packed with a dozen RAM sticks or whether even the fans will be missing. It’s also satisfying to learn where they came from, in our case it was mostly from a bank and a utility company.

It’s interesting how some of them come preloaded with those hardware testing procedure that go beyond a basic POST. You get checks and result reports per component, down to individual fans. When recruiting worker devices in little cloud, we should probably test capabilities when trying to detect them in a similar way.

Having run out of ideas for simplifying the enclosure (for now), I started digging a bit deeper into the actual protocols through which little cloud’s microprocessor (MPU) could communicate with the individual port microcontrollers (MCUs). The initial idea from a couple weeks back was that the MCUs could act as software-defined USB controllers driven by the MPU, such that they could present themselves as anything from a memory stick to a network card to the worker devices.

However, I’m not sure anymore about SPI as the protocol of choice for having the MPU communicate with the port MCUs. There are a few downsides. First, SPI would require the MPU to explicitly “chip-select” and query every MCU regularly, eroding bandwidth and increasing complexity. Second, we’d need to route 5 or so pins out of each MCU. Third, the USB driver ecosystem doesn’t natively overlap with SPI all too much. I did get to order an evaluation board predicated on this approach before growing skeptical about it, though.

ethernet

Another option for the MPU-MCU interconnect would be Ethernet. In this arrangement, the MPU and MCUs would connect their Ethernet pins to a dedicated on-board switch chip. 100 Mbps seems quite common as a choice of Ethernet speed on MCUs that implement it, which is higher than typical SPI speeds. Plus, it natively supports many-to-many communication, unlike SPI where only the MPU could initiate exchanges as master.

There is also USB/IP, which appears to enable the MCU USB controllers to appear as local, native ports to the MPU. It works by sending USB packets over a network, in our case a network that lives entirely on a PCB. Though USB/IP appears to only handle host roles natively, not so much device roles. We’d also incur the Ethernet switch on the BOM, and Ethernet on MCUs carries a premium. Could we do better?

usb

What if we used the same stack and tooling to connect the MPU with the port MCUs as we do when connecting MCUs to worker devices? The MPU could be the USB host that connects to many MCU devices. Crucially, MCUs would need to have two independent USB buses, a device-only one oriented towards the MPU, and a dual-role one oriented towards the worker devices. An interesting precedent here are those PC-to-PC cables that present themselves as a device to both USB hosts and shuttle data through.

If we could reduce the interconnect protocol to USB, we’d get the benefit of only having to use one stack for both interconnect on the PCB and communication with worker devices. CherryUSB appears to be a very versatile USB library, with strong support for the cheap Chinese MCUs. USB would also only require us to mostly route 2 data pins only out of an MCU, easier than 5. Most MPUs already have dedicated USB silicon, which is not the case for Ethernet. The MCUs might be able to only lightly edit USB packets shuttling through.

We would still need to use a USB hub between the MCUs and the MPU, and two USB buses on an MCU is not too common. But these parts are below 2$ still. I also realized we definitely need high-speed USB at least for having laptops or desktops potentially boot a live OS off of little cloud. Full-speed only would take forever to load the OS in memory. USB hub concurrency is also much more mature than via SPI.

hub

If we have a USB hub IC standing between the MCUs and the MPU, we could also route some of the hub buses out directly to ports. This could enable ports that can only connect to phone or tablet workers, not laptops or desktops, but for a very low cost. If MCUs with two high-speed USB buses grow into a meaningful cost center on the bill of materials, we could potentially offset this by only having some ports with full dual-role data capabilities. I’m not a fan of the broken symmetry across ports, although it could match the real-life e-waste distribution.

switches

Another option I considered briefly that I wanted to mention in the logs was that of analog switches on the ports. Need to emulate a host? Connect the port to a hub IC. Need to emulate a storage device? Connect it to a read-only flash on the board. This would mean lowering the emulation logic down to the hardware level. Though I figured it would be unwieldy to manage and iterate on, besides disabling the option to emulate multiple devices on the same port. I’d rather stick to two-sided high-speed MCUs, potentially occupying only part of a USB hub to the MPU. Driven entirely by the MPU software.

I took the general ideas for little cloud’s form factor from log entry #2 and implemented them in Onshape. The construction is pretty basic. Because we get lots of symmetry in a 1U rack-mountable box, we start by sketching out a quarter of both the inner and outer shells. We then flange from each towards the opposite plate.

Then, create mounting holes on the short and long sides. Also, we can remove material from the bends themselves, following the “fold it yourself” idea from a few weeks back.

Then, mirror both inner and outer shells across the two base axes to get the actual clamshell box. Finally, create a through-all hole and pattern it linearly across the same axes to implement the modular mounting interface idea.

simpler

After seeing it take shape and bouncing ideas off of others, I decided to push for modifications related to the grill, supports, and size. When it comes to the grill, I realized that sheet metal costs are partially a function of the perimeter length of all cuts. A grill with a gazillion holes takes a toolhead more to cut out, keeping it busy instead of fulfilling other jobs. Also, even if punctured by a lot of holes, the grill’s remaining material might still pose resistance to the fans, reducing the volume of air they manage to move around worker devices per unit time. So we’ll go for a basic large hole instead.

When it comes to the supports, I realized that it would be simpler to get hold of them through the same manufacturing process as the enclosure itself. We might as well just build them out of sheet metal while we’re at it, consolidating our supply chain. I played around with a few possible geometries, some requiring more material and bends than others, some requiring additional screws for mounting. I quite like the simplest one, two bends and no screws required. Instead, it seems to allow worker devices to securely rest on one side because of its bottom geometry and how it interacts with the enclosure. Move it around in your head.

When it comes to size, I realized we can maintain server rack compatibility while making the enclosure smaller. A smaller enclosure appears more manageable for end-users, more in line with household e-waste statistics, and of course it would cost a bit less. We can then recover the rack-mountable property through a separate face plate that attaches to both the enclosure and the server rack, but only if needed. For lack of a more principled constraint, I then opted for the general size of “fits two standard fans side-by-side” for the main enclosure.

quote

I was curious to run the current 3D models through JLCCNC for an instant quote at 1K volume. If we go for 1mm aluminum for the shells, we get a bit over 3$ per shell. Opting to laser-engrave the outer shell as a finish gets us instead to 5$. That finish seems cheaper, more durable, and more recyclable than layering silkscreen paint on the enclosure, and it would be neat to be able to make the device explain itself through labels and visual cues. The supports would be a bit over 0.5$ per piece, perhaps these could be stainless steel. The cheapest delivery option is in the same ballpark as the shells, but it would take forever to arrive. I signed up for a course on operating the CNCs at a local makerspace to be able to prototype faster. I’ll share how that goes in a future update.

simplest

Then I thought, what if the case would just be the bare PCB and a top cover on standoff spacers? It seems there’s no hard regulatory requirement for a box to explicitly be enclosed on all sides. The PCB would match the footprint of a flat metal sheet sitting above it on 4-6 standoffs. The sheet would retain the fan cut-outs and support mounts. Though, if we use standoffs, we might as well use them as supports, too.

I’d rather have the whole arrangement be incredibly cheap than feel premium, given it’s intended for reviving e-waste. Running the only metal plate through JLCCNC, we get an instant quote of about 1.5$ at 1K volume for no finish. The 4-layer PCB with the same outer dimensions is a bit pricier at around 4$, but I think it would still be cheaper than a smaller PCB combined with an extra metal plate on the bottom and more stand-offs involved. Same rack-mountable face plate adaptation as above, but hugging the top and bottom sides with some tiny flanges instead.

Let’s think through the structure of the printed circuit board (PCB) that will act as the physical core of little cloud. We likely need an array of USB ports through which diverse worker devices will be recruited into a unified cluster. USB is very versatile, as it can support internet tethering, storage media, debug shells, keyboard input, video output, and many others. To decouple hardware requirements from the exact software methods we’ll end up using for handling various classes of worker devices, we can keep our options open and simply mandate that every port should be able to present itself as anything the USB standard supports.

USB is an asymmetric protocol that requires an explicit host and device. Most laptops, and virtually all desktops and servers, are hard-coded to only act as hosts. Old smartphones and tablets are hard-coded to only act as devices, while modern versions can act as both. The chips behind standard USB hubs are typically hard-coded to connect many USB devices to one USB host. This means we can’t really get away with just using one hub chip to back all our ports, because then little cloud wouldn’t be able to easily connect to many laptops, desktops, and servers over USB.

What we could do is have one cheap “dual-role data” microcontroller (MCU) per port, whose role would only be to present itself as anything that’s needed and act as a simple bridge to some beefier integrated circuit (IC) that manages them all. Typical USB connections span “full speed” (12 Mbps), “high speed” (480 Mbps), and “super speed” (5 Gbps). The upstream link from the port MCU to its beefier manager might be SPI (1 to 100 Mbps), on-board Ethernet (100 or 1000 Mbps), or actually one of the same USB variants above. I think we could go for high speed on the port and SPI on the manager link initially.

That said, I did manage to find a very narrow niche of MCUs that manage to pack insanely many USB buses on the same chip. WCH’s CH645 for instance, whose product page isn’t even available in English at the moment, boasts 8 independent buses, 4 of which can effectively be dual-role data, with the other 4 host-only. With a niche MCU like this, we’d get extreme design consolidation and cost reduction, at the cost of a more brittle supply chain. Would it be worth it? Not sure, we might regret going for this if supply suddenly becomes unavailable. But only needing one dirt-cheap MCU per product instead of one per port is appealing for sure.

power

Not only is USB versatile in terms of what kind of data is being transferred, but it is also versatile in terms of what power it can carry. Older USB can do 5V@0.5A (2.5W) all the way to 5V@1.5A (7.5W). On a Type-C connector with a proper power delivery (PD) controller behind it, two devices can negotiate dynamically up to 20V@3A (60W), and even higher if the cable itself is marked electronically.

In addition, modern USB can flip power direction relative to data roles, such that the device can power the host. It can also negotiate an emergency contract where power flips if the wall-plugged device loses its power while a battery-enabled one carries on. As with data, let’s reduce coupling between hardware and software constraints and push for ports that are able to simply do whatever is needed when it comes to power.

However, we can cut a corner here and limit ourselves to 5V only across ports. This is partly to avoid having to add DC-DC converters and further support circuitry on each separate port that would’ve allowed it to independently climb up to 20V. After all, we need to charge phones and tablets as slowly as possible anyway, in order to avoid heat buildup and maintain battery life. We need to be able to dynamically charge them a bit faster than they drain, though, so hard-coding 5V@0.5A wouldn’t cut it. The 5V simplification largely does lock us out of being able to power laptops through vendor-specific adapters, though I think the vast majority of people just use the original power-brick cables. We’re not touching AC in this version, so anything other than a phone or tablet needs to separately plug into its own power outlet.

manager

The manager chip needs to be a bit beefier than the port-facing MCU(s). One option is to go with a tiny Linux-capable microprocessor (MPU) with co-packaged RAM to avoid having to route (and buy) dedicated RAM chips. Allwinner MPUs seem decent at around 4$ at 1K volume via Chinese distributor LCSC, depending on the exact model. They have 64-256 MB of RAM, >1GHz processing, and all kinds of handy peripherals. Our bill of materials (BOM) could swallow ~4$ given it’d be a single MPU per board. Compare that to per-port MCUs that plummet under ~1$ really fast at higher volumes.

We could also just go with a beefier MCU for the manager. There are ecosystems like Zephyr OS, backed by the Linux Foundation, which provide mature networking stacks and other handy utilities designed to fit in the KBs of RAM of an MCU. Going for an MCU brain would also consolidate the software toolchain, and might constantly force the removal of non-essential features to keep things lean. I’m not sure if it’d be beefy enough to orchestrate and network the worker devices, though. Plus I think targeting an MCU with an Yggdrasil build would be extremely difficult, even though WireGuard has been ported to MCUs successfully as another VPN technology.

auxiliary

Besides the port MCUs and the manager MPU, the top signal layer will likely need to be populated with a few other things as well. A few gigabytes of persistent storage in some flash chip would be handy for storing prebuilt images or binaries for pushing on worker devices during recruitment. We’d also have the miniPCIe slot gated by a pin multiplexer for accommodating future long-range radio, as foreshadowed in earlier updates. We could also throw in an RJ45 port, integrated into a MagJack to avoid worrying about magnetics ourselves, as an internet uplink for when we lack worker devices equiped with radios of their own, such as some desktops and most servers.

We also need some components to handle the incoming power responsible for little cloud’s own chips, as well as for any phone and tablet workers it powers. We settled on having laptops, desktops, and servers get their own power separately, though maybe we could at least integrate some hidden tray for storing the laptop power-bricks. Little cloud should be able to negotiate as much power as it needs via PD from its upstream USB-C power supply, such that it can charge phones and tablets a hair faster than they drain. It can locally negotiate above 5V, but we should clean that up and convert it to 5V as soon as possible.

stackup

It might drastically simplify routing to then dedicate an entire internal PCB layer to our unified 5V, turning it into our power plane. Then, from anywhere on the top signal layer, we can use several vias and a copper pour to tap into 5V directly. Similarly, a ground plane would also be pretty handy for routing, and also useful for shielding during certification tests. We mainly get the bottom signal layer for crossing below other intersecting traces, maybe also with some extra writing on that bottom silkscreen. We’d try to use co-packaged RAM and avoid ultra-dense footprints in order to get away with just two signal layers and simpler signal routing. This gets us better hand-solderability and repairability as a bonus.

That would leave us with four PCB layers in total. Even if a bit more expensive than bare 2-layer boards, I think it’d vastly simplify the design, especially given the non-trivial currents we’d be moving around. These would have otherwise required chunky traces all over the place if it weren’t for a dedicated power plane. Plugging some numbers into JLCPCB’s online price calculator, we find that a 45 x 5 cm 4-layer board with default settings is around 2.5$ at 1K volume, compared to 1.7$ for a 2-layer one. I’ll take the easier power routing, especially given the MCUs and MPU would probably be at least 10$ together.

I’ve recently been thinking about a tension inherent to little cloud and how to resolve it. On one hand, it’s important for it to be convenient to set up and use, such that anyone could turn their unused electronics into platforms they can use and rely on. On the other hand, the spirit of the project is in large part about resilience: hardware you own, not corporate data centers; mesh networks, not internet service providers; solar panels, not the energy grid.

Here’s my current best guess as to how to get both the convenience of an integrated solution and the resilience of grassroots infrastructure. There could be two ways for someone to access the platforms hosted on their own little cloud or those of their friends. On one hand, consider a seamless option that can be configured in under a minute, but against which companies and governments still hold the leverage of a kill switch. On the other hand, consider a resilient option that takes ten minutes to initially set up, but which then runs entirely independent from mainstream internet infrastructure.

Crucially, it would be possible to upgrade your setup to resilient mode later, such as during an internet blackout or under a compute surveillance regime, based on instructions bundled with the device itself. The mere presence of a credible option to switch away from classic infrastructure might be a partial deterrent against overreaching authorities.

seamless

For the seamless path, I’m thinking of something along the following vignette. Your little cloud has picked a random identifier during its initial setup, and you can now use your phone to access it by heading over to the matching subdomain of littlecloud.ngo. Because your phone has been previously bound to your little cloud’s account using passkeys, you can then sign in without using a password or magic link. That’s it.

On this seamless path, however, we rely on: third-party DNS resolvers to recognize the domain, third-party certificate authorities for the HTTPS certificate, a centralized gateway into the little network, as well as the tons of third-party plumbing between these components. But this allows us to simply visit our URL from any device and just sign in, all without having to remember a password.

Unbeknownst to disinterested users, the random identifier of their little cloud simply encodes its Yggdrasil address. Yggdrasil is similar to a VPN like Tailscale, in that it allows nodes across different local networks to talk to each other. However, unlike Tailscale, it has no centralized coordination server. Who gives out names to each node then? They pick their own random names. Who tells nodes what other nodes are on the network? They gossip with each other automatically to discover peers. The subdomain namespace in the vignette above simply acts as a convenient gateway into the Yggdrasil network, analogous to Tailscale Funnel or Cloudflare Tunnels.

resilient

Okay, so you can head over to a URL and sign into your little cloud. But you’re still at the mercy of various corporate and government actors when trying to remotely access your own tiny cluster or that of your friends. That doesn’t feel quite right. Fortunately, it only takes ten minutes to make your connection truly resilient, and you’d be guided step-by-step along the process.

First, install Yggdrasil to be able to bypass the gateway and connect directly to little clouds. Second, register a private certificate authority in your device settings, to be able to recognize certificates burned into the little clouds directly. Third, configure your device to use your little cloud’s own DNS resolver to be able to reach the same domains as before. Assume further that you have a wired, WiFi, or long-distance radio connection to a little cloud, and that it has been equipped with long-distance radio to reach your own one over the mesh network.

With such a setup, you’d be able to sign into your little cloud or those of your friends in the same exact way you were doing before. Only that in this advanced mode, you wouldn’t encounter any of the traditional third-party middlemen of mainstream internet. And it’d be okay to ignore this more involved process until the situation actually calls for it. Until then, just go to your URL and press a button to sign in.

binding

What about the initial sign up before being able to sign into your account? One option would be to allow the owners of a little cloud to configure it such that anyone who can reach it can create an account. I’d personally not be too fond of this setup, but people should be free to decide what they’re willing to do with the devices they own.

Another option would be to take advantage of the inherent access controls inherent to the physical device. If it’s running inside a home, for instance, physical access is already restricted to a trusted circle of family and friends. So what if you had to initially be present near little cloud for getting access to it? Inherit the culture-specific access controls implicit to different types of spaces directly.

Maybe to bind your client device to little cloud, you initially need a wired connection to one of its many ports. For adding new devices, maybe you either connect your already-paired and not-yet-paired devices at the same time. Or scan a code between them. Either way, identity should remain federated to avoid having to “sign in with” a centralized identity provider.

setup

Before you can sign into your account, and before you can create an account, you need to first turn your little cloud on and configure it in the first place. This boils down to connecting it to the network and adding your old electronics as worker devices.

There are a few options I considered for a setup wizard. Maybe you turn a worker device with a screen into a control panel. But that requires you to have already recruited it and to have such a screen-enabled worker device. Maybe you hook it up to a monitor or TV to double as a media system. But then you might also need a keyboard, which gets awkward. I’d like to avoid dedicated WiFi or Bluetooth for the first version, which rules out access points and smart-home-like apps as setup pathways. On-device screens and buttons might be frustratingly tiny on a 1U-tall rack-mountable box.

The more promising option is inspired by reMarkable’s tablet ecosystem. It has this interesting web interface that you can access from any browser once you have a wired connection to the tablet. People could use their existing daily-driver devices to configure little cloud by simply connecting to it via a single USB cable and visiting a URL. There, you could handle these initial device setup issues, such as adding worker devices or using their existing radios to connect to WiFi or mobile data.

These first few log entries will continue to break down the concept of a device that turns your old devices into a personal cloud.

One option I’ve considered for the form factor of “little cloud” is that of a network-attached storage unit, or NAS. These typically house a bunch of HDDs or SSDs in neat little bays. The idea here was that you could slot in your old smartphones, tablets, and laptops into dedicated bays. The upside being that it would wrap the mess of different devices into a visually coherent system of matching containers.

However, there are quite a few downsides. First, each worker device would require its own bay, increasing the manufacturing costs of a product that is explicitly about reviving e-waste. Second, because smartphones, tablets, and laptops would require bays of different sizes, it would add friction to the process of integrating a patchwork of worker devices. Third, I don’t think wrapping each device into its own container is too useful for airflow and cooling.

stations

Another possible form factor would be the general category of charging stations, docks, and stands. Many of these are already trying to accommodate a range of consumer devices with different form factors, if you think about it. They also tend to have many ports, such that they can physically connect to each and every device, though newer ones lean into wireless charging.

In contrast to the bay systems, these charging stations are quite efficient in terms of material. Each device barely gets a flap to rest on. Because of that, they’re also not too prescriptive about exactly what kind of device you’re allowed to connect where.

When it comes to cooling, I’m not too sure. This would be a situation where the components that dissipate heat (i.e., the worker devices) would be somewhat outside of our device’s main enclosure, merely resting on top of it. Contrast this to desktop cases or rack-mounted servers, where the hot components are often in the middle of an air tunnel whose geometry has been carefully tuned. Exposing junk electronics right on top might also create some amount of visual clutter, though maybe at least cables could run down the back side.

racks

In the previous log entry, we emphasized the overlap in responsibility between little cloud and traditional enterprise equipment, such as network switches. Rack-mountable equipment has been optimized to allow for connectivity between densely packed devices. Accordingly, they tend to boast dozens of ports on their front and back panels, always accompanied by clear labels and grouped using visual cues.

It would be nice if little cloud adopted the general form of a charging station, but whose base housing happened to also be compatible with rack-mounted standards. This would allow it to be used at home by placing small consumer e-waste on top of it, but it would also allow it to be used in actual racks filled with enterprise e-waste.

The latter would make this product slot right into a related initiative I’m involved with, where we’re redirecting data center e-waste into high schools and universities for students to run their own local platforms on them. We’d get a unified plug-and-play device for reviving e-waste ranging from smartphone all the way to server caliber. That level of consolidation would be pretty sweet.

process

3D printing the enclosure won’t cut it, both because it doesn’t scale favorably with volume, but also because we might be dealing with quite a bit of power inside this enclosure. Typical filament isn’t really well-suited for this, and this would turn into a real liability during product safety certification. Injection molding is how plastic enclosures scale instead, but the upfront cost for a production run is prohibitive.

Sheet metal is quite interesting here, it’s a bit like folding cardboard but instead with aluminum or steel. Excellent thermal conductivity. Cheap to prototype, but also scales favorably with higher volumes. If our geometry boils down to a basic box with maybe some flaps and legs, then manufacturability wouldn’t be an issue. We don’t really need the ability of 3D printing to create intricate internal structures.

I found some fascinating precedents from Teenage Engineering that exploit the similarity between sheet metal and folding cardboard. Their computer-1 desktop case ships with metal sheets that they’ve cut with a CNC, but that they haven’t yet actually bent. The end-user is able to bend the sheets and screw them together, probably creating some degree of Ikea effect in the process. They did the same with their pocket operator modular series, they ship the flat sheets and call on the end-user for the final assembly. Such a DIY option might simplify manufacturing and delivery.

modularity

For computer-1, the top handles mount to a grill pattern drilled into the metal sheet. I think it was just a neat way for them to mount the handles without digging further holes outside the regular grid. However, think about what such geometry could enable in our case. You could move the flaps for worker devices around freely, depending on their unique shapes and sizes. You could also take them off entirely if doing a rack-mounted setup with servers only.

If mirrored on the bottom side, the hole matrix could also allow the legs to be adjusted. This could make little cloud sit well on either a flat surface or an old desktop that has been recruited into the cluster, as well. Internally, you could also mount stand-offs against the same grill to hold circuit boards, fans, and other components. Not to speak of the original purpose of the computer-1 grill, which was probably airflow.

Pulling these threads back together, we get to what looks like a somewhat large charging station built out of sheet metal, whose base enclosure happens to be rack-mountable. Its top and bottom sides are perforated to allow for flexible mounting options, while its front and back sides have clear labels that organize its many ports. Finally, it might be available in the form of a cheaper DIY kit that you assemble yourself.

This newsletter is about the journey of bringing to life a physical product from scratch, from concept all the way to manufacturing.

The product we’ll be building along the way is a device that allows you to take your existing, old electronics and instantly turn them into your own little cloud.

Think about all the smartphones, tablets, laptops, and maybe even desktops that are sitting in your junk drawer and simply collecting dust. What if you could connect these devices you already own into a cluster of tiny computers that can host all kinds of platforms for you? What if you didn’t have to be a sysadmin professional to do it, and instead you had a plug-and-play experience? Maybe you could get these to handle cloud storage, music streaming, or even language models, all without relying on subscriptions to Big Tech. That’s the pitch, that’s what we’re building.

background

If you’ve got a bunch of old devices stuffed in a drawer somewhere, you’re not alone. Surveys estimate that around four out of five US residents hoard unused smartphones. For tablets, the figure is around two out of three. Similar for laptops. That’s a lot of devices.

Even when electronics are recycled at authorized e-waste processors, less than 2% actually get reused in the EU. Most of them are reduced to raw metals, even if the majority of devices are still functional.

You can also ask language models to deep research the total processing power of hoarded devices and e-waste, and compare that to Big Tech data centers. It turns out that the sum total of consumer junk and e-waste lands comfortably above the largest data center, and around the total amount of compute across flagship AI data centers. But it is much more scattered and diverse, and so difficult to coordinate.

Now, you might be skeptical that your smartphone can compare to a GPU. Let’s use a concrete example, take my Pixel 8 from a few years back and an Nvidia GTX 1070 I pulled from a desktop. Both of them can have around 8 GB of GPU-available memory. The Pixel’s GPU has around 30x more half-precision throughput, while at the same time drawing 30x less power. However, the Nvidia card has 5x higher bandwidth between its memory and the actual cores, and much better cooling. It’s fair to say they’re at least trading blows, and both can run tiny language models alright.

features

Let’s get back to the product we’ll be building. To recap, “little cloud” will be a device that can physically connect to a bunch of other devices with wildly different form factors and computational resources.

On a hardware level, this new device will be responsible for handling the power, network, control, and cooling of the tiny computers attached to it. It effectively needs to bundle together the roles of several traditional pieces of enterprise equipment: a power distribution unit, a network switch, a KVM switch, and a coolant distribution unit.

On a software level, it will be responsible for automatically “recruiting” the diverse worker devices into a unified cluster, across which it can then orchestrate workloads to ensure users gain access to the platforms they want. It effectively needs to handle the job of traditional on-premises tooling used to define and run bare metal fleets, such as Talos and Kubernetes.

We’ll partially rule out some features to preserve focus for an initial version. First, we’ll leave an expansion slot for an eventual long-distance radio module, such that people will be able to connect their tiny personal clusters into a “little network” without relying on their internet service providers. Second, we’ll avoid adding connectors specific to solar power, but we’ll make sure portable panels with USB-C outputs can still be used to help people partially power their little clouds without relying on the grid.

development

We want to build towards a collection of files that can then be sent directly to manufacturing houses. These standardized files taken together specify the entire product, from the enclosure through the printed circuit board to the firmware, and allow the product to be manufactured reproducibly across fabs. This is known as “digital fabrication,” and allows us to avoid having to rely on any one particular manufacturing business.

We’ll use Onshape for modeling the enclosure and KiCAD for the printed circuit board, mostly because they’re the only CAD tools I know for these respective jobs. Here’s a picture of an open frame rig for which I used Onshape to model the mounts for the computer parts, it was pretty okay to work with. We’ll use Rust for low-level software, as it seems to have a decent path to native hardware on mobile devices, and because it’s the only language I used to get language models to run on consumer devices. It was GPT-2 back then, simpler times.

The design files would be open. The litmus test for openness here is whether someone has all the files they need get their own device built directly with a turnkey manufacturer. However, economies of scale help drive down costs significantly at higher volumes, and so people should be able to participate in those savings. We’ll probably aim for a first real production run through a platform like Crowdsupply, which helps open hardware projects with crowdfunding and fulfillment logistics.

format

I’m pretty excited about building this in public, both for the accountability pressure and as a way to meet people who might be interested in this little device. I’ll try sharing weekly build logs in here, first time publishing on Substack. We might occasionally visit places like makerspaces, e-waste processors, manufacturing houses, or repair workshops to mix things up.

If you’d like to follow along the full journey of bringing a product to life, including different kinds of engineering that go into it, consider subscribing! If you’re curious about this actual product and want to steer its development, use the comments to share feedback and suggestions. Either way, looking forward to seeing you around!