[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Status in init.d (was: Re: init script config files)



On Sat, Jul 08, 2000 at 11:05:12PM -0300, Henrique M Holschuh wrote:
> 
> Unfortunately, the *current* LSB standards has that status thingie in it.
> Debian will eventually adopt the LSB, so we'll either have to implement (and
> do it RIGHT, it *has* to be *very* accurate and detect stale lock/pid files
> per the LSB) status, or we must convince the LSB to remove it from the
> standard.

LSB also wants to use RPM i guess we better plan on throwing out dpkg
and apt-get eh?  

frankly from what i have seen of the LSB they are including FAR too
much redhat non-standardisms.  if they want to create a fucked up
standard then LSB be damned i hope debian ignores it.  

if LSB wants us to use that stupid redhat esque /etc/rc.d/init.d
instead of /etc/init.d will we do that? i hope not. if LSB wants us to
throw away dpkg in favor of that peice of manure RPM will we do that?  

either LSB needs to stop letting redhat run the show or we should just
ignore it.  the `standard' for operating systems is Windows so i
really don't give a damn if the `stadard' for linux is redhat.  

> BTW, a working (as in well behaved, well implemented, AND accurate) status
> function is useful for sysvinit wrappers. Debian will have one of these
> (optional, the flamewars will make sure of THAT at least) sooner or later,
> and IMHO they're the reason the LSB left the status stuff in there.

i think a accurate and useful status function is impossible, and a
waste of time. besides that what about the people use use filerc
instead of sysvinit scripts?  some people hate sysv.   the burdon
should be on the eye candy wrapper people to make thier wrapper work,
not the initscript maintainers.  

> Yes, you can. Automated tools, however, could probably benefit greatly of an
> accurate (and consistant) status function (which is supposedly tailored to
> detect if a certain daemon is either running or dead in the most accurate
> way it can be done for that particular daemon)...

bloat.  IMNSHO this will be the decline of GNU/Linux, where
complicated bloat will be littered about to make it easier on the eye
candy programs and idiot wrappers.  as far as im concerned those
people can just use windows.  (or else a specifically broken linux
distribution designed to work with that crap the rest of us will
ignore anyway.)

i think this LSB should define very little, individual distributions
should be able to write their initscripts however they damnwell
please, the individual daemon should not even include such things. 

> PS: I am against anything more damaging to the holy KISS principle than a
> conffile defaults (variable assignment ONLY) directory (with conffile init

agreed, but i really don't think its worth it.

> scripts). RedHat-style init scripts be damned, the stuff the LSB asks us to
> do (right now) is already complicated enough to do _right_ (half-assed
> solutions need NOT apply).

screw the LSB then, i don't want debian to be ruined just to comply
with some dubious `standard' 

>   "One disk to rule them all, One disk to find them. One disk to bring
>   them all and in the darkness grind them. In the Land of Redmond
>   where the shadows lie." -- The Silicon Valley Tarot
>   Henrique Holschuh

how appropriate to describe something like the LSB, taking away our
freedom to build a quality, elegant distribution free of cruft and
unecessary bloat.

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

Attachment: pgprN0YBxnbJB.pgp
Description: PGP signature


Reply to: