86 lines
58 KiB
JSON
86 lines
58 KiB
JSON
[
|
|
{
|
|
"conversations_memory": "**Work context**\n\nCaptain Bob (Robert Allan James) is the sole architect and developer of StarshipOS, a novel computing ecosystem built around StarForth (a FORTH-79 compliant adaptive VM in C99), LithosAnanke (a bare-metal microkernel), and the K\u22611.0 conservation law he calls James Law. He has a USPTO provisional patent (December 2026 conversion deadline) with pro bono counsel engaged, and an SSRN empirical paper validated across 38,400 experimental runs. He also runs Progressive Papers, a political commentary publication.\n\n**Personal context**\n\nBob is a 67-year-old polymath based in Ashland, Ohio, with roots in the Cleveland/Lorain area, currently in transitional housing at Safe Haven shelter while awaiting permanent housing through Appleseed/HUD (target September\u2013October). His background spans pipe organ voicing, large-format photography, mountaineering (Denali attempt), road racing (1998 Dodge Viper RT/10), BBS sysop work, Arabic fluency, and mead-making. He identifies philosophically as a Buddhist atheist Zen pragmatist. He has a dog named Santino (Dachshund/Ridgeback/Staffordshire mix), who is the StarshipOS mascot. He communicates primarily via voice dictation, which produces frequent transcription errors on proper nouns. He manages neuropathy affecting his hands (post-laminoplasty) and uses a one-finger-and-thumb typing approach. Bob dislikes stock photos.\n\n**Top of mind**\n\nBob is actively working through the FABRIC.md refactor of StarshipOS \u2014 a major architectural document treating blocks, messages, dirty cells, ACLs, and VMs as expressions of a unified physics engine. Phase 3 (Stadium core, items 3.1\u20133.8) is complete, and Phase 4 item 4.1 (hot words onto the Stadium via \u00a717.7 reservoir heat-conservation mechanism) is done. Next items are 4.1a (Hermes's initial quota grant) and 4.2 (Hermes native on the Stadium), with 4.2 held pending discussion with Bob before starting. A second LithosAnanke patent filing (stronger than the original SSM provisional) is targeting a December 16 deadline, with pro bono counsel involved. Bob has set up a structured weekday schedule in Google Calendar to maintain pacing. His new Beelink SER5 development machine (Ryzen 5 5500U, 32GB DDR4) is running his full stack \u2014 CLion, QEMU targets, Gitea, and a Docker Compose service stack \u2014 with the swap file corrected to 8GB after a period of instability.\n\n**Brief history**\n\n*Recent months*\n\nBob set up his Beelink SER5 as a primary development machine running Kubuntu, with local Gitea hosting StarForth and LithosAnanke as separate repositories, and a Docker Compose stack (Nexus, XWiki, Taiga, Mattermost/Postgres) for project infrastructure. He completed cross-architecture boot validation of LithosAnanke (amd64, aarch64, riscv64 all booting to `ok>` prompt), with Phase 0 substrate parity confirmed via reproducible dict hashes. FABRIC.md emerged as the core architectural document \u2014 the recognition that the dictionary is the reference implementation of a single unified physics engine governing all system objects. A \"claim pressure-test\" skill was formalized for evaluating technical claims bidirectionally. Bob is planning an \"Old Fart\" coding/development stream using OBS Studio, with toolchain including Kdenlive and Auphonic. He researched home audio hardware (targeting floorstanding JBL/Klipsch towers with a Class D integrated amp, one piece at a time as finances allow), is active on Hinge, and had a contact note created for MIT professor Jeffrey Grossman (Compudynamics outreach). The Console VM was named \u2014 Seshat (Egyptian goddess of writing) is the leading candidate given Console's framebuffer rendering role; Zuse (Z-U-S-E, punning on Konrad Zuse/Zeus) remains the superuser/root identity.\n\n*Earlier context*\n\nBob relocated from Lorain/Amherst to Ashland, Ohio after leaving a long-term domestic situation. He spent time at Safe Haven shelter, where he introduced the project to his caseworker Karen, produced a six-slide PowerPoint for non-technical audiences, and continued StarshipOS development via phone/Claude Code while awaiting his workstation. He developed the Starship Ananke Foundation concept \u2014 community tech centers in rust belt cities funded by licensing revenue. The LithosAnanke v250.0.0 \"FORTH of July\" milestone was reached: three VMs (Hera/Hermes/Artemis) running simultaneously on amd64, aarch64, and riscv64 with K conserved and inter-VM messaging confirmed. The ACL architecture was refined (toggle model: commenting out one line drops to single-user mode with zero structural changes). UEFI debug checkpoints with ConOut were added for real-hardware bring-up. Bob identified his development workflow: architectural thinking dictated to Claude, converted to structured prompts for Claude Code, with session-limit resets used as natural pacing. He explored expatriation to Ghana as a longer-term aspiration. He was in contact with a family member in Strongsville who proofread patent materials.\n\n*Long-term background*\n\nBob has ~50 years of embedded systems experience (active since 1973 on a DEC mainframe via TTY), spanning bit-sliced processor design at Lorain Products/Marconi, reliability engineering at Steris (including FDA enforcement navigation and a DoE/Six Sigma background), pipe organ voicing at Ruhland Organ, BBS operation (Catacombs of Cleveland, including early threat intelligence work), and contract work across mainframes, supercomputers, network integration, and ETL. He ran the first instance of the StarForth Design of Experiments (38,400 runs, 128 configurations, K\u22611.0 validated), published on SSRN, and filed the provisional patent in December 2024. The Jacquard Selector, Rolling Window of Truth, and SSM (Steady State Machine) are the core architectural inventions. He has a documented ancestral connection to Continental Army General Lachlan McIntosh. His mother (born 1942, still active) proofread the patent and has been an intellectual model; she hosted politically significant figures in their home during Bob's youth, which he cites as formative. Bob's grandfather Robert Evan James held a railroad engineering patent. Bob has a 33,000-track FLAC music library, Soundcore Q30 Bluetooth headphones, and runs KDE Plasma on X11 (prefers X11 over Wayland for stability with background processes).\n\n**Other instructions**\n\nBob dislikes stock photos.",
|
|
"project_memories": {
|
|
"0199c601-fa9a-7536-84fb-d2f8e1286581": "**Purpose & context**\n\nCaptain Bob is actively developing StarshipOS, an operating system built on Forth with a distinctive physical trust model. The project reflects strong personal values around user responsibility, physical security primitives, and deliberate engineering of computational principles into silicon. Success looks like a coherent, principled OS where design decisions flow naturally from a unified theoretical foundation rather than ad hoc engineering choices.\n\nKey domain areas include: Forth-based OS architecture, security/trust models, block-level storage management, cryptography, and a novel theoretical framework Captain Bob calls compudynamics.\n\n**Current state**\n\nCore architectural decisions recently solidified include:\n\n- **Physical trust model**: Device identity and home block storage are anchored to physical USB media rather than network credentials. USB devices (thumbdrives, SSDs, peripherals) are first-class system citizens with embedded certs that dynamically update the BAM (Block Allocation Map).\n- **ACL.4th**: Toggles between raw single-user Forth mode and credentialed operation; first-boot USB provisioning ceremonies establish `zuse` (the superuser) via physical key insertion.\n- **Backup philosophy**: The system provides aggressive, escalating warnings tied to device wear monitoring but never auto-backs up without explicit user consent \u2014 a deliberate expression of Captain Bob's value that users are responsible for their own equipment and data.\n- **Block-level encryption**: Explored as feasible via a TTL-based block cache (`hot_blocks`) modeled on `hot_words` compudynamics, amortizing crypto overhead similarly to how ACL caching reduces enforcement overhead.\n\n**On the horizon**\n\n- Submitting a paper to SSRN related to the compudynamic framework\n- Considering adding a Discussion section to the paper reframing ACL-RWT as a security layer finding its compudynamic attractor\n\n**Key learnings & principles**\n\n- The `hot_` family (`hot_words`, `hot_blocks`, `hot_messages` via Hermes pub/sub routing cache, ACL caching) forms a **unified architectural family** governed by compudynamic budget allocation at runtime: budget determines TTL, TTL is energy expressed as time, and the system substrate behaves as an unrealized lattice where executions are temporal traversals.\n- This framework is **deliberate engineering of natural computational principles**, not emergent discovery \u2014 Captain Bob is explicit that this distinction matters.\n- The compudynamic budget model generalizes across caching, security enforcement, and message routing, suggesting it is a true substrate-level principle for StarshipOS.\n- User responsibility is a load-bearing design value, not a UX preference \u2014 the system is architected to reflect it structurally (e.g., no auto-backup).\n\n**Approach & patterns**\n\n- Captain Bob works through deep architectural unification \u2014 seeking to connect disparate subsystems (security, storage, messaging, execution) under shared theoretical primitives rather than treating them as isolated components.\n- Precise framing matters; Captain Bob actively corrects imprecise characterizations (e.g., \"discovery\" vs. \"deliberate engineering\") and expects Claude to engage at that level of precision.\n- Design philosophy flows from personal values \u2014 understanding the value (user autonomy, physical trust) helps anticipate architectural choices.\n\n**Tools & resources**\n\n- Forth as the implementation and design language for StarshipOS\n- SSRN as a target publication venue for the compudynamic framework paper"
|
|
},
|
|
"memory_files": [
|
|
{
|
|
"path": "/areas/expatriation-ghana.md",
|
|
"content": "---\nname: expatriation-ghana\ndescription: Bob considering expatriating to West Africa, specifically Ghana\nsources: [chat]\naliases: [Ghana move, expatriation]\n---\n\n- [stated] Interested in expatriating, wants to go back to Africa\n- [stated] Leaning toward West Africa, specifically Ghana \u2014 heard there are expat communities there and it's affordable on his income\n- [stated] Views Ghana as stable and safe by West African standards\n- [stated] StarshipOS work travels with him, so the project isn't a blocker to relocating\n- [stated] Would want a static IP for a physical, self-hosted server box rather than a VPS or relay \u2014 physical control matters to him\n- [stated] Pictures a mid to low-mid tier dwelling rather than the premium expat neighborhoods\n- [stated] Sequencing: get his [[housing-move]] (Ashland, OH) situation stabilized first, then plan an engineered exit strategy toward Ghana \u2014 not there yet\n- [stated] Now leaning toward actually making the move happen; sticking with traditional Medicare while still in the US, plans to sort health insurance once actually in Ghana\n- [stated] Seriously doubts he'd return to the US once he left, so is comfortable dropping Medicare Part B despite the re-enrollment penalty\n",
|
|
"updated_at": "2026-07-29T15:52:11.604272+00:00"
|
|
},
|
|
{
|
|
"path": "/areas/housing-move.md",
|
|
"content": "---\nname: housing-move\ndescription: Bob's housing transition \u2014 Safe Haven stay, Appleseed application, and planned move-in setup\nsources: [chat]\naliases: [Safe Haven, Appleseed]\n---\n- [stated] Decided to stay in the city of Ashland, away from Renata\n- [stated] Completed a housing intake phone interview\n- [stated] Currently staying at Safe Haven while waiting on a housing application through Appleseed\n- [stated] Safe Haven restricts move-in items to brand new only \u2014 no used or refurbished items allowed\n- [stated] Asked to call Appleseed one week after intake to check on the application status\n- [stated] Guesses he won't move into the new place until September or October\n- [stated] Current location's WiFi works on the patio but not in his room, so he plans to do development work outside on the patio while waiting\n- [stated] Plans to get help with furniture from Salvation Army and Appleseed once housing comes through, and to use Rent-A-Center if needed\n- [stated] Will get an air mattress/air bed once move-in day arrives, but is deferring furniture/move-in logistics until then\n- [stated] Priority right now is finishing electronics purchases before rent and living expenses start\n</content>\n<parameter name=\"if_version\">new\n- [stated] Safe Haven is a shelter for survivors of domestic abuse; Appleseed is the separate organization handling his housing process\n- [stated] Process is a waiting game (weeks to months): Appleseed handles Section 8 paperwork as his proxy, then provides a grant once HUD determines specifics, after which they'll tell him what rent range to look for; the grant covers rent, deposit, and part of utilities until Section 8 is approved\n- [stated] Salvation Army handles the intake application; JFS handles SNAP; Safe Haven and Appleseed coordinate the overall process across these agencies\n- [stated] Plans to set up a real hifi audio system once situated in the new home \u2014 wants \"concert hall\" sound in a small room, listens via Strawberry music player with its equalizer, and wants to avoid both cheap junk and $1200+ systems (Sonos, JBL, McIntosh-tier)",
|
|
"updated_at": "2026-08-03T22:08:50.007227+00:00"
|
|
},
|
|
{
|
|
"path": "/areas/starship-ananke-foundation.md",
|
|
"content": "---\nname: starship-ananke-foundation\ndescription: Starship Ananke Foundation \u2014 organizational vehicle for community technology centers\nsources: [backfill]\naliases: [Ananke Foundation]\n---\n- [stated] The Starship Ananke Foundation is the organizational vehicle for community technology centers in rust belt cities\n- [stated] Formalized as a concept during earlier work on StarshipOS commercial and organizational strategy\n- [stated] Has a \"Robinhood licensing idea\" tied to the Foundation concept, which his caseworker is currently trying to help figure out how to implement",
|
|
"updated_at": "2026-07-30T13:30:47.153009+00:00"
|
|
},
|
|
{
|
|
"path": "/areas/starshipos.md",
|
|
"content": "---\nname: starshipos\ndescription: StarshipOS bare-metal OS ecosystem \u2014 architecture, VM design, and formal validation work\nsources: [backfill]\naliases: [StarForth, LithosAnanke, Tripod, Quadrupod, James Law]\n---\nStarshipOS is a novel bare-metal operating system ecosystem built around a formally validated conservation law Bob calls James Law (K\u22611.0).\n\nComponents:\n- [stated] StarForth \u2014 a FORTH-79 compliant adaptive VM in C99\n- [stated] LithosAnanke \u2014 a bare-metal microkernel\n- [stated] Tripod VM architecture composed of three VMs: Hera (in charge of the VMs), Hermes (message routing), Artemis (blocks)\n- [stated] Adding a fourth VM \u2014 the operator console, providing the user interface \u2014 making it a \"Quadrupod\" rather than Tripod; the console is where the user's certificate (stored on a thumb drive) gets plugged in\n- [stated] The superuser console VM is named \"Zuse\" (styled ZUSE, pronounced like \"Zeus\") \u2014 a pun on Konrad Zuse; it spawns when the identity thumb drive is inserted, and like any other VM it must still prove itself via ACLs to interlock with other service VMs rather than having automatic privileged access; ACLs function as a VM's identity, and all inter-VM interaction happens via messages\n- [stated] Zuse is simply the superuser/root identity \u2014 a pun name, not a functional role; Hera is the actual decision-maker for access grants and VM birthing/lifecycle, not Zuse\n- [stated] Every message is checked against ACLs individually (not just once at connection), and messages, ACLs, and blocks all carry a heat-driven TTL that can rise or fall depending on system state; TTL expiry is unconditional (the thing goes away, period), while pinning is a separate, opposite mechanism that makes something invariant/unable to change (rather than just extending its TTL) \u2014 e.g. Zuse's own ACL would be pinned so it can never drift; pinning a TTL on a transient thing like a message isn't something he'd normally do\n- [stated] Zuse's identity/cert is minted (burned in) onto an empty thumb drive on the very first system boot; this is designed as a one-time hardware-style fuse \u2014 once burned, no other drive can ever have that same Zuse identity minted onto it again; losing/destroying that drive is unrecoverable by design (the \"nuclear option\" \u2014 the whole instance's root of trust is gone forever, no regeneration path)\n- [stated] Regular (non-Zuse) users losing or wearing out their dongle is a separate, much lower-stakes case: they'd go through some admin/CIO-style process to get reissued, with deliberate friction/hassle as a deterrent, but it's recoverable \u2014 unlike Zuse\n\nCurrent architecture work:\n- [stated] \"Try\" is intended to be volatile/RAM-resident and never writes back to the thumb drive; \"install\" is the function that creates the bootloader and writes those blocks onto the SSD; both are planned to be written in pure StarForth\n- [stated] Considering packaging a fixed-size virtual disk image alongside the bootable thumb drive, where the \"install\" word would write/mount that image onto the SSD\n- [stated] Hermes has reached the point of reading and writing blocks; next planned step before the Zuse framebuffer demo is a stress test that hammers reads/writes/overwrites on the block subsystem to surface crashes and conflicts\n- [stated] Considering deferring full ACL enforcement for the initial Hermes/Artemis messaging demo, and instead building a Zuse-only framebuffer as the first demonstrative piece\n- [stated] Working through the ARTEMIS.md logical block layer design\n- [stated] Working on heat-driven block migration mechanics\n- [stated] Working on per-instance VM startup scripts\n- [stated] Believes the current primitive set isn't complete yet \u2014 expects to need a moderate number of additional primitives before starting the shrink-to-colon-definitions refactor pass\n- [stated] Design principle: regular users compose via GUI, power users get both the GUI and a CLI/REPL, but everything user-facing must be pure StarForth \u2014 no C compiler shipped inside the OS itself; adding a new C primitive requires going into the actual source and rebuilding, not something done from within a running system\n\nRecent development:\n- [stated] Unified the compudynamics engine into a single C99 module maintaining K\u22611.0 conservation\n- [stated] Introduced a Kconfig-based configuration system across three architectures (amd64, aarch64, riscv64)\n- [stated] Tripod integration test passed 16/16 checks at commit fe4b2442\n- [stated] Tripod VM architecture milestones: a \"FORTH of July\" v250.0.0 target, Artemis Phase 1 acceptance with Q48.16 per-block heat arenas, and K soak milestone passing on all three architectures\n- [stated] Key architectural decisions documented in ARTEMIS.md, HERMES.md, and TRIPOD.md: heat-driven block migration, ACL toggle model, boot-time disk detection states, and a dynamic VM fleet physics mechanism treating fleet size as a governed variable with the same compudynamic substrate as word-level physics\n- [stated] Tightened CLAUDE.md quality guardrails with production-grade-only policies and a Definition of Done checklist\n\nIP and publication:\n- [stated] Has a provisional patent with a December 26, 2026 conversion deadline; expects to miss that deadline and is instead prioritizing a separate LithosAnanke-specific patent, which he expects to have solid by December 1, 2026\n- [stated] LithosAnanke kernel patent filing planned for late November 2026; this timeline leaves another year to get the FPGA/CU work in a stable state\n- [stated] Plan: once Tripod is done and the console VM is added, the remaining work is writing everything up, which will also strengthen the LithosAnanke patent claim\n- [stated] Now leaning toward treating the steampunk \"trailers\" concept as more of a trademark matter than a patent angle, and considers it outside LithosAnanke's patent scope\n- [stated] New case concept: a small internal PCB driving an LED matrix behind the case grille that pulsates/glows based on live compudynamics temperature/state data\n- [stated] Diffuser plan: hand-dip parchment coated with a homemade albumen/silver-nitrate emulsion (salted for sensitizing, fixed with sodium thiosulfate) to get uneven, drippy density, deliberately exposed under music-reactive LED strips for chaotic variation; considers the resulting unpredictable, one-of-a-kind look a selling point if he ever sells pre-built units, and has coined the phrase \"indeterminate determinism\" for the concept\n- [stated] Has a published SSRN paper (abstract revised for better conversion)\n- [stated] USPTO Pro Bono counsel engaged\n- [stated] Seven patent claims drafted for counsel review\n\nEarlier validation and strategy:\n- [stated] Ran Design of Experiments campaigns validating K\u22611.0 across 38,400+ runs on amd64, aarch64, and riscv64 under QEMU\n- [stated] Developed the Jacquard Selector concept \u2014 the patent-established name for the pattern-driven selection mechanism\n- [stated] Ran the ACL-RWT Latin Square experiment confirming ISA-invariant conservation attractor\n- [stated] Established LaTeX documentation infrastructure under `docs/formal/` with a shared house style\n- [stated] Plans to implement Isabelle/HOL formal verification for the CU/ALU work, augmenting the existing write-up under `docs/formal/`; the verification harness is planned as part of the ARM boot sequence\n- [stated] Commercial strategy: Starship License 1.0 and a corrected dual-licensing approach\n- [stated] Target: a single $200k/year license deal; at this point would also consider an outright sale of StarshipOS\n- [stated] Concept for a hosted StarForth SSH service on Oracle Cloud Always Free ARM\n- [stated] Floated idea of building a StarshipOS-native phone/desktop companion protocol (like KDE Connect) after finding Linux's phone-sync options limited\n\nHistory:\n- [stated] Has been building StarshipOS for over two years\n- [stated] Development philosophy: phenomenon first, then mathematics; minimal complexity; document before code; no time references in design docs \u2014 correctness matters more than delivery\n\nHardware/porting plans:\n- [stated] Decided to put the Pi 4/Milk-V Mars SBC route on hold and go FPGA-first instead, reasoning that a Pi demo is a \"toy\" and RISC-V SBCs aren't a saleable commodity, whereas an FPGA embodiment is both the more scientifically meaningful test of the substrate invariant and more saleable/fundable given his financial situation\n- [stated] Plan before FPGA: use the existing POST functional test suite (which exercises every dictionary word) as a regression gate to shrink the StarForth dictionary word-by-word \u2014 recomposing C99 primitives as colon definitions where possible, swapping into the capsule, and rebooting/retesting to confirm before removing the primitive; goal is a minimal primitive set prior to committing anything to silicon/fabric; StarForth's primitives are ~18 months mature (first ran natively on hosted Linux about that long ago) and are not a speed concern for this pass\n- [stated] FPGA architecture concept: build the CPU directly in the fabric using a J1-style stack-machine approach (words as instructions, no general fetch-decode-execute layer) \u2014 a hardware data stack and return stack, a lean register set (T/N/IP/A-style, avoiding a \"rich\" general register bank to keep opcode space collapsed), single-cycle execution with no pipelining (matching classic 8-bit stack machine design just widened to 64-bit, to preserve determinism and simplify eventual formal verification); the on-chip ARM (Zynq PS side) would just handle boot/bitstream loading, not run any of the actual StarForth logic\n- [stated] Compudynamics (K\u22611.0 tracking) is planned to be feedback into the control unit itself (not just passive instrumentation) \u2014 conceived as part of the CU (\"compudynamic unit\"), still open question of whether the feedback affects only timing/scheduling or also which instruction path executes next\n- [stated] Speculatively planning to buy SBC hardware timed around next SSI check: Raspberry Pi 4 and a Milk-V Mars (RISC-V) to get riscv64 running on real hardware; BeagleBone Black shelved for now\n- [stated] Plans to 3D print a single scaled StarshipOS-branded case (based on a Babbage-engine-styled Analytical Engine design) sized to house all three real-hardware nodes \u2014 a second Beelink SER5 (amd64), Raspberry Pi 4B (aarch64), and Milk-V Mars (riscv64) \u2014 via one interchangeable mounting plate per platform, swapped in one at a time\n- [stated] Views the patio rig (amd64), Pi 4B (aarch64), and Milk-V Mars (riscv64) together as a true real-hardware PoC covering all three ISAs; will keep validating K\u22611.0 under QEMU until ready to move to real hardware\n- [stated] Case design plan: each mounting plate carries its own board-specific wiring (HDMI, power, USB, GPIO) with strain relief and epoxy at the plate, terminating in standardized full-size external connectors (full-size HDMI, one common power standard, full-size USB-A) so the case's external face is identical regardless of which plate/board is installed; no soldering required, using existing header-to-panel adapter cables\n- [stated] Wants a dedicated USB port/slot for a security key (thumbdrive holding CA-issued certs + a home block range), routed via internal USB header to a panel-mount jack, decoupled from whichever board is installed\n- [stated] Since the SER5 (x86) has no native GPIO, plans to add a USB-C GPIO bridge dongle just for that node, with StarshipOS giving an explicit boot-time warning/notice when the bridge is (or isn't) detected, rather than pretending the node has native GPIO like the Pi 4 and Mars\n- [stated] Considering adding an internal USB hub inside the case (feeding panel ports, the GPIO bridge, and the identity key slot from one upstream connection) and a shared internal PSU sized for the highest-draw board, rather than per-board wall warts\n- [stated] Wants the 40-pin GPIO header to be a well-constructed, genuinely gold-plated (not just gold-colored) header given repeated plate insertion/removal cycles, and plans to source it from Digi-Key/Mouser rather than generic marketplace listings\n- [stated] Considering a Zynq (FPGA + ARM) SoC as an additional platform/mounting plate down the line, since its GPIO would be defined in the programmable logic fabric rather than inherited from a fixed vendor pinout\n- [stated] \"Trailers\" concept: modular peripheral units (each with their own SBC) connecting to the main case via a standardized USB-C interface for both power and data; GPIO is reserved for breadboarding/prototyping rather than being part of the trailer spec itself\n- [stated] First trailer concept: a non-contact, gesture-perturbed holographic display \u2014 a poke-able (but non-contact) multi-sided cube using proximity/hand-tracking sensing so hand movement perturbs a Pepper's-Ghost-style projected image, paired with anaglyph 3D glasses, ideally visualizing live StarshipOS compudynamics state\n- [stated] Had set up his SER5 as a server running Gitea (with its own CI) with plans for XWiki and sshd; ran into apparent RAM-related instability (kernel panics, service failures) running the stack, which turned out to actually be caused by a nearly nonexistent swap file (5MB) rather than insufficient RAM; increasing swap to 8GB relieved the memory pressure immediately, so the SER5 may not need a RAM upgrade after all; Gitea's repository listing had also appeared empty at one point but this was just because he wasn't logged in \u2014 no repos were actually lost\n- [stated] Plan: create two new separate GitHub repos, one for StarForth and one for LithosAnanke, point local repo remotes at them, and force-push \u2014 replacing the Gitea setup; the old stale github.com/rajames440/StarshipOS repo will be kept (made private, not archived) as a backup rather than removed\n- [stated] Looking for a cheap managed VPS host bundled with a domain name, to host infrastructure (Gitea and XWiki at minimum) \u2014 budget-constrained\n- [stated] Plans to use XWiki with Groovy scripting to build a portal for the \"Starship Foundation\" / Starship Project umbrella, covering StarForth, StarshipOS, LithosAnanke, the yet-unnamed FPGA platform, and the physical case/trailer work\n- [stated] Has an existing but stale GitHub repo at github.com/rajames440/StarshipOS reflecting an earlier gForth/JVM/L4Re-based direction of the project, predating the current bare-metal StarForth/LithosAnanke architecture\n- [stated] Considering using the Anthropic API to pull design conversations into the XWiki portal semi-realtime, with manual editing before publishing; sees documenting his AI-assisted design process as a way to push back on being told he \"can't program\"\n\nHermes/Artemis rework (in progress, 2026-08-03):\n- [stated] Rethinking how Artemis and Hermes are going to work; treats word-level compudynamics in the StarForth VM as the thing that has to be understood first\n- [stated] Considering deciding per-VM heap allocation at birth (VMs are \"birthed\", not spawned/murdered); notes there appears to be plenty of heap space available\n- [stated] Plans some sort of fabric inside Hera to keep track of all the VMs; reconsidering whether that fabric is done in native Forth\n- [stated] Plans to organize Hera's VM fabric conceptually (not literally) the same way the StarForth dictionary is organized, with the compudynamics engine reorganizing it on the fly as needed\n- [stated] Floating a third per-VM store general to all VMs \u2014 an \"object stack\" separate from the data stack and return stack, somewhere to dump things \u2014 but unsure a stack is the right shape, since he wants something searchable/reorderable where the compudynamics engine determines access order; wants to achieve this without introducing a scheduler\n- [stated] In the StarForth VM, words are executed based on their heat\n- [stated] Proposes that a VM's permanence and its priority of execution are the VM-level analogy to a word\n- [stated] Core direction: take the dictionary up a level of abstraction into a general \"fabric\"/container (likens it to a vacuum in a bottle \u2014 what's popped out is popped out) used consistently across messages, VMs, block fabric, and screen fabric/framebuffer; the compudynamics engine doesn't care what it's acting on, it just acts on whatever is in the container\n- [stated] Wants that container set aside as dedicated memory rather than part of the heap, built into the VM itself\n- [stated] Open question: whether the container is one general OS-wide memory area, or per-VM and possibly atomically shared \u2014 undecided\n- [stated] Revised the container image from a rigid bottle to a bladder/bubble/water balloon \u2014 squishy walls that can grow and shrink\n- [stated] Expects the bladder to hold mixed content \u2014 messages, blocks and everything else floating in it together; thinks Hera should allocate the bladder area, ultimately bounded by the system\n- [stated] Sees the fabric generalization as a more object-oriented direction; since the dictionary already works this way he doesn't expect a horrible refactor, but expects it to be sticky and to need really thorough testing\n- [stated] Crux of the design: had been stuck assuming blocks would need to be different, but concluded everything already has the same \"wires\" (properties) \u2014 so the plan is to look at the dictionary structure, lift it to the next level of abstraction, and put everything in the same container since the wires are identical anyway\n- [stated] Status as of 2026-08-03: Artemis can now reliably read/write and persist \u2014 that part is banked and considered done; Hermes is still unfinished and he expects the same defects are latent in it\n- [stated] Post-FABRIC.md build order (2026-08-05): Hermes first (rebuilding its FORTH capsules from scratch on the Stadium, per item 4.2), then Console, then Artemis last \u2014 matching FABRIC.md \u00a710's original sequencing rationale (Artemis already works reliably and is the one thing that can't be broken, so it goes last)\n- [stated] Optimistic two-week timeline floated (2026-08-05): Hermes + Artemis + Console all working together by this coming Friday; ACLs implemented, Artemis finished, and user minting done by the Friday after that\n- [stated] Block-addressing design for Artemis: each user's blocks always appear to them as a contiguous range starting at block 0 through the end of their own blocks, regardless of where those blocks actually sit on the underlying SSD \u2014 a user is always the last set of blocks in the system, keeping the user-facing view consistent even as the physical layout changes\n- [stated] Longer-term (explicitly not being built now) idea for extending storage: some future non-privileged way to add block space by mounting/attaching an external file (e.g. a swap-file-like blob stored on Dropbox or similar) as additional blocks \u2014 undecided on the right term for this since \"mount\" doesn't feel accurate to him\n- [stated] Bought two physical thumb drives for the initial user-minting test: one to become the Zuse (superuser) drive, one for his own regular-user identity, Captain Bob\n- [stated] Block allocation on a minted drive: the entire drive capacity becomes blocks (e.g. a 32GB thumb drive), minus whatever metadata overhead is needed (expected to be small); reserves a 4K controller region split into three 1K blocks plus one 1K metadata block. Confirmed 1K is the actual system block size, chosen because modern SSD/hard drive controllers read/write in 4K physical units, so four 1K logical blocks fill exactly one 4K controller read/write\n- [stated] ACLs are planned to start actually being implemented once Artemis is reached \u2014 the gating infrastructure already exists in the VM itself, but nothing is wired up yet; wants Console working first, and considers ACL implementation itself mostly straightforward once its turn comes since the infrastructure is already in place\n- [stated] Plan: build one \"engine\" (the whole compudynamics thing) that drives everything, reusing the same feedback loops with a governor so it doesn't oscillate; reckons roughly eight loops once Hera and the depth of the heartbeat are counted\n- [stated] Considers the knowns settled \u2014 the experiments are done and the algorithms exist; the remaining open question is purely how much implementation effort and technical debt it will incur\n- [stated] Mental model that clicked: a Detroit-style auto show hall \u2014 cars inside, people inside, a definite capacity that can't be escaped; people arrive and leave, bump into each other, stare at a car for a while and move on, sometimes want to sit in one; the questions and conversations people have are the messages\n- [stated] Storage doesn't fall into the metaphor cleanly \u2014 persistence feels separate to him; framebuffer is another story he doesn't want to get into. Wants one unified modified system, not a proliferation, and keeps getting stuck in detail when what he wants is the high-level abstraction\n- [stated] Settled term: it's an arena, sitting outside any of the VMs, allocated at boot time by some yet-undecided mechanism; suspects the engine and the capacity may have to be built before any VM boots at all\n- [stated] Considers the direction settled and non-optional (\"it's gotta go this way, there's just no choice\") \u2014 the ideas are all there and it's now a matter of unifying them; expects the arena to be what maintains the K value\n- [stated] Plans the next day to be mostly planning/layout and brain work rather than coding; asked for a plain-markdown (non-LaTeX) draft of the unified design to review and play with on waking\n- [stated] Realized the fabric unification also solves a huge separate problem \u2014 it greatly simplifies the Isabelle/HOL formal verification work\n- [stated] FABRIC.md has since been expanded with Claude Cowork into a living working document (\u00a71\u201315 original design argument, \u00a716+ findings against the actual tree, \u00a725 authoritative punch list). The abstraction is now called the Stadium \u2014 \"arena\" collided with src/starkernel/vm/arena.c, the PMM-backed VM page allocator; occupants are called patrons. Destined for the LithosAnanke repository.\n\nConsole VM (Quadrupod, CONSOLE.md draft, 2026-08-02):\n- [stated] Pivoted Console's design from \"wrap the existing bitmap/VT100 framebuffer driver\" to treating the framebuffer as a full-color, Cartesian-addressed, rasterized-vector drawing fabric, with text as just one thing drawn on it rather than a special bitmap-cell case\n- [stated] Console will be the fleet's fourth VM (Quadrupod, not Tripod), spawned by Hera, participating in fleet K\u22611.0 like Hermes and Artemis; it owns the drawing fabric and (later) keyboard input, but does not route messages, own storage, or make VM lifecycle decisions\n- [stated] Language rule for Console: StarForth only, with the same narrow exception as other Tripod VMs \u2014 raw hardware pixel writes into GOP framebuffer memory are C, registered as Forth primitives; everything above that (glyph composition, cursor logic, dirty-cell tracking, VT100 semantics, fonts) is StarForth; any further C99 use requires his explicit written permission per instance\n- [stated] Coordinate system decision: true Cartesian, origin bottom-left, Y increases upward (Y-flip applied at the lowest primitive layer)\n- [stated] Primitive layer is absolute-coordinate (not turtle/relative) \u2014 PLOT and LINE \u2014 chosen because the long-term wireframe/triangle direction is fed by projected vertex data, which is naturally absolute\n- [stated] Fonts are StarForth words (each glyph a short pen-stroke sequence resolving to LINE calls), authored as swappable, hash-verified `.4th` capsules like everything else in the system; Phase 1 requires the full printable-ASCII glyph set, not a subset\n- [stated] Redraw model is heat-driven dirty-cell tracking (same compudynamic vocabulary as BLK-HEAT): a cell goes hot on content change, Console's tick scans only hot cells, and redrawing a cell is itself the reap event (heat to zero from work done, not decay)\n- [stated] Wants a LOGO-style turtle-graphics command layer for general drawing (pen up, pen down, turtle left/right, turtle north/etc.) as the user-facing way to command drawing, distinct from how fonts/glyphs get drawn; fonts/glyphs are meant to be their own thing entirely \u2014 drawn directly, programmed into capsules, so users can author their own custom fonts\n- [stated] Decided to build Console's coordinate system as full X/Y/Z from the start rather than 2D now with 3D retrofitted later, reasoning it'll make the eventual 3D/wireframe direction easier since it avoids redoing the coordinate system down the line\n- [stated] Clarified everything being built right now is genuinely flat/2D content \u2014 the Z dimension is there so things can later rotate/roll and move in depth, not because near-term drawing needs actual depth\n- [stated] Idea: use the existing StarshipOS circular logo/badge artwork (starfield background, circular ring with \"StarshipOS\" arced around the top, Santino the corgi mascot centered inside) as the startup/boot screen\n- [stated] Immediate Phase 1 goal: VT100-equivalent terminal rendered via the vector fabric, Console joining fleet K\u22611.0, full ASCII stroke font, cursor/scrolling/VT100 semantics, heat-driven redraw, text delivered via Hermes (no second message mechanism); keyboard input, double buffering, and the full wireframe GUI vision are explicitly out of scope for this phase\n- [stated] Open decisions not yet settled: Console's mythological name (candidates Argus/Iris/Hestia raised but not chosen), whether to retire or keep font_8x16.c/vt100.c for pre-Console boot diagnostics, whether/how to add double buffering, and actual achievable frame rate (unmeasured, QEMU TCG vs real hardware expected to differ)\n- [stated] New UI concept for Console (2026-08-05), inspired by the Claude Code bash console layout: a fixed single-line input field bordered by horizontal rules above and below, with a dynamic scrolling output field above that \u2014 the REPL prompt lives in that bordered input line where FORTH commands are typed, and the output area above is meant to also be editable\n- [stated] Clarified the Console UI concept is layout inspiration only, not a VT100/escape-sequence approach \u2014 rendering stays fully vector/cartesian on the framebuffer as already decided for Console, with fonts/glyphs defined in capsules so a font can be written and ported in FORTH; considers the box layout itself his own idea distinct from just copying Claude Code's UI\n- [stated] FABRIC.md's second review pass (2026-08-03, pre-coding) closed all fourteen findings \u2014 including ruling GAP-A1 (the engine's tick is a virtual tick, a pure function of the execution stream, not a hardware tick) \u2014 leaving the document ready to hand to a coding model\n- [stated] FABRIC.md progress as of 2026-08-04: Phase 0 (substrate \u2014 real timer interrupts/IRQ return paths on all three ISAs) complete and accepted, with identical reproducible parity dict hashes across runs; most of Phase 1's design questions (items 1.1-1.12, e.g. the \"contains\" containment wire replacing a lock, elastic per-VM capacity quotas, linked continuation cells, outer VM-count bound of 4) resolved; Phase 2 items 2.1 (heat transfer restated on the virtual tick) and 2.2 (bounded VM registry) done; ruled an adaptive hardware heartbeat (\u00a726) reusing an existing orphaned Loop #7 mechanism rescaled to kernel timescale\n- [stated] FABRIC.md progress as of 2026-08-05: Phase 3 (Stadium core) complete \u2014 items 3.1-3.8, including cell/header definition, boot-time allocation, behaviour dispatch, density ranking, admission/eviction, Hera as pinned patron zero, per-VM free lists, and a VM identifier switch from uint32_t to a 128-bit UUID (deterministic splitmix64 PRNG fallback since none of the three ISAs has a real RNG in this QEMU config, seeded from the capsule hash for reproducibility); Phase 4 item 4.1 (hot words onto the Stadium via a reservoir-based heat-conservation mechanism, \u00a717.7) done, replacing the old round-robin hotwords cache in kernel builds while leaving it untouched for hosted builds; items 4.1a (Hermes's initial quota grant) and 4.2 (Hermes native on the Stadium, the \"proving ground\" step) are next, with 4.2 explicitly held for discussion before starting per Bob's request\n- [stated] Later idea for Console: let users set a custom background image, with the ability to pan and zoom across it while vector graphics (the normal drawing fabric) render on top of it\n- [stated] Rendering decision: vector character set plus TTF support, using Q48.16 fixed-point; JetBrains Mono is the standard REPL font after boot, with the native vector font as fallback; imagines POST itself rendered in the old-school vector font, drawn in native StarForth; TTF is strictly a post-Console capability (no rasterizer exists pre-Console, so vector is the only option at POST) \u2014 once Console is up, users can load any TTF font capsule they like for the REPL\n- [stated] TTF fonts get fully rasterized to a bitmap from source at load time and handed to the REPL that way, rather than rendering glyphs char-by-char on the fly; wants user-customizable kerning; floated a possible future application capsule for on-screen font design; if no TTF is loaded, wants the vector font(s) to default for a PARC (Xerox Alto/Star-era) look\n- [stated] Planned redesign (2026-08-11, deferred until after the framebuffer console work is finished): HB-ON/HB-OFF FORTH words to gate whether heartbeat/DoE instrumentation is being recorded, with the recorded rows written onto the virtio-blk disk image as physical blocks (ring-buffer style) rather than relying on a live serial capture; this is meant to supersede the existing doe_log.c output mechanism, not run alongside it, so a \"daily driver\" boot can record instrumentation to disk with no host tooling attached; intends to have Claude Code implement this once the fb console work is polished up\n\nFirst boot milestone (2026-08-12):\n- [stated] Achieved a full clean first boot: UEFI loader through kernel handoff, Hermes 4.2 self-test (stadium HADES/DOE cells, promotion/eviction, PARITY:KILL on a VM, resting state restored, conservation invariants held), heartbeat ticking, landing in the StarForth Emergency CLI on LithosAnanke v1.5.4 / StarForth 3.1.0 \u2014 a live FORTH-79 REPL\n- [stated] Confirmed the VM naming/roles: Hera is the first of three VMs (godmother/in-charge-of-all), then Hermes (the messenger), then Artemis (storage device manager)",
|
|
"updated_at": "2026-08-13T02:23:30.219955+00:00"
|
|
},
|
|
{
|
|
"path": "/people/brother.md",
|
|
"content": "---\nname: brother\ndescription: Bob's brother, a Cleveland-area musician\nsources: [chat]\naliases: []\n---\n- [stated] Bob's brother played in a band that had its farewell show at the Beachland Ballroom in Cleveland\n- [stated] Bob's brother's band opened for Iggy Pop at CBGB\n- [stated] A friend/bandmate named Dave was the bassist for the band Death of Samantha\n- [stated] Bob feels he and his brother process things in a similar way, more than either of them consciously realizes\n",
|
|
"updated_at": "2026-07-26T12:05:11.702213+00:00"
|
|
},
|
|
{
|
|
"path": "/people/michael-stanley.md",
|
|
"content": "---\nname: michael-stanley\ndescription: Bob's close friend from his days at The Coral; Cleveland musician (Michael Stanley Band), now deceased\nsources: [chat]\naliases: []\n---\n- [stated] Bob's best friend from \"the days at the Coral\"\n- [stated] Cleveland-born musician, Michael Stanley (Michael Stanley Band)\n- [stated] Has passed away; Bob is still deeply affected by his death\n- [stated] Met/knew Michael at The Coral, a Cleveland-area venue that later burned down (empty lot on Cook Road now, likely Columbia Station, OH); Bob and Michael became fast friends after Bob warned him that bandmate Jonah Koslen wasn't going to stick around, which ended up altering MSB's internal dynamic through to the end\n- [stated] Worked sound at the Stagepass recording sessions, which he feels cemented his friendship with Michael\n- [stated] Recalls the Stagepass sessions were recorded on only 16 tracks, and that both nights ran the exact same setlist (an undocumented detail), which helped the final mixdown\n- [stated] Jonah Koslen wrote \"Strike Up the Band,\" which Michael used as his closing song at every show and echoed as his backstage catchphrase before going on\n- [stated] Koslen later sued Michael Stanley for rights to his music after leaving the band, part of a turbulent period of label switches and lineup/personnel changes",
|
|
"updated_at": "2026-07-25T23:01:40.889358+00:00"
|
|
},
|
|
{
|
|
"path": "/people/nadia.md",
|
|
"content": "---\nname: nadia\ndescription: Woman Bob has connected with at Safe Haven; he's one of the only people she talks to besides her case manager\nsources: [chat]\naliases: []\n---\n- [stated] Named Nadia, staying at [[housing-move]] (Safe Haven)\n- [stated] Bob is one of the only people she talks to there besides her case manager\n",
|
|
"updated_at": "2026-07-31T15:52:55.437875+00:00"
|
|
},
|
|
{
|
|
"path": "/people/partner.md",
|
|
"content": "---\nname: partner\ndescription: Bob's long-term partner\nsources: [backfill]\naliases: []\n---\n- [stated] Bob's long-term partner, who he used to live with\n- [stated] Bob has left Renata for good, now staying in Ashland (see [[housing-move]])\n- [stated] Bob describes the relationship as transactional on her part \u2014 together 15 years, and things deteriorated after he retired",
|
|
"updated_at": "2026-07-31T15:51:33.179083+00:00"
|
|
},
|
|
{
|
|
"path": "/people/santino.md",
|
|
"content": "---\nname: santino\ndescription: Bob's dog and the StarshipOS mascot\nsources: [backfill]\naliases: []\n---\n- [stated] Bob's dog, a Dachshund/Ridgeback/Staffordshire mix\n- [stated] The StarshipOS mascot",
|
|
"updated_at": "2026-07-15T22:09:38.374894+00:00"
|
|
},
|
|
{
|
|
"path": "/profile.md",
|
|
"content": "---\nname: profile\ndescription: Who Captain Bob is \u2014 identity, background, and work at a stable level\nsources: [backfill, chat]\naliases: []\n---\n- [stated] Goes by Captain Bob (Robert Allan James)\n- [stated] Sole architect and developer of StarshipOS, a bare-metal operating system ecosystem\n- [stated] Now based in Ashland, Ohio (previously Cleveland / Lorain County area)\n- [stated] Polymath with roughly 50 years of embedded systems experience\n- [stated] Directs StarshipOS architecture himself, using Claude Code as an implementation assistant\n- [stated] 67 years old",
|
|
"updated_at": "2026-08-02T14:03:31.543743+00:00"
|
|
},
|
|
{
|
|
"path": "/topics/background.md",
|
|
"content": "---\nname: background\ndescription: Bob's professional and family engineering background\nsources: [backfill]\naliases: []\n---\n- [stated] Roughly 50 years of embedded systems experience\n- [stated] Did bit-sliced processor design at Marconi/Lorain Products\n- [stated] Reliability engineering at Steris\n- [stated] Pipe organ voicing at Ruhland Organ\n- [stated] Grandfather Robert Evan James held a railroad engineering patent\n- [stated] Describes a multi-generational, credential-independent engineering pattern in his family\n- [stated] Mom and brother are also polymaths; in his family's polymaths, one domain tends to bubble up as dominant per person \u2014 his is science, his brother's is music, his mom's is philosophical\n- [stated] Bob, his mom, and his brother would sometimes speak Latin together when they wanted privacy from the rest of the family\n- [stated] Mom started teaching Bob and his brother Latin intentionally around age 3-4; his sister Linda went along with it but had no particular interest in it\n- [stated] Mom's school required two foreign languages; she chose Latin and Russian, before she had to drop out of school\n- [stated] After leaving Bob's father (Allan), mom got her GED and a Master's in Divinity\n- [stated] Mom never became a preacher; she worked behind the scenes as a food bank coordinator for Harvest for Hunger at the Westside Ecumenical Ministry\n- [stated] Mom was involved in serious social-justice activism that touched Bob's own childhood household directly; her circle included Norman Bent, a Moravian minister who was part of the Daniel Ortega government, and Joel Gajarda, a Chilean university professor\n- [stated] The family hosted Norman Bent for about two weeks during a missionary tour where he gave pulpit talks around the country; he later returned to visit for about a month. Joel traveled incognito but publicly, telling people what was happening in Chile whenever he got the chance\n- [stated] Has an ancestor in Continental Army General Lachlan McIntosh, which informs his sense of civic obligation\n- [stated] Worked two full-time jobs (sound engineering and organ voicing) at once in his younger years to pay his own way through CCC (Cuyahoga Community College) tuition\n- [stated] Worked sound for the Agora (hired directly by the Agora, not the Belkins) during the 1970s Cleveland rock scene, including World Series of Rock concerts at Cleveland Municipal Stadium (the \"echo bowl\") and Todd Rundgren shows; had run-ins with promoter Jules Belkin\n- [stated] Lost his collection of concert stubs and VIP passes; his mother ended up with some of his clothes from that era, including an original never-worn WMMS \"Buzzard\" t-shirt with the Daffy Dan logo, and a Cleveland Crusaders jersey\n- [stated] Still in occasional contact with some surviving figures from that era: Joe Walsh pings him occasionally, and Todd Rundgren exchanges emails with him about meeting up",
|
|
"updated_at": "2026-07-26T13:21:00.154989+00:00"
|
|
},
|
|
{
|
|
"path": "/topics/dev-environment.md",
|
|
"content": "---\nname: dev-environment\ndescription: Bob's development tooling and workflow\nsources: [backfill]\naliases: []\n---\n- [stated] Primary development workflow uses CLion with Claude Code integration\n- [stated] Long-time, strong preference for JetBrains/IntelliJ Platform products over alternatives like NetBeans or Eclipse\n- [stated] Uses voice-to-text as part of his development workflow\n- [stated] Uses KDE Plasma 6, with ALSA/PipeWire audio working well on it\n- [stated] Upgraded Kubuntu from 24.04 LTS to 26.04 LTS; afterward started having audio stack problems and kernel panics he hadn't had before\n- [stated] Has never used a CAD application before\n- [stated] Doesn't mind GUI tools, especially when learning something new (e.g. Vivado for his first FPGA project)\n- [stated] Got a new Beelink SER5 computer\n- [stated] Set up rclone with Dropbox on the Beelink SER5, backed by a systemd service \u2014 daily incremental backups, weekly full backups, running every morning\n- [stated] Has tried Codex and GitHub Copilot for coding work and found both lacking compared to Claude Code\n- [stated] Uses Claude session-limit resets as a natural pacing/break point in his work \u2014 when he hits the wall he steps away until the window resets rather than pushing through\n- [stated] Workflow pattern: bounces back and forth between this web chat interface and CLion/Claude Code \u2014 uses design conversations here as notes he reads back to himself when he sits down to actually implement in Claude Code",
|
|
"updated_at": "2026-08-05T20:35:21.223838+00:00"
|
|
},
|
|
{
|
|
"path": "/topics/hobbies-and-interests.md",
|
|
"content": "---\nname: hobbies-and-interests\ndescription: Bob's hobbies, past pursuits, and areas of interest outside work\nsources: [backfill]\naliases: []\n---\n- [stated] Pipe organ building and voicing (voiced organs at Ruhland Organ)\n- [stated] Large format photography (including a juried Cleveland Museum of Art placement at age 16)\n- [stated] Mountaineering, including a Denali attempt\n- [stated] Road racing \u2014 a 1998 Dodge Viper RT/10 raced at Mid-Ohio\n- [stated] BBS operation (the Catacombs of Cleveland) in the 1980s, including early threat intelligence work\n- [stated] Mead-making\n- [stated] Built a LOX/Jet-A rocket engine as a teenager\n- [stated] Intellectual models: Dirac, Shannon, Feynman, and Chuck Moore\n- [stated] Dislikes stock photos\n- [stated] Early programming history: translated spaghetti-code BASIC listings (from a book) into structured Commodore BASIC using a jump table, on a Tandy/Radio Shack computer originally; later bought a GEOS macro assembler (6502/6510) for the Commodore 64 and built his own libraries and stateful subroutines on it, eventually writing a Forth system on the C64 he called GeoForth\n- [stated] Once built a website (never launched) integrating an AIML-based chatbot (from a downloaded \"personality\" script library) with live web search (e.g. Wikipedia) and OpenNLP, so the bot could riff on fetched content\n- [stated] Doesn't use Facebook\n- [stated] Built his own turntable as a teenager: cast concrete table, salvaged JVC tonearm, dual Pickering cartridges (one diamond, one sapphire), weighed 75 lbs, could track at 1/8 gram\n- [stated] Turntable workflow: used the sapphire cart once per record to check for warping/defects, then switched to the diamond cart for the real listen, dubbing to metal cassette or reel-to-reel and storing tapes flat to preserve the vinyl\n- [stated] Had a vinyl collection of around 1,000 records at one point; no longer has them and wishes he did\n- [stated] Had a hand-engraved desk sign made at a Parmatown Mall kiosk reading \"DO NOT FUCKING TOUCH ANYTHING\" to keep party guests off the rig; the reel-to-reel meant nobody could mess with it\n- [stated] The reel-to-reel deck had auto-reverse, letting a tape run about 4 hours before needing attention\n- [stated] Favorite bands: Deep Purple, Black Sabbath, and The Who\n- [stated] Documented family lineage traces back 5 generations to Lachlan McIntosh (Revolutionary War-era figure); his aunt Shirley holds a fully digitized trunk of the genealogical documents but guards access to them closely\n- [stated] Owns a pair of Soundcore Q30 headphones, and has noticed the current version's build quality has improved \u2014 screwed-together construction and a sturdier headband instead of the old snap-together plastic",
|
|
"updated_at": "2026-08-03T22:21:11.357347+00:00"
|
|
},
|
|
{
|
|
"path": "/topics/recent-work.md",
|
|
"content": "---\nname: recent-work\ndescription: Recent work-adjacent activity and one-off items that don't warrant their own project file\nsources: [backfill]\naliases: []\n---\n- [stated] Plans to get back to 8+ hrs/day building the rest of the Tripod once the new computer is set up\n- [stated] Planning to buy a Zynq SoC next month\n- [stated] Considering an \"Old Fart\" podcast/stream where people can watch and listen to him work on [[starshipos]] / LithosAnanke\n- [stated] Got isometric cube rendering working on the framebuffer, along with polygons, curves, circles, arcs, and ellipses; now building a PS/2 keyboard driver, then glyphs, then a REPL \u2014 targeting completion in a week (from Aug 7, 2026), then picking back up on Artemis\n- [stated] First game planned: an old-school 8-bit-look color Asteroids clone, then plans to tackle audio next\n- [stated] Audio plan: capsules for WAV playback, plus a Commodore SID-style synth approach\n- [stated] Audio architecture planned to mirror the framebuffer model, using a soundbuffer\n- [stated] Planned build order after audio: TCP/IP stack, continuing the pattern of reusing compudynamics across every subsystem\n- [stated] Capsule server would allow update capsules to supersede baked-in ones at runtime with no restart needed; strongly dislikes POSIX/Windows-style restart-to-install patterns",
|
|
"updated_at": "2026-08-08T02:14:40.559737+00:00"
|
|
},
|
|
{
|
|
"path": "/topics/writing.md",
|
|
"content": "---\nname: writing\ndescription: Bob's political commentary publication\nsources: [backfill]\naliases: []\n---\n- [stated] Publishes commentary under the Progressive Papers banner, with a Saturday Evening Post aesthetic\n- [stated] Produces illustrated pieces and a \"Weekly Heroes & Hacks\" feature",
|
|
"updated_at": "2026-07-15T22:09:39.800615+00:00"
|
|
}
|
|
],
|
|
"account_uuid": "34142841-6707-48ce-9d55-c8b221559f41"
|
|
}
|
|
] |