[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: End of hypocrisy, beginning of reason



On Tue, 5 Aug 2014 12:32:48 -0400
Steve Litt <slitt@troubleshooters.com> wrote:

 >When I switch to systemd, I'd like to have it as isolated as humanly
 >possible, just because I'm a modularity kind of guy.

I've been watching the thread here... and I understand the thought of
not changing from sysvinit because sysvinit works well [sometimes] ...

But here you've made a point that should lead you directly to use
systemd over sysvinit... especially Debian styled sysvinit.  Note this
snippet of documentation from Fedora's systemd documentation.

...
systemd has the concept of targets which is a more flexible
replacement for runlevels in sysvinit.

Run level 3 is emulated by multi-user.target. Run level 5 is emulated
by graphical.target. runlevel3.target is a symbolic link to
multi-user.target and runlevel5.target is a symbolic link to
graphical.target.

You can switch to 'runlevel 3' by running
...

Source:
https://fedoraproject.org/wiki/Systemd#How_do_I_change_the_target_.28runlevel.29_.3F

In Debian sysvinit, there are pretty much 2 runlevels.  Sure, the user
can configure the init scripts to run at the "correct" moment during
the boot process, but systemd brings a huge advantage to the table by
discarding the idea of large slots to start things.  It's like going
from 8 character long file names in MS DOS to 255 in a *nix environment.

I understand the desire of"K.I.S.S.", but the reality is that sysvinit
is already massively complex and for all intents and purposes
is monolithic in nature.

As a side note:  I've converted all my personal machines to systemd,
and I've yet to run into any problems.  I don't usually use the systemd
utilities to start and stop services or check logs, but that's mostly
habit rather than an actually problem with systemd.  In some cases, I
have noticed that the verbosity is on the thinner side with journald --
but it's likely there's a setting somewhere that will change that to my
liking.

Lastly, if sysvinit is no longer a component of any major distro --
likely true -- then sysvinit will quickly go unmaintained.  Regardless
of the desire to change, it's better to get onboard [whether it's
kicking and screaming or just bobbing along with the crowd] rather than
remain on the platform holding the bag of growing vulnerabilities...

Just these 6 cents -- and out...

--Andrew


Reply to: