Well, I’ve read enough of the arguments against systemd to know that they are not mostly about personality, some are, and some are also about having been misled. I couldn’t produce a technical list either, but then I’m not making any claim about how much has been refuted, nor whether it was successful in doing so.
On Thu, 22 Oct 2015 19:56:01 +0000, consused wrote:
> Well, I’ve read enough of the arguments against systemd to know that
> they are not mostly about personality, some are, and some are also
> about having been misled.
A fair number of the objections about systemd have to do with the fact
that it came from Lennart Pottering - and that led to the general feeling
(based on some peoples’ bad experiences with pulseaudio) that there must
be something seriously wrong with systemd.
That was early days, but a lot of that feeling persists today.
The bulk of the people who feel that they were misled were, IMHO, looking
for things to say that were misleading because Pottering was instrumental
in the creation of systemd - the assumption being that since he was
involved, it must be screwed up, because look at how screwed up pulseaudio
is/was.
Personally, I don’t really care about his personality or what supposed
“sins” he committed with pulseaudio - I’ve never had any significant
problems with it.
But when one starts with “it must be bad because of who created it”,
there tends to be a lot of FUD involved.
> I couldn’t produce a technical list either,
> but then I’m not making any claim about how much has been refuted, nor
> whether it was successful in doing so.
The main list of issues that I remember seeing about this were refuted at
http://0pointer.de/blog/projects/the-biggest-myths.html
The technical points made here seem pretty sound to me. People complain,
for example, that systemd is monolithic. As noted, systemd, fully
configured, has 69 separate binaries - the opposite of “monolithic”. To
me, that claim is like claiming that the Linux kernel is monolithic, in
spite of the underlying modules architecture.
Another big one is that it isn’t backwards-compatible to sysvinit - but I
can tell you from having written sysvinit scripts that work with systemd,
the compatibility module (which is included at least in openSUSE 13.2)
works just fine here.
That’s just two examples out of the list of 30 outlined at the referenced
link. Every single discussion I’ve seen about systemd and how “evil” or
“bad” it is comes down to one thing: Lennart Poettering created it,
therefore it must be awful, because pulseaudio sucks. Lennart Poettering
is shoving it down everyone’s throats, so get rid of it, because he’s a
“bad person”.
That’s not a very good technical argument. It is, in fact, the opposite
of a good technical argument.
And what it really seems to me to boil down to is “systemd is different
than what I’m used to, so now I have to go learn something new, and I
don’t want to do that.”
Like I said, I don’t really care one way or the other - decisions about
what init system are used are not something I really care about - but
what I do care about is when the debate turns personal - and where systemd
is involved, it seems to always turn personal.
Jim
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
On Thu 22 Oct 2015 02:56:01 PM CDT, consused wrote:
malcolmlewis;2733178 Wrote:
> Hi
> Who owns PID 1…
>
> I’m happy for the computer to start up and do what I want it to do…
>
And you think that’s a “helpful” summary? Hmm, tough luck on the
situations where it doesn’t start up and it’s more difficult to
diagnose.
Hi
Maybe I should have said “who’s on PID 1(st)” 
I’ve had one bug related to systemd with one package I maintain, a
simple fix and all done. It’s sometimes extra work to create both an
init script and a systemd service since I use systems with both.
Never had an issue with bringing systems up, have had more issues with
the btrfs implementation and snapper in it’s early days.
–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
SUSE Linux Enterprise Desktop 12 | GNOME 3.10.1 | 3.12.48-52.27-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
On 10/22/2015 07:25 PM, Jim Henderson wrote:
…
>
> Another big one is that it isn’t backwards-compatible to sysvinit - but I
> can tell you from having written sysvinit scripts that work with systemd,
> the compatibility module (which is included at least in openSUSE 13.2)
> works just fine here.
Thanks for posting this… how do we do system wide resource settings like what
we used to do with initscript? It’s a compatibility thing I haven’t figured
out, but obviously systemd can do it. Sorry about hijacking the thread a bit.
On Fri, 23 Oct 2015 01:54:56 +0000, Chris Cox wrote:
> On 10/22/2015 07:25 PM, Jim Henderson wrote:
> …
>>
>> Another big one is that it isn’t backwards-compatible to sysvinit - but
>> I can tell you from having written sysvinit scripts that work with
>> systemd,
>> the compatibility module (which is included at least in openSUSE 13.2)
>> works just fine here.
>
> Thanks for posting this… how do we do system wide resource settings
> like what we used to do with initscript? It’s a compatibility thing I
> haven’t figured out, but obviously systemd can do it. Sorry about
> hijacking the thread a bit.
It’s probably worth starting a separate thread on to get more attention -
that’s something I don’t think I’ve personally had to deal with.
Jim
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
systemd is compatible with “well behaving” sysvinit scripts. But because with sysvinit there were no real rules to follow, authors of those scripts could do anything so there are scripts that are not compatible. Sometimes changing such script is too much work. Sometimes it is overall impossible because they are out of your control (third party software). And when scripts can be fixed the obvious question is “what is the benefit and why not start with systemd unit in the first place”.
So it does have its reasons and it is not completely false. systemd is no****t drop-in replacement where initscripts are concerned.
On Fri, 23 Oct 2015 04:06:01 +0000, arvidjaar wrote:
> So it does have its reasons and it is not completely false. systemd is
> no**t drop-in replacement where initscripts are concerned.
And if you read over the answer to that question (#21), the explanation
there seems to make perfect sense to me.
If the scripts are that convoluted, then it’s probably time to re-
architect the scripts. Enforcing structure is a good thing - trust me, I
know about that (I manage content - documentation and so on - for my
employer; taking unstructured content written in Word and other similar
programs and trying to get it consistent is not an easy task - but it IS
possible, just takes a lot of work).
I don’t see it as a bad thing if there isn’t 100% compatibility if it
forces people to not write stuff that could pass for an entry in the
IOCCC. 
Jim
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
Why you assume I did not?
If the scripts are that convoluted, then it’s probably time to re-
architect the scripts.
Which is one of the biggest complaints about systemd as a project - the attitude “I broke your script, it is up to you to fix it”.
On Fri, 23 Oct 2015 06:26:01 +0000, arvidjaar wrote:
> hendersj;2733245 Wrote:
>>
>> And if you read over the answer to that question
> Why you assume I did not?
Simply because your hypothetical was covered by the answer.
>> If the scripts are that convoluted, then it’s probably time to re-
>> architect the scripts.
>
> Which is one of the biggest complaints about systemd as a project - the
> attitude “I broke your script, it is up to you to fix it”.
In computing in particular, change is one of the very reliable constants.
But you could also read it as “you wrote a script that wasn’t solid
enough to survive the constantly changing landscape of Linux - and it’s
up to you to architect a better script”.
Or, you could even interpret it as “I broken your script, it’s up to you
to report the problem so we can either address why it broke, or we can
identify that it’s not something we can or should fix because it would
expose <whatever>, so you will need to fix your script.”
But the bottom line here is this: Just like the ML discussion about
dropping 32-bit support in Leap, there are /lots/ of people who want to
complain about systemd, but very few - if any - who are willing to step
up and provide an alternative.
If systemd causes anyone that much trouble, and after trying to fix those
problems, there is /always/ the option for the community to organize an
alternative. If part of the community wants sysvinit over systemd, fine
- that part of the community is welcome to create a community-based
variant that fills that need.
In my personal opinion, though, those who want to complain about it will
probably find that fixing their sysvinit scripts so they work with systemd
will be far, far easier than trying to maintain a community-based variant
of the entire distro. But if that particular itch is something they want
to scratch, there’s nothing stopping that from happening.
Jim
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
I remember those days, so Jim please put your whitewash and brush away. They (led by LP) earned that bad reputation while developing PulseAudio, and only have themselves to blame for that. The evidence for it was in plain site on their website, more specifically to be seen in their excuse for a maintenance ticketing system. I spent a long time reading there to see what all the fuss was about. They were forced in the end to deal with broken or missing stuff they were trying to duck. Along the way, the reputation for arrogance and lack of cooperation with other developers was forged.
Gnome’s P/A was implemented first in openSUSE, I think, wasn’t P/A originally developed for Gnome, but the early KDE4 integration was more complicated and much more problematic. I can imagine openSUSE devs having difficult times dealing with LP and friends, and as someone defending on Factory ML said the decision for systemd wasn’t taken lightly given who they would be dealing with!
On Fri, 23 Oct 2015 17:46:01 +0000, consused wrote:
>> That was early days, but a lot of that feeling persists today.
> I remember those days, so Jim please put your whitewash and brush away.
The problem is that as far as some people are concerned, there’s no
forgiveness possible for LP. None, whatsoever.
It’s time people move past that history.
Jim
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
If there are still some people expressing that old grudge, then it sounds like a form of “bike shedding”, certainly in discussions re systemd.
Once upon a time, PulseAudio caused serious problems for users needing to remove it, such as pro/am musicians using the JACK sound server or users with familiar configs that just didn’t require P/A. For most desktop users today it provides a reliable audio experience for a range of multimedia players, and gui-based configuration tools. It can also be removed, or even suspended by adding a simple command in JACK’s setup program (qjackctl).
P/A did replace inadequate or unmaintained sound servers, but it didn’t affect system administration generally, nor the operating system’s other servers, nor does it contribute to a centralized design approach in the way systemd does.
I don’t recall any particular “mission creep” with P/A, where in the case of systemd LP attempts to sanitize it as “feature creep”. Mission creep should always raise questions like “hmm, did I sign up to that, so where is this heading, and how does it impact other projects and the ecosystem in which it is operating?”
LP wants to unify components across the distros, because he and friends think they know what makes a good operating system. Oh, and there was me (and I hope some others) thinking that the diversity and fairly good-natured competition, between linux distros and between the component projects, both gave rise to many continually improving and easily accessible technologies.
On Sat, 24 Oct 2015 15:46:01 +0000, consused wrote:
> hendersj;2733331 Wrote:
>> On Fri, 23 Oct 2015 17:46:01 +0000, consused wrote:
>>
>> >> That was early days, but a lot of that feeling persists today.
>> > I remember those days, so Jim please put your whitewash and brush
>> away.
>>
>> The problem is that as far as some people are concerned, there’s no
>> forgiveness possible for LP. None, whatsoever.
>>
>> It’s time people move past that history.
> If there are still some people expressing that old grudge, then it
> sounds like a form of “bike shedding”, certainly in discussions re
> systemd.
Indeed, it is. 
> LP wants to unify components across the distros, because he and friends
> think they know what makes a good operating system. Oh, and there was me
> (and I hope some others) thinking that the diversity and fairly
> good-natured competition between linux distros and the component
> projects gave rise to continually improving and easily accessible
> technology.
There’s nothing stopping anyone from creating another init system, or
continuing to maintain sysvinit.
The continual pining for sysvinit comes across as “will someone just DO
this?” - but what it takes for someone to do it is for someone to do
it. As the slogan goes, “just do it”.
Jim
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
On Sat, 24 Oct 2015 19:36:13 +0000, Jim Henderson wrote:
> There’s nothing stopping anyone from creating another init system, or
> continuing to maintain sysvinit.
Indeed, that’s where systemd came from - several people who were not
happy with Upstart deciding to start over.
Upstart came from a desire to move away from a serial startup system to
an event-driven system.
Jim
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C