I agree that systemd isn’t really ideal for the embedded case. What would really be awesome in these space constrained situations is a file system that is aware of network focused dedupping algorithms like casync. Just found this issue, for example.
Would go long way to save space in constained environments, but it would also open the door for us to use this on the remote cache end to make the network traffic more efficient in general.
The current implementation of the module system in NixOS is also probably too heavy for these cases, but something like RFC 22 could help that in the future.
I know of at least one case where something similar is in production. A friend of mine is working in a new-space startup that uses Alpine + nix on their satellite. Basically, NixOS was too heavy for them and they had trouble with some proprietary binary drivers. As far as I understand, they now build a base image on Alpine with the proprietary stuff, add a single-user install of nix on top of that and then use that to manage dependencies and updates to the majority of their firmware. They can roll back all the critical parts of the firmware as desired, and the base image doesn’t need to be updated in space, so they just leave that alone, making all firmware updates as risk-free as they would be on full-blown NixOS.
I think until something like a minimal embedded-friendly version of NixOS exists, this will be the way to go for embedded.
For work I’ve made a custom embedded OS using nix which is probably not too different than Not-OS. We now need better networking capabilities so I am experimenting with switching from runit to systemd (for networkd in particular).
Also, prior to this need I have continuously struggled with packages bringing in systemd as a dependency. They usually have switches to disable the dependency, but hunting all that down has been a pain. I’ve had cases where a package did not depend on systemd, but after an update suddenly started depending on systemd and then I would have to go figure it out. I am looking forward to not having to do that anymore after this systemd integration.
Nice. I know this has been controversial due to the systemd, anti-systemd debate, but a service layer can really help us generalize the ecosystem outside of Linux (BSD, MacOs, etc), not to mention help out where systemd isn’t needed or wanted.
Jup, that’s the one. The company is called OroraTech, they do wildfire detection with satellites. The longer talk from Nixcon 2022 might also be interesting: https://www.youtube.com/watch?v=RL2xuhU9Nhk
Hey, somehow I got interested in running nixos without systemd. Come to think of it, it would be cool to change it in the declarative way. I use artix with dinit and I like it very much for its simplicity. https://github.com/davmac314/dinit
funny you should mention that … i recently wrote an incredibly minimal proof of concept os using dinit and chunks of nixos
i found dinit to be an interesting experience
i am going that @MagicRB will be at nixcon this year as i have some questions for them about their os… and hopefully some of the nix bsd os developers as well
Hey, I gotta be honest, I tried searching the nixcon videos for this topic, I did not get lucky.
Any chance we can declaratively change our inits, just be cool and completely nixy? Hehe
there were some conversations at nixcon about this, not a whole lot though, and no actual talks i believe
did you have some concrete ideas on doing this? it isn’t the most trivial thing to accomplish and the value is debated by a number of people - what @MagicRB is working on is probably your best bet
personally i think this is a good idea so i’m watching nix-ng carefully
NixNG (or others like it) is realistically the only way you’re getting a module system built Linux rootfs, NixOS is moving towards being more closely integrated and dependant on systemd (for good reason).
One reason is because there is not a blatantly obvious stand-in for the kernel. The kernel also goes through rigorous, multi-architecture testing from developers, and people who compile release candidates also submit bug reports about bugs they find before they come into the mainstream kernel. There is a long list of things that developers have to do to even get their PR submitted to the kernel, which is why, for example, projects like bcachefs haven’t been merged; they didn’t follow the instructions, and their commit didn’t get merged. I’m not sure how systemd does testing, but I’m almost positive that it’s not as rigorous as the linux kernel.
When you talk about and compare the size of the linux kernel to the size of systemd, you have to take into account that the linux kernel supports numerous architectures, not even counting in drivers and other software that doesn’t come with distribution kernels. Yes, I am aware that systemd is a suite of tools that don’t all necessarily get shipped, but it’s still a crazy number of lines.
Yet another point is that, quoting the Unix Philosophy, it says “Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features”.” systemd does way to many things, and when one thing breaks, such as in the case of Bug #1988119 “systemd-udevd: Run net_setup_link on 'change' ueve...” : Bugs : systemd package : Ubuntu, there are large outages across multiple systems. I can put up with systemd, but part of Unix, Linux, and this community as a whole is customization, and not having the ability to change your init system is a step in the wrong direction.
and yes I’ll be at NixCon
