LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Closed Thread
 
Search this Thread
Old 06-04-2013, 09:02 PM   #391
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, Slackware-14.1, PCBSD-10.0
Posts: 2,883
Blog Entries: 15

Rep: Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743

Quote:
Originally Posted by T3slider View Post
Maybe you need to read this:

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

Quote:
Originally Posted by Matthew October 1, 2009 at 12:20 am

“Some distros (both technical and social) might be about choice, and others might not be. And that’s fair.”

So Linux is about choice 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.
Old 06-04-2013, 09:07 PM   #392
qweasd
Member
 
Registered: May 2010
Posts: 436

Rep: Reputation: Disabled
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.
 
Old 06-04-2013, 11:00 PM   #393
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, Slackware-14.1, PCBSD-10.0
Posts: 2,883
Blog Entries: 15

Rep: Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743
Let's just hope all that flexibility can amount of something rather than be swept under the rug with reckless abandon.
 
Old 06-05-2013, 12:22 AM   #394
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.0
Posts: 2,243

Rep: Reputation: 616Reputation: 616Reputation: 616Reputation: 616Reputation: 616Reputation: 616
Quote:
Originally Posted by rkelsen View Post
Never used Dropline Gnome? They extensively leverage Slackware's SysV capabilities, because it is easier and yields a cleaner result. It means that they don't have to mess with any of the default scripts and that when the user decides to uninstall Dropline, their system will be restored to a pristine state.
My not using Dropline was due to reasons entirely other than init scripts.
Quote:
Originally Posted by rkelsen View Post
It is pretty clear that you haven't used this.
You're wrong. I have.
Quote:
Originally Posted by rkelsen View Post
What you said is patently wrong. SysV init is fully supported in a default installation of Slackware.
I didn't say it wasn't 'fully supported'...
Quote:
Originally Posted by rkelsen View Post
You can't say that it doesn't work merely because it offends your principles...
...or that it didn't work. You've put words in my mouth.
Quote:
Originally Posted by rkelsen View Post
Pat's implementation of SysVinit is nothing short of genius. I highly recommend that you at least look at it.
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.
Quote:
Originally Posted by rkelsen View Post
As an exercise, download one of the Dropline packages and see how they use it. You don't have to install the package... Just pull it apart and see how it works.
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:
Code:
# rc.sysvinit   This file provides basic compatibility with SystemV style
#               startup scripts.  The SystemV style init system places 
#               start/stop scripts for each runlevel into directories such as
#               /etc/rc.d/rc3.d/ (for runlevel 3) instead of starting them
#               from /etc/rc.d/rc.M.  This makes for a lot more init scripts,
#               and a more complicated execution path to follow through if
#               something goes wrong.  For this reason, Slackware has always
#               used the traditional BSD style init script layout.
#
#               However, many binary packages exist that install SystemV
#               init scripts.  With rc.sysvinit in place, most well-written
#               startup scripts will work.  This is primarily intended to
#               support commercial software, though, and probably shouldn't
#               be considered bug free.
README.functions:
Code:
If you're reading this in /etc/init.d/, Slackware's real init directory is
/etc/rc.d/.  Maybe you already knew this, but it never hurts to say.  :-)

This script was taken from Fedora (and is presumably licensed under the GPL).
While I don't see Slackware init scripts making much use of it (but use it
if you wish), some third party init scripts (such as for commercial software
designed to run on Red Hat based systems) expect this script and use it in
their own init scripts, so it's a good idea to make it available here.

These functions are provided solely for commercial (or other) software that
expects to find "Red Hat-isms".  I wouldn't use them to write new init
scripts (personally), but if you've had experience with them in the past
and like them, by all means feel free.

It's planned to continue support for them.
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.
Old 06-05-2013, 07:34 AM   #395
rkelsen
Senior Member
 
Registered: Sep 2004
Distribution: slackware
Posts: 1,748

Rep: Reputation: 159Reputation: 159
Quote:
Originally Posted by T3slider View Post
I can imagine how it would work, but it means, now, having two init systems to look at.
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.
Quote:
Originally Posted by T3slider View Post
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.
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?
Quote:
Originally Posted by T3slider View Post
# startup scripts will work. This is primarily intended to
# support commercial software, though, and probably shouldn't
# be considered bug free.
[/CODE]
I wonder if he'll put the same disclaimer in systemd? :P
Quote:
Originally Posted by T3slider View Post
These functions are provided solely for commercial (or other) software that
expects to find "Red Hat-isms". I wouldn't use them to write new init
scripts (personally), but if you've had experience with them in the past
and like them, by all means feel free.
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.
Quote:
Originally Posted by T3slider View Post
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.
You said:
Quote:
Originally Posted by T3slider View Post
With a Slackware-style SysV init you still need to place the start stanza in the appropriate place, which means knowing the program's dependencies anyway.
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.
 
Old 06-05-2013, 09:13 AM   #396
jens
Senior Member
 
Registered: May 2004
Location: Belgium
Distribution: Debian, Slackware, Fedora
Posts: 1,190

Rep: Reputation: 159Reputation: 159
Quote:
Originally Posted by ReaperX7 View Post
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.
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.

Last edited by jens; 06-05-2013 at 10:51 AM. Reason: spelling
 
2 members found this post helpful.
Old 06-05-2013, 10:04 AM   #397
GazL
Senior Member
 
Registered: May 2008
Posts: 3,324

Rep: Reputation: 881Reputation: 881Reputation: 881Reputation: 881Reputation: 881Reputation: 881Reputation: 881
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.
 
Old 06-05-2013, 11:29 AM   #398
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 1,919

Rep: Reputation: Disabled
Quote:
Originally Posted by GazL View Post
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?
 
Old 06-05-2013, 12:25 PM   #399
GazL
Senior Member
 
Registered: May 2008
Posts: 3,324

Rep: Reputation: 881Reputation: 881Reputation: 881Reputation: 881Reputation: 881Reputation: 881Reputation: 881
Quote:
Originally Posted by Ser Olmy View Post
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.
Old 06-05-2013, 02:55 PM   #400
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.0
Posts: 2,243

Rep: Reputation: 616Reputation: 616Reputation: 616Reputation: 616Reputation: 616Reputation: 616
Quote:
Originally Posted by rkelsen View Post
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.
rc.local and rc.local_shutdown are not stock scripts (rc.local is shipped, I believe, but is empty save for comments).
Quote:
Originally Posted by rkelsen View Post
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?
Most stanzas include
Code:
if [ -x /etc/rc.d/rc.script ]; then
...
fi
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.
Quote:
Originally Posted by rkelsen View Post
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.
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.
Quote:
Originally Posted by rkelsen View Post
Quote:
Originally Posted by T3slider View Post
With a Slackware-style SysV init you still need to place the start stanza in the appropriate place, which means knowing the program's dependencies anyway.
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.
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.
Old 06-05-2013, 03:05 PM   #401
solarfields
Member
 
Registered: Feb 2006
Location: Outer Shpongolia
Distribution: Slackware
Posts: 448

Rep: Reputation: 116Reputation: 116
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.
 
Old 06-05-2013, 03:47 PM   #402
kikinovak
Senior Member
 
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: ElementaryOS, Ubuntu LTS, Slackware
Posts: 1,498

Rep: Reputation: 682Reputation: 682Reputation: 682Reputation: 682Reputation: 682Reputation: 682
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.
Old 06-05-2013, 03:52 PM   #403
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, Slackware-14.1, PCBSD-10.0
Posts: 2,883
Blog Entries: 15

Rep: Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743
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.

Last edited by ReaperX7; 06-05-2013 at 03:55 PM.
 
1 members found this post helpful.
Old 06-05-2013, 06:23 PM   #404
rkelsen
Senior Member
 
Registered: Sep 2004
Distribution: slackware
Posts: 1,748

Rep: Reputation: 159Reputation: 159
Quote:
Originally Posted by GazL
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, then Slackware's implementation is the sane one.
Quote:
Originally Posted by T3slider
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.
Straw man. Nice.
 
Old 06-05-2013, 06:52 PM   #405
GazL
Senior Member
 
Registered: May 2008
Posts: 3,324

Rep: Reputation: 881Reputation: 881Reputation: 881Reputation: 881Reputation: 881Reputation: 881Reputation: 881
Quote:
Originally Posted by rkelsen View Post
If this is correct, then Slackware's implementation is the sane one.
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.
 
  


Closed Thread

Tags
cgroups


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Slackware: Is Systemd Inevitable? LXer Syndicated Linux News 5 07-22-2013 04:54 AM
[SOLVED] slackware and systemd fl0 Slackware 512 08-29-2012 11:07 AM
slackware and systemd (OT) eloi Slackware 44 08-24-2012 04:36 PM
[SOLVED] systemd and Slackware's future kikinovak Slackware 95 07-14-2012 11:40 AM
Boot Delay 30min: systemd-analyze blame systemd-tmpfiles-setup.service BGHolmes Fedora 0 07-27-2011 09:02 AM


All times are GMT -5. The time now is 12:42 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration