Lennart Poettering, Christian Brauner founded a new company

What Amutable Appears To Be Building

• Company describes goal as “cryptographically verifiable integrity” for Linux: systems boot into a verified state and remain trusted (secure boot + TPM + immutable images + attestation).
• Likely built around existing systemd work: UKIs (unified kernel images), image-based/immutable OS layouts, dm-verity, TPM‑bound disk encryption, secure boot integration.
• Representatives confirm: Linux-based OS, focus on attestation of immutable systems; details and revenue model intentionally vague for now.

Enthusiasm and Positive Use Cases

• Strong support from some who see Linux boot security as badly behind ChromeOS/Windows/macOS and want:
  • Authenticated boot + TPM-backed FDE against evil‑maid and persistent malware.
  • Server/cloud attestation: verifying that rented or remote machines run exactly the audited image (Mullvad-style “transparent servers”, confidential computing).
  • Safety‑critical or industrial devices where owners explicitly want to prevent arbitrary code for life-safety reasons.
• Some hope this could provide a FOSS attestation stack that breaks current mobile duopolies, or improve Linux’s standing for enterprise workloads.

Major Fears: DRM, Lockdown, and “War on General-Purpose Computing”

• Large portion of thread sees remote attestation as “literally DRM” and part of a long-running “war on general-purpose computing.”
• Concrete worries:
  • Banks, streaming, games, or ISPs eventually refusing service to “unattested” or user-modified systems (parallels with Android SafetyNet/Play Integrity, iOS, streaming DRM).
  • Laptop/PC vendors shipping hardware where users can’t enroll their own keys or disable secure boot, making unsigned or alternative OSes (including BSDs) second-class.
  • Governments or industry lobbying to outlaw user-controlled keys once the technical friction is gone.
• Some view this as plugging the “user freedom hole”: making it hard to leave controlled ecosystems or run self-built kernels.

Debate: Neutral Mechanism vs Inherently Restrictive

• One camp: remote attestation, trusted boot, TPM, etc. are neutral tools; DRM is policy layered on top. Same mechanisms can:
  • Help users verify their own machines and servers.
  • Improve cloud privacy (e.g., “private compute” models).
• Other camp: in practice these tools overwhelmingly end up serving corporate/government control, not end users; citing:
  • Mobile platforms, Widevine/HDCP, printer DRM, vendor-keyed secure boot, banking apps blocking rooted/custom ROM devices.
  • Once built, such mechanisms cannot be “unbuilt” and will be reused in the most oppressive ways incentives allow.

systemd, Track Record, and Governance Trust

• Heated revisiting of systemd’s history: some praise it as vastly better than SysV/Upstart (dependencies, security options, timers, logging); others catalog years of regressions, breakage, opaque behavior, and “arrogant” responses to bug reports.
• Specific fear that new attestation features will follow the “systemd pattern”: start optional, become tightly coupled, then de-facto mandatory via distro decisions.
• systemd maintainers in thread insist:
  • Disruptive features are intended to be opt-in.
  • Attestation features won’t be enforced by systemd itself; distros decide.
• Skeptics counter that maintainers define what’s “disruptive” and past experience shows dissenters effectively told to “live with it.”

Threat Models, Privacy, and Technical Nuances

• Supporters emphasize:
  • Current Linux secure boot use is weak: often only kernel is verified; initrd/userspace can still be replaced.
  • A strong chain (firmware → bootloader/UKI → dm-verity rootfs) plus TPM-bound secrets can detect or prevent persistence.
• Critics question:
  • Realistic benefit for typical users vs. dominant risks from network-facing software.
  • Privacy impact of attestation keys (EK/AIK), potential cross-service tracking, and linkage to purchase records.
• Some argue reproducible builds and transparency logs are essential complements; others note attestation can still be useful without them, depending on trust assumptions.

Business Model, Control, and Long-Term Risks

• Company answers on revenue are generic (“robust path to revenue”); observers infer enterprise/server focus and possibly appliance/embedded deals (Tivo-style locked products).
• Founding engineers repeatedly say:
  • User-controlled keys are central to their designs.
  • They won’t build systems to enforce vendor lockout.
  • Work will remain open source.
• Many remain unconvinced, citing:
  • Historical shifts of projects once money, regulation, or acquisition enter (HashiCorp, WhatsApp, mobile OSes, etc.).
  • Risk that, even if initial intentions are good, later owners or partners (including large cloud or OS vendors) can repurpose the mechanisms against user freedom.