Artificial Intelligence is rapidly moving beyond simple chatbots. Today’s users want AI systems that can remember context, understand workflows, connect with tools, and actually help in durlay-to-day productivity. This is where OpenHuman GitHub Repository enters the picture.
Built by TinyHumans AI, OpenHuman is an open-source “personal AI super intelligence” designed to act more like a persistent digital companion than a temporary chatbot. Unlike traditional AI tools that forget everything after each session, OpenHuman focuses heavily on memory, personalization, privacy, and deep integration with your digital life.

What is OpenHuman?

OpenHuman is a local-first AI assistant that combines:

• Long-term memory
• AI agent capabilities
• Tool integrations
• Voice interactions
• Desktop automation
• Personalized context understanding

The project positions itself as a private AI runtime that learns about you continuously and becomes smarter over time. According to the official repository, OpenHuman is designed to “integrate with you in your daily life.”
What makes the project especially interesting is its ambition to move AI from “question-answering” into a real-world personal operating system for productivity.

Key Features of OpenHuman

1. Massive Memory System

One of OpenHuman’s biggest highlights is its memory architecture.
The platform claims support for up to 1 billion tokens of memory, allowing the AI to remember emails, documents, notes, workflows, meetings, and user preferences over time.
Instead of relying only on temporary chat history, OpenHuman creates a structured memory tree that continuously evolves.
This allows the assistant to:

• Recall previous conversations
• Understand recurring tasks
• Maintain long-term user context
• Learn workflows automatically

2. 118+ Integrations
OpenHuman supports over 118 third-party integrations including:

• Gmail
• GitHub
• Slack
• Notion
• Google Calendar
• Stripe
• Jira
• Linear
• Google Drive

and many more.

The integrations work through OAuth connections and expose tools directly to the AI assistant.
This means the assistant can:

• Read schedules
• Understand projects
• Summarize updates
• Organize workflows
• Provide proactive suggestions

3. Local-First Privacy
Privacy is becoming one of the most important discussions in AI.
OpenHuman focuses heavily on local execution and on-device memory storage. According to project documentation, data is stored locally using SQLite and can also sync into an Obsidian-compatible markdown vault.
This approach gives users more ownership over:

• Personal data
• AI memory
• Documents
• Workflows

Unlike cloud-only AI platforms, OpenHuman aims to reduce dependency on external servers.

4. Obsidian-Style Knowledge Base
Another standout feature is its Obsidian-compatible memory vault.
The system converts connected information into markdown knowledge chunks that can be browsed, edited, and organized like a personal wiki.
This creates a fascinating bridge between:

• AI assistants
• Personal knowledge management
• Second-brain systems

For users already working with tools like Obsidian, this integration can be extremely valuable.

5. Voice and Desktop Presence
OpenHuman is not just a text chatbot.
The project includes:

• Voice interactions
• Speech-to-text
• Text-to-speech
• Animated desktop mascot
• Background AI processing

The assistant is designed to feel more “alive” and persistent rather than appearing only when manually opened.

Technical Stack

OpenHuman uses a modern desktop architecture built with:

• Rust
• React
• Tauri
• TypeScript
• QuickJS sandbox runtime

The main application combines a Rust-powered backend with a React-based UI, while integrations and “skills” run in isolated environments.

This architecture provides:

• Better performance
• Lower memory usage
• Cross-platform compatibility
• Stronger security isolation

Why OpenHuman is Gaining Attention

OpenHuman has recently gained significant traction in the open-source AI community.
Several reasons explain this momentum:

AI Fatigue with Traditional Chatbots

Many users are frustrated by AI systems that:

• Forget context
• Require repeated prompting
• Lack personalization
• Depend heavily on cloud services

OpenHuman directly targets these pain points.

Rise of AI Agents

The industry is rapidly shifting from static chatbots toward AI agents capable of:

• Taking actions
• Managing workflows
• Using tools
• Automating tasks

OpenHuman positions itself as part of this “agentic AI” movement.

Local AI Movement

There is increasing interest in:

• Offline AI
• Private AI
• Self-hosted AI systems
• Local LLMs

OpenHuman aligns strongly with this trend by enabling local execution and persistent user-owned memory.

Current Limitations

Despite the excitement, OpenHuman is still in early beta.
The developers openly mention:

• Rough edges
• Ongoing development
• Potential bugs
• Frequent updates

Users should expect instability while the project matures.
Additionally, because the platform handles sensitive data and deep integrations, security and permission management will remain critical areas to watch.

The Bigger Vision Behind OpenHuman

OpenHuman represents a broader shift happening in AI.
Instead of AI being:

• A website
• A chatbot
• A prompt box

the future may look more like:

• Persistent AI companions
• Personal operating systems
• Digital memory assistants
• Autonomous workflow agents

Projects like OpenHuman are exploring what happens when AI becomes deeply integrated into daily life rather than isolated to short conversations.

Final Thoughts

OpenHuman is one of the most ambitious open-source AI assistant projects currently gaining momentum in the developer ecosystem.
Its combination of:

• Long-term memory
• Local-first privacy
• Deep integrations
• Personalized workflows
• Open-source architecture

makes it stand out in an increasingly crowded AI landscape.
While the project is still early in development, it offers a compelling glimpse into the future of personal AI systems.
For developers, productivity enthusiasts, and AI researchers, OpenHuman is definitely a project worth watching.

Useful Links:

OpenHuman GitHub Repository

OpenHuman Official Website

OpenHuman Documentation

TinyHumans AI GitHub Organization

My Linkedin

Component-Driven Development assumed a render model that signal-based Angular has quietly left behind. The tooling has not caught up, and I am not sure simply patching it will be enough.

The moment that made me write this

I was building ng-prism, an Angular-native component showcase tool I maintain, and I needed to update a component’s inputs from a controls panel. The naive version looked roughly like this:

const ref = vcr.createComponent(ButtonComponent);
const instance = ref.instance;

instance.variant = 'primary';
instance.label  = 'Save';
ref.changeDetectorRef.detectChanges();

It works on a pre-signal component. On a signal-based component it quietly breaks the component. variant and label are no longer plain properties. They are InputSignal objects, callable as variant(). Angular stores the InputSignal as a plain class field; there is no defineProperty setter or proxy to intercept the write. So the assignment just overwrites the field reference with a string, and Angular never finds out. The next render then blows up the first time the template evaluates variant(), because variant is no longer a function. I verified this against @angular/core 21.2.0: createInputSignal() returns a plain function with a [SIGNAL] symbol attached, no setter trap in sight.

The fix is one line:

ref.setInput('variant', 'primary');
ref.setInput('label',   'Save');

That is the version that lives in ng-prism today, in the renderer effect that drives every showcase:

// packages/ng-prism/src/app/renderer/prism-renderer.component.ts
// Simplified; real version also handles content projection and unknown-input warnings.
effect(() => {
  const inputs = this.rendererService.inputValues();
  const ref    = this.componentRef;
  if (!ref) return;

  performance.mark('prism:rerender:start');
  for (const [key, value] of Object.entries(inputs)) {
    ref.setInput(key, value);
  }
  // setInput() already marks dirty and schedules CD. The explicit
  // detectChanges() here forces it to run synchronously so the
  // performance.mark below wraps the actual render, not just the
  // dirty-marking. Also keeps timings predictable under zoneless.
  ref.changeDetectorRef.detectChanges();
  performance.mark('prism:rerender:end');
});

This is a tiny detail, but it is the symptom of a much bigger thing. The way Component-Driven Development (CDD) thinks about a component (props in, render out, args table on the side) was modelled on a world where component inputs were plain properties. That world is gone in Angular. And once you stop assuming it, a lot of the tooling we have built over the last decade starts to look like it is solving the wrong problem.

The implicit model behind classic CDD

Look at what almost every CDD tool, Storybook included, has agreed on for years:

1. A component is a pure-ish function of its inputs.
2. Inputs are configured as a flat dictionary, the “args”.
3. A “story” is a specific value of that dictionary.
4. Changing args triggers a discrete re-render cycle.
5. Addons (a11y, viewport, knobs, controls) hook into that cycle.

In the pre-Hooks era this was the right abstraction. React class components had setState. Angular had @Input() decorators and ngOnChanges. Vue had options API. All of them had a clear, discrete moment where a property got assigned, the framework noticed, and the component re-rendered top-down. Args tables map onto that perfectly. Whatever knob you turn becomes a property assignment, which becomes an ngOnChanges call, which becomes a render.

This is also why Storybook’s args model felt so natural for so long. Args are properties. Properties are state. State drives render. Story = scenario = property snapshot.

It was a beautiful, simple model. It is also, for Angular today, the wrong abstraction.

What Signals actually changed

I do not want to retread the “signals are great” territory. What matters for CDD is more specific.

Inputs are no longer properties. An InputSignal is a callable getter. From outside the component, the only correct way to push a value into it is ComponentRef.setInput(name, value). There is no property to assign anymore. Tools that still build their abstractions on “assign this prop” are not even wrong yet, they just produce broken components.

Components are nodes in a reactive graph, not pure functions of inputs. Half of a real-world signal-based component is computed() derived state. Those derived signals are part of the component’s behaviour. They are not inputs, but they are also not opaque internal state. An args table cannot represent them. A story shapes inputs, not derived state.

Lifecycle work is increasingly split between explicit hooks and reactive subscriptions. ngOnInit and ngOnDestroy still exist and are still idiomatic for a lot of cases (subscriptions, teardown, one-shot setup). What has changed is that ngOnChanges is largely irrelevant for signal inputs, and a growing share of the work that used to live in lifecycle hooks now lives inside effect() or computed() that is read by the template. The places where work happens have multiplied, and a chunk of it fires on a much finer-grained schedule than mount → change → destroy. CDD tools that visualise lifecycle as those three states are visualising a real but shrinking slice of what the component actually does.

Re-renders are continuous, not cycle-based. Zoneless Angular still has ApplicationRef.tick() and a ChangeDetectionScheduler. What is gone is the implicit tick driven by zone.js intercepting every async operation. In a zoneless app, change detection runs because the scheduler decided to run it, which in practice is because a signal flagged a view dirty. From the outside that looks less like a single render cycle and more like a graph of signals notifying their dependents at fine granularity. An addon that says “re-run my check on each render cycle” has no clean event to listen to, because there is no single render cycle visible at the public surface of the component.

The pre-signal mental model is not catastrophically wrong. It is just lossy. And every layer of CDD tooling pays the price of that loss somewhere.

Where the tooling lags, concretely

Three examples I have hit while building ng-prism.

1. Controls and args still treat inputs as a flat property bag.

The Storybook args object and ng-prism’s own variant config both look like this:

{ variant: 'primary', label: 'Save', disabled: false }

That is fine as a starting state. It is wrong as a model of how the component actually consumes its inputs. A signal-based input has a default expression, can be required, can be tied through computed() into other state, and can be read multiple times per render. None of that is in the args object. The args object is a snapshot of a tree it cannot see.

2. A11y, perf, and visual-diff addons assume “render happened, now check”.

axe-core, layout measurements, screenshot capture: they all rely on a moment where the DOM has settled and you can inspect it. Angular does give you some primitives here. afterNextRender() fires once after the next render. afterRender() fires after every render. ApplicationRef.isStable exposes a stable-state observable. None of those quite match what an a11y or visual-diff addon actually wants, which is closer to “the reactive graph has been quiet for N milliseconds across multiple microtasks, and I am now safe to walk the DOM”. That concept does not exist as a framework primitive. So you debounce, you wait for animation frames, you hope. In ng-prism the built-in a11y audit runs after a 500ms debounce on signal changes (A11yAuditService.scheduleAudit, default debounceMs = 500), which works in practice but feels like a workaround. I am not sure a true “graph is quiescent” signal even makes sense in a system designed to update continuously.

3. The “scenario” unit is too coarse.

A Storybook story is one set of args. A ng-prism variant is one set of input values. Neither can express “this component embedded in a parent that emits a signal stream over time”. The interesting bug in a signal-based component is rarely the static case. It is the transition. It is the moment when an upstream computed() updates twice in the same microtask and your effect runs once instead of twice. You cannot represent that with { variant: 'primary' }.

What I tried in ng-prism, honestly

ng-prism started life with the same implicit model as Storybook. Components have inputs. Inputs have values. Variants are named tuples of input values. The decorator looks similar:

@Showcase({
  title: 'Button',
  variants: [
    { name: 'Primary', inputs: { variant: 'primary', label: 'Save' } },
    { name: 'Danger',  inputs: { variant: 'danger', disabled: true } },
  ],
})

What ng-prism does that I think is on the right track:

• Uses setInput() for every input push, never property assignment. So at least the signal contract is respected. This is the absolute floor and a surprising number of Angular-adjacent tools still get it wrong.
• Drives the rendering loop with effect() on a signal of input values, not with a render-cycle event. The renderer reacts to whatever upstream signal happens to change.
• Treats the scanner as a build-time concern. Signal inputs are recognised via the TypeScript Compiler API at build time, so the runtime never has to read decorator metadata. The decorator itself is literally a no-op, just a marker.
• Supports zoneless via an opt-in flag in the ng add schematic (--zoneless), which wires up provideZonelessChangeDetection() and drops zone.js from polyfills. The default still ships with zone.js, but nothing in the renderer depends on an implicit zone tick; change detection runs because something signal-shaped told it to.

What ng-prism does not solve yet, and where I think the whole category is still stuck:

• The variant model is still a flat input snapshot. I cannot describe a component as “embedded in a parent that pushes this signal stream over 2 seconds”.
• computed() derived state is invisible in the UI. You see the inputs you set. You do not see the graph that hangs off them. For some components, that graph is the interesting part.
• The a11y, perf, and box-model panels all hook into renderer output the way an old addon would. They debounce. They do not subscribe to the actual reactive graph the component is part of.
• The “code snippet” feature generates a template string from input values. It cannot show how the component would behave in a parent where one of those inputs is itself a signal.

I am being deliberate about this in the docs. I do not want ng-prism to claim a level of insight into signal-based components that it does not yet deliver.

What I think the next generation should look like

This is the speculative part, so take it as opinion.

I think the unit of CDD will stop being “the component with these props” and start being “the component embedded in a reactive context”. A scenario will look more like a tiny fixture: this component, mounted under this parent, with these signal sources feeding it, over time. Closer to a Playwright scenario than a Storybook story.

I think tooling will need to render the reactive graph, not just the visual output. For a serious component, the dependency graph between inputs, computed(), and effect() is the documentation. We render the box and the controls. We should also be able to render the graph.

I think the addon model needs to flip. Instead of hooking into a render lifecycle that no longer exists, addons should subscribe to specific signals. Visual diff subscribes to the renderedElement signal. A11y subscribes to the same. Perf subscribes to a “graph quiescent” signal that the framework would have to expose. None of this lives in Storybook’s current architecture, and bolting it on is not obviously the right answer.

And I think “args” as a UI metaphor has run its course. A signal-based component is not configured by setting properties. It is wired up. The control surface should reflect that.

Closing

I am not arguing that Storybook is bad, or that the people maintaining it have missed something obvious. They built the right tool for the framework world of 2018, and that tool became a standard. Standards lag by definition. That is fine.

What I am arguing is that the abstraction is starting to leak in ways that matter. Signal-based Angular is a different kind of component runtime, not a faster version of the old one, and the surface area that CDD tooling was designed against has changed underneath it.

I am building ng-prism partly to test that hypothesis in code, not just in prose. I am also fully prepared to find out that I am wrong, that an args table plus setInput() plus a debounce is good enough for 95% of cases, and that the rest is academic. Possible. But I do not think it is, and I would rather find out by building than by predicting.

If you have hit the same kind of friction, or you have a counter-example where the args model still maps cleanly onto a signal-heavy component, I would genuinely like to hear it. That is more useful than another “signals are great” thread.

ng-prism is open source on GitHub. Feedback and counter-examples especially welcome.

Qwen 3.6 enable_thinking — The MoE Pitfall That Broke My Agent JSON Parsing

I lost two hours last week to a Qwen 3.6 quirk that doesn’t show up in any quickstart guide. My agent kept returning malformed JSON. Logs showed the model output started with <think> and a 200-token reasoning monologue before the actual JSON I asked for. Parser exploded every time.

The fix is one keyword argument. The frustration is that nothing in the obvious places — model card, MLX docs, generic chat template examples — tells you about it.

If you’re running Qwen 3.6 MoE for an agent setup and your structured outputs are broken, read on.

The symptom

I had a tool-calling loop that asked Qwen to emit JSON. Something like:

prompt = "Return a JSON object with keys 'action' and 'target'."
response = generate(model, tokenizer, prompt)
data = json.loads(response)

Worked fine with Qwen 2.5. Broke immediately with Qwen 3.6. The output looked like:

<think>
The user wants a JSON object. I need to think about what action and target make sense.
Let me consider the context...
[200 more tokens of reasoning]
</think>

{"action": "search", "target": "weather"}

JSON parser saw the <think> block as garbage, threw a JSONDecodeError. Easy enough to spot once I logged the raw output. But it took me a while to realize this was a model feature, not a prompt problem.

What’s actually happening

Qwen 3.6 ships with reasoning mode default-on. The chat template injects markers — <think> and </think> — and the model is trained to fill them with its chain-of-thought before producing the user-facing answer. For interactive chat, this is sometimes useful: you can show or hide the reasoning to a user, and the reasoning content does measurably improve answer quality on hard problems.

For an agent loop that parses structured output, it’s silently destructive. Every response starts with hundreds of tokens you have to strip before you can use the actual answer. And worse, the reasoning length is unpredictable — sometimes 50 tokens, sometimes 800 — so your max_tokens budget gets eaten by thinking instead of output. On a memory-tight Mac running a 35B model already, those wasted tokens also fragment Metal cache faster — separate problem but they compound. (I wrote up the memory side in my MLX memory safety checklist if that’s the angle you hit first.)

The fix

In apply_chat_template, pass enable_thinking=False:

messages = [{"role": "user", "content": prompt}]
text = tokenizer.apply_chat_template(
    messages,
    tokenize=False,
    add_generation_prompt=True,
    enable_thinking=False  # <-- this
)
response = generate(model, tokenizer, text)

That’s it. No <think> blocks, no reasoning preamble, just the answer. JSON parses cleanly. max_tokens budget goes to the actual response.

Where the flag has to go

This took me embarrassingly long to figure out. The flag belongs at template apply time, not at generation time. You can’t pass it to model.generate() and have it work. You can’t set it as a tokenizer kwarg at load time. It only has effect inside apply_chat_template.

I tried these wrong things first:

# These do nothing — flag is ignored
generate(model, tokenizer, prompt, enable_thinking=False)
tokenizer = AutoTokenizer.from_pretrained(model_id, enable_thinking=False)
model.generate(prompt, enable_thinking=False)

If you’ve inherited a codebase where chat formatting is wrapped in a custom function, the wrapper probably calls apply_chat_template somewhere. That’s the spot. Patch it there.

When you actually want thinking on

For interactive chat where a user reads the response, leaving enable_thinking=True (the default) usually helps. The model is genuinely smarter on multi-step reasoning when it gets to think out loud. Math problems, code debugging, multi-constraint planning — all measurably better with thinking on.

So the rule isn’t “always disable.” It’s “disable for any path where the output gets machine-parsed, kept on for any path where a human reads it.”

In my own setup (a multi-agent local stack on M1 Max — full hardware notes in the 19 GB memory compression writeup), I split into two generate functions:

def generate_for_agent(messages, max_tokens=512):
    text = tokenizer.apply_chat_template(
        messages, tokenize=False, add_generation_prompt=True,
        enable_thinking=False  # parser-safe
    )
    return generate(model, tokenizer, text, max_tokens=max_tokens)

def generate_for_chat(messages, max_tokens=2000):
    text = tokenizer.apply_chat_template(
        messages, tokenize=False, add_generation_prompt=True,
        enable_thinking=True  # quality boost for chat
    )
    return generate(model, tokenizer, text, max_tokens=max_tokens)

Two functions, two contexts. Same model, same tokenizer, different chat template flag. Clean separation.

Why the docs don’t surface this

This is my speculation, not authoritative — but here’s what I think happened. Qwen 3.6 launched as Alibaba’s flagship reasoning model. The whole pitch is “thinks before it answers.” Disabling that flag in the quickstart would undercut the marketing of the feature itself. So the docs assume you want thinking on by default, and the flag is buried in API reference, not the first-page tutorial.

If your use case is agent JSON, you’ll find this gotcha on day one. If your use case is human chat, you might never need to touch the flag and won’t see why anyone would.

It’s a real-world case where the default optimizes for the most demo-worthy path, not the most common production path.

Verification

After patching, you can verify the flag took effect by inspecting the rendered template before generation:

text = tokenizer.apply_chat_template(
    messages, tokenize=False, add_generation_prompt=True,
    enable_thinking=False
)
print(text[-200:])  # tail of the prompt

You should see the assistant generation prompt with no <think> marker. If you see <think> in the tail, the flag didn’t apply — most likely because you’re calling a wrapper that doesn’t pass it through.

You can also check by inspecting the first 100 tokens of any response. Reasoning-on output starts with <think>. Reasoning-off output starts with the actual answer.

What this isn’t

This is specifically Qwen 3.6 behavior. Earlier Qwen versions (2.5 and below) don’t have the enable_thinking flag because reasoning mode wasn’t a feature yet. Other reasoning-mode models (DeepSeek-R1, the o1 family on the OpenAI API) have similar dynamics but different flags or modes — check their respective chat templates.

If your output isn’t parsable but doesn’t have <think> blocks, the cause is somewhere else. Common alternatives I’ve hit:

• Trailing whitespace or newlines in the response — strip before parsing
• Markdown code-fence wrapping around the JSON — strip json ` and `
• Model adding explanatory text before/after the JSON — tighten the system prompt with explicit “no preamble, no explanation”

The <think> block fix only solves the reasoning-leak case. The other cases need other fixes.

The smaller lesson

When a new model breaks an existing pipeline silently, the bug is usually in the chat template, not the generate call. The template is the interface between your code and the model’s expectations. Most upstream API changes happen there.

For Qwen 3.6, the gotcha is enable_thinking. For the next model in two months, it’ll be something else. The diagnostic habit — log the rendered template, not just the response — saves hours over the year.

If you’ve hit a different Qwen 3.6 surprise that nobody flags, I’d genuinely like to know. Reply on the post.

Come along for the ride — see me fall or thrive, whichever comes first.

*# *

Choosing how to install Linux is one of the most foundational decisions a system administrator, developer, or enthusiast will make. The installation method directly influences performance, isolation, hardware access, ease of experimentation, and long-term maintainability. The three primary approaches—bare metal, virtual machine (VM), and dual boot—each solve different problems and come with distinct trade-offs in architecture, workflow, and operational behavior.

This chapter explores each method in depth, from the underlying system architecture to practical implementation, real-world engineering considerations, and advanced usage patterns.

Understanding the Installation Landscape

At its core, installing Linux means placing a functional kernel, init system (most commonly systemd), root filesystem, and necessary userspace tools onto a storage medium that the bootloader can locate and execute.

The Linux kernel is a monolithic kernel that interacts directly with hardware through drivers compiled either statically or as loadable kernel modules. The bootloader (typically GRUB) is responsible for loading the kernel image (vmlinuz), initial ramdisk (initrd or initramfs), and passing kernel parameters.

Each installation method changes where and how this stack executes:

• Bare metal runs the kernel directly on physical CPU, memory, and devices.
• Virtual machine runs the kernel inside a hypervisor-managed environment.
• Dual boot shares physical hardware between two operating systems.

Bare Metal Installation: Maximum Performance and Direct Hardware Control

Bare metal installation means Linux runs natively on the physical hardware without any abstraction layer between the kernel and the CPU, memory, storage controllers, or peripherals.

Why Choose Bare Metal?

Bare metal delivers the highest possible performance because there is zero hypervisor overhead. All CPU cycles, memory bandwidth, and I/O operations go directly to your Linux environment. This approach is preferred for production servers, high-performance computing, gaming desktops, audio/video workstations, and any workload where latency or throughput is critical.

Hardware Preparation and UEFI vs BIOS

Modern systems use UEFI (Unified Extensible Firmware Interface) with GPT partitioning. Legacy systems may still use BIOS with MBR. During installation, you must decide on an EFI System Partition (ESP) formatted as FAT32 (typically 512 MiB) mounted at /boot/efi.

A recommended bare metal partition layout for a production system might look like this:

/dev/nvme0n1p1     512M     FAT32     /boot/efi     (ESP)
/dev/nvme0n1p2     1G       ext4      /boot
/dev/nvme0n1p3     remaining space    LVM physical volume

LVM (Logical Volume Manager) is strongly recommended because it allows online resizing of logical volumes without downtime.

Step-by-Step Bare Metal Installation Process

1. Create bootable media using dd, Rufus, or Ventoy.
2. Boot from the media and enter the live environment.
3. Partition disks using gdisk, fdisk, or the distribution installer.
4. Format partitions (mkfs.ext4, mkfs.fat, etc.).
5. Mount the target filesystem hierarchy under /mnt.
6. Use debootstrap, pacstrap, or the graphical installer to populate the root filesystem.
7. Generate fstab, chroot into the new system, install the bootloader, and configure networking.
8. Reboot and remove installation media.

Advanced Considerations

On bare metal, you have full control over kernel parameters passed via GRUB (quiet splash, mitigations=off, iommu=pt). You can compile a custom kernel tailored to your hardware, enable specific CPU features (AVX512, huge pages), and optimize I/O schedulers (mq-deadline, bfq, or none for NVMe).

Limitations: No easy rollback. Hardware failures affect the entire system. Testing new distributions requires physical hardware or reinstallation.

Virtual Machine Installation: Isolation, Flexibility, and Rapid Experimentation

Virtual machines run Linux inside a hypervisor such as KVM/QEMU, VirtualBox, VMware, or Hyper-V. The hypervisor presents virtualized hardware (vCPU, vRAM, virtio devices) to the guest.

Architecture of Modern Virtualization

KVM (Kernel-based Virtual Machine) turns the Linux kernel into a hypervisor by loading the kvm and kvm-intel/kvm-amd modules. QEMU provides device emulation, while virtio drivers deliver near-native performance for block, network, and graphics devices.

libvirt acts as a management layer, providing a unified API for creating, starting, and monitoring virtual machines.

Creating a High-Performance Linux VM

Here is a complete example using virt-install (recommended for production-grade VMs):

virt-install 
  --name ubuntu-server-24 
  --ram 8192 
  --vcpus 8 
  --cpu host-passthrough 
  --disk path=/var/lib/libvirt/images/ubuntu24.qcow2,size=80,format=qcow2,bus=virtio 
  --network network=default,model=virtio 
  --graphics none 
  --console pty,target_type=serial 
  --location https://releases.ubuntu.com/24.04/ubuntu-24.04-live-server-amd64.iso 
  --extra-args 'console=ttyS0,115200n8'

Key options explained:

• --cpu host-passthrough: Exposes the full host CPU capabilities to the guest for maximum performance.
• virtio drivers: Paravirtualized devices that bypass much of the emulation overhead.
• qcow2 format: Supports snapshots, compression, and thin provisioning.

Advanced VM Techniques

• PCI passthrough: Assign physical GPUs, NICs, or storage controllers directly to the VM using VFIO.
• Nested virtualization: Run VMs inside VMs (useful for testing Kubernetes clusters).
• Live migration: Move running VMs between hosts with zero downtime.

Advantages: Snapshots, easy cloning, hardware independence, and the ability to run multiple distributions simultaneously.

Limitations: Slight performance overhead (typically 2-10% for CPU-bound tasks, higher for I/O without virtio). Resource contention on the host.

Dual Boot: Sharing Physical Hardware Between Operating Systems

Dual boot allows both Linux and another OS (usually Windows) to coexist on the same physical machine, with the bootloader presenting a choice at startup.

Bootloader Architecture in Dual Boot

GRUB is installed to the EFI System Partition and configured to detect other operating systems via os-prober. The chainloading mechanism works as follows:

1. UEFI firmware loads GRUB.efi.
2. GRUB reads its configuration (/boot/grub/grub.cfg).
3. Menu is displayed with entries for Linux and Windows.
4. Selecting Windows chainloads the Windows Boot Manager.

Safe Dual Boot Installation Strategy

Always install Windows first. Windows will claim the entire disk and create its own partitions (EFI, MSR, Windows, Recovery). Then:

1. Shrink the Windows partition from within Windows using Disk Management or diskpart.
2. Boot from Linux media.
3. Install Linux into the unallocated space.
4. Let the Linux installer install GRUB to the EFI partition (it will automatically detect Windows).
5. Update GRUB configuration: sudo update-grub.

Common Challenges and Solutions

• Fast Startup in Windows can leave NTFS partitions in an inconsistent state. Disable it.
• Time synchronization: Windows uses local time, Linux uses UTC. Set Linux to use local time or Windows to use UTC.
• Secure Boot: Sign your custom kernels or use distribution-provided signed bootloaders.
• Shared data partition: Create an NTFS or exFAT partition accessible by both systems.

Advantages: Native performance for both OSes, access to hardware-specific applications.

Limitations: Risk of bootloader corruption, difficulty in resizing partitions later, and inability to run both OSes simultaneously.

Choosing the Right Method: Decision Framework

Consider these factors when deciding:

• Performance needs: Bare metal for maximum speed, VM for acceptable performance with isolation.
• Experimentation frequency: VM wins for rapid testing.
• Hardware availability: Dual boot or bare metal when you have dedicated machines.
• Production requirements: Bare metal or Type-1 hypervisor (KVM) for servers.
• Development workflow: Many engineers maintain a bare metal workstation for daily work and multiple VMs for isolated testing environments.

Best practice: Start with a virtual machine to learn safely, move to dual boot for daily driver usage, and deploy to bare metal for production workloads.

Practical Engineering Workflows

Professional Linux users often combine methods. A common setup includes:

• Bare metal host running KVM + libvirt.
• Multiple specialized VMs (development, testing, CI/CD).
• Physical dual-boot machine for graphics-intensive work.
• Cloud instances for additional capacity.

This hybrid approach provides both performance and flexibility.

IMAGE DIAGRAM PROMPT

Create a highly detailed, educational diagram on a completely white background in the realistic style of handwritten notes on a professional engineering whiteboard. Use red ink for the main title “Linux Installation Methods: Bare Metal vs VM vs Dual Boot” and all major section subtitles. Use black ink for all explanatory text, labels, arrows, and technical details. The layout should resemble a comprehensive whiteboard explanation with neatly aligned sections, clear flowcharts, and connected components.

Divide the diagram into three main columns: Bare Metal (left), Virtual Machine (center), and Dual Boot (right). For each method, include:

• Architecture stack (Firmware → Bootloader → Kernel → Userspace) with icons.
• Key components and data flow arrows.
• Performance indicators (CPU, I/O, overhead percentages).
• Recommended use cases in boxes.
• Partition layouts shown as disk diagrams.
• Advantages and limitations in separate callout boxes.
• Central comparison table connecting all three methods.
• Workflow arrows showing installation steps for each.
• Small illustrations of physical server, hypervisor layer, and dual-boot menu.

Make everything highly detailed, technically accurate, and easy to read with proper spacing, clear handwriting simulation, labeled arrows explaining relationships (e.g., “virtio drivers reduce overhead”), and professional engineering aesthetics. Ensure high visual clarity with no clutter while packing substantial educational information.

To use the Claude API by Anthropic, you need to provide your government-issued photo ID and a live selfie. Yes, you read that correctly.

I genuinely thought this was satire when I first saw it. It’s not.

Why This Matters

Reports have surfaced that Claude’s API access may soon require government-issued photo identification and a real-time selfie for verification. Not for enterprise contracts. Not for classified data. For API access.

Developers immediately reacted with strong emotions. From disbelief to “I knew it wouldn’t work,” the LocalLLaMA community had valid points. Hard to argue with them.

The Privacy Red Line

There’s a difference between “sign up with an email” and “hand over your passport.” One is friction. The other is a fundamentally different relationship between you and a tool.

Think about what this means in practice. Every prompt you send is now tied to your verified legal identity. Every weird experiment, every edgy test case, every half-baked prototype — all of it linked to your face and your government ID.

I don’t care how good Claude is. That’s a privacy red line for a lot of devs. 🚩

Local Models Aren’t a Compromise Anymore

Here’s the thing that makes this story bigger than one company’s policy. Local inference has gotten really good.

One year ago, if you wanted to run models locally, you had to be ready to make incredible sacrifices when it comes to quality. That difference is not even as pronounced anymore. Open weight releases like Llama 3 and Qwen are sort of… wildly competitive for most of the developer’s work. Programming assistance, summarization, data extraction – all these things, you run them locally and they just… do it.

→ No identity verification
→ No usage logging by a third party
→ No policy changes that retroactively change your relationship with the tool
→ Your data stays on your hardware, period

The hardware story has improved too. You don’t need a server rack. A decent GPU and some patience gets you surprisingly far.

Every Requirement Is Free Marketing

This is the aspect that cloud AI providers often fail to understand. Every new hoop they make developers jump through pushes another cohort toward self-hosted alternatives.

API rate limits pushed people to explore local options. Content filters that blocked legitimate use cases pushed more. And now biometric identity verification is going to push the biggest wave yet.

Each restriction is essentially a press release for the local LLM ecosystem. You couldn’t buy better marketing if you tried. 😅

I’m not saying cloud AI is dead. Managed APIs still make sense for large-scale production workloads for many teams. But individual developers? Side projects? Anything where you value autonomy over convenience?

The situation has changed significantly.

What This Really Comes Down To

Cloud AI providers are creating isolated environments. They are entitled to do so. But developers have always routed around gatekeepers when the friction gets high enough.

The trend towards identity verification is a really big tell in terms of how those companies view their relationship with customers. They want to know exactly who is using their models and exactly what they’re using them for. That’s a business decision, not a safety one.

Local models provide an alternative proposition. You trade some convenience and peak capability for ownership. Control of your data, your process, and your reputation. For a growing number of developers, that trade is looking better every month.

The open-weight community has momentum. The tools are maturing. And cloud providers keep handing them new reasons to exist. 🏔️

Here’s my question for you: Where’s your red line? What would a cloud AI provider have to require before you’d invest the time to run models locally?

A few days ago, a devops engineer posted on r/devops:

“MCP servers just showed up in our infrastructure and I genuinely have no idea how to secure them, anyone been through this?”

Filesystem access, shell permissions, database connectors – all callable by agents without human approval. At the time I’m writing this, the thread has 76 upvotes and 39 comments from fellow engineers improvising solutions: “separate by blast radius,” “don’t mix list_files and execute_shell in one server,” “three security surfaces, not one.”

They’re all describing the same thing. They just don’t have the words for it yet.

The patterns they are rediscovering have been formalized in Domain-Driven Design (DDD), by Eric Evans.

In his book, Eric introduced concepts like Bounded Contexts and Anti-Corruption Layers, which gave us the vocabulary we’ve been using for system boundaries ever since. They helped us survive the microservices transition, and they apply directly to the architectural problems AI systems are creating right now.

We made the same mistakes a decade ago

In the 2010s, many teams adopted microservices without understanding what made them work. They took monoliths, split them apart, and called the pieces “services.” More often than not, the result was distributed monoliths – all the operational complexity of distribution with none of the architectural benefits of real, well-defined boundaries.

The correction took years. We learned (painfully) that a microservice boundary isn’t where you split the code. It’s where you split the mental model you have of the application. A payment service and a user service don’t just live in different containers – they have different vocabularies, different invariants, different reasons to change.

And the same mistake is happening again, this time with MCP servers. We wrap existing REST APIs one-to-one and call it AI integration. David Soria Parra, one of the creators of MCP, said “it’s a bit cringe, it just results in horrible things” at AI Engineer World’s Fair 2025. The Thoughtworks Technology Radar placed “MCP by default” as a Caution. And if you dive into the argument they make, they’re both saying the same thing: we’re building distributed monoliths again.

But the correction doesn’t have to take years this time. The vocabulary already exists – and has been battle-tested for more than 20 years.

Bounded Contexts: one server, one model, one language

A Bounded Context defines where a particular (data or object) model is valid. Inside the boundary, terms have precise meanings: a “transaction” in the finance context means money changing hands, a “transaction” in the booking context means a reservation. Inside each boundary lives one language and one set of rules. Across boundaries, you expect translation.

And MCP is particularly interesting from this angle: the protocol already enforces bounded contexts at the topology level.

MCP’s architecture uses a one-client-per-server model. The host spawns a separate client for each MCP server, and each client talks to exactly one server. An MCP server for your database cannot accidentally leak data to an MCP server for your file system. Unlike microservices, where any service can trivially call any other over the network, an MCP server has no protocol-level way to reach another server’s tools. You have to deliberately build that bridge. Cross-boundary coupling becomes visible and intentional rather than accidental.

But only if you design your servers as bounded contexts.

The failure mode is an MCP server that exposes everything, including filesystem access, shell execution, and database connectors in a single server. That’s three separate concerns crammed into one boundary – the equivalent of a microservice that owns users, payments, and notifications.

The commenter on Reddit who wrote “don’t mix list_files and execute_shell in one server” was actually designing context boundaries, even if he didn’t know the term.

Anti-Corruption Layers: separating the tools from domain logic

An Anti-Corruption Layer (ACL) prevents one system’s model from contaminating another. It translates between two different worldviews.

In AI systems, two fundamentally different models collide every time an agent calls a tool:

• For the LLM, everything is strings, parameters are simple, and context is a token window. It reasons in natural language to generate structured calls.
• The domain consists of rich types, configuration, state, complex error handling, and business invariants that must hold regardless of how they’re invoked.

The tools layer sits between these two worlds. In Chris Hughes’s words, it “protects your domain from the LLM’s interface requirements – translating between ‘strings the LLM can reason about’ and ‘rich domain objects your code works with’.”

Here’s a tool that ignores this principle:

# Everything in one function - LLM interface mixed with domain logic

@mcp.tool()
async def transfer_funds(from_account: str, to_account: str, amount: str):
    amount_decimal = Decimal(amount)
    from_acc = await db.get_account(from_account)

    if from_acc.balance < amount_decimal:
        return "Insufficient funds"

    if from_acc.is_frozen:
        return "Account frozen"

    await db.execute_transfer(from_acc, to_account, amount_decimal)
    await audit_log.record(from_account, to_account, amount_decimal)

    return f"Transferred {amount} from {from_account} to {to_account}"

And here’s the same operation with a proper separation:

# Tool layer: thin adapter (the ACL)
@mcp.tool()
async def transfer_funds(from_account: str, to_account: str, amount: str):
    result = await transfer_service.execute(
        from_account=from_account,
        to_account=to_account,
        amount=Decimal(amount)
    )
    return result.to_agent_summary()

# Service layer: domain logic, testable without the LLM
class TransferService:
    async def execute(self, from_account, to_account, amount) -> TransferResult:
        account = await self.accounts.get(from_account)
        account.validate_transfer(amount)  # raises on invariant violation
        transfer = account.initiate_transfer(to_account, amount)
        await self.transfers.save(transfer)
        await self.audit.record(transfer)
        return TransferResult(transfer)

The second version gives you:

• Testability: the service works without an LLM. Run it from tests, CLI, scripts.
• Replaceability: change the LLM interface (tool parameters, response format) without touching business logic. Change business rules without touching the tool layer.
• Composability: other MCP servers, other agents, or humans can call the same service through their own interface.

The ACL protects both sides. The domain doesn’t get contaminated by the LLM’s string-based worldview. The LLM doesn’t get overwhelmed by domain complexity it can’t reason about.

The same vocabulary in a new domain

Back to that Reddit thread.

“Separate MCP servers by blast radius.” That’s bounded context design. Each server owns one domain. The blast radius is contained because the boundary is real.

“Three security surfaces, not one – tool capability, tool description, and tool call chains.” The ACL decomposed into its responsibilities. Tool capability is what the domain allows. Tool description is what the LLM thinks it can do. Tool call chains are cross-boundary interactions that need explicit orchestration.

“The dangerous part is not one tool in isolation. It is the chain.” In DDD terms: an aggregate invariant violation. A sequence of operations crossing bounded contexts without coordination. Each operation succeeds locally while the system fails globally.

Same patterns, same structural problem, discovered independently because the problem is real.

The “abstraction tax” is the ACL doing its job

One fair criticism is that MCP adds a layer. The Thoughtworks Tech Radar calls this the “abstraction tax” – every protocol layer between an agent and an API loses fidelity. Simon Willison notes that “almost everything I might achieve with an MCP can be handled by a CLI tool instead.”

This is correct. And it’s exactly the same argument people made against microservice boundaries, API gateways, and anti-corruption layers in traditional systems. The translation layer comes with costs: you lose directness.

But this loss is intentional. It’s the ACL doing its job. The LLM doesn’t need to know about your domain’s internal types, retry logic, or state management. The domain doesn’t need to accommodate the LLM’s string-based reasoning model. The “tax” buys you isolation, replaceability, and, ultimately, peace of mind.

It’s only a mistake if we’re paying this tax without getting the architectural benefit – which is exactly what REST-to-MCP 1:1 wrappers do. They add the layer without adding the boundary: all cost, no benefit.

The vocabulary already exists. Let’s keep using it.

We don’t have to reinvent these patterns – DDD has 20+ years of battle scars. We’ve learned the hard way where to draw boundaries, how to enforce them, and what happens when we don’t. AI or no AI, Eric Evans’s Domain-Driven Design is still the canonical reference for complex software systems.

MCP is already designed to establish bounded contexts; the tools layer is already an anti-corruption layer. Name your MCP servers after the domain they own, not the API they wrap, and when someone on your team says “separate by blast radius” – let them know that there are established patterns for what they’re describing.