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) > [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://www.exit.com/ > Exit Consulting http://www.gpsclock.com/ > http://www.exit.com/blog/frank/ > _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
