4 ms·

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

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

vlovich123 4y ago
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.
- monocasa 4y ago
  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.
nine_k 4y ago
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.
touisteur 4y ago
Wondering now whether it'd be a good fit for microvms too.
- astro1 4y ago
  Me too :-)
rendaw 4y ago
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.

vlovich123 4y ago

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.

monocasa 4y ago
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.

nine_k 4y ago

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.

touisteur 4y ago

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

astro1 4y ago
Me too :-)

rendaw 4y ago

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.