On Tue, 25.05.10 09:00, Jeff Spaleta (jspaleta@xxxxxxxxx) wrote: > > On Tue, May 25, 2010 at 7:45 AM, Lennart Poettering > My one concern about the current discussion is that the decision to > move to systemd in the timeframe of F14 is being rushed ahead of the > aforementioned technical judgement. I can understand your personal > enthusiasm for the move as you are intimately familiar with systemd. > But I'm not sure its adequate to rush ahead until we all have a better > feel on how this works in practise... and how much work its going to > take to convert all our existing packages to systemd styled startup. > The back and forth on your blog between yourself and Tim Waugh about > cups service activation, for example, is something I think we all need > to understand. I think there is a lot buried in that discussion about > how complex some of our existing services are going to look under > systemd styled configuration. Yes, if we'd adopt systemd in F14, then this would indeed be very quick. But as mentioned, I have not proposed it yet, and while I currently leaning towards that yes, I will propose it, I'll make my mind up later about this. There is no need to convert all services to the native format right-away. Even normal SysV scripts should boot a little faster with systemd, since we parallelize them to the level the LSB headers allow that. systemd plus the current scripts makes things a bit faster, systemd plus native unit files should make things quite a bit more faster. If we chose to adopt it for F14 it would probably a good idea to have native files for everything that is installed by default at least. I have mostly written those files now, so this goal should not be too hard to reach, if we can convince all the maintainers involved to include them in their packages. Regarding CUPS: systemd supports all triggers for service startup that launchd supports, and Apple (who develops CUPS) is starting it via launchd, on demand. Not sure how nicely CUPS-on-MacOS translates to CUPS-on-Fedora, but we can do things at least as nicely as they are on MacOS. There, CUPS is started whenever 1. a local printer is plugged in 2. a local client wants to access its services 3. there's a file in the printer queue, possibly from before the last reboot We can translate those rules 1:1 for systemd. And then we could optionally add one more rule: 4. start cups anyway, on boot. That way we would still benefit from the fully parallelized bootup the socket based activation allows, but of course lose the on-demand nicety. Implementing rule #4 means adding a single symlink in /etc/systemd/system. We could for example choose to not have that symlink by default, but ask the administrator to create it if he sets up a multiplexing print server the way Tim suggested. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
