You are not logged in.
Pages: 1
Why do so many distros out there use SysV style initscripts? What advantage is there to four initscripts per daemon per runlevel, or to so many little config files with weird names? And the first distro out there (Slackware) used BSD-style scripts... So why the bizarre glut of SysV distros? :?
Offline
To make people feel 1337 when they can keep track of all the pointless crud?
Writing stories for a machine.
Offline
After admining several BSD boxen that have been through many hands, I really learned to appreciate sys5. Seven+ page long rc and rc.local files which have some scripting done in them, and some calls to other scripts you have to hunt down on the system are no fun to read through. Looking in a directory that has numbered sequences of what orders daemons start, and then looking at a simple rc.local is a hell of a lot easier. I really don't have a preference at this point, though I do wonder how people who learn on slack/arch/whatever can find their way around other systems like, say, RedHat, which has the messiest most unmanageable /etc in the history of linux.
Unthinking respect for authority is the greatest enemy of truth.
-Albert Einstein
Offline
Well in a way SysV is more flexible. It allows you to assign different programs to different runlevels, something which is not possible in Arch or BSD afaik. I doubt, however, that many people are using this functionality, except for starting or stopping X (which is also possible in Arch, but I guess the preffered way in Arch is just to add {x,g,k}dm to rc.conf).
Offline
I guess the preffered way in Arch is just to add {x,g,k}dm to rc.conf
Don't know where you got that idea; I had the runlevel method recommended to me over the daemon way many times here, and personally I quite prefer it.
Offline
After admining several BSD boxen that have been through many hands, I really learned to appreciate sys5. Seven+ page long rc and rc.local files which have some scripting done in them, and some calls to other scripts you have to hunt down on the system are no fun to read through. Looking in a directory that has numbered sequences of what orders daemons start, and then looking at a simple rc.local is a hell of a lot easier. I really don't have a preference at this point, though I do wonder how people who learn on slack/arch/whatever can find their way around other systems like, say, RedHat, which has the messiest most unmanageable /etc in the history of linux.
That's an interesting point. But, as you say, I've noticed that SysV distros tend to have 50 or so files floating around in /etc before any extra aemons are even installed, most of them bizarrely named and hidden in bizarrely named directories.
Well in a way SysV is more flexible. It allows you to assign different programs to different runlevels, something which is not possible in Arch or BSD afaik. I doubt, however, that many people are using this functionality, except for starting or stopping X (which is also possible in Arch, but I guess the preffered way in Arch is just to add {x,g,k}dm to rc.conf).
That is indeed the case, but I do wonder what all the runlevels are good for. In all my history of Linux use, I've only used runlevels 1, 3, and (very rarely because login managers suck) 5. A bunch of runlevels could be useful, but I doubt it would be useful very often.
Offline
LB06 wrote:I guess the preffered way in Arch is just to add {x,g,k}dm to rc.conf
Don't know where you got that idea; I had the runlevel method recommended to me over the daemon way many times here, and personally I quite prefer it.
Well I pretty much figured that out myself, so I could very well be wrong I just thought that a part of Arch' simplicity centered philosophy was to do everything (well, as much as possible) in rc.conf. To me, it would make more sense.
Why the hell differentiate between with X and without X? What makes it so special that it deserves its own runlevel? Isn't that just the heritage of good ol' UNIX?
Also, /etc/inittab is definitely not the most intuive place to look at if you want to enable or disable X at boot, for example. I mean, in what sense is an X(DM) daemon differerent from any other daemon? (From a service point of view.)
Offline
Wotca,
Having used UNIX for quite awhile I can honestly say that I really do not much like BSD type init approach, at least the traditional ones (rc.single, rc.local.rc.network .....). Had to work this way back when on SunOS 4.x and when Solaris came out with system V files things got easier to manage.
However, for a couple of boxes BSD fine, but when you're looking at 100s of servers, system V is just easier to use as you can dist out new/improved init scripts without worrying about screwing up the script in the case of single init scripts.
BSD scripts are non obvious in a quick "when does this start" kinda way and same kinda goes for Arch. When does mysql start? When does networking start? I know the answers to these but there will be other services I do not know off the top of my head. With SysV S75mysql will start before S80squid and it is numerically obvious.
Before anyone screams, I do not see that Arch needs to use Sys V and I not gonna dump it because it doesn't, which init system is used is low on my list of importance.
Comments anyone??
Cheers,
Jon
Offline
your daemons start in the order you list them in rc.conf. to me, that's a lot smarter.
Offline
Okay, gotta ask: what's wrong with rc.conf? I could see problems if you're editing it with sed, but with vi?
Offline
Okay, gotta ask: what's wrong with rc.conf? I could see problems if you're editing it with sed, but with vi?
Yes that is somewhat of a disadvantage of Arch initscripts (not BSD scripts), it not really obvious on how to modify the daemons array. You can't echo "enable_postgres=YES" >> /etc/rc.conf, for example. Or ln -s /etc/init.d/kdm /etc/rc5.d/S90kdm for that matter.
I'm not really sure which I like better. The best thing about Arch' initscripts is definitely the intuitivity and the backgrounding thing.
Offline
Pages: 1