yes Reaper, this is possible.
you decide when it starts and on what conditions.

1 members found this post helpful.

Once again Bart, good work.

This actually may be the ONLY thing that will have to be considered for servers but for end users it may prove beneficial also. In fact if the networking start and networking daemons and services can be linearly loaded, systemd might have a chance, but in my honest opinion, it's still better suited to be an alternative solution, but there is only one last thing I'd like to question...

Would there be ANY way to remove the hard dependency of systemd by other packages to where even if you add in or remove systemd nothing has to be replaced or built?

I'd like to know how many arms we can chop off this octopus if possible.

The only package that does need to be rebuild is dbus.
However, with the current development, they are implementing kdbus (kernel dbus)
so this might be solved in future releases.

Yes, it'd be nice to have the octopus completely controlled and simply a drop-in/drop-out package. I saw kdbus being considered but no time table was given.

You an expect the 208 build the latest stable build (this one will be used in rhel 7 - it is already in beta)
The development is now in progress of switching to kdbus if you follow the git commits.

the 209 build will be with kdbus.

imo 208 is currently a stable version that can be worked with.
some patches might be considered, but are not mandotary.

On a side note: the Debian developers just voted in favour of systemd for their next release.

https://lists.debian.org/debian-ctte.../msg00338.html

I've been using Debian on servers and desktops for a few years, so it will be interesting to see the consequences of this decision on a traditionally rock-solid distribution.

1 members found this post helpful.

It means that there are 2 major distributions that are not using systemd at the moment, or undecided
thats Ubuntu (upstart) and slackware (sysvinit).

The Major distribution imo are as follows:

Rhel (beta 7 runs systemd) - centos will have systemd with 7 aswell in this case - fedora is using systemd for some time
suse (suse enterprise 12 will use systemd) - opensuse is using it already
ubuntu (using upstart)
debian decided to go for systemd
slackware - still using sysvinit

There are alot of other distributions that are not Major but big, like archlinux for example
alot of them uses systemd aswell.

Well, I'm not sure that game be over inside Debian's TC...

Sometimes I feel comfortable using a distribution managed by a BDFL

I'm curious how Pat will decide. There is a latin saying: variatio delectat (“variety gives joy”). I think a systemd monopoly would be a bit unhealthy.

And so another falls...

By technicality Slackware doesn't use sysvinit. It uses a hybridized version of bsdinit with sysvinit compatibility.

LFS has a book for an LFS-systemd, but it's not as detailed as the main LFS which still uses sysvinit. It's more or less a experiment still and outside the LFS book.

There are a few other distributions out there that use other init systems still.

GoboLinux
PardusLinux

And Gentoo is still mainly OpenRC.

There's at least a dozen init systems out there.

2 members found this post helpful.

Back on topic, I noticed that, after installing systemd (without PAM), booting with sysvinit results in a not existing /dev/shm, which is needed for some programs to run. This should definitely be fixed somehow. I sadly have no clue what is going wrong, except that I suspect udev to be the culprit here. I can for now not check if the same issue also appears when booting with systemd, I have currently only remote access to that machine.

You know what I mean Reaper.

Tobi, apart from your install problem, did you encounter anything special.
I haven't heard any problems lately regarding the use of systemd in slackware as how I provided it.

Other than what I just posted I couldn't test it really, I have to first figure out how to work with it. For now I have to set keyboard layout manually after boot, automatically activating swap doesn't work, as it seems due to a corrupted path to /dev/disk/by-uuid/{UUID} and switching to the graphical target doesn't work, as it seems due to a lack of .service file for any display manager. I will have to learn a bit more about that.

If needed this should fix /dev/shm missing Tobi...

if [ -h /dev/shm ]; then
mkdir -pv $(readlink /dev/shm)
fi

provided your fstab does mount /run for the tmpfs.

It's a quick fix but it works. As far as the services files... ArchWiki maybe might have something.

well you are in control.
you decide which graphical target you want to start.
in other words, if you want the graphical loader of KDE (not sure what it is) I use Gnome (GDM)
you can create a standard .service file and place it inside the directory graphical.target.wants

The swap is indeed an issue on certain installations.
also UTF8 is needed (forgot to list that somewhere I think)