[ale] [Fwd: Advertising on ale.org] - OT MS vs Apple vs Linux/UNIX

[Alex Carver]

Ok, so serious questions, then, that no one ever seems to answer online
that I can find:

1.  If a feature of systemd is not needed at all, does it still load?
Case in point, according to the docs PulseAudio is a core module of PID
1.  If I have no audio hardware, is that still going to be in the memory
footprint?  It appears from some reading that the packaged versions that
would come with any major distro would have every single module built in
which case the only way to turn things off is to compile systemd from
scratch.  I can't find anything about turning features off if the
compile-time switch was turned on.

2. Can I patch a piece of systemd without forcing a reboot?  Right now
most things except the kernel can get restarted individually without
bringing down the whole system.  There's no indication that systemd can
be patched piecemeal.  At the moment it appears that if a flaw is found
in any portion of systemd, the whole thing would have to be patched and
then rebooted.

3.  For some of the more unusual inclusions in systemd (e.g. DHCPd) is
it possible to turn that feature off, remove its memory footprint, and
replace it with another?  I use DNSMasq as my DHCP daemon because of a
lot of flexibility in the way it hands out leases.  From the
systemd-devel posts:

systemd-networkd learnt minimal DHCPv4 server support in addition to the
existing DHCPv4 client support. It also learnt DHCPv6 client and IPv6
Router Solicitation client support. The DHCPv4 client gained support for
static routes passed in from the server. Note that the [DHCPv4] section
known in older systemd-networkd versions has been renamed to [DHCP] and
is now also used by the DHCPv6 client. Existing
.network files using settings of this section should be updated, though
compatibility is maintained. Optionally, the client hostname may now be
sent to the DHCP server.

So it's a "minimal DHCPv4 server".  If I want something more than
minimal, can I turn it off completely and put in a replacement?


Maybe some of the angst would calm down a bit if the developers and
documenters would actually explain these things instead of just saying
"look what new feature we added".  That's mostly what I see on that
-devel list, a lot of excitement about pulling in yet another feature
but no real documentation about what to do when it doesn't fit a need.

I can't afford to "just try it", I have to know many of these things
ahead of time.  But the very act of asking these questions sends a lynch
mob after me with the "just use it and shut up" mantra.  I did dig
through a lot of documentation and ask some questions elsewhere prior to
creating my opinions.  I was trying to give it the benefit of the doubt
but the documentation I can find is so poor or inapplicable to the use
case (meaning supplied as a distro package rather than built from
source) and the responses to questions terrible that I gave up and just
couldn't support the change to systemd.


On 2015-09-12 10:32, Michael B. Trausch wrote:
> On Sat, 2015-09-12 at 13:26 -0400, Michael B. Trausch wrote:
>> At the end of the day, it saves time and resources for those of us
>> who make our living managing systems.  For my part, I manage things
>> ranging from smaller than the Rπ to larger than a 1U. And systemd
>> saves me time and resources across the board.
> And just to clarify here: While some of my real small systems are only
> using systemd in testing, as I mentioned several emails back, this is
> just lack of time to move it to production on my part.  I've done
> enough work to see for myself the benefits of moving.
> And one more clarification:
>> udev provides a much more convenient method of handling things than
>> standard scripting. If you need to load a userspace driver to handle
>> a particular USB device (e.g., a generic HID sensor not handled by
>> the kernel, or something similar), then you plug the rule in and
>> systemd/udevd make it happen. (Of course, you do not need systemd for
>> udevd, but since systemd and udevd play very well together, it'd be
>> silly to not use it.)
> Not only is this a benefit all by itself, but it means userspace
> drivers no longer have to internally reproduce the logic required to
> find their devices.  Udev tells you your device node for the userspace
> driver.  This allows me to cut out the probe logic which traverses
> sysfs or devtmpfs directly, which is error prone and can screw up other
> similar-looking devices. In other words, it's more robust by design
> than The Old Ways.  And that's kinda the whole gist of
> systemd/networkd/journald/etc.: small, robust tools.
> "systemd" refers to more than PID 1, but it also contains more than
> /sbin/init.  It's true to its name, otherwise it'd have been called
> sysinitd, and not systemd.