|FROM ||Rick Moen
|SUBJECT ||Re: [Hangout-NYLXS] New Distros to try: Please explain what the
|Quoting mayer ilovitz (pmamayeri-at-gmail.com):
> I'm still at 17.1 and probably going to update to 17.3 (which I
> presume is still largely init-based) in the next few weeks pending a
> decision to change to a completely different distro.
> Others can better explain all the issues with SystemD. SystemD
> violates all the classic UNIX principles (programs should be
> (relatively) small, independent, & straightforward in function; use
> PLAIN TEXT log & control files for easy maintenqnce & diagnostics).
See, if you launch an exposition of the details online, and include
material like the above, _generally_ what happens is opposing parties
show up to bog the discussion down with objections to small errors,
which are difficult to avoid because of the sheer mass of facts. For
example, they'd pounce on the 'plain text logs' bit. There would be
a two-prong approach:
1. You'd hear a well-rehearsed presentation purporting to show that you
can do with systemd's journalctl utility everything you can do with
rsyslog/syslog-ng. This would actually be a partial truth, carefully
omitting or glossing over the important things that are part of normal
system administration that journalctl _cannot_ do. The disputants
normally prevail on this because they aren't arguing with seasoned
system administrators who can spot the holes and evasions.
2. They would also point out, quite correctly and significantly, that
systemd does _not_ mandate binary log files, because it has a
prominently documented hook to permit handing off of log information to
rsyslog or syslog-ng, making the logs be exactly as they were in
traditional Linux systems because they are _managed_ by the traditional
logging software. This is, in fact, the distro-installation default
configuration in Debian 8 'Jessie', where rsyslog continues to handle
all system log output exactly as before.
Arguing the details in this fashion is, IMO, a sucker's game, as the
biggest problem isn't with the innumerable individual dumb architectural
decisions made by the devs. The biggest problem is lock-in enforced by
package dependency hairballs -- involving the whole suite of
Freedesktop.org plumbing packages, not just or even primarily systemd.
But make up your own mind, of course.
hangout mailing list