On Wed, Jul 22, 2015 at 12:59:56PM +0200, Laurent Bercot wrote:
> On 22/07/2015 10:00, Oz Tiram wrote:
> >One argument I hear often about systemd is that it more adapted to current hardware needs, [e.g. here][1]
> >
> > > Computers changed so much that they often doesn’t even look like
> > > computers. And their operating systems are very busy : GPS, wireless
> > > networks, USB peripherals that come and go, tons of softwares and
> > > services running at the same time, going to sleep / waking up in a
> > > snap… Asking the antiquated SysVinit to manage all this is like asking
> > > your grandmother to twerk.
> >
> >What I don't understand is how an init system manages hot pluggable devices.
> >What does replacing a hot plugable disk drive it have to do with how the system is booted?
> >Maybe this all done at the none init parts of systemd?
>
> Hi Oz,
>
> Don't believe everything you read on the Web. ;)
> The author of the article has already adopted systemd's point of view, which
> is "one init should do everything", without even being aware of it.
>
> The truth it, you're perfectly right: it is not init's job to manage hot-
> pluggable devices. There is NO reason why init should be made aware of
> those kernel events, and the "systemd can manage modern hardware" meme is
> but a pile of propaganda.
> Any init system, including sysvinit, will work just as well: managing
> hotplug is udev's job, and anything implementing udev functionality will
> do. udev predates systemd, so systemd did not invent the feature; it
> just took udev and integrated it tightly to make itself unavoidable,
> a.k.a. virus tactics.
>
> eudev and vdev, as well as other udev-like daemons, prove this is not
> necessary. So you can safely ignore the article, written by someone who
> has a wrong idea of what init is supposed to do.

In general, I'd agree with you, but there are some situations where it's
possible to argue for hotplugger/service manager integration:
if you hotplug a scanner or printer, there's reason to think that the
corresponding daemon (sane/cups/lprng/lpr) should start.
Note that I did not say that I think it's a good argument.

The obvious defect in this approach is that there *are* network scanners
and printers, which cannot be hotplugged. A less obvious obnoxious
detail is the sudden demand on system resources, and the delay before
the service is available.

One alternative to this approach would be socket activation, but...
using cups with inetd would really suck, given that it's pretty slow
to start.
Socket activation as done in systemd and upstart (wait till the first
connection, then start the service) could sort-of-work, though the
first print will always be slow.

None of these are actually 100% reliable, since you have a service
starting upon some request; if there isn't enough RAM, it falls flat.
But then, printing involves spawning filters anyhow, so it would have
that problem (to a lesser degree) anyhow.

Anyone who says systemd is necessary because of wireless networks is
talking out of their hat if they mean 802.11. You have to use
wpa_supplicant if you want to handle those, and it's perfectly adequate.
A similar observation is true for GPS: just leave gpsd running, and
it will only start up the GPS when needed.
There is an alternative to gpsd from FDO, but:
-it's less reliable: gpsd carefully avoids as many conditions that may
fail as possible, and the FDO stack was written because the developer
didn't like the fact that that required avoiding malloc().
-it's much less useful: gpsd handles almost every known GPS, while the
FDO stack only supports some NMEA-conformant GPSs.

Overall reaction to the argument:
Expecting init to manage all that is stupid; init should only be concerned
with system processes.

Thanks,
Isaac