|FROM ||Rick Moen
|SUBJECT ||Re: [Hangout-NYLXS] New Distros to try: Please explain what the
|From hangout-bounces-at-nylxs.com Mon Dec 19 18:19:44 2016
Received: from www.mrbrklyn.com (www.mrbrklyn.com [184.108.40.206])
by mrbrklyn.com (Postfix) with ESMTP id 831B816131F;
Mon, 19 Dec 2016 18:19:43 -0500 (EST)
Received: from linuxmafia.com (linuxmafia.COM [220.127.116.11])
by mrbrklyn.com (Postfix) with ESMTP id 087A716131B
for ; Mon, 19 Dec 2016 18:19:39 -0500 (EST)
Received: from rick by linuxmafia.com with local (Exim 4.72)
(envelope-from ) id 1cJ7DX-0004bw-04
for hangout-at-nylxs.com; Mon, 19 Dec 2016 15:19:39 -0800
Date: Mon, 19 Dec 2016 15:19:38 -0800
From: Rick Moen
Organization: If you lived here, you'd be $HOME already.
X-Mas: Bah humbug.
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.5.20 (2009-06-14)
X-SA-Exim-Scanned: No (on linuxmafia.com); SAEximRunCond expanded to false
Subject: Re: [Hangout-NYLXS] New Distros to try: Please explain what the
issue is with SystemD. Mayer, I am using Mint 17.3,
what is it using in contrast to system D ?
Reply-To: NYLXS Discussions List
List-Id: NYLXS Discussions List
Content-Type: text/plain; charset="us-ascii"
Quoting Mancini, Sabin (DFS) (Sabin.Mancini-at-dfs.ny.gov):
> Please explain what the issue is with SystemD.
If you're a typical 'desktop' Linux user (as suggested by the citation
of Linux Mint, which, I hasten to add, is a generally excellent Linux
distribution that I specifically recommend to people), then your
personal experience with init systems is either (1) nonexistent (you
went with distro defaults and have no reason to start and stop, let
alone configure, services), or (2) just the basic start/stop/restart
administrative actions (using sudo, in Mint's case), once in a blue
Either way, systemd does what you would vaguely expect an init to do.
In that sense, you won't perceive an 'issue'. In all likelihood, if
you're a typical Linux Mint user, you are only hazily aware of init
systems and are probably a little unclear on what they must do.
(Nothing wrong with that, BTW.)
Far into the future, you might (or might not) notice that your
distribution has become a mass of system software that must all be
upgraded in lockstep, and that substituting something different (e.g.,
to switch to what you consider best of breed in its category) is
mysteriously no longer possible -- but most users wouldn't even perceive
this fact when it's present in their systems.
You might on rare occasions encounter a startup problem that is
ridiculously intractible because some mysterious system component will
not permit you to do an administrative login (even as root!) in order to
fix the problem that's preventing your system from booting. However,
(1) it won't be obvious what -specifically- is causing this roadblock,
just something-you-cannot-track-down, and (2) your distro people will
have FAQed some workaround, perhaps using a live-CD recovery image.
If you lack the existing experience to know in advance that this is an
absurd situation and that something deeply evil must have been accepted
into the core of your system to even permit this to happen, you would
probably blandly accept it as just-the-way-it-is, and it won't occur to
you that the underlying rot might be removed.
I believe Ruben encountered exactly such a situation on newly
systemd-dependent OpenSUSE, and that this event was the final straw that
lead him into months of ASCII-yelling on this and other forums. I'd
speculated that the systemd init received D-Bus (or other) messaging
from the PolKit Freedesktop.org policy layer advising that, for reasons
that passeth understanding, the root user should not be permitted to
login at that time on account of some underlying problem state in the
not-quite-booting system. There are many descriptions of such roadblock
scenarios occuring on systems that hand over system operation to
Freedesktop.org components like systemd and PolKit.
And, again, desktop users, and most Linux users, will just suffer
through these absurdities as just-the-way-it-is.
A few of us look at those outcomes, and our reaction is 'If some piece
of system software is preventing the root user from being permitted to
login to fix the system, even in single-user maintenance mode, then that
software is broken and needs to be taken out and shot.'
The list of software typically implicated in such incidents pretty much
equates to the Freedesktop.org plumbing software I mentioned upthread.
Some of us have moved to regard such software as damage and route around
it. Others of us Linux users follow the path of least resistance and
just use distro defaults.
So, is there an 'issue'? Dunno, man. You tell me. ;->
hangout mailing list