Hacker News Reader

Comment by pxc | Hacker News Reader

This is actually a really long-standing project by now! Michael has been a Nixer for a long time. He's very helpful and quite an adept Nix hacker. When I was first getting started with NixOS he gave me a lot of help in IRC for some packaging issues (Nixpkgs was less than 25% of it's current size back then, IIRC!) and inspired me to knuckle down and learn the Nixpkgs codebase by reading it.

Cool to see his work show up here. :)

Fans of slimmer and systemd-less spinoffs of NixOS should perhaps also check out NixNG: https://github.com/nix-community/NixNG

View on HN

> Fans of slimmer and systemd-less spinoffs of NixOS should perhaps also check out NixNG

So a primary difference from NixNG is that not-OS has a kernel and initial RAM disk, making it viable for running on hardware? The sparse README says it's for "embedded" purposes, but I'm struggling to understand the value of Nix here if the whole filesystem is read-only — you'd be working entirely off the RAM disk?

The Linux boot image is a squashfs image loaded into memory by your boot loader (eg grub). It can still mount other filesystems for on-disk partitions (provided the relevant file system and drivers are compiled into the kernel). 50MiB is a bit on the heavy side for many embedded use cases (ie M0 devices). It’s possible M3/M4 CPUs have enough storage and RAM to support this. It’s been a while since I checked the specs for those chips.

Embedded is a broad category. Yeah, this is a bit heavyweight for Cortex-M, but so is Linux just kind of in general. This would be great for a Cortex-A class SoC.

In an embedded system you likely have all the code on a read-only filesystem which is the device's flash storage. You can have a separate device for writable storage (an SD card, another piece of flash, etc), or operate on a RAM disk entirely if all you need is storing runtime-only data. The latter is how OpenWRT operates, for instance.

Wondering now whether it'd be a good fit for microvms too.

Me too :-)

With a read only filesystem the value is in the simple and robust tooling for assembling the image, rather than administration of the live system.

Other embedded filesystem image generation I'm aware of (like android?) require a huge swath of software and dependencies installed, byzantine build systems, star alignment, etc. Or emulation and shell scripts with timing issues, limited failure recovery/idempotency.

> A lighter and simpler design, due to the omission of systemd

What does it use in alternative?

IIRC, Magic was trying to get runit working. But, the idea would be that the init system is modular/swappable.

The answers are in the source, though.

Reply on news.ycombinator.com