The Ubuntu Cremation Manifesto

Debian asks:

What is the least surprising thing we could do?

Ubuntu asks:

How can we differentiate?

This philosophical distinction explains why your Ethernet cable has to survive a product strategy.

Debian sees a mature Linux subsystem and says:

Good.

Canonical sees the same subsystem and begins drawing architecture diagrams.

Ubuntu's history is a beautiful repeating cycle:

1. existing Linux technology works;
2. Canonical decides the ecosystem needs a Canonical-shaped replacement;
3. Ubuntu adopts it aggressively;
4. everyone else says “why?”;
5. several years of ecosystem friction occur;
6. the industry standardizes around something else;
7. Ubuntu migrates;
8. nobody speaks of the incident again.

The archaeological layers include:

• Upstart;
• Unity;
• Mir as the proposed display-server future;
• Ubuntu Phone;
• convergence;
• scopes;
• Snap;
• various server-management layers;
• and enough abandoned strategic initiatives to furnish a small museum.

Canonical does not simply adopt technology.

Canonical periodically attempts to declare independence from consensus reality.

Canonical sees a wheel and invoices the ecosystem for a hexagon. Three releases later, the migration guide calls the corners a learning experience.

Ubuntu Server begins innocently.

A terminal.

SSH.

APT.

Systemd.

Beautiful.

Then you ask:

“How is the network configured?”

And the floor collapses.

The answer may involve:

• cloud-init;
• Netplan;
• systemd-networkd;
• NetworkManager;
• generated configuration;
• datasource metadata;
• /etc/netplan;
• /run;
• machine images;
• vendor initialization behavior.

You wanted Ethernet.

You received a dependency graph.

Someone decided that Linux networking needed a higher-level configuration abstraction.

This is defensible.

Then they chose YAML.

This is an act of hostility.

A static address now looks like:

network:
  version: 2
  ethernets:
    enp1s0:
      addresses:
        - 192.168.1.20/24
      routes:
        - to: default
          via: 192.168.1.1

Beautiful.

Human-readable.

Declarative.

Until one whitespace mistake gets the configuration rejected and you find yourself debugging indentation over SSH like an overpaid fucking typesetter.

Nothing says “production networking” like a maintenance window spent counting spaces. Invalid YAML gets rejected; a valid route to the wrong gateway is what really earns you the long drive.

Cisco:

% Invalid input detected at '^' marker.

Netplan:

Error in network definition: expected mapping

Me:

I AM 400 KILOMETERS FROM THIS SERVER.

There is no prayer quite like:

sudo netplan apply

over SSH.

The cursor hangs for 300 milliseconds.

Your entire ancestral lineage flashes before your eyes.

You think:

“Was that normal latency?”

Then:

“Why hasn't the prompt returned?”

Then:

“Oh fuck.”

Then it returns.

The relief is disproportionate to the complexity of the operation.

You changed one IP address.

You should not experience adrenaline.

A blinking cursor has turned your salary into a hostage. Four hundred kilometers away, one interface is deciding whether you still have a job to connect to.

Netplan includes a rollback-oriented testing workflow because remote networking changes can disconnect you.

This is genuinely useful.

It is also incredibly funny.

The networking tool effectively says:

“Before committing your configuration, perhaps verify you haven't accidentally destroyed your access to the machine.”

Thank you, Netplan.

I appreciate the honesty.

This is my favorite part.

Netplan is not necessarily the component controlling your network.

Netplan describes what another component should do.

So debugging networking can become:

Is the YAML correct?

Then:

Did Netplan interpret it correctly?

Then:

Did Netplan generate the right backend configuration?

Then:

Which renderer is active?

Then:

Did networkd accept it?

Then:

Is cloud-init going to rewrite it on reboot?

Then:

Who created 50-cloud-init.yaml?

Then:

Why does this file say edits may not persist?

Then:

I just wanted DNS.

Cloud-init is extremely useful.

It also creates one of computing's finest horror-movie moments.

You configure a cloud VM.

Everything works.

You reboot.

Something changes.

You inspect the system and discover a file that effectively says:

“This configuration was generated elsewhere. Your edits may be overwritten.”

There is no stronger reminder that you do not own a cloud VM.

You are merely temporarily supervising a declarative object.

Ubuntu images make extensive use of this ecosystem, so the first few minutes on a new machine often become an investigation into:

“Which configuration file is actually authoritative?”

The most important question in Linux administration should not be existential philosophy.

You edit the file. Cloud-init edits your expectations. Reboot, and your configuration comes back wearing its landlord’s fucking clothes.

To be fair, this is not uniquely Ubuntu.

But Ubuntu embraced it enthusiastically enough that it belongs at the funeral.

You inspect:

/etc/resolv.conf

Like your ancestors did.

It points somewhere else.

Naturally.

Maybe:

127.0.0.53

You ask:

“What DNS server am I using?”

Linux says:

“Conceptually or operationally?”

You run:

resolvectl status

Now DNS has per-link state, routing domains, fallback behavior, scopes, and enough metadata to apply for citizenship.

Again: technically justified.

But there was a time when:

nameserver 1.1.1.1

meant something spiritually comprehensible.

You configure YAML so a generator can configure a renderer which configures an interface whose DNS is mediated by a stub resolver whose initial settings may have been injected by cloud-init.

People criticize Arch for being complicated.

Arch at least has the decency to make you responsible for the complexity.

Ubuntu sometimes hides it under carpet until you need to debug something.

Ubuntu Server advocates:

“It's basically Debian, but with newer packages and commercial backing.”

Yes.

And several additional opinions per square centimeter.

Debian server:

networking
apt
systemd
ssh

Ubuntu Server:

networking
Netplan
renderer
cloud-init
snapd
apt
Ubuntu Pro messaging
systemd
resolved
ssh
maybe Landscape

It is Debian after hiring consultants.

RHEL-style distributions:

NetworkManager is managing your network.

You:

Okay.

nmcli

Done.

Ubuntu:

NetworkManager may be managing your network.

You:

May?

Ubuntu:

Or systemd-networkd.

You:

Which one?

Ubuntu:

Check Netplan.

You:

Why?

Ubuntu:

Netplan tells the renderer.

You:

Who wrote Netplan?

Ubuntu:

Maybe cloud-init.

You:

I'm going back to AlmaLinux.

Ubuntu is called easy because:

• installation is easy;
• hardware support is broad;
• documentation is abundant;
• commercial software often targets it;
• third-party vendors test against it;
• drivers are generally accessible.

All true.

But “easy to begin using” and “simple system architecture” are not the same thing.

Ubuntu is frequently easy at the surface and complicated underneath.

Arch is difficult up front because it makes you assemble the machine.

Ubuntu is easy up front because Canonical assembled it.

Six months later something breaks and you discover Canonical assembled it using twelve interlocking mechanisms you didn't know existed.

Ubuntu users:

“Just use the supported way.”

Which supported way?

The upstream project's way?

Debian's way?

Canonical's way?

The cloud-image way?

The desktop way?

The Server ISO way?

The Snap way?

The APT way?

The way documented for 22.04?

The way documented for 24.04?

The way cloud-init regenerates after boot?

Ubuntu contains enough layers that “supported” sometimes sounds less like a technical property and more like canonical law.

The broader pattern is remarkable.

Problem:

Linux desktop shell.

Canonical:

Unity.

Problem:

init system.

Canonical:

Upstart.

Problem:

display server.

Canonical:

Mir.

Problem:

cross-device computing.

Canonical:

convergence.

Problem:

application packaging.

Canonical:

Snap.

Problem:

network configuration.

Ubuntu ecosystem:

Netplan.

The instinct is always:

“We can build an integrated solution.”

Sometimes they can.

The deeper question is:

“Should you make everyone use it before the rest of the ecosystem agrees?”

The future of Linux. Apparently it needed an orange logo.

Lil bro really thought he was going to define the next era of Linux.

Then the next era arrived, and an awkward amount of it had Fedora and Red Hat fingerprints on it.

Not a keynote. Not a convergence render. The shit your machine actually runs:

• systemd: Lennart Poettering and Kay Sievers started it; Fedora made it the default in Fedora 15. Ubuntu eventually retired Upstart. The future booted. It did not ask Canonical for directions.
• PipeWire: Wim Taymans built it at Red Hat; Fedora 34 put it in charge of audio by default. Actual plumbing, connecting actual applications. Somebody managed to improve Linux without first declaring a new kingdom.
• Wayland: Kristian Høgsberg's project, developed across the graphics community; Fedora 25 made Wayland the default GNOME session. Canonical brought Mir to the desktop argument. Ubuntu eventually joined the Wayland session. That's a hell of a long detour to arrive at somebody else's bus stop.
• Flatpak: Alexander Larsson's work grew into an independent community project, with substantial Red Hat involvement. Applications, runtimes, portals, multiple repositories. Canonical looked at the packaging problem and decided the missing feature was more Canonical.

These projects have authors and contributors, not a single corporate birth certificate. Red Hat doesn't get to steal their names either. But Fedora and the engineers Red Hat paid helped turn major upstream changes into things people could actually use.

Ubuntu kept arriving with a competing vision and leaving with a migration guide.

Every Linux standards meeting, Canonical turns up with competing homework and the confidence of a child who put his own name on the group project.

The recurring sales pitch:

We are designing the future of the Linux desktop.

The upstream release notes:

Here it is.

Canonical's next move: explain why this one doesn't count, spend several years on an alternative, then learn how to package the thing everybody was arguing about in the first place.

Fedora's contribution to this process is less glamorous than a keynote. Ship the new stack early. Find the bugs. Get the fixes upstream. Repeat until the thing stops setting people's weekends on fire.

Fedora users are the crash-test dummies of tomorrow's Linux stack. They meet the windshield so your next LTS can call the seat belt mature technology.

Red Hat paid people to build parts of the future. Fedora users paid in weekends. Canonical arrived for the ribbon cutting with a different ribbon and a proposal to replace the scissors.

And KVM?

Avi Kivity and the team at Qumranet. Red Hat acquired Qumranet in 2008.

Canonical did not make KVM.

And this isn't some obscure basement project. Google Compute Engine runs VMs on a security-hardened KVM-based hypervisor. AWS built the Nitro Hypervisor around KVM, stripped down and customized for its infrastructure.

Meanwhile, Canonical bills Ubuntu as the world's most popular cloud operating system.

Excellent. You won the guest list.

The cloud provider runs the building. The KVM-based hypervisor partitions the resources. Ubuntu checks into a VM, unpacks Snap, and starts explaining its vision for the property.

Brother. You are the guest operating system.

Being the most popular thing installed upstairs does not mean you invented the fucking elevator.

And yes, making a guest OS people actually want to deploy is useful work. That's why the joke hurts: Ubuntu is good enough to get invited everywhere and still can't stop acting like it built the venue.

The hypervisor hands you virtual CPUs. You hand the customer a subscription offer.

Congratulations on the occupancy rate. Stop signing the architect's drawings.

Then actual Linus walked in.

In the November 2025 LTT PC build, around 45:43, small Linus was building big daddy Linus a workstation. The distribution they installed was Fedora.

Torvalds explained that Fedora aligned well with kernel developers. When he had tried Ubuntu years earlier, its consumer focus had made replacing the kernel harder for his particular workflow. He wanted the rest of the distribution to work so he could replace the one component he cared about.

His verdict on that old Ubuntu experience:

“this is not for me clearly by design.”

The man who created Linux found your Linux vision inconvenient for developing Linux.

Somewhere in this product philosophy, you can practically hear the objection: modifying the kernel isn't the intended consumer experience.

My brother in Christ, the consumer is Linus Torvalds.

He isn't trying to rice the fucking scheduler. He has patches to test. He wants to replace Linux with Linux and get back to work.

The compile-everything crowd offers him an entire distribution to rebuild. Ubuntu's old consumer workflow puts friction around the one piece he does want to rebuild. It's an extraordinary achievement to make both extremes miss the point of a man whose job title is practically printed on the kernel.

Congratulations. You designed the future so thoughtfully that the guy writing it went somewhere else.

Fedora let him get on with the kernel. Canonical had a vision for his relationship with the computer.

He already had a relationship with it.

Paternity.

You can keep the orange wallpaper. Dad's busy upstream.

UEFI
↓
GRUB
↓
kernel
↓
systemd
↓
cloud-init remembers your cloud provider
↓
Netplan remembers your network renderer
↓
systemd-networkd remembers your NIC
↓
systemd-resolved remembers your DNS
↓
snapd remembers it is refresh day
↓
unattended-upgrades remembers security
↓
GNOME remembers your extensions
↓
Ubuntu Pro remembers you haven't subscribed
↓
You remember why you installed Debian last time

Ubuntu markets ufw as uncomplicated.

For once, the name is refreshingly accurate.

ufw is actually pretty pleasant.

Naturally, Docker can then manipulate packet-filtering behavior underneath it and create situations where exposed container ports do not behave the way someone naively expects from UFW policy.

This isn't fundamentally Ubuntu's fault.

But it perfectly captures the Ubuntu experience:

one friendly abstraction sitting on top of another subsystem while a third subsystem modifies the actual rules.

Linux networking is not configured.

It is negotiated.

UFW is guarding the front door while Docker cuts a loading bay through the wall. The sign still says “uncomplicated.”

Install Ubuntu because everybody uses it for Docker.

Install Docker.

Never interact meaningfully with Ubuntu again.

This is perhaps Ubuntu Server's greatest success:

Millions of machines run Ubuntu primarily to launch containers containing distributions they actually care about.

Ubuntu has achieved operating-system transcendence.

It is the BIOS of Docker.

We must remember our ancestors.

There was a time Ubuntu integrated online Amazon results into desktop Dash search.

You searched your own computer.

Ubuntu said:

Perhaps commerce?

This decision generated exactly the community reaction one might expect when Linux users discover that local desktop search has become entrepreneurial.

It was a perfect Canonical moment:

technically explainable;

commercially understandable;

socially radioactive.

Ubuntu once attempted to create a mobile operating system.

Not merely a skin.

Not merely an Android derivative.

A genuine converged Ubuntu platform.

Audacious.

Interesting.

Technically fascinating.

Dead.

Ubuntu has a long history of products where the retrospective reads:

“That was actually a cool idea.”

followed shortly by:

“Anyway, it no longer exists.”

Unity is perhaps the funniest Ubuntu story because people spent years complaining about it, Canonical abandoned it, and then some users realized:

Wait, I kind of miss Unity.

Linux desktop discourse is a machine that converts all decisions into nostalgia after approximately eight years.

Canonical replaced GNOME with Unity.

People were furious.

Canonical returned to GNOME.

People became nostalgic for Unity.

There is no winning.

Only release notes, and the damp smell of another roadmap being quietly buried.

Canonical wanted Mir while much of the ecosystem rallied around Wayland.

Technical arguments existed.

Strategic arguments existed.

Eventually Ubuntu adopted Wayland.

Somewhere in the universe is a graveyard containing technologies that were once described as:

“Ubuntu's future.”

It is getting crowded. Planning permission has been filed for a second cemetery.

The graveyard of Ubuntu’s futures needs its own package index. Even the headstones will probably arrive as Snaps.

Before systemd became everybody's favorite argument, Ubuntu used Upstart.

Then systemd won.

Ubuntu migrated.

Thus Ubuntu veterans have experienced multiple init-system epochs.

New Linux users think systemd controversy is ancient history.

Ubuntu users remember when there was different ancient history.

This accusation is sometimes unfair.

Independent engineering is not automatically NIH.

Alternative implementations can spur innovation.

But Canonical has historically produced enough parallel solutions that the reputation did not emerge from vacuum.

At some point the company's engineering motto began to feel like:

“Yes, there is an upstream project. But have you considered an upstream project where we're upstream?”

Ubuntu's installer may be easier than many distributions.

The real trap is that convenience creates a future debugging debt.

The new user doesn't know:

• what Snap is;
• what Netplan is;
• what cloud-init is;
• what systemd-resolved is;
• what is upstream GNOME;
• what Ubuntu modified;
• which packages are transitional;
• why /etc/resolv.conf is a symlink;
• why Firefox appears in snap list.

Everything works.

Until it doesn't.

Then Linux 101 abruptly becomes Ubuntu Internals 401.