Another daemon for managing control groups

There are lots of cases where you don't need systemd. For example, Google runs on its servers very static images, that know no hotplugging, that have a relatively static cgroup tree and so on. For them, having something that deals with all the dynamic bits like systemd is far less interesting than for the general audience. And that's totally fine.

Why for heaven's sake should I "provide" a second cgroup manager implementation? I only care for systemd. If people don't want systemd, they can use something else, but why for heaven's sake should *I* provide them the cgroup manager for that? My interest is making systemd good, and minimal, and integrated. I am certainly not compromising that in major ways, just to solve problems for people who hate anyway what we are working on? That's pointless, we cannot win that anyway.

If you say we don't work with any alternatives, then a) there acurrently are no alternatives, your story is about code that doesn't exist, about nothing but plans, that haven't even been thought to the end. And b) the work to make this all function in systemd was relatively simple and small, and just makes use of concepts that exist anyway in systemd, like the execution queue, like service management, the dependency tree or device management. We hence got it all done in little time, in in a very nicely integrated uniform way. You can list your cgroups ("scopes" and "slices") next to your services, you can influence them with the same tools, introspect them, and everything. If instead you rip all that out, do it in some separate project, that would be totally new and cross-init system, just to "work with alternatives", then we'd be nowhere, and our code would be much worse and way more complex. So yeah, my priority is quality and simplicity of code and the uniformity and usefulness of the user interface. That's what matters most for me. I will not compromise on that just so that you don't write about us that we "don't work with alternatives".

What you are writing here is not very smart. You are suggesting that I want to make life hard of people who don't want to use systemd. But you are confusing something here: I just *don't care* about non-systemd cases, and I don't have to. I don't care, not because I was evil, just because it's not interesting for my usecase. And I do not actively do anything against alternative impelemtnations of anything (how can I), I am just interested in my own code.

If others don't use systemd and use something else, then that's their choice and *they* have to come up with an alternative implementation, that's certainly not my duty, even if you claim it was.

Over the history of systemd we designed some things which needed little integration with PID 1 in a way that you can split them out and use them outside of systemd. For example, udev, tmpfiles, and hostnamed are components like that. Others OTOH need more integration with the rest of the system and you cannot just isolate them out. Which ones those are are explicitly documented in much detail here: http://www.freedesktop.org/wiki/Software/systemd/Interfac... -- we did that as a service to the people who don't use systemd as PID1. How nice of us! You should appreciate that. It's a question of honesty to list explicitly what is separable and what is not, and so we did that. If something is not separable, then that's due to technical reasons, that's all. And you should grant us that. SO much respect is necessary.

Anyway, Jake, I really don't appreciate what you are writing here. You shouldn't imply that we had ill intentions or when we don't. We don't force anyone to anything. We make an offer, we even make it easy to take only parts of the offer. It's all free. We aren't the only coders around, so if you don't like something, pick something else.

Jake, not cool. Not cool at all.