Noticed this while doing an update:
/etc/dbus-1/system.d/com.redhat.NewPrinterNotification.conf.new

Did not like the look of that, so looked into the folder and found more...
Is slackware going systemd?
If it is a yes, that would be very sad.
If no, how do I purge all this RedHat stuff and deny it from creeping it again?

bash-4.4$ ls -lh /etc/dbus-1/system.d/
total 148K
-rw-r--r-- 1 root root 9.0K Nov 19 2015 ConsoleKit.conf
-rw-r--r-- 1 root root 1.5K Sep 15 02:39 bluetooth.conf
-rw-r--r-- 1 root root 752 Sep 22 11:50 com.hp.hplip.conf
-rw-r--r-- 1 root root 1007 Nov 19 2015 com.redhat.NewPrinterNotification.conf
-rw-r--r-- 1 root root 1000 Sep 22 11:49 com.redhat.NewPrinterNotification.conf.new
-rw-r--r-- 1 root root 1016 Nov 19 2015 com.redhat.PrinterDriversInstaller.conf
-r--r--r-- 1 root root 460 Jun 15 2016 cups.conf
-rw-r--r-- 1 root root 1.1K Jan 6 2017 dbus-wpa_supplicant.conf
-rw-r--r-- 1 root root 465 Sep 22 02:58 nm-dispatcher.conf
-rw-r--r-- 1 root root 403 Sep 22 11:53 org.blueman.Mechanism.conf
-rw-r--r-- 1 root root 422 Jun 20 08:43 org.freedesktop.ModemManager1.conf
-rw-r--r-- 1 root root 9.3K Sep 22 02:58 org.freedesktop.NetworkManager.conf
-rw-r--r-- 1 root root 638 Jun 20 06:53 org.freedesktop.PolicyKit1.conf
-rw-r--r-- 1 root root 1.3K Nov 21 2015 org.freedesktop.UDisks.conf
-rw-r--r-- 1 root root 525 Jun 20 06:38 org.freedesktop.UDisks2.conf
-rw-r--r-- 1 root root 1.8K Mar 5 2016 org.freedesktop.UPower.conf
-rw-r--r-- 1 root root 570 Feb 23 2016 org.gnome.GConf.Defaults.conf
-rw-r--r-- 1 root root 434 Sep 2 18:54 org.kde.auth.conf
-rw-r--r-- 1 root root 302 Oct 25 2015 org.kde.baloo.filewatch.conf
-rw-r--r-- 1 root root 295 Jun 24 2016 org.kde.fontinst.conf
-rw-r--r-- 1 root root 300 Jun 9 08:07 org.kde.kalarmrtcwake.conf
-rw-r--r-- 1 root root 304 May 7 07:19 org.kde.kcontrol.k3bsetup.conf
-rw-r--r-- 1 root root 304 Jun 24 2016 org.kde.kcontrol.kcmclock.conf
-rw-r--r-- 1 root root 302 Jun 24 2016 org.kde.kcontrol.kcmkdm.conf
-rw-r--r-- 1 root root 306 Oct 25 2015 org.kde.kcontrol.kcmkwallet.conf
-rw-r--r-- 1 root root 312 Jul 18 09:20 org.kde.kcontrol.kcmremotewidgets.conf
-rw-r--r-- 1 root root 314 Jun 24 2016 org.kde.ksysguard.processlisthelper.conf
-rw-r--r-- 1 root root 304 Jul 18 09:17 org.kde.nepomuk.filewatch.conf
-rw-r--r-- 1 root root 609 Jan 12 2012 org.kde.polkitkde1.helper.conf
-rw-r--r-- 1 root root 313 Jun 24 2016 org.kde.powerdevil.backlighthelper.conf
-rw-r--r-- 1 root root 305 Oct 25 2015 org.kde.wicdclient.scripts.conf
-rw-r--r-- 1 root root 1.1K Feb 4 2017 pulseaudio-system.conf
-rw-r--r-- 1 root root 2.2K Mar 27 2016 wicd.conf
bash-4.4$

The directory is system.d, not systemd.

4 members found this post helpful.

EDIT: See edit at the bottom after Gerard snapped me back to reality

They are default location for those files. Packages expect them to be there and it's much easier to use the default directory than to patch all the programs to find them someplace else.

This is not a sign that systemd is being incorporated into Slackware, just that many programs are starting to use directories with the expectation that systemd is installed on the system.

There is no easy way to purge all of that except to remove and blacklist all the packages that add those items. And it isn't a small list. There's 27 packages that use it (on 14.2).

EDIT: Good catch Gerard! It is common to see conf files stored in .d directories of the thing that uses them. X has xorg.conf.d, profile uses profile.d, sane uses sane.d. I totally spaced this with my above post.

However, there are still a few programs that have systemd in their structure. You can see that using grep systemd /var/log/packages/*, however these files are harmless and are just things those programs provide by default. They were just never removed by the SlackBuild (because they don't harm anything and only take up a few extra KB of system space).

3 members found this post helpful.

That may be and it has pulse in there too.
Simple find shows
/usr/lib/systemd
/usr/lib/systemd/system
/usr/lib/systemd/user
/usr/lib/systemd/system/hplip-printer@.service
/usr/lib/systemd/system/phoromatic-client.service
/usr/lib/systemd/system/phoromatic-server.service
/usr/lib/systemd/user/at-spi-dbus-bus.service
/usr/lib/systemd/user/glib-pacrunner.service
/usr/lib/systemd/user/xfce4-notifyd.service
/usr/lib64/rpm-plugins/systemd_inhibit.la
/usr/lib64/rpm-plugins/systemd_inhibit.so

The reason I like Slackware is it remains absolutely stable and did not succumb like Debian and so many others did.

How do I purge anything systemd related from my main machine?

1 members found this post helpful.

As far as I know some sort of shim has been introduced to trick software that expects systemd into thinking systemd is really present. If this works I'm all for it, but as time goes on it's not going to get any easier to keep this dirt out of Linux. Someone has even started work on a systemd fork for OpenBSD.

2 members found this post helpful.

I covered this in my edit, however, these programs provide those .service files in the source and likely the installing of the package. .service files are the equivalent of Slacwkare's /etc/rc.d/rc.PROGRAM files. They're just used to start up the program based on certain conditions. If systemd isn't installed, then they aren't used. Pat just decided to not remove them from the system, because they don't do anything. If you want to purge them from your system, find the packages that create them and remove and blacklist them. Or patch the SlackBuild to prevent these files from being packaged.

However, you should know that Pat and team have never said they're staying systemd free. They've only stated that they aren't switching so far. If things change enough, it is very possible that Slackware could add systemd. Have a look at these posts by Pat for more details. He doesn't want it, but it may become inevitable (let's hope it doesn't).

7 members found this post helpful.

Once upon a time someone who didn't take the time to find and read previous threads about systemd and Slackware opens yet a new thread on the same topic.

Again and again.

That's rather boring, but what can we do? There will always be people beating dead horses, we can live with that.

4 members found this post helpful.

@bassmadrigal and @Gerard
Sure pray it never happens.
For example, everybody is aware of the poor practices from the systemd maintainers:
it.slashdot.org/story/17/07/03/0343258/severe-systemd-bug-allowed-remote-code-execution-for-two-years
suckless.org/sucks/systemd

Not wanting to start another systemd bashing/flame war/etc here, that would make a lot of our good folk frustrated in many ways.
Just want no part of this systemd debacle on my main machine.

That's it exactly. We don't gain anything (other than negligible space) by removing those files, and they would be useful to someone wanting to implement systemd on their system. If someone wants to do that, I'm not going to create obstacles for political reasons.

27 members found this post helpful.

I think we can all agree on that. Then again, systemd is not the only problem Linux has. The kernel developers' seeming indifference to security flaws in the kernel is just as worrisome. For a long time this was mitigated by grsecurity, which is no longer available to the average Joe.

Appreciate the input.
My immediate worries have been assuaged.
Let's close this thread as resolved.

1 members found this post helpful.

As the original poster (OP), you can do just that. At the top of the thread you opened, there should be a link that says "Mark this thread as [SOLVED]". Go ahead and click that.

1 members found this post helpful.

Have u heard bout BSD ? ? ?

Have u read bout post #5 ? ¿ ?

10 members found this post helpful.

I don't like the philosophy behind systemd, even though it may work for some. PV has managed to avoid other elements of an OS that other distros consider mandatory, I am sure he can avoid this one as well. If not, then I have confidence that PV, RW and EH as well as others will figure out how to gut systemd so that only the absolute minimum required to boot remains. Wait, thats BSD style sysV....never mind then...but seriously, there are bigger problems in this world to worry about then systemd invading Slackware, especially when you have a guard at the gate that has not left the post in 24 years.....

5 members found this post helpful.