I'm leaving Arch Linux. Here's why:

Mischa van den Burg

👑

⭐

12d • 💬 General discussion

I'm leaving Arch Linux. Here's why:

After 4 years of daily driving Arch Linux, I’m leaving.

You may think I’m leaving because Arch Linux breaks often.

Or because it’s unstable.

But the reason why I’m leaving is actually very different.

I’m going to be running my workflow like a Kubernetes cluster.

I want a workflow where I can throw my laptop in the sea and restore it on a new machine in 10 minutes.

And in this newsletter I’ll explain how I’m going to build the workflow of my dreams, and why I have to leave Arch to do this.

I will teach you about modern software deployment practices and how you can apply them to your own setup as well.

Let’s dive in.

Backups

What would happen if your main laptop or workstation would die right now?

Would you panic?

Do you have any backups of your most important files?

How fast could you rebuild your system exactly as it was?

Could you do it under an hour?

Most people, even senior DevOps engineers, would not have any structured backups of their machine, and they would need at least a day to rebuild their computer.

I’m doing something most people don’t do.

I’m applying the same principles we use for managing server infrastructure to my personal computer.

Infrastructure as Code. Immutable systems. Containerization. Stateless workstations.

These concepts come from managing Kubernetes clusters and cloud infrastructure.

But what if you applied them to your laptop?

That’s what I’m testing over the next few months.

Why I’m Doing This:

KubeCraft is going places. We’ve rented an office space so me and my brother can work together.

I need my work environment available on multiple machines now - one at home, one at the office, and my travel laptop for when I’m working from my camper van across Europe.

I’ve been organizing things with that goal in mind, but I’ve never actually tested whether it works.

Over the next 2 months, I’m going to document building what I’m calling a stateless workstation.

It’s the same concept as stateless services in Kubernetes - nothing important lives only on the machine itself.

I’ll show you what works, what doesn’t, and what I learn along the way.

Most People Treat Computers Like Pets. They Should Be Like Cattle.

There’s a concept from DevOps infrastructure management that perfectly explains what I’m trying to build.

It’s called “pets versus cattle.”

In traditional IT, servers were pets. Each one was unique, hand-configured, and if it died, you were in trouble because rebuilding it from scratch was nearly impossible.

In modern DevOps, servers are cattle.

Each one is replaceable, built from code, and if it dies, you spin up another one identical to it in minutes.

This revolutionized how companies manage infrastructure.

But almost nobody applies this to their personal computers.

How This Applies to Your Laptop:

Think about how you treat your computer right now.

It’s probably a pet.

It’s YOUR laptop with YOUR specific setup.

Everything is configured just the way you like it after months or years of tweaking.

You have your favorite applications, your personalized settings, your carefully organized files.

If this computer breaks, you’re in serious trouble because you don’t really know how you’d recreate everything.

It’s all just… there, and it works, and you hope nothing bad happens to it.

What I’m Building Instead:

I’m applying Infrastructure as Code principles to personal computing.

I’m treating my laptop like cattle.

This machine is just one instance running my environment.

I should be able to recreate my entire setup on any hardware in under an hour.

If this laptop breaks, it’s annoying, but I just grab another one and keep working.

That is the Way of the Stateless Workstation.

I Only Work In Containers

Let me show you what applying these principles actually looks like in practice, because I’m already doing this for all my development work.

I’m a Kubernetes engineer.

I work with multiple clients, each with their own clusters, their own tool versions, their own configurations.

Traditionally, people install everything on their local machine and deal with version conflicts and configuration chaos.

I don’t.

My Development Setup:

I don’t have kubectl installed on my base system.

I don’t have Terraform. I don’t have Helm. I don’t have any client tools.

Instead, every client gets their own environment running in a container.

Each container is completely isolated.

Different tool versions, different configs, different everything.

Inside each container, I have my full development environment set up exactly how I need it.

One single script installs everything using Infrastructure as Code principles.

Want to my complete workflow in detail?

There are still a few spots left for the November cohort.

Sign ups close until next month when they're filled.

CLICK HERE to claim your spot.

Why This Matters:

If my laptop dies right now, I lose nothing related to my actual work.

My dev containers are defined as code.

I spin them up on any machine and I’m productive in minutes.

Each client environment is completely reproducible.

No “it works on my machine” problems.

No conflicts between different tool versions.

No pollution of my base system.

This is applying Kubernetes principles to development environments.

Containers for isolation. Everything declarative and reproducible. Nothing precious on the host machine.

Stateless workstation at its finest.

What I’m Testing Now:

I’ve proven dev containers work beautifully for development.

My coding environment is completely portable and reproducible.

But what about everything else?

Can I apply the same Infrastructure as Code principles to my entire system?

That’s the experiment.

Sometimes You Need to Leave to Really Learn

I’m not just rebuilding my current system on new hardware.

I’m switching from Arch Linux to Fedora Atomic Desktops for 3 months.

Then coming back to Arch in December with everything I learned.

Not because Fedora Atomic is “better than Arch.”

But because sometimes the best way to master something is to temporarily leave it.

Why Leave Arch?

I’ve been running Arch Linux for years now.

It’s still the best way to truly understand how Linux works under the hood.

You build everything yourself. You understand every component. You know exactly what’s on your system.

But I’ve gotten comfortable.

And comfort is the enemy of learning.

What Fedora Atomic Forces:

It takes the immutable infrastructure concept to the operating system level.

The base system is read-only.

You literally can’t modify it the normal way, just like immutable infrastructure in production.

Every application runs in containers via Flatpak, enforcing isolation just like my dev containers do.

Updates are atomic: all or nothing, just like Kubernetes deployments.

You can’t just install random packages wherever you want.

It forces you to think like you’re managing production infrastructure.

Because that’s literally what it is: production infrastructure patterns applied to a laptop.

Why Not NixOS?

Some people will ask “why not just use NixOS?”, it’s designed for declarative, reproducible systems.

But here’s the thing: learning Nix means learning a whole programming language with almost zero industry relevance outside the Nix ecosystem.

I’d rather use containers, the same technology that runs production workloads in every company I work with.

The Learning:

By forcing myself into these constraints, I’ll learn patterns I wouldn’t discover by staying comfortable in Arch.

I already know dev containers work for development isolation.

But can I extend that containerization philosophy to GUI applications too?

Can I keep my base system truly minimal and stateless?

What are the real trade-offs of treating your entire computer like a Kubernetes cluster?

I don’t know yet. That’s why I’m doing it.

The Return:

In December, when the Framework desktop arrives, I’m coming back to Arch.

But I won’t be rebuilding the same system I had before.

I’ll come back with patterns learned from Fedora Atomic's immutable approach.

A tested, validated approach instead of assumptions.

Arch is still the foundation, it’s still the best way to understand Linux deeply.

But Silverblue will teach me how to take the Infrastructure as Code concept even further.

The Dev Container Foundation:

I already teach the dev container workflow in an 8-hour course at KubeCraft.

It’s how you actually work as a Kubernetes engineer.

Every client or cluster in isolation, everything reproducible, nothing polluting your base system.

Students who master this approach stand out in interviews because they can talk about containerization from daily experience.

And it's working. One of my students got a $50K raise 4 weeks after joining KubeCraft.

CLICK HERE to claim your spot.

Have a good week,

Mischa

P.S. the stateless workstation approach is golden when you do freelancing. A fresh environment for each contract. Don't have any freelance contracts yet? You are missing out. You can double your income by going freelance if you have the Kubernetes skills. Click here to find out more.

7 comments