Mailinglist Archive: opensuse (856 mails)

< Previous Next >
[opensuse] Re: interesting reading about systemd
Knurpht - Gertjan Lettink wrote:

But unlike GNOME + KDE, or vi + emacs, or Firefox + Chrome, supporting
2 init systems is a totally different situation
Not really -- unless they are not just limited to "init".

Start giving it a try,
It's a bit late to make it easy. If they started when sysV
was still in place and added auto-port options for systemd, it would have
been reasonably possible, but now, you'd have to reinvent the wheel --
also true is systemd is a monolithic piece of SW that has replace
so much -- requiring any replacement of it to supply replacements for
everything it has replaced.

That's the MAIN reason why choice was eliminated,
as systemd provides all the choices -- it is one monolithic (yes,
it is -- because the parts won't inter-connect with anything
but systemd-parts) piece of SW that is designed to crowd out
and extinguish any competing part that it has taken over.

That's an explicit and very serious accusation of the developpers of systemd. Please reread and think again.
I've read many times. I'm not the only one who has noticed
systemd's lack of allowing alternatives. Show me how I could run
my own "init(pid=1)" that implements a subscriber service for dying pid notifications... I believe you'll find it can't be done
without modifying systemd -- and that such modifications won't be
accepted upstream.

EVERY SINGLE SERVICE will need to have a systemd unit file (normally
easy) AND a sysvinit script (normally complicated as heck).
Laugh! LSI included a 39-line auto-converter to
generate sysd-unit files on the fly, from existing scripts. It's
automated in a 39-line shell script -- and you call that
"complicated as heck"?

Reread what's been called "complicated as heck".
You mean the scripts -- all of which were already written?
It was a well understood technology that provided skeleton.templates for
new services that were remarkably easy to generate services with.

Well, you've made your point, you don't like systemd, and you're still frustrated about the fact that systemd became the de facto standard.
You don't get my point.
It's systemd's bad design I don't like. You can't replace
parts and it doesn't allow use of standard interfaces if you tried.
Maybe I want systemd to start my daemons, but not be PID 1.
Will it allow that? Nope. Because it ties everything together, I can't
use the parts I like -- give it everything, or nothing are the two
options -- systemd was designed to not allow use of it's parts separately
from init.
A simple init could have provided info on processes dying with a subscription model, the same way the OS provides notices of
file-alteration through something like famd -- allowing many programs
to use the notification feature.
The programs don't have to be installed in the kernel to
monitor the files or monitor process death. But if one program replaces
the standard interface and famd breaks? A bunch of other programs
stop working.
That systemd replaces pid-1 disallows any other "sharing" program that
could notify all programs -- not just systemd or its tentacles.

If anything goes wrong in systemd, you need to do the Microsoft-reboot
dance, which is pathetic. I can't see businesses worried about uptime
being happy about that.
Init(pid1) could be a small separate program that was built for a
specific purpose and provided a pid-death-notification service that
could be used by "anyD" and wouldn't be hard to write -- but it won't
work with sysD, which, I'm told, won't run unless it is started as
pid-1. That's what I mean by sysD not being a team player that even
*allows* any alternative -- it shuts down avenues of compatibility.

To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
This Thread