Linux distros are very much about personality. That's why there are so many of them. Additionally, as a community we need to be careful about rallying behind any one something and saying it is the way to do a thing. The truth is, it isn't.
Systemd is simply the new way to do things we have been doing for years. There are things like about it and things I like about it but it's hardly the deciding factor nor is it the thing that defines the personality of a distro.
The core requirement of a system is to be able to provide reliable service and truth be told the vast majority of distros do that.
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Keith C. Perry, MS E.E.
From: "Steve Litt" <slitt@troubleshooters.com>
To: plug@lists.phillylinux.org
Sent: Thursday, October 22, 2015 4:08:38 PM
Subject: Re: [PLUG] Void Linux tips
On Thu, 22 Oct 2015 00:17:10 -0400
brent timothy saner <brent.saner@gmail.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 10/21/2015 11:45 PM, Steve Litt wrote:
>
> For me, the elephant in the room was systemd, which Arch embraces
> enthusiastically, and which Void formerly used as its init before
> dumping it for runit.
not liking systemd is certainly a right and prerogative someone has,
but what you've presented here is largely a preference rather than
any sort of objective reasoning.
That's absolutely true. Based on my use case, and my personality, and
my strengths and weaknesses, I choose to forego systemd. It's a
preference.
there is a lot of FUD around systemd, however, which i discuss in
S0E8[0] of my podcast (starting at 39m20s).
I'd suggest everyone on the list listen to this podcast, at
https://sysadministrivia.com/?p=archive&cat=all, go down to the one
numbered S0E8, and listen from 39m20s to the end. Brent, I'd like to
congratulate you on not trotting out all the old character
assassinations that people not wanting systemd are "neckbeards",
"against innovation", "afraid to try something new", "demotivating",
etc. Your choosing not to go down those roads already puts you in the
upper 20% of class within the systemd debate.
I wouldn't characterize all the positions your podcast discusses as
"FUD". We've all seen anti-systemd FUD: Firefox crashes and it's
automatically systemd's fault. That's FUD.
What you're discussing are assertions. People choosing to avoid systemd
assert that systemd ties together huge chunks of functionality. Your
podcast waves off this assertion by mentioning that netcat includes a
lot of functionality, but this comparison of systemd's inclusion with
netcat's is breathtakingly asymmetrical. I suggest you find a better
way of framing your response, although I have no idea what better (and
accurate) way that would be.
Roughly five times your podcast compared systemd favorably to sysvinit.
This is kind of like saying "I'm smarter than Mike Tyson and stronger
than Stephen Hawking." Saying something is superior to sysvinit is no
complement at all: There are many better alternatives.
Truth be told, I personally would prefer even sysvinit to systemd, but
that's not the issue and heck, just to proceed forward I'll stipulate
that systemd is better than sysvinit. But there are at least four init
systems I vastly prefer to sysvinit: Epoch, s6, runit, and even
suckless init plus daemontools-encore plus LittKit. Not a one of these
have "init scripts" of the size and complexity of those of sysvinit and
OpenRC. Comparing systemd to sysvinit is a very restricted partial
truth, so I'd suggest you frame the discussion over the wider range of
init systems.
Toward the end of the podcast your buddy says that things would be
better if if everyone who is trying to fork debian would work to
integrate systemd. That's not how Open Source or Free Software works.
And you mention something to the effect that people forking Debian are
"causing a problem." I'd suggest you jetison that line of thinking
right along with the "neckbeard" assertions that you refused to engage
in.
Last but not least is, I'm not sure if it's my inference or your
implication, that one init system fits all use cases. Absent is
recognition that a person's use case drives his/her software choice.
Use case is everything in software choice.
For instance, if I had 99.9999% uptime guarantees, I'd for sure pay a
large bill, in money or in added complexity, for systemd's 1 second
boot.
But my use case is a Daily Driver Desktop, that boots at the most once
every couple days, usually weeks between boot. 1 second, 10 seconds, 30
seconds, makes no difference to me. My Daily Driver Desktop runs my
1 man business, meaning I'm the guy who has to fix it. I'm the guy who
has to customize it. If you count debugging my own and other
peoples' code as repair, I repaired things, for a living for 26 years
before becoming a trainer and author. Never during that 26 years did I
see added complexity that didn't make repair more difficult. You
mention in your podcast that journald replaces (or is like) logrotate
plus rsyslog. Well, I already have logrotate and rsyslog, and all the
other tools Linux gives me, so I don't need the extra systemd layer
that I need to pierce if I get a problem not fixable on the systemctl
level. All other things being equal, I prioritize simple. And in my use
case, all other things *are* equal: I don't need fast boots, I don't
need the edge case benefits bestowed by socket activation, and I don't
need logs covering my initramfs. Void's nine second runit init covers
all my needs, without the systemd layer.
The reason I know it's a layer is, first of all, because of what
Lennart says here:
https://www.youtube.com/watch?feature=player_detailpage&v=LdRmnSHHVw4#t=35
Lennart also says it when he describes the architecture in various
parts of his hard to research Pid Eins blog, although I can't find the
exact pages.
I also know from personal experience that systemd is a layer, and a
hard layer to pierce. I learned about that while replacing systemd with
Epoch and/or runit on Centos and Manjaro. Replacing any ordinary init
system with Epoch or runit is a straightforward clean swap. Replacing
systemd, you need to tweak many details in many programs and config
files. And then there's the software dependency issues, which are too
big to get into here.
Systemd is a thick layer with tenticles into a lot of software, my use
case doesn't require that layer, so I won't use that layer.
i find a lot of it comes from individuals who have never actually used
systemd in a production or regular environment (or a *proper* systemd
implementation- such as Arch's- and have instead used a half-cocked
hybridized implementation such as debian, ubuntu, centos to a lesser
degree, etc.)
The preceding paragraph seems to imply that if you want to use systemd
the right way you go with Arch. I'm going to assume that's not what
you meant, because that would be a potent anti-systemd argument.
I used Manjaro with systemd on a notebook for a few months. It was
OK. It was fine. I had no problem with it. I use simple setups
everywhere I go, so systemctl was easily capable of controlling the
notebook, and if it hadn't been, re-installation would have been
trivial. But with my Daily Driver Desktop that runs my business, which
I must keep functional all the time and mold to my exact usage, I want
the simplest possible construction with the fewest abstraction layers,
and that means no systemd.
i'd invite you to look a bit deeper into systemd and use it a little
bit before criticizing it.
:-)
If you knew how much I've looked into systemd, you'd be flabbergasted.
But seriously, it's about use case. We don't all use the same init
system for the same reason that we don't all drive the same kind of car.
SteveT
Steve Litt
October 2015 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive
___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug