Re: [tlug] Um, so... systemd?

[Curt Sampson <cjs@example.com>]

On 2017-01-17 12:05 +0900 (Tue), Kalin KOZHUHAROV wrote:

> I put it in one basket with a bunch of other complex middlewarez (in
> the middle of nowhere, trying to interface) that got introduced a few
> (10?) years ago in a way to "smarten" the linux experience and
> windoze-it more (for the lack of better wording), to make systems
> behave "automagically".

That is not at all what it is. Systemd is doing basically what
existing systems already do except it's now all in one place (rather
than you having to install and use, e.g., inetd and separate
supervisor daemons, configure the process groups yourself, etc.) and
no longer using bad and flakey shell scripts to deal with starting and
stopping processes.

> Some people said debugging init.d problems is hard. Really? Then your
> scrips (i.e. whoever wrote those init.d scripts) was not a good
> developer, didn't document it, didn't make it debuggable.

This, unfortunately, is total rubbish. Due to the nature of how those
shell and those shell scripts themselves work they will never be as
reliable and as easily debuggable as a systemd unit.

As I said in my previous message, go build a systemd unit for a
trivial server and then go build the init.d stuff you need to get the
same functionality. You'll see.

Perhaps we should consider running a workshop where I demonstrate the
systemd way of doing this and you demonstrate the init.d way.

> They use "shell hacks"? Same problem. journald... yeah, logging is
> important! But we had STDOUT (/proc/self/fd/0) since the beginning
> of time and you can redirect it to anywhere since boot, even over
> the whole Internet if you like.

Which is precisely the problem. To start with, you have to write all
the code yourself to handle this redirection and logging of the ouput,
rather than just letting systemd handle it in an easy default way.

> If you want fast boot, just don't boot - start from booted state,
> rsync booted images (RAM snapshots).

And how does this help you after a kernel upgrade, or a crash, or just
when you want to confirm that your startup scripts actually start
things properly?

> And for your laptop/desktop? The longest is usually the
> network/dhcp/wifi and it blocks many services anyway....

Actually, that blocks suprisingly little. In fact, I can't think of
anything off-hand where you'd even need a network connection until
after you've logged in and want to start doing something like browsing
the web.

cjs
-- 
Curt Sampson         <cjs@example.com>         +81 90 7737 2974

To iterate is human, to recurse divine.
    - L Peter Deutsch