Date: Sun, 29 Nov 1998 08:26:12 +0000 From: daniel lawrence <danny@AlphaZed.com> To: Greg Lehey <grog@lemis.com> Cc: dyson@iquest.net, wes@softweyr.com, tlambert@primenet.com, advocacy@FreeBSD.ORG Subject: Re: Linux to be deployed in Mexican schools; Where was FreeBSD? Message-ID: <36610524.F573A5C7@AlphaZed.com> References: <19981129175648.F456@freebie.lemis.com> <199811290733.CAA35884@y.dyson.net> <19981129183019.H456@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Greg Lehey wrote: > > On Sunday, 29 November 1998 at 2:33:53 -0500, John S. Dyson wrote: > > Greg Lehey said: > >> > >> OK, I must be missing something, but what does System V init have that > >> makes it easier to start up or shut down an application? /etc/rc*.d > >> isn't the problem: that's a question of scripts, not init. > >> > > Init supports runmodes (good or bad -- I don't care -- if one doesn't like > > it, then don't use them.) > > OK. The *idea* of run modes seems to make sense, and I wouldn't > change the System V method on a system which had it, but how useful is > it really? Consider: > > Run state Meaning BSD init > 0 halt halt > 1 single user shutdown > 2 multi user, Whaat?? > no network > 3 multiuser (multiuser; stop single user) > 4 undefined > (most systems) can't see any equivalent on PCs > 5 PROM monitor > 6 reboot reboot > > Where's the important difference? > > > SysV init has an established set of standards for usage of > > startup/shutdown files. It doesn't solve ALL problems, but moves > > forward, other than just staying idle. > > Sure, but as I said, that's all a question of scripts. That is absolutely correct. Most SysV's that I have used had truly abominable init scripts. It is always a cross your fingers time when you change run levels because sometimes the daemons would be killed correctly and sometimes not. Sometimes the scripts would try to start a daemon even if it was already running. This would happen if you tried to go from 2 to 3 to 2, for example. At one site I got so impatient with the factory scripts that I rewrote every one of them so that the "run level" concept for levels 2, 3 and 4 actually were treated as sub/supersets. Level 2 was the usual mutli-user, no network; 3 started networking daemons; 4 started Oracle. Going from 2 to 4 caused level 3 start/stop scripts to be invoked. This is more limited than the original concept where run levels can almost cause the machine to take on different personalities, depending on the run level, but it is infinitely more useful. The machine subjectively felt more solid, if only because there was no question about what it was going to do when you ran init. > Greg > -- > See complete headers for address, home page and phone numbers > finger grog@lemis.com for PGP public key > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-advocacy" in the body of the message -- daniel lawrence AlphaZed, Ltd mailto:danny@AlphaZed.COM http://uk.AlphaZed.COM +44 (0)1322 410 419 London To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36610524.F573A5C7>