systemd (Was Re: tmpfs for strategic directories)
mzerqung at 0pointer.de
Tue Jun 1 00:27:34 UTC 2010
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:
> > And so on.
> Someone else already pointed out the issues here.
> > 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
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
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 Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the devel