that's regurgitating systemd propaganda... but that does not make it true ;)
It's common sense; in my Fedora laptop I don't use cups, but it's
started anyway. If I want to optimize the boot time for speed, I need
to manually turn off the services I'm not really using. Presumably
MeeGo is doing the same. However, if the process is not started at all
(with systemd), then I don't need to turn it off.
Since cups is talked to over networking sockets, and not used always, we
use xinetd to start it yes.
you're getting to the whole crux of the problem: some things you need
pretty much always, and some you really want
to start on demand, because they're pretty rare.
In MeeGo we start the things we need always early, because starting them
on demand is the worst thing you can do
for startup performance (you introduce unneeded waits). But things like
cups that are only rarely used we start ondemand
using xinetd or dbus activation or whatever mechanism is appropriate.
But systemd turns the problem around; nothing gets started, unless
it's really used, so there's less need to customize (if any).
systemd turns it into a worst case problem unfortunately, because now you
hit the start latency ALL THE TIME.
this is what I meant with design issues; systemd's design isn't going to
give you a super fast boot. Now
maybe they'll fix it sometime in the future.... but today it makes systemd
entirely uninteresting for booting fast.
yes it'll boot faster than the really really slow existing Fedora, but
that's not an interesting benchmark point.
the benchmark point should be the state of the art, not the worst of the
industry.
I don't know what you call "state of the art", is it a highly tweaked
sequence of events?
we have a optimized critical path, mostly achieved by removing
dependencies that were not needed...
this is a sequential series of events that we just need to get X up and
running.
Then there are the non-critical path components that we start at lower
priority to fill any gaps of CPU
and IO time that might have been left by the critical path. We think we
can achieve this same split between critical and non-critical with upstart.
It's highly optimized, which is different from "highly tweaked" in that
it does not need constant tinkering.
I can get the same on my Fedora system if I want,
but that would require a lot of effort. And that's the point;
constantly tweaking the services to start at the right time simply
doesn't scale. With systemd such tweaking is not necessary.
yeah because with systemd as is you get always the worst case (only
spend the time starting the things up that you end up always starting right
as you need them... which is the absolute worst possible time because it
creates stalls in the boot right where you can't use them).
It's ok to have multiple competing technologies; that's one of the ways
innovation happens in open source.. competition.
Sure, but we are not using any, so I don't see why we should assume
that upstart will be used. I think both approaches need to be
carefully and equally considered.
oh trust me we are looking at all options, very very carefully. That's why I
said that upstart currently is more likely than systemd,
but frankly, for 1.2 we might also just stick with what we have now.. it
works and is fast.
Well, don't take this the wrong way, but I don't trust anyone's word
without evidence. A document explaining such detailed analysis with
hard numbers and preferably the tests to generate that data would be
very welcome. That's what I would consider careful.
MeeGo currently boots in about 8 seconds on a netbook. We're not
starting things we don't need to start.
We start all the things we know we need anyway as early as possible so
we don't need to wait on it later.
We know exactly where we're spending time due to our bootchart tooling,
and what it'd take to boot even faster
(it's not "go to systemd" it is "need less disk size footprint" at this
point)
For us to switch to some other method, and do a lot of work to see where
it ends up, it needs to start with knowing
that the new method gives us something that optimizes either the boot
time or (at the same boot time) the maintenance work.
with upstart we may get some interesting functionality (but we might
just implement those few things ourselves, for reasons GregKH mentioned
before).
with systemd as it is today, we know we'll take 3 steps back in terms of
boot flow. I'm not ready to do that at this point... and I'm not going
to spend too much time on
analysis of systemd until that changes.
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
