Wow, I'd never heard of that. I've been using LXD for a while now and love it. From a quick glance at the docs, I'm not sure what benefits this has, apart from not requiring Snap. :D
If you're on a systemd distro, one advantage is you already have systemd-nspawn. Although, on debian boxes, it's split out into the systemd-container package.
Another advantage is it's somewhat integrated into the rest of systemd, having hooks into systemd-machined and the machinectl tooling, and an out-of-box instance unit file for systemd-nspawn@ where the instance name maps to the machine name. Meaning you can trivially start a container w/`systemctl start systemd-nspawn@that-contained-webservice` having nothing more than something useful in /var/lib/machines/that-contained-webservice/, or enable it to start at boot like any other systemd service i.e. `systemctl enable systemd-nspawn@that-contained-webservice`.
BTW, rkt was basically just a wrapper around systemd-nspawn, though the pluggable stages supported alternative containment mechanisms. The nspawn stage1 is what was originally shipped from the beginning.
It's less worrying if you view systemd as a mono-repo containing a collection of related projects maintained in one place, one of which is PID 1 - which really should have been renamed to systemd-initd.
The fact that Debian is able to isolate the nspawn-related bits into systemd-container without breaking everything speaks to the modular arrangement. Though the project may be a mono-repo under the systemd umbrella, it's not a monolithic beast antithetical to unix tradition as many like to claim.
It's odd how *bsd people don't get all up in arms about their core system pieces being in one repo, but the linux world loses their minds when sprawling messes get a little more consolidated even though it's for the better.
You say that the mono-repo contains a collection of "related" projects, but how many of those projects is it possible to install and use without installing and using at least one other project from the same repo?
It's possible to have a system with "ls" and without "grep", and vice versa, at least in principle. More importantly, it's possible to replace "ls" with a competing implementation, without having to change "grep". The systemd ecosystem is not structured in a way that lets alternatives be explored.
As cycloptic mentioned, journald is one of the few tightly-coupled components.
The difference is the utilities you mention interoperate at the level of bare UNIX pipes and execv/argv. Systemd components are largely integrated via dbus (UNIX domain sockets), as they're mostly services, daemons, which users don't generally interact with via execv/argv.
You're comparing apples and oranges here, and I'd like to note that GNU has already consolidated a lot of those CLI utilities into monorepos and I expect more consolidation like that to happen in the future as it's a natural evolution as the system stabilizes and active developers move on to other projects.
I think your argument would be more valid if systemd weren't establishing stable dbus interfaces, and instead were inventing all sorts of snowflake, constantly changing interfaces, but that simply isn't the case.
We already have examples of systemd components being forked and used independent of the project, to fulfill some of those interfaces without bringing in the entirety of systemd. [0] [1] I have mixed feelings about those efforts, but it at least demonstrates an ability to relatively trivially break off pieces you like and leave out the stuff you don't.
> I think your argument would be more valid if systemd weren't establishing stable dbus interfaces, and instead were inventing all sorts of snowflake, constantly changing interfaces, but that simply isn't the case.
This didn't _used_ to be the case, but then I just looked it up, and… Yay, it actually is now! † I just want to say thanks (to the whole systemd team) for that!
>but how many of those projects is it possible to install and use without installing and using at least one other project from the same repo?
Nearly all of them. Have you actually tried to do this? The only thing I can think of off the top of my head that won't really work separately is journald.
People actually doing this (i.e. trying to use systemd components on a non-systemd system) end up forking the critical bits and pieces, because trying to build and use them directly from upstream doesn't work well.
So yes, systemd is a mono-repo containing a bunch of loosely-coupled projects, but they are still coupled too tightly to sanely distribute and use separately without a fork.
> but they are still coupled too tightly to sanely distribute and use separately without a fork.
That's not true, forking becomes necessary when what you actually want is a different implementation fulfilling the same dbus interface.
If you just wanted intact systemd-logind and none of the rest, you could fairly trivially build systemd from source and package just logind and libsystemd and get on with your life. Maybe you'd have to carry some patches to inhibit some things like cgroups meddling in the systemd way, but that's no different than what say Debian does for practically every upstream tarball it packages.
Those projects have in a very real sense forked the components for the purposes of modifying their implementations in ways too substantial for some small packaging-time patches to cover.
I'd argue that it actually speaks to the modularity and organization of systemd's code that forking was a more attractive option for these folks than starting over with just the dbus interface in hand.
Systemd didn't take this over, nspawn is a pretty small wrapper around functionality that already existed. It turns out containers are not really that special compared to services, and most of the plumbing was already there in the service manager anyway.
> nspawn is a pretty small wrapper around functionality that already existed. It turns out containers are not really that special compared to services, and most of the plumbing was already there in the service manager anyway.
That's more than a little misleading. It's not like nspawn just calls into the service manager to get things done on its behalf via dbus or something like that.
If that were the case, rkt would only have worked on systemd hosts, since it used nspawn to setup its containers.
While it's true nspawn shares a bunch of code in common with the service manager, being in the same repository, it's a substantial program on its own and can function entirely independent of the service manager.
There was a time when nspawn actively required running on a systemd-booted host, but it was completely unnecessary and that check was removed while rkt was being developed. [0]
It's not some thin little ergonomic wrapper around existing service manager facilities.
Additionally there is a lot of shared functionality in libsystemd. Take a look at the rest of the code in nspawn and see how little it actually accomplishes.
No, it literally doesn't. That's just registration with the service manager, and it's optional. Basically it's to make the service manager aware of nspawn's actions, when it's on a systemd host.
I already pointed out they share a lot of code. The service manager process doesn't do squat on behalf of nspawn.
It doesn't matter that it's optional and you could use some other service manager. The minimal amount of stuff it does is not really that useful without registering with a service/container manager. Of course it doesn't have to be systemd and machinectl, but anything else would have to implement the same dbus interface if it wanted to work the intended way. My point is that nspawn would not have been written if it couldn't piggyback on this work that was already done. Otherwise all you have is a cgroup, some firewall rules and some mounts in a random folder, which as demonstrated here recently, can just be done with a small bash script.
This 'joke' has been repeated so many after every single release or even mention of systemd that it utterly baffles me how somebody could actually type it again.
systemd is a container runtime even without nspawn... you can control all of the namespaces and control groups via regular service units. Not sure if you can pivot_root too, but I would not be surprised.
