I am slowly moving more of my engineering life back into Linux. Not as a slogan. As a workflow.

This is part two of my hardening series. Part one was Hardening Long Projects in the Age of AI. That post was about the discipline of staying with long projects, using AI without losing ownership, and turning old work into a system that can keep compounding. This post is the practical operating-system layer of that same idea: hardening the Linux workflow underneath Antsand, C Kernel Engine, robotics, PCB design, CAD, simulation, and content production.

Antsand was always built on Linux. ShivasNotes was always generated through Antsand. But the important change now is that AI can work through this system with me. It can update posts, fix templates, upload assets, regenerate pages, inspect code, and leave the deterministic website generator as the gatekeeper. That matters because the website is not being hand-edited into chaos. The AI can help, but Antsand still decides what becomes the final public site.

That is the part of Antsand that I think people may miss. It is not only a CMS. It is becoming an AI-facing operating layer for my own work. I can write from the command line, push drafts into Notes, upload images, adjust templates, regenerate ShivasNotes, and keep the website output deterministic. The AI is not directly hand-editing a website folder. It is working through Antsand, and Antsand produces the site.

This also connects to an earlier post I wrote on why I replaced QuickBooks with Antsand and why AI plus open source changes the software subscription game: Why I Replaced QuickBooks with Antsand. The point is not that every tool should be rebuilt from scratch. The point is that once AI can help maintain and improve open systems, the cost-benefit equation changes.

That same pattern is now spreading into the rest of my work. My video production is slowly moving into Linux. My writing pipeline is moving into Linux. My PCB design workflow is moving from old Windows-heavy tools toward KiCad. My mechanical design workflow is moving from Fusion/SolidWorks-style tools toward FreeCAD and STEP-based versioned geometry. My circuit simulation is moving toward ngspice, and eventually field solving with openEMS.

Why This Matters

The bottleneck in hardware is not only money. It is process reliability. If every PCB starts with hunting for symbols, guessing footprints, copying reference designs by hand, downloading random CAD models, and hoping the board solders correctly, then the workflow itself becomes the risk.

The Part That Still Makes Linux Hard

Even with all of this progress, I do not want to pretend Linux is frictionless. The Linux kernel and the operating system are not usually the problem. Vendor support is the problem.

My Blackmagic ATEM Mini video switcher is a good example. The official workflow is Windows and macOS. There are open-source alternatives, but I have not hardened them yet. That alone can force me back to my Windows machine for parts of video production.

The Stream Deck is another example. My folder organization and button layouts on Stream Deck are powerful. But again, the official experience is Windows and macOS. Elgato Camera Hub and the Elgato teleprompter may or may not work cleanly on Linux. That uncertainty matters when the goal is not to tinker forever, but to produce daily content reliably.

This is why I am not yet saying I am 100% Linux. I have already converted my old W530 to Linux. I bought a used ThinkPad T14 Gen 3 for around $600, and that is now full Linux and is the machine I use almost all the time. The next question is whether I convert my P15v to Linux too. I want to, but the video recording stack, ATEM Mini, Stream Deck, Elgato hardware, Thunderbolt dock, and driver support all need to be tested first.

That is the real Linux migration blocker: not whether Linux is powerful enough, but whether vendors care enough to support the hardware I already own.

AI changes this calculation. Open-source tools are powerful, but sometimes difficult to configure, connect, and remember. AI helps bridge that gap. It can inspect logs, write wrapper scripts, organize configuration, test command-line tools, document the workflow, and help me replace vendor-polished software with reproducible Linux-native systems. That does not erase the vendor support problem, but it makes the Linux path much more realistic.

The LinuxUtilities Layer

This is also why my LinuxUtilities work matters. A lot of Linux pain is not dramatic kernel work. It is small device and workflow friction repeated every day: audio routing, Bluetooth, clipboard recovery, window management, screenshots, local scripts, service checks, and command-line wrappers.

Those utilities are not glamorous, but they are how a workstation becomes dependable. When the mouse, keyboard, audio, clipboard, windows, or device state gets weird, I do not want to randomly click through settings for twenty minutes. I want scripts, logs, and repeatable recovery paths. That is exactly the kind of work AI can help harden because it can inspect commands, summarize failures, and turn fixes into reusable utilities.

The Content Engine

The content side is becoming part of the same system. The carousel generator is not a random design toy. It is a JSON-to-HTML-to-image pipeline for making technical posts repeatable. I can write a technical idea once, turn it into a ShivasNotes post, generate a carousel, and later turn the same topic into shorts or long-form video.

This is where Antsand has become much more interesting to me. Most of my blog writing and content workflow can now happen from the command line. I can draft an article in a local file, ask the AI to tighten the structure, push the HTML into Antsand Notes through the API, update the same note by ID, upload assets, regenerate the local or production ShivasNotes site, and review the result in the browser.

local draft file
→ Notes API
→ Antsand database
→ deterministic ShivasNotes generator
→ rendered blog post
→ carousel / shorts / video assets

The important part is that Antsand remains the interface boundary. The AI does not need to directly edit generated website files. It can work through the same content and deployment surfaces that I use: Notes, assets, tags, templates, and save/deploy actions. That makes the workflow much less fragile. The agent can help me write, edit, upload, tag, and regenerate, but the final website still comes from Antsand’s deterministic generation path.

That is why modern AI agents understand Antsand surprisingly well now. The system has enough structure for an agent to reason about it: there are Notes APIs, profile post APIs, upload APIs, generated HMVC templates, Sass layers, deployment actions, and local/prod boundaries. Instead of saying “make a website,” I can say “update note 5917, keep it a draft, add these tags, regenerate the local blog, and do not touch production.” That is a very different kind of control surface.

That is important because content is how I document the work while the work is happening. The goal is not just marketing. The goal is active recall, public documentation, and slow compounding. Antsand publishes the long-form post. The carousel kit turns it into scrollable learning content. The video workflow turns it into explanation. Linux ties the whole loop together.

This also means ShivasNotes is becoming a public lab notebook rather than just a blog. C Kernel Engine posts, quaternion explanations, flight-controller notes, PCB workflow notes, Linux migration notes, and carousel content all move through the same pipeline. I can write from the shell, generate the article, generate the carousel, and keep all of it tied back to the same source idea. That is the part I want to keep hardening.

The video pipeline is part of this too. I still use hardware like the ATEM Mini for recording, but the direction I want is Linux-native post-production: AI-assisted transcripts with Whisper, FFmpeg for repeatable cuts and conversions, scripts for asset organization, and Kdenlive for final human review. Long-form video does not need to start as a perfectly polished studio workflow. It can start as a hardened capture, transcript, edit, review, and publish loop.

C Kernel Engine Depends On Linux Too

C Kernel Engine is another reason this migration matters. It is heavily Linux-centered. The whole project is about turning model weights and computational graphs into generated C, compiled shared objects, and CPU-native execution. That workflow depends on compilers, shared libraries, build scripts, shell automation, profiling, and reproducible Linux execution.

That is not incidental. C Kernel Engine is a compiler-style infrastructure project. It belongs on Linux. The more my main workstation, content pipeline, development tools, and simulation stack live on Linux, the less context switching I have between the things I am trying to build.

This also ties directly into the way I think about long projects. I wrote about that separately inHardening Long Projects in the Age of AI.The thesis is similar here: do not just chase novelty. Harden the systems that keep compounding.

So I am building the boring layers first.

• Supplier truth: DigiKey and Mouser connect the digital inventory to the actual parts I ordered and physically own.
• Part intelligence: Octopart/Nexar can help resolve availability, alternates, lifecycle, and CAD-model sources.
• CAD assets: KiCad official libraries, SnapMagic, Ultra Librarian, Component Search Engine, and manufacturer datasheets become staged sources, not blindly trusted sources.
• Local authority: only reviewed symbols, footprints, and models move into my accepted library.
• Simulation: ngspice handles circuit-level behavior first; openEMS will handle field-solver work later for traces, coupling, antennas, and high-speed structures.

The PCB Workflow I Want

The ideal workflow is simple to describe, and I want as much of it as possible to be driven from the command line:

reference design
→ command-line BOM and schematic-intent extraction
→ command-line comparison against physical inventory
→ identify missing parts
→ resolve supplier candidates
→ fetch and stage CAD assets
→ create KiCad schematic
→ review symbols and footprints
→ route PCB
→ simulate where useful
→ fabricate
→ test
→ feed corrections back into the library

This is especially useful for reference designs from Nordic Semiconductor, NXP, Texas Instruments, and other vendors I work with often. These companies usually provide strong engineering material, but much of the ecosystem still assumes Altium, Windows-first workflows, or vendor-specific tooling. I want the same discipline in KiCad, under Linux, with a local component library that knows what I already own and can be queried from the shell.

This PCB workflow is still experimental. I am not claiming it is final or fabrication-safe yet. The current goal is to build the command-line pipeline: supplier inventory, part resolution, KiCad pending libraries, footprint review, SPICE seed models, and eventually better simulation checks. Generated symbols and footprints are review candidates, not trusted production assets.

What Is Working Now

The first useful layer is already working. DigiKey production API access is connected. Historical orders were imported into a local physical inventory. That inventory is now being organized into component folders: capacitors, resistors, inductors, IMUs, current sensors, connectors, switches, MCUs, and other categories.

For the passive components, I now have generated seed data:

• KiCad pending symbols and footprints for common R/C/L parts.
• SPICE seed models for ideal passive simulation.
• An ngspice RLC smoke test using actual parts from my inventory.

The word pending matters. Generated footprints are not accepted footprints. They are review candidates. Before anything goes to fabrication, the footprint needs to match a trusted KiCad official footprint, datasheet land pattern, or verified CAD provider model.

The Robotics And Engineering Stack

The reason Linux matters for Antshiv Robotics is that so many serious engineering tools already exist there. KiCad for PCB design. FreeCAD for mechanical geometry. ngspice and LTspice-style workflows for circuit simulation. openEMS for electromagnetic field solving. OpenFOAM for aerodynamics and prop wash. Octave and Python for numerical analysis. Bash for automation. ParaView for visualization.

What I want is not a pile of disconnected tools. I want a workflow where these tools talk to each other. PCB design should connect to circuit simulation. Circuit simulation should connect to component inventory. Mechanical design should connect to test rigs and propeller geometry. Aerodynamic simulation should connect to propeller and drone-body design. The full robotics stack should connect back to actual hardware: thrust stands, attitude test rigs, flight controllers, ESCs, cameras, sensors, and eventually ecological monitoring missions.

I am still early in this workflow. But the commercial equivalent of this toolchain can easily become absurdly expensive: PCB tools, mechanical CAD, field solvers, CFD, numerical computing, reporting tools, code generation tools, and data pipelines. If you tried to assemble that from commercial vendors, the license stack could become hundreds of thousands of dollars per year.

The open-source version has a different tradeoff. The tools are powerful, but the workflow is less polished. Commercial tools often put everything behind one interface. That convenience is real. But it also means you learn their interface, their license model, their file formats, their assumptions, and eventually their worldview. You become dependent on the tool, and sometimes you become a walking marketing agent for the tool.

MATLAB is the clearest example from engineering education. It dominates universities so thoroughly that many people feel strange using Octave, even when Octave is more than sufficient for a large fraction of the work. MATLAB can generate C code from MATLAB code. That is useful. But now with AI, I can often work from the math and my engineering intuition and generate the C code directly, review it, test it, and own it.

This is where AI changes the open-source equation. A lot of the value commercial tools provide is convenience, integration, examples, support, and workflow memory. AI reduces that gap. It can read logs, write glue scripts, explain APIs, generate C, help with math, inspect KiCad files, organize simulation outputs, and stitch tools together. It does not remove the need for engineering judgment, but it reduces the pain of building the workflow.

That is my hunch: CLI plus AI plus open-source engineering tools is going to keep getting stronger. It is not as polished as buying one commercial suite. But it is more transparent, more scriptable, more versionable, more inspectable, and much easier to bend into my actual robotics workflow.

As a concrete example, openEMS is now installed locally from source with the Circuit Toolbox and Python bindings. That means the field-solver path is no longer just theoretical. I can start building small electromagnetic simulation examples and gradually connect that work back to KiCad, FreeCAD, and the PCB/component library.

Why This Delays Buying More Hardware

I still need proper soldering and rework equipment. JBC tools, hot air, microscopes, and better electronics benches matter. But buying tools before hardening the digital process can just create a more expensive mess.

For now, the better move is to reduce uncertainty before money is spent:

• Organize the parts I already own.
• Move CAD and PCB workflows to Linux.
• Build repeatable KiCad library gates.
• Simulate simple circuits before building boards.
• Convert old CAD assets into STEP/FreeCAD-friendly workflows.
• Use AI to accelerate the boring review and organization work.

The Bigger Pattern

This is the same pattern as C Kernel Engine and Antsand. Build the system first. Harden the pipeline. Make the workflow deterministic enough that AI can help without turning everything into random output.

Antsand is the publishing and orchestration layer. LinuxUtilities is the workstation hardening layer. The carousel kit is the content generation layer. C Kernel Engine is the CPU-native AI infrastructure layer. KiCad and FreeCAD are the engineering layer. ngspice and openEMS are the simulation layer. DigiKey, Mouser, and Octopart are the component intelligence layer. AI sits across all of it, not as a magic replacement for engineering judgment, but as a multiplier for organizing, checking, connecting, and repeating the work.

That is the part that feels different now. I am not just learning Linux tools one by one. I am turning Linux into the workshop where the drone stack, C Kernel Engine, Antsand, PCB design, CAD, simulation, and content production can start reinforcing each other.

That is the workflow I want to harden.