Maybe you need to read this:

http://blogs.gnome.org/hughsie/2009/...-about-choice/

No one is forcing anyone to use software (A) instead of software (B). You can freely pick to use Slackware or use Fedora, however in that respect, in regards to the packages used, there is the option and choice of customization.

Have you ever built a Linux From Scratch system? LFS is entirely about choice when you get to the BLFS stage. Yes, the core LFS system is fairly streamlined into a single existence, but afterwards you then have a choice for your system.

Should I build and install X11 or Apache web server? Should I build QT or GTK? Do I need to build a package for Firefox or not?

Regardless what some drone of Red Hat like Adam Jackson would stake to claim that Linux isn't about choice as stated here, Linux actually is about choice beyond the core, and even within the core at times.

It's this kind of poisonous thoughts and talk that have allowed bad software to permeate and seep into Linux at a frightening pace, and why little is being done to ensure that sanity is achieved before chaos ensues and GNU/Linux becomes something it was never intended to be at all.

3 members found this post helpful.

I think Slackware strikes a great balance by supporting both SysV bureaucracy and BSD zoo of the init scripts; maximum flexibility for a very modest price.

Let's just hope all that flexibility can amount of something rather than be swept under the rug with reckless abandon.

My not using Dropline was due to reasons entirely other than init scripts.
You're wrong. I have.
I didn't say it wasn't 'fully supported'...
...or that it didn't work. You've put words in my mouth.
I have looked at it. But it is easier to label me ignorant than to understand my side, so you can continue pretending I have no idea what I'm talking about if it makes your arguments easier to fabricate.
I can imagine how it would work, but it means, now, having two init systems to look at. A desktop environment should not need to run anything early in the boot process (though Gnome has always been farther reaching than it should, so who knows), but I would imagine most scripts could be contained in an rc.dropline file which itself checks for the executable bit on sub-scripts -- but I suppose they have chosen not to do that. The only relevant times that rc.sysvinit gets called are in rc.M (it gets called right before rc.local) and rc.K (it gets called a little before rc.local_shutdown). A properly written rc.dropline with a stanza in rc.local and rc.local_shutdown would have worked just as well and remained elegant...but I digress. I suppose they could have run different start scripts in runlevel 3 compared to runlevel 4 using SysV init, but why would that ever be necessary?

From the Man himself:
rc.sysvinit:
README.functions:
Slackware ships BSD-style scripts and has to write some of them by hand, and maintainers at slackbuilds.org often have to do the same. This is all I have said, and again, my point still stands. You can continue to refute it if you wish, but I don't think it's really a debatable point...it is a statement of fact. I have not compared the merits of BSD-style vs SysV-style init scripts, nor have I said that Slackware is incapable of using SysV init scripts. But feel free to put more words in my mouth if it helps you sleep at night.

1 members found this post helpful.

Hyperbole. It's a script and a symlink.

The real advantage comes from the fact that you can drop in a script and it will work with no further effort. At package removal time, the script is removed and the system is exactly as it was beforehand.

The reason I prefer this for add-ons is that it means that I don't have to touch any of the stock scripts, and everything just works.

For some reason, people seem to fear this. I've had this discussion many times before. Your reaction was no different to any others.
And if the user chooses to remove the package, how do you remove the stanza from rc.local? Or do you leave it there for eternity?
I wonder if he'll put the same disclaimer in systemd? :P
Of course, you understand that you don't have to use any of those functions in order to use Slackware's SysVinit, right?

Furthermore, you can use BSD-style scripts and they will work without the need to add a stanza to rc.local... All it takes is a symlink in the right place.
You said: This is wrong. You don't need to put a start stanza anywhere for an init script to work. A single symlink will do it.

You're confusing choice with options ...

If Linux was ABOUT choice, you could demand upstream to do what YOU want.
If Linux was ABOUT choice, ... why would this topic even exist?

That whole Core OS idea is shared by most kernel folks (it's NOT all about systemd at all!!!, you're giving it way to much credit.).
Does that make people like Linus, Greg K-H and most others drug-dealers and brainless drones as well?

Your whole crusade against systemd appears to be something religious.

2 members found this post helpful.

I'm not even sure Slackware's rc.sysvinit gets it right, so it's probably just as well no-one uses it on Slackware.

My understanding of SysV init and 'rc' is that on a change of runlevel 'rc' runs the Knn* scripts of the new runlevel, followed by the Snn* of the new runlevel. Slackware's rc.sysvinit appears to run the Knn* scripts of the previous runlevel, which is not how I was taught it should work.

If this is correct, I can certainly understand how Patrick got it wrong. Going from runlevel X to runlevel Y, how does it make sense to run the shutdown scripts for the new runlevel first? Surely, in order to properly clean up after runlevel X, one must run the shutdown scripts for that runlevel before entering runlevel Y?

Are you sure about this?

I agree it's not intuitive, but yes I'm sure.

Consider this: if you're in runlevel 4 then you would need to stop a different set of services/daemons in order to drop down to runlevel 3 than you would to drop down to runlevel 1. Unless you are happy to take the very inefficient approach of indiscriminately stopping everything and then restarting the things needed for the new target runlevel then you can't use the runlevel 4 entries to stop the services.

In contrast, if you use the kill/start scripts of the target runlevel directory as a delta to get you from where you are to where you want to be then you only need to stop the things that are not desired in the new runlevel. In the case of runlevel 3, the only Knn* script it would contain would be for [KGX]DM (assuming Slackware actually used this mechanism in the first place for these).

If that explanation still leaves you unsure, then ask yourself how the kill scripts of runlevel 0 or 6 (halt/reboot) would ever get called if it worked the way you describe?

1 members found this post helpful.

rc.local and rc.local_shutdown are not stock scripts (rc.local is shipped, I believe, but is empty save for comments).
Most stanzas include
so if it stays, it doesn't matter (it does not get run) and it is easy to remove. The point is moot -- both styles are easy to manage.
And then you need to worry about incremental naming to make sure that everything starts at the right time. In rc.local you just lay things out linearly, in SysV-style init directories you need to prefix scripts with numbers if there is a start sequence. Again, I don't think either one is easier than the other, but one definitely is more consistent with the rest of Slackware.
With a Slackware-style SysV init you need to place the start stanza in the appropriate place. Read more carefully. Also, you completely misunderstood the point of that text -- it was talking about startup dependencies, which I meant to imply Slackware's startup procedure and not necessarily that of third-party software. Therefore, the startup stanza does need to be present *AT THE RIGHT PLACE* in /etc/rc.d/rc.S or /etc/rc.d/rc.M, and no symlink will get it running at the right time (rc.S calls rc.sysvinit but as far as I know no script will ever get run from there since it is not in a numbered runlevel [rc.S is run from inittab during sysinit, which has no numbered runlevel, so there is no appropriate /etc/rc.d/rc${RUNLEVEL}.d directory...correct me if I'm wrong though], and rc.M calls rc.sysvinit right at the end, so symlinking will only allow stuff to run AFTER everything else in rc.M). As it currently stands, without rewriting rc.S/rc.M, you will never get a proper full-system start order using SysV-style scripts in Slackware, and for order-dependent third-party stuff you have the option of throwing it in rc.local or numbering scripts (or links) in rc?.d, only one of which is used officially in Slackware and, as far as I know, at slackbuilds.org. Anyway, this is all overblown, because good reading comprehension would have indicated that the focus of that sentence was on the requirement of knowing startup dependencies with SysV init, and that this is not unique with systemd.

Nothing I have read has discredited my original post or my followups, but people seem to think I have somehow assaulted their way of life by stating plain facts. Since 90% of the posts in this thread are rants without any evidence to back them up, perhaps I haven't drunk enough Kool-Aid to follow the conversation.

1 members found this post helpful.

Since we are talking about boot time: my Slackware system boots for about 10 seconds on a SSD, but honestly I don't really care. If I mess with rc.M it will boot faster. So, what.

What is it that is so fascinating about boot times? What would you think of someone claiming "Hey, I can start my car faster than you" ?!?

1 members found this post helpful.

My home system is up in about 25 seconds, and our servers pop fully functional in about 15 seconds each. That's fast enough for what we need. I don't see how shaving off a few seconds is going to matter. I'm hardly ever actually watching the boot process anyways doing paperwork and checking other machines. We check all the logs for each system after boot anyways so if anything has occurred we'll know about it right away.

As I stated and this has been greatly not answered:

How is systemd supposed to help me when honestly, I find no use for it on my systems for any reason, nor do I have a need for it in any way, shape, form, or fashion, and why should I waste time learning a new Init and process management system when I have a perfectly working on right in front of me without any issues that I already know well enough?

This is the same question, or similar to, what every sane and reasonable system and network administrator has SAID here for God, Jesus, Buddha, Allah, Shiva, whatever deity you have faith in knows how many pages without one reasonable answer.

1 members found this post helpful.

If this is correct, then Slackware's implementation is the sane one.
Straw man. Nice.

hehe. If you think this is backward you should check out JCL condition code logic sometime.


If you think of the runlevel directory as a list of things to stop(if started), and things to start(if stopped), in order to achieve that runlevel then it doesn't seem quite so crazy. The idea just takes a little getting used to.