I understand that. Originally I never mean't for this thread to explode into the big ball of flames that it did.

I just wanted to try to start ideas or opinions on what a competitive solution
could be to systemd.

The responses that followed pretty much said that there is nothing wrong
with Sys V so why change it?

Therefore it is frustrating to have non consensus in any area of this issue.

People who think SysV is perfect and systemd is a pointless usurpation.

People who think SysV is not perfect and systemd is the solution.

& Then on both sides

Loyalists to both causes for their effects they could have on how they enjoy Slackware/GNULinux.


I didnt come here to argue.

I just wanted people who disagreed with systemd to talk about alternatives (ReaperX7 having the best responses yet in the thread).

Instead of what has already happened in this thread, and other threads regarding systemd.


I understand why you said what you said now. Sorry for the trouble.

Actually no init system will ever be truly perfect.

RunIt, systemd, OpenRC, sysvinit, and bsdinit, as well as every other init system out there will all have their shortfalls. They always have and always will, but systemd is a init that's trying to perform the equivalent feet of killing a squirrel with a bazooka.

A true future-proof init needs to be expandable which sysvinit and bsdinit both offer and accept into each other. Slackware's BSDInit implementation accepts both itself and sysvinit, and can further be expanded if you really want to do so. If you wanted you could add in daemontools, RunIt, s6, or any other service management and supervisory toolkit, then find a way to add in tree-dependency loading of services in parallel, and you'd have a equivalency to systemd for less than half the system overhead and bloatware costs.

The only problem is, OpenRC has already done this. OpenRC can be grafted into sysvinit and bsdinit without usurping them, and uses existing libraries and toolkits to manage services as they should be managed, in a modular form. OpenRC has been arpund a lot longer than systemd has, and does the same workload and more.

The only difference between systemd and OpenRC's acceptance is Lennart has major backing (developmentally and financially) by Red Hat and through Red Hat's pressuring of software developers for Linux it has a wider range of people willing to drink the Jim Jones kool-aid, and OpenRC was a project done by Gentoo... do the math and you see who controls the future of Linux, and possibly what is to come.

Deleted by poster.

By the very statement that if one is not well informed he shouldn't talk about it, no threads should be started in any ways on any forums. Most asked out of ignorance or lack of knowledge. And the whole point is to learn from those who know more. Just saying...

Oh, come on, there is a difference between threads where somebody needs help and threads meant to discuss a topic and I am fairly sure you know that. If you have to ask something it is obvious that you don't have the knowledge and need help. But if you open a thread meant for discussion you should have at least some basic knowledge about the topic. You also wouldn't open a thread on a car forum and discuss engines when you have no knowledge about engines.Of course it is. Learning about a software starts by going to the developers site and read the documentation.

There's no such thing as a stupid question... just a stupid answer.

Well, I can see that you've never been a platoon leader.

It's just those bloody stupid answers Richard... repeating them again, and again, and again...

Because it's the de facto standard. And it's the de facto standard, because they are drinking the Kool-Aid.

It's not the true de-facto standard. It's the Red Hat de-facto standard rammed down your throat claiming to be the true de-facto standard.

I feel like The Doctor trying to explain this in metaphor and soliloquy and maintaining sanity within the insanity of things.

I have looked at that document. Since it was written by people that really, really want systemd to be adopted by Debian, I can believe that they'd pull some parc out of their ttub. But when someone writes......it's rather difficult to take anything following seriously.

Look, I get the drive behind a unified thingy starter. Certainly, the things that we want to start when we plug in a device are more similar than not than the things that we find when we start running which are more similar than not than the things we want to run when someone contacts us on a certain port.

Unless, perhaps, that isn't exactly the case.

To a large extent, the direction that systemd is moving towards is similar to the direction that Gnome is taking. And I haven't agreed with that direction since Gnome 2.x.

I trust Pat's views on the matter. He's "resisted" PAM for over a decade. If he decides that we must start using systemd, well, then I'll use it until/unless it bugs me enough to move to another distro.

Until Slackware uses systemd, I'm not gonna worry about it. Other than dealing with the goofball RedHat systems that I deal with in the Day Job (TM). [Kickstart was written by frigging lunatics.]

*sigh* I see that you missed the joke.

The story of my life, indeed.

Yes. And i accept your point. What im trying to say is that one shouldn't need to b a subject matter expert in order to voice his/her views.

To quote an example, i offen find that there is something to take away even from different threads asking the same question. Anyway, it's not intended to b personal. Or maybe im just saying it because im guilty of ask

---------- Post added 11-07-13 at 05:35 AM ----------

Yes. And i accept your point. What im trying to say is that one shouldn't need to b a subject matter expert in order to voice his/her views.

To quote an example, i offen find that there is something to take away even from different threads asking the same question. Anyway, it's not intended to b personal. Or maybe im just saying it because im guilty of asking stupid questions at times :)

No, that is not configuration-less, it is just configuration by patching the source code. The dream of a C programmer...

Super duper.