[sf-lug] Byfield's "Verdict" on systemd

[Rick Moen]

Quoting Alex Kleider (akleider at sonic.net):

> I don't have any "discontent", and I'm not so much "fretting" as
> wondering what might be suggested in the way of something with less,
> call it 'bloat' if you will.  Booting up my laptop (Lenovo ThinkPad
> X301 as mentioned) seems to take an inordinately long time- I've
> assumed (rightly or wrongly, I'm not sure) that this was because there
> is a lot being loaded, much, if not most, of which I never use.

So, your next logical step would be investigate what is being launched at
bootup time, and (for each) why, right?  

Doing that will get you into the rudiments of system administration,
which IMO ought to be a primary goal of anyone on Linux systems after a
couple of days of mousing around.  

On older Ubuntu LTS, the startup configuration was embodied in Upstart
config files.  Starting with Ubuntu 16.04 LTS (Xenial Xerus), that's
been in systemd unit files.  If you want to understand and control what
starts during startup, you need to focus your attention there.

Personal opinion:  Your reliance on Ubuntu and ergo GNOME means that
studying and asserting control over startup is going to be artificially
made difficult by the fact that GNOME autolaunches lots and lots of
obscure but persistent processes.  This is a trait it has in common with
some of the other major DEs, but carried to extremes relative to the
rest.

As you know, I'm just not a GNOME fan in general, so my preferred
solution to any GNOME-related problem is 'How about with no GNOME?'
But I certainly don't argue with people who like it.


> I'm still curious if what (again, rightly or wrongly) I perceive to be
> a movement away from Debian is because of systemd?

I'd be careful about drawing conclusions from Internet buzz, because 
obviously the correlation between that and reality is often very unclear.

What is undeniable is that Debian Project in recent years alienated a
significant number of people including major Debian Developers (DDs).
Reasons are diverse, but some of the DDs quit the project over what they
perceived to broken governance mechanisms and a toxic discussion
environment, an example being my friend and former co-worker Joey Hess,
author of quite a bit of important Debian tools and highly respected
figure.  When he suddenly shut down all association with the project in
2014 over what might be summarised as toxic political processes, a lot
of observers were shocked:

https://www.phoronix.com/scan.php?page=news_item&px=MTgzMjg

Example (critical) Joey postings to debian-user and debian-vote just
before his departure:
https://lists.debian.org/debian-user/2014/09/msg01897.html
https://lists.debian.org/debian-user/2014/10/msg01058.html
https://lists.debian.org/debian-vote/2014/10/msg00023.html
https://lists.debian.org/debian-vote/2014/10/msg00109.html
https://lists.debian.org/debian-vote/2014/10/msg00140.html

And he specifically pleaded with the Debian Technical Committee to 
back down from forcing a badly conceived and badly administered General
Resolution on the project (the infamous one about init system policy):
https://lists.debian.org/debian-ctte/2014/11/msg00045.html

They didn't listen.  He quite soon after that.


> The problem then becomes where to learn enough to make the critical 
> decisions.

I'd start by studying my system and its technical documentation.
(I'm sorry, and you're going to get tired of hearing about my biases,
but I'm not super-impressed with the documentation Ubuntu provides to
technical users to help them understand their systems' architecture.)

When I was first using Debian for production systems, I started studying
my new 'home's' internals and distinctive ways of doing things, and
started throwing together this 'Debian Tips' text file:
http://linuxmafia.com/pub/linux/debian-tips

Today, it's of course two decades out of date, mostly.  For most people,
this would have been a 'notes to myself about Debian' file, but I
happened to operate a Web server, so I immediately made it public even
as a ramshackle work in process.  And I never got around to redacting,
rewriting, organising, etc., the piece, so it's just a now-abandoned set
of notes from another era -- but I offer it as an example of how I set
about that task (understanding one's system).  Looks like I ceased
appending newer stuff after the older stuff around 2004-5.

Of course, one of the things I learned eventually is that I'd discovered
a lot of the topic I covered in the debian-tips file the hard way:  They 
were in general covered in Debian's published documentation, but I was
too impatient to read that.




> What do you (or others) think of UNIX and Linux System Administration 
> Handbook (5th Edition)? 

You mean, the late Evi Nemeth's, as published by O'Reilly?  I have a
dead-tree copy of an earlier edition, but I doubt I've ever gotten any
use out of it.  Looks like her successors (the four co-authors) have
followed market logic by throwing in coverage of all kinds of trendy
stuff.  A lot of reviewers seem to like it.  I probably don't have 
a factual basis for saying much more.

> Sobel's is another book that I've noticed is out with a newer edition 
> but someone who has a copy told me there's no mention of systemd in it.

See, it just wouldn't occur to me, in 2020, to reach for a book in order
to learn the particulars of systemd.  If I wanted to become a systemd
guru, I'd start doing targeted Web searching, collect what appeared to
be the best of what I found, paste them into a file on my Web server
called systemd-tips  ;-> , and spend at least a modest amount of time
reading the linked pages and documentation I felt to be good.  (Just to
be clear, you will not find a systemd-tips file on linuxmafia.com.
But that would actually be a good thing to write.)