Nanos – A Unikernel

Original Article ↗ Hacker News Discussion ↗

Perceived Benefits and Use Cases

  • Nanos is seen as a good fit for:
    • High-performance, low-variance cloud workloads and HPC.
    • Pedagogy, OS/systems/CPU-architecture research.
    • Embedded systems needing a Linux-like process model.
  • Main advantages cited:
    • Very small, single-purpose OS image with reduced attack surface.
    • Higher throughput (benchmarks show ~1.6x vs Linux for static content).
    • Mental model: “your app + minimal kernel + hypervisor,” nothing else.

Architecture, Bare Metal, and Filesystems

  • Nanos is explicitly designed to run as a VM atop a hypervisor, not on arbitrary bare metal.
  • It targets paravirtualized environments (e.g., KVM devices), avoiding diverse hardware drivers.
  • It does have filesystems; what’s missing is an interactive multiuser userland.

Debugging, Logging, and Operational Concerns

  • Multiple commenters struggle with the lack of a shell and traditional tooling inside the image.
  • Logging is typically exported via syslog or cloud logging (e.g., CloudWatch), similar to Kubernetes practices.
  • Some fear an “anemic” environment when things go wrong; others argue remote logs + attachable debuggers are enough.
  • Docs are praised for detail on Nanos itself but criticized for thin guidance on administration, deployment, and testing.

Deployment, Orchestration, and Cloud Integration

  • The ops CLI can build images and launch VMs on AWS; there’s a Terraform provider and examples.
  • Strategy is to rely on cloud primitives (ELB, ASGs, storage services) instead of replicating Kubernetes-style orchestration.
  • ops is not an orchestration system; Terraform or cloud tooling is suggested for larger deployments.
  • Confusion exists around runtime configuration (e.g., env vars) vs baking config into images.

Comparison to Containers, Alpine, and Kubernetes

  • Many note Alpine + containers “won” due to ecosystem maturity, familiarity, and orchestration (Kubernetes).
  • Containers are seen as “good enough” for isolation and performance, easier to debug (shell, package installs).
  • Some argue unikernels remove a full multiuser OS and unnecessary kernel features; others see lost convenience and skills transfer.

Security Discussion

  • Advocates emphasize that VMs provide a strong isolation boundary; containers do not, as shown by recurring container breakouts.
  • Running unikernels under Kubernetes is said to reduce security benefits because Linux/container layers reappear.
  • Installation via curl | sh and MD5 checksums is criticized as irresponsible; critics call for signed, reproducible builds and multi-party verification. Project representatives point to alternative download options, but concerns remain.

Language, Research, and Verification

  • Desire is expressed for a Rust-based unikernel; others defend C for stability and simplicity when carefully written.
  • Nanos is language-agnostic and reportedly used with Rust apps.
  • Broader unikernel ecosystem: mentions of MirageOS and its partially formally-derived components.
  • Some see OS research as having slowed, but still see big open problems in distribution, security, and rethinking the “stack under the cloud.”

Ecosystem and Tooling

  • Three main components generate confusion:
    • nanos.org: the kernel/technology.
    • nanovms.com: the company/products.
    • ops.city: packages and the ops CLI.
  • Packaging model is likened to Docker: base packages (e.g., nginx) are extended via config (files/dirs/mappings); users are already publishing their own packages.
  • Community-space strategy is debated (no official chat vs desire for a central, searchable, privacy-respecting venue).