[patch] rc.d/tmp (silly mkdir usage)

[diz at linuxpowered.com]

All the while I point to code example of this exact same usage being
deployed in the system already, and in the same exact situation. I see no
reason why you must bikeshed on this. Correctness is always correct,
despite established bad'ism, and in this case I am carefull to use an
already approved shell code commit even if that is bad, it is approved bad
or at least commited previously.

-Jon

> On Mon, 1 Aug 2005 23:37:05 -0500 (CDT)
> diz at linuxpowered.com wrote:
>> I grep'ed the entire rc.d dir, and found that the same technique is used
>> elsewhere in accounting, and cleanvar. So I feel justified this time,
>> although please review, and thanks for the look. While I understand the
>> need to want a fork program to touch, or otherwise create an inode, I
>> feel
>> forking for such an effort is weird and a bit over-engineered.
>
> Well, while one prefers a system to boot as quickly as reasonably
> possible,
> it's not like startup is particularly performance-critical.  This is
> another
> place where I feel that clarity more than compensates for (very minor)
> slowness,
> particularly when coupled with the fact that the cost of a fork()/exec()
> is
> overwhelmed by the cost of cranking up some of the heavy-weight daemons.
>
> It seems to me that you're looking at things from a very "hacky"
> perspective.
> That is, it seems that you know a lot of shortcuts that add a bit of speed
> here and there and that's what you're trying to apply.  (Please correct me
> if I'm wrong.)  I would suggest that you look at the startup scripts
> somewhat
> differently, by asking yourself what is _broken_ there.  I've seen at
> least a
> couple of suggestions along this line in reply to you.  The mkdir usage
> isn't
> really broken, it seems to me.  While I'm by no stretch of the imagination
> an
> expert regarding the rc scripts (they work and I ignore them), there are
> others
> around here that are, and they can, I am certain, give you some relevant,
> useful and very challenging suggestions.
> --
> Frank Mayhar frank at exit.com	http://www.exit.com/
> Exit Consulting                 http://www.gpsclock.com/
>                                 http://www.exit.com/blog/frank/
>