[ale] [Fwd: Advertising on ale.org] - OT MS vs Apple vs Linux/UNIX
Michael B. Trausch
mike at trausch.us
Sat Sep 12 14:43:51 EDT 2015
On Sat, 2015-09-12 at 11:08 -0700, Alex Carver wrote:
> 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.
Pulseaudio is its own dæmon. I do not have it on any of my embedded
systems (even the testing ones). You can still communicate directly
with ALSA just fine.
Offer of proof: Fedora 22 is a systemd-based system. Pulseaudio is
started as part of the X11 startup process or the user session. The PA
daemon runs as user gdm or user $UID, and is not started by the system.
PulseAudio can make use of the udev library to simplify the process of
finding hardware sound interfaces. One of the points of udev and
dynamic device management is that nothing is loaded if there isn't a
reason for it (or rather, that capability exists: it is possible to run
legacy code that is unaware of udev, which may or may not work in
modern systems anyway.)
Additional offer of proof: The PulseAudio package is a set of packages,
none of which are part of systemd. PulseAudio can be killed with the
only ramification being that your software will either need to manually
or automatically fall back to using ALSA's interface, which may or may
not support simultaenous playback of multiple streams (again depending
on the ALSA configuration and the hardware which backs it).
Final proof: The PulseAudio package depends on systemd as built in
Fedora 22 (not the other way around). Attempting to remove PA from the
system will succeed (but due to the way that the Fedora packagers built
the system, this removes a lot of useful functionality, such as GNOME).
Though not as much as I would have expected, really:
> [mbt at aloe ~]$ sudo dnf remove pulseaudio
> [sudo] password for mbt:
> Dependencies resolved.
> ====================================================================================================================================
> Package Arch Version Repository Size
> ====================================================================================================================================
> Removing:
> alsa-plugins-pulseaudio x86_64 1.0.29-1.fc22 @System 104 k
> gdm x86_64 1:3.16.2-1.fc22 @System 3.3 M
> gnome-bluetooth x86_64 1:3.16.1-1.fc22 @System 83 k
> gnome-classic-session noarch 3.16.2-1.fc22 @System 114 k
> gnome-initial-setup x86_64 3.16.3-1.fc22 @System 2.1 M
> gnome-shell x86_64 3.16.3-1.fc22 @System 9.2 M
> gnome-shell-extension-alternate-tab noarch 3.16.2-1.fc22 @System 9.4 k
> gnome-shell-extension-apps-menu noarch 3.16.2-1.fc22 @System 27 k
> gnome-shell-extension-background-logo noarch 3.16.1-1.fc22 @System 56 k
> gnome-shell-extension-common noarch 3.16.2-1.fc22 @System 542 k
> gnome-shell-extension-launch-new-instance noarch 3.16.2-1.fc22 @System 4.9 k
> gnome-shell-extension-places-menu noarch 3.16.2-1.fc22 @System 22 k
> gnome-shell-extension-user-theme noarch 3.16.2-1.fc22 @System 7.0 k
> gnome-shell-extension-window-list noarch 3.16.2-1.fc22 @System 55 k
> gnome-tweak-tool noarch 3.16.2-1.fc22 @System 941 k
> pulseaudio x86_64 6.0-8.fc22 @System 3.3 M
> pulseaudio-gdm-hooks x86_64 6.0-8.fc22 @System 354
> pulseaudio-module-bluetooth x86_64 6.0-8.fc22 @System 170 k
> pulseaudio-module-x11 x86_64 6.0-8.fc22 @System 61 k
>
> Transaction Summary
> ====================================================================================================================================
> Remove 19 Packages
As you can see, systemd fares just fine and no attempt is made to
remove it.
>
>
> 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.The answer is, as always: "it depends". On a great deal.
Method 1: Memory hot patch. Sure, you can. It's about the only way to
update PID 1 ***WHILE IT IS RUNNING***. This is the same regardless of
the PID 1 implementation used.
Method 2: Package update and re-exec. Systemd supports this
('systemctl daemon-reexec). This allows you to upgrade systemd and
restart PID 1 without a reboot.
Method 3: The Old Way. Update the thing and reboot.
Note also that systemd comprises more than just PID 1. As with any
dæmon, you must restart the dæmon for the update to take effect. If
you're doing a system update wherein you've updated a substantial
number of dæmons, it is often faster to reboot than restart them all at
runtime. However, systemd allows both options, giving you the choice
in how you want to manage your update application procedures.
The upside is the time saved: If you start dæmon X, which depends on Y
and Z, where Y and Z were only started for X, then they'll get
restarted too. Automatically.
The additonal upside is that if your service is socket activated, NO
ACTION IS NECESSARY AT ALL. The service update will apply after the
next time the process recycles itself, which you can force to happen at
any time with standard POSIX signals.
>
>
> 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?Sure. Nothing forces you to use the components of systemd in a systemd
based system. You can refuse to use networkd or journald if you wish.
Systemd allows you to hard-mask any unit it knows about by using the
SA-override directory /etc/systemd, and symlinking the unit to
/dev/null. See also systemctl disable and systemctl enable. Want to
use ISC DHCPd? Go for it. Want to take IPv6 configuration away from
the kernel and move it to ISC DHCPd? Sure, can do that too. Want to
use MySpecialNetworkD to handle everything for you, pulling rules from
https://example.org/system_$UUID? Well, you can do that, too.
Your options are exactly as constrained as they've been in the past.
Which is to say, they're not.
>
> 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've found no real lacking in the documentation for systemd; however,
as with any system, you need to read all of the documentation at some
point to make sense of it. That said, systemd provides a simple and
straightforward interface, which itself is inspired in parts by the
major bolt-on additions to the init system which Debian and Red Hat
maintained in their own distributions for years. (Just why do you think
that they were both willing to adopt systemd in the first place?
Unified infrastructure and Don't Repeat Yourself are concepts which we
all benefit from.) See Debian's public voting system for more
information, but they've both adopted the use of systemd, and
subsequently adopted a resolution stating that no specific resolution
was required to address init system coupling between packages.
>
>
> 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.
Good thing is that you don't have to. It just works.
Also, please show me some of this "horrible documentation" that you're
talking about. I've used only the documentation. I've never needed to
ask the Giant Asshole or any of his minions for help or assistance in
any aspect of using or managing systemd. The man pages are very well
-written (and aren't giant rambling tomes as can be found in GNU
documentation). There are a lot of man pages, sure, but that's because
systemd takes the approach of breaking down the entire world into
small, manageable problems. There are many different unit types,
specifically because of the fact that system maintenance and management
is a messy thing to do.
Systemd gives the system administrator a SINGLE interface for managing
"the system". If you still want to do your piecemeal management, you
sure can. It's up to you. Nothing is forced on you. You can mask the
entire new world if you want, and only run your old systems if you'd
like. Personally, I find it much easier to update my software for the
new world: I get to drop several kilobytes of code from hardware
drivers and daemons, and get a more robust system as well. How that's
not win/win, I don't know.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20150912/c30da8f0/attachment.html>
More information about the Ale
mailing list