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

[Alex Carver]

On 2015-09-12 16:07, Solomon Peachy wrote:
> On Sat, Sep 12, 2015 at 03:33:32PM -0700, Alex Carver wrote:
>> It's a bit confusing and probably not well written but when trying to
>> find any information on something very new and unfamiliar it's hard to
>> separate out any mistakes.
> 
> Fair enough.  there's no shortage of bad or confusing documentation out 
> there.  I'm personally responsible for far more than I care to admit.  :)
> 
> But in this case, they were using PulseAudio as common system service 
> that could be started up via systemd.

Ok, that's fair, confusing but fair.  I think documentation like that
should first define the absolute core of something and then clearly mark
"this is an optional thing" as an add-on.

>> Ok, no one ever describes *how* nor do they ever really mention it.
>> It's not even in the FAQ on the project page.
> 
> From the systemd man page: 
> 
>   SIGTERM:
>            Upon receiving this signal the systemd system manager serializes
>            its state, reexecutes itself and deserializes the saved state
>            again. This is mostly equivalent to systemctl daemon-reexec.
> 
> The recommended way is using the systemctl invocation, which is also in 
> the systemctl man page:
> 
>        daemon-reexec
>            Reexecute the systemd manager. This will serialize the manager
>            state, reexecute the process and deserialize the state again. This
>            command is of little use except for debugging and package upgrades.
> 	   [ .. and some more stuff .. ]
> 
> FWIW your distro upgrade scripts should automatically invoke this.

It's not so much that I need to invoke it, it's trying to understand and
obtain information that says "this is not going to need to reboot to do
an update".  The idea here is no surprises.  I would be livid if I were
to put together a new machine that ran something like systemd, get
everything configured and then suddenly find out "oh, every single
update is going to require a total reboot".  There are enough flaws in
software (especially something as big as systemd) that patches are
frequent.  At least right now I don't have to reboot except for the
occasional kernel patch, everything else restarts.  But this kind of
thing is not clear up front, it's buried in a man page.  It should be in
a FAQ or as its own up-front key feature bullet list item.

> 
> In the most basic sense, to bring up your own network you'd create a 
> systemd 'network.service' definition that includes the details on how 
> you want your network to be brought up -- eg a set of command 
> invocations, or invoking a dhcp client.
> 
> To run a dhcp server, you'd just create a 'dhcpd.service' definition 
> that includes details on how to get your preferred dhcp server running.  
> You'd probably want it to depend on network.service' since it's rather 
> useless without the network being up (and can be made to automatically 
> restart should the network itself be restarted)
> 
> How you make these things interact is actually up to you.  They provide 
> recommendations for best practices, but you're free to ignore all of
> that.

So, in theory, I could tell systemd it can start up services that I
create and define using only the tools/software that I want even if it's
available with a built-in module and then never touch them again no
matter what unless and until I invoke a stop/start manually?