[ale] Systemd and cygwin

[Steve Litt]

On Wed, 18 Nov 2015 07:25:01 -0500
Michael Trausch <mike at trausch.us> wrote:

> Systemd is an optional dependency of GNOME.
> 
> And it makes higher level management easier. 
> 
> I am sick of the bullshit ignorance here and everywhere on this. It's
> a damned useful tool which simplifies many tasks all across the IT
> board.
> 
> Show me another system where with nothing more than an extra keyboard
> and mouse and monitor, and one single command, one workstation can
> become two.
> 
> Show me one use case where logging more information with additional
> security controls available is bad. 
> 
> Remind me again why reducing several code paths into one more easily
> maintained one is bad?
> 
> And why is a simple config file harder for you than a turing complete
> shell script? Do you hate the 1kb reduction per executable to
> eliminate the double fork tty disassociation hokey pokey, too? Or the
> consolidation of common functionality in now nearly universal shared
> objects?
> 
> Nah. Don't waste the time. I won't have the give a fuck to read it
> anyway. If you want to walk uphill both ways to work in six inches of
> snow, don't use a major, audited, supported distribution in your
> work. Simple.

A powerful argument, stated powerfully.

Now let's examine this argument, and let's start by removing all the
anger and neutralizing the negative characterizations:

> 
> Show me another system where with nothing more than an extra keyboard
> and mouse and monitor, and one single command, one workstation can
> become two.

I can't, but this ability is not needed for my use case. I am not
alone, and very well may be in the majority.

> 
> Show me one use case where logging more information with additional
> security controls available is bad. 

Not bad, but not needed in my use case. I'm perfectly happy with my logs
and security. And if I want to log more information, I can easily do it
by enhancing Runit's logs. I know many people quite satisfied with the
logging and security they've had for the last decade.

> Remind me again why reducing several code paths into one more easily
> maintained one is bad?

As stated, it wouldn't be bad. But I wonder about the characterization
"more easily maintained". If I'm not mistaken, Red Hat is paying about
a million dollars a year in programmer salaries to maintain systemd.
Its alternatives are done by volunteers in their spare time, involving
much smaller code. This question can be further discussed when the
"several code paths" are specifically identified and the "one [code
path]" is specifically identified.

> And why is a simple config file harder for you than a turing complete
> shell script? 

Again, it depends on use case. For most, the shellscript is no harder.
If the shellscript is a monstrosity like the init scripts shipped with
sysvinit and OpenRC, the declarative config files shipped with systemd
and Epoch are easier. But if the shellscript is a daemontools-workalike
run script, the shellscripts are just as easy, and if you're going to do
something unanticipated by the makers of your init, that Turing
completeness can make your life easier. It's all about use case.

> Do you hate the 1kb reduction per executable to eliminate the
> double fork tty disassociation hokey pokey, too?

Once again, use case. Are you so lean on RAM that a couple hundred Kb
makes a difference? If so, then you love the reduction. If not, you
deprioritize the reduction almost to the point of nonexistance.

> Or [do you hate] the
> consolidation of common functionality in now nearly universal shared
> objects?

Depends on priorities. Do you prioritize consolidation, or do you
prioritize interchangeable parts? You can't have both, at least not how
systemd has implemented this consolidation. 

> 
> Nah. Don't waste the time. I won't have the give a fuck to read it
> anyway. If you want to walk uphill both ways to work in six inches of
> snow, don't use a major, audited, supported distribution in your
> work. Simple.

Hmmm.

In the preceding assertion, removing the anger removes half the
preceding verbiage. Removing the winter wonderland metaphor removes
most of the rest, so we're left with the basic question "do you want to
use a major, audited, supported distribution in your work, and at what
cost?"

Use case. All other things being equal, many (but certainly not all) of
us would prefer a major, audited, supported distribution. From time
immemorial major distributions, the only ones financially capable of
auditing and professional support, made compromises in order to make
themselves "easier" and "one size fits all." These compromises clashed
with a significant number of use cases, which is why we still have the
likes of Slackware today.

Today there are many people who have, or are seriously contemplating,
going with the lesser known distros or even *BSD so that they can
retain the interchangeable parts, easy divisibility, easy modifiability
of the Linux they've come to know. So I'd rephrase the assertion like
this:

"Almost every major, audited, supported distribution currently runs
systemd. If you view systemd as a massive black box whose sole
interface is systemctl, journalctl, et al, and you worry that your
ability to troubleshoot, modify or augment will be disrupted, then use a
non-systemd distro, even if it isn't a major, audited, supported
distribution."

I use Void Linux for the use case of my Daily Driver Desktop that
creates all content for Troubleshooters.Com, and I'm quite pleased.

SteveT

Steve Litt 
November 2015 featured book: Troubleshooting Techniques
     of the Successful Technologist
http://www.troubleshooters.com/techniques