Nanos – A Unikernel

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).