Author's Note: Hey, Y'All, Watch This!

For those wondering about some of the technical background:

The chief obstacles to using “normal” computers in space are heat generation (given the average spacecraft’s limited heat budget – disposing of heat in vacuum is hard), cooling (because in microgravity, convection doesn’t work – there go heat-sinks without a lot of active coolant-movement devices), ability to work in low air pressure and/or vacuum if something goes wrong, and the prevalence of ionizing  and other EM radiation, which tends to muck up delicate electronics.  For a large part of history, this was handled by many of the same compromises we made – reduced transistor density, specially hardened chips and designs, magnetic core memory, and so forth.

(Fun fact: this problem was particularly bad back in the Apollo-era equivalents of Projects Phoenix, Oculus, and Silverfall, because they were using Orion-style nuclear pulse drives.  Which is to say, during atmospheric ascent, a crapload of EMP happening right near the flight computers.  Back then, they were using “electron plumbing” machines, because despite their space program being relatively later in their technological timeline and thus having better ICs available, they still were by no means EMP-immune.  “Electron plumbing” is a technological path we didn’t take – essentially, evolved thermionic valves/vacuum tubes to higher orders of complexity.  Never widely used, because ICs were still a better technology overall, but for this specific use, excellent.)

But in the modern era of spaceflight, they can use standard commercial computers, because those use optronic nanocircs.  Those run cool (no need to wiggle significant electrons about; photons are much easier to handle) inherently, and care much, much less about passing ionizing and other EM radiation.  Also, all but the most cut-down “standard” ML runtimes or hardprocs (a processor that implements the ML runtime directly in hardware) incorporate all the real-time and safety-critical features that you’d need for spaceflight applications, because those features are also used in general automation and robotics and other applications that are pretty close to ubiquitous downside as well.  And so does the standard IIP networking protocol, and so forth, and for much the same reasons.

As for WeaveControl, it’s more formal name is Interweave Command/Control Protocol; for reasons of technological evolution, plus much more prevalent hackerish tendencies in the population, just about every device manufactured – cars, lightbulbs, drink-makers, ovens, coins – comes with an IIP interface and a WeaveControl endpoint, which lets you run all the functions of the device from an external command source.  (It’s become such a ubiquitous open standard that there’s no reason not to spend the couple of micros it takes to install it.)  You really can script just about anything to do anything, or hook it up to interfaces of your choosing on any device you have that can run them.  Things as simple as programming your alarm clock to tell the appropriate devices to make your morning cuppa, lay out suitable clothes according to the weather and the style of the day, cook your breakfast, fetch and program your paper with the morning’s news, order a car to come take you to work, and program its music system with a playlist suitable for your mood are downright commonplace.

But they’re serious about anything/anything compatibility.  You can program your bath from your car, drive your car from your PDA, operate an industrial 3D printer from seat 36B on the sub-ballistic – hell, run your building elevator from your pocket-watch if you can think of any reason why that might be something you’d want to do.

Some of these applications are, ah, less advisable than others!