And what about the kernel? The Linux kernel is perhaps the most monolithic piece of software in any FOSS operating system today. It is one project that has “engulfed” an unbelievably wide variety of functions. And yet people who want to avoid systemd are happy to use Linux.
It works because it well compartmentalized. Yes, Linux has a great many functions and many of them intertwine in complicated ways. But overall, the subsystem structure of maintenance makes sure that any particular piece of the kernel is reasonable to maintain. The same goes for systemd. It is made up of many components. It’s not 1M lines of code in PID1, it’s 1M lines of code spread across many independent functions, many of which NixOS doesn’t even use.
I really don’t understand how a Linux user can make this argument.
The kernel is of course the elephant in the room. And you mentioned some modern kernel design philosophy to solve some problems.
However, it doesn’t mean as we see potentials in new on-going approaches such as those in multikernel architecture research with specialized kernels for scalable multicore systems and even peripheral cores, we do not care about open-source community projects with unsurpassed community momentum such as Linux (and the various distros) going to a more possible direction or a more restrictive direction.
The way I see it, you’re arguing from an ideological position whereas “systemd in NixOS” is purely a practical choice.
It provides tangible benefits despite a number of draw-backs but at this point it’s probably the best option and we simply don’t have the man-power to reinvent the wheel. Maybe systemd sucks - but it sucks less than having to put in a lot of effort to try and replicate all the features we depend on through different projects.
I think there is definitely a side to this that it’s “cool” to dislike systemd and want to pursue this kind of topic for a vague definition of “minimalism” that doesn’t make much sense if thought out to its conclusion. This has been something demanded of lots of distros ever since systemd started seeing any adoption, and has poisoned basically any discussion on the topic.
But I want to point out that @menuhin didn’t start out the question like that. I think the question of how much effort it would be is legitimate - there are use cases, such as wanting to have a very stripped down OS for running on minimal hardware (think puny embedded devices, though IME lots of commercial embedded devices use systemd these days anyway, so maybe that use case is shrinking too).
NixOS obviously doesn’t target these use cases though, so the question is hitting some sore points for maintainers who think they might have to be responsible for a feature like this, especially considering the abuse that’s been thrown at distros about this in the past. You’d be better off starting your own distro if you want to go systemd-less.
I think the answer “quite hard, not impossible, but good luck convincing anyone it’s worth merging it into nixpkgs” is a good one, and probably all that needs to be said on the topic, at least until someome has put in the work (and shown that they are both capable of and have the time to maintain it in the long-term - which is the harder part of this).
and I’m absolutely thankful for this thread, that starts playing with thought into that direction.
IMHO, it’s completely pointless.
It’s a bit like saying “let’s get the conversation started around replacing the Linux kernel with GNU Hurd because micro-kernels are so much better”. I mean sure, at some point that might make sense but currently it just isn’t practical. Same thing with discussing changes to abstract out configuration to accommodate a possible future systemd replacement that doesn’t exist yet.
If you want to replace A with B, there needs to be a strong value proposition and tangible problems with tangible solutions. Otherwise it’s just a waste of time.
(I do appreciate the irony of both the topic and discussion itself thus being a waste of time)
If you want to do something really different I think your options for good starting points are Alpine, Gentoo, Guix and NixOS. I think NixOS is the best option because you have the functional benefits without the ideological constraints of Guix.
A successful fork needs to intuitively combine our packages with an alternative init and yield better (or more coherent) features than systemd. There are people trying, I’ve already seen code for NixOS-derivatives that use runinit, s6, and Synit.
As you walk ahead, you’d better look ahead, and not backwards.
But we’re not looking ahead. We’re simply gazing blankly into space. There is nothing concrete for us to look at.
Let’s try a different approach - what do you propose the next set of actions should be? What’s the plan here? Because if it is just “yeah, we kinda, sorta needs to think about this”, then it’s pointless. I’m not saying it isn’t going to be relevant later, but not now.
@peterhoeg I think you’ve stepped away from the metaphor. Metaphors are really only useful as long as everyone is perceiving them with the same rules, which doesn’t appear to be the case here.
That said, I don’t think there’s anything wrong with imagining a future where NixOS has a different init system or even a different kernel. I wouldn’t call it pointless because if nothing else it can spur ideas to be used in other endeavors. The chances that it happens in NixOS in the next decade are basically 0%, but e.g. I can imagine a world where people take the ideas developed from these conversations and make a Nix based BSD variant. In that case, these conversations would have been critical.
It’s really just a valid curiosity. It’s never going to mean anything for NixOS specifically, but it could mean a lot to people who have other ideas for Nix.
I’m currently forming a mental model about this, it includes:
Aura is set to heal the schism between host and cloud native runtimes/scheduler. They may consider Nickel as their config lingua franca
OAM (Open Application Model) attempts to define abstract interfaces for long runing services, that can then be executed by schedulers.
The “Entrypoint” (a.k.a. known as Systemd’s Script) is the umbilical scenery across schedulers. Quite some features of Systemd are sugar around that (others aren’t, ofc).
The container distributions model (if it can be tweaked a little *) is actually a good interop choice. Aura is using it as their prime distribution target.
* a runtime that can assemble Nix store paths, natively.
Suggested Action Items: (brainstorming, please! )
Amend the OCI standard for native NAR layers, consider the OCI distribution model.
Experiment with a unified control plane a la Aura as soon as possible.
Assess how much NixOS makes use of Systemd sugar (can that be abstracted into the entrypoint?)
Assess if the OAM (needs to evolve/stabilize a little) can describe the abstract fundamentals of Systemd. Systemd can be a provider. If not possible, either contribute to OAM or reach for a similar implementation of separation of concerns, after all we already got a functional config lingua franca that is (if you count nickel) perfect (if used properly) for separation of concern along contract boundaries.
OCI is not “docker”. And its jailing is what you make of it. systemd’s approach is but one. Aura seems to be looking at firejail, afaik.
I suggest more concrete steps: how about maintaining the abstractions we already have in Nixpkgs and improve them?
For example, for both stage-1 and networking setup we have two independent implementations obeying the same set of options: one is using shell scripts, the other using systemd. Let’s start by not talking about removing the script variants and instead focus on making them 100% functionally equivalent (they’re not) and writing more tests.
Then we could think about providing (and maintaining) abstractions for minor (but widely used) features like systemd.network.links (udev rules as alternative) and systemd.tmpfiles.rules (pretty easy to do with shell scripts) and so on.
Finally one could think about doing systemd.services.
So you are suggesting to reimplement parts of systemd feature-to-feature and bug-to-bug in stringly typed shell code and then maintain it ourselves or am I misunderstanding something here?
If so please excuse my bluntness but I fail to see a value here except that it is no longer C code that Poettering started. But we would have a lot more development and maintenance burden and loose the work that went into systemd and could no longer count on the systemd maintainers and other distros to find bugs and implement features.
Summed up: not invented here
I agree that networking would be a really great place to start. Both the script based and networkd based implementations are good, but can confirm they definitely aren’t interchangeable currently, especially if you are statically setting up ips and routes
No, you completely missed my point. It’s not about getting rid of systemd or reinventing the wheel: it’s about making the backend independent from the NixOS module system.
The init system being systemd, SysVinit, launchd or whatever should be abstracted away and the best way to do this is:
not making NixOS any more dependent on one particular backend
maintain and improve the abstractions we already have
provide more similar abstractions
But we would have a lot more development and maintenance burden and loose the work that went into systemd
It’s inevitable if you want to bring NixOS to platforms not supported by systemd, which is basically just non-embedded Linux.
While I agree this is the best use case, I’m not sure just removing the systemd dependency is sufficient, considering how hard it is to deploy NixOS to such systems anyway. I’ve yet to see a NixOS that didn’t need some 20GB of disk space available, which is usually far too much.
I suppose it would be a first step to enabling people who want embedded systems, and with some iteration the other problems could slowly be ironed out. But I feel like systemd isn’t the main problem when it comes to disk space.
If the goal is to enable embedded uses cases, perhaps a new embedded profile and such should see some looking at first, and if this gets NixOS into a reasonable range then perhaps someone with an actual embedded use case could chime in on what other blockers there are? Or maybe it is discovered that systemd makes up a huge portion of the remaining size, at which point there is a clear motivation for this.
We should do that regardless and develop more abstraction with some direction, not just plan-less start to abstract systemd out and later notice that this wasn’t the biggest problem in the first place.
That is also a general problem right now regardless of this discussion. We need a smarter way to describe dependencies while keeping the amount of duplications in the nix store low. I imagine a system where all required features are collected and then the library is build with all of them which are then consumed by the packages. But this would trigger a lot of configuration specific rebuilds and likely requires CA derivations to be viable at all.
And for embedded devices we would need to drastically reduce the minimal footprint of many many packages and likely replace some of them. There is a reason why OpenWrt has its own package repository and is from the ground up build for embedded device which have very limited resources and not just a flavor of another Distro. Many of the decisions done do not make sense on a a normal sized computer where eg. 30 MB of extra disk usage do not matter at all. Keeping embedded systems in mind with every dependency change will put a lot of extra work on reviewers and maintainers alike and the situation would likely be similar to pkgsMusl/pkgsStatic which are regularly broken by updates.
In my opinion it would make way more sense to design NixOS for embedded devices from the ground up with them in mind while trying to reuse as much of NixOS as possible instead of adapting and slimming down NixOS from its bloated point. This would also ensure NixOS can develop without keeping embedded devices in mind with every change.
Then the ground up design can freely choose its init system, change the module system to be more adaptable friendly which would also aid home-manager a lot but also would be free to do its own service collection which fit its very special and different requirements.
I would love to see this. My experience with embedded integration systems (well, mainly yocto/bitkbake) hasn’t been convincing so far. A nix-based distro would be awesome for this. I’m not sure I see industries moving to it anytime soon with the certification those kinds of systems often need, though.
I also think the whole nix ecosystem is a little too nixpkgs centric for this to happen easily. Lots of third party flakes, deployment tools, and even just the nixpkgs lib are such a shame to lose, while not actually being particularly distro-specific. As nice as nixpkgs is, it shouldn’t be this hard to go without it.
It’d be very nice if some kind of “core nixpkgs” api could be abstracted instead - it would make experiments like “what if I just removed systemd?” much easier too
But yeah, probably not the right place for that discussion. I agree the systemd abstraction is not really worth it without a real use case. Though I also understand why it is so tempting, from the eye of a software engineer (especially if you dislike Poeterring, which I can’t really relate with knowing nothing about him beyond systemd/pulse/some cool blog posts on signed boot, so maybe I’m biased).
The idea of a “from the ground up” novel distribution using Nixpkgs certainly interests me. I was thinking on something like that, a “linux from scratch” but injecting Nix (and Nixpkgs) as soon as possible.
)