[colug-432] systemd dislike

Jacob Ulrich contact at peachchannel.lol
Mon Mar 7 15:19:20 EST 2016

I personally avoid systemd like a plague. I won't even install a distro 
with systemd as the default init. Slackware, my OS of choice, the latest 
stable release kernel is getting to be outdated for my taste; so I've 
switched to the current branch. If you are in need of a rolling release 
distro without systemd then maybe try Void Linux. I think I would rather 
build Linux-From-Scratch every install then use systemd. I just 
recommend these Operating Sytems because they are what I use.

On 2016-03-07 13:05, Jim Wildman wrote:
> While I agree with your basic philosophy and approach, at this point,
> it is a bit of tilting at windmills.  All the major distros have 
> adopted
> systemd.  If you are getting paid to work on Linux, you're most likely
> going to be using systemd for at least the next 5 years.  If you're
> purely a hobbyist, then there are distros that are working around it,
> but you are going to be in a corner.
> It's kind of like side air bags on cars.  I hate the lack of visibility
> they cause.  But complaining is not really going to change anything...
> For an interesting take on it, see this review as well...which is a bit
> of RHT getting hoisted on it's on petard.
> http://lwn.net/Articles/676831/
> On Mon, 7 Mar 2016, Rick Troth wrote:
>> I propose that it will be more effective long term to focus on what's
>> good about SysV INIT (or other INIT schemes). This will naturally 
>> touch
>> on things that "we" dislike about SystemD. But if we keep our compass
>> stayed on "I like thus-and-so" we may actually be able to retain what
>> remains of thus-and-so. See below.
>> Try to be practical. If all your thus-and-sos really don't matter, 
>> then
>> join the SystemD crowd and move on.
>> Otherwise,
>> be bold! If your thus-and-sos DO matter, then talk about them ... 
>> shout
>> loudly and and preach broadly.
>> Historically, Solaris, HP-UX, and others (including AIX) used the AT&T
>> branch of INIT driven by /etc/inittab. Few people wanted to mess with
>> /etc/inittab. Maybe it was because the syntax is akin to that of
>> /etc/passwd. (Only certain kinds of doctors really *want* to look at
>> that many colons on a regular basis.) HP-UX and Solaris and others
>> adopted an improved method, without breaking /etc/inittab, where 
>> scripts
>> could start and stop services at each run-level. Some Linux distros 
>> went
>> this route. (I never got my head completely wrapped around pre-Upstart
>> Ubuntu/Debian, nor the BSDs for that matter.) HP-UX went so far as to
>> support a per-service message, yet without breaking when an HP-UX
>> "message capable" INIT script is used on Solaris or (eventually) 
>> Linux.
>> I found that I was able to hack FreeBSD to drive SysV INIT scripts. 
>> Easy
>> peazy.
>> What appealed to me about Linux from the earliest days was that it
>> provides an unencumbered Unix system, borrowing "the best" from either
>> AT&T or from Berzerkeley (Left Coast). I like Unix, leaning slightly 
>> to
>> the right (East Coast, so to speak). Mostly, I hate being painted into 
>> a
>> corner, and with "Unix" I can move a program or workload (or my 
>> desktop)
>> from one system to another, pursuing that fit-for-purpose goal. Fond 
>> as
>> I am of Linux, I've never (ever!) suggested that it would be the 
>> basket
>> to hold all my eggs.
>> Here's my current thus-and-so list, what I like about SysV INIT:
>> + Interoperability (among other Unix and Unix-like systems)
>> + Non-Breakage (of older /etc/inittab which don't have the break-out
>> scripts, e.g., AIX)
>> + "the Unix way" because INIT does one thing and does it well*
>> + Simplicity, in that the scripts can stand on their own**
>> + Speed, in that some of us did not experience the delays SystemD
>> allegedly relieves***
>> + Ease of implementation (I know at least one guy who wrote his own 
>> set
>> of INIT scripts ... from scratch)
>> Anyone have more bullet points they could add? Please do!
>> * For varying values of "well", since obviously a great number of 
>> people
>> were dissatisfied with SysV INIT. Never the less, SysV INIT is clearly
>> more attuned to the "do one thing" method than SystemD.
>> This "do one thing and do it well" mantra has been mentioned many 
>> times
>> already by prominent software luminaries. The assimilation of other
>> functions into SystemD is probably its most damning feature. It seems
>> that resistance is futile.
>> ** What little I have been able to comprehend of SystemD takes me to
>> several directories. (And that's just for the INIT function.)
>> *** I actually experience more delays, and longer delays since my
>> distros of choice went with SystemD. Not a scientific sample, but does
>> lead one man to ask, "why did we do this?". In any case, a well 
>> written
>> SysV INIT script does not inherently mean delays. Most of them simply
>> fork the associated daemon and return.
>> There *are* Linux distributions which eschew SystemD. Not sure what 
>> the
>> current story is in Debian land. (Mostly due to lack of time, not that 
>> I
>> don't care.) There was certainly a great hue and cry in that world, 
>> Jim.
>> Debian may be pressed by decisions made by Canonical. And I know of at
>> least one large company in-house Debian spin which fell to SystemD.
>> There are other battles. I'm keeping silent about a big one (now 
>> several
>> years older than SystemD) for now.
>> For what it's worth, I'm in the middle of a discussion with the
>> Coreutils team over their recent dis-use of /etc/mtab in favor of
>> /proc/self/mountinfo. The latter has more detailed info than
>> /proc/mounts. Both /proc/mounts and /proc/self/mountinfo still do not
>> provide what I enjoyed from /etc/mtab. I'm hoping they'll just make it 
>> a
>> compile-time option. But they put some work into their
>> /proc/self/mountinfo parsing so they seem to be a little sensitive 
>> about
>> it. (I can relate!)
>> When most distros started making /etc/mtab a sym-link to /proc/mounts,
>> the remedy was trivial, so I didn't complain. Whatever "mtab hate" 
>> there
>> was in the community has evidently continued, not satisfied with
>> /proc/mounts.
>> Twice over the past year or three, I was surprised by dislike which I
>> did not share:
>> Git is terribly unpopular with long time users of Subversion, CVS, and
>> others. Some of it may be learning curve or muscle memory. But I've 
>> seen
>> arguments stated from (what reads like) practical and objective
>> objection. (For me, the worst thing about Git is building the cussed
>> thing, where CVS and SVN are "standard recipe".)
>> Recently at COLUG, someone mentioned LibreSSL and a number of staunch
>> OpenSSL aficionados booed the former quite vocally. I use the newcomer
>> when I can, but follow updates in both camps very closely. (Call me
>> paranoid. But am I paranoid enough?)
>> -- R; <><
>> _______________________________________________
>> colug-432 mailing list
>> colug-432 at colug.net
>> http://lists.colug.net/mailman/listinfo/colug-432
> ----------------------------------------------------------------------
> Jim Wildman, CISSP, RHCE       jim at rossberry.com 
> http://www.rossberry.net
> "Society in every state is a blessing, but Government, even in its best
> state, is a necessary evil; in its worst state, an intolerable one."
> Thomas Paine
> _______________________________________________
> colug-432 mailing list
> colug-432 at colug.net
> http://lists.colug.net/mailman/listinfo/colug-432

More information about the colug-432 mailing list