reaperx7, darth vader,

what if I make the build script in such a way, that you can enable/disable pam in that way.

That would make it a lot easier for people who consider trying out your work.

And in order to address unspawn's concerns: I sincerely dislike the whole concept of SystemD, and the way it is promoted. However, I do not regard your own work in any negative way - I encourage everybody to make more of his or her Slackware computer. If you end up with a working Slackware computer running SystemD, then that is a proper achievement which deserves respect, not scalding.

Eric

12 members found this post helpful.

1. Keeping rc.local usable is a key to keeping software daemons useful if they don't have, won't, or can't receive support through systemd. This is UNIX friendliness even while systemd isn't too POSIX compliant.

2. PAM disabled by default is a huge plus. PAM is just a bad concept from any way you look at it. I've had PAM lock out an entire system forcing a complete rebuild on LFS, and even after a week of backtracking through the system to see what went wrong, no solution except a reluctant rebuild solved it. Giving modulariry to ConsoleKit proves systemd can be minimized in impact. If even more can be modularized out that isn't necessary it'll reduce the overhead on lower end systems.

3. Documenting within the systemd daemon startup scripts will be a must have to ease transitioning. Having lots of predrafted handwritten scripts in a package all it's own will help rather than using the default scripts from the packages themselves.

You could always take the samples in the sysvinit and bsdinit scripts used by Slackware and translate them to systemd scripts with the commands altered only unless the systemd scripts do not allow for commented out embedded documentation in scripts.

Of course not, and I think systemd does have its usefulness. While rpm manages dependencies of files, systemd can manage dependencies of processes. However, it takes time before people can see its benefit.

A similar thing is communism. When people see it's good they will have it. Don't tell people "you need it". It's already proved unsuccessful.

UPDATE

- I am updating systemd slackbuild to have pam as option. [ standard disabled ]
- I am also updating systemd slackbuild to have default init as systemd as an option. [ standard disabled ]
- I am setting up a wiki instead of the current standard page, to extend the documentation.


ReaperX7:
rc.local is standard usable within systemd, and I made the needed effort to make sure that this works on Slackware.
you can actually create unit files to start from systemd for every daemon you want.
This is my inet1.service file (also included in the slackbuild)

Creating systemd unit files from all scripts in /etc/rc.d/rc.xxx is an option.
And I could offer this as a seperate resource, so that people can copy them and enable if needed.

More Documentation is being setup with a wiki instead of the now standard page I have on the website.

3 members found this post helpful.

UPDATE

Slackbuilds of Shadow and Systemd have been updated.
PAM is standard disabled. (also default init)
Read the slackbuild on how to boot into systemd if you leave the default init as /sbin/init. (lilo config addition required)

building shadow, systemd, dbus is sufficient to have systemd working.
I will update the openssh script for pam option aswell.

you can always start sshd with /etc/rc.d/rc.sshd start

Do we need cracklib ?

not if you build without pam.

openssh updated now aswell.

1 members found this post helpful.

I have created a wiki now instead of the standard simple page

Systemd for Slackware wiki

You can find here information on howto install systemd with or without pam.

7 members found this post helpful.

bartygymnast,

I was wondering if you could elaborate on your first bullet point on your Wiki page:Doesn't Linux From Scratch describe performing just such an extraction?

1 members found this post helpful.

It was possible before v208 to compile systemd, and extract the udev parts after compiling.

now you need to create your own Makefile, and use some parts of src/udev from systemd.
so they are not extracting imo, they are using parts of the source code.

thats why the line that it can not be extracted seperatly.

I have changed the description on thew wiki accordingly

In that case, I think it is less that udev cannot be extracted (because some distros do, even if it's with custom Makefiles), and more that extracting udev from systemd is unsupported.

1 members found this post helpful.

systemd-208 can still have udev extracted. LFS still uses this method but yes it is a custom makefile to modularize it and udev-extras out from the main tree.

I haven't seen any efforts yet to make udev un-extractable, though eudev and other udev-like projects are still in heavy development as a replacement, eudev was work last I saw, as well as mdev. The only project that I have no idea about is Hotplug2.

Cracklib can be included without PAM. Though if you build shadow with SHA-512 support, it might not be required at all.

This is an excerpt from my LFS's shadow build-install-setup script on how to build shadow without PAM:

Alternatively you can build with Cracklib support, without PAM still, just switch out the comment lines for ./configure and uncomment the sed argument.

Hmmm... interesting thought I'm having, but how much more could be modularized out of systemd back to other daemons and handlers without removing the main init portion and daemon handlers? Just thinking of how much more could be simplified.

thats correct Reaper,

It is not required, unless you build PAM.
otherwise it is an option to use or not.

1 members found this post helpful.

Okay, so what exact list of parts of systemd are you implementing at this time bart?