Complete Computing Environment

Table of Contents

A World of My Own

And where does the newborn go from here? The 'net is vast and infinite.

This is sort of an exploratory document of what an ideal computing scenario looks like for me, as well as medium-term aspirations, as well as a list of todo items to make the current iteration more useful now and to further myself towards the goal of an optimal malleable computing system.

The Hardware

In my perfect world, I own two computing devices – a powerful server that is hosted in my apartment, and a compute core that can integrate with a number of dumb-hardware peripherals depending on how I want to use it.

The Server

A single server is easy to manage, the perfect setup would be that the server is running a Qubes-like Kubernetes, which I guess is probably just CoreOS. The server will have a large set of disks attached to them with full-disk encryption attached to them, which contains gpg-encrypted backups (so that they can't be pulled from a running system), media files, and the state for all the containers running within CoreOS.

The server itself is nothing special, it doesn't even need to be a "server," per se, it could just be a beefy desktop machine or even a home-theatre system, as long as it can schedule containers. Overall though, the moral here is that the hardware should be under my control, no cloud servers, no rented hardware, just my own hardware under my own lock and key.

  • State of the World as of [2016-12-24 Sat]

    I'm pretty happy with my setup right now; I am using an HP Microserver, but have specced out some desktop-class components and might build a new machine with 8 or 10 terabytes of storage, before RAIDing them. I also need to define and adhere to an off-site backup story so that a natural disaster doesn't leave me without my data and backups.

  • State of the World as of [2018-06-16 Sat]

    I built a desktop in 2017 and used it to run my services, but now I have a much-less-static IP address, and have bought a Dell R410 and racked it with a friend in a local co-location hotel. This machine is going to become the central host for all of my personal cloud services, with a bunch of Docker containers scheduled via my systemd setup.

    I expect this machine to last me quite a while, eventually I might rack a second host in the co-location facility eventually, to allow for some more disk space, and long-term storage.

The Core

This is part that has changed a lot over time for me. Longterm, I really love the idea that a small ARM single-board computer with enough IO ports could drive whatever hardware I need at the time; unfortunately, that's not the case right now with my requirements, and so I'm currently evaluating other options, and waiting until the technology industry moves more towards a system I can integrate.

The main issues where the Core falls short right now, are the security footprint of the device, and the IO throughput of the device.

I want a device that I can trust; that boils down to a fully attestable secure-boot, fast crypto, and full-disk encryption. There are few ARM cores that can do any of these, let alone all three, and so the devices fall short on the security front, and these are areas that I could see great improvement in the near future.

The other one of my main requirements is IO throughput, in terms of network IO, external device IO (be it GPIO, i2c, USB), and IO extensibility. The fascinating thing about most ARM single-board computers is that each line has their own standardized "expansion port" layout; I hope that as time goes on, and these devices become more powerful, there is a standard which emerges and all SBCs unite under, but that seems like a while off. Other than that, the ability to hook up more than one USB-3 device to the machine, or, hell, a single USB-C would be a game changer. Gigabit network, display, storage, power all on the same bus, along with the ability to add GPIO and other IO channels would allow me to build a small system in a housing that fits my needs and fits my pocket.

The lack of machines which fulfill these requirements leads me down to looking in to x86 boxes like the Intel NUC. Of course, this is too big to fit in to your pocket, doesn't have a power solution that works, and doesn't have a standardized IO header that would allow me to design peripherals, but such is life, and it's caused me to sort of find neat middle grounds which I am currently exploring as a way to meld my weird thoughts on workflow and data locality in to my penchant for designing goofy physical interfaces.

  • State of the World as of [2016-12-24 Sat]

    So, let's boil those requirements listed above in to a table and start seeing how things look. I need to figure this out of course.

    Machine Form-factor Arch CPU Secure Boot AES CPU Ins Native FDE USB-3 USB-C IO Headers Wifi BT Wattage
    RPi3 SBC ARM                    
    CHIP SBC ARM                    
    BeagleBone SBC ARM Cortex A8   No   No No 2x46      
    ODROID XU4 SBC ARM Exynos5422 No No   Yes No   No No  
    Intel Edison SBC x86 Atom 500mhz No Yes Yes No No Arduino Yes Yes  
    Intel NUC Mini PC x86   Yes Yes Yes Yes Yes No Yes Yes 16.5W

    This isn't filled out, but it ain't pretty. Essentially, where I am at right now is to sort of leapfrog the pocketable compute core, until the pocketable machines catch up with what I want. For a long time, I've designed goofy looking keyboard computers, things which you could slot aforementioned SBC in to, boot it up, and have a keyboard and display that can drive the OS on the SBC.

    For now, the route that I am going down is to take an existing piece of hardware and modify it to my needs. To that end, I purchased an Amstrad CPC 464 off of eBay, and in the process of trying to fit an Intel NUC in to the machine, wiring up the keyboard to a Teensy and driving the NUC with the Amstrad's keyboard. It'll also have a small 5" display embedded where the tape deck is on the machine, and the ports of the NUC will be exposed out the back of the device to allow you to hook a modern monitor up to the machine. The thing will have a 20000mAh battery inside of it that'll give it something like 5 or 10 hours of battery life.

    I'll probably carry that, along with some sort of small interface kit I've wanted to build for a while, most likely something in the form-factor of a Nintendo DS which can interface with chats via XBee – the Amstrad will have an XBee in it, along with some software to forward messages between the two devices for one room at a time; the interface kit will have a buzzer or speaker on it, a small keyboard and a simple black and white display, all driven from an Arduino equivalent. It doesn't need much power or storage since it's basically acting as a serial device for the Amstrad.

  • State of the world as of [2018-06-16 Sat]

    This one is still heavily in-flux, I never crammed a NUC in that Amstrad. Right now, the story around Single Board Computers is largely the same – I can buy a couple of ARM SBCs that have SATA, but the story around user-controlled secure boots, et cetera, is decidedly not great. The Intel Edison is dead, CHIP is dead, and there's a bunch of ARM64 players, as well as a few RISC-V SBCs.

    Right now, the best I can get is the Intel Atom powered GPD Pocket, a 7" aluminum chassis laptop with 8GB of RAM and a fair bit of SSD. It's a pretty neat little thing, but largely doesn't feel "quite right", and I want to spend more time on this.

    I've backed a crowdfunding campaign for Purism's Librem phone, a GNU/Linux machine that'll hopefully serve as a good base for the compute-core vision I've laid out. I want to attach a small USB hub to an ortholinear 40% or 50%, with a battery pack and small e-ink display. Overall, I think if the Librem actually plays to fruition, I'm in a spot where I can make it work, now that I've spent some time with an f-droid'd Nexus 5, without needing a large amount of applications that wouldn't be accessible on Linux.

The Network

Right now, I poke some holes in my home router through to my server, which I think is a little bit of a bad move; in the longer-term, I want to move towards having the server only available as a Tor hidden service, which only my own devices know how to reach. The only machine I may rent outside of my network would be a machine that is also a Hidden Service client that forwards web traffic for my websites out of the secure domain and on to the net; hell, in a perfect world, those sites are all plaintext hosted on some CDN, but I have a Git server and some other "dynamic" things that the Real World would care about.

This of course means that my personal devices would have to have a Tor connection running, but this is okay, perhaps preferable. I want to live in a world where it's possible to have private spaces and private thoughts and to that end, I want Tor and encryption to be a social norm. Or at least a norm for me and my friends.

The Software

Okay, here's the meat of my future, right? The reason I'm building a fucking operating system from scratch in Lisp. Well, here's the crux of my requirements:

Transparent Access to Information

A core ideology is that my data should belong to me; this is both in terms of where it lives, but also how it's accessed and how accessible it is. However, a mountain of data is only as useful as your ability to pull information out of it, and so systems like that are going to be of key importance as I capture more and more data about my life and habits and world around me.

I've intention to build out some ElasticSearch indices of my files and information, that'll probably have its own stack of ingestors; I have been using Org-Mode as a search database for quite a while but the scalability of this system is suspect, and the APIs to access the data are pretty ugly. And so, I'm probably going to do some data modeling to define what the shape of the documents for various "things" are, create an internal standard and then write ingestors that pull those data out of the ether. And then, doing the opposite of what I have now, generating ElasticSearch documents for my Org-mode headings will allow me to quickly make queries about my daily agenda, and how various elements of information fall in to that agenda. "Show me the list of emails I got during that team meeting yesterday" or "What project was I working on when I was watching Mad Max 2" are the types of questions I should be able to ask that system and get a real answer for.

After that, the access to the information becomes the primary concern, and this probably looks like a bespoke client to the "information store" as both a Matrix client and as a command line application which I can write an Emacs wrapper around. You could toss some NLP in front of a Matrix frontend and have a Memex1 that I can write normal English queries to. Write a Matrix client that has a speech recognition system in front of it and you have a wee little Jarvis.

Integrated Environment

I'm a big fan of the Emacs-bag-of-tricks philosophy; being able to write a few lines of code which affects your entire computing environment is incredibly powerful, and it's something that I've taken a lot of advantage of with CCE.

As I move towards more compartmentalization and data ACLs, this sort of power structure is hard to maintain – there is not a version of Qubes that just boots to Emacs. There shouldn't be. And so in the long term, I need to evaluate whether Qubes is the proper solution for me, and adjust as appropriate. This might mean building up my own system which can run sub-systems in dedicated VMs, or running applications as disconnected rkt containers, or more and more starting to treat my local instance as a thin client and keeping all state and surface area on the server, with a caching system to make sure I can do core tasks while offline or off-LAN.

This might also mean breaking a lot of synergies I have with different sub-systems, like my integrated self-learning mail platform built on top of Gnus. It learns from my behavior and is probably the only reason I can productively keep up with my mail, but it's a single bag without any compartmentalization. And so, maybe I just need to take data like this and properly compartmentalize it, with some sort of data channel between the compartments, but for now this is a tough problem to solve without building a lot of infrastructure myself.

Maybe the compartmentalization is solved with dm-crypt volumes per domain, and some scaffolding to serialize and deserialize Emacs state for the domain in to it, along with the files for that particular client or project or identity. A single Emacs configuration and computing environment working against different data depending on which dm-crypt is mounted.

Malleable Interface

Just because I believe in a single computing device, that doesn't mean that I believe in a single formfactor. Indeed, I think that in a perfect world the computing device would be a simple credit-card sized box with no interface, and you attach it (wirelessly or wired) to whatever you're needing at the time, be that a keyboard and display, five inch touch screen, VR headset, GPGPU cluster. This future is far off and dreamy and probably not going to actually happen, but a man can dream.

In the mean time, it's a dream worth moving towards. I've blogged at length about this philosophy and the lengths I've gone to emulate it, but in the mean time, one thing that has followed its way in to CCE is the idea of different frontends. For a while, this environment could be controlled in limited fashion using a keyboard and Emacspeak2, and could also be a normal desktop operating system, and to a certain extent also works as a daemon interface to some data that is "locked" in Emacs.

I want to move more towards a world where this is feasible, in a way that doesn't limit me to using systems like Emacspeak which introduced some very difficult to debug issues. The big problem that I've had with the system so far is most ideas revolving around the passive use of the system – how do I get notified in a way that is unobtrusive yet high-bandwidth. For the previous incarnation of this system, it was a tightly integrated voice interface paired with some earbuds. I think the next time I take a crack at this particular part, after I build out the Amstrad hardware entirely and prove its feasibility and portability are worth the investment, and build a very simple interface on top of eloud or a similar toolkit, or cut those systems entirely and feed more and more data in to the Eye of Sauron and give that expressive notifications, be it through audio or through the Interface Kit that I outlined as a temporary solution in the Hardware section above.

Free Software

This is a no-brainer. If I'm going to be throwing my life behind a system, it needs to be a system which respects my freedom as a user, since my personal liberty will be directly tied to my ability to pull information out of the system.

No Cloud

Another no-brainer. I shouldn't be writing clients to services that aren't hosted by me.

Future Work


NEXT exwm-init in tres-ebow

[2019-02-11 Mon 23:29] file:~/org/watch.txt

NEXT add calibre to cce

NEXT install scrot   CCE

Reinstall syndicate

Set up a bunch of org capture templates


Task and Time Tracking, Information Management

  • NEXT create beginning of work taskflow

  • NEXT create end of work taskflow

  • NEXT LDAP to bbdb thing?

  • NEXT Trying to figure out why memacs-timelog is missing data

  • NEXT Set up memacs to process my Sleep as Android tracking data
  • NEXT blog idea: org-mode as zeitgeist

  • NEXT org capture template to add data to a org-table

    • Meal food logging
    • Weight logs
  • NEXT Memacs in CCE

  • NEXT Review OpenNutritionDatabase

  • NEXT Set up a FTP container for scanner
  • NEXT Make (mfblog:gen) track un-syndicated URLs and post them on twitter/facebook, updating the SYN-TWITTER and SYN-FACEBOOK properties.
  • INPROGRESS Memacs consume from Android Tasker data

  • CANCELLED Set up some memacs stuff to pull from foursquare
  • CANCELLED Try to figure out some sort of desktop integration with a Plasma widget

    In my head, this is, like, a plasma applet that sits in the panel, and just shows what task you're clocked in to. If you're not clocked in to a task, it'll have some sort of alerted state, so that you can remember to clock in, it'll also have the ability to assign actions to it, like, a dropdown of various elisp snippets you can run on a running server.


    • clock in to default task
    • capture clipboard
    • open a frame
    • gather and show appointment notifications and org agenda
  • DONE Add a ledger capture to FSEM

  • DONE re-write rrix/inventory-stats

  • DONE Parameterize the Inventory capture

  • DONE Set up some memacs stuff for work
  • DONE Set up memacs to process my Android tracking data
  • DONE Centralize memacs configuration on to cloud01
  • DONE Design a good workflow for using emacs in terminal environment
  • DONE Investigate IPython integration with Emacs
    • Org org-babel with nice rendering stuffs


Downtime Niceties

  • DONE Port mingus hydra to use mpd/ogg123

  • NEXT Control MPD from Matrix


  • DONE Create a low-level Emacs library for Matrix

  • CANCELLED wire mcat up to a comint buffer

  • NEXT make mcat more featureful

    • NEXT batch lines with a timeout

    • NEXT be able to simultaneously do input and input

  • NEXT ansible playbook to deploy the IRC AS

  • DONE Look at what a full matrix chat client would entail, decide if it is worth it

    • multiple rooms
    • typing notifications
    • sauron support
    • file uploads
    • speed var or chat list even?
  • DONE port matrix.el to use request.el instead of url.el for timeouts and deferreds.

  • CANCELLED render images inline

  • CANCELLED fix typing support
  • CANCELLED Scrollback

  • DONE command support "input filters"

  • CANCELLED Handle Invites

    ((userid . "") (type . "") (statekey . "") (roomid . "!") (originserverts . 1446658776811.0) (eventid . "$") (content (membership . "invite")) (age . 10))

  • CANCELLED Load credentials from something other than authinfo, or document its use better
  • CANCELLED figure out how to prevent the deletion of the status line readwrite point
  • CANCELLED Zalgo isnt sanely handled

    May be an Emacs issue that I need to upstream and resolve.

  • CANCELLED matrix-client chokes on same-name rooms

  • CANCELLED Expose Matrix room state events in a buffer-local variable

    This can be used to implement per-room notification settings, for examle.

  • CANCELLED quash all URL messages from Matrix

  • DONE Make matrix-client foreground buffers on connection

  • CANCELLED Change the status line to use
    • CANCELLED Store point to useful things like the in the status line

  • CANCELLED Optionally disable emojicons
  • CANCELLED add a fixer to matrix-client to strip the last slash from matrix-homeserver-base-url   NOTE NOEXPORT
  • CANCELLED Don't send mistyped slash-commands in matrix-client   NOTE NOEXPORT
  • CANCELLED Integrate set-emoji-font in to matrix-client when adding a toggle for Emoji support   NOTE NOEXPORT
  • CANCELLED Investigate input filters for sending markdown and org-mode formatted messages   NOTE NOEXPORT
  • CANCELLED fix matrix-client

General Emacs Improvements



Author: Ryan Rix

Created: 2019-05-07 Tue 11:12

Validate XHTML 1.0