2 options ReaperX7.

with pam support it builds everything.
without pam, it does not support user sessions.

I meant what all services will your implementation of systemd provide other than init boot service, and daemon management?

And yes, without logind we will be using ConsoleKit for user sessions.

systemd.hostname - http://www.freedesktop.org/wiki/Soft...temd/hostnamed
systemd.timedated - http://www.freedesktop.org/wiki/Soft...temd/timedated
systemd.machined - http://www.freedesktop.org/wiki/Soft...stemd/machined
systemd.journald - journaling system of systemd

That's actually fairly minimal of an implementation and fairly non-invasive.

To be honest having only six core services being supported by systemd would give a lot of flexibility to the system. This is the implementation I doubt even Lennart would have thought of as balanced and reasonable rather than ultra-invasive. Minimal yet flexible. You may have actually done what we may have deemed impossible due to how Lennart designed his monstrosity. You may have also gotten my respect.

My only, and last, remaining question is now Bart, and I hope I don't say this wrong, can other parts of the system such as the packages still be built with or without systemd as a dependency at the choice of the person who's building the package?

I've installed systemd with PAM support on a Slackware64-14.1 VM.

I did not install cracklib or libpwquality (I added --disable-cracklib to the PAM SlackBuild). systemd was not installed as the default init, so as suggested in your wiki I added it to the kernel boot parameters. Both init systems are working.

I've briefly played around and have noted a few things so far:
localectl list-locales complains "Failed to open locale directory: No such file or directory". From the source code systemd seems to be looking for /usr/lib/locale but the locales are in /usr/lib64/locale on 64-bit.
Currently with the default settings the kernel loglevel does not seem to be set (it was previously set in rc.sysinit), so more messages than normal appear on the console, which is a bit annoying. I guess this can be solved with a service file or some other form of configuration. In the meantime I will probably just modify the loglevel in the boot options to make it slightly quieter.

I'll play around a bit more after I read up on systemd configuration and also when I find more time.

Hope this helps.

I'm going to try to answer this one.

The short answer is yes. You would be hard pressed to find packages today that outright require systemd, except for utilities that operate directly on top of it, like systemd log viewers.

Examples: PulseAudio 4.0 can be built with systemd support, but this can be disabled at compile time. Lightdm can use logind directly, or it can use consolekit, though it appears to decide at runtime. Transmission builds with systemd service files if systemd is detected, but this can be disabled at compile time.

I doubt this is going to change for a long time, if ever. There may be a bit of systemd fervor right now, but Ubuntu still exists and still uses Upstart instead. On top of that, many packages still want to maintain compatibility with Windows, Mac and the BSDs, which means not getting tied down to any init system. The only packages that will consider doing this are the ones that are fine with restricting themselves to specific Linux distros, such as GNOME.

If this is the case, this is the sanest build of systemd that only replaces the bare minimum of sysvinit/bsdinit scripting to date I've seen.

While I would say test away and ensure full working order, this solution does still present choice rather than no choice. Time will tell how well it does but you've shown that systemd can effectively be downsized to a minimal high functioning core system daemon that doesn't wrap its tendrils around the system and choke it to death.

While I don't see it being a mainstay, I would have no problems seeing it up on Slackbuilds.org as an alternative alongside OSSv4 and other alternative software sets.

Systemd can be minimal and sane but it's going to still going to have to prove itself. And honestly in my opinion Lennart should focus on porting systemd to other UNIX systems rather than stay solely on Linux, but too many people want to see big brand UNIX like Solaris, HP-UX, and the BSDs go away it's not funny. The UNIX ecosystem shouldn't be what it's turning into.

i wish there would be a way to have systemd as a plain replacement of sysvinit.. what do i mean by plain? well.. no logging (journald) - leave job do a syslog daemon (rsyslog, syslog-ng, syslog), no managment of hostnames or time leave that to ntpd and /etc/hostname.

i dont want to flame.. that shell not be a flame, but i dislike systemd most for that is trys to take over things like logging, hostname and time, which was the job of any initsystem i ever have seen. (sry for my bad english)

if one could bring systemd down to plain replaceing sysvinit (starting/stop) i would take it.. i dont even say anything against logind if consolekit would really be that bad it needs to be replaced. i dont want/like it if modularity is taken away.. let syslog and ntp manage plaintext logging and time please.

isnt it possible (i know mr systemd doesnt want that), to patch at least journald out of systemd??

friendly greatings.

Small thing: I notice your slackbuilds now contain a polkit build, but there's no mention of it in the build order/instructions on your wiki.


Good job so far, I'm still watching with interest.

It seems I will need to specify the locale directory

--localedir=/usr/lib$LIBDIRSUFFIX

I will add it to the slackbuild

stuferus, journald can not be disabled as far as I know.
you can however use the newer versions of rsyslog that support journalctl, so that you still have some classic logging in /var/log/message, etc.

the slackbuild has been updated with --localedir.

yes I added polkit, and planning to add NetworkManager.
and write on the wiki some part of networking.

Lately I was discussing OSes and/or initialization scripts with someone on Freenode IRC, and (s)he assumed my OS has systemd and who knows what else, maybe from LSB or some other standard (because, paraphrased 'any modern GNU/Linux has all this'). I do not know if I knew, but eventually stated Slackware does not have systemd, and was arguing why Slackware is the top OS, and most modern, of all, even if it does not have systemd, and maybe because of that--not that I have an opinion on systemd, just an opinion that Slackware is doing it most correctly of all. I started using BSD and Slackware in 1998, and over the years tried Slackware more and more, until being able to use it basically exclusively many years ago, then also trying running a server with something also called a Unix, so I recalled that I went through when Slackware switched back and forth from various systems like systemd.

I may not be interested enough to bother trying it, but since I have heard systemd will make things faster, and can integrate udev, it sounds good. If there is some interesting mathematical or abstract computer science software that requires systemd, I would like to know and might try it, but that is not likely the case, unless I wanted to learn about systemd itself for a computer science exercise.

Good luck on your project of getting systemd working... I hope that when it integrates udev, that will all work out, and if Pat decides (or if you mean the udev project will be integrated into systemd), then it will have systemd again and become even faster (not that I ever have much of a speed problem, but hopefully whatever problem he had last time--which maybe ReaperX7 mentioned--will be dealt with).

I do not really care if KDE or Gnome use systemd, because though I use KDE, I would like to use TDE, and there is not only Wayland but one or two other new X11 alternatives... what sounds interesting to me is if when udev is integrated, it may (or may not) be easy to transition to systemd, then the OS will be faster/fastest. I have used GUIs daily since maybe Windows 3.1 (or at least 98), but I always boot to a shell on a text terminal device, and I could not care less about GUI debates as long as one works enough like a combination of pre-OSX Apple, and Windows 9x.

What other SlackBuilds are depending on systemd?

nothing depends on systemd at the moment.
everything can be build without.

there are some software that looses functionality without systemd (gnome-power-manager) to name 1
you need to patch some things and write scripts in order to make it work.

to bad one cant patch out journald thats the core part i dont like on systemd (a part from the unitfiles).

but still good luck with your project.