Aesthetic Dot Computer
Readings of essays from Aesthetic.Computer, in @jeffrey's voice. Each episode is a single essay read start to finish sourced from A mobile-first runtime and social network for creative computing, read aloud. papers.aesthetic.computer
Aesthetic Dot Computer
The Machine That Came Back
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
A reading of the essay, The Machine That Came Back by Jeffrey, approximately 11 minutes, will wrote to say that my old NZXT machine was free for me to use again. Around here it has two names, JAS NZXT in the network and JASTAW in conversation. A returned computer always presents the same temptation. Wipe it, update it, and invent a new purpose. But this one was not empty. It had already spent the past few weeks becoming something quite specific for aesthetic computer. So before deciding what it should be next, I wanted to ask a better question. What has this machine already learned how to do? The answer was hiding in a large expensive body of state. Jasto had become the fleet's x86 Linux and NVIDIA laboratory. It held a Chromium OS and Fleet OS checkout, software development kitten package caches, a chain of Cellus and Octopus image experiments, OTA payloads, and a persistent Fedora builder guest. It had produced versions B0 through B8 of a hardware image and kept a 7.7 gigabyte accepted image among the results. It had also received CUDA, exercised its RTX 3070, and briefly mined Bitcash under a 150-watt power cap. This was not debris. It was a record of work that would be slow and bandwidth heavy to reconstruct. That distinction shaped the cleanup. The Chromium source tree appeared to occupy roughly 265 gigabytes, but the underlying B-tree file system was using far less physical space and still had more than 750 gigabytes free. Deleting the tree would have made a pleasing before and after number, while destroying the most useful cache on the machine. Instead, the accepted RAW image was compressed losslessly from 7.7 gigabytes to about 919 megabytes, tested, hashed, and copied to durable storage. Two untracked native Fedora setup files were preserved with it. Only after that did the old guest receive a clean shutdown, the stale terminal workspaces close, and reproducible leftovers become eligible for removal. The actual cleanup recovered about 8 gigabytes without touching the expensive build state. Six completed old composer jobs went away. Four unused Docker volumes went away, including an old Visual Studio code cache. The oldest Fedora kernel and safe development caches went away. An obsolete display access service was disabled. Then Jastow upgraded 151 Fedora packages and rebooted into kernel 7.1.4 with the matching NVIDIA driver. Afterward, there were no failed services, no pending Fedora or flat pack updates, no B3 device errors, no swap use, and about 761 gigabytes free. CUDA 13.2 was working. The important result was not merely a cleaner disc. It was a known good machine whose valuable state had survived the cleaning. The Matador miner was updated from version 0.8.32 to the current stable 0.8.58 using the official release checksum. The previous binary was retained as a rollback. Its guard now checks once a minute and gives interactive work and builds a 10-minute quiet window before mining can resume. At the time of the handoff, the pool was connected, shares were accepted with none rejected or stale, and the machine was producing about 4.1 kilo hashes per second. The GPU sat near 149 watts and 60 degrees Celsius. Network traffic was only a few kilobytes per second. Mining is therefore a reasonable idle filler, but it is not the machine's job. Any aesthetic computer build, render, or inference task should stop it first. The network reinforces that hierarchy. Jastow is on Wi-Fi 5 with a conservative download sample around 169 Mbps and direct private network latency to NEO around 9 milliseconds. That is plenty for command and control, package updates, source sync, and returning finished artifacts. It is less attractive for a public service or a workflow that repeatedly throws away and re-downloads hundreds of gigabytes. The right pattern is to keep costly caches local, send compact inputs, do the heavy work on Jasto, and return compressed accepted results to Neo or Silo. Daily interface accounting and per job byte counts should be added before we treat the box as a recurring high-volume worker. Ethernet would improve predictability, but it is not required to begin. Jasolite needed a different kind of attention. It is an Ubuntu server with 15 gigabytes of memory and roughly 169 gigabytes free. 59 packages were upgraded, two new packages installed, obsolete dependencies removed, tailscale brought to version 1.98.9, and the machine rebooted cleanly into its current kernel. Caddy, SSH, Cron, Tailscale, and the mail service all return normally. There were no failed units, pending packages, or pending reboot. Its old bitcache source, 103-gigabyte chain, wallet backup, and one-time synchronization records remain intact, but no node or wallet process is running. That is a good dormant state while we decide whether the node is worth reviving. The installed core is older than the current release, so restarting it should be a deliberate upgrade project, not an accidental side effect of cleanup. Across the rest of the fleet, the roles are already fairly clear. Neo is the interactive command seat and should keep the work that needs a person close to the screen. Panda and Chicken are small Apple silicon client laboratories for Fuser and Iris. Blueberry and Porslice are useful Mac workers when awake. The Windows Tower is another Nvidia peer, but it was offline and belongs to interactive Windows work. Lith, Session Server, and Silo already own public serving, real-time authority, and durable artifacts. Jastau should not quietly become a dependency of any of those systems. Its advantage is narrower and more useful. It is the online x86 Linux and CUDA workhorse that complements the mostly ARM Mac fleet. The first local model to put there should be Whisper Large V3 Turbo, preferably a quantized Whisper C build. Its model is about half a gigabyte, and it fits easily within the 8 gigabytes of video memory. It would immediately help aesthetic computer by transcribing recaps, tool chain videos, grant footage, interviews, and multilingual audio. It also creates searchable text for the fleet without sending private recordings to a third party. This is the cleanest test of the worker design because it is useful, bounded, easy to benchmark, and friendly to the existing network. The next installation should be a small utility vision bundle rather than a fashionable giant image model. Segment, anything 2.1, depth, anything V2 small, and real ESRGAN together cover masks and cutouts for no paint, object tracking for cap-shooter footage, depth maps for parallax, and restoration or enlargement of paintings and print assets. Their combined weights are modest, and each job can fit comfortably when run alone. Practical Rife and FFM Pegs NVIDIA encoder belong in the same practical layer for interpolation, dropped frame repair, and fast delivery encodes. These are not glamorous demos. They remove repeated production friction across several parts of AC. After those are proven, stable audio 3 small could generate sound effects, percussion, ambience, and short music beds with only a few gigabytes of video memory subject to a careful license review. SDXL Lightning can follow for rapid backdrops, thumbnails, image-to-image work, and in painting. But it will live close to the 8-gigabyte ceiling and should use low memory loading and offload. A small Quen vision language model may later help caption paintings, inspect screenshots, and propose alt text or tags. Large local video generators, flux stable diffusion 3.5, and other heavyweight image systems should wait. Several either exceed the card, leave no safety margin, or impose licensing and operational costs that are hard to justify for a temporary worker. The operating rule is simple: one substantial job at a time. JASTAW has 16 gigabytes of system memory and 8 gigabytes of video memory. The earlier Fedora guest consumed 8 gigabytes by itself, and an experimental CUDA workload already proved that an unrestricted GPU job can fault. So the miner stops, the build or media job takes a lock, memory is checked, the task runs, accepted outputs leave the box, video memory is cleared, and only then may mining resume. A safe first policy is to keep system memory below 13 gigabytes, video memory below 7.5, and swap at zero. The build lane and GPU lane should never overlap. What comes next is therefore less about installing everything than about giving the machine a shape. First, reconcile the fleet registry so JASTO and SNZXT are one canonical identity and the stale panda and chicken records cannot misdirect automation. Second, add bandwidth and job accounting. Third, make a private network-only single job worker with two cues, build and media, both able to preempt the minor. Validate it with one native operating system build and one whisper transcription. Then add the utility vision bundle, followed by audio and image generation only when real AC work asks for them. The machine came back, but the more interesting fact is that its purpose was already visible. It is not another server, not a backup desktop, and not primarily a miner. It is a laboratory with a memory, an x86 builder, a bounded CUDA worker, and a place where expensive local state can stay warm. Mining can keep the fan turning between assignments. The measure of success, though, will be the useful artifacts it returns to the rest of the fleet. Here ends the reading. Questions and feedback are welcome at mail at aesthetic.computer. Unless you ask us not to, your letter may be read or mentioned on a future episode.