[Time references are from the video on
https://judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html ]
On 31/01/19 at 12:56, Dmitrii Kashin wrote:
> В Чт, 31/01/2019 в 00:19 +0100, Alessandro Selli пишет:
[...]
> I'd like to notice that Benno just repeats systemd's propaganda.
Actually he lists things that Linux+systemd have that BSD does not.
And he prompts the BSD community towards implementing what it lacks,
*without* *ever* *suggesting* porting systemd to BSD.
> All
> these theses were considered in 2014 by Jude Nelson.
>
> Here's the link:
> http://judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html
Good read. But it does not refute anything that Benno Rice said.
Fallacy #1.1: "Systemd's components have well-defined
interfaces, so you can just replace the parts you don't like."
Rice never claimed systemd is cool because you can replace any of it's
components.
Fallacy #1.2: "The Linux kernel is monolithic, therefore it is
okay for systemd to be monolithic"
Did Rice ever said anything about systemd being good or bad because of
it's monolithic nature.
*Fallacy #2: "Lots of people use systemd, therefore you should too"*
Rice did not state that. What he did say is that there are reasons
systemd caught on like wildfire, it is an innovation right were Linux
was more strikingly lagging behing WindowsNT and macOSX (launchd):
"active service management" (07:55).
He did state the obvious, that all major Linux distributions do run
systemd, but he does not suggest this is a reason the BSD people should
even try porting it to that OS.
Fallacy #2.1: "Systemd earned widespread adoption through its
technical merits"
He did say systemd has technical merits, and he talked about them. I
already listed them, they are again: automatic HW and SW system
reconfiguration, cgroups, message transport, service lifecycle,
automation API and containers.
If an alternative init and service management system is to have any
chance at being considered a viable alternative to systemd it's got to
be as good as systemd at doing these things. Benno Rice would like the
BSD community to star developing their own solution. What about the
Linux folks? What do we have, what are developers working on that could
do that?
Fallacy #3: "People who don't like systemd just don't like change"
Well yes, Benno Rice did say that most resistance to systemd stems from
the unwillingness to change long time habits. Which is true, I do
remember how much I hated migrating from initd to xinetd, learning the
new rules iptables introduced compared to ipchains, losing LiLO's and
then grub-0.8's simplicity to be forced into grub2's awfully complicated
config file syntax and generation procedure. But he said it mostly of
the BSD people, and as an example to that he said (28:07):
"And one of the biggest problems that I had with the FreeBSD community
on this one was things like this:
[slide] #systemd got you down? Come see my talk "Switching to the BSDs"
at @lfnw this weekend.
linuxfestnorthwest.org/conferences/lf...
because to me this says on behalf of my community: 'Come join FreeBSD,
we'll never change, we refuse to move forward into the future.'"
Can you really think sticking to sysv-init to avoid systemd tells
anything different?
Fallacy #4: "Unit files are better than shell scripts"
While he did not state that, it's a matter of fact that SysV's init
script have been for decades vilified as an awkward kludge, generally
badly implemented, extremely static and inefficient way of managing
system services and deamons. And rightly so. All attempts at producing
a better init than SysV started with doing away with service scripts and
having just config files instead.
Fallacy #4.1: "Unit files reduce complexity"
While I do acknowledge this is true, I also list this as a problem.
Reducing complexity has greatly reduced sysadmin's capability to
customize their systems or implementing a workaround when systemd gets
something wrong.
Benno Rice did say this, and he is right.
*Fallacy #4.2: "Shell scripts are buggy"*
Yes, they are. A lot. And they often are so easily correctable that I
wonder how comes some bugs have staid in init script for years after
patches were proposed (a year ago I figured out an init script just
needed two lines of code to implement the status reporting it lacked).
Scripts are considered something trivial and inessential, they only run
once for a very brief time and all it matters is that the service they
are to start gets started. I can't explain it in any other way.
*Fallacy #4.3: "Systemd is better because it gets rid of shell scripts!"*
Again, Benno Rice did not state this, but this is true. Again i point
out that *all* sysv-init alternatives started with doing away with init
scripts.
*Fallacy #4.4: "Systemd is better because it reduces shell script code
duplication!"*
No, it does not reduce it, it completely does away with any shell scripting.
And again, Benno Rice did not state this in his talk.
Fallacy #5: "Systemd enables you to use $LINUX_SPECIFIC_FEATURE"
Benno Rice listed this as a limitation of systemd.
"Another one that is particularly interesting to me is that it's not
portable. Now, this interests me because, for those who don't know, I'l
a long time FreeBSD developer. systemd is aggressively Linux-specific.
It uses a whole bunch of Linux specific process maintenance hooks that
just aren't present on other systems. And so, if it becomes the sort of
established way to manage the services, it runs the risks of isolating
the other platforms that don't have those things."
(21:21)
BTW, since the Linux kernel has so many functionalities, I do am in
favour of using them.
Fallacy #6: "Systemd is open source, so if you don't like it, you
can fork it!"
Close, but not quite. What he said is:
"Why? Why did systemd show up? Why is systemd important? Thinking about
that means you suddenly have a hang on. So, is systemd solving a
problem? What problem is it solving? *Could* *I* *solve* *it*
*better*? Because one of the solutions if you don't like systemd is to
go and make your own. At the very least you're going to find out how
fun that is."
(28:36)
Fallacy #6.1: "Those systemd detractors should stop whining and
make their own alternative!"
Well, of course. Just whining won't change the reality. It's not
whining that's going to replace systemd, it's only going to be a better
init and system management tool.
Fallacy #7: "You should use systemd, since it gives you socket
activation!"
Nowhere did Benno Rice say or imply this.
Fallacy #7.1: "You should use systemd, since it lets you assign
targets to be activated on receiving the connection!"
Like previous point.
Fallacy #7.2: "You should use systemd, since it supports more
than network sockets! It supports pipes and UNIX sockets too!"
As before.
Fallacy #7.3: "You need to use systemd for socket activation,
since otherwise you'll encounter race conditions with parallel
start-up!"
Ditto.
Fallacy #8: "$PROGRAM doesn't depend on systemd, it just depends
on something that implements systemd's interface"
while ... do ... done
Fallacy #9: "Systemd is the KISS principle in action"
Where, oh where does he state that?
Fallacy #10: "Binary log files aren't a problem in practice"
Yes, he said it. And I agree binary log files are a bad idea. Still
this is a marginal systemd selling point (even the most
systemd-enthusiastic distributions come with plain text logs not just
available, but installed and active right out of the box).
BTW, it's worth noting that systemd is the only free and readily
available implementation of a log system that not just sends over the
network encrypted logs, but that can store on disk only encrypted log
messages right after receiving them from the processes that produced
them. If you think this is overkill, know that this is a requirement
for an OS to be considered fit to run in security-critical
environments. How long before one of the several available syslog
daemons was at last capable to do the same?
Fallacy #10.1: "Journald's binary format lets its perform
authenticity and integrity checks"
It's not the binary format that does that, it's the encryption and
signing keys that do it.
And I agree that a log daemon that was capable to do it is indeed a
better log daemon.
Fallacy #10.2: "Journald binary format lets it have an index
that makes log access faster"
I quote from the "rebuttal": "no one will contest that indexing will
speed up log access".
Fallacy #10.3: "All the problems you have with journald can be
avoided by having it simply pass everything to syslog"
Nowhere did Benno Rice say or imply this.
Fallacy #11: "People who don't like systemd really just don't
like Lennart Poettering, and that's not a valid excuse to avoid it"
Nowhere did Benno Rice say or imply this. But I do read a lot of
scathing remarks against LP whenever I read a thread about
systemd/pulseaudio/avahi.
Fallacy #11.1: "You should judge systemd on its technical
merits alone, otherwise your criticisms are wrong"
They might not be wrong, but surely criticism of a piece of software
(=product of technology) that overlooks the technical points will never
gain traction in an almost purely technical environment like software
development and system administration is.
Fallacy #12: "The Linux kernel is complex, and you use the Linux
kernel, therefore you are okay with systemd being complex too"
Nowhere did Benno Rice say or imply this.
Fallacy #13: "Systemd has at least 574 contributors from many
different backgrounds, therefore it is not pushed or controlled by
a small group"
Nowhere did Benno Rice say or imply this.
Now, one thing strikes me: you accused Benno Rice of running a
propaganda piece for systemd while you evidently did not listen anything
he said, and come up pointing to a paper to counter his statements that
does not actually refute his talk's points. Speak of propaganda!
> And (if someone is interested) here's my russian translation:
> https://www.opennet.ru/base/sys/systemd_myth.txt.html
>
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
--
Alessandro Selli <alessandroselli@???>
VOIP SIP: dhatarattha@???
Chiave firma e cifratura PGP/GPG signing and encoding key:
BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE
::
Re: [DNG] Systemd as tragedy
