djb utilities

Matt Rogers mattrogers at sbcglobal.net
Sun May 4 07:47:55 PDT 2003


On Sunday 04 May 2003 05:44 am, Michael A. Peters wrote:
[snip]
>
> > So the question is this.  Are we doing DJB Utilities a disservice by
> > relocating all the files just like every other distrobution AND would
> > installing these utilities as the author intended harm any of our current
> > packages?
> >
> > Larry
>

To answer Larry's question.  If we installed all the DJB packages per the 
author's directions, it will _not_ harm any of the current packages. 
Also, if we remove the djb packages, then that means removing qmail.  IMHO, 
removing qmail is A Bad Idea (tm). It's one of the fastest and most secure 
MDAs I've seen.  However, I think we're doing them a slight disservice by 
making the packages FHS compliant.  I don't have a good argument for this 
other than we should install them where the author wants them cause that's 
how they're meant to work. (yes, i know, a lame argument)


> I looked at Daemontools once.
> It looked like an interesting concept - but wasn't well documented and I
> didn't see the point, really. As far as the "symlink mess" that he
> complains about w/ SysV init - solutions such as chkconfig to manage
> those have existed for a LONG time (as in before Linux afaik) so there
> really isn't much point imho in having daemontools as part of blfs.
>

wasn't well documented? It's as well documented as everything else. The 
unfortunate thing is that you have to download a seperate tarball with the 
man pages because they're not included in the main daemontools package. Red 
Hat was the first distro I've seen that used chkconfig, and even with that 
it's still a pain in the ass to manage the symlinks (IMO). AFICT, you're 
misinterpreting what daemontools is supposed to be used for. daemontools does 
not manage symlinks, but functions more like init.

> But if you have it - standards compliance is a good thing.
>

so what happens if the standards suck? (i generally agree that standards 
compliance is a good thing, but not just for the sake of standards 
compliance)

> Things like this from his web page:
> "In contrast, with init.d and rc.local, daemons are not monitored. Your
> daemon will fail to start if, for example, a previously started daemon
> has temporarily chewed up almost all available memory. The system
> administrator has to manually restart your daemon after he notices the
> problem."
>
> That's a half truth at best. Every system where service availability is
> an issue has software that monitors the daemons, and many daemons fork
> themselves once started to prevent loss of service etc.
>
> So since he's not really completely honest with his propoganda, then
> force his stuff to be as standards compliant as possible.
>
> -=-
> I love this from his page:
>
> -=-
>
> Portability. With /service, your program works the same way on every
> system: Linux, BSD, Solaris, etc.
>
> In contrast, inittab and ttys and init.d and rc.local vary from system
> to system. Some systems don't have init.d, for example, and the ones
> that do have it don't agree on its location. This is extremely annoying
> for cross-platform system administrators.
> -=-
>
> um, no - with /service, your program works the same on any system
> [emphasis]with your fricken software installed[/emphasis] - which can be
> said for ANY boot scheme.

Yup, you have to use his software. But he is correct. inittabs and ttys and 
init.d and rc.local differ from Solaris to Linux to the BSDs.  They may not 
differ much between linux distros, but that's not what he's talking about. 

>
> Sorry to rant - he just doesn't seem to be honest. I don't think his
> stuff should be included at all.
>
> --

So you want to give us a real reason why the DJB stuff shouldn't included? 


--
Matt
http://matt.rogers.name
http://ktagit.sf.net
--
Do not meddle in the affairs of dragons for you are crunchy and taste good 
with ketchup.

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-dev' in the subject header of the message



More information about the blfs-dev mailing list