The mass exodus if Slackware uses Systemd

Gerard Lally · 02-19-2015, 07:17 AM

Quote:

Originally Posted by TobiSGD

firewalld is not a part of systemd. If you have problems with firewalld you may better contact its author instead of bothering the systemd people.

It is, however, a service systemd is supposed to spawn and control, is it not? If systemd fails to do that what good is it? What's it giving us that we don't already have? From my own layman's perspective it seems for all the convulsions we're going to have to put up with we're getting very little, if anything, in return, that we don't already have.

TobiSGD · 02-19-2015, 07:57 AM

Quote:

Originally Posted by gezley

It is, however, a service systemd is supposed to spawn and control, is it not? If systemd fails to do that what good is it?

And it does exactly that: It spawns the service and reports that the service bailed out with an error. What else should it do, bisect the firewalld code and try to find the bug? If there is a bug in [insert service name here] that prevents it from start, why is systemd to blame? If there is a bug in OpenSSH or its configuration on your Slackware system that brings the service down, do you start to blame sysvinit for it?

Gerard Lally · 02-19-2015, 08:04 AM

Quote:

Originally Posted by TobiSGD

And it does exactly that: It spawns the service and reports that the service bailed out with an error. What else should it do, bisect the firewalld code and try to find the bug? If there is a bug in [insert service name here] that prevents it from start, why is systemd to blame? If there is a bug in OpenSSH or its configuration on your Slackware system that brings the service down, do you start to blame sysvinit for it?

If you read my earlier post a little more carefully you will see I was talking about systemd and "systemd-related junk".

It's quite obvious ancillary software like firewalld has been developed with systemd in mind. The problem is not just systemd, but this flaky scaffolding around it as well. As you very well know.

hitest · 02-19-2015, 08:12 AM

I really do believe in free expression, but, this thread has given new life to beating a dead horse. After over 100+ pages and almost 1700 posts is it time to lock this train wreck? Just a suggestion.

ReaperX7 · 02-19-2015, 08:52 AM

Quote:

Originally Posted by Alien Bob

Let me add a last post before giving up on this ugly thread with its ugly Subject line.

You are ignoring the use-case for PAM.
If you have the time to tinker with your Slackware system and add PAM in a meaningful way, then that is not trivial, takes time, and introduces a maintenance burden because your computer may refuse to let you in after any official Slackware update if the "wrong" package gets updated and you did not notice. Also, this is a typical case where you are not going to have any use for PAM, since tinkering usually means, you are dealing with a single-user system.

Requiring someone like kikinovak to add PAM himself seems reasonable, because he can make a decision between the added work load of maintaining out-of-tree Slackware packages versus the increased functionality he can offer his customers (aka increasing revenue). Still, this strategy will introduce "islands" of non-standard Slackware setups that are hard to troubleshoot because if you post your issues here at LQ, none of us will be able to help because of the unknown implementation.
PAM is not evil despite rumors of the past. If implemented in a proper way, it will not add complexity to your computer. In its simplest implementation, you can just continue with your user management the way you are used even with PAM inbetween, while allowing others to add more complex authentication schemes without having to rebuild several core packages.

And that is what I said, just more drawn out. We could have a semi-standardized Linux-PAM package in SBo, for example, with enough of a detailed README-Slackware file explaining everything anyone would need to know. Rebuilding and reinstalling packages, configuration files, etc. Yes it would be "work" but that's not the point. The problem is until someone is willing to take it up, all we'll have is private out-of-tree packages in personal repositories.

Bart has done an exemplary job with his work and is leading by example of doing hard work with high pay out. His packages may never go official, but at least he's stood his ground and let his package speak for themselves.

As far as the use-case... it all depends is the best answer I can give you, and depending on what can be simple or complex on a case by case basis.

And yes, I agree with hitest, this topic has ran for enough time. By now we all should have gotten the information we all need, learned what we needed to learn, and forged our paths for whatever scenario comes, if and/or when.

TobiSGD · 02-19-2015, 09:19 AM

Quote:

Originally Posted by gezley

It's quite obvious ancillary software like firewalld has been developed with systemd in mind. The problem is not just systemd, but this flaky scaffolding around it as well. As you very well know.

systemd is not at all a dependency of firewalld. systemd is not mentioned even once on the firewalld website. So claiming it has clearly been developed with systemd in mind is somewhat weird. Can you back up that claim? When you are at it, still waiting for the numbers for your claim that Linux sysadmins are leaving Linux in droves for BSD.

jeremy · 02-19-2015, 11:18 AM

The foul language, hostile attitude and personal attacks contained in this thread are not acceptable here at LQ and will not be tolerated. I'm going to close this thread for some time to allow a cooling off period (Which is unfortunate; we should be able to respectfully and thoughtfully debated topics that we don't agree on). Additional threads created for the sole purpose of arguing over systemd will result in closures and/or bans. If you have any questions or comments on this, feel free to contact me directly.

--jeremy