> An operating system generator, based on NixOS, that, given a config, outputs a small (47 MB), read-only squashfs for a runit-based operating system, with support for iPXE and signed boot.

> runit is a cross-platform Unix init scheme with service supervision, a replacement for sysvinit, and other init schemes.

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

> 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?

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.

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.

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.

Q: What is an example usage? What have people used read-only *NIX installations for? Would this be especially suitable to run virtually?

The author has game related repos on GH and I speculate a usage they are considering is to setup an emulation station.

Would be perfect for a small VM, or a container. Writable storage can be mounted separately where needed.

A slight optimization here could be to use in-kernel dhcp for init1 netbooting instead of packaging dhcpd and then sleeping for 5 seconds during the bootup to get a lease -- last time I tried it the in-kernel version ensures a lease is acquired before the init script is run.

This is the kind of NixOS project that makes sense; unlike all the people cargo culting it as a desktop OS.

It is an OS. Do you know what “cargo cult” means?

It's when people begin ineffectually mimicking the surface patterns of technology necessary for one context in a completely inapropriate one in order to try to reap the benefits of it. Like using an OS designed for "deployals" necessary in some businesses/institutional contexts when you're actually just a single person running a home desktop computer.

NixOS as a desktop and hoping this reduces your complexity is the technological equivalent to making planes out of straw and hoping for cargo drops.

I think it's fair to argue "the costs/drawbacks of using NixOS as a desktop outweigh the benefits".

But, I think that discounts the value of enthusiastic tinkering, and learning a complicated technology.

Nix is unusual and relatively difficult. This makes it difficult to recommend in many settings. But, if you're interested in learning it, spending time to try it out as a personal desktop (where there aren't external deadlines or requirements of reliability) is a decent way to explore it.

It's similar to how vim or emacs have a steeper learning curve than vscode. It takes more effort, but you get a power-user experience out of it.

> Nix is unusual and relatively difficult. This makes it difficult to recommend in many settings. But, if you're interested in learning it, spending time to try it out as a personal desktop (where there aren't external deadlines or requirements of reliability) is a decent way to explore it.

I was originally interested in Nix and NixOS on servers, and started running it on my main desktop at work in order to force myself to really learn it, as a way of jumping in with both feet.

I think it worked well, and I ended up really enjoying it.

* * *

If you only use things people already created environments for it's pretty great.

But try to compile and run a random C program you found on the internet on NixOS and that complexity immediately becomes apparent. Because there is no "system library" set for NixOS you have to create the environment needed for every single thing you do. If it is a very popular thing than someone else will have done it. If it is not, as is the case in most situations, you end up having to create the environment yourself via config. A huge extra layer of complexity and work before you even begin to attempt compiling.

By the time I started using NixOS, I'd already decided that the only way for me to install software on a distro was via the package manager. So when I want to run something novel, I generally package it, regardless of distro. (For quick and dirty testing of binaries, of course, an escape hatch or a hack is fine.) I love using openSUSE's public instance of the Open Build Service to easily build and distribute my own packages when I'm using non-NixOS in some situation, and would not hesitate to use or create a hosted one in an enterprise context.

So for me, NixOS doesn't add too much complexity because my minimal complexity commitment is covers much of what NixOS 'adds' anyway. But this story:

> If you only use things people already created environments for it's pretty great.

doesn't end at that layer, and in fact it essentially recurs deeper down!

When it comes to packaging with Nix or crafting environments, what's popular is usually easy, and what's easy is really easy.

But when you go off the beaten path... you're going on a journey. Maybe a short one, but possibly a long and painful one.

For me, Nixpkgs and NixOS have grown so much since I first started running NixOS on desktop (like 8 years ago, now!) that such work is rare enough for me that I hardly think about it. But you're quite right that the additional complexity is there, and it can be discouraging and draining when setting up software environments in that way is new to you, or when you just don't wanna do it.

It works perfectly fine (even better, I'd say, than other Linux distributions) as a desktop OS. Currently running it on both a laptop and a desktop, and not sure what you're referring to.

Very tempting to start using a combination of nix and qubes

You may be interested in Spectrum OS[1], which is more or less what you're looking for.

[1] https://spectrum-os.org/

Glad to see it doesn't stick with Xen, that's really interesting! (if not seL4-interesting)

I've had the same though with Guix, and have considered attempting to repackage / port the Qubes components, but it's one of those far fetched ideas that I know I can't make time for (or even maintain if it was just magically done).

A kernel, initrd, and 47MB squashfs, making the squashfs the smallest of the three.

Could this potentially also be used as a foundation to create an OCI compliant container image?

Slurm now supports OCI images and creating them completely from nixpkgs in an automated system would pair very well.

If I add any stuffs within the system, does it persist (or if not how can I make it so)