Weekly Edition
Return to the Development page
| |||||||||||||
Systemd for Developers II
Lennart Poettering has written a second
installment in his "systemd for developers" series. "This time
we'll focus on adding socket activation support to real-life software, more
specifically the CUPS printing server. Most current Linux desktops run CUPS
by default these days, since printing is so basic that it's a must have,
and must just work when the user needs it. However, most desktop CUPS
installations probably don't actually see more than a handful of print jobs
each month... That all together makes CUPS a perfect
candidate for lazy activation: instead of starting it unconditionally at
boot we just start it on-demand, when it is needed. That way we can save
resources, at boot and at runtime."
(Log in to post comments)
Systemd for Developers II Posted Jul 8, 2011 18:06 UTC (Fri) by thedevil (subscriber, #32913) [Link]
"Most current Linux desktops run CUPS by default these days, since printing is so basic that it's a must have"
A non-sequitur. You only need the cups *client* on the desktop. Of course that's not what distros do by default, but the fact they promote unnecessary bloat doesn't make it right.
Systemd for Developers II Posted Jul 8, 2011 21:30 UTC (Fri) by raven667 (subscriber, #5198) [Link]
What an odd statement. You could only get away with having the client only installed if there was a print server in same broadcast domain sending out service announcements. That condition would only occur in managed environments, in most cases an end user is going to plug a USB printer into their laptop and expect it to just show up and work. Are you expecting that the first time someone plugs in a printer the system should pop up a dialog on the graphical console authorizing a package install for the print server and any additional drivers?
Systemd for Developers II Posted Jul 12, 2011 13:34 UTC (Tue) by nye (guest, #51576) [Link]
He's probably expecting printers to work like other devices, where you don't need to be running a server just to use the damn thing.
Anyway this sounds like the killer feature of systemd since most Linux distributions these days install a boatload of daemons that I will never use [0], and if they're only activated on demand then that should mean all I'm paying for is the disk space (and the time spent inevitably spent installing endless updates fixing security bugs).
And come to think of it:
What exactly is wrong with this? In fact, isn't that *exactly* how it should work? Nobody seems to mind when Windows does that, and it's rather worse there since it's somewhat less likely to be as simple as 'please authorise this and it will be sorted for you'.
[0] Rant follows; please disregard:
Systemd for Developers II Posted Jul 13, 2011 10:43 UTC (Wed) by elanthis (guest, #6227) [Link]
With your Windows example you are confusing two separate things: the event when you plug an unknown new printer into a machine for the first time, and the event when you plug a known printer into the machine. Windows and Linux both need a dialog in the first place to configure the printer. In the second case, no dialog should ever be required.
Also, many drivers require daemons to work properly, especially when those drivers are for very complex devices or for network-attached devices. Printers are complex due to the queing requirement (even if you are a single user printing a single document, pages are queued due to the small buffers on most consumer grade printers) and are often networked.
A ton more drivers also just require X to be running to get proper support, which is of course another daemon. :)
Systemd for Developers II Posted Jul 13, 2011 11:23 UTC (Wed) by nye (guest, #51576) [Link]
>With your Windows example you are confusing two separate things: the event when you plug an unknown new printer into a machine for the first time, and the event when you plug a known printer into the machine. Windows and Linux both need a dialog in the first place to configure the printer. In the second case, no dialog should ever be required.
I wasn't confusing anything; I was specifically talking about the first case.
>Also, many drivers require daemons to work properly, especially when those drivers are for very complex devices or for network-attached devices. Printers are complex due to the queing requirement (even if you are a single user printing a single document, pages are queued due to the small buffers on most consumer grade printers) and are often networked.
Most of the time though this shouldn't require everyone to be running a dedicated daemon preëmptively in case a device of that nature ever shows up. *One* daemon watching for new devices should suffice - isn't this what udev is for?
It looks like systemd's on-demand activation is solving the 'extra daemon' problem, but it still seems like an odd way to do so: we're running CUPS when it's not needed, but rather than fixing that we're adding an extra step where it's sort-of-started but we're not paying for it yet. It fixes the symptom but the underlying problem remains.
And CUPS by no means the only offender here; Bluetooth is another example. Bluetooth controllers are something you find only on moderate- to high-end laptops, but rather than detect that there isn't one, the installers of modern desktop distros make everyone pay for it by default on the chance that one might be added in the future.
Anyway I think the socket activation is probably the killer feature for systemd (it's the only thing that's looked at all interesting to me at least), but I can't shake the feeling that it's mostly there to solve problems that shouldn't have existed in the first place.
Systemd for Developers II Posted Jul 13, 2011 11:48 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
Bluez has been demand activated for some time on Fedora, at least. It'd be possible to add infrastructure to support installing it on demand rather than starting it on demand, but I don't know that having an install dialog pop up the first time I enabled bluetooth would be less anger-inducing than the loss of a relatively small amount of disk space on systems without bluetooth.
Systemd for Developers II Posted Jul 13, 2011 12:13 UTC (Wed) by nye (guest, #51576) [Link]
>Bluez has been demand activated for some time on Fedora, at least
That's good to hear - I haven't done a Fedora install in a while. It doesn't seem to be the case on Ubuntu but that could have changed recently too.
Is there some reason why udev can't be used for on-demand activation in general? Is it actually unsuitable or was it just too new/nonexistant when the decision was originally made to keep a number of daemons running 'just in case'?
|
|||||||||||||