On Wed, 14.07.10 14:28, Bill Nottingham (notting@xxxxxxxxxx) 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
