[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ale] for all you systemd haters...
On Fri, 16 Feb 2018 14:20:38 -0500
leam hall via Ale <ale at ale.org> wrote:
> On Fri, Feb 16, 2018 at 2:12 PM, Steve Litt via Ale <ale at ale.org>
> > On Fri, 16 Feb 2018 11:52:03 -0500
> > Solomon Peachy via Ale <ale at ale.org> wrote:
> >> On Fri, Feb 16, 2018 at 11:22:20AM -0500, leam hall via Ale
> >> wrote:
> >> > I was thinking "People who actually like Linux."
> >> What does that even mean?
> > I already posited one theory on what Leam meant, and now a second
> > possible explanation occurs to me:
> > Systemd originator and evangelizer in chief Lennart Poettering has
> > never been shy in stating his dislike of Linux, often going so far
> > as to negatively compare Linux to Mac and even Windows. Yeah
> > Windows. And it's clear that systemd makes Linux systems it has
> > been installed on more like Windows, in terms of reduced diy, and
> > increased program to program interdependencies. Poettering has
> > several times suggested ignoring and breaking POSIX, an
> > underpinning of all things UNIXy including Linux, for the last 30
> > years.
> > Poettering doesn't like Linux and created systemd to make Linux less
> > Linux. A person who likes Linux would therefore not like systemd.
> > SteveT
> That makes me wonder; what does systemd do that non-systemd mechanisms
> Granted, it may make some things easier or more to someone's
> liking, but what does it do well that cannot be replicated otherwise?
It looks like you're asking 2 questions:
1) What does systemd do that other mechanisms can't do?
2) Can these benefits be replicated by other systems?
As far as your question 1, it depends who you ask. Here's the systemd
The preceding is so chock full of logical fallacies, but not a day goes
by when I don't hear someone with absolutely no idea of the
functionality of an init system parroting its fallacies.
Here's the rebuttal to same, by Jude Nelson, author of the vdev
replacement for systemd-entangled udev:
And here's why musl C standard library author Rich Felker says systemd
is "broken by design." Be sure to go to the bottom and see the 14 line
PID1 written by Felker. Later, Dimitris Papastamos made an 83 line
version, Suckless Tools Init (sinit), that responded to all the
necessary interrupts for a PID1. Then I bolted on daemontools-encore,
and some custom shellscripts I called LittKit to bring up services in a
given order. The sinit/daemontools-encore/LittKit combo was better,
faster and more understandable than sysvinit, and it was better and
more understandable than systemd (systemd *does* boot pretty fast, if
that's your priority and you're a one issue voter). I'd still be using
the combo today, but I found out that the runit init system is pretty
much the same thing, from a single free software vendor, with a lot of
improvements bestowed not by dependencies or kilolines of code, but by
a few symlinks and a few lightweight utilities.
So, both sinit+Daemontools-encore+LittKit and runit do the init work of
systemd, in a different way, much more simply. Another init system does
it in a slightly more complex and featureful way than runit and my
combo, but it's as good or superior to the init section of systemd,
and much simpler. These have to do with your question #2.
LOL, here's the systemd sales process, as shown time and time again by
1 Find or invent a need.
2 Write a messy, entangled solution with a design you might expect from
a group of DP101 students. This solution is inseparably interwoven
3 When people say it's a mess, he says "well, how else are you going to
4 When people voice realistic ideas, he proves they won't work by
showing how they conflict with the existing Rube Goldberg systemd
he's already built. He does this by getting into nitty gritty details
of his code that nobody outside the systemd/freedesktop developer
community could possibly understand.
5 Finally, after somebody shows a working example of how to do ______
that involves no help from systemd, Poettering writes it off as
"simple", the worst insult he knows.
Steps 4 and 5 are Poettering's answer to your question: They say you
can't. And if you *do* make a superior mechanism, they'll say it
doesn't count because it's "simple."
Throughout all those steps he Poettering (and systemd fans who use his
techniques) sprinkle in all sorts of personal insults.
Here's a video showing Poettering, using the steps above, ambushing and
bullying a presenter who had little skill in English.
Poettering asks the presenter "do you hate handicapped people"
because the presenter didn't want the display manager to be a
preload of Gnome. He's fully in step 4 here, explaining why with his
software, you need all that trash to be accessible.
At 23:53 Poettering appears to score some major points when he
defends NetworkManager as part of the Display manager and the
presenter unwisely suggests static configuration. But of course, a very
simple program with a limited X interface can manipulate wpa_cli and
wpa_password within a shellscript to provide that function: You don't
need NetworkManager, which is extremely promiscuous with its
communications with other programs. Poettering's kicking ass on step 4.
And then at 24:51 the presenter makes Poettering look silly with the
sentence "do you know what shellscripts are?", thereby kicking it up to
step 5. Poettering mutters an insult and changes the subject.
Many projects are led by dicks. If I refused to use software led by
dicks, I'd still be using CPM. Thing is though, the systemd posse
parrots the words of Poettering as if it's gospel instead of a
combination of insults and fallacies.
True story: A pro-systemd guy assured me I needed "socket activation"
to read and automount thumb drives. After two hours experimentation I
presented a shellscript automounter based on inotifywait. Pro-systemd
guy didn't like it, too simple, didn't work with systemd (that was the
whole point), and too buggy (did I mention I wrote it in 2 hours?).
I have yet to hear of anything systemd does that could not be done in a
more modular, simpler and easy to troubleshoot way.