If you want eudev instead of systemd, you just reinstall the replaced/updated packages.
And look for eudev slackbuilds.

Dbus is required for systemd, that is the only real required package that systemd needs.

The rest can basically be options.

systemd is still working together with The CoreOS team, to implement kdbus directly into the kernel.
This would remove the need for dbus, and the I/O communication is shorter.

This would also make it easier to switch to and from systemd.

After months of working on this project I can give a better opinion about how well systemd is operating compared to slackware's stock init.

my v208 of systemd uptime

root@systemd-slackware:~# uptime
12:59:40 up 100 days, 1:21, 1 user, load average: 0.56, 0.51, 0.45
root@systemd-slackware:~#

A question I have asked myself is:
Is systemd required, handy, needed ?

for required I would say NO
a systemd can easily be used without systemd

for handy I would say YES
there are alot of things that makes systemd handy for server admins.
pid/child pid, display and killing/monitoring of processes
The extra feature like multi-seat sessions is pure dependable per user

for needed I would say FOR NOW NO
as it is not required, the question regarding the needed all depends on what's the gain when using it.
I have an uptime of 100 days, and reports about crashing of systemd are older than 2y.
RH released RHEL 7 and included v208 showing everyone: we think/believe systemd is stable.

I dont see any real difference in operating side, except that the bsd startup scripts will be useless and replaced by systemd.service files.
as long as there is no functionaly and features loss in other software when systemd is not used, than systemd is not needed.

So for now I am asking myself, What functionality would be a loss if we dont use systemd to make systemd needed/required for slackware
I think, that PV has that question in his mind and when he answers that questions, systemd will enter slackware.

Untill than I will keep on creating the slackbuilds for systemd.

4 members found this post helpful.

Uptime is also not any kind of 'good sign' that systemd has done anything so great as to replace any other init system. Superb long uptimes can be found all over the place long before systemd was around.

If it weren't for being in an area that has constant blackouts to the point my UPS is just there to keep my hdd safe, I'd have uptimes far exceeding 100 days (and I actually have hit 123 once, which I thought was amazing, heh) and my load averages are like this ever since the year 2000:

So is journald.
It is not an option when those services depend on systemd. You have to recompile them (at a minimum) to be able to function without systemd.
Not unless the services will work with and without systemd without recompiling. Unfortunately, to have both means you STILL have to have the systemd libraries installed even if they function without them.
My 486 system ran for a year... until I had a power failure.
There are other ways that have been done for quite a while for those features.
Look for system hangs... on boot and shutdown.
http://forums.opensuse.org/showthrea...r-systemd-fsck
http://superuser.com/questions/76741...-during-reboot

On the second one, note the problem: hangs 1 out 10 reboots...

Still happening, still unreliable, still not fixable.

Reliability is lost with systemd.
No functionality is lost without systemd. Most of the time systemd does boot a little faster...

3 members found this post helpful.

the 2nd one is very case specific: upgrading from v196 to v198

the problem on opensuse is a user error.

dbus would not be a requirement and will be able to operate with or without systemd. no special systemd libraries needed.
both connect to kdbus. no need to recompile.

No. The services using dbus have to have systemd to respond.

Now, having the services compiled WITHOUT systemd would remove that dependency, and remove the dependency on dbus.

Now, kdbus is a different animal... and uses a different library. But in either case, as those services are written now, they use a dbus specific library that has all the systemd communications requirements built in. I would expect anything using kdbus to also use/require those libraries as well. Though there might be some internal differences in the library itself. So any alternate init system would also have to supply an equivalent library.

At least, until a generic library is written with yet another configuration file...

But that becomes borderline with a different distribution...

On Gentoo it is no problem at all to have a fully functioning system with OpenRC and systemd installed, where you decide at boot time, using the init= kernel option, which init system to use. No recompile needed.

Thanks - that does indicate that the services have both capabilities compiled in.

On fedora that isn't true. If you try to replace systemd, you get lots of failures - and the system is unusable.

I would guess that the Fedora developers don't deem replacing the init system as something someone would do (after all, it is somewhat like systemd's "main distro"), so it may indeed be that they have stripped away or patched parts of the services to better run with systemd without looking for compatibility with other init systems.
This would indicate that it should not really be a problem for distros that want to have several init systems available. I know at least that this is possible for Gentoo and that this will be possible Debian 8/Jessie, which comes with systemd by default, but is fully capable to run with sysvinit instead.

Quite - there was a LOT of pushback about systemd not working with F14, and was rammed down the users throats at F15, though it actually almost worked (the network support broke though). SysVinit was available as an option, but those that tried it reported the results non-functional. Even in Fedora 16 things were still broken (complex networks with more than one interface didn't work at all, virtual networks for VMs failed, though simple wireless laptop connections did start working better). Even in 17/18 people were still having to disable NetworkManager to use legacy startups to get the network just usable.

Even in F20 it doesn't work reliably, but for the simple case of desktops and laptops it appears to work tolerably well. Servers are where the problems are still occurring, and still without the ability to be easily debugged, log files get corrupted on crashes...

If it's still going poorly on Fedora 20 then chances are it's usage could get heavily re-evaluated eventually and a few decisions on it's future might have to be made. I doubt if by Fedora 22~25 at least, things haven't changed, by Fedora 26~30 they very well could be in-search-of yet another init system.

I doubt Red Hat's engineers are thrilled as well at this outcome. Isn't RHEL and Fedora somewhat tied together developmentally?

I really don't see how this could have gotten so out of hand, if systemd is a major project, it should have, in theory, top quality level quality assessment and control.

It hasn't! You and jpollard are spreading FUD in your own little land where sytemd is a catastrophic failure.

You are so, so out of touch with reality. When systemd is in RHEL 7 and you say:

I honestly don't know how to respond.

You have any evidence otherwise please by all means post Frog... We'd love to know otherwise... and if not... Pipe down!

6 members found this post helpful.

@unSpawn
thanks

my post post on this page might been misleading.
I just wanted to share my hands on experience while working on the project.
and telling you guys that you dont have to be affraid that systemd will enter slackware soon (I think)

but untill it is, I will continu with the project.
my 1st aim is to branch systemd when a new slackware comes out. (within 1 week)
and branch everytime a new slackware comes out.

so people can try and experience systemd on slackware.

and the thread here is to discuss problems in the script or things that are not working correct on slackware with my slackbuilds.