systemd (Was Re: tmpfs for strategic directories)

[Casey Dahlin]

On Tue, May 25, 2010 at 05:45:07PM +0200, Lennart Poettering wrote:
> On Tue, 25.05.10 10:21, Casey Dahlin (cdahlin at redhat.com) wrote:
> 
> > 
> > On Mon, May 24, 2010 at 09:05:31AM -0400, Tom spot Callaway wrote:
> > > On 05/23/2010 04:19 AM, Kevin Kofler wrote:
> > > > Lennart Poettering wrote:
> > > >> So far response from the community has been very positive, but we didn't
> > > >> have a fedora-devel discussion about this yet, so we'll have to see
> > > >> whether we can somehow make the broader community as enthusiastic about
> > > >> the whole idea as I am. ;-)
> > > > 
> > > > I, for one, think systemd should be the default ASAP.
> > > 
> > > Perhaps the first time I can recall that we have agreed. ;)
> > > 
> > > ~spot
> > 
> > Any particular reason on either of your parts?
> > 
> > Just about everything in systemd is either set to be in upstart (simpler
> > dependency syntax, xinetd-style service activation) or was discarded by it
> > years ago (cgroups are a dead end).
> 
> Oh, is that so? 
> 
> Have you actually read the blog story I put together? 
> 

Yes, but I'm going to go read it again just to be sure.

> Why do you say "cgroups are a dead end"? Sure, Scott claims that, but
> uh, it's not the only place where he is simply wrong and his claims
> baseless. In fact it works really well, and is one of the strong points
> in systemd. I simply see no alternative for it. The points Scott raised
> kinda showed that he never really played around with them.
> 
> Please read up on cgroups, before you just dismiss technology like that
> as "dead end".
> 

I did. When upstart was about to use them. 2 years ago. We chucked them by the
following LPC.

The problem we've found is that cgroups are too aggressive. They don't have a
notion of sessions and count too much as being part of your service, so you end
up with your screen session being counted as part of gdm.

This is why setsid was added to the netlink connector.

> > The assumption that just because its new means its more advanced is in this
> > case a bit misguided.
> 
> Well, please read the blog story. I know it's long, but it should be an
> interesting read. The whole point of the blog story is to make clear the
> reason systemd exists is purely technical, and that we think our design
> is simply the better one.
> 

So you have:

1) Socket activation. Part of Upstart's roadmap. Would happen sooner if you
cared to submit the patch. We don't think its good enough by itself, hence the
rest of Upstart, but a socket activation subsystem that could reach as far as
systemd and even work standalone in settings where systemd can work is
perfectly within Upstart's scope. I'd be happy to firm up the design details
with you if you wanted to contribute patches.

2) Bus activation. Missed opportunity here to actually become the launchpoint
for activated services. I won't criticize that too much though, as its
usefulness is largely dependent on kernelspace DBus, which I've been trying to
bludgeon Marcel Holtmann into turning over to the public for a year now.

3) Cutting down on the forking by replacing some of the shell scripts... cool
   3a) With C code... really?

4) Process environment control. No complaints, and also nothing Upstart doesn't
want to do.

> We did systemd because we thought that technically Upstart is
> fundamentally flawed and misses out on so many opportunities.
> 

And we think the same of systemd.

> And if you cannot see that then I can only beg you to read the blog
> story, because it goes into much detail about all the technical
> features.
> 
> Please, judge systemd on technical grounds, don't judge it on political,
> or emotional grounds.
> 

Not to be specifically political, but did you ever consider submitting systemd
itself as a patch? Literally:

diff -pruN ~lennart/coding/upstart ~lennart/coding/systemd

And mail it to upstart-devel-list. I'm being a bit hyperbolic, but actually not
much. That would have been a valid move.

You should really come work with us. We're fun guys.

--CJD