systemd (Was Re: tmpfs for strategic directories)

[Lennart Poettering]

On Wed, 26.05.10 10:16, Casey Dahlin (cdahlin at redhat.com) wrote:

> > Who is "we"?
> > 
> 
> Upstart has about 1.7 developers. The 1 is Scott, myself and Johann Kiviniemi
> fight over the .7.

the bzr history tells a different story.

> 
> > > 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.
> > 
> > Well, how exactly you set up the groups is up to you, but the way we do
> > it in systemd is stick every service in a seperate cgroup, plus every
> > user in a seperate one, too. Some examples:
> <snip>
> > 
> > And so on.
> > 
> 
> Someone else already pointed out the issues here.

Hmm, where?

> > enforcement for your services, since you simply have no cgroups. And no
> > nice interfacing with the other libcgroup tools either.
> 
> There's no reason Upstart couldn't offer cgroups for resource limits, its
> just passed them up as a process supervision mechanism. And they are broken for
> the screen case, though perhaps that could be fixed in the kernel.

They are not broken for the screen case, and there is no fixing in the
kernel necessary.

Scott is simply a bit confused about cgroups, there is no screen problem.

> > Well, for once, it would be nice to judge things due to actually
> > existign features, not of big plans nobody is working on as you
> > apparently admit outright.
> > 
> 
> You worked on it, and finished it. You just didn't do it within Upstart. The
> manpower was there it was just misapplied.

Well, in my blog story I tried to explain why we started anew, instead
of "fixing" Upstart. Won't repeat this here.

> > And then, the socket activtion is nice for various reasons, and
> > lazy-loading is just one of them. The bigger advantage is that it does
> > automatic dependency handling -- which of course is nothign that really
> > fits into upstart's design, since that is based on "events" not
> > dependencies -- events are just broken, as I might note. And adding
> > dependency would turn around upstart's design, making it a completely
> > different beast.
> > 
> 
> Event-driven in Upstart's case just talks about the internal operation of
> Upstart. Its rather exposed in current iterations but its just a design
> philosophy. You can implement "dependencies" within it, though in the past
> Upstart has been hesitant with the term because it tends to imply a
> dependency-solving algorithm, where as Upstart provides its dependencies
> reactively, in response to change.

Ah, if events are hidden from the outside in upcoming versions, then
Upstart will become a completely different beast, and reinvent itself
another time completely. Are you sure Upstart is really ready for use if
every version is a complete redesign of what was before, and a departure
from the core design paradigm that the old versions followed?

> > Yes, really. MacOS could do it, and so can we. Its not that hard. And as
> > I my add here I already hacked up a big part of it now for the servcies
> > we start by default.
> > 
> 
> Good for Apple? Maybe now they can design a better kernel? This is linux. We
> configure our systems here.

Well, no need to shut your eyes that Apple is really good at some
things. We should learn from them where it is a good idea. And here they
are a positive example we can be inspired of.

> > OK, I am listening. What's flawed about systemd? I wrote very detailed
> > explanation why Upstart is just wrong in its core design. Please be so
> > kind and be more specific if you claim the same abotu systemd, because
> > otherwise all you are doing is spreading FUD.
> > 
> 
> Apart from the issue of circular dependencies, which I know you've
> already had
> explained to you, I'd like to see how you intend to manage, say

Circular dependencies? I don't think I heard that from you ever. Please
explain?

I mean, dependencies are dependencies. Whether they are configured manually
or implicitly doesn't have any effect on the fact that they are there or
not there. So if there is a dep loop with systemd in place there is a
dep loop without systemd too.

So please, elaborate on this, and tell me exactly what you mean by this.

> Veritas clustering products. Like it or not there are systems out
> there running software that's unstable, not open source, written by
> people who don't like you, will /never/ take your socket passing patch
> and would probably find clever ways to break or do it wrong if they
> did (yes, because of a 10-line patch).

And, so? They can stay sysv init scripts just fine.

> Upstart doesn't ask anything of the userspace it intends to manage, and that
> userspace is a harsher place than you seem to realize.

Neither do we ask anything. Socket actviation is cool, and a nice way to
make things more robust and faster. But it's an optional
feature. You don't have to use it. We support classic non-socket
activation too, and we support classic Sysv too.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4