We don't all have to go anywhere together. We can watch bartgymnast going somewhere alone, so long as we don't piss him off with negativity.

We should bear in mind this famous sentence: "Slackware is well known for its simplicity and the fact that we try to bring software to you in the condition that the authors intended." If that condition is broken-by-design, then it should be broken-by-design in Slackware. Plenty of software is broken-by-design. Observing the world outside Slackware, most people seem to prefer their software that way, or maybe they just have low standards. *shrug*

3 members found this post helpful.

Broken-by-design should have no place in a working stable system like Slackware that has one of it's prides as stability, especially if it's a system critical service daemon.

I think for now, we know how it works, how well it will work, and what else is going to have to be done to achieve a working system using this software.

Sadly, yes low-standards are what fuels the world today, and software sadly is not immune to this trend. It's the fact that distributions like Slackware, LFS, and others strive for higher standards, they get singled out and ridiculed for doing so. However, as we all do see, when higher standards continue onward, people see those as a point of interest and try out the higher standard stuff, and they find it is better.

1 members found this post helpful.

Correct. That is why systemd hasn't replaced SysV init in Slackware yet. But this thread is about the effort of a third party, trying to implement systemd in Slackware. If you think that this effort shouldn't be done then just stop contributing. If you want to try to port a different init system to Slackware then go ahead, start a new thread about that and just do it.

2 members found this post helpful.

Inspiring. There's a Mark Minasi book about 'bad software.' "The Software Conspiracy" A very good read. Google it. It's downloadable.

Most folks DON'T have the ability to make things different and just go with the flow. That could also be interpreted as 'low standards.'

Us Slack folk most likely do NOT fit into that category.

2 members found this post helpful.

At least, Fedora (at whatever said version) is able to self build without supplementary changing/patching of its sources. Slackware is not capable to self build, out of box, like I believe you known...

That's the point! The guy on horse who try to catch the bull is him, we... we only watch the show with a beer in hand.

Being older than the dirt, I remember the hungry speeches against adoption of UDEV, right there, in this forum. And how it limit your ability to configure your devices. And even I remember that someone invoked that popping up devices can be considered a security threat wich can NOT be tolerated in the so stable and secure Slackware.

Still, yet, right now, Slackware use UDEV by default...

Finally, to be on topic, ... finally!

I work at a patch to make SystemD to work directly with the shadow thing.

Not being a die-hard SystemD lover, but trying to sustain the Bart's wonderful work.

And yes, I have now a Slackware with SystemD init (without PAM) which work like a charm. And boot faster.

And it isn't mandatory to use it either. If it aborts, the system continues functioning...

The version now in systemd doesn't. Because of the interdependencies it is just as likely to crash the system if it aborts. It does crash the system if dbus aborts...

I would have a LOT less heartburn over systemd if it stayed away from the core init functions of getting the system started. Some of the features are quite nice and would be very useful - the process monitoring is interesting though I don't care for the specific implementation (too error prone - this is what forces all the changes into all the services and causes some of the startup/shutdown problems). The interference with logging I can do without (that was done because it lost log events, I also don't like binary logs - impossible to read during recovery unless you have a nearly full installation from a different boot device).

I feel like being someone that tell the truth about Santa Claus...

Well, SystemD is just a INIT system. Of course that it replace the orthodox init functions. Because that is his nature. The reason to exist. You want the turkey cooked and be still alive?

On topic:

Bart, how is the now the level of working of Network Manager under your SystemD? I want to test that thing, and to known possible problems...

1 members found this post helpful.

you can read the logs with a live CD (the live CD needs to have systemd tho)

Here is a video explaining some things. (yes lennart is speaking)

https://access.redhat.com/site/videos/403833

This video is explaining things you might not know.

@Darth-Vader: on the wiki you can see how to build systemd without pam (and yes this does require shadow at least to be build)
Network-Manager is working fine, you just need to make sure inet1.service is disabled.

I am abit busy at the office this week, so hopefully I can continue this weekend.

1 members found this post helpful.

That is the problem. It isn't just an init system. It also attempts to be a dependency web sorting solver. And a process monitoring solution. And a network monitoring solution. And a system log solution.

Had these additional functions been implemented separately from init (quite possible) and from each other, there wouldn't be a problem - the parts that don't work could be easily replaced or substituted. Instead, it takes a NP hard problem (web dependency sorting) and mashes it into process/network monitoring and logging... Making the entire thing a mess. Any part fails and the system crashes. Or hangs (I think it causes a livelock, but can't get the system to respond when it happens).

As for boot speed, I have two VMs, one running Fedora 19, one running Slakware. The slackware VM boots faster.

Again, this thread is NOT about problems that you see in systemd in general, this thread is about porting systemd to Slackware. Please keep this thread on topic.

2 members found this post helpful.

I have right now a machine with your SystemD (built without PAM support). And it works fine.

But, I do not, yet, make support per SystemD for NetworkManager. That was the question. If I should expect eventually problems after activating the support for SystemD into NetworkManager...

With a new never-before attempted port there are going to be issues that are unresolved or problematic. Best we put our cards on the table now before we ante up.

Actually someone recently did audit the code of Slackware with it's current code and patch set and with only a few minor fixes, Slackware was able to rebuild against itself. Fedora has just about as many if not more patches than Slackware does.