[HEADS-UP] systemd for F14 - the next steps

Lennart Poettering mzerqung at 0pointer.de
Wed Jul 14 20:24:44 UTC 2010


On Wed, 14.07.10 14:28, Bill Nottingham (notting at redhat.com) wrote:

> > And the admin could even define additional targets, to achieve different
> > system profiles he can boot into or switch forth and back to and from,
> > and give it arbitrary names, and even pull in any of the targets we ship
> > by default.
> 
> The issue is that this is a behavior change (from both sysvinit and upstart)
> that will need code to be handled properly in other packages. Anaconda,
> at least, will need to be patched to set the default bootup target
> differently depending on which init system it's installing, which
> is kind of ugly.

Hmm, can you please elaborate on what you think anaconda should be
writing into that file?

Also, is there something easier then calling symlink(2)? Way easier than
patching config files at least...

> If I must ask, what's gained by the change in implementation and
> nomenclature here? All of these existed before as runlevels, and at least
> with sysvinit, the administrator could define their own custom ones.

"Any customer can have a car painted any colour he wants so long as it
is black."    -- Henry Ford, when he designed sysvinit.

sysvinit allows you to have exactly 4 general purpose runlevels, which
have the superbly descriptive names "2", "3", "4", and "5". And that's
where the story ends. In systemd the model is much simpler, more obvious
yet more powerful: target units can be labeled freely and you can have
as many as you want.

On top of that they can be explicit supersets of other targets, and they
follow the same synchronization logic as any other unit. You can alias
targets (i.e. make them accessible under more than one name), and you
can even activate multiple of these at the same time (and this is
actually used by default, for example there is
"bluetooth.target"). Yippieh, yippieh, yeah!

You really cannot see why runlevels are old cruft and completely
arbitrary in their design and naming, and really need replacing?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the devel mailing list