[Novalug] dynamic symbolic links

Bryan J Smith b.j.smith@ieee.org
Sat May 2 21:32:33 EDT 2015


On Sat, May 2, 2015 at 9:15 PM, James Ewing Cottrell III via Novalug
<novalug@firemountain.net> wrote:
> You missed the point. I eat Manuals for Lunch, but Systemd is not helpful.
> Even Bryan said that 90% of what he knows is from LP Tutorials.
> Perhaps it's not Systemd itself that is Bad...perhaps the Man Pages are.

Ummm ... dude ...

Man pages on "systemctl" aren't going to teach you systemd any more
than "virsh" will teach you KVM.

Now once you know systemd and have run "systemctl" a few times, the
man page is useful for remembering an option.  Just like "virsh" is
for KVM.

> I am willing to Change My Argument.

Here's the deal ...

People can argue about all sorts of things that are built around the
systemd "ecosystem."  Many have valid arguments.  In fact, I noted
there are no less than seven (7) things people blame systemd for, but
only three (3) are even related to systemd, and only one (1) is the
"core" init (it's modular people!).**

But if you haven't experienced the bliss of regular usage of
"systemctl" command that is the core of systemd, then you really will
never appreciate systemd.  Once you start using it regularly, you
_never_ want to go back.  Unless, of course, you have given yourself
job security writing hacked up scripts.

Like those around grep'ing "ps" and "syslog".  ;)

-- bjs

P.S.  The seven (7) things people blame systemd for ... (only the
first 2 are valid)

A)  Actual systemd

The systemd "program" and core *ctl commands (e.g., systemctl) -- yes,
this is the only "monolithic" portion, like any other init solution.

B)  Supporting *d/*ctl components

The additional *d/*ctl components that are part of the systemd project
(e.g., journald, udev, etc...) that add capabilities.  These are _not_
"monolithic" portions of systemd.  They are modular, separate
components, many of which _can_ operate _independently_ of systemd.

C)  Recommended file path and other changes

The select, "recommendations" made by various people associated with
*d/*ctl services/tools that distros have decided to adopt.  Ironically
most of these are "Debian-like," removing a lot of Red Hat'isms and
SuSE'isms in an attempt to standardize around Debian defaults,
whenever they vary from universal locations.

D)  Non-supporting *d/*ctl components

The quite separate *d/*ctl compnents that are not part of the systemd
project (e.g., firewalld, libvirtd, NetworkManager/nmcli, etc...).
Just because their systemd service units are very capable, doesn't
mean they are remotely related to systemd.

E)  All those added "server-lets" (as I call them)

The high rate of submissions for "service-lets" to the systemd Project
that are much like different userspace support and other additions to
the kernel, but not part of the kernel, but maintained at kernel.org
or separately by various kernel maintainers.  This is where 99% of the
complaints of "do one thing and do it well" come from, and are
_neither_ systemd itself _nor_ even the "supporting" components like
journald, udev, etc...  And they are _not_ part of the monolithic "A"
at all.

F)  Nomenclature changes

The quite unrelated "configuration/rule" changes that are not part of
the systemd project (e.g., OEM udev nomenclature pre-systemd, various
configuration and program changes, etc...).  Just because udev is part
of systemd doesn't mean the rules are systemd.  Most are not, although
systemd _did_ adopt them as part of udev.

G)  Library, command, feature, etc... changes

Countless, various changes that have already occurred, sometimes 10-15
years ago, that people don't realizes are not even associated with any
*d/*ctl service/program at all, not even time-wise (e.g., ip*
commands).



More information about the Novalug mailing list